@ c1e9ab3a:9cb56b43

## Introduction Throughout human history, the pyramids of Egypt have fascinated scholars, archaeologists, and engineers alike. Traditionally thought of as tombs for pharaohs or religious monuments, alternative theories have speculated that the pyramids may have served advanced technological functions. One such hypothesis suggests that the pyramids acted as large-scale nitrogen fertilizer generators, designed to transform arid desert landscapes into fertile land. This paper explores the feasibility of such a system by examining how a pyramid could integrate thermal convection, electrolysis, and a self-regulating breeder reactor to sustain nitrogen fixation processes. We will calculate the total power requirements and estimate the longevity of a breeder reactor housed within the structure. ## The Pyramid’s Function as a Nitrogen Fertilizer Generator The hypothesized system involves several key processes: - **Heat and Convection**: A fissile material core located in the King's Chamber would generate heat, creating convection currents throughout the pyramid. - **Electrolysis and Hydrogen Production**: Water sourced from subterranean channels would undergo electrolysis, splitting into hydrogen and oxygen due to electrical and thermal energy. - **Nitrogen Fixation**: The generated hydrogen would react with atmospheric nitrogen (N₂) to produce ammonia (NH₃), a vital component of nitrogen-based fertilizers. ## Power Requirements for Continuous Operation To maintain the pyramid’s core at approximately **450°C**, sufficient to drive nitrogen fixation, we estimate a steady-state power requirement of **23.9 gigawatts (GW)**. ### Total Energy Required Over 10,000 Years Given continuous operation over **10,000 years**, the total energy demand can be calculated as: \[ \text{Total time} = 10,000 \times 365.25 \times 24 \times 3600 \text{ seconds} \] \[ \text{Total time} = 3.16 \times 10^{11} \text{ seconds} \] \[ \text{Total energy} = 23.9 \text{ GW} \times 3.16 \times 10^{11} \text{ s} \] \[ \approx 7.55 \times 10^{21} \text{ J} \] ## Using a Self-Regulating Breeder Reactor A **breeder reactor** could sustain this power requirement by generating more fissile material than it consumes. This reduces the need for frequent refueling. ### Pebble Bed Reactor Design - **Self-Regulation**: The reactor would use passive cooling and fuel expansion to self-regulate temperature. - **Breeding Process**: The reactor would convert thorium-232 into uranium-233, creating a sustainable fuel cycle. ### Fissile Material Requirements Each kilogram of fissile material releases approximately **80 terajoules (TJ)** (or **8 × 10^{13} J/kg**). Given a **35% efficiency rate**, the usable energy per kilogram is: \[ \text{Usable energy per kg} = 8 \times 10^{13} \times 0.35 = 2.8 \times 10^{13} \text{ J/kg} \] \[ \text{Fissile material required} = \frac{7.55 \times 10^{21}}{2.8 \times 10^{13}} \] \[ \approx 2.7 \times 10^{8} \text{ kg} = 270,000 \text{ tons} \] ### Impact of a Breeding Ratio If the reactor operates at a **breeding ratio of 1.3**, the total fissile material requirement would be reduced to: \[ \frac{270,000}{1.3} \approx 208,000 \text{ tons} \] ### Reactor Size and Fuel Replenishment Assuming a **pebble bed reactor** housed in the **King’s Chamber** (~318 cubic meters), the fuel cycle could be sustained with minimal refueling. With a breeding ratio of **1.3**, the reactor could theoretically operate for **10,000 years** with occasional replenishment of lost material due to inefficiencies. ## Managing Scaling in the Steam Generation System To ensure long-term efficiency, the water supply must be conditioned to prevent **mineral scaling**. Several strategies could be implemented: ### 1. Natural Water Softening Using Limestone - Passing river water through **limestone beds** could help precipitate out calcium bicarbonate, reducing hardness before entering the steam system. ### 2. Chemical Additives for Scaling Prevention - **Chelating Agents**: Compounds such as citric acid or tannins could be introduced to bind calcium and magnesium ions. - **Phosphate Compounds**: These interfere with crystal formation, preventing scale adhesion. ### 3. Superheating and Pre-Evaporation - **Pre-Evaporation**: Water exposed to extreme heat before entering the system would allow minerals to precipitate out before reaching the reactor. - **Superheated Steam**: Ensuring only pure vapor enters the steam cycle would prevent mineral buildup. - **Electrolysis of Superheated Steam**: Using multi-million volt electrostatic fields to ionize and separate minerals before they enter the steam system. ### 4. Electrostatic Control for Scaling Mitigation - The pyramid’s hypothesized high-voltage environment could **ionize water molecules**, helping to prevent mineral deposits. ## Conclusion If the Great Pyramid were designed as a **self-regulating nitrogen fertilizer generator**, it would require a continuous **23.9 GW** energy supply, which could be met by a **breeder reactor** housed within its core. With a **breeding ratio of 1.3**, an initial load of **208,000 tons** of fissile material would sustain operations for **10,000 years** with minimal refueling. Additionally, advanced **water treatment techniques**, including **limestone filtration, chemical additives, and electrostatic control**, could ensure long-term efficiency by mitigating scaling issues. While this remains a speculative hypothesis, it presents a fascinating intersection of **energy production, water treatment, and environmental engineering** as a means to terraform the ancient world.

@ c1e9ab3a:9cb56b43

## Introduction Since the mid-1990s, American media has fractured into two distinct and increasingly isolated ecosystems, each with its own Overton window of acceptable discourse. Once upon a time, Americans of different political leanings shared a common set of facts, even if they interpreted them differently. Today, they don’t even agree on what the facts are—or who has the authority to define them. This divide stems from a deeper philosophical rift in how each side determines truth and legitimacy. The institutional left derives its authority from the **expert class**—academics, think tanks, scientific consensus, and mainstream media. The populist right, on the other hand, finds its authority in **traditional belief systems**—religion, historical precedent, and what many call "common sense." As these two moral and epistemological frameworks drift further apart, the result is not just political division but the emergence of **two separate cultural nations sharing the same geographic space**. ## The Battle of Epistemologies: Experts vs. Tradition The left-leaning camp sees **scientific consensus, peer-reviewed research, and institutional expertise** as the gold standard of truth. Universities, media organizations, and policy think tanks function as arbiters of knowledge, shaping the moral and political beliefs of those who trust them. From this perspective, governance should be guided by data-driven decisions, often favoring progressive change and bureaucratic administration over democratic populism. The right-leaning camp is skeptical of these institutions, viewing them as ideologically captured and detached from real-world concerns. Instead, they look to **religion, historical wisdom, and traditional social structures** as more reliable sources of truth. To them, the "expert class" is not an impartial source of knowledge but a self-reinforcing elite that justifies its own power while dismissing dissenters as uneducated or morally deficient. This fundamental disagreement over the **source of moral and factual authority** means that political debates today are rarely about policy alone. They are battles over legitimacy itself. One side sees resistance to climate policies as "anti-science," while the other sees aggressive climate mandates as an elite power grab. One side views traditional gender roles as oppressive, while the other sees rapid changes in gender norms as unnatural and destabilizing. Each group believes the other is **not just wrong, but dangerous**. ## The Consequences of Non-Overlapping Overton Windows As these worldviews diverge, so do their respective **Overton windows**—the range of ideas considered acceptable for public discourse. There is little overlap left. What is considered self-evident truth in one camp is often seen as **heresy or misinformation** in the other. The result is: - **Epistemic Closure** – Each side has its own trusted media sources, and cross-exposure is minimal. The left dismisses right-wing media as conspiracy-driven, while the right views mainstream media as corrupt propaganda. Both believe the other is being systematically misled. - **Moralization of Politics** – Since truth itself is contested, policy debates become existential battles. Disagreements over issues like immigration, education, or healthcare are no longer just about governance but about **moral purity versus moral corruption**. - **Cultural and Political Balkanization** – Without a shared understanding of reality, compromise becomes impossible. Americans increasingly consume separate news, live in ideologically homogeneous communities, and even **speak different political languages**. ## Conclusion: Two Nations on One Land A country can survive disagreements, but can it survive when its people no longer share **a common source of truth**? Historically, such deep societal fractures have led to **secession, authoritarianism, or violent conflict**. The United States has managed to avoid these extremes so far, but the trendline is clear: as long as each camp continues reinforcing its own epistemology while rejecting the other's as illegitimate, the divide will only grow. The question is no longer whether America is divided—it is whether these two cultures can continue to coexist under a single political system. Can anything bridge the gap between institutional authority and traditional wisdom? Or are we witnessing the slow but inevitable unraveling of a once-unified nation into **two separate moral and epistemic realities**?

@ c1e9ab3a:9cb56b43

# Election Authority (EA) Platform ## 1.1 EA Administration Interface (Web-Based) - **Purpose**: Gives authorized personnel (e.g., election officials) a user-friendly way to administer the election. - **Key Tasks**: 1. **Voter Registration Oversight**: Mark which voters have proven their identity (via in-person KYC or some legal process). 2. **Blind Signature Issuance**: Approve or deny blind signature requests from registered voters (each corresponding to one ephemeral key). 3. **Tracking Voter Slots**: Keep a minimal registry of who is allowed one ephemeral key signature, and mark it “used” once a signature is issued. 4. **Election Configuration**: Set start/end times, provide encryption parameters (public keys), manage threshold cryptography setup. 5. **Monitor Tallying**: After the election, collaborate with trustees to decrypt final results and release them. ## 1.2 EA Backend Services - **Blind Signature Service**: - An API endpoint or internal module that receives a *blinded ephemeral key* from a voter, checks if they are authorized (one signature per voter), and returns the blind-signed result. - Typically requires secure storage of the EA’s **blind signing private key**. - **Voter Roll Database**: - Stores minimal info: “Voter #12345 is authorized to request one ephemeral key signature,” plus status flags. - Does **not** store ephemeral keys themselves (to preserve anonymity). - **(Optional) Mix-Net or Homomorphic Tally Service**: - Coordinates with trustees for threshold decryption or re-encryption. - Alternatively, a separate “Tally Authority” service can handle this. --- # 2. Auditor Interface ## 2.1 Auditor Web-Based Portal - **Purpose**: Allows independent auditors (or the public) to: 1. **Fetch All Ballots** from the relays (or from an aggregator). 2. **Verify Proofs**: Check each ballot’s signature, blind signature from the EA, OTS proof, zero-knowledge proofs, etc. 3. **Check Double-Usage**: Confirm that each ephemeral key is used only once (or final re-vote is the only valid instance). 4. **Observe Tally Process**: Possibly see partial decryptions or shuffle steps, verify the final result matches the posted ballots. - **Key Tasks**: - Provide a **dashboard** showing the election’s real-time status or final results, after cryptographic verification. - Offer **open data** downloads so third parties can run independent checks. ## 2.2 (Optional) Trustee Dashboard - If the election uses threshold cryptography (multiple parties must decrypt), each **trustee** (candidate rep, official, etc.) might have an interface for: - Uploading partial decryption shares or re-encryption proofs. - Checking that other trustees did their steps correctly (zero-knowledge proofs for correct shuffling, etc.). --- # 3. Voter Application ## 3.1 Voter Client (Mobile App or Web Interface) - **Purpose**: The main tool voters use to participate—**before**, **during**, and **after** the election. - **Functionalities**: 1. **Registration Linking**: - Voter goes in-person to an election office or uses an online KYC process. - Voter obtains or confirms their **long-term (“KYC-bound”) key**. The client can store it securely (or the voter just logs in to a “voter account”). 2. **Ephemeral Key Generation**: - Create an ephemeral key pair (\(nsec_e, npub_e\)) locally. - Blind \(\npub_e\) and send it to the EA for signing. - Unblind the returned signature. - Store \(\npub_e\) + EA’s signature for use during voting. 3. **Ballot Composition**: - Display candidates/offices to the voter. - Let them select choices. - Possibly generate zero-knowledge proofs (ZKPs) behind the scenes to confirm “exactly one choice per race.” 4. **Encryption & OTS Timestamp**: - Encrypt the ballot under the election’s **public** (threshold) key or produce a format suitable for a mix-net. - Obtain an **OpenTimestamps** proof for the ballot’s hash. 5. **Publish Ballot**: - Sign the entire “timestamped ballot” with the ephemeral key. - Include the EA’s blind signature on \(\npub_e\). - Post to the Nostr relays (or any chosen decentralized channel). 6. **Re-Voting**: - If the user needs to change their vote, the client repeats the encryption + OTS step, publishes a new ballot with a strictly later OTS anchor. 7. **Verification**: - After the election, the voter can check that their final ballot is present in the tally set. ## 3.2 Local Storage / Security - The app must securely store: - **Ephemeral private key** (\(nsec_e\)) until voting is complete. - Potential backup/recovery mechanism if the phone is lost. - Blind signature from the EA on \(\npub_e\). - Potentially uses hardware security modules (HSM) or secure enclaves on the device. --- # 4. Nostr Relays (or Equivalent Decentralized Layer) - **Purpose**: Store and replicate voter-submitted ballots (events). - **Key Properties**: 1. **Redundancy**: Voters can post to multiple relays to mitigate censorship or downtime. 2. **Public Accessibility**: Auditors, the EA, and the public can fetch all events to verify or tally. 3. **Event Filtering**: By design, watchers can filter events with certain tags, e.g. “election: 2025 County Race,” ensuring they gather all ballots. --- # 5. Threshold Cryptography Setup ## 5.1 Multi-Seg (Multi-Party) Key Generation - **Participants**: Possibly the EA + major candidates + accredited observers. - **Process**: A **Distributed Key Generation (DKG)** protocol that yields a single **public** encryption key. - **Private Key Shares**: Each trustee holds a piece of the decryption key; no single party can decrypt alone. ## 5.2 Decryption / Tally Mechanism - **Homomorphic Approach**: 1. Ballots are *additively* encrypted. 2. Summation of ciphertexts is done publicly. 3. Trustees provide partial decryptions for the final sum. - **Mix-Net Approach**: 1. Ballots are collected. 2. Multiple servers shuffle and re-encrypt them (each trustee verifies correctness). 3. Final set is decrypted, but the link to each ephemeral key is lost. ## 5.3 Trustee Interfaces - **Separate or integrated into the auditor interface**—each trustee logs in and provides their partial key share for decrypting the final result. - Possibly combined with ZK proofs to confirm correct partial decryption or shuffling. --- # 6. OpenTimestamps (OTS) or External Time Anchor ## 6.1 Aggregator Service - **Purpose**: Receives a hash from the voter’s app, anchors it into a blockchain or alternative time-stamping system. - **Result**: Returns a proof object that can later be used by any auditor to confirm the time/block height at which the hash was included. ## 6.2 Verifier Interface - Could be part of the **auditor tool** or the **voter client**. - Checks that each ballot’s OTS proof is valid and references a block/time prior to the election’s closing. --- # 7. Registration Process (In-Person or Hybrid) 1. **Voter presents ID** physically at a polling station or a designated office (or an online KYC approach, if legally allowed). 2. **EA official**: - Confirms identity. - Links the voter to a “voter record” (Voter #12345). - Authorizes them for “1 ephemeral key blind-sign.” 3. **Voter obtains or logs into the voter client**: - The app or website might show “You are now cleared to request a blind signature from the EA.” - Voter later (or immediately) generates the ephemeral key and requests the blind signature. --- # 8. Putting It All Together (High-Level Flow) 1. **Key Setup** - The EA + trustees run a DKG to produce the **election public key**. 2. **Voter Registration** - Voter is validated (ID check). - Marked as eligible in the EA database. 3. **Blind-Signed Ephemeral Key** - Voter’s client generates a key, blinds \(\npub_e\), obtains EA’s signature, unblinds. 4. **Voting** 1. Voter composes ballot, encrypts with the election public key. 2. Gets OTS proof for the ballot hash. 3. Voter’s ephemeral key signs the entire package (including EA’s signature on \(\npub_e\)). 4. Publishes to Nostr. 5. **Re-Voting** (Optional) - Same ephemeral key, new OTS timestamp. - Final ballot is whichever has the latest valid timestamp before closing. 6. **Close of Election & Tally** 1. EA announces closing. 2. Tally software (admin + auditors) collects ballots from Nostr, discards invalid duplicates. 3. Threshold decryption or mix-net to reveal final counts. 4. Publish final results and let auditors verify everything. --- # 9. Summary of Major Components Below is a succinct list: 1. **EA Admin Platform** - Web UI for officials (registration, blind signature issuing, final tally management). - Backend DB for voter records & authorized ephemeral keys. 2. **Auditor/Trustee Platforms** - Web interface for verifying ballots, partial decryption, and final results. 3. **Voter Application (Mobile / Web)** - Generating ephemeral keys, getting blind-signed, casting encrypted ballots, re-voting, verifying included ballots. 4. **Nostr Relays (Decentralized Storage)** - Where ballots (events) are published, replicated, and fetched for final tally. 5. **Threshold Cryptography System** - Multi-party DKG for the election key. - Protocols or services for partial decryption, mix-net, or homomorphic summation. 6. **OpenTimestamps Aggregator** - Service that returns a blockchain-anchored timestamp proof for each ballot’s hash. ## Additional Implementation Considerations - **Security Hardening**: - Using hardware security modules (HSM) for the EA’s blind-signing key, for trustee shares, etc. - **Scalability**: - Handling large numbers of concurrent voters, large data flows to relays. - **User Experience**: - Minimizing cryptographic complexity for non-technical voters. - **Legal and Procedural**: - Compliance with local laws for in-person ID checks, mandatory paper backups (if any), etc. --- ## Final Note While each **functional block** can be designed and deployed independently (e.g., multiple aggregator services, multiple relays, separate tally servers), the **key** to a successful system is **interoperability** and **careful orchestration** of these components—ensuring strong security, a straightforward voter experience, and transparent auditing. nostr:naddr1qqxnzde5xq6nzv348yunvv35qy28wue69uhnzv3h9cczuvpwxyargwpk8yhsygxpax4n544z4dk2f04lgn4xfvha5s9vvvg73p46s66x2gtfedttgvpsgqqqw4rs0rcnsu

@ c1e9ab3a:9cb56b43

# 1. Introduction Modern election systems must balance **privacy** (no one sees how individuals vote) with **public verifiability** (everyone can confirm the correctness of the tally). Achieving this in a decentralized, tamper-resistant manner remains a challenge. Nostr (a lightweight protocol for censorship-resistant communication) offers a promising platform for distributing and archiving election data (ballots) without relying on a single central server. This paper presents a design where: 1. Each *voter* generates a **new ephemeral Nostr keypair** for an election. 2. The election authority (EA) **blind-signs** this ephemeral public key (npub) to prove the voter is authorized, without revealing which voter owns which ephemeral key. 3. Voters cast *encrypted ballots* to Nostr relays, each carrying an **OpenTimestamps** proof to confirm the ballot’s time anchor. 4. **Re-voting** is allowed: a voter can replace a previously cast ballot by publishing a *new* ballot with a *newer* timestamp. 5. Only the *latest valid ballot* (per ephemeral key) is counted. We combine well-known cryptographic primitives—**blind signatures**, **homomorphic or mix-net encryption**, **threshold key management**, and **time anchoring**—into an end-to-end system that preserves anonymity, assures correctness, and prevents double-voting. --- # 2. Roles and Components ## 2.1 Voters - **Long-Term (“KYC-bound”) Key**: Each voter has some identity-verified Nostr public key used only for official communication with the EA (not for voting). - **Ephemeral Voting Key**: For each election, the voter **locally generates** a new Nostr keypair \((nsec_e, npub_e)\). - This is the “one-time” identity used to sign ballots. - The EA never learns the real identity behind \(\npub_e\) because of **blinding**. ## 2.2 Election Authority (EA) - Maintains the **official voter registry**: who is entitled to vote. - **Blind-Signs** each valid voter’s ephemeral public key to authorize exactly one ephemeral key per voter. - Publishes a **minimal voter roll**: e.g., “Voter #12345 has been issued a valid ephemeral key,” without revealing which ephemeral key. ## 2.3 Nostr Relays - Decentralized servers that store and forward events. - Voters post their ballots to relays, which replicate them. - No single relay is critical; the same ballot can be posted to multiple relays for redundancy. ## 2.4 Cryptographic Framework 1. **Blind Signatures**: The EA signs a blinded version of \(\npub_e\). 2. **Homomorphic or Mix-Net Encryption**: Ensures the content of each ballot remains private; only aggregate results or a shuffled set are ever decrypted. 3. **Threshold / General Access Structure**: Multiple trustees (EA plus candidate representatives, for example) must collaborate to produce a final decryption. 4. **OpenTimestamps (OTS)**: Attaches a verifiable timestamp proof to each ballot, anchoring it to a blockchain or other tamper-resistant time reference. --- # 3. Protocol Lifecycle This section walks through **voter registration**, **ephemeral key authorization**, **casting (and re-casting) ballots**, and finally the **tally**. ## 3.1 Registration & Minimal Voter Roll 1. **Legal/KYC Verification** - Each real-world voter proves their identity to the EA (per legal procedures). - The EA records that the voter is eligible to cast one ballot, referencing their long-term identity key (\(\npub_{\mathrm{KYC}}\)). 2. **Issue Authorization “Slot”** - The EA’s voter roll notes “this person can receive exactly one blind signature for an ephemeral key.” - The roll does *not* store an ephemeral key—just notes that it can be requested. ## 3.2 Generating and Blinding the Ephemeral Key 1. **Voter Creates Ephemeral Key** - Locally, the voter’s client generates a fresh \((nsec_e, npub_e)\). 2. **Blinding** - The client blinds \(\npub_e\) to produce \(\npub_{e,\mathrm{blinded}}\). This ensures the EA cannot learn the real \(\npub_e\). 3. **Blind Signature Request** - The voter, using their **KYC-bound key** (\(\npub_{\mathrm{KYC}}\)), sends \(\npub_{e,\mathrm{blinded}}\) to the EA (perhaps via a secure direct message or a “giftwrapped DM”). - The EA checks that this voter has not already been issued a blind signature. - If authorized, the EA signs \(\npub_{e,\mathrm{blinded}}\) with its private key and returns the blinded signature. 4. **Unblinding** - The voter’s client unblinds the signature, obtaining a **valid signature** on \(\npub_e\). - Now \(\npub_e\) is a **blinded ephemeral public key** that the EA has effectively “authorized,” without knowing which voter it belongs to. 5. **Roll Update** - The EA updates its minimal roll to note that “Voter #12345 received a signature,” but does *not* publish \(\npub_e\). ## 3.3 Casting an Encrypted Ballot with OpenTimestamps When the voter is ready to vote: 1. **Compose Encrypted Ballot** - The ballot can be **homomorphically** encrypted (e.g., with Paillier or ElGamal) or structured for a **mix-net**. - Optionally include Zero-Knowledge Proofs (ZKPs) showing the ballot is valid (one candidate per race, etc.). 2. **Obtain OTS Timestamp** - The voter’s client computes a **hash** \(H\) of the ballot data (ciphertext + ZKPs). - The client sends \(H\) to an **OpenTimestamps** aggregator. - The aggregator returns a **timestamp proof** verifying that “this hash was seen at or before block/time \(T\).” 3. **Create a “Timestamped Ballot” Payload** - Combine: 1. **Encrypted ballot** data. 2. **OTS proof** for the hash of the ballot. 3. **EA’s signature** on \(\npub_e\) (the blind-signed ephemeral key). 4. A final **signature** by the voter’s ephemeral key \((nsec_e)\) over the entire package. 4. **Publish to Nostr** - The voter posts the complete “timestamped ballot” event to one or more relays. - Observers see “an event from ephemeral key \(\npub_e\), with an OTS proof and the EA’s blind signature,” but cannot identify the real voter or see the vote’s contents. ### 3.4 Re-Voting (Updating the Ballot) If the voter wishes to revise their vote (due to coercion, a mistake, or simply a change of mind): 1. **Generate a New Encrypted Ballot** - Possibly with different candidate choices. 2. **Obtain a New OTS Proof** - The new ballot has a fresh hash \(H'\). - The OTS aggregator provides a new proof anchored at a *later* block/time than the old one. 3. **Publish the Updated Ballot** - Again, sign with \(\npub_e\). - Relays store both ballots, but the *newer* OTS timestamp shows which ballot is “final.” **Rule**: The final vote for ephemeral key \(\npub_e\) is determined by the ballot with the **highest valid OTS proof** prior to the election’s closing. ## 3.5 Election Closing & Tally 1. **Close Signal** - At a specified time or block height, the EA publishes a “closing token.” - Any ballot with an OTS anchor referencing a time/block *after* the closing is invalid. 2. **Collect Final Ballots** - Observers (or official tally software) gather the *latest valid* ballot from each ephemeral key. - They confirm the OTS proofs are valid and that no ephemeral key posted two different ballots with the **same** timestamp. 3. **Decryption / Summation** - If homomorphic, the system sums the encrypted votes and uses a **threshold** of trustees to decrypt the aggregate. - If a mix-net, the ballots are shuffled and partially decrypted, also requiring multiple trustees. - In either case, individual votes remain hidden, but the final counts are revealed. 4. **Public Audit** - Anyone can fetch all ballots from the Nostr relays, verify OTS proofs, check the EA’s blind signature, and confirm no ephemeral key was used twice. - The final totals can be recomputed from the publicly available data. --- # 4. Ensuring One Vote Per Voter & No Invalid Voters 1. **One Blind Signature per Registered Voter** - The EA’s internal list ensures each real voter only obtains one ephemeral key signature. 2. **Blind Signature** - Ensures an *unauthorized* ephemeral key cannot pass validation (forging the EA’s signature is cryptographically infeasible). 3. **Public Ledger of Ballots** - Because each ballot references an EA-signed key, any ballot with a fake or duplicate signature is easily spotted. --- # 5. Security and Privacy Analysis 1. **Voter Anonymity** - The EA never sees the unblinded ephemeral key. It cannot link \(\npub_e\) to a specific person. - Observers only see “some ephemeral key posted a ballot,” not the real identity of the voter. 2. **Ballot Secrecy** - **Homomorphic Encryption** or **Mix-Net**: no one can decrypt an individual ballot; only aggregated or shuffled results are revealed. - The ephemeral key used for signing does not decrypt the ballot—the election’s threshold key does, after the election. 3. **Verifiable Timestamping** - **OpenTimestamps** ensures each ballot’s time anchor cannot be forged or backdated. - Re-voting is transparent: a later OTS proof overrides earlier ones from the same ephemeral key. 4. **Preventing Double Voting** - Each ephemeral key is unique and authorized once. - Re-voting by the same key overwrites the old ballot but does not *increase* the total count. 5. **Protection Against Coercion** - Because the voter can re-cast until the deadline, a coerced vote can be replaced privately. - No receipts (individual decryption) are possible—only the final aggregated tally is revealed. 6. **Threshold / Multi-Party Control** - Multiple trustees must collaborate to decrypt final results, preventing a single entity from tampering or prematurely viewing partial tallies. --- # 6. Implementation Considerations 1. **Blind Signature Techniques** - Commonly implemented with RSA-based Chaumian blind signatures or BLS-based schemes. - Must ensure no link between \(\npub_{e,\mathrm{blinded}}\) and \(\npub_e\). 2. **OpenTimestamps Scalability** - If millions of voters are posting ballots simultaneously, multiple timestamp aggregators or batch anchoring might be needed. - Verification logic on the client side or by public auditors must confirm each OTS proof’s integrity. 3. **Relay Coordination** - The system must ensure no single relay can censor ballots. Voters may publish to multiple relays. - Tally fetchers cross-verify events from different relays. 4. **Ease of Use** - The user interface must hide the complexity of ephemeral key generation, blind signing, and OTS proof retrieval—making it as simple as possible for non-technical voters. 5. **Legal Framework** - If law requires publicly listing which voters have cast a ballot, you might track “Voter #12345 used their ephemeral key” without revealing the ephemeral key. Or you omit that if secrecy about *who voted* is desired. 6. **Closing Time Edge Cases** - The system uses a *block/time anchor* from OTS. Slight unpredictability in block generation might require a small buffer around the official close. This is a policy choice. --- # 7. Conclusion We propose an **election system** that leverages **Nostr** for decentralizing ballot publication, **blinded ephemeral keys** for robust voter anonymity, **homomorphic/mix-net encryption** for ballot secrecy, **threshold cryptography** for collaborative final decryption, **OpenTimestamps** for tamper-proof time anchoring, and **re-voting** to combat coercion. **Key Advantages**: 1. **Anonymity**: The EA cannot link ballots to specific voters. 2. **One Voter, One Credential**: Strict enforcement through blind signatures. 3. **Verifiable Ordering**: OTS ensures each ballot has a unique, provable time anchor. 4. **Updatability**: Voters can correct or override coerced ballots by posting a newer one before closing. 5. **Decentralized Audit**: Anyone can fetch ballots from Nostr, verify the EA’s signatures and OTS proofs, and confirm the threshold-decrypted results match the posted ballots. Such a design shows promise for secure, privacy-preserving **digital elections**, though real-world deployment will require careful **policy, legal, and usability** considerations. By combining cryptography with decentralized relays and an external timestamp anchor, the system can uphold both **individual privacy** and **publicly auditable correctness**.

@ 65912a7a:5dc638bf

I didn’t set out to become an enemy of the world’s richest man, but I seem to have managed it all the same. Until this moment, I’ve resisted describing my falling out with Elon Musk in much detail, but as the man’s cultural influence has metastasized—and he continues to spread lies about me on the social media platform that he owns (Twitter/X)—it seems only appropriate to set the record straight. I know that it annoys many in my audience to see me defend myself against attacks that they recognize to be spurious, but they might, nevertheless, find the details of what happened with Elon interesting. Of all the remarkable people I’ve met, Elon is probably the most likely to remain a world-historical figure—despite his best efforts to become a clown. He is also the most likely to squander his ample opportunities to live a happy life, ruin his reputation and most important relationships, and produce lasting harm across the globe. None of this was obvious to me when we first met, and I have been quite amazed at Elon’s evolution, both as a man and as an avatar of chaos. The friend I remember did not seem to hunger for public attention. But his engagement with Twitter/X transformed him—to a degree seldom seen outside of Marvel movies or Greek mythology. If Elon is still the man I knew, I can only conclude that I never really knew him. When we first met, Elon wasn’t especially rich or famous. In fact, I recall him teetering on the brink of bankruptcy around 2008, while risking the last of his previous fortune to make payroll at Tesla. At the time, he was living off loans from his friends Larry and Sergey. Once Elon became truly famous, and his personal wealth achieved escape velocity, I was among the first friends he called to discuss his growing security concerns. I put him in touch with Gavin de Becker, who provided his first bodyguards, and recommended other changes to his life. We also went shooting on at least two occasions with Scott Reitz, the finest firearms instructor I’ve ever met. It is an ugly irony that Elon’s repeated targeting of me on Twitter/X has increased my own security concerns. He understands this, of course, but does not seem to care. So how did we fall out? Let this be a cautionary tale for any of Elon’s friends who might be tempted to tell the great man something he doesn’t want to hear: (1.) When the SARS-CoV-2 virus first invaded our lives in March of 2020, Elon began tweeting in ways that I feared would harm his reputation. I also worried that his tweets might exacerbate the coming public-health emergency. Italy had already fallen off a cliff, and Elon shared the following opinion with his tens of millions of fans : *the coronavirus panic is dumb* As a concerned friend, I sent him a private text: *Hey, brother— I really think you need to walk back your coronavirus tweet. I know there’s a way to parse it that makes sense (“panic” is always dumb), but I fear that’s not the way most people are reading it. You have an enormous platform, and much of the world looks to you as an authority on all things technical. Coronavirus is a very big deal, and if we don’t get our act together, we’re going to look just like Italy very soon. If you want to turn some engineers loose on the problem, now would be a good time for a breakthrough in the production of ventilators...* (2.) Elon’s response was, I believe, the first discordant note ever struck in our friendship: *Sam, you of all people should not be concerned about this.* He included a link to a page on the CDC website, indicating that Covid was not even among the top 100 causes of death in the United States. This was a patently silly point to make in the first days of a pandemic. We continued exchanging texts for at least two hours. If I hadn’t known that I was communicating with Elon Musk, I would have thought I was debating someone who lacked any understanding of basic scientific and mathematical concepts, like exponential curves. (3.) Elon and I didn’t converge on a common view of epidemiology over the course of those two hours, but we hit upon a fun compromise: A wager. Elon bet me $1 million dollars (to be given to charity) against a bottle of fancy tequila ($1000) that we wouldn’t see as many as 35,000 cases of Covid in the United States (cases, not deaths). The terms of the bet reflected what was, in his estimation, the near certainty (1000 to 1) that he was right. Having already heard credible estimates that there could be 1 million deaths from Covid in the U.S. over the next 12-18 months (these estimates proved fairly accurate), I thought the terms of the bet ridiculous—and quite unfair to Elon. I offered to spot him two orders of magnitude: I was confident that we’d soon have 3.5 million cases of Covid in the U.S. Elon accused me of having lost my mind and insisted that we stick with a ceiling of 35,000. (4.) We communicated sporadically by text over the next couple of weeks, while the number of reported cases grew. Ominously, Elon dismissed the next batch of data reported by the CDC as merely presumptive—while confirmed cases of Covid, on his account, remained elusive. (5.) A few weeks later, when the CDC website finally reported 35,000 deaths from Covid in the U.S. and 600,000 cases, I sent Elon the following text: *Is (35,000 deaths + 600,000 cases) > 35,000 cases?* (6.) This text appears to have ended our friendship. Elon never responded, and it was not long before he began maligning me on Twitter for a variety of imaginary offenses. For my part, I eventually started complaining about the startling erosion of his integrity on my podcast, without providing any detail about what had transpired between us. (7.) At the end of 2022, I abandoned Twitter/X altogether, having recognized the poisonous effect that it had on my life—but also, in large part, because of what I saw it doing to Elon. I’ve been away from the platform for over two years, and yet Elon still attacks me. Occasionally a friend will tell me that I’m trending there, and the reasons for this are never good. As recently as this week, Elon repeated a defamatory charge about my being a “hypocrite” for writing a book in defense of honesty and then encouraging people to lie to keep Donald Trump out of the White House. Not only have I never advocated lying to defeat Trump (despite what that misleading clip from the Triggernometry podcast might suggest to naive viewers), I’ve taken great pains to defend Trump from the most damaging lie ever told about him. Elon knows this, because we communicated about the offending clip when it first appeared on Twitter/X. However, he simply does not care that he is defaming a former friend to hundreds of millions of people—many of whom are mentally unstable. On this occasion, he even tagged the incoming president of the United States. All of this remains socially and professionally awkward, because Elon and I still have many friends in common. Which suggests the terms of another wager that I would happily make, if such a thing were possible—and I would accept 1000 to 1 odds in Elon’s favor: I bet that anyone who knows us both knows that I am telling the truth. Everyone close to Elon must recognize how unethical he has become, and yet they remain silent. Their complicity is understandable, but it is depressing all the same. These otherwise serious and compassionate people know that when Elon attacks private citizens on Twitter/X—falsely accusing them of crimes or corruption, celebrating their misfortunes—he is often causing tangible harm in their lives. It’s probably still true to say that social media “isn’t real life,” until thousands of lunatics learn your home address. A final absurdity in my case, is that several of the controversial issues that Elon has hurled himself at of late—and even attacked me over—are ones we agree about. We seem to be in near total alignment on immigration and the problems at the southern border of the U.S. We also share the same concerns about what he calls “the woke mind virus.” And we fully agree about the manifest evil of the so-called “grooming-gangs scandal” in the U.K. The problem with Elon, is that he makes no effort to get his facts straight when discussing any of these topics, and he regularly promotes lies and conspiracy theories manufactured by known bad actors, at scale. (And if grooming were really one of his concerns, it’s strange that he couldn’t find anything wrong with Matt Gaetz.) Elon and I even agree about the foundational importance of free speech. It’s just that his approach to safeguarding it—amplifying the influence of psychopaths and psychotics, while deplatforming real journalists and his own critics; or savaging the reputations of democratic leaders, while never saying a harsh word about the Chinese Communist Party—is not something I can support. The man claims to have principles, but he appears to have only moods and impulses. Any dispassionate observer of Elon’s behavior on Twitter/X can see that there is something seriously wrong with his moral compass, if not his perception of reality. There is simply no excuse for a person with his talents, resources, and opportunities to create so much pointless noise. The callousness and narcissism conveyed by his antics should be impossible for his real friends to ignore—but they appear to keep silent, perhaps for fear of losing access to his orbit of influence. Of course, none of this is to deny that the tens of thousands of brilliant engineers Elon employs are accomplishing extraordinary things. He really is the greatest entrepreneur of our generation. And because of the businesses he’s built, he will likely become the world’s first trillionaire—perhaps very soon. Since the election of Donald Trump in November, Elon’s wealth has grown by around $200 billion. That’s nearly $3 billion a day (and over $100 million an hour). Such astonishing access to resources gives Elon the chance—and many would argue the responsibility—to solve enormous problems in our world. So why spend time spreading lies on X?

@ 0155373a:ba3e1bed

Imagine an internet where you don’t need a big Internet Service Provider (ISP) to stay connected—an internet powered by the people, for the people. Decentralized internet is no longer a far-fetched idea; it's becoming a reality through community-driven networks. These networks rely on individuals within a community to act as "nodes," connecting their neighbors to the web and bypassing traditional ISPs. #### **What is Decentralized Internet?** Decentralized internet refers to a system where control over connectivity and access is distributed among individuals or local organizations rather than being concentrated in large ISPs. Instead of paying a single company for access, people in a community collaborate to build and maintain the network themselves. #### **How Does It Work?** 1. **Mesh Networks**: Each participant (or node) in the network connects to nearby nodes, creating a web of connectivity. This eliminates the need for a central ISP. 2. **Hardware**: Nodes are powered by simple devices like routers or small computers running specialized software. 3. **Peer-to-Peer Sharing**: Data flows through multiple nodes in the network, ensuring redundancy and reliability. 4. **Backbone Connection**: Some networks may still rely on a single connection to a traditional ISP for broader internet access, but others can connect to decentralized backbone providers or satellites. #### **Benefits of Decentralized Internet** - **Affordable Access**: By cutting out traditional ISPs, communities can lower the cost of internet access. - **Empowerment**: Communities gain control over their own connectivity and data, reducing reliance on corporations. - **Resilience**: Decentralized networks are less prone to outages since they don’t depend on a single point of failure. - **Privacy**: With less reliance on ISPs, there’s less risk of surveillance and data tracking. - **Inclusivity**: Remote or underserved areas can establish connectivity without waiting for ISPs to expand their infrastructure. #### **Real-World Examples** - **Guifi.net**: A community network in Spain that has thousands of nodes providing internet to rural areas. - **NYC Mesh**: A grassroots effort in New York City to create an affordable, community-owned internet. - **Althea**: A project enabling neighbors to share internet bandwidth and earn income for participating in the network. #### **How to Get Started** 1. **Educate Yourself**: Research mesh network technologies like OpenWRT, LibreMesh, or BATMAN. 2. **Form a Group**: Collaborate with neighbors or community organizations to pool resources. 3. **Get the Hardware**: Invest in routers and antennas that support mesh networking. 4. **Set Up Nodes**: Position nodes strategically to ensure strong connections across the community. 5. **Collaborate**: Join forces with regional or global decentralized internet initiatives for support and knowledge sharing. #### **The Future of Decentralized Internet** As internet access becomes increasingly vital, decentralized networks present a way to bridge the digital divide and democratize connectivity. By building these systems, communities can take charge of their digital futures and ensure that no one is left behind. Together, we can create an internet that is truly open, accessible, and resilient. The power lies in our hands—let’s connect, one node at a time.

@ 65912a7a:5dc638bf

## Chef's notes This is my late partner's award winning Cajun rice & beans recipe. It's an updated take on the traditional Cajun comfort food. Chef Darin was a classically trained chef who spent 30+ years in the kitchen perfecting his recipes, and delivering authentic Cajun and Creole food to his patrons. This is a 5-star dish that will earn the respect of the most discerning Cajun afficionado. You won't be disappointed. I suggest making this recipe exactly as directed the first time, and then make whatever adjustments you want for future batches. Also, don't cheap out on the Andouille. No Johnsonville or Hillshire Farms. Chef Aidelle's is a good choice, as is Silva's from Whole Foods. They cost a few extra bucks, but it's absolutely worth it. ## Details - ⏲️ Prep time: 30 min - 🍳 Cook time: 3 hours - 🍽️ Servings: 12 ## Ingredients - 16oz small red beans, dry - 2 cups long grain white rice - 14-16oz andouille sausage, sliced - 8oz ham, cubed - 1 large yellow onion, chopped - 1 green bell pepper, chopped - 2-3 stalks celery, chopped - 2 tbsp garlic (12 cloves), minced - 7 cups water - ¼ cup olive oil - 2 large bay leaves - 1 tbsp parsley, dried - 1 tsp thyme, dried - 1 tsp Cajun seasoning - ½ tsp cayenne pepper, dried - ¼ tsp sage, rubbed - 1½ tsp salt (more or less to taste) ## Directions 1. Soak beans in a large pot of water overnight. 2. Heat oil in a large stockpot over medium heat. Cook onion, bell pepper, celery, garlic in olive oil for 3 to 4 minutes (until onion is translucent). 3. Add beans, bay leaves, parsley, thyme, salt, MSG, Cajun seasoning, cayenne pepper, Sage, and water. Stir, bring to a boil, and then reduce heat to medium-low (btwn 2-3). Cover and simmer for 2½ hours. 4. Remove bay leaves. Mash some of the beans. Stir Andouille and ham into beans, and simmer uncovered for an additional 30 minutes. 5. Meanwhile, prepare the rice. Bring water and rice to a boil in a saucepan. Reduce heat, cover, and simmer for 20 minutes. 6. Serve beans over steamed white rice.

@ 65912a7a:5dc638bf

## Details - ⏲️ Prep time: 5 min - 🍳 Cook time: 30 min - 🍽️ Servings: 12 ## Ingredients - 12-14oz fresh cranberries - 1⅓ cup packed brown sugar - 1 cup raisins - 1 orange, peeled & chopped - 1 cup water ## Directions 1. Using medium sauce pan, simmer cranberries and water for 5-6 min. Cranberries will start to pop. 2. Add brown sugar, raisins, and chopped orange to the berries. 3. Bring to a simmer and continue to cook for 20 min. Stir often to prevent sticking. Remove from heat. 4. Let set until room temp. Mixture will thicken as it cools. 5. Put in a covered container and keep refrigerated. Lasts for about 2 weeks.

@ 3bf0c63f:aefa459d

# The case against edits Direct edits are a centralizing force on Nostr, a slippery slope that should not be accepted. Edits are fine in other, more specialized event kinds, but the `kind:1` space shouldn't be compromised with such a push towards centralization, because [`kind:1` is the public square of Nostr, where all focus should be on decentralization and censorship-resistance](cd8ce2b7). - _Why?_ Edits introduce too much complexity. If edits are widespread, all clients now have to download dozens of extra events at the same time while users are browsing a big feed of notes which are already coming from dozens of different relays using complicated outbox-model-based querying, then for each event they have to open yet another subscription to these relays -- or perform some other complicated batching of subscriptions which then requires more complexity on the event handling side and then when associating these edits with the original events. I can only imagine this will hurt apps performance, but it definitely raises the barrier to entry and thus necessarily decreases Nostr decentralization. Some clients may be implemneted in way such that they download tons of events and then store them in a local databases, from which they then construct the feed that users see. Such clients may make edits potentially easier to deal with -- but this is hardly an answer to the point above, since such clients are already more complex to implement in the first place. - _What do you have against complex clients?_ The point is not to say that all clients should be simple, but that it should be simple to write a client -- or at least as simple as physically possible. You may not be thinking about it, but if you believe in the promise of Nostr then we should expect to see Nostr feeds in many other contexts other than on a big super app in a phone -- we should see Nostr notes being referenced from and injected in unrelated webpages, unrelated apps, hardware devices, comment sections and so on. All these micro-clients will have to implement some complicated edit-fetching logic now? - _But aren't we already fetching likes and zaps and other things, why not fetch edits too?_ Likes, zaps and other similar things are optional. It's perfectly fine to use Nostr without seeing likes and/or zaps -- and, believe me, it does happen quite a lot. The point is basically that likes or zaps don't affect the content of the main post at all, while edits do. - _But edits are optional!_ No, they are not optional. If edits become widespread they necessarily become mandatory. Any client that doesn't implement edits will be displaying false information to its users and their experience will be completely broken. - _That's fine, as people will just move to clients that support edits!_ Exactly, that is what I expect to happen too, and this is why I am saying edits are a centralizing force that we should be fighting against, not embracing. If you understand that edits are a centralizing force, then you must automatically agree that they aren't a desirable feature, given that if you are reading this now, with Nostr being so small, there is a 100% chance you care about decentralization and you're not just some kind of lazy influencer that is only doing this for money. - _All other social networks support editing!_ This is not true at all. Bluesky has 10x more users than Nostr and doesn't support edits. Instagram doesn't support editing pictures after they're posted, and doesn't support editing comments. Tiktok doesn't support editing videos or comments after they're posted. YouTube doesn't support editing videos after they're posted. Most famously, email, the most widely used and widespread "social app" out there, does not support edits of any kind. Twitter didn't support edits for the first 15 years of its life, and, although some people complained, it didn't hurt the platform at all -- arguably it benefitted it. If edits are such a straightforward feature to add that won't hurt performance, that won't introduce complexity, and also that is such an essential feature users could never live without them, then why don't these centralized platforms have edits on everything already? There must be something there. - _Eventually someone will implement edits anyway, so why bother to oppose edits now?_ Once Nostr becomes big enough, maybe it will be already shielded from such centralizing forces by its sheer volume of users and quantity of clients, maybe not, we will see. All I'm saying is that we shouldn't just push for bad things now just because of a potential future in which they might come. - _The market will decide what is better._ The market has decided for Facebook, Instagram, Twitter and TikTok. If we were to follow what the market had decided we wouldn't be here, and you wouldn't be reading this post. - _OK, you have convinced me, edits are not good for the protocol. But what do we do about the users who just want to fix their typos?_ There are many ways. The annotations spec, for example, provides a simple way to append things to a note without being a full-blown edit, and they fall back gracefully to normal replies in clients that don't implement the full annotations spec. Eventually we could have annotations that are expressed in form of simple (human-readable?) diffs that can be applied directly to the post, but fall back, again, to comments. Besides these, a very simple idea that wasn't tried yet on Nostr yet is the idea that has been tried for emails and seems to work very well: delaying a post after the "submit" button is clicked and giving the user the opportunity to cancel and edit it again before it is actually posted. Ultimately, if edits are so necessary, then maybe we could come up with a way to implement edits that is truly optional and falls back cleanly for clients that don't support them directly and don't hurt the protocol very much. Let's think about it and not rush towards defeat.

@ 3bf0c63f:aefa459d

# Anglicismos estúpidos no português contemporâneo Palavras e expressões que ninguém deveria usar porque não têm o sentido que as pessoas acham que têm, são apenas aportuguesamentos de palavras inglesas que por nuances da história têm um sentido ligeiramente diferente em inglês. Cada erro é acompanhado também de uma sugestão de como corrigi-lo. ### Palavras que existem em português com sentido diferente - _submissão_ (de trabalhos): **envio**, **apresentação** - _disrupção_: **perturbação** - _assumir_: **considerar**, **pressupor**, **presumir** - _realizar_: **perceber** - _endereçar_: **tratar de** - _suporte_ (ao cliente): **atendimento** - _suportar_ (uma idéia, um projeto): **apoiar**, **financiar** - _suportar_ (uma função, recurso, característica): **oferecer**, **ser compatível com** - _literacia_: **instrução**, **alfabetização** - _convoluto_: **complicado**. - _acurácia_: **precisão**. - _resiliência_: **resistência**. ### Aportuguesamentos desnecessários - _estartar_: **iniciar**, **começar** - _treidar_: **negociar**, **especular** ### Expressões - _"não é sobre..."_: **"não se trata de..."** ---  ## Ver também - [Algumas expressões e ditados excelentes da língua portuguesa, e outras não tão excelentes assim](https://fiatjaf.alhur.es/expressões-e-ditados.txt)

@ 1739d937:3e3136ef

This update marks a major milestone for the project. I know, with certainty, that MLS messaging over Nostr is going to work. That might sound a little crazy after so many months working on the project, and I was pretty confident, but until you’ve got running code, it’s all conjecture. Late last week, I released a video of a working prototype of [White Noise](https://github.com/erskingardner/whitenoise) that shows the full flow; creating groups, inviting other users to join those groups, accepting invites, and sending messages back-and-forth. I’m thrilled that I’ve gotten this far but also appalled that it’s taken so long and disgusted at the state of the code in the app (I’ve been told I have unrelenting standards 😅). If you missed the video last week... nostr:note125cuk0zetc7sshw52v5zaq9apq3rq7e2x587tr2c96t7z7sjs59svwv0fj ## What's Next? In this update, I want to cover a few things about how I'm planning to proceed and how I’m splitting code out of the app into libraries that will help other developers implement MLS messaging in their own Nostr clients. First off, many of you know that I've been building White Noise as a Rust app using the [Tauri](https://tauri.app) framework. The [OpenMLS](https://github.com/openmls/openmls) implementation is also written in Rust (with bindings for many other languages). So, when you hear me talking about library code, think Rust crates for now. The first library, called [openmls-nostr](https://github.com/erskingardner/openmls-nostr), is an extension/abstraction on top of the openmls implementation of the MLS spec that helps Nostr clients interact more easily with that implementation in a way that feels native to Nostr. Mostly this will be helping developers interact with MLS primitives and ensure that they’re creating, validating, and serializing these objects in the right way at the right times. The second isn’t a new library as a big contribution to the already excellent [rust-nostr](https://github.com/rust-nostr) library from nostr:npub1drvpzev3syqt0kjrls50050uzf25gehpz9vgdw08hvex7e0vgfeq0eseet. The methods that will go in rust-nostr are highly abstracted and based specifically on the requirements of NIP-104. Mostly this will be helping developers to take those MLS primitives and publish or query them as Nostr events at the right times and to/from the right relays. Most of this code was originally written directly in the White Noise library so this week I've started to pull code for both of those libraries out and move it to its new home. While I’ve been at it, I've been writing some tests and trying to document things. An unfortunate offshoot of this is that the usable builds of White Noise are going to take a touch longer. I promise it’s still a very high priority but at this point I need to clean a few things up based on what I've learned thus far. Another thing that is slowing down release is that; behind the scenes of the dev work, I’ve been battling with Apple for nearly 2 months now to get a proper developer team set up so that we can publish the app via TestFlight for MacOS and iOS. I’ve also been recently learning the intricacies of Android publishing (oh my dear god there are so many devices, OS versions, etc.). With that in mind, if you know anyone who can help get me up to speed on CI/CD, release pipelines, and multi-platform distribution please hit me up. I would love to learn more and hopefully shortcut some of the pain. Thanks again so much for all the support over the last few months! It means a lot to me and is a huge part of what is keeping me going on this. 🙏

@ 1739d937:3e3136ef

## Previous updates - Check them all out here: <https://highlighter.com/jeffg.fyi> ## Progress this week It was a busy one. I've been focused on the critical path of getting the full end-to-end MLS messaging flow built into White Noise. Unfortunately, or fortunately for those that will come after, this has necessitated writing quite a bit of library code and figuring out how clients should think about storing the necessary group state and secrets. Today I released the highly creatively named [openmls-sled-storage](https://github.com/erskingardner/openmls-sled-storage). This is a storage adapter for Sled DB, an embedded database written in Rust. This allows clients to simply give their clients a file path where they want to store the data and the library will take care of the rest with regards to MLS storage. Another bit of library code is a customer MLS extension called NostrGroupData (again with a wildly creative title - check it out in the WN repo [here](https://github.com/erskingardner/whitenoise/blob/master/src-tauri/src/nostr_mls/nostr_group_data.rs)). This is a standardized way of storing the necessary metadata about a group that will allow it to function properly with Nostr conventions as well as basic data like Group name, description, etc. This, in specific, is the source of quite a few updates to the NIP, but overall it's going to give clients implementing MLS groups assurances that the data required is not only formatted the same, but cryptographically guaranteed to be there and respected by each group member, or the group will fork. ## White Noise The client currently supports multiple accounts, including generating new Nostr identities on the fly. It's also loading user's contact lists, and NIP-04 DMs at the moment as well. This week I managed to build out nearly the entire group creation flow. This includes publishing and fetching key packages (kind: 443 events), inviting another user to create a group, sending welcome messages (kind: 444 events), and I've started working on both parsing those welcome messages and how to represent the groups in the UI in a way that makes reasonable sense to users. ## No showstoppers I know this might sound insane after working on this project for several months already but I'm genuinely surprised that I've not run into any big unknown unknowns yet. Everything is coming together well and, while it's taking me some time to build it right and think carefully about where and how data is being stored and passed around, I'm very confident the client is going to be up and running in a few weeks (famous last words). ## The NIP As I mentioned before, I've left the NIP dormant while I'm working on implementing the entire messaging flow. Once I've got the flow fully built out, I'll know all the details that need to change and I'll update the NIP. If anyone out there wants to chat about the changes I already know are coming, let me know. ## Feedback & contributions always welcome Thoughts? Questions? Want to contribute? Hit me up. ## P.S. The plant in the cover image is Asparagus Officinalis. My grandfather was the only person I knew growing up that grew it and, as a result, I also grow it at home. The interesting thing about Asparagus (other than making your pee smell funny) is that it takes several years before it starts bearing edible veggies. It's a low time preference plant and further proof that good things take time.

@ 0f1b5961:868242bd

The public theologian Jonathan Pageau has been a major influence in my life for the past couple years. I remember in one of his podcasts he talks about how church buildings have historically been the "focal points" of many towns. In the physical sense, this meant the church building was at the center of the town and was the tallest structure. He argues that the church occupying this station had a sort of psychological effect on the town members, enforcing a way of life that has God in the highest "place". This got me thinking about my own home city of Des Moines, Iowa. Here, the two most prominent buildings, by far, are the capitol building and a skyscraper called the Principal building. They sit on either side of the Des Moines River and to me, seem to "face off" against each other as if in competition. *The Iowa State Capitol* *The Principal Building (801 Grand Avenue)* I was musing over how to settle the competition between these two buildings and I realized that it could be addressed with some pretty basic math. The apparent heights of these buildings change as you move closer or further from them. So whichever building appears taller for a larger portion of the city would be the most prominent building. In an idealized scenario, there would be a straight line between the two buildings where they would appear to be the same height. This line ends up coinciding with East 4th street on the east side of the Des Moines River. As the Principal building is about twice as tall as the capitol buiding, the point at which they look the same height is about twice as close to the capitol building. *Line along which the capitol and Principle building appear to be the same height.* And so a clear winner emerges. Not only is the Principal building the most prominent in the downtown district of the city. It's influence extends across the river and eclipses the capitol in what one might expect to be its home turf. The focal point of Des Moines is a skyscraper. I now must conclude with a confession. With the Principal building being about twice as tall as the capitol, there was never going to be a close competition between the two buildings. And indeed this matches the experience of one moving about the city. The Principal building plainly *feels* more prominent. Despite this, the area in which the capitol ascends to the highest is certainly not small. I like to think this reflects some amount of balance between the mercantile powers and political powers in the area. Perhaps this balance is proportional to the very heights of the buildings. Not looking good for the ecclesiastical powers in the area... \-Scott

@ 3bf0c63f:aefa459d

# Nostr: a quick introduction, attempt #2 Nostr doesn't subscribe to any ideals of "free speech" as these belong to the realm of politics and assume a big powerful government that enforces a common ruleupon everybody else. Nostr instead is much simpler, it simply says that servers are private property and establishes a generalized framework for people to connect to all these servers, creating a true free market in the process. In other words, Nostr is the public road that each market participant can use to build their own store or visit others and use their services. (Of course a road is never truly public, in normal cases it's ran by the government, in this case it relies upon the previous existence of the internet with all its quirks and chaos plus a hand of government control, but none of that matters for this explanation). More concretely speaking, Nostr is just a set of definitions of the formats of the data that can be passed between participants and their expected order, i.e. messages between _clients_ (i.e. the program that runs on a user computer) and _relays_ (i.e. the program that runs on a publicly accessible computer, a "server", generally with a domain-name associated) over a type of TCP connection (WebSocket) with cryptographic signatures. This is what is called a "protocol" in this context, and upon that simple base multiple kinds of sub-protocols can be added, like a protocol for "public-square style microblogging", "semi-closed group chat" or, I don't know, "recipe sharing and feedback".

@ c230edd3:8ad4a712

## Chef's notes Allow meat to soak for 1-24 hours. The rougher the cut, the longer the soak. This is great for open flame grilling, as well as pan seared, though the latter is preferable. Petit Sirloin can marinade for approximately 1 hour and still develop tenderness. I like to score the steaks if they will only be resting in the mix for a short time. All seasonings can be adjusted to taste. Base ingredients scale well, for any number of steaks. Equal parts, enough to coat the meat is really all that matters. I'm terrible at remembering cooking pictures, so image is a random steak. I will try to remember to update that next time I make these. ## Details - ⏲️ Prep time: 10 - 🍳 Cook time: However long you usually cook your steak to preferred doneness ## Ingredients - 4 petite sirloin steaks or other cut - 1/4 cup yellow mustard - 1/4 cup soy sauce - 3-5 cloves garlic, depending on size, minced and salted - 1 tsp dried basil - 1\2 tsp crushed red pepper ## Directions 1. Mix ingredients and marinade 1-24 hours. 2. Grill or pan sear to your preferred doneness 3. Enjoy!

@ 3bf0c63f:aefa459d

# Estórias * [O caso da Grêmio TV](nostr:naddr1qqyxzce3vguxvvfkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823caz985v) * [Jofer](nostr:naddr1qqyxxdt9x4snwwpkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cgsxml2) * [Lagoa Santa: como chegar -- partindo da rodoviária de Belo Horizonte](nostr:naddr1qqyrsdrpxverwdmrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c724d7h) * [O Planetinha](nostr:naddr1qqyxzvnzv9jrgef5qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cgmfd3v)

@ 2f7463a4:e92b8023

| GitHub Repository | Lightning Address | | --- | --- | | https://github.com/sfr0xyz/openagents-bitcoin-stats | sefiro@getalby.com | This is a plugin for [OpenAgents](https://openagents.com) that gives you the latest statistics about the Bitcoin network, its mempool and the Lightning Network. It is inspired by Clark Moody's [Bitcoin Dashboard](https://bitcoin.clarkmoody.com/dashboard) and the [TimeChainCalendar](https://timechaincalendar.com). The project uses the [Extism Framework](https://extism.org/docs/overview/), in particular its [Go PDK](https://github.com/extism/go-pdk), and the REST APIs of [mempool.space](https://mempool.space/docs/api/rest), [bitnodes.io](https://bitnodes.io/api) and [coincap.io](https://docs.coincap.io/). ## Usage Ensure that you have installed the [Extism CLI](https://github.com/extism/cli?tab=readme-ov-file#extism-cli) and downloaded the `btcstats.wasm` file. You can call the plugin with the Extism CLI: ```sh extism call btcstats.wasm run --input '<YOUR INPUT>' --wasi --allow-host '*' ``` Replace `<YOUR INPUT>` with a list of statistics you are interested in. Available statistics (see detailed descriptions on [GitHub](https://github.com/sfr0xyz/openagents-bitcoin-stats?tab=readme-ov-file#description-of-the-values)): - `market`: Bitcoin market data such as current price and market cap - `latestBlock`: Information about the latest block, such as size and total reward - `mining`: Mining data such as current hashrate and difficulty, and difficulty adjustment - `fees`: Recommended feerates based on the current mempool - `mempool`: Mempool statistics such as number of unconfirmed transactions and pending fees - `lightning`: Lightning Network statistics such as total capacity and number of channels - `nodes`: Bitcoin node statistics such as total number of nodes You can include more than one of the above at once. If you leave the field empty (`''`), or include none of the above, all stats will be requested. With the prefix `-`, e.g. `-nodes`, you can exclude stats, i.e. "I want all stats except `nodes`". > Note: If you request the `nodes` statistic, it will take a while, a few seconds, for the result to be displayed. ### Examples[^1] > Note: The resulting JSON is prettified here for better readability. Get `latestBlock` and `mempool` stats: ```plain $ extism call btcstats.wasm run --input 'latestBlock mempool' --wasi --allow-host '*' { "latestBlock": { "height": 845325, "timestamp": "Mon, 27 May 2024 01:34:54 UTC", "transactions": 5692, "size": 1.55, "totalReward": 3.272, "totalFees": 0.147, "medianFeeRate": 8.1, "miner": "MARA Pool" }, "mempool": { "unconfirmedTXs": 170669, "vSize": 180.66, "pendingFees": 5.257, "blocksToClear": 181 }, "mining": { "hashrate": 677612693053317300000, "difficulty": 84381461788831.34, "retargetDifficultyChangePercent": 13.39, "retargetRemainingBlocks": 1395, "retargetEstimatedDate": "Tue, 04 Jun 2024 15:07:02 UTC" } } ``` Get **all** stats except `nodes`: ```plain $ extism call btcstats.wasm run --input '-nodes' --wasi --allow-host '*' { "fees": { "fastest": 9, "halfHour": 9, "hour": 9, "economy": 6, "minimum": 3 }, "latestBlock": { "height": 845325, "timestamp": "Mon, 27 May 2024 01:34:54 UTC", "transactions": 5692, "size": 1.55, "totalReward": 3.272, "totalFees": 0.147, "medianFeeRate": 8.1, "miner": "MARA Pool" }, "lightning": { "totalNodes": 12836, "torNodes": 8930, "clearnetNodes": 1700, "clearnetTorNodes": 1360, "unannouncedNodes": 846, "channels": 50872, "totalCapacity": 4980.822, "averageChannelCapacity": 0.098, "medianChannelCapacity": 0.02 }, "market": { "supply": 19699693, "supplyPercent": 93.81, "price": 69020.61, "priceChange24hPercent": -0.32, "moscowTime": 1448, "marketCap": 1359684729700.71 }, "mempool": { "unconfirmedTXs": 170669, "vSize": 180.66, "pendingFees": 5.257, "blocksToClear": 181 }, "mining": { "hashrate": 677612693053317300000, "difficulty": 84381461788831.34, "retargetDifficultyChangePercent": 13.39, "retargetRemainingBlocks": 1395, "retargetEstimatedDate": "Tue, 04 Jun 2024 15:07:02 UTC" } } ``` [^1]: more examples in the [README](https://github.com/sfr0xyz/openagents-bitcoin-stats?tab=readme-ov-file#examples) on GitHub

@ 3bf0c63f:aefa459d

# About Nostr, email and subscriptions I check my emails like once or twice a week, always when I am looking for something specific in there. Then I go there and I see a bunch of other stuff I had no idea I was missing. Even many things I wish I had seen before actually. And sometimes people just expect and assume I would have checked emails instantly as they arrived. It's so weird because I'm not making a point, I just don't remember to open the damn "gmail.com" URL. --- I remember some people were making some a Nostr service a while ago that sent a DM to people with Nostr articles inside -- or some other forms of "subscription services on Nostr". It makes no sense at all. Pulling in DMs from relays is exactly the same process (actually slightly more convoluted) than pulling normal public events, so why would a service assume that "sending a DM" was more likely to reach the target subscriber when the target had explicitly subscribed to that topic or writer? Maybe due to how some specific clients work that is true, but fundamentally it is a very broken assumption that comes from some fantastic past era in which emails were 100% always seen and there was no way for anyone to subscribe to someone else's posts. Building around such broken assumptions is the wrong approach. Instead we should be building new flows for subscribing to specific content from specific Nostr-native sources (creators directly or manual or automated curation providers, communities, relays etc), which is essentially what most clients are already doing anyway, but specifically Coracle's new custom feeds come to mind now. --- This also [reminds me](nostr:nevent1qqsda83vup73lhv6m4mee2wka83dzuwf78e95wtpn70r6ce99e8ah4gpr9mhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5pzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vammnc95) of the interviewer asking the Farcaster creator if Farcaster made "email addresses available to content creators" completely ignoring all the cryptography and nature of the protocol (Farcaster is shit, but at least they tried, and in this example you could imagine the interviewer asking the same thing about Nostr). I imagine that if the interviewer had asked these people who were working (or suggesting) the Nostr DM subscription flow they would have answered: "no, you don't get their email addresses, but you can send them uncensorable DMs!" -- and that, again, is getting everything backwards.

@ 3bf0c63f:aefa459d

# Bitcoin transactions explained A transaction is a piece of data that takes **inputs** and produces **outputs**. Forget about the blockchain thing, Bitcoin is actually just a big tree of transactions. The blockchain is just a way to keep transactions ordered. Imagine you have 10 satoshis. That means you have them in an unspent transaction output (**UTXO**). You want to spend them, so you create a transaction. The transaction should reference unspent outputs as its inputs. Every transaction has an immutable id, so you use that id plus the index of the output (because transactions can have multiple outputs). Then you specify a **script** that unlocks that transaction and related signatures, then you specify outputs along with a **script** that locks these outputs.  As you can see, there's this lock/unlocking thing and there are inputs and outputs. Inputs must be unlocked by fulfilling the conditions specified by the person who created the transaction they're in. And outputs must be locked so anyone wanting to spend those outputs will need to unlock them. For most of the cases locking and unlocking means specifying a **public key** whose controller (the person who has the corresponding **private key**) will be able to spend. Other fancy things are possible too, but we can ignore them for now. Back to the 10 satoshis you want to spend. Since you've successfully referenced 10 satoshis and unlocked them, now you can specify the outputs (this is all done in a single step). You can specify one output of 10 satoshis, two of 5, one of 3 and one of 7, three of 3 and so on. The sum of outputs can't be more than 10. And if the sum of outputs is less than 10 the difference goes to fees. In the first days of Bitcoin you didn't need any fees, but now you do, otherwise your transaction won't be included in any block.  If you're still interested in transactions maybe you could take a look at [this small chapter](https://github.com/bitcoinbook/bitcoinbook/blob/6d1c26e1640ae32b28389d5ae4caf1214c2be7db/ch06_transactions.adoc) of that Andreas Antonopoulos book. If you hate Andreas Antonopoulos because he is a communist shitcoiner or don't want to read more than half a page, go here: <https://en.bitcoin.it/wiki/Coin_analogy>

@ 2f7463a4:e92b8023

_Original „[Speaking Freely](https://dergigi.com/2024/03/25/speaking-freely-online/)“ von [Gigi](https://dergigi.com/nostr), veröffentlicht zur Blockzeit [836245](https://www.blockstream.info/block-height/836245) unter der [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) Lizenz. Übersetzt von [sefiro](https://njump.me/sfr0.xyz)._ --- Neulich unterhielt ich mich mit einem Freund und wir kamen auf das Problem der Meinungsfreiheit zu sprechen. Ich sollte es nicht als Problem bezeichnen, denn es ist die Lösung eines Problems. Das Problem ist ein immerwährendes Problem, was eine andere Art ist zu sagen, dass es ein _wirklich_ schwieriges Problem ist, ein Problem, mit dem wir immer konfrontiert sein werden, solange wir Menschen sind. Das Problem ist folgendes: Was ist das Problem, das es zu lösen gilt? Es ist ein Problem von Problemen, was natürlich ein Metaproblem ist. Wir als Homo Sapiens sind ein denkender Organismus. Sowohl kollektiv als auch individuell. Denken ist das, was uns ausmacht, aber es ist nicht einfach Denken als Selbstzweck, es ist Denken, um Dinge herauszufinden, ohne ständig dabei umgebracht zu werden. Eine weniger brutale Form der Evolution sozusagen. Die Menschen der Antike haben der Aufmerksamkeit einen sehr hohen Wert beigemessen. Auch die Aufmerksamkeit ist von einem Metaproblem geplagt: Worauf soll man seine Aufmerksamkeit richten? Um diese Frage zu beantworten, muss man darauf achten, worauf man seine Aufmerksamkeit richtet, und das unterscheidet einen klugen von einem weisen Menschen. Das bringt mich zu einem der Dinge die mir derzeit Sorgen bereiten. Wir sind zivilisatorisch gesehen sehr klug, aber nicht sehr weise. Wir sind schlecht darin, auf das zu achten, worauf wir unsere Aufmerksamkeit richten, zumindest gegenwärtig. Und ich fürchte, dass sowohl die [falschen Anreize](https://dergigi.com/vew), die das Internet plagen, als auch unser [kaputtes Geld](https://bitcoin-resources.com/books/broken-money) daran schuld sind. ## Annahmen [n=0] - ∀ i ≤ c[^1] - P! = NP[^2] - Leben ist es wert gelebt zu werden[^3] - Es gibt kein kostenloses Mittagessen[^4] - Meinungsfreiheit ist erstrebenswert[^5] ## Der Logos [n=1] Es gibt einen Grund, warum Der Logos heilig ist. Aus dem gleichen Grund ist der Erste Zusatzartikel zur Verfassung der Vereinigten Staaten der erste, d.h. der wichtigste. Meinungsfreiheit ist nicht optional; sie ist nicht optional, weil wir frei sprechen können müssen, um frei denken zu können. Es gibt kein echtes Denken ohne echtes Sprechen, genauso wie es kein echtes Sprechen ohne echtes Denken gibt. Es muss erlaubt sein, dummes Zeug zu sagen, so wie es erlaubt sein muss, dummes Zeug zu denken. > „Der Vernünftige passt sich der Welt an, der Unvernünftige versucht beharrlich, die Welt an sich anzupassen. Daher hängt aller Fortschritt vom Unvernünftigen ab.“\ > — George Bernhard Shaw, [Man and Superman](https://www.goodreads.com/work/quotes/376394-man-and-superman) Der Grat zwischen Genie und Wahnsinn ist nicht ohne Grund schmal. Was idiotisch und was genial ist, ist oft schwer zu unterscheiden. Deshalb hängt aller Fortschritt vom Unvernünftigen ab. Wie können wir den Unvernünftigen finden und ihm zuhören, wenn wir ihn zum Schweigen bringen? Schlimmer noch, wie können wir dem unvernünftigen/genialen Teil in uns selbst hören, wenn wir Angst haben, ihn in der Öffentlichkeit oder im Privaten zu äußern? ## DiaLogos [n=2] Auch freier und unbelasteter Dialog sind nicht optional. Wir müssen in der Lage sein, Dinge zu diskutieren, damit andere uns sagen können, wo wir idiotisch sind. Und wir sind alle idiotisch. Wir sind vielleicht auf unsere Weise idiotisch, aber wir sind alle idiotisch. Es gibt keine wertfreie Meinung, so wie es keine Sichtweise ohne blinden Fleck gibt. Das Beste, was wir tun können, ist, uns unserer Vorurteile und blinden Flecken bewusst zu werden und zu versuchen, ihnen entgegenzuwirken. Aber das können wir nicht individuell, das müssen wir kollektiv tun, und noch wichtiger: auf eine verteilte Art und Weise.[^6] Der Bau eines Turms von Babel ist eine schlechte Idee. ## Verteilte Erkenntnis [n=m] Auch öffentlicher Diskurs ist nicht optional. In der heutigen Zeit, insbesondere im Internet, ist öffentlicher Diskurs, gelinde gesagt, problematisch. Eines der Probleme ist, dass wir keine öffentlichen Räume haben, so dass wir gezwungen sind, private Räume als quasi-öffentliche Räume zu nutzen. Die übliche Methode, sich öffentlich zu äußern, besteht darin, auf eine Plattform zu gehen und zu sagen, was man zu sagen hat. Das Problem ist natürlich, dass es nicht deine Plattform ist. Es ist die Plattform eines anderen. Deshalb kannst du von der Plattform ausgeschlossen werden. Der Unterschied zwischen all diesen Plattformen liegt im _Grad_, nicht in der Art. Auf einigen Plattformen kann man für sexuelle Inhalte sprichwörtlich ins Gefängnis kommen. Auf anderen Plattformen kann man für politische Äußerungen ins Gefängnis kommen. Nicht einmal sprichwörtlich.[^7] > „Geben Sie mir sechs Zeilen, die von der Hand des ehrlichsten Menschen geschrieben wurden, ich würde etwas darin finden, um ihn hängen zu lassen.“\ > — Kardinal Richelieu Wenn jemand die Macht hat, jemand anderen von einer Plattform auszuschließen, dann wird diese Macht früher oder später auch genutzt und missbraucht. Ein ausreichend großer Skandal oder eine entsprechende Kontroverse wird gefunden oder inszeniert und _\*puff\*_ ist der „problematische“ Nutzer verschwunden. Depersonalisiert, auf Knopfdruck. Egal, wie mächtig man ist.[^8] Aus diesem Grund können [Plattformen](https://x.com/dergigi/status/1508217667768963075) für Meinungsfreiheit nicht existieren. Es kann nur [Protokolle](nostr:nevent1qqsz9fgdac7yvs7z07sx92zf2rkldgnfav2rkce03gdm95efzyfgg4szyphydppzm7m554ecwq4gsgaek2qk32atse2l4t9ks57dpms4mmhfxt5xvet) für Meinungsfreiheit geben. Der Unterschied ist ebenso subtil wie wichtig: Wenn du ein Protokoll verwendest, bist du kein Nutzer im herkömmlichen Sinne. Du bist ein Sprecher. Du sprichst die gleiche Sprache wie andere, und wenn jemand anderes dich hören und verstehen kann, dann gibt es eine Verbindung. Es gibt keinen Vermittler. Die Sprache selbst ist der Vermittler. Sprachen sind Protokolle, und Protokolle sind Sprachen. Sie haben keine Nutzer, sie haben Sprecher. Sprache ist naturgemäß frei. Du brauchst keinen Deutsch-Account, um diese Sätze zu lesen. Genauso wie dein Computer keinen HTTP-Account braucht, um die Nullen und Einsen zu verstehen, aus denen die Bytes bestehen, die wiederum die Zeichen dieses Satzes bilden. Beide sprechen die Sprache, daher könnt ihr euch verstehen. Sprachen und Protokolle sind Netzwerkphänomene. Ohne Netzwerk keine Sprache. Ohne Peers keine Protokolle. Deshalb ist Sprache, wie Geld, in einer komplexen Gesellschaft nicht optional. Wenn man in das eine oder das andere hineinpfuscht, [zerbricht die Gesellschaft](https://bitcoin-resources.com/books/when-money-dies). ## Es liegt an uns, es ist soweit [n=i] Wir stehen an einem Wendepunkt in der Geschichte. Noch nie war unsere Zivilisation so vernetzt, so global, und sich ihrer Grenzen und Ignoranz so wenig bewusst. Meine Hoffnung ist, dass [hartes Geld](https://bitcoin-resources.com/) und [Meinungsfreiheit](https://nostr-resources.com/) das wiederbeleben, was unsere Gesellschaft groß gemacht hat. Kooperation und verteilte Erkenntnis haben es uns ermöglicht, das Chaos des Dschungels hinter uns zu lassen. Sie haben es uns ermöglicht, von Auge um Auge zu einer klaren Sicht zu gelangen, zumindest teilweise. Sie haben es uns ermöglicht, von der Knappheit zum Überfluss zu gelangen. Sie haben uns ermöglicht, zur _Wahrheit_, zum _Guten_ und zum _Schönen_ zu gelangen. Sie ermöglichen es uns zu streben. Nach vorne und nach oben. Der Kairos unserer Zeit ist ein persönlicher – vielleicht sind das alle kairotischen Momente. Du musst entscheiden wie du weitermachen willst. Du musst entscheiden, welches Spiel du spielen willst; wie viel [Verantwortung](https://dergigi.com/responsibility) du bereit bist zu übernehmen. Willst du weiterhin in der Maschine stecken bleiben? Einer Maschine, die dich benutzt und ausnutzt? Eine Maschine, die sich selbst nährt, indem sie deine Zeit, deine Aufmerksamkeit und deinen [Wert](https://dergigi.com/value) raubt und verschlingt? Oder hast du den Mut, die Kontrolle über deinen Wohlstand, deine Gesundheit, deine Gedanken und deine [Sprache](https://dergigi.com/speech) zu übernehmen? Diese Entscheidung kann dir niemand abnehmen. Sie beginnt und endet mit [dir](https://nostr.org/). 💜 [^1]: Keine Information kann sich schneller als [Lichtgeschwindigkeit](https://de.wikipedia.org/wiki/Lichtgeschwindigkeit#Lichtgeschwindigkeit_als_universelle_Grenzgeschwindigkeit) verbreiten. Folglich stoßen alle Informationssysteme an [physikalische Grenzen](https://dergigi.com/threads/physical-limits), wenn es um Synchronisation und Informationsweitergabe geht. [^2]: Kryptographie funktioniert und wird [weiterhin](https://de.wikipedia.org/wiki/P-NP-Problem#P_und_NP) funktionieren. „[...] irgendwie [lächelt das Universum bei Verschlüsselung](https://bitcoin-resources.com/books/cypherpunks).“ [^3]: Existenz ist [real und gut](https://www.goodreads.com/book/show/40311194). Weder Nihilismus noch Solipsismus sind wünschenswert. „[...] und es war [gut](https://en.wikipedia.org/wiki/Life_Is_Worth_Living).“ [^4]: Wir können nicht [etwas für nichts](https://de.wikipedia.org/wiki/Erster_Hauptsatz_der_Thermodynamik) haben. Freiheit erfordert [Verantwortung](https://archive.is/U6iJ4); elektronisches Bargeld erfordert [Zeit](https://dergigi.com/time); Zeit erfordert [Wärme](https://dergigi.com/threads/time-requires-heat). [^5]: [Meinungsfreiheit](https://de.wikipedia.org/wiki/Meinungsfreiheit) ist erstrebenswert, weil Freiheit der Tyrannei vorzuziehen ist, und der erste Schritt eines jeden Tyrannen ist es, die Meinungsfreiheit einzuschränken, Dissidenten zum Schweigen zu bringen, und Bücher zu verbrennen. Der zweite Schritt ist Völkermord. [^6]: Es ist großartig, dass es immer mehr lange Dialoge in Form von Podcasts gibt. Der Nutzen dieser Gespräche geht jedoch verloren, wenn sie von einer zentralen Partei gehostet werden, weshalb ein [offenes Podcast-Ökosystem](https://newpodcastapps.com) so wichtig ist. [^7]: Siehe Fälle im [Vereinigten Königreich](https://archive.is/OQ1LC), in [Saudi Arabien](https://archive.is/co19A), etc. [^8]: Noch nicht einmal [amtierende US-Präsidenten](https://archive.is/0LvLe) sind vor einem Ausschluss von Plattformen sicher.

@ 3bf0c63f:aefa459d

# Nostr is not decentralized nor censorship-resistant Peter Todd has been [saying this](nostr:nevent1qqsq5zzu9ezhgq6es36jgg94wxsa2xh55p4tfa56yklsvjemsw7vj3cpp4mhxue69uhkummn9ekx7mqpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5qy8hwumn8ghj7mn0wd68ytnddaksz9rhwden5te0dehhxarj9ehhsarj9ejx2aspzfmhxue69uhk7enxvd5xz6tw9ec82cspz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3vamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmnyqy28wumn8ghj7un9d3shjtnwdaehgu3wvfnsz9nhwden5te0wfjkccte9ec8y6tdv9kzumn9wspzpn92tr3hexwgt0z7w4qz3fcch4ryshja8jeng453aj4c83646jxvxkyvs4) for a long time and all the time I've been thinking he is misunderstanding everything, but I guess a more charitable interpretation is that he is right. Nostr _today_ is indeed centralized. Yesterday I published two harmless notes with the exact same content at the same time. In two minutes the notes had a noticeable difference in responses:  The top one was published to `wss://nostr.wine`, `wss://nos.lol`, `wss://pyramid.fiatjaf.com`. The second was published to the relay where I generally publish all my notes to, `wss://pyramid.fiatjaf.com`, and that is announced on my [NIP-05 file](https://fiatjaf.com/.well-known/nostr.json) and on my [NIP-65](https://nips.nostr.com/65) relay list. A few minutes later I published that screenshot again in two identical notes to the same sets of relays, asking if people understood the implications. The difference in quantity of responses can still be seen today:  These results are skewed now by the fact that the two notes got rebroadcasted to multiple relays after some time, but the fundamental point remains. What happened was that a huge lot more of people saw the first note compared to the second, and if Nostr was really censorship-resistant that shouldn't have happened at all. Some people implied in the comments, with an air of obviousness, that publishing the note to "more relays" should have predictably resulted in more replies, which, again, shouldn't be the case if Nostr is really censorship-resistant. What happens is that most people who engaged with the note are _following me_, in the sense that they have instructed their clients to fetch my notes on their behalf and present them in the UI, and clients are failing to do that despite me making it clear in multiple ways that my notes are to be found on `wss://pyramid.fiatjaf.com`. If we were talking not about me, but about some public figure that was being censored by the State and got banned (or shadowbanned) by the 3 biggest public relays, the sad reality would be that the person would immediately get his reach reduced to ~10% of what they had before. This is not at all unlike what happened to dozens of personalities that were banned from the corporate social media platforms and then moved to other platforms -- how many of their original followers switched to these other platforms? Probably some small percentage close to 10%. In that sense Nostr today is similar to what we had before. Peter Todd is right that if the way Nostr works is that you just subscribe to a small set of relays and expect to get everything from them then it tends to get very centralized very fast, and this is the reality today. Peter Todd is wrong that Nostr is _inherently_ centralized or that it needs a _protocol change_ to become what it has always purported to be. He is in fact wrong today, because what is written above is not valid for all clients of today, and if we [drive in the right direction](nostr:naddr1qqykycekxd3nxdpcvgq3zamnwvaz7tmxd9shg6npvchxxmmdqgsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8grqsqqqa2803ksy8) we can successfully make Peter Todd be more and more wrong as time passes, instead of the contrary. --- See also: - [Censorship-resistant relay discovery in Nostr](nostr:naddr1qqykycekxd3nxdpcvgq3zamnwvaz7tmxd9shg6npvchxxmmdqgsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8grqsqqqa2803ksy8) - [A vision for content discovery and relay usage for basic social-networking in Nostr](nostr:naddr1qqyrxe33xqmxgve3qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cywwjvq)

@ 0f1b5961:868242bd

Trying out the highligher.com editor... heaven : earth governance : generation emanation : emergence selection : variation

@ 3d842afe:2d44a42d

Websocket connection overhead is an obvious problem with the gossip model that few are willing to acknowledge. The more decentralized relay selection becomes (the goal) the worse it scales. Even at the current scale of nostr if users chose more diverse relay sets the issue would be crippling. Below are some very simple simulations to illustrate my point. I used 2 relays per person to be conservative and chose 3 different realistic follow counts. The NIP-65 spec suggests clients should guide users to keep the lists small (2-4 relays) though currently the average kind 10002 contains many more. I ran each simulation 10 times and then took the average result. EDIT: I understand that selecting relays at random is NOT how things currently work or will ever work. My point is that if our goal is to make relay sets more diverse then we should work towards a solution that scales with accomplishing that goal. Available relays: 600 (~what nostr.watch currently shows for online relays) Follows: 200 Relays per person: 2 (randomly selected) Unique Connections Required: 291 Available Relays: 600 Follows: 500 Relays per person: 2 Unique Connections Required: 486 Available Relays: 600 Follows: 1000 Relays per person: 2 Unique Connections Required: 577 Even today if users randomly selected relays the total number of connections required would be staggering and this is with users only selecting 2 relays each. What happens if the available number of relays increases by 5x? Available Relays: 3000 Follows: 200 Relays per person: 2 Unique Connections Required: 376 Available Relays: 3000 Follows: 500 Relays per person: 2 Unique Connections Required: 847 Available Relays: 3000 Follows: 1000 Relays per person: 2 Unique Connections Required: 1461 I’m not a client developer and I certainly don’t have all the solutions but I’ve spent enough time operating websockets at scale to know that these numbers aren’t going to work even with only 2 relays per person. Aside from the practical performance implications, browsers also enforce websocket limits that put most of these numbers out of reach (I believe Chrome is 255 and Firefox is 200). What am I missing?

@ 3bf0c63f:aefa459d

# Censorship-resistant relay discovery in Nostr In [Nostr is not decentralized nor censorship-resistant](nostr:naddr1qqyrsdmpxgcrsepeqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c4n8rw6) I said Nostr is centralized. Peter Todd thinks it is centralized by design, but I disagree. Nostr wasn't designed to be centralized. The idea was always that clients would follow people in the relays they decided to publish to, even if it was a single-user relay hosted in an island in the middle of the Pacific ocean. But the Nostr explanations never had any guidance about how to do this, and the protocol itself never had any enforcement mechanisms for any of this (because it would be impossible). My original idea was that clients would use some undefined combination of relay hints in reply tags and the (now defunct) `kind:2` relay-recommendation events plus some form of manual action ("it looks like Bob is publishing on relay X, do you want to follow him there?") to accomplish this. With the expectation that we would have a better idea of how to properly implement all this with more experience, Branle, my first working client didn't have any of that implemented, instead it used a stupid static list of relays with read/write toggle -- although it did publish relay hints and kept track of those internally and supported `kind:2` events, these things were not really useful. [Gossip](https://github.com/mikedilger/gossip) was the first client to implement a [truly censorship-resistant relay discovery mechanism](https://mikedilger.com/gossip-relay-model.mp4) that used NIP-05 hints (originally proposed by [Mike Dilger](nprofile1qqswuyd9ml6qcxd92h6pleptfrcqucvvjy39vg4wx7mv9wm8kakyujgua442w)) relay hints and `kind:3` relay lists, and then with the simple insight of [NIP-65](https://nips.nostr.com/65) that got much better. After seeing it in more concrete terms, it became simpler to reason about it and the approach got popularized as the "gossip model", then implemented in clients like [Coracle](https://coracle.social) and [Snort](https://snort.social). Today when people mention the "gossip model" (or "outbox model") they simply think about NIP-65 though. Which I think is ok, but too restrictive. I still think there is a place for the NIP-05 hints, `nprofile` and `nevent` relay hints and specially relay hints in event tags. All these mechanisms are used together in [ZBD Social](nostr:naddr1qqyxgvek8qmryc3eqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823chekfst), for example, but I believe also in the clients listed above. I don't think we should stop here, though. I think there are other ways, perhaps drastically different ways, to approach content propagation and relay discovery. I think manual action by users is underrated and could go a long way if presented in a nice UX (not conceived by people that think users are dumb animals), and who knows what. Reliance on third-parties, hardcoded values, social graph, and specially a mix of multiple approaches, is what Nostr needs to be censorship-resistant and what I hope to see in the future.

@ 3bf0c63f:aefa459d

# início > "Vocês vêem? Vêem a história? Vêem alguma coisa? Me parece que estou tentando lhes contar um sonho -- fazendo uma tentativa inútil, porque nenhum relato de sonho pode transmitir a sensação de sonho, aquela mistura de absurdo, surpresa e espanto numa excitação de revolta tentando se impôr, aquela noção de ser tomado pelo incompreensível que é da própria essência dos sonhos..." > Ele ficou em silêncio por alguns instantes. > "... Não, é impossível; é impossível transmitir a sensação viva de qualquer época determinada de nossa existência -- aquela que constitui a sua verdade, o seu significado, a sua essência sutil e contundente. É impossível. Vivemos, como sonhamos -- sozinhos..." * [Livros mencionados por Olavo de Carvalho](https://fiatjaf.com/livros-olavo.html) * [Antiga _homepage_ Olavo de Carvalho](https://site.olavo.fiatjaf.com "Sapientiam autem non vincit malitia") * [Bitcoin explicado de um jeito correto e inteligível](nostr:naddr1qqrky6t5vdhkjmspz9mhxue69uhkv6tpw34xze3wvdhk6q3q80cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsxpqqqp65wp3k3fu) * [Reclamações](nostr:naddr1qqyrgwf4vseryvmxqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c9f9u03) --- * [Nostr](-/tags/nostr) * [Bitcoin](nostr:naddr1qqyryveexumnyd3kqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c7nywz4) * [How IPFS is broken](nostr:naddr1qqyxgdfsxvck2dtzqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c8y87ll) * [Programming quibbles](nostr:naddr1qqyrjvehxq6ngvpkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cu05y0j) * [Economics](nostr:naddr1qqyk2cm0dehk66trwvq3zamnwvaz7tmxd9shg6npvchxxmmdqgsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8grqsqqqa28clr866) * [Open-source software](nostr:naddr1qqy8xmmxw3mkzun9qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cmyvl8h) --- [Nostr](nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gpyfmhxue69uhkummnw3ez6an9wf5kv6t9vsh8wetvd3hhyer9wghxuet5fmsq8j) [GitHub](https://github.com/fiatjaf) [Telegram](https://t.me/fiatjaf) [Donate](lnurlp://zbd.gg/.well-known/lnurlp/fiatjaf)

@ 7f5c2b4e:a818d75d

Nsec.app is a Nostr application which lets you share access to your account and login to Nostr apps seamlessly with numerous devices. The app is super useful when collaboratively running a Nostr account. It lets you generate tokens to share with partners or colleagues and provide different levels of access to different individuals. Another bonus feature of nsec.app is letting you forget about Nostr browser extensions. Extensions have their fair share of useful features, but using nsec.app (or other apps that support NIP-46 login, e.g. nsecBunker) is often more convenient, arguably more secure and offers some features, that extensions aren't able to deliver. Let's walk through the process of starting the nsec.app and see what features it has to offer. ## Installation Nsec.app is a PWA (see my short blog post on PWAs and their benefits [here](https://habla.news/tony/PWA)), meaning that it can be saved to your device in a way that it feels and acts like a native app. Alternatively the app can be used in the browser. Visit [Nsec.app](https://use.nsec.app/home): https://i.nostr.build/axlP.png After pressing the "Get started" button you'll be welcomed by three main options: "Sign up", "Login" or "Import Key". Let's explore each of these options: 1. Sign up: This option suits those, who do not have a Nostr account yet. I'd steer clear from this option **for now** and create an account in a more "conventional" way – via one of the popular Nostr clients or by utilizing a dedicated browser extension. > Stay tuned as the developers are working on wide implementation of NIP49. At the moment few Nostr clients support NIP49, so you won't have many options of using keys created with nsec.app. When most Nostr apps support NIP49 logins, signing up to Nostr via nsec.app will become a more convenient option. If you decide to utilize nsec.app to create your Nostr account, the process is super simple: 1) Choose your Nostr address 2) Create and confirm your password 3) Enjoy your new Nostr account 💜 https://i.nostr.build/JqgP.png 2. Import key: This approach assumes you would like to start using nsec.app with the existing Nostr account. https://i.nostr.build/5e9y.png In this case you'll need to choose your username, provide your private key and choose a password. This will create the nsec.app account (by setting a username and a password) while binding it with your original Nostr account (by providing your private key). > It is worth noting that your keys will be encrypted by your password and stored on nsec.app's server to sync to other devices in end-to-end encrypted manner. 3. Login: This approach assumes you've already set up nsec.app and would like to enter your dashboard from a new device. https://i.nostr.build/k6aa.png > Do not forget to click the "Enable background service" tile after setting up your account. This will ensure you receive a notification whenever the request to authorize a login is created. https://i.nostr.build/Zrdx.png ## Usage After setting up nsec.app you're ready to start utilizing it to login to numerous Nostr apps. The most powerful feature of nsec.app is that it lets you login to apps without having to use the browser extension or exposing your private key. For example, I can now turn [Coracle](https://coracle.social/) client into a PWA on my iPhone, which is otherwise impossible, because Apple does not allow you to utilize browser extensions with PWAs. Another use case is delegating the rights to interact with Nostr on behalf of the account you created. Regardless of wether you want to use the app single-handedly, or delegate the private key, the process is as follows: 1. Use nsec.app to create a login string by pressing "Connect app". 2. Copy the string by pressing the corresponding button. https://i.nostr.build/rvVB.png 3. Paste the string into the client that you'd like to login to. 4. As you (or your companion) try to login to the Nostr app, nsec.app will display a notification asking you (the administrator) to approve the login. https://i.nostr.build/7x53.png As you can see, there are two options for you to choose from: - Basic permissions: This will approve all potential future interactions. - On demand: This will log the user in and ask for your approvals every time the user tries to interact with the protocol in a new way (like, zap, follow, etc.) That's it. You can now interact with nostr without ever having to utilize the browser extension or share your private key with any app. ## Features ### Customization Nsec.app lets you customize the way your connected apps look. You can name them, specify a website address and choose an icon of your choice. Very handy functionality for when you start actively using the app: https://i.nostr.build/ej6X.png As the stack of connected apps grows this will help you distinguish between them in order to introduce any necessary changes. https://i.nostr.build/XEgW.png ### Connected apps management This leads us to the next important part of using nsec.app: revoking access to apps. This is especially important when it comes to sharing access to account with someone else. In case you no longer plan to collaborate on the account, or you simply do not need some app connection to function any longer, you can revoke access at any time. Just open the app you need and: (a) press "Delete app" (this completely cuts connection between your app and nsec.app) or (b) press the three dots next to the existing approved permission followed by "Delete permission" (this cancels the given permission, so that the next time you (or other user) tries to interact with the protocol, you will receive a notification asking you to approve their action). https://i.nostr.build/d3QD.png ### NIP49 logins Nsec.app allows you to utilize another way of logging into Nostr apps – NIP49. We touched on this approach earlier, so let's explore how it works. Here's an example with [Noogle](https://noogle.lol): 1. Choose the Login with **NCryptSec** option: https://i.nostr.build/DzeV.png 2. Enter the encrypted Nsec (to be retrieved from the nsec.app in Settings -> Export) and the nsec.app password: https://i.nostr.build/R505.png That's it. You're logged in. https://i.nostr.build/moLR.png At the moment few clients support this NIP, but given the benefits of this functionality, it shouldn't be long before we see more and more clients join in. ## Outro Just like with every other Nostr app, there's a lot of work to be done. Nevertheless, nsec.app already solves many important problems, and is definitely worth your attention. Give it a try and let us know if you find any bugs, or come up with some ideas worth implementing. Feel free to ping myself or, better yet, the app developer nostr:npub1xdtducdnjerex88gkg2qk2atsdlqsyxqaag4h05jmcpyspqt30wscmntxy --- Hope this guide was useful! If so, don't forget to zap this post 😉 *See you on the other side of the Nostr rabbit hole* *Tony⚡️*

@ 2d5b6404:d4b500b0

1. アンフィールドでリバプールの試合を観戦する 2. イタリアでピザ食べたりエスプレッソ飲む 3. じゅりよんやラルフ、ewelina、マルティン、jefgとか𓆏に会いにヨーロッパ旅行行く 4. 長崎ぺんぎん水族館に行く 5. 九十九里で貝を食べる 6. 奄美大島でクジラの鳴き声を聞く 7. 蒸気機関車に乗る 8. 台湾旅行に行く 9. 韓国旅行に行く 10. 船で東京か大阪、四国に行く 11. Punkt. MP02を買い替える 12. ベトナムに住んでる友達に会いに行く 13. ホームベースとなる共同体を見つける。もしくは作る 14. 収入の10分の１を寄付する 15. ~~デスストランディングをクリアする~~ 16. ブレワイ、ティアキンをクリアする 17. べランピングする 18. 冷蔵庫を伊良コーラでいっぱいにする 19. 友達とこたつでゲームする

@ 3bf0c63f:aefa459d

# Nostr: a quick introduction, attempt #1  Nostr doesn't have a material existence, it is not a website or an app. Nostr is just a description what kind of messages each computer can send to the others and vice-versa. It's a very simple thing, but the fact that such description exists allows different apps to connect to different servers automatically, without people having to talk behind the scenes or sign contracts or anything like that. When you use a Nostr _client_ that is what happens, your _client_ will connect to a bunch of servers, called _relays_, and all these _relays_ will speak the same "language" so your _client_ will be able to publish notes to them all and also download notes from other people. That's basically what Nostr is: this communication layer between the _client_ you run on your phone or desktop computer and the _relay_ that someone else is running on some server somewhere. There is no central authority dictating who can connect to whom or even anyone who knows for sure where each note is stored. If you think about it, Nostr is very much like the internet itself: there are millions of websites out there, and basically anyone can run a new one, and there are websites that allow you to store and publish your stuff on them. The added benefit of Nostr is that this unified "language" that all Nostr _clients_ speak allow them to switch very easily and cleanly between _relays_. So if one _relay_ decides to ban someone that person can switch to publishing to others _relays_ and their audience will quickly follow them there. Likewise, it becomes much easier for _relays_ to impose any restrictions they want on their users: no _relay_ has to uphold a moral ground of "absolute free speech": each _relay_ can decide to delete notes or ban users for no reason, or even only store notes from a preselected set of people and no one will be entitled to complain about that. There are some bad things about this design: on Nostr there are no guarantees that _relays_ will have the notes you want to read or that they will store the notes you're sending to them. We can't just assume all _relays_ will have everything — much to the contrary, as Nostr grows more _relays_ will exist and people will tend to publishing to a small set of all the _relays_, so depending on the decisions each _client_ takes when publishing and when fetching notes, users may see a different set of replies to a note, for example, and be confused. Another problem with the idea of publishing to multiple servers is that they may be run by all sorts of malicious people that may edit your notes. Since no one wants to see garbage published under their name, Nostr fixes that by requiring notes to have a cryptographic signature. This signature is attached to the note and verified by everybody at all times, which ensures the notes weren't tampered (if any part of the note is changed even by a single character that would cause the signature to become invalid and then the note would be dropped). The fix is perfect, except for the fact that it introduces the requirement that each user must now hold this 63-character code that starts with "nsec1", which they must not reveal to anyone. Although annoying, this requirement brings another benefit: that users can automatically have the same identity in many different contexts and even use their Nostr identity to login to non-Nostr websites easily without having to rely on any third-party. To conclude: Nostr is like the internet (or the internet of some decades ago): a little chaotic, but very open. It is better than the internet because it is structured and actions can be automated, but, like in the internet itself, nothing is guaranteed to work at all times and users many have to do some manual work from time to time to fix things. Plus, there is the cryptographic key stuff, which is painful, but cool.

@ 2f7463a4:e92b8023

Dies ist die deutsche Übersetzung von / _This is the German translation of_ : nostr:naddr1qqxnzd3cxserxdpsxverzwp4qgs87hptfey2p607ef36g6cnekuzfz05qgpe34s2ypc2j6x24qvdwhgrqsqqqa28zcj37a — nostr:npub10awzknjg5r5lajnr53438ndcyjylgqsrnrtq5grs495v42qc6awsj45ys7 Weitere Übersetzungen / _Other translations_ : - Spanisch / _Spanish_ : nostr:naddr1qqx9zat994jhxttgv93xccgzypl4c26wfzswnlk2vwjxky7dhqjgnaqzqwvdvz3qwz5k3j4grrt46qcyqqq823cf6w59v — nostr:npub138s5hey76qrnm2pmv7p8nnffhfddsm8sqzm285dyc0wy4f8a6qkqtzx624 --- [Habla](https://habla.news/) ist eine auf Nostr basierende Plattform, mit der du umfangreiche Beiträge erstellen und verwalten kannst. Man könnte es mit Medium vergleichen, aber Habla ist viel mehr als das. Habla ist herkömmlichen Blogging-Plattformen überlegen, weil es auf [Nostr](https://bevstr.com/Nostr/) basiert. Es ist mit einer Vielzahl anderer [Nostr-Apps](https://www.nostrapps.com/) interoperabel, was die Benutzererfahrung nahtlos und fesselnd macht. Darüber hinaus können deine Inhalte, wenn sie von den Lesern als wertvoll empfunden werden, dank des [Lightning-Netzwerkes](https://www.lopp.net/lightning-information.html) sofort mit dem besten Geld, das die Menschheit je gesehen hat, belohnt werden: [Bitcoin](https://www.lopp.net/bitcoin-information.html). ## Was ist Nostr? Nostr ist eine neue Art der Online-Kommunikation, die ihren Nutzern zahlreiche Vorteile bietet. Nostr ist für alle kostenlos, man braucht keine ID oder andere Verifizierung durch Dritte, um sich anzumelden, Gleichgesinnte zu treffen und die Community um sich herum zu vergrößern. Nostr wird oft mit einer Social-Media-Plattform verwechselt, ist aber viel mehr als das. Wir empfehlen dir einen Blick auf die [hier](https://www.bevstr.com/Nostr/) gesammelten Nostr-Ressourcen zu werfen, um die potenzielle Dimension dieses Tools zu erkennen. ## Wie melde ich mich bei Habla an? Um auf Habla zu schreiben, erstelle einfach ein Habla/Nostr-Konto und melde dich an. Folge diesen [einfachen Schritten](https://nosta.me/), um dich zu registrieren, Mehrwert zu bieten und Gegenwert zurückzuerhalten. ## Wie verdiene ich mit Habla? Habla ermöglicht es, Werte direkt von deinen Lesern zu erhalten. Es ist kein Bankkonto oder Ausweis erforderlich. Verbinde einfach deine Lightning-Adresse mit deinem Habla/Nostr-Konto und erhalte Geld direkt auf dein Wallet – ohne Dritte, ohne Warten auf Abhebungen, ohne Stress. Folge [diesen einfachen Schritten](https://lnshort.it/earn-with-nostr/), um loszulegen. ## Warum ist das Publizieren auf Habla anders? Das Nostr-Protokoll ist sehr schlank, was einige Besonderheiten im Verhalten von Nostr-basierten Anwendungen mit sich bringt. Wir gehen hier nicht auf die technischen Details ein, aber der offensichtlichste Unterschied, den du als Autor bemerken wirst, ist, dass du ein anderes und möglicherweise ungewohntes Textformat für deine Beiträge verwenden musst. Aber keine Angst, Habla bietet Tools, die diesen Prozess einfach und intuitiv machen. Hier ist ein kurzes Video von nostr:npub1wkljx5c6a8uccc5etws8ry0y3r4dgavh2dcav0tal4rtmcdl4z2sfu5u0t, das die Grundlagen des Publizierens mit Habla erklärt (der Leitfaden wurde vor dem Redesign erstellt, ist aber immer noch nützlich): https://nostr.build/p/nb9474.mp4 Habla (und viele andere Nostr-Anwendungen) verwendet das etablierte Format Markdown. Das gibt es schon seit fast einem Jahrzehnt und wird von den meisten Apps, die du jeden Tag benutzt, unterstützt. Der Grund, warum du vielleicht noch nichts von Markdown gehört hast, ist, dass herkömmliche Anwendungen es normalerweise vor dem Benutzer verbergen, und wir arbeiten daran, dies auch zu tun. Mehr über Markdown kannst du [hier](https://markdown.land/) herausfinden. ## Wo werden meine Inhalte gespeichert? Herkömmliche Blogging-Plattformen speichern die Inhalte auf ihren eigenen Servern. Das ist ein bequemer und (früher) solider Ansatz, der aber auch kritische Risiken birgt. Wenn du die Früchte deiner Arbeit einer einzigen Partei überlässt, hat diese die vollständige Kontrolle über deine Inhalte. Nostr löst dieses Problem. Jedes Mal, wenn du etwas veröffentlichst, wird dein Inhalt an zahlreiche [Relais](https://lnshort.it/nostr-relays) zur Speicherung und Verbreitung weitergeleitet. Wenn ein Relais-Betreiber deinen Beitrag blockiert oder sich weigert, ihn weiterzuverbreiten, können deine Leser auf andere Relais zurückgreifen, um Zugang zu deinen Inhalten zu erhalten (keine Sorge, wenn das kompliziert klingt, alles geschieht unter der Haube). Auf diese Weise wird sichergestellt, dass du niemals zum Schweigen gebracht wirst. Wir haben uns entschieden, uns auf das zu konzentrieren, was wir am besten können: eine intuitive, effiziente und einfach zu bedienende Blogging-Plattform zu entwickeln, die sich lohnt – und das Speichern und Verbreiten von Inhalten den Profis auf diesem Gebiet zu überlassen. ## Wie publiziere ich? Habla bietet alle Tools, die du brauchst, um eindrucksvolle Artikel zu erstellen, die sich von anderen abheben. Bereite deinen Artikel vor, formatiere deinen Text mit den entsprechenden Tools, füge Medien hinzu und schau dir das Ergebnis vor Veröffentlichung selbst noch einmal an. Alles, was du brauchst, steht dir zur Verfügung, und die Plattform wird von Tag zu Tag besser und benutzerfreundlicher. ## Wer kann meine Beiträge auf Habla lesen? Jeder im Internet kann deine Beiträge lesen. Wenn deine Leser jedoch mit deiner Arbeit interagieren möchten – sei es durch Folgen, Kommentieren oder indem sie dir etwas zurückgeben möchten – sollten sie ein Nostr-Konto einrichten. Wir ermutigen dich, deine Follower einzubeziehen, um eine blühende Community aufzubauen und neue Höhen zu erreichen. [Diese Kurzanleitung](https://lnshort.it/nostr-welcome/) wird dir und deinen Fans den Einstieg erleichtern. --- _Dieses FAQ befindet sich in ständiger Entwicklung und wird sich in dem Maße ändern, wie Habla und Nostr zu noch leistungsfähigeren Tools werden. Bitte teile mir dein Feedback mit, damit ich es noch besser machen kann._

@ 3bf0c63f:aefa459d

# Pequenos problemas que o Estado cria para a sociedade e que não são sempre lembrados - **vale-transporte**: transferir o custo com o transporte do funcionário para um terceiro o estimula a morar longe de onde trabalha, já que morar perto é normalmente mais caro e a economia com transporte é inexistente. - **atestado médico**: o direito a faltar o trabalho com atestado médico cria a exigência desse atestado para todas as situações, substituindo o livre acordo entre patrão e empregado e sobrecarregando os médicos e postos de saúde com visitas desnecessárias de assalariados resfriados. - **prisões**: com dinheiro mal-administrado, burocracia e péssima alocação de recursos -- problemas que empresas privadas em competição (ou mesmo sem qualquer competição) saberiam resolver muito melhor -- o Estado fica sem presídios, com os poucos existentes entupidos, muito acima de sua alocação máxima, e com isto, segundo a bizarra corrente de responsabilidades que culpa o juiz que condenou o criminoso por sua morte na cadeia, juízes deixam de condenar à prisão os bandidos, soltando-os na rua. - **justiça**: entrar com processos é grátis e isto faz proliferar a atividade dos advogados que se dedicam a criar problemas judiciais onde não seria necessário e a entupir os tribunais, impedindo-os de fazer o que mais deveriam fazer. - **justiça**: como a justiça só obedece às leis e ignora acordos pessoais, escritos ou não, as pessoas não fazem acordos, recorrem sempre à justiça estatal, e entopem-na de assuntos que seriam muito melhor resolvidos entre vizinhos. - **leis civis**: as leis criadas pelos parlamentares ignoram os costumes da sociedade e são um incentivo a que as pessoas não respeitem nem criem normas sociais -- que seriam maneiras mais rápidas, baratas e satisfatórias de resolver problemas. - **leis de trãnsito**: quanto mais leis de trânsito, mais serviço de fiscalização são delegados aos policiais, que deixam de combater crimes por isto (afinal de contas, eles não querem de fato arriscar suas vidas combatendo o crime, a fiscalização é uma excelente desculpa para se esquivarem a esta responsabilidade). - **financiamento educacional**: é uma espécie de subsídio às faculdades privadas que faz com que se criem cursos e mais cursos que são cada vez menos recheados de algum conhecimento ou técnica útil e cada vez mais inúteis. - **leis de tombamento**: são um incentivo a que o dono de qualquer área ou construção "histórica" destrua todo e qualquer vestígio de história que houver nele antes que as autoridades descubram, o que poderia não acontecer se ele pudesse, por exemplo, usar, mostrar e se beneficiar da história daquele local sem correr o risco de perder, de fato, a sua propriedade. - **zoneamento urbano**: torna as cidades mais espalhadas, criando uma necessidade gigantesca de carros, ônibus e outros meios de transporte para as pessoas se locomoverem das zonas de moradia para as zonas de trabalho. - **zoneamento urbano**: faz com que as pessoas percam horas no trânsito todos os dias, o que é, além de um desperdício, um atentado contra a sua saúde, que estaria muito melhor servida numa caminhada diária entre a casa e o trabalho. - **zoneamento urbano**: torna ruas e as casas menos seguras criando zonas enormes, tanto de residências quanto de indústrias, onde não há movimento de gente alguma. - **escola obrigatória + currículo escolar nacional**: emburrece todas as crianças. - **leis contra trabalho infantil**: tira das crianças a oportunidade de aprender ofícios úteis e levar um dinheiro para ajudar a família. - **licitações**: como não existem os critérios do mercado para decidir qual é o melhor prestador de serviço, criam-se comissões de pessoas que vão decidir coisas. isto incentiva os prestadores de serviço que estão concorrendo na licitação a tentar comprar os membros dessas comissões. isto, fora a corrupção, gera problemas reais: __(i)__ a escolha dos serviços acaba sendo a pior possível, já que a empresa prestadora que vence está claramente mais dedicada a comprar comissões do que a fazer um bom trabalho (este problema afeta tantas áreas, desde a construção de estradas até a qualidade da merenda escolar, que é impossível listar aqui); __(ii)__ o processo corruptor acaba, no longo prazo, eliminando as empresas que prestavam e deixando para competir apenas as corruptas, e a qualidade tende a piorar progressivamente. - **cartéis**: o Estado em geral cria e depois fica refém de vários grupos de interesse. o caso dos taxistas contra o Uber é o que está na moda hoje (e o que mostra como os Estados se comportam da mesma forma no mundo todo). - **multas**: quando algum indivíduo ou empresa comete uma fraude financeira, ou causa algum dano material involuntário, as vítimas do caso são as pessoas que sofreram o dano ou perderam dinheiro, mas o Estado tem sempre leis que prevêem multas para os responsáveis. A justiça estatal é sempre muito rígida e rápida na aplicação dessas multas, mas relapsa e vaga no que diz respeito à indenização das vítimas. O que em geral acontece é que o Estado aplica uma enorme multa ao responsável pelo mal, retirando deste os recursos que dispunha para indenizar as vítimas, e se retira do caso, deixando estas desamparadas. - **desapropriação**: o Estado pode pegar qualquer propriedade de qualquer pessoa mediante uma indenização que é necessariamente inferior ao valor da propriedade para o seu presente dono (caso contrário ele a teria vendido voluntariamente). - **seguro-desemprego**: se há, por exemplo, um prazo mínimo de 1 ano para o sujeito ter direito a receber seguro-desemprego, isto o incentiva a planejar ficar apenas 1 ano em cada emprego (ano este que será sucedido por um período de desemprego remunerado), matando todas as possibilidades de aprendizado ou aquisição de experiência naquela empresa específica ou ascensão hierárquica. - **previdência**: a previdência social tem todos os defeitos de cálculo do mundo, e não importa muito ela ser uma forma horrível de poupar dinheiro, porque ela tem garantias bizarras de longevidade fornecidas pelo Estado, além de ser compulsória. Isso serve para criar no imaginário geral a idéia da __aposentadoria__, uma época mágica em que todos os dias serão finais de semana. A idéia da aposentadoria influencia o sujeito a não se preocupar em ter um emprego que faça sentido, mas sim em ter um trabalho qualquer, que o permita se aposentar. - **regulamentação impossível**: milhares de coisas são proibidas, há regulamentações sobre os aspectos mais mínimos de cada empreendimento ou construção ou espaço. se todas essas regulamentações fossem exigidas não haveria condições de produção e todos morreriam. portanto, elas não são exigidas. porém, o Estado, ou um agente individual imbuído do poder estatal pode, se desejar, exigi-las todas de um cidadão inimigo seu. qualquer pessoa pode viver a vida inteira sem cumprir nem 10% das regulamentações estatais, mas viverá também todo esse tempo com medo de se tornar um alvo de sua exigência, num estado de terror psicológico. - **perversão de critérios**: para muitas coisas sobre as quais a sociedade normalmente chegaria a um valor ou comportamento "razoável" espontaneamente, o Estado dita regras. estas regras muitas vezes não são obrigatórias, são mais "sugestões" ou limites, como o salário mínimo, ou as 44 horas semanais de trabalho. a sociedade, porém, passa a usar esses valores como se fossem o normal. são raras, por exemplo, as ofertas de emprego que fogem à regra das 44h semanais. - **inflação**: subir os preços é difícil e constrangedor para as empresas, pedir aumento de salário é difícil e constrangedor para o funcionário. a inflação força as pessoas a fazer isso, mas o aumento não é automático, como alguns economistas podem pensar (enquanto alguns outros ficam muito satisfeitos de que esse processo seja demorado e difícil). - **inflação**: a inflação destrói a capacidade das pessoas de julgar preços entre concorrentes usando a própria memória. - **inflação**: a inflação destrói os cálculos de lucro/prejuízo das empresas e prejudica enormemente as decisões empresariais que seriam baseadas neles. - **inflação**: a inflação redistribui a riqueza dos mais pobres e mais afastados do sistema financeiro para os mais ricos, os bancos e as megaempresas. - **inflação**: a inflação estimula o endividamento e o consumismo. - **lixo:** ao prover coleta e armazenamento de lixo "grátis para todos" o Estado incentiva a criação de lixo. se tivessem que pagar para que recolhessem o seu lixo, as pessoas (e conseqüentemente as empresas) se empenhariam mais em produzir coisas usando menos plástico, menos embalagens, menos sacolas. - **leis contra crimes financeiros:** ao criar legislação para dificultar acesso ao sistema financeiro por parte de criminosos a dificuldade e os custos para acesso a esse mesmo sistema pelas pessoas de bem cresce absurdamente, levando a um percentual enorme de gente incapaz de usá-lo, para detrimento de todos -- e no final das contas os grandes criminosos ainda conseguem burlar tudo.

@ 3bf0c63f:aefa459d

# Drivechain Understanding Drivechain requires a shift from the paradigm most bitcoiners are used to. It is not about "trustlessness" or "mathematical certainty", but game theory and incentives. (Well, Bitcoin in general is also that, but people prefer to ignore it and focus on some illusion of trustlessness provided by mathematics.) Here we will describe the basic mechanism (simple) and incentives (complex) of ["hashrate escrow"](https://github.com/bitcoin/bips/blob/master/bip-0300.mediawiki) and how it enables a 2-way peg between the mainchain (Bitcoin) and various sidechains. The full concept of "Drivechain" also involves blind merged mining (i.e., the sidechains mine themselves by publishing their block hashes to the mainchain without the miners having to run the sidechain software), but this is much easier to understand and can be accomplished either by [the BIP-301 mechanism](https://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki) or by [the Spacechains mechanism](https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5). ## How does hashrate escrow work from the point of view of Bitcoin? A new address type is created. Anything that goes in that is locked and can only be spent if all miners agree on the _Withdrawal Transaction_ (`WT^`) that will spend it for 6 months. There is one of these special addresses for each sidechain. To gather miners' agreement `bitcoind` keeps track of the "score" of all transactions that could possibly spend from that address. On every block mined, for each sidechain, the miner can use a portion of their coinbase to either increase the score of one `WT^` by 1 while decreasing the score of all others by 1; or they can decrease the score of all `WT^`s by 1; or they can do nothing. Once a transaction has gotten a score high enough, it is published and funds are effectively transferred from the sidechain to the withdrawing users. If a timeout of 6 months passes and the score doesn't meet the threshold, that `WT^` is discarded. ## What does the above procedure _mean_? It means that people can transfer coins from the mainchain to a sidechain by depositing to the special address. Then they can withdraw from the sidechain by making a special withdraw transaction in the sidechain. The special transaction somehow freezes funds in the sidechain while a transaction that aggregates all withdrawals into a single mainchain `WT^`, which is then submitted to the mainchain miners so they can start voting on it and finally after some months it is published. Now the crucial part: _the validity of the `WT^` is not verified by the Bitcoin mainchain rules_, i.e., if Bob has requested a withdraw from the sidechain to his mainchain address, but someone publishes a wrong `WT^` that instead takes Bob's funds and sends them to Alice's main address there is no way the mainchain will know that. What determines the "validity" of the `WT^` is the miner vote score and only that. It is the job of miners to vote correctly -- and for that they may want to run the sidechain node in SPV mode so they can attest for the existence of a reference to the `WT^` transaction in the sidechain blockchain (which then ensures it is ok) or do these checks by some other means. ## What? 6 months to get my money back? Yes. But no, in practice anyone who wants their money back will be able to use an atomic swap, submarine swap or other similar service to transfer funds from the sidechain to the mainchain and vice-versa. The long delayed withdraw costs would be incurred by few liquidity providers that would gain some small profit from it. ## Why bother with this at all? Drivechains solve many different problems: ### It enables experimentation and new use cases for Bitcoin Issued assets, fully private transactions, stateful blockchain contracts, turing-completeness, decentralized games, some "DeFi" aspects, prediction markets, futarchy, decentralized and yet meaningful human-readable names, big blocks with a ton of normal transactions on them, a chain optimized only for Lighting-style networks to be built on top of it. These are some ideas that may have merit to them, but were never _actually_ tried because they couldn't be tried with real Bitcoin or inferfacing with real bitcoins. They were either relegated to the shitcoin territory or to custodial solutions like Liquid or RSK that may have failed to gain network effect because of that. ### It solves conflicts and infighting Some people want fully private transactions in a UTXO model, others want "accounts" they can tie to their name and build reputation on top; some people want simple multisig solutions, others want complex code that reads a ton of variables; some people want to put all the transactions on a global chain in batches every 10 minutes, others want off-chain instant transactions backed by funds previously locked in channels; some want to spend, others want to just hold; some want to use blockchain technology to solve all the problems in the world, others just want to solve money. With Drivechain-based sidechains all these groups can be happy simultaneously and don't fight. Meanwhile they will all be using the same money and contributing to each other's ecosystem even unwillingly, it's also easy and free for them to change their group affiliation later, which reduces cognitive dissonance. ### It solves "scaling" Multiple chains like the ones described above would certainly do a lot to accomodate many more transactions that the current Bitcoin chain can. One could have special Lightning Network chains, but even just big block chains or big-block-mimblewimble chains or whatnot could probably do a good job. Or even something less cool like 200 independent chains just like Bitcoin is today, no extra features (and you can call it "sharding"), just that would already multiply the current total capacity by 200. Use your imagination. ### It solves the blockchain security budget issue The calculation is simple: you imagine what security budget is reasonable for each block in a world without block subsidy and divide that for the amount of bytes you can fit in a single block: that is the price to be paid in _satoshis per byte_. In reasonable estimative, the price necessary for every Bitcoin transaction goes to very large amounts, such that not only any day-to-day transaction has insanely prohibitive costs, but also Lightning channel opens and closes are impracticable. So without a solution like Drivechain you'll be left with only one alternative: pushing Bitcoin usage to trusted services like Liquid and RSK or custodial Lightning wallets. With Drivechain, though, there could be thousands of transactions happening in sidechains and being all aggregated into a sidechain block that would then pay a very large fee to be published (via blind merged mining) to the mainchain. Bitcoin security guaranteed. ### It keeps Bitcoin decentralized Once we have sidechains to accomodate the normal transactions, the mainchain functionality can be reduced to be only a "hub" for the sidechains' comings and goings, and then the maximum block size for the mainchain can be reduced to, say, 100kb, which would make running a full node very very easy. ## Can miners steal? Yes. If a group of coordinated miners are able to secure the majority of the hashpower and keep their coordination for 6 months, they can publish a `WT^` that takes the money from the sidechains and pays to themselves. ## Will miners steal? No, because the incentives are such that they won't. Although it may look at first that stealing is an obvious strategy for miners as it is free money, there are many costs involved: 1. The cost of **ceasing blind-merged mining returns** -- as stealing will kill a sidechain, all the fees from it that miners would be expected to earn for the next years are gone; 2. The cost of **Bitcoin price going down**: If a steal is successful that will mean Drivechains are not safe, therefore Bitcoin is less useful, and miner credibility will also be hurt, which are likely to cause the Bitcoin price to go down, which in turn may kill the miners' businesses and savings; 3. The cost of **coordination** -- assuming miners are just normal businesses, they just want to do their work and get paid, but stealing from a Drivechain will require coordination with other miners to conduct an immoral act in a way that has many pitfalls and is likely to be broken over the months; 4. The cost of **miners leaving your mining pool**: when we talked about "miners" above we were actually talking about mining pools operators, so they must also consider the risk of miners migrating from their mining pool to others as they begin the process of stealing; 5. The cost of **community goodwill** -- when participating in a steal operation, a miner will suffer a ton of backlash from the community. Even if the attempt fails at the end, the fact that it was attempted will contribute to growing concerns over exaggerated miners power over the Bitcoin ecosystem, which may end up causing the community to agree on a hard-fork to change the mining algorithm in the future, or to do something to increase participation of more entities in the mining process (such as development or cheapment of new ASICs), which have a chance of decreasing the profits of current miners. Another point to take in consideration is that one may be inclined to think a newly-created sidechain or a sidechain with relatively low usage may be more easily stolen from, since the blind merged mining returns from it (point 1 above) are going to be small -- but the fact is also that a sidechain with small usage will also have less money to be stolen from, and since the other costs besides 1 are less elastic at the end it will not be worth stealing from these too. All of the above consideration are valid only if miners are stealing from _good sidechains_. If there is a sidechain that is doing things wrong, scamming people, not being used at all, or is full of bugs, for example, that will be perceived as a bad sidechain, and then miners can and will safely steal from it and kill it, which will be perceived as a good thing by everybody. ## What do we do if miners steal? Paul Sztorc has suggested in the past that a user-activated soft-fork could prevent miners from stealing, i.e., most Bitcoin users and nodes issue a rule [similar to this one](https://twitter.com/LukeDashjr/status/1126221228182843398) to invalidate the inclusion of a faulty `WT^` and thus cause any miner that includes it in a block to be relegated to their own Bitcoin fork that other nodes won't accept. This suggestion has made people think Drivechain is a sidechain solution _backed by user-actived soft-forks for safety_, which is very far from the truth. Drivechains must not and will not rely on this kind of soft-fork, although they are possible, as the coordination costs are too high and no one should ever expect these things to happen. If even with all the incentives against them (see above) miners do still steal from a _good sidechain_ that will mean _the failure of the Drivechain experiment_. It will very likely also mean _the failure of the Bitcoin experiment_ too, as it will be proven that miners can coordinate to act maliciously over a prolonged period of time regardless of economic and social incentives, meaning they are probably in it just for attacking Bitcoin, backed by nation-states or something else, and therefore no Bitcoin transaction in the mainchain is to be expected to be safe ever again. ## Why use this and not a full-blown trustless and open sidechain technology? Because it is impossible. If you ever heard someone saying "just use a sidechain", "do this in a sidechain" or anything like that, be aware that these people are either talking about "federated" sidechains (i.e., funds are kept in custody by a group of entities) or they are talking about Drivechain, or they are disillusioned and think it is possible to do sidechains in any other manner. ### No, I mean a trustless 2-way peg with correctness of the withdrawals verified by the Bitcoin protocol! That is not possible unless Bitcoin verifies all transactions that happen in all the sidechains, which would be akin to drastically increasing the blocksize and expanding the Bitcoin rules in tons of ways, i.e., a terrible idea that no one wants. ### What about the Blockstream sidechains whitepaper? Yes, that was a way to do it. The Drivechain hashrate escrow is a conceptually simpler way to achieve the same thing with improved incentives, less junk in the chain, more safety. ## Isn't the hashrate escrow a very complex soft-fork? Yes, but it is much simpler than SegWit. And, unlike SegWit, it doesn't force anything on users, i.e., it isn't a mandatory blocksize increase. ## Why should we expect miners to care enough to participate in the voting mechanism? Because it's in their own self-interest to do it, and it costs very little. Today over half of the miners mine RSK. It's not blind merged mining, it's a [very convoluted process that requires them to run a RSK full node](https://developers.rsk.co/rsk/architecture/mining/implementation-guide/). For the Drivechain sidechains, an SPV node would be enough, or maybe just getting data from a block explorer API, so much much simpler. ## What if I still don't like Drivechain even after reading this? That is the entire point! You don't have to like it or use it as long as you're fine with other people using it. The hashrate escrow special addresses will not impact you at all, validation cost is minimal, and you get the benefit of people who want to use Drivechain migrating to their own sidechains and freeing up space for you in the mainchain. See also the point above about infighting. ## See also * [Podcast episode with Ruben Somsen and Aaron van Wirdum explaining Drivechain](https://www.youtube.com/watch?v=DhU6nsB5Z-0) * [Alternatives to Drivechain](nostr:naddr1qqyrqenzvvukvcfkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823csjg2t6) * [Drivechain comparison with Ethereum](nostr:naddr1qqyx2dp58qcx2wpjqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cane7px)

@ 3bf0c63f:aefa459d

# `bitcoind` decentralization It is better to have multiple curator teams, with different vetting processes and release schedules for `bitcoind` than a single one. "More eyes on code", "Contribute to Core", "Everybody should audit the code". All these points repeated again and again fell to Earth on the day it was discovered that Bitcoin Core developers merged a variable name change from "blacklist" to "blocklist" without even discussing or acknowledging the fact that that innocent pull request opened by a sybil account was a social attack. After a big lot of people manifested their dissatisfaction with that event on Twitter and on GitHub, most Core developers simply ignored everybody's concerns or even personally attacked people who were complaining. The event has shown that: 1) Bitcoin Core ultimately rests on the hands of a couple maintainers and they decide what goes on the GitHub repository[^pr-merged-very-quickly] and the binary releases that will be downloaded by thousands; 2) Bitcoin Core is susceptible to social attacks; 2) "More eyes on code" don't matter, as these extra eyes can be ignored and dismissed. ## Solution: `bitcoind` decentralization If usage was spread across 10 different `bitcoind` flavors, the network would be much more resistant to social attacks to a single team. This has nothing to do with the question on if it is better to have multiple different Bitcoin node implementations or not, because here we're basically talking about the same software. Multiple teams, each with their own release process, their own logo, some subtle changes, or perhaps no changes at all, just a different name for their `bitcoind` flavor, and that's it. Every day or week or month or year, each flavor merges all changes from Bitcoin Core on their own fork. If there's anything suspicious or too leftist (or perhaps too rightist, in case there's a leftist `bitcoind` flavor), maybe they will spot it and not merge. This way we keep the best of both worlds: all software development, bugfixes, improvements goes on Bitcoin Core, other flavors just copy. If there's some non-consensus change whose efficacy is debatable, one of the flavors will merge on their fork and test, and later others -- including Core -- can copy that too. Plus, we get resistant to attacks: in case there is an attack on Bitcoin Core, only 10% of the network would be compromised. the other flavors would be safe. ## Run Bitcoin Knots The first example of a `bitcoind` software that follows Bitcoin Core closely, adds some small changes, but has an independent vetting and release process is [Bitcoin Knots][knots], maintained by the incorruptible Luke DashJr. Next time you decide to run `bitcoind`, run Bitcoin Knots instead and contribute to `bitcoind` decentralization! --- ### See also: - [How to attack Bitcoin, Anthony Towns' take](nostr:naddr1qqyrywphxdskzwp5qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cwx779x) [^pr-merged-very-quickly]: See [PR 20624](https://github.com/bitcoin/bitcoin/pull/20624), for example, a very complicated change that [could be introducing bugs or be a deliberate attack](http://www.erisian.com.au/wordpress/2021/01/07/bitcoin-in-2021), merged in 3 days without time for discussion. [knots]: https://bitcoinknots.org/

@ 3bf0c63f:aefa459d

# On "zk-rollups" applied to Bitcoin ZK rollups make no sense in bitcoin because there is no "cheap calldata". all data is already ~~cheap~~ expensive calldata. There could be an onchain zk verification that allows succinct signatures maybe, but never a rollup. What happens is: you can have one UTXO that contains multiple balances on it and in each transaction you can recreate that UTXOs but alter its state using a zk to compress all internal transactions that took place. The blockchain must be aware of all these new things, so it is in no way "L2". And you must have an entity responsible for that UTXO and for conjuring the state changes and zk proofs. But on bitcoin you also must keep the data necessary to rebuild the proofs somewhere else, I'm not sure how can the third party responsible for that UTXO ensure that happens. I think such a construct is similar to a credit card corporation: one central party upon which everybody depends, zero interoperability with external entities, every vendor must have an account on each credit card company to be able to charge customers, therefore it is not clear that such a thing is more desirable than solutions that are truly open and interoperable like Lightning, which may have its defects but at least fosters a much better environment, bringing together different conflicting parties, custodians, anyone.

@ 3bf0c63f:aefa459d

# The problem with ION [ION](https://techcommunity.microsoft.com/t5/identity-standards-blog/ion-we-have-liftoff/ba-p/1441555) is a [DID method](nostr:naddr1qqyrjwrpv93rjcf4qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cuxp7vx) based on a thing called "Sidetree". I can't say for sure what is the problem with ION, because I don't understand the design, even though I have read all I could and asked everybody I knew. All available information only touches on the high-level aspects of it (and of course its amazing wonders) and no one has ever bothered to explain the details. I've also asked the main designer of the protocol, Daniel Buchner, but he may have thought I was trolling him on Twitter and refused to answer, instead pointing me to an incomplete spec on the Decentralized Identity Foundation website that I had already read before. I even tried to join the DIF as a member so I could join their closed community calls and hear what they say, maybe eventually ask a question, so I could understand it, but my entrance was ignored, then after many months and a nudge from another member I was told I had to do a KYC process to be admitted, which I refused. **One thing I know is**: - ION is supposed to provide a way to _rotate keys_ seamlessly and automatically without losing the main identity (and the ION proponents also claim there are no "master" keys because these can also be rotated). - ION is also _not a blockchain_, i.e. it doesn't have a deterministic consensus mechanism and it is decentralized, i.e. anyone can publish data to it, doesn't have to be a single central server, there may be holes in the available data and the protocol doesn't treat that as a problem. - From all we know about years of attempts to scale Bitcoins and develop offchain protocols it is clear that _you can't solve the double-spend problem without a central authority or a kind of blockchain_ (i.e. a decentralized system with deterministic consensus). - _Rotating keys also suffer from the double-spend problem_: whenever you rotate a key it is as if it was "spent", you aren't supposed to be able to use it again. The logic conclusion of the 4 assumptions above is that ION is flawed: it can't provide the key rotation it says it can if it is not a blockchain. ## See also - [Excerpt of discussion about DIDs and ION](nostr:naddr1qqyrydtpx33nsvpcqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ccx33ee)

@ 3bf0c63f:aefa459d

# lnurl-auth explained You may have seen the [lnurl-auth](https://github.com/btcontract/lnurl-rfc/blob/master/lnurl-auth.md) spec or heard about it, but might not know how it works or what is its relationship with other [lnurl](https://github.com/fiatjaf/awesome-lnurl) protocols. This document attempts to solve that. ## Relationship between lnurl-auth and other lnurl protocols First, **what is the relationship of lnurl-auth with other lnurl protocols?** The answer is none, except the fact that they all share the lnurl format for specifying `https` URLs. In fact, lnurl-auth is very unique in the sense that it doesn't even need a Lightning wallet to work, it is a standalone authentication protocol that can work anywhere. ## How does it work Now, **how does it work?** The basic idea is that each wallet has a seed, which is a random value (you may think of the BIP39 seed words, for example). Usually from that seed different keys are derived, each of these yielding a Bitcoin address, and also from that same seed may come the keys used to generate and manage Lightning channels. What lnurl-auth does is to generate a new key from that seed, and from that a new key for each service (identified by its domain) you try to authenticate with.  That way, you effectively have a new identity for each website. Two different services cannot associate your identities. **The flow goes like this:** When you visit a website, the website presents you with a QR code containing a _callback URL_ and a _challenge_. The challenge should be a random value.  When your wallet scans or opens that QR code it uses the _domain_ in the callback URL plus the _main lnurl-auth key_ to derive a key specific for that website, uses that key to sign the challenge and then sends both the public key specific for that for that website plus the signed challenge to the specified URL.  When the service receives the public key it checks it against the challenge signature and start a session for that user. The user is then **identified only by its public key**. If the service wants it can, of course, request more details from the user, associate it with an internal id or username, it is free to do anything. lnurl-auth's goals end here: no passwords, maximum possible privacy. # FAQ * What is the advantage of tying this to Bitcoin and Lightning? One big advantage is that your wallet is already keeping track of one seed, it is already a precious thing. If you had to keep track of a separate auth seed it would be arguably worse, more difficult to bootstrap the protocol, and arguably one of the reasons similar protocols, past and present, weren't successful. * Just signing in to websites? What else is this good for? No, it can be used for authenticating to installable apps and physical places, as long as there is a service running an HTTP server somewhere to read the signature sent from the wallet. But yes, signing in to websites is the main problem to solve here. * Phishing attack! Can a malicious website proxy the QR from a third website and show it to the user to it will steal the signature and be able to login on the third website? No, because the wallet will only talk to the the callback URL, and it will either be controlled by the third website, so the malicious won't see anything; or it will have a different domain, so the wallet will derive a different key and frustrate the malicious website's plan. * I heard [SQRL](https://sqrl.grc.com/) had that same idea and it went nowhere. Indeed. SQRL in its first version was basically the same thing as lnurl-auth, with one big difference: it was vulnerable to phishing attacks (see above). That was basically the only criticism it got everywhere, so the protocol creators decided to solve that by introducing complexity to the protocol. While they were at it they decided to add more complexity for managing accounts and so many more crap that in the the spec which initially was a single page ended up becoming 136 pages of highly technical gibberish. Then all the initial network effect it had, libraries and apps were trashed and nowadays no one can do anything with it (but, [see](https://sqrl.grc.com/threads/developer-documentation-conflicted-and-confusing-please-help-clarify.951/), there are still people who love the protocol writing in a 90's forum with no clue of anything besides their own Java). * We don't need this, we need WebAuthn! [WebAuthn](https://webauthn.guide/) is essentially the same thing as lnurl-auth, but instead of being simple it is complex, instead of being open and decentralized it is centralized in big corporations, and instead of relying on a key generated by your own device it requires an expensive hardware HSM you must buy and trust the manufacturer. If you like WebAuthn and you like Bitcoin you should like lnurl-auth much more. * What about [BitID](https://github.com/bitid/bitid)? This is another one that is [very similar](https://www.youtube.com/watch?v=3eepEWTnRTc) to lnurl-auth, but without the anti-phishing prevention and extra privacy given by making one different key for each service. * What about LSAT? It doesn't compete with lnurl-auth. LSAT, as far as I understand it, is for when you're buying individual resources from a server, not authenticating as a user. Of course, LSAT can be repurposed as a general authentication tool, but then it will lack features that lnurl-auth has, like the property of having keys generated independently by the user from a common seed and a standard way of passing authentication info from one medium to another (like signing in to a website at the desktop from the mobile phone, for example).

@ 3bf0c63f:aefa459d

# A Causa o Princípios de Economia Política de Menger é o único livro que enfatiza a CAUSA o tempo todo. os cientistas todos parecem não saber, ou se esquecer sempre, que as coisas têm causa, e que o conhecimento verdadeiro é o conhecimento da causa das coisas. a causa é uma categoria metafísica muito superior a qualquer correlação ou resultado de teste de hipótese, ela não pode ser descoberta por nenhum artifício econométrico ou reduzida à simples antecedência temporal estatística. a causa dos fenômenos não pode ser provada cientificamente, mas pode ser conhecida. o livro de Menger conta para o leitor as causas de vários fenômenos econômicos e as interliga de forma que o mundo caótico da economia parece adquirir uma ordem no momento em que você lê. é uma sensação mágica e indescritível. quando eu te o recomendei, queria é te imbuir com o espírito da busca pela causa das coisas. depois de ler aquilo, você está apto a perceber continuidade causal nos fenômenos mais complexos da economia atual, enxergar as causas entre toda a ação governamental e as suas várias consequências na vida humana. eu faço isso todos os dias e é a melhor sensação do mundo quando o caos das notícias do caderno de Economia do jornal -- que para o próprio jornalista que as escreveu não têm nenhum sentido (tanto é que ele escreve tudo errado) -- se incluem num sistema ordenado de causas e consequências. provavelmente eu sempre erro em alguns ou vários pontos, mas ainda assim é maravilhoso. ou então é mais maravilhoso ainda quando eu descubro o erro e reinsiro o acerto naquela racionalização bela da ordem do mundo econômico que é a ordem de Deus. _em scrap para T.P._

@ 3bf0c63f:aefa459d

# Who will build the roads? Who will build the roads? Em Lagoa Santa, as mais novas e melhores ruas -- que na verdade acabam por formar enormes teias de bairros que se interligam -- são construídas pelos loteadores que querem as ruas para que seus lotes valham mais -- e querem que outras pessoas usem as ruas também. Também são esses mesmos loteadores que colocam os postes de luz e os encanamentos de água, não sem antes terem que se submeter a extorsões de praxe praticadas por COPASA e CEMIG. Se ao abrir um loteamento, condomínio, prédio um indivíduo ou uma empresa consegue sem muito problema passar rua, eletricidade, água e esgoto, por que não seria possível existir livre-concorrência nesses mercados? Mesmo aquela velha estória de que é ineficiente passar cabos de luz duplicados para que companhias elétricas possam competir já me parece bobagem.

@ 3bf0c63f:aefa459d

# Why IPFS cannot work, again Imagine someone comes up with a solution for P2P content-addressed data-sharing that involves storing all the files' contents in all computers of the network. That wouldn't work, right? Too much data, if you think this can work then you're a BSV enthusiast. Then someone comes up with the idea of not storing everything in all computers, but only some things on some computers, based on some algorithm to determine what data a node would store given its pubkey or something like that. Still wouldn't work, right? Still too much data no matter how much you spread it, but mostly incentives not aligned, would implode in the first day. Now imagine someone says they will do the same thing, but instead of storing the full contents each node would only store a pointer to where each data is actually available. Does that make it better? Hardly so. Still, you're just moving the problem. This is IPFS. Now you have less data on each computer, but on a global scale that is still a lot of data. No incentives. And now you have the problem of finding the data. First if you have some data you want the world to access you have to broadcast information about that, flooding the network -- and everybody has to keep doing this continuously for every single file (or shard of file) that is available. And then whenever someone wants some data they must find the people who know about that, which means they will flood the network with requests that get passed from peer to peer until they get to the correct peer. The more you force each peer to store the worse it becomes to run a node and to store data on behalf of others -- but the less your force each peer to store the more flooding you'll have on the global network, and the slower will be for anyone to actually get any file. --- But if everybody just saves everything to Infura or Cloudflare then it works, magic decentralized technology. ## Related - [How IPFS is broken](nostr:naddr1qqyxgdfsxvck2dtzqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c8y87ll)

@ 3bf0c63f:aefa459d

# How IPFS is broken I once fell for this talk about "content-addressing". It sounds very nice. You know a certain file exists, you know there are probably people who have it, but you don't know where or if it is hosted on a domain somewhere. With content-addressing you can just say "start" and the download will start. You don't have to care. Other magic properties that address common frustrations: webpages don't go offline, links don't break, valuable content always finds its way, other people will distribute your website for you, any content can be transmitted easily to people near you without anyone having to rely on third-party centralized servers. But you know what? Saying a thing is good doesn't automatically make it possible and working. For example: saying stuff is addressed by their content doesn't change the fact that the internet is "location-addressed" and you still have to know where peers that have the data you want are and connect to them. And what is the solution for that? A DHT! DHT? ---- Turns out DHTs have terrible incentive structure (as you would expect, no one wants to hold and serve data they don't care about to others for free) and the IPFS experience proves it doesn't work even in a small network like the IPFS of today. If you have run an IPFS client you'll notice how much it clogs your computer. Or maybe you don't, if you are very rich and have a really powerful computer, but still, it's not something suitable to be run on the entire world, and on web pages, and servers, and mobile devices. I imagine there may be a lot of unoptimized code and technical debt responsible for these and other problems, but the DHT is certainly the biggest part of it. IPFS can open up to 1000 connections by default and suck up all your bandwidth -- and that's just for exchanging keys with other DHT peers. Even if you're in the "client" mode and limit your connections you'll still get overwhelmed by connections that do stuff I don't understand -- and it makes no sense to run an IPFS node as a client, that defeats the entire purpose of making every person host files they have and content-addressability in general, centralizes the network and brings back the dichotomy client/server that IPFS was created to replace. Connections? ------------ So, DHTs are a fatal flaw for a network that plans to be big and interplanetary. But that's not the only problem. Finding content on IPFS is the _most slow experience ever_ and for some reason I don't understand downloading is even slower. Even if you are in the same LAN of another machine that has the content you need it will still take hours to download some small file you would do in seconds with `scp` -- that's considering that IPFS managed to find the other machine, otherwise your command will just be stuck for days. Now even if you ignore that IPFS objects should be content-addressable and not location-addressable and, knowing which peer has the content you want, you go there and explicitly tell IPFS to connect to the peer directly, maybe you can get some seconds of (slow) download, but then IPFS will drop the connection and the download will stop. Sometimes -- but not always -- it helps to add the peer address to your bootstrap nodes list (but notice this isn't something you should be doing at all). IPFS Apps? ---------- Now consider the kind of marketing IPFS does: it tells people to build "apps" on IPFS. It sponsors "databases" on top of IPFS. It basically advertises itself as a place where developers can just connect their apps to and all users will automatically be connected to each other, data will be saved somewhere between them all and immediately available, everything will work in a peer-to-peer manner. Except it doesn't work that way at all. "libp2p", the IPFS library for connecting people, is broken and is rewritten every 6 months, but they keep their beautiful landing pages that say everything works magically and you can just plug it in. I'm not saying they should have everything perfect, but at least they should be honest about what they truly have in place. It's impossible to connect to other people, after years there's no js-ipfs and go-ipfs interoperability (and yet they advertise there will be python-ipfs, haskell-ipfs, whoknowswhat-ipfs), connections get dropped and many other problems. So basically all IPFS "apps" out there are just apps that want to connect two peers but can't do it manually because browsers and the IPv4/NAT network don't provide easy ways to do it and WebRTC is hard and requires servers. They have nothing to do with "content-addressing" anything, they are not trying to build "a forest of merkle trees" nor to distribute or archive content so it can be accessed by all. I don't understand why IPFS has changed its core message to this "full-stack p2p network" thing instead of the basic content-addressable idea. IPNS? ----- And what about the database stuff? How can you "content-address" a database with values that are supposed to change? Their approach is to just save all values, past and present, and then use new DHT entries to communicate what are the newest value. This is the IPNS thing. Apparently just after coming up with the idea of content-addressability IPFS folks realized this would never be able to replace the normal internet as no one would even know what kinds of content existed or when some content was updated -- and they didn't want to coexist with the normal internet, they wanted to replace it all because this message is more bold and gets more funding, maybe? So they invented IPNS, the name system that introduces location-addressability back into the system that was supposed to be only content-addressable. And how do they manage to do it? Again, DHTs. And does it work? Not really. It's limited, slow, much slower than normal content-addressing fetches, most of the times it doesn't even work after hours. But still although developers will tell it is not working yet the IPFS marketing will talk about it as if it was a thing. Archiving content? ------------------ The main use case I had for IPFS was to store content that I personally cared about and that other people might care too, like old articles from dead websites, and videos, sometimes entire websites before they're taken down. So I did that. Over many months I've archived stuff on IPFS. The IPFS API and CLI don't make it easy to track where stuff are. The `pin` command doesn't help as it just throws your pinned hash in a sea of hashes and subhashes and you're never able to find again what you have pinned. The IPFS daemon has a fake filesystem that is half-baked in functionality but allows you to locally address things by names in a tree structure. Very hard to update or add new things to it, but still doable. It allows you to give names to hashes, basically. I even began to write a wrapper for it, but suddenly after many weeks of careful content curation and distribution all my entries in the fake filesystem were gone. Despite not having lost any of the files I _did_ lose everything, as I couldn't find them in the sea of hashes I had in my own computer. After some digging and help from IPFS developers I managed to recover a part of it, but it involved hacks. My things vanished because of a bug at the fake filesystem. The bug was fixed, but soon after I experienced a similar (new) bug. After that I even tried to build a service for hash archival and discovery, but as all the problems listed above began to pile up I eventually gave up. There were also problems of content canonicalization, the code the IPFS daemon use to serve default HTML content over HTTP, problems with the IPFS browser extension and others. Future-proof? ------------- One of the core advertised features of IPFS was that it made content future-proof. I'm not sure they used this expression, but basically you have content, you hash that, you get an address that never expires for that content, now everybody can refer to the same thing by the same name. Actually, it's better: content is split and hashed in a merkle-tree, so there's fine-grained deduplication, people can store only chunks of files and when a file is to be downloaded lots of people can serve it at the same time, like torrents. But then come the protocol upgrades. IPFS has used different kinds of hashing algorithms, different ways to format the hashes, and will change the default algorithm for building the merkle-trees, so basically the same content now has a gigantic number of possible names/addresses, which defeats the entire purpose, and yes, files hashed using different strategies aren't automagically compatible. Actually, the merkle algorithm could have been changed by each person on a file-by-file basis since the beginning (you could for example split a book file by chapter or page instead of by chunks of bytes) -- although probably no one ever did that. I know it's not easy to come up with the perfect hashing strategy in the first go, but the way these matters are being approached make me wonder that IPFS promoters aren't really worried about future-proof, or maybe we're just in Beta phase forever. Ethereum? --------- This is also a big problem. IPFS is built by Ethereum enthusiasts. I can't read the mind of people behind IPFS, but I would imagine they have a poor understanding of incentives like the Ethereum people, and they tend towards scammer-like behavior like getting a ton of funds for investors in exchange for promises they don't know they can fulfill (like Filecoin and IPFS itself) based on half-truths, changing stuff in the middle of the road because some top-managers decided they wanted to change (move fast and break things) and squatting fancy names like "distributed web". The way they market IPFS (which is not the main thing IPFS was initially designed to do) as a "peer-to-peer cloud" is very seductive for Ethereum developers just like Ethereum itself is: as a place _somewhere_ that will run your code for you so you don't have to host a server or have any responsibility, and then Infura will serve the content to everybody. In the same vein, Infura is also hosting and serving IPFS content for Ethereum developers these days for free. Ironically, just like the Ethereum hoax peer-to-peer money, IPFS peer-to-peer network may begin to work better for end users as things get more and more centralized. ### More about IPFS problems: * [IPFS problems: Too much immutability](nostr:naddr1qqyrqen9xf3nvdpeqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cmdjnnj) * [IPFS problems: General confusion](nostr:naddr1qqyr2wf4xvcrwvnyqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823chvx94h) * [IPFS problems: Shitcoinery](nostr:naddr1qqyxxdpev5cnsvpkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cta4a2e) * [IPFS problems: Community](nostr:naddr1qqyrxdmrvvengdmrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cekkch5) * [IPFS problems: Pinning](nostr:naddr1qqyrgvf3xcenydesqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c9ckstx) * [IPFS problems: Conceit](nostr:naddr1qqyxyeryx93kxv3nqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cwxek0q) * [IPFS problems: Inefficiency](nostr:naddr1qqyr2dp3vsmx2vpsqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ckklcy6) * [IPFS problems: Dynamic links](nostr:naddr1qqyrvcnx8y6nwwtpqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cz8tlwh) ### See also * [A crappy course on torrents](nostr:naddr1qqyrwdfevfjnxefcqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cuskhxf), on the protocol that has done most things right * [The Tragedy of IPFS in a series of links](https://mobile.twitter.com/fiatjaf/status/1289246273669697536), an ongoing Twitter thread.

@ 3bf0c63f:aefa459d

# Lagoa Santa: como chegar -- partindo da rodoviária de Belo Horizonte Ao descer de seu ônibus na rodoviária de Belo Horizonte às 4 e pouco da manhã, darás de frente para um caubói que toma cerveja em seus trajes típicos em um bar no setor mesmo de desembarque. Suba a escada à direita que dá no estacionamento da rodoviária. Vire à esquerda e caminhe por mais ou menos 400 metros, atravessando uma área onde pessoas suspeitas -- mas provavelmente dormindo em pé -- lhe observam, e então uma pracinha ocupada por um clã de mendigos. Ao avistar um enorme obelisco no meio de um cruzamento de duas avenidas, vire à esquerda e caminhe por mais 400 metros. Você verá uma enorme, antiga e bela estação com uma praça em frente, com belas fontes aqüáticas. Corra dali e dirija-se a um pedaço de rua à direita dessa praça. Um velho palco de antigos carnavais estará colocado mais ou menos no meio da simpática ruazinha de parelepípedos: é onde você pegará seu próximo ônibus. Para entrar na estação é necessário ter um cartão com créditos recarregáveis. Um viajante prudente deixa sempre um pouco de créditos em seu cartão a fim de evitar filas e outros problemas de indisponibilidade quando chega cansado de viagem, com pressa ou em horários incomuns. Esse tipo de pessoa perceberá que foi totalmente ludibriado ao perceber que que os créditos do seu cartão, abastecido quando de sua última vinda a Belo Horizonte, há três meses, pereceram de prazo de validade e foram absorvidos pelos cofre públicos. Terá, portanto, que comprar mais créditos. O guichê onde os cartões são abastecidos abre às 5h, mas não se espante caso ele não tenha sido aberto ainda quando o primeiro ônibus chegar, às 5h10. Com alguma sorte, um jovem de moletom, autorizado por dois ou três fiscais do sistema de ônibus que conversam alegremente, será o operador da catraca. Ele deixa entrar sem pagar os bêbados, os malandros, os pivetes. Bastante empático e perceptivo do desespero dos outros, esse bom rapaz provavelmente também lhe deixará entrar sem pagar. Uma vez dentro do ônibus, não se intimide com os gritalhões e valentões que, ofendidíssimos com o motorista por ele ter parado nas estações, depois dos ônibus anteriores terem ignorado esses excelsos passageiros que nelas aguardavam, vão aos berros tirar satisfação. O ponto final do ônibus, 40 minutos depois, é o terminal Morro Alto. Lá você verá, se procurar bem entre vários ônibus e pessoas que despertam a sua mais honesta suspeita, um veículo escuro, apagado, numerado **5882** e que abrigará em seu interior um motorista e um cobrador que descansam o sono dos justos. Aguarde na porta por mais uns vinte minutos até que, repentinamente desperto, o motorista ligue o ônibus, abra as portas e já comece, de leve, a arrancar. Entre correndo, mas espere mais um tempo, enquanto as pessoas que têm o cartão carregado passem e peguem os melhores lugares, até que o cobrador acorde e resolva te cobrar a passagem nesse velho meio de pagamento, outrora o mais líqüído, o dinheiro. Este último ônibus deverá levar-lhe, enfim, a Lagoa Santa.

@ 3bf0c63f:aefa459d

# Jofer Jofer era um jogador diferente. À primeira vista não, parecia igual, um volante combativo, perseguia os atacantes adversários implacavelmente, um bom jogador. Mas não era essa a característica que diferenciava Jofer. Jofer era, digamos, um chutador. Começou numa semifinal de um torneio de juniores. O time de Jofer precisava do empate e estava sofrendo uma baita pressão do adversário, mas o jogo estava 1 a 1 e parecia que ia ficar assim mesmo, daquele jeito futebolístico que parece, parece mesmo. Só que aos 46 do segundo tempo tomaram um gol espírita, Ruizinho do outro time saiu correndo pela esquerda e, mesmo sendo canhoto, foi cortando para o meio, os zagueiros meio que achando que já tinha acabado mesmo, devia ter só mais aquele lance, o árbitro tinha dado dois minutos, Ruizinho chutou, marcou e o goleiro, que só pulou depois que já tinha visto que não ia ter jeito, ficou xingando. A bola saiu do meio e tocaram para Jofer, ninguém nem veio marcá-lo, o outro time já estava comemorando, e com razão, o juiz estava de sacanagem em fazer o jogo continuar, já estava tudo acabado mesmo. Mas não, estava certo, mais um minuto de acréscimo, justo. Em um minuto dá pra fazer um gol. Mas como? Jofer pensou nas partidas da NBA em que com alguns centésimos de segundo faltando o armador jogava de qualquer jeito para a cesta e às vezes acertava. De trás do meio de campo, será? Não vou ter nem força pra fazer chegar no gol. Vou virar piada, melhor tocar pro Fumaça ali do lado e a gente perde sem essa humilhação no final. Mas, poxa, e daí? Vou tentar mesmo assim, qualquer coisa eu falo que foi um lançamento e daqui a uns dias todo mundo esquece. Olhou para o próprio pé, virou ele de ladinho, pra fora e depois pra dentro (bom, se eu pegar daqui, direitinho, quem sabe?), jogou a bola pro lado e bateu. A bola subiu escandalosamente, muito alta mesmo, deve ter subido uns 200 metros. Jofer não tinha como ter a menor noção. Depois foi descendo, o goleirão voltando correndo para debaixo da trave e olhando pra bola, foi chegando e pulando já só pra acompanhar, para ver, dependurado no travessão, a bola sair ainda bem alta, ela bateu na rede lateral interna antes de bater no chão, quicar violentamente e estufar a rede no alto do lado direito de quem olhava. Mas isso tudo foi sonho do Jofer. Sonhou acordado, numa noite em que demorou pra dormir, deitado na sua cama. Ficou pensando se não seria fácil, se ele treinasse bastante, acertar o gol bem de longe, tipo no sonho, e se não dava pra fazer gol assim. No dia seguinte perguntou a Brunildinho, o treinador de goleiros. Era difícil defender essas bolas, ainda mais se elas subissem muito, o goleiro ficava sem perspectiva, o vento alterava a trajetória a cada instante, tinha efeito, ela cairia rápido, mas claro que não valia à pena treinar isso, a chance de acertar o gol era minúscula. Mas Jofer só ia tentar depois que treinasse bastante e comprovasse o que na sua imaginação parecia uma excelente idéia. Começou a treinar todos os dias. Primeiro escondido, por vergonha dos colegas, chegava um pouco antes e ficava lá, chutando do círculo central. Ao menor sinal de gente se aproximando, parava e ia catar as bolas. Depois, quando começou a acertar, perdeu a vergonha. O pessoal do clube todo achava engraçado quando via Jofer treinando e depois ouvia a explicação da boca de alguém, ninguém levava muito a sério, mas também não achava de todo ridículo. O pessoal ria, mas no fundo torcia praquilo dar certo, mesmo. Aconteceu que num jogo que não valia muita coisa, empatezinho feio, aos 40 do segundo tempo, a marcação dos adversários já não estava mais pressionando, todo mundo contente com o empate e com vontade de parar de jogar já, o Henrique, meia-esquerdo, humilde, mas ainda assim um pouco intimidante para Jofer (jogava demais), tocou pra ele. Vai lá, tenta sua loucura aí. Assumiu a responsabilidade do nosso volante introspectivo. Seria mais verossímil se Jofer tivesse errado, primeira vez que tentou, restava muito tempo ainda pra ele ter a chance de ser herói, ninguém acerta de primeira, mas ele acertou. Quase como no sonho, Lucas, o goleiro, não esperava, depois que viu o lance, riu-se, adiantou-se para pegar a bola que ele julgava que quicaria na área, mas ela foi mais pra frente, mais e mais, daí Lucas já estava correndo, só que começou a pensar que ela ia pra fora, e ele ia só se dependurar no travessão e fazer seu papel de estar na bola. Acabou que por conta daquele gol eles terminaram em segundo no grupo daquele torneiozinho, ao invés de terceiro, e não fez diferença nenhuma.

@ 3bf0c63f:aefa459d

# My personal experience (as a complete ignorant) of the blocksize debate in 2017 In the beginning of 2017 I didn't know Bitcoin was having a "blocksize debate". I had stopped paying attention to Bitcoin in 2014 after reading Tim Swanson's book on shitcoineiry and was surprise people even care about Bitcoin still while Ethereum and other fancy things were around. My introduction to the subject was this interview with Andrew Stone and Andrew Clifford from Bitcoin Unlimited (still don't know who these guys are). I've listened to it and kinda liked the conspiracy theory about "a group of developers trying, against miners and users, to control the whole ecosystem by not allowing blocks to grow" (actually, if you listen to this interview that announced the creation of Blockstream and the sidechains whitepaper it does sound like a government agent bribing all the Core developers into forming a consortium that will turn Bitcoin into an Ethereum-like shitcoin under their control -- but this is just a useless digression). Some time later I listened to this interview with Jimmy Song and was introduced to two hard forks and conspiracies and New York Agreement and got excited because I didn't care about Bitcoin (I'm ashamed to remember this feeling) and wanted to see things changing, people fighting, Bitcoin burning, for no reason. Oddly, what I grasped from the interview was that Jimmy Song was defending the agreement and expecting everybody to fulfill it. When the day actually come and "Bitcoin Cash" forked I looked at it with pity because it looked clearly a failure from the beginning, but I still cheered for it a bit, still not knowing anything about the debate, besides the fact that blocks were bigger on BCH, which looked like a very reductionist explanation to me. "Of course it's not just making blocks bigger, that would be too simple, they probably have a very complex plan I'm not apt to understand", I thought. To my surprise the entire argument was actually just that: bigger blocks bigger blocks. I came to that conclusion by listening to tomwoods.com/1064, a debate in which reasonable arguments faced childish claims. That debate gave me perspective and was a clear, undisputed win from Jameson Lopp against Roger Ver. Actually some time before that I had listened to another Tom Woods Show episode thinking it was going to be an episode about Bitcoin, but in fact it was just propaganda about a debate I had almost forgotten. And nothing about Bitcoin, everything about "Bitcoin Cash" and how there were two Bitcoins, one legitimate and the other unlegitimate. So, from the perspective of someone that came to the debate totally fresh and only listens to the big-blocker arguments for a long time, they still don't convince anyone with some common sense (as I would like to think of myself), they just sound like mad dogs and everything goes against themselves. --- Fast forward to the present and with much more understanding of the issues in place I started digging some material from 2016-2017 about the debate to try to get more context, and found this ridiculous interview with Mike Hearn. It isn't a waste of time to listen to it if you're not familiar with the debate from that time. As I should have probably expected from my experience with Epicenter.tv, both the interviewers agree with Mike Hearn about his ridiculous claims about how (not his words) we have to subsidize the few thousand current Bitcoin users by preventing fees from increase and there are no trade-offs to doing that -- and even with everybody agreeing they all manage to sound stupid. There's not a single phrase that is defendable in the entire interview, no criticisms make any sense, it makes me feel bad for the the guy as he feels so self-assured and obviouslyright. After knowing about these and other adventures of stupid people with high influences in the Bitcoin world trying to impose their idiocy on others it feels even more odd and unexpected to find Bitcoin in the right track. Generally in politics the most dumb wins, but apparently not in Bitcoin. Bitcoin is a miracle.

@ 3bf0c63f:aefa459d

# idea: Per-paragraph paywalls Using the lnurl-allowance protocol, a website could instead of putting a paywall over the entire site, charge a reader for only the paragraphs they read. Of course this requires trust from the reader on the website, but this is normal. The website could just hide the rest of the article before an invoice from the paragraph just read was paid. This idea came from Colin from the _Unhashed Podcast_. Could also work with podcasts and videos.

@ 3bf0c63f:aefa459d

# Thoughts on Nostr key management On [Why I don't like NIP-26 as a solution for key management](nostr:naddr1qqyrgceh89nxgdmzqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ctgmx78) I talked about multiple techniques that could be used to tackle the problem of key management on Nostr. Here are some ideas that work in tandem: - [NIP-41](https://github.com/nostr-protocol/nips/blob/master/41.md) (stateless key invalidation) - [NIP-46](https://github.com/nostr-protocol/nips/blob/master/46.md) (Nostr Connect) - [NIP-07](https://github.com/nostr-protocol/nips/blob/master/07.md) (signer browser extension) - [Connected hardware signing devices](https://lnbits.github.io/nostr-signing-device/installer/) - other things like musig or frostr keys used in conjunction with a semi-trusted server; or other kinds of trusted software, like a dedicated signer on a mobile device that can sign on behalf of other apps; or even a separate protocol that some people decide to use as the source of truth for their keys, and some clients might decide to use that automatically - there are probably many other ideas Some premises I have in my mind (that may be flawed) that base my thoughts on these matters (and cause me to not worry too much) are that - For the vast majority of people, Nostr keys aren't a target as valuable as Bitcoin keys, so they will probably be ok even without any solution; - Even when you lose everything, identity can be recovered -- slowly and painfully, but still --, unlike money; - Nostr is not trying to replace all other forms of online communication (even though when I think about this I can't imagine one thing that wouldn't be nice to replace with Nostr) or of offline communication, so there will always be ways. - For the vast majority of people, losing keys and starting fresh isn't a big deal. It is a big deal when you have followers and an online persona and your life depends on that, but how many people are like that? In the real world I see people deleting social media accounts all the time and creating new ones, people losing their phone numbers or other accounts associated with their phone numbers, and not caring very much -- they just find a way to notify friends and family and move on. We can probably come up with some specs to ease the "manual" recovery process, like social attestation and explicit signaling -- i.e., Alice, Bob and Carol are friends; Alice loses her key; Bob sends a new Nostr event kind to the network saying what is Alice's new key; depending on how much Carol trusts Bob, she can automatically start following that and remove the old key -- or something like that. --- One nice thing about some of these proposals, like NIP-41, or the social-recovery method, or the external-source-of-truth-method, is that they don't have to be implemented in any client, they can live in standalone single-purpose microapps that users open or visit only every now and then, and these can then automatically update their follow lists with the latest news from keys that have changed according to multiple methods.

@ 3bf0c63f:aefa459d

# IPFS problems: Shitcoinery IPFS was advertised to the Ethereum community since the beggining as a way to "store" data for their "dApps". I don't think this is harmful in any way, but for some reason it may have led IPFS developers to focus too much on Ethereum stuff. Once I watched a talk showing libp2p developers – despite being ignored by the Ethereum team (that ended up creating their own agnostic p2p library) – dedicating an enourmous amount of work on getting a libp2p app running in the browser talking to a normal Ethereum node. The always somewhat-abandoned "Awesome IPFS" site is a big repository of "dApps", some of which don't even have their landing page up anymore, useless Ethereum smart contracts that for some reason use IPFS to store whatever the useless data their users produce. Again, per se it isn't a problem that Ethereum people are using IPFS, but it is at least confusing, maybe misleading, that when you search for IPFS most of the use-cases are actually Ethereum useless-cases. ## See also * [Bitcoin](nostr:naddr1qqyryveexumnyd3kqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c7nywz4), the only non-shitcoin

@ 3bf0c63f:aefa459d

# rosetta.alhur.es A service that grabs code samples from two chosen languages on [RosettaCode](http://rosettacode.org/wiki/Rosetta_Code) and displays them side-by-side. The code-fetching is done in real time and snippet-by-snippet (there is also a prefetch of which snippets are available in each language, so we only compare apples to apples). This was my first Golang web application if I remember correctly. - <https://rosetta.alhur.es/> - <https://github.com/fiatjaf/rosetta.alhur.es>

@ 3bf0c63f:aefa459d

# SummaDB This was a hierarchical database server similar to the original Firebase. Records were stored on a LevelDB on different paths, like: - `/fruits/banana/color`: `yellow` - `/fruits/banana/flavor`: `sweet` And could be queried by path too, using HTTP, for example, a call to `http://hostname:port/fruits/banana`, for example, would return a JSON document like ```json { "color": "yellow", "flavor": "sweet" } ``` While a call to `/fruits` would return ```json { "banana": { "color": "yellow", "flavor": "sweet" } } ``` `POST`, `PUT` and `PATCH` requests also worked. In some cases the values would be under a special `"_val"` property to disambiguate them from paths. (I may be missing some other details that I forgot.) GraphQL was also supported as a query language, so a query like ```graphql query { fruits { banana { color } } } ``` would return `{"fruits": {"banana": {"color": "yellow"}}}`. ## SummulaDB SummulaDB was a browser/JavaScript build of SummaDB. It ran on the same Go code compiled with GopherJS, and using PouchDB as the storage backend, if I remember correctly. It had replication between browser and server built-in, and one could replicate just subtrees of the main tree, so you could have stuff like this in the server: ```json { "users": { "bob": {}, "alice": {} } } ``` And then only allow Bob to replicate `/users/bob` and Alice to replicate `/users/alice`. I am sure the require auth stuff was also built in. There was also a PouchDB plugin to make this process smoother and data access more intuitive (it would hide the `_val` stuff and allow properties to be accessed directly, today I wouldn't waste time working on these hidden magic things). ## The computed properties complexity The next step, which I never managed to get fully working and caused me to give it up because of the complexity, was the ability to automatically and dynamically compute materialized properties based on data in the tree. The idea was partly inspired on CouchDB computed views and how limited they were, I wanted a thing that would be super powerful, like, given ```json { "matches": { "1": { "team1": "A", "team2": "B", "score": "2x1", "date": "2020-01-02" }, "1": { "team1": "D", "team2": "C", "score": "3x2", "date": "2020-01-07" } } } ``` One should be able to add a computed property at `/matches/standings` that computed the scores of all teams after all matches, for example. I tried to complete this in multiple ways but they were all adding much more complexity I could handle. Maybe it would have worked better on a more flexible and powerful and functional language, or if I had more time and patience, or more people. ## Screenshots This is just one very simple unfinished admin frontend client view of the hierarchical dataset.  - https://github.com/fiatjaf/summadb - https://github.com/fiatjaf/summuladb - https://github.com/fiatjaf/pouch-summa

@ 3bf0c63f:aefa459d

# Parallel Chains We want merged-mined blockchains. We want them because it is possible to do things in them that aren't doable in the normal Bitcoin blockchain because it is rightfully too expensive, but there are other things beside the world money that could benefit from a "distributed ledger" -- just like people believed in 2013 --, like issued assets and domain names (just the most obvious examples). On the other hand we can't have -- like people believed in 2013 -- a copy of Bitcoin for every little idea with its own native token that is mined by proof-of-work and must get off the ground from being completely valueless into having some value by way of a miracle that operated only once with Bitcoin. It's also not a good idea to have blockchains with custom merged-mining protocol (like Namecoin and Rootstock) that require Bitcoin miners to run their software and be an active participant and miner for that other network besides Bitcoin, because it's too cumbersome for everybody. Luckily [Ruben Somsen invented this protocol for blind merged-mining](https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5) that solves the issue above. Although it doesn't solve the fact that each parallel chain still needs some form of "native" token to pay miners -- or it must use another method that doesn't use a native token, such as trusted payments outside the chain. ## How does it work With the `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT` soft-fork[^eltoo] it becomes possible to create presigned transactions that aren't related to any previous UTXO. Then you create a long sequence of transactions (sufficient to last for many many years), each with an `nLockTime` of 1 and each spending the next (you create them from the last to the first). Since their `scriptSig` (the unlocking script) will use `SIGHASH_ANYPREVOUT` you can obtain a transaction id/hash that doesn't include the previous TXO, you can, for example, in a sequence of transactions `A0-->B` (B spends output 0 from A), include the signature for "spending A0 on B" inside the `scriptPubKey` (the locking script) of "A0". With the contraption described above it is possible to make that long string of transactions everybody will know (and know how to generate) but each transaction can only be spent by the next previously decided transaction, no matter what anyone does, and there always must be at least one block of difference between them. Then you combine it with `RBF`, `SIGHASH_SINGLE` and `SIGHASH_ANYONECANPAY` so parallel chain miners can add inputs and outputs to be able to compete on fees by including their own outputs and getting change back while at the same time writing a hash of the parallel block in the change output and you get everything working perfectly: everybody trying to spend the same output from the long string, each with a different parallel block hash, only the highest bidder will get the transaction included on the Bitcoin chain and thus only one parallel block will be mined. ## See also - [Drivechain](nostr:naddr1qq9xgunfwejkx6rpd9hqzythwden5te0ve5kzar2v9nzucm0d5pzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqr4gumtjfnp) [^eltoo]: The same thing used in [Eltoo](nostr:naddr1qqyxvenyvejnwdejqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c6qlqxc).

@ 3bf0c63f:aefa459d

# Criteria for activating Drivechain on Bitcoin [Drivechain](nostr:naddr1qq9xgunfwejkx6rpd9hqzythwden5te0ve5kzar2v9nzucm0d5pzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqr4gumtjfnp) is, in essence, just a way to give Bitcoin users the option to deposit their coins in a hashrate escrow. If Bitcoin is about coin ownership, in theory there should be no objection from anyone on users having the option to do that: my keys, my coins etc. In other words: even if you think hashrate escrows are a terrible idea and miners will steal all coins from that, you shouldn't care about what other people do with their own money. There are only two reasonable objections that could be raised by normal Bitcoin users against Drivechain: 1. Drivechain adds code complexity to `bitcoind` 2. Drivechain perverts miner incentives of the Bitcoin chain If these two objections can be reasonably answered there remains no reason for not activating the Drivechain soft-fork. ## 1 To address **1** we can just take a look at the code once it's done (which I haven't) but from my understanding the extra validation steps needed for ensuring hashrate escrows work are very minimal and self-contained, they shouldn't affect anything else and the risks of introducing some catastrophic bug are roughly zero (or the same as the risks of any of the dozens of refactors that happen every week on Bitcoin Core). For the BMM/BIP-301 part, again the surface is very small, but we arguably do not need that at all, since [anyprevout](https://anyprevout.xyz/) (once that is merged) enables blind merge-mining in way that is probably better than BIP-301, and that soft-fork is also very simple, plus already loved and accepted by most of the Bitcoin community, implemented and reviewed on Bitcoin Inquisition and is live on the official Bitcoin Core signet. ## 2 To address **2** we must only point that BMM ensures that Bitcoin miners don't have to do any extra work to earn basically all the fees that would come from the sidechain, as competition for mining sidechain blocks would bid the fee paid to Bitcoin miners up to the maximum economical amount. It is irrelevant if there is MEV on the sidechain or not, everything that reaches the Bitcoin chain does that in form of fees paid in a single high-fee transaction paid to any Bitcoin miner, regardless of them knowing about the sidechain or not. Therefore, there are no centralization pressure or pervert mining incentives that can affect Bitcoin land. Sometimes it's argued that Drivechain may facilitate the ocurrence of a transaction paying a fee so high it would create incentives for reorging the Bitcoin chain. There is no reason to believe Drivechain would make this more likely than an actual attack than anyone can already do today or, as has happened, some rich person typing numbers wrong on his wallet. In fact, if a drivechain is consistently paying high fees on its BMM transactions that is an incentive for Bitcoin miners to keep mining those transactions one after the other and not harm the users of sidechain by reorging Bitcoin. Moreover, there are many factors that exist today that can be seen as centralization vectors for Bitcoin mining: arguably one of them is non-blind merge mining, of which we have [a (very convoluted) example on the Stacks shitcoin](https://twitter.com/fiatjaf/status/1684171939298803712), and introducing the possibility of blind merge-mining on Bitcoin would basically remove any reasonable argument for having such schemes, therefore reducing the centralizing factor of them.

@ 3bf0c63f:aefa459d

# idea: Custom multi-use database app Since 2015 I have this idea of making one app that could be repurposed into a full-fledged app for all kinds of uses, like powering small businesses accounts and so on. Hackable and open as an Excel file, but more efficient, without the hassle of making tables and also using ids and indexes under the hood so different kinds of things can be related together in various ways. It is not a concrete thing, just a generic idea that has taken multiple forms along the years and may take others in the future. I've made quite a few attempts at implementing it, but never finished any. I used to refer to it as a "multidimensional spreadsheet". Can also be related to [DabbleDB][dabble-db]. [dabble-db]: <https://en.wikipedia.org/wiki/Dabble_DB>

@ 3bf0c63f:aefa459d

# `OP_CHECKTEMPLATEVERIFY` and the "covenants" drama There are many ideas for "covenants" (I don't think this concept helps in the specific case of examining proposals, but fine). Some people think "we" (it's not obvious who is included in this group) should somehow examine them and come up with the perfect synthesis. It is not clear what form this magic gathering of ideas will take and who (or which ideas) will be allowed to speak, but suppose it happens and there is intense research and conversations and people (ideas) really enjoy themselves in the process. What are we left with at the end? Someone has to actually commit the time and put the effort and come up with a concrete proposal to be implemented on Bitcoin, and whatever the result is it will have trade-offs. Some great features will not make into this proposal, others will make in a worsened form, and some will be contemplated very nicely, there will be some extra costs related to maintenance or code complexity that will have to be taken. Someone, a concreate person, will decide upon these things using their own personal preferences and biases, and many people will not be pleased with their choices. That has already happened. Jeremy Rubin has already conjured all the covenant ideas in a magic gathering that lasted more than 3 years and came up with a synthesis that has the best trade-offs he could find. CTV is the result of that operation. --- The fate of CTV in the popular opinion illustrated by the thoughtless responses it has evoked such as "can we do better?" and "we need more review and research and more consideration of other ideas for covenants" is a preview of what would probably happen if these suggestions were followed again and someone spent the next 3 years again considering ideas, talking to other researchers and came up with a new synthesis. Again, that person would be faced with "can we do better?" responses from people that were not happy enough with the choices. And unless some famous Bitcoin Core or retired Bitcoin Core developers were personally attracted by this synthesis then they would take some time to review and give their blessing to this new synthesis. To summarize the argument of this article, the actual question in the current CTV drama is that there exists hidden criteria for proposals to be accepted by the general community into Bitcoin, and no one has these criteria clear in their minds. It is not as simple not as straightforward as "do research" nor it is as humanly impossible as "get consensus", it has a much bigger social element into it, but I also do not know what is the exact form of these hidden criteria. This is said not to blame anyone -- except the ignorant people who are not aware of the existence of these things and just keep repeating completely false and unhelpful advice for Jeremy Rubin and are not self-conscious enough to ever realize what they're doing.

@ 3bf0c63f:aefa459d

# A response to Achim Warner's "Drivechain brings politics to miners" article I mean this article: https://achimwarner.medium.com/thoughts-on-drivechain-i-miners-can-do-things-about-which-we-will-argue-whether-it-is-actually-a5c3c022dbd2 There are basically two claims here: ### 1. Some corporate interests might want to secure sidechains for themselves and thus they will bribe miners to have these activated First, it's hard to imagine why they would want such a thing. Are they going to make a proprietary KYC chain only for their users? They could do that in a corporate way, or with a federation, like Facebook tried to do, and that would provide more value to their users than a cumbersome pseudo-decentralized system in which they don't even have powers to issue currency. Also, if Facebook couldn't get away with their federated shitcoin because the government was mad, what says the government won't be mad with a sidechain? And finally, why would Facebook want to give custody of their proprietary closed-garden Bitcoin-backed ecosystem coins to a random, open and always-changing set of miners? But even if they do succeed in making their sidechain and it is very popular such that it pays miners fees and people love it. Well, then why not? Let them have it. It's not going to hurt anyone more than a proprietary shitcoin would anyway. If Facebook really wants a closed ecosystem backed by Bitcoin that probably means we are winning big. ### 2. Miners will be required to vote on the validity of debatable things He cites the example of a PoS sidechain, an assassination market, a sidechain full of nazists, a sidechain deemed illegal by the US government and so on. There is a simple solution to all of this: just kill these sidechains. Either miners can take the money from these to themselves, or they can just refuse to engage and freeze the coins there forever, or they can even give the coins to governments, if they want. It is an entirely good thing that evil sidechains or sidechains that use horrible technology that doesn't even let us know who owns each coin get annihilated. And it was the responsibility of people who put money in there to evaluate beforehand and know that PoS is not deterministic, for example. About government censoring and wanting to steal money, or criminals using sidechains, I think the argument is very weak because these same things can happen today and may even be happening already: i.e., governments ordering mining pools to not mine such and such transactions from such and such people, or forcing them to reorg to steal money from criminals and whatnot. All this is expected to happen in normal Bitcoin. But both in normal Bitcoin and in Drivechain decentralization fixes that problem by making it so governments cannot catch all miners required to control the chain like that -- and in fact fixing that problem is the only reason we need decentralization.

@ 3bf0c63f:aefa459d

# On HTLCs and arbiters This is another attempt and conveying the same information that should be in [Lightning and its fake HTLCs](nostr:naddr1qqyryefsxqcxgdmzqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cp0m63a). It assumes you know everything about Lightning and will just highlight a point. This is also valid for PTLCs. The protocol says HTLCs are trimmed (i.e., not actually added to the commitment transaction) when the cost of redeeming them in fees would be greater than their actual value. Although this is often dismissed as a non-important fact (often people will say "it's trusted for small payments, no big deal"), but I think it is indeed very important for 3 reasons: 1. Lightning absolutely relies on HTLCs actually existing because the payment proof requires them. The entire security of each payment comes from the fact that the payer has a preimage that comes from the payee. Without that, the state of the payment becomes an unsolvable mystery. The inexistence of an HTLC breaks the atomicity between the payment going through and the payer receiving a proof. 2. Bitcoin fees are expected to grow with time (arguably the reason Lightning exists in the first place). 3. MPP makes payment sizes shrink, therefore more and more of Lightning payments are to be trimmed. As I write this, the mempool is clear and still payments smaller than about 5000sat are being trimmed. Two weeks ago the limit was at 18000sat, which is already below the minimum most MPP splitting algorithms will allow. Therefore I think it is important that we come up with a different way of ensuring payment proofs are being passed around in the case HTLCs are trimmed. ## Channel closures Worse than not having HTLCs that can be redeemed is the fact that in the current Lightning implementations channels will be closed by the peer once an HTLC timeout is reached, either to fulfill an HTLC for which that peer has a preimage or to redeem back that expired HTLCs the other party hasn't fulfilled. For the surprise of everybody, nodes will do this even when the HTLCs in question were trimmed and therefore cannot be redeemed at all. It's very important that nodes stop doing that, because it makes no economic sense at all. However, that is not so simple, because once you decide you're not going to close the channel, what is the next step? Do you wait until the other peer tries to fulfill an expired HTLC and tell them you won't agree and that you must cancel that instead? That could work sometimes if they're honest (and they have no incentive to not be, in this case). What if they say they tried to fulfill it before but you were offline? Now you're confused, you don't know if you were offline or they were offline, or if they are trying to trick you. Then unsolvable issues start to emerge. ## Arbiters One simple idea is to use trusted arbiters for all trimmed HTLC issues. This idea solves both the protocol issue of getting the preimage to the payer once it is released by the payee -- and what to do with the channels once a trimmed HTLC expires. A simple design would be to have each node hardcode a set of trusted other nodes that can serve as arbiters. Once a channel is opened between two nodes they choose one node from both lists to serve as their mutual arbiter for that channel. Then whenever one node tries to fulfill an HTLC but the other peer is unresponsive, they can send the preimage to the arbiter instead. The arbiter will then try to contact the unresponsive peer. If it succeeds, then done, the HTLC was fulfilled offchain. If it fails then it can keep trying until the HTLC timeout. And then if the other node comes back later they can eat the loss. The arbiter will ensure they know they are the ones who must eat the loss in this case. If they don't agree to eat the loss, the first peer may then close the channel and blacklist the other peer. If the other peer believes that both the first peer and the arbiter are dishonest they can remove that arbiter from their list of trusted arbiters. The same happens in the opposite case: if a peer doesn't get a preimage they can notify the arbiter they hadn't received anything. The arbiter may try to ask the other peer for the preimage and, if that fails, settle the dispute for the side of that first peer, which can proceed to fail the HTLC is has with someone else on that route.

@ 3bf0c63f:aefa459d

# "Você só aprendeu mesmo uma coisa quando consegue explicar para os outros" Mentira. Tá certo que existe um ponto em que você acha que sabe algo mas não consegue explicar, mas não necessariamente isso significa não saber. Conseguir explicar não depende de saber, mas de verbalizar. Podemos saber muitas coisas sem as conseguir verbalizar. Aliás, para a maior parte das experiências humanas verbalizar é que é a parte difícil. Por último, é importante dizer que a verbalização é uma abstração e portanto quando alguém tenta explicar algo e se força a fazer uma abstração está arriscando substituir a experiência concreta ou mesmo o conhecimento difuso de algo por aquela abstração e com isso ficar mais burro -- me parece que esse é risco é maior quanto mais prematura for a tentativa de explicação e quando mais sucesso a abstração improvisada fizer.

@ 3bf0c63f:aefa459d

# neuron.vim I started using this [neuron][neuron] thing to create an update this same [zettelkasten](nostr:naddr1qqyrwwfh8yurgefnqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c7qmjrw), but the [existing vim plugin](https://github.com/ihsanturk/neuron.vim) had too many problems, so I forked it and ended up changing almost everything. Since the upstream repository was somewhat abandoned, most users and people who were trying to contribute upstream migrate to my fork too. - <https://github.com/fiatjaf/neuron.vim> [neuron]: https://github.com/srid/neuron

@ 3bf0c63f:aefa459d

# Flowi.es At the time I thought [Workflowy][workflowy] had the ideal UI for everything. I wanted to implement my [custom app maker](nostr:naddr1qqyxgcejv5unzd33qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cz3va32) on it, but ended up doing this: a platform for enhancing Workflowy with extra features: - An email reminder based on dates input in items - A website generator, similar to [Websites For Trello](nostr:naddr1qqyrydpkvverwvehqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c9d4yku), also based on [Classless Templates](nostr:naddr1qqyxyv35vymk2vfsqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cqwgdau) Also, I didn't remember this was also based on CouchDB and had some _couchapp_ functionalities.  - <https://flowi.es> - <https://github.com/fiatjaf/flowies> [workflowy]: <https://workflowy.com/>

@ 3bf0c63f:aefa459d

# Multi-service Graph Reputation protocol ## The problem 1. Users inside centralized services need to know reputations of other users they're interacting with; 2. Building reputation with ratings imposes a big burden on the user and still accomplishes nothing, can be faked, no one cares about these ratings etc. ## The ideal solution Subjective reputation: reputation based on how you rated that person previously, and how other people you trust rated that person, and how other people trusted by people you trust rated that person and so on, in a web-of-trust that actually can give you some insight on the trustworthiness of someone you never met or interacted with. ## The problem with the ideal solution 1. Most of the times the service that wants to implement this is not as big as Facebook, so it won't have enough people in it for such graphs of reputation to be constructed. 2. It is not trivial to build. ## My proposed solution: I've drafted a protocol for an open system based on services publishing their internal reputation records and indexers using these to build graphs, and then serving the graphs back to the services so they can show them to users when it is needed (as HTTP APIs that can be called directly from the user client app or browser). Crucially, these indexers will gather data from multiple services and cross-link users from these services so the graph is better. <https://github.com/fiatjaf/multi-service-reputation-rfc> The first and single actionable and useful feedback I got, from [@bootstrapbandit](https://twitter.com/bootstrapbandit) was that services shouldn't share email addresses in plain text (email addresses and other external relationships users of a service may have are necessary to establish links from users accross services), but I think it is ok if services publish hashes of these email addresses instead. At some point I will update the spec draft and that may have been before the time you're reading this. Another issue is that services may lie about their reputation records and that will hurt other services and users in these other services that are relying on that data. Maybe indexers will have to do some investigative job here to assert service honesty. Or maybe this entire protocol is just failed and we will actually need a system in which users themselves will publish their own records. ## See also * [P2P reputation thing](nostr:naddr1qqyrqv3cxumnydfsqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cnjc88q) * [idea: Graph subjective reputation as a service](nostr:naddr1qqyrjdehxymrsdpkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cal60d8) * <https://github.com/jangerritharms/reputation_systems>

@ 3bf0c63f:aefa459d

# Module Linker  A browser extension that reads source code on GitHub and tries to find links to imported dependencies so you can click on them and navigate through either GitHub or package repositories or base language documentation. Works for many languages at different levels of completeness. - <https://github.com/fiatjaf/module-linker> - <https://module-linker.alhur.es/> - <https://addons.mozilla.org/firefox/addon/module-linker> - <https://chrome.google.com/webstore/detail/dglofghjinifeolcpjfjmfdnnbaanggn>

@ 3bf0c63f:aefa459d

# Splitpages The simplest possible service: it splitted PDF pages in half. Created specially to solve the problem of those scanned books that come with two pages side-by-side as if they were a single page and are much harder to read on Kindle because of that.  It required me to learn about Heroku Buildpacks though, and fork or contribute to a Heroku Buildpack that embedded a [mupdf][mupdf] binary. - <https://github.com/fiatjaf/splitpages> - <https://splitpages.herokuapp.com/> [mupdf]: <https://mupdf.com/>

@ 3bf0c63f:aefa459d

# Just malinvestiment Traditionally the Austrian Theory of Business Cycles has been explained and reworked in many ways, but the most widely accepted version (or the closest to the Mises or Hayek views) view is that banks (or the central bank) cause the general interest rate to decline by creation of new money and that prompts entrepreneurs to invest in projects of longer duration. This can be confusing because sometimes entrepreneurs embark in very short-time projects during one of these bubbles and still contribute to the overall cycle. The solution is to think about the "longer term" problem is to think of the entire economy going long-term, not individual entrepreneurs. So if one entrepreneur makes an investiment in a thing that looks simple he may actually, knowingly or not, be inserting himself in a bigger machine that is actually involved in producing longer-term things. Incidentally this thinking also solves the biggest criticism of the Austrian Business Cycle Theory: that of the rational expectations people who say: "oh but can't the entrepreneurs know that the interest rate is artificially low and decide to not make long-term investiments?" ("and if they don't know they should lose money and be replaced like in a normal economy flow blablabla?"). Well, the answer is that they are not really relying on the interest rate, they are only looking for profit opportunities, and this is the key to another confusion that has always followed my thinkings about this topic. If a guy opens a bar in an area of a town where many new buildings are being built during a "housing bubble" he may not know, but he is inserting himself right into the eye of that business cycle. He expects all these building projects to continue, and all the people involved in that to be getting paid more and be able to spend more at his bar and so on. That is a bet that may or may not end up paying. Now what does that bar investiment has to do with the interest rate? Nothing. It is just a guy who saw a business opportunity in a place where hungry people with money had no bar to buy things in, so he opened a bar. Additionally the guy has made some calculations about all the ending, starting and future building projects in the area, and then the people that would live or work in that area afterwards (after all the buildings were being built with the expectation of being used) and so on, there is no interest rate calculations involved. And yet that may be a malinvestiment because some building projects will end up being canceled and the expected usage of the finished ones will turn out to be smaller than predicted. This bubble may have been caused by a decline in interest rates that prompted some people to start buying houses that they wouldn't otherwise, but this is just a small detail. The bubble can only be kept going by a constant influx of new money into the economy, but the focus on the interest rate is wrong. If new money is printed and used by the government to buy ships then there will be a boom and a bubble in the ship market, and that involves all the parts of production process of ships and also bars that will be opened near areas of the town where ships are built and new people are being hired with higher salaries to do things that will eventually contribute to the production of ships that will then be sold to the government. It's not interest rates or the length of the production process that matters, it's just printed money and malinvestiment.

@ 3bf0c63f:aefa459d

# hledger-web A Haskell app that uses [Miso](https://hackage.haskell.org/package/miso) and [hledger's Haskell libraries](https://hledger.org/) plus [ghcjs](https://github.com/ghcjs/ghcjs) to be compiled to a web page, and then adds [optional remoteStorage](https://remotestorage.io/) so you can store your ledger data somewhere else. This was my introduction to Haskell and also built at a time I thought remoteStorage was a good idea that solved many problems, and that it could use some help in the form of just yet another somewhat-useless-but-cool project using it that could be [added to their wiki](https://wiki.remotestorage.io/Apps). - <https://hledger.alhur.es/> - <https://github.com/fiatjaf/hledger-web> ## See also - [My stupid introduction to Haskell](nostr:naddr1qqyrxveevscrqcmrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cxd5qyk) - [LessPass remoteStorage](nostr:naddr1qqyrsctpxfjnqepeqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cfa6z2z) - [TiddlyWiki remoteStorage](nostr:naddr1qqyxxve4x33nqerrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cat32d3)

@ 3bf0c63f:aefa459d

# Why I don't like NIP-26 as a solution for key management NIP-26 was created out of the needs of the Nostr integration at https://minds.com/. They wanted Minds users to be able to associate their "custodial" Nostr key with an external self-owned key. [NIP-26](https://github.com/nostr-protocol/nips/blob/master/26.md) looked like a nice fit for the job, because it would allow supporting clients to associate the two identities _statelessly_ (i.e. by just seeing one event published by Minds but with a delegation tag on it the client would be able to associate that with the self-owned external key without anything else[^1]). The big selling point of NIP-26 (to me) was that it was fully _optional_. Clients were free to not implement it and they would not suffer much. They would just see "bob@minds.com" published this, and "bob-self-owned" published that. They would probably know intuitively that these two were the same person, or not, but it wouldn't be an issue. Both would still be identified as Bob and have a picture, a history and so on. Moreover, this wasn't expected to happen a lot, it would be mostly for the small intersection of people that wanted to have their own keys and also happened to be using one of these "custodial Nostr" platforms like Minds. At some point, though, NIP-26 started to be seen as _the solution for key management_ on Nostr. The idea is that someone will generate a very safe key on a hardware device and guard it as their most precious treasure without it ever touching the internet, and use it just to sign delegation tags. Then use multiple of these delegation tags, one for each different Nostr app, and maybe rotate them every month or so, details are unclear. This breaks the previous expectations I had for NIP-26 entirely, as now these keys become faceless entities that can't be associated with anything _except their "master" key_ (the one that is in cold storage). So in a world in which most Nostr users are using NIP-26 for everything, clients that do not implement NIP-26 become completely useless, as all they will see is a constant stream of random keys. They won't be able to follow anyone or interact with anyone, as these keys will not identify any concrete person on their back, they will vanish all the time and new keys will show up and the world will be chaotic. So now every client must implement NIP-26 to become usable at all, it is not _optional_ anymore. You may argue that making NIP-26 a de facto mandatory NIP isn't a bad thing and is worth the cost, but I think it breaks a lot of the simplicity of the protocol. It would probably be worth the cost if we knew NIP-26 was an actual complete solution, but it definitely is not, it is partial, and not the most elegant thing in the world. I think key management can be solved in multiple different ways that can all work together or not, but most importantly they can all remain optional. More thoughts on these multiple ways can be found at [Thoughts on Nostr key management](nostr:naddr1qqyrwvnxx4jrzef5qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cchlq3c). If I am wrong about all this and we really come to the conclusion that we need a _de facto mandatory **key delegation**_ method for Nostr, so be it -- but in that case, considering that we will break backwards-compatibility anyway, I think there might be a better design than NIP-26, more optimized and easier to implement, I don't know how exactly. But I really think we shouldn't rush that. [^1]: as opposed to other suggestions that would also work, but that would require dealing with multiple events -- for example, the external user could publish a new replaceable event -- or use `kind:0` -- to say they wanted to grandfather the Minds key into their umbrella, while the Minds key would also need to signal its acceptance of that. This also had the problem of requiring changes every time a new replaceable event of such kind was found. Although I am unsure now, at the time me and William agreed this was worse than NIP-26 with the delegation tag.

@ 3bf0c63f:aefa459d

# IPFS problems: Dynamic links Content-addressability is cool and we all like it, but we all also know we can't live in a world without readable and memorizeable names. IPFS has proposed IPNS, the Interplanetary Name System (the names are very cool indeed), since its beggining (or maybe it was some months after the first IPFS idea, which would indicate this problem arrived as an afterthought). It has been said IPNS would work in a manner similar to Git heads and branches (this was probably part of Juan Benet's marketing pitches that were immensely repeated in the first years, that IPFS was a mix between Torrents, Git and some other cool technology). This remains a distant promise, however. IPNS has been, for the last years, a very slow, unrecommended by their own developers and unusable way of addressing content that is basically just a pointer from a public key to an object hash. Recommendations fall on using a domain and dnslink, the way to tell IPFS nodes you own a domain and that can be used to identify an object hash. That works, but it is not the wonder of decentralization that was promised, and still, it's just a pointer. Any key-value store, database of filesystem can do pointers. --- Here I'm not saying, like tons of stupid people have on the internet, that IPFS should support dynamic links so we can build web apps on it. No, I would be pretty fine with just static links for static content, and continue to use the other internet protocols for things that needed to be dynamic.

@ 3bf0c63f:aefa459d

# On the state of programs and browsers Basically, there are basically (not exhaustively) 2 kinds of programs one can run in a computer nowadays: 1.1. A program that is installed, permanent, has direct access to the Operating System, can draw whatever it wants, modify files, interact with other programs and so on; 1.2. A program that is transient, fetched from someone else's server at run time, interpreted, rendered and executed by another program that bridges the access of that transient program to the OS and other things. Meanwhile, web browsers have basically (not exhaustively) two use cases: 2.1. Display text, pictures, videos hosted on someone else's computer; 2.2. Execute incredibly complex programs that are fetched at run time, executed and so on -- you get it, it's the same 1.2. These two use cases for browsers are at big odds with one another. While stretching itsel f to become more and more a platform for programs that can do basically anything (in the 1.1 sense) they are still restricted to being an 1.2 platform. At the same time, websites that were supposed to be on 2.1 sometimes get confused and start acting as if they were 2.2 -- and other confusing mixed up stuff. I could go hours in philosophical inquiries on the nature of browsers, how rewriting everything in JavaScript is not healthy or where everything went wrong, but I think other people have done this already. One thing that bothers me a lot, though, is that computers can do a lot of things, and with the internet and in the current state of the technology it's fairly easy to implement tools that would help in many aspects of human existence and provide high-quality, useful programs, with the help of a server to coordinate access, store data, authenticate users and so on many things are possible. However, due to the nature of UI in the browser, it's very hard to get any useful tool to users. Writing a UI, even the most basic UI imaginable (some text input boxes and some buttons, or a table) can take a long time, always more than the time necessary to code the actual core features of whatever program is being developed -- and that is considering that the person capable of writing interesting programs that do the functionality in the backend are also capable of interacting with JavaScript and the giant amount of frameworks, transpilers, styling stuff, CSS, the fact that all this is built on top of HTML and so on. This is not good.

@ 3bf0c63f:aefa459d

# A big Ethereum problem that is fixed by Drivechain While reading the following paragraphs, assume Drivechain itself will be a "smart contract platform", like Ethereum. And that it won't be used to launch an Ethereum blockchain copy, but instead **each different Ethereum contract could be turned into a different sidechain** under [BIP300](https://bips.xyz/300) rules. ## A big Ethereum problem Anyone can publish any "contract" to Ethereum. Often people will come up with somewhat interesting ideas and publish them. Since they want money they will add an unnecessary token and use that to bring revenue to themselves, gamify the usage of their contract somehow, and keep some control over the supposedly open protocol they've created by keeping a majority of the tokens. They will use the profits on marketing and branding, have a visual identity, a central website and a forum with support personnel and so on: their _somewhat interesting idea_ have become a full-fledged company. If they have success then another company will appear in the space and copy the idea, launch it using exactly the same strategy with a tweak, then try to capture the customers of the first company and new people. And then another, and another, and another. Very often these contracts require some network effect to work, i.e., they require people to be using it so others will use it. The fact that the market is now split into multiple companies offering roughly the same product hurts that, such that none of these protocols get ever enough usage to become _really_ useful in the way they were first conceived. At this point it doesn't matter though, they get some usage, and they use that in their marketing material. It becomes a race to pump the value of the tokens and the current usage is just another point used for that purpose. The company will even start giving out money to attract new users and other weird moves that have no relationship with the initial somewhat intereting idea. Once in a lifetime it happens that the first implementer of these things is not a company seeking profits, but some altruistic developer or company that believes in Ethereum and wants to see it grow -- or more likely someone financed by the Ethereum Foundation, which allegedly doesn't like these token schemes and would prefer everybody to use the token they issued first, the ETH --, but that's a fruitless enterprise because someone else will copy that idea anyway and turn it into a company as described above. ## How Drivechain fixes it In the [Drivechain](nostr:naddr1qq9xgunfwejkx6rpd9hqzythwden5te0ve5kzar2v9nzucm0d5pzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqr4gumtjfnp) world, if someone had an idea, they would -- as it happens all the time with Bitcoin things -- publish it in a public forum. Other members of the community would evaluate that idea, add or remove things, all interested parties would contribute to make it the best possible incarnation of that idea. Once the design was settled, someone would volunteer to start writing the code to turn that idea into a sidechain. Maybe some company would fund those efforts and then more people would join. It's not a perfect process and one that often involves altruism, but Bitcoin inspires people to do these things. Slowly, the thing would get built, tested, activated as a sidechain on testnet, tested more, and at this point luckily the entire community of interested Bitcoin users and miners would have grown to like that idea and see its benefits. It could then be proposed to be activated according to [BIP300](https://bips.xyz/300) rules. Once it was activated, the entire pool of interested users would join it. And it would be impossible for someone else to create a copy of that because everybody would instantly notice it was a copy. There would be no token, no one profiting directly from the operations of that "smart contract". And everybody would be incentivized to join and tell others to join that same sidechain since the network effect was already the biggest there, they will know more network effect would only be good for everybody involved, and there would be no competing marketing and free token giveaways from competing entities. ## See also - [Upgrading 'Smart Contracts' to 'Wise Contracts'](https://www.truthcoin.info/blog/wise-contracts/), by Paul Sztorc - [Drivechain](nostr:naddr1qq9xgunfwejkx6rpd9hqzythwden5te0ve5kzar2v9nzucm0d5pzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqr4gumtjfnp) - [Drivechain comparison with Ethereum](nostr:naddr1qqyx2dp58qcx2wpjqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cane7px) - [Alternatives to Drivechain](nostr:naddr1qqyrqenzvvukvcfkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823csjg2t6)

@ 3bf0c63f:aefa459d

# Reasons why Lightning is not that great Some Bitcoiners, me included, were fooled by hyperbolic discourse that presented Lightning as some magical scaling solution with no flaws. This is an attempt to list some of the actual flaws uncovered after 5 years of experience. The point of this article is not to say Lightning is a complete worthless piece of crap, but only to highlight the fact that Bitcoin needs to put more focus on developing and thinking about other scaling solutions (such as [Drivechain](nostr:naddr1qq9xgunfwejkx6rpd9hqzythwden5te0ve5kzar2v9nzucm0d5pzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqr4gumtjfnp), less crappy and more decentralized trusted channels networks and [statechains](https://bitcoinmagazine.com/technical/statechains-sending-keys-not-coins-to-scale-bitcoin-off-chain)). ## Unbearable experience Maintaining a node is cumbersome, you have to deal with closed channels, allocating funds, paying fees unpredictably, choosing new channels to open, storing channel state backups -- or you'll have to delegate all these decisions to some weird AI or third-party services, it's not feasible for normal people. ## Channels fail for no good reason all the time Every time nodes disagree on anything they close channels, there have been dozens, maybe hundreds, of bugs that lead to channels being closed in the past, and implementors have been fixing these bugs, but since these node implementations continue to be worked on and new features continue to be added we can be quite sure that new bugs continue to be introduced. ## Trimmed (fake) HTLCs are not sound protocol design What would you tell me if I presented a protocol that allowed for transfers of users' funds across a network of channels and that these channels would pledge to send the money to miners while the payment was in flight, and that these payments could never be recovered if a node in the middle of the hop had a bug or decided to stop responding? Or that the receiver could receive your payment, but still claim he didn't, and you couldn't prove that at all? These are the properties of "trimmed HTLCs", HTLCs that are uneconomical to have their own UTXO in the channel presigned transaction bundles, therefore are just assumed to be there while they are not (and their amounts are instead added to the fees of the presigned transaction). Trimmed HTLCs, like any other HTLC, have timelocks, preimages and hashes associated with them -- which are properties relevant to the redemption of actual HTLCs onchain --, but unlike actual HTLCs these things have no actual onchain meaning since there is no onchain UTXO associated with them. This is a game of make-believe that only "works" because (1) payment proofs aren't worth anything anyway, so it makes no sense to steal these; (2) channels are too expensive to setup; (3) all Lightning Network users are honest; (4) there are so many bugs and confusion in a Lightning Network node's life that events related to trimmed HTLCs do not get noticed by users. Also, so far these trimmed HTLCs have only been used for very small payments (although very small payments probably account for 99% of the total payments), so it is supposedly "fine" to have them. But, as fees rise, more and more HTLCs tend to become fake, which may make people question the sanity of the design. Tadge Dryja, one of the creators of the Lightning Network proposal, has been critical of the fact that these things were allowed to creep into the BOLT protocol. ## Routing Routing is already very bad today even though most nodes have a basically 100% view of the public network, the reasons being that some nodes are offline, others are on Tor and unreachable or too slow, channels have the balance shifted in the wrong direction, so payments fail a lot -- which leads to the (bad) solution invented by professional node runners and large businesses of probing the network constantly in order to discard bad paths, this creates unnecessary load and increases the risk of channels being dropped for no good reason. As the network grows -- if it indeed grow and not centralize in a few hubs -- routing tends to become harder and harder. While each implementation team makes their own decisions with regard to how to best way to route payments and these decisions may change at anytime, it's worth noting, for example, that CLN will use MPP to split up any payment in any number of chunks of 10k satoshis, supposedly to improve routing success rates. While this often backfires and causes payments to fail when they should have succeeded, it also contributes to making it so there are proportionally more fake HTLCs than there should be, as long as the threshold for fake HTLCs is above 10k. ## Payment proofs are somewhat useless Even though payment proofs were seen by many (including me) as one of the great things about Lightning, the sad fact is that they do not work as proofs if people are not aware of the fact that they are proofs. Wallets do all they can to hide these details from users because it is considered "bad UX" and low-level implementors do not care very much to talk about them at all. There have been attempts from Lightning Labs to get rid of the payment proofs entirely (which at the time to me sounded like a terrible idea, but now I realize they were not wrong). Here's a piece of anecdote: I've personally witnessed multiple episodes in which Phoenix wallet released the preimage without having actually received the payment (they did receive a minor part of the payment, but the payment was split in many parts). That caused my service, _@lntxbot_, to mark the outgoing payment as complete, only then to have to endure complaints from the users because the receiver side, Phoenix, had not received the full amount. In these cases, if the protocol and the idea of preimages as payment proofs be respected, should I have been the one in charge of manually fixing user balances? Another important detail: when an HTLC is sent and then something goes wrong with the payment the channel has to be closed in order to redeem that payment. When the redeemer is on the receiver side, the very act of redeeming should cause the preimage to be revealed and a proof of payment to be made available for the sender, who can then send that back to the previous hop and the payment is proven without any doubt. But when this happens for fake HTLCs (which is the vast majority of payments, as noted above) there is no place in the world for a preimage and therefore there are no proofs available. A channel is just closed, the payer loses money but can't prove a payment. It also can't send that proof back to the previous hop so he is forced to say the payment failed -- even if it wasn't him the one who declared that hop a failure and closed the channel, which should be a prerequisite. I wonder if this isn't the source of multiple bugs in implementations that cause channels to be closed unnecessarily. The point is: preimages and payment proofs are mostly a fiction. Another important fact is that the proofs do not really prove anything if the keypair that signs the invoice can't be provably attached to a real world entity. ## LSP-centric design The first Lightning wallets to show up in the market, LND as a desktop daemon (then later with some GUIs on top of it like Zap and Joule) and Anton's BLW and Eclair wallets for mobile devices, then later LND-based mobile wallets like Blixt and RawTX, were all standalone wallets that were self-sufficient and meant to be run directly by consumers. Eventually, though, came Breez and Phoenix and introduced the "LSP" model, in which a server would be trusted in various forms -- not directly with users' funds, but with their privacy, fees and other details -- but most importantly that LSP would be the primary source of channels for all users of that given wallet software. This was all fine, but as time passed new features were designed and implemented that assumed users would be running software connected to LSPs. The very idea of a user having a standalone mobile wallet was put out of question. The entire argument for implementation of the bolt12 standard, for example, hinged on the assumption that mobile wallets would have [LSPs capable of connecting to Google messaging services and being able to "wake up" mobile wallets](https://twitter.com/hampus_s/status/1442493786110705668) in order for them to receive payments. Other ideas, like a complicated standard for allowing mobile wallets to receive payments without having to be online all the time, just [assume LSPs always exist](https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003307.html); and changes to the expected BOLT spec behavior with regards to, for example, [probing of mobile wallets](https://github.com/lightningnetwork/lnd/pull/4785). Ark is another example of a kind of LSP that got so enshrined that it become a new protocol that depends on it entirely. ## Protocol complexity Even though the general idea of how Lightning is supposed to work can be understood by many people (as long as these people know how Bitcoin works) the Lightning protocol is not really easy: it will take a long time of big dedication for anyone to understand the details about the BOLTs -- this is a bad thing if we want a world of users that have at least an idea of what they are doing. Moreover, with each new cool idea someone has that gets adopted by the protocol leaders, it increases in complexity and some of the implementors are kicked out of the circle, therefore making it easier for the remaining ones to proceed with more and more complexity. It's the same process by which Chrome won the browser wars, kicked out all competitors and proceeded to make a supposedly open protocol, but one that no one can implement as it gets new and more complex features every day, all envisioned by the Chrome team. ## Liquidity issues? I don't believe these are a real problem if all the other things worked, but still the old criticism that Lightning requires parking liquidity and that has a cost is not a complete non-issue, specially given the LSP-centric model.

@ 3bf0c63f:aefa459d

# LessPass remoteStorage [LessPass](https://www.lesspass.com/) is a nice idea: a password manager without any state. Just remember one master password and you can generate a different one for every site using the power of hashes. But it has a very bad issue: some sites require just numbers, others have a minimum or maximum character limits, some require non-letter characters, uppercase characters, others forbid these and so on. The solution: to allow you to specify parameters when generating the password so you can fit a generated password on every service. The problem with the solution: it creates state. Now you must remember what parameters you used when generating a password for each site. This was a way to store these settings on a [remoteStorage](https://wiki.remotestorage.io/Apps) bucket. Since it isn't confidential information in any way, that wasn't a problem, and I thought it was a good fit for remoteStorage. Some time later I realized it maybe would be better to have a centralized repository hosting all weird requirements for passwords each domain forced on its users, and let LessPass use data from that central place when generating a password. Still stateful, not ideal, not very far from a centralized password manager, but still requiring less trust and less cryptographic assumptions. - <https://github.com/fiatjaf/lesspass-remotestorage> - <https://addons.mozilla.org/firefox/addon/lesspass-remotestorage/> - <https://chrome.google.com/webstore/detail/lesspass-remotestorage/aogdpopejodechblppdkpiimchbmdcmc> - <https://lesspass.alhur.es/> ## See also - [hledger-web](nostr:naddr1qqyrsefkvvck2efkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cffvz7c) - [TiddlyWiki remoteStorage](nostr:naddr1qqyxxve4x33nqerrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cat32d3)

@ 3bf0c63f:aefa459d

# Carl R. Rogers sobre a ciência > Creio que o objetivo primário da ciência é fornecer uma hipótese, uma convicção e uma fé mais seguras e que satisfaçam melhor o próprio investigador. Na medida em que o cientista procura provar qualquer coisa a alguém -- um erro em que incorri mais de uma vez --, creio que ele está se servindo da ciência para remediar uma insegurança pessoal, desviando-a do seu verdadeiro papel criativo a serviço do indivíduo. _Tornar-se Pessoa_, página aleatória

@ 3bf0c63f:aefa459d

# contratos.alhur.es A website that allowed people to fill a form and get a standard _Contrato de Locação_. Better than all the other "templates" that float around the internet, which are badly formatted `.doc` files. It was fully programmable so other templates could be added later, but I never did. This website made maybe one dollar in Google Ads (and Google has probably stolen these like so many other dollars they did with their bizarre requirements). - <https://github.com/fiatjaf/contratos> - <http://contratos.alhur.es>

@ 3bf0c63f:aefa459d

# Classless Templates There are way too many hours being wasted in making themes for blogs. And then comes a new blog framework, it requires new themes. Old themes can't be used because they relied on different ways of rendering the website. Everything is a mess. Classless was an attempt at solving it. It probably didn't work because I wasn't the best person to make themes and showcase the thing. Basically everybody would agree on a simple HTML template that could fit blogs and simple websites very easily. Then other people would make pure-CSS themes expecting that template to be in place. No classes were needed, only a fixed structure of `header`. `main`, `article` etc. With **flexbox** and **grid** CSS was enough to make this happen. The templates that were available were all ported by me from other templates I saw on the web, and there was a simple one I created for my old website. - <https://github.com/fiatjaf/classless> - <https://classless.alhur.es/> - <https://classless.alhur.es/themes/>

@ 3bf0c63f:aefa459d

# doulas.club A full catalog of all Brazilian doulas with data carefully scrapped from many websites that contained partial catalogs and some data manually included. All this packaged as a _Couchapp_ and served directly from **Cloudant**. This was done because the idea of doulas was good, but I spotted an issue: pregnant womwn should know many doulas before choosing one that would match well, therefore a full catalog with a lot of information was necessary. This was a huge amount of work mostly wasted. Many doulas who knew about this didn't like it and sent angry and offensive emails telling me to remove them. This was information one should know before choosing a doula. ### See also - [About CouchDB](nostr:naddr1qqyrwepevf3n2wf5qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c0jq39e)

@ 3bf0c63f:aefa459d

# jiq When someone created [`jiq`](https://github.com/simeji/jid) claiming it had "jq queries" I went to inspect and realized it didn't, it just had a poor simple JSON query language that implemented 1% of all [`jq`](https://stedolan.github.io/jq/manual/) features, so I forked it and plugged `jq` directly into it, and renamed to `jiq`. After some comments on issues in the original repository from people complaining about lack of `jq` compatibility it got a ton of unexpected users, was even packaged to ArchLinux.  - <https://github.com/fiatjaf/jiq>

@ 3bf0c63f:aefa459d

# comentário pertinente de Olavo de Carvalho sobre atribuições indevidas de acontecimentos à "ordem espontânea" Eis aqui um exemplo entre outros mil, extraído das minhas apostilas de aulas, de como se analisam as relações entre fatores deliberados e casuais na ação histórica. O sr, Beltrão está INFINITAMENTE ABAIXO da possibilidade de discutir essas coisas, e por isso mesmo me atribui uma simploriedade que é dele próprio e não minha: Já citei mil vezes este parágrafo de Georg Jellinek e vou citá-lo de novo: “Os fenômenos da vida social dividem-se em duas classes: aqueles que são determinados essencialmente por uma vontade diretriz e aqueles que existem ou podem existir sem uma organização devida a atos de vontade. Os primeiros estão submetidos necessariamente a um plano, a uma ordem emanada de uma vontade consciente, em oposição aos segundos, cuja ordenação repousa em forças bem diferentes.” Essa distinção é crucial para os historiadores e os analistas estratégicos não porque ela é clara em todos os casos, mas precisamente porque não o é. O erro mais comum nessa ordem de estudos reside em atribuir a uma intenção consciente aquilo que resulta de uma descontrolada e às vezes incontrolável combinação de forças, ou, inversamente, em não conseguir enxergar, por trás de uma constelação aparentemente fortuita de circunstâncias, a inteligência que planejou e dirigiu sutilmente o curso dos acontecimentos. Exemplo do primeiro erro são os Protocolos dos Sábios de Sião, que enxergam por trás de praticamente tudo o que acontece de mau no mundo a premeditação maligna de um número reduzidos de pessoas, uma elite judaica reunida secretamente em algum lugar incerto e não sabido. O que torna essa fantasia especialmente convincente, decorrido algum tempo da sua publicação, é que alguns dos acontecimentos ali previstos se realizam bem diante dos nossos olhos. O leitor apressado vê nisso uma confirmação, saltando imprudentemente da observação do fato à imputação da autoria. Sim, algumas das idéias anunciadas nos Protocolos foram realizadas, mas não por uma elite distintamente judaica nem muito menos em proveito dos judeus, cuja papel na maioria dos casos consistiu eminentemente em pagar o pato. Muitos grupos ricos e poderosos têm ambições de dominação global e, uma vez publicado o livro, que em certos trechos tem lances de autêntica genialidade estratégica de tipo maquiavélico, era praticamente impossível que nada aprendessem com ele e não tentassem por em prática alguns dos seus esquemas, com a vantagem adicional de que estes já vinham com um bode expiatório pré-fabricado. Também é impossível que no meio ou no topo desses grupos não exista nenhum judeu de origem. Basta portanto um pouquinho de seletividade deformante para trocar a causa pelo efeito e o inocente pelo culpado. Mas o erro mais comum hoje em dia não é esse. É o contrário: é a recusa obstinada de enxergar alguma premeditação, alguma autoria, mesmo por trás de acontecimentos notavelmente convergentes que, sem isso, teriam de ser explicados pela forca mágica das coincidências, pela ação de anjos e demônios, pela "mão invisível" das forças de mercado ou por hipotéticas “leis da História” ou “constantes sociológicas” jamais provadas, que na imaginação do observador dirigem tudo anonimamente e sem intervenção humana. As causas geradoras desse erro são, grosso modo: Primeira: Reduzir as ações humanas a efeitos de forças impessoais e anônimas requer o uso de conceitos genéricos abstratos que dão automaticamente a esse tipo de abordagem a aparência de coisa muito científica. Muito mais científica, para o observador leigo, do que a paciente e meticulosa reconstituição histórica das cadeias de fatos que, sob um véu de confusão, remontam às vezes a uma autoria inicial discreta e quase imperceptível. Como o estudo dos fenômenos histórico-políticos é cada vez mais uma ocupação acadêmica cujo sucesso depende de verbas, patrocínios, respaldo na mídia popular e boas relações com o establishment, é quase inevitável que, diante de uma questão dessa ordem, poucos resistam à tentação de matar logo o problema com duas ou três generalizações elegantes e brilhar como sábios de ocasião em vez de dar-se o trabalho de rastreamentos históricos que podem exigir décadas de pesquisa. Segunda: Qualquer grupo ou entidade que se aventure a ações histórico-políticas de longo prazo tem de possuir não só os meios de empreendê-las, mas também, necessariamente, os meios de controlar a sua repercussão pública, acentuando o que lhe convém e encobrindo o que possa abortar os resultados pretendidos. Isso implica intervenções vastas, profundas e duradouras no ambiente mental. [Etc. etc. etc.] (no facebook em 17 de julho de 2013)

@ 3bf0c63f:aefa459d

# idea: Rumple _a payments network based on trust channels_ This is the description of a Lightning-like network that will work only with credit or trust-based channels and exist alongside the normal Lightning Network. I imagine some people will think this is undesirable and at the same time very easy to do (such that if it doesn't exist yet it must be because no one cares), but in fact it is a very desirable thing -- which I hope I can establish below -- and at the same time a very non-trivial problem to solve, as the history of Ryan Fugger's Ripple project and posterior copies of it show. Read these first to get the full context: 1. [Ryan Fugger's Ripple](nostr:naddr1qqyxgenyxe3rzvf4qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c8pp8zu) 2. [Ripple and the problem of the decentralized commit](nostr:naddr1qqyrxcmzxa3nxv34qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cjrqar6) 3. [The Lightning Network solves the problem of the decentralized commit](nostr:naddr1qqyx2vekxg6rsvejqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ccs2twc) 4. [Parallel Chains](nostr:naddr1qqyxzd3hx5uryvmrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ca5e585) ## Explanation about the name Since we're copying the fundamental Ripple idea from Ryan Fugger and since the name "Ripple" is now associated with a scam coin called XRP, and since Ryan Fugger has changed the name of his old website "Ripplepay" to "Rumplepay", we will follow his lead here. If "Ripplepay" was the name of a centralized prototype to the open peer-to-peer network "Ripple", now that the centralized version is called "Rumplepay" the peer-to-peer version must be called "Rumple". ## Now the idea Basically we copy the Lightning Network, but without HTLCs or channels being opened and closed with funds committed to them on multisig Bitcoin transactions published to the blockchain. Instead we use pure trust relationships like the original Ripple concept. And we use [the blockchain commit method](http://ripple.ryanfugger.com/Protocol/BlockChainCommitMethod.html), but instead of spending an absurd amount of money to use the actual Bitcoin blockchain instead we use a parallel chain. ## How exactly -- a protocol proposal attempt It could work like this: ### The parallel chain, or "Rumple Chain" 1. We define a parallel chain with a genesis block; 2. Following blocks must contain ``` a. the ID of the previous block; b. a list of up to 32768 entries of arbitrary 32-byte values; c. an ID constituted by sha256(the previous block ID + the merkle root of all the entries) ``` 3. To be mined, each parallel block must be included in the Bitcoin chain according [as explained above](nostr:naddr1qqyxzd3hx5uryvmrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ca5e585). Now that we have a structure for a simple "blockchain" that is completely useless, just blocks over blocks of meaningless values, we proceed to the next step of assigning meaning to these values. ### The off-chain payments network, or "Rumple Network" 1. We create a network of nodes that can talk to each other via TCP messages (all details are the same as the Lightning Network, except where mentioned otherwise); 2. These nodes can create trust channels to each other. These channels are backed by nothing except the willingness of one peer to pay the other what is owed. 3. When Alice creates a trust channel with Bob (`Alice trusts Bob`), contrary to what happens in the Lightning Network, it's A that can immediately receive payments through that channel, and everything A receives will be an IOU from Bob to Alice. So Alice should never open a channel to Bob unless Alice trusts Bob. But also Alice can choose the amount of trust it has in Bob, she can, for example, open a very small channel with Bob, which means she will only lose a few satoshis if Bob decides to exit scam her. (in the original Ripple examples these channels were always depicted as friend relationships, and they can continue being that, but it's expected -- given the experience of the Lightning Network -- that the bulk of the channels will exist between users and wallet provider nodes that will act as hubs). 4. As Alice receive a payment through her channel with Bob, she becomes a creditor and Bob a debtor, i.e., the balance of the channel moves a little to her side. Now she can use these funds to make payments over that channel (or make a payment that combines funds from multiple channels using [MPP](https://ln.dev/read/04-onion-routing#basic-multi-part-payments)). 5. If at any time Alice decides to close her channel with Bob, she can send all the funds she has standing there to somewhere else (for example, another channel she has with someone else, another wallet somewhere else, a shop that is selling some good or service, or a service that will aggregate all funds from all her channels and send a transaction to the Bitcoin chain on her behalf). 6. If at any time Bob leaves the network Alice is entitled by Bob's cryptographic signatures to knock on his door and demand payment, or go to a judge and ask him to force Bob to pay, or share the signatures and commitments online and hurt Bob's reputation with the rest of the network (but yes, none of these things is good enough and if Bob is a very dishonest person none of these things is likely to save Alice's funds). ### The payment flow 1. Suppose there exists a route `Alice->Bob->Carol` and Alice wants to send a payment to Carol. 2. First Alice reads an _invoice_ she received from Carol. The invoice (which can be pretty similar or maybe even the same as [BOLT11](https://ln.dev/read/11-payment-encoding)) contains a payment hash `h` and information about how to reach Carol's node, optionally an amount. Let's say it's 100 satoshis. 3. Using the routing information she gathered, Alice builds an onion and sends it to Bob, at the same time she offers to Bob a "conditional IOU". That stands for a signed commitment that Alice will owe Bob an 100 satoshis if in the next 50 blocks of the Rumple Chain there appears a block containing the preimage `p` such that `sha256(p) == h`. 4. Bob peels the onion and discovers that he must forward that payment to Carol, so he forwards the peeled onion and offers a conditional IOU to Carol with the same `h`. Bob doesn't know Carol is the final recipient of the payment, it could potentially go on and on. 5. When Carol gets the conditional IOU from Bob, she makes a list of all the nodes who have announced themselves as miners (which is not something I have mentioned before, but nodes that are acting as miners will must announce themselves somehow) and are online and bidding for the next Rumple block. Each of these miners will have previously published a random 32-byte value `v` they they intend to include in their next block. 6. Carol sends payments through routes to all (or a big number) of these miners, but this time the conditional IOU contains two conditions (values that must appear in a block for the IOU to be valid): `p` such that `sha256(p) == h` (the same that featured in the invoice) and `v` (which must be unique and constant for each miner, something that is easily verifiable by Carol beforehand). Also, instead of these conditions being valid for the next 50 blocks they are valid only for the single next block. 7. Now Carol broadcasts `p` to the mempool and hopes one of the miners to which she sent conditional payments sees it and, allured by the possibility of cashing in Carol's payment, includes `p` in the next block. If that does not happen, Carol can try again in the next block. ## Why bother with this at all? 1. **The biggest advantage of Lightning is its openness** It has been said multiple times that if trust is involved then we don't need Lightning, we can use Coinbase, or worse, Paypal. This is very wrong. Lightning is good specially because it serves as a bridge between Coinbase, Paypal, other custodial provider and someone running their own node. All these can transact freely across the network and pay each other without worrying about who is in which provider or setup. Rumple inherits that openness. In a Rumple Network anyone is free to open new trust channels and immediately route payments to anyone else. Also, since Rumple payments are also based on the reveal of a preimage it can do swaps with Lightning inside a payment route from day one (by which I mean one can pay from Rumple to Lightning and vice-versa). 3. **Rumple fixes Lightning's fragility** Lightning is too fragile. It's known that Lightning is vulnerable to multiple attacks -- like the [flood-and-loot](https://www.coindesk.com/bitcoins-lightning-network-is-vulnerable-to-looting-new-research-explains) attack, for example, although not an attack that's easy to execute, it's still dangerous even if failed. Given the existence of these attacks, it's important to not ever open channels with random anonymous people. Some degree of trust must exist between peers. But one does not even have to consider attacks. The creation of HTLCs is a liability that every node has to do multiple times during its life. Every initiated, received or forwarded payment require adding one HTLC then removing it from the commitment transaction. Another issue that makes trust needed between peers is the fact that channels can be closed unilaterally. Although this is a feature, it is also a bug when considering high-fee environments. Imagine you pay $2 in fees to open a channel, your peer may close that unilaterally in the next second and then you have to pay another $15 to close the channel. The opener pays (this is also a feature that [can double as a bug](https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002804.html) by itself). Even if it's not you opening the channel, a peer can open a channel with you, make a payment, then clone the channel, and now you're left with, say, an output of 800 satoshis, which is equal to zero if network fees are high. So you should only open channels with people you know and know aren't going to actively try to hack you and people who are not going to close channels and impose unnecessary costs on you. But even considering a fully trusted Lightning Network, even if -- to be extreme -- you only opened channels with yourself, these channels would still be fragile. If some HTLC gets stuck for any reason (peer offline or some weird small incompatibility between node softwares) and you're forced to close the channel because of that, there are the extra costs of sweeping these UTXO outputs plus the total costs of closing and reopening a channel that shouldn't have been closed in the first place. Even if HTLCs don't get stuck, a [fee renegotiation event during a mempool spike](https://twitter.com/renepickhardt/status/1321862538859073548) may cause channels to force-close, become valueless or settle for very high closing fee. Some of these issues are mitigated by Eltoo, others by only having channels with people you trust. Others referenced above, plus the [the griefing attack](https://twitter.com/joostjgr/status/1308414364911841281) and in general the ability of anyone to spam the network for free with payments that can be pending forever or a lot of payments fail repeatedly makes it very fragile. Rumple solves most of these problems by not having to touch the blockchain at all. Fee negotiation makes no sense. Opening and closing channels is free. Flood-and-loot is a non-issue. The griefing attack can be still attempted as funds in trust channels must be reserved like on Lightning, but since there should be no theoretical limit to the number of prepared payments a channel can have, the griefing must rely on actual amounts being committed, which prevents large attacks from being performed easily. 4. **Rumple fixes Lightning's unsolvable reputation issues** In the Lightning Conference 2019, Rusty Russell promised there would be pre-payments on Lightning someday, since everybody was aware of potential spam issues and pre-payments would be the way to solve that. Fast-forward to November 2020 and these pre-payments have become an [apparently unsolvable problem](https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002826.html)[^thread-402]: no one knows how to implement them reliably without destroying privacy completely or introducing worse problems. Replacing these payments with tables of reputation between peers is also an unsolved problem[^reputation-lightning], for the same reasons explained in the thread above. 5. **Rumple solves the hot wallet problem** Since you don't have to use Bitcoin keys or sign transactions with a Rumple node, only your channel trust is at risk at any time. 6. **Rumple ends custodianship** Since no one is storing other people's funds, a big hub or wallet provider can be used in multiple payment routes, but it cannot be immediately classified as a "custodian". At best, it will be a big debtor. 7. **Rumple is fun** Opening channels with strangers is boring. Opening channels with friends and people you trust even a little makes that relationship grow stronger and the trust be reinforced. (But of course, like it happens in the Lightning Network today, if Rumple is successful the bulk of trust will be from isolated users to big reliable hubs.) ## Questions or potential issues 1. **So many advantages, yes, but trusted? Custodial? That's easy and stupid!** Well, an enormous part of the current Lightning Network (and also onchain Bitcoin wallets) already rests on trust, mainly trust between users and custodial wallet providers like ZEBEDEE, Alby, Wallet-of-Satoshi and others. Worse: on the current Lightning Network users not only trust, they also expose their entire transaction history to these providers[^hosted-channels]. Besides that, as detailed in point 3 of the previous section, there are many unsolvable issues on the Lightning protocol that make each sovereign node dependent on some level of trust in its peers (and the network in general dependent on trusting that no one else will spam it to death). So, given the current state of the Lightning Network, to trust peers like Rumple requires is not a giant change -- but it is still a significant change: in Rumple you shouldn't open a large trust channel with someone just because it looks trustworthy, you must personally know that person and only put in what you're willing to lose. In known brands that have reputation to lose you can probably deposit more trust, same for long-term friends, and that's all. Still it is probably good enough, given the existence of MPP payments and the fact that the purpose of Rumple is to be a payments network for day-to-day purchases and not a way to buy real estate. 2. **Why would anyone run a node in this parallel chain?** I don't know. Ideally every server running a Rumple Network node will be running a Bitcoin node and a Rumple chain node. Besides using it to confirm and publish your own Rumple Network transactions it can be set to do BMM mining automatically and maybe earn some small fees comparable to running a Lightning routing node or a JoinMarket yield generator. Also it will probably be very lightweight, as pruning is completely free and no verification-since-the-genesis-block will take place. 10. **What is the maturity of the debt that exists in the Rumple Network or its legal status?** By default it is to be understood as being payable _on demand for payments occurring inside the network_ (as credit can be used to forward or initiate payments by the creditor using that channel). But details of settlement outside the network or what happens if one of the peers disappears cannot be enforced or specified by the network. Perhaps some standard optional settlement methods (like a Bitcoin address) can be announced and negotiated upon channel creation inside the protocol, but nothing more than that. [^thread-402]: Read at least the first 10 messages of the thread to see how naïve proposals like you and me could have thought about are brought up and then dismantled very carefully by the group of people most committed to getting Lightning to work properly. [^reputation-lightning]: See also the footnote at [Ripple and the problem of the decentralized commit](nostr:naddr1qqyrxcmzxa3nxv34qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cjrqar6). [^hosted-channels]: Although that second part can be solved by [hosted channels](https://gist.github.com/btcontract/d4122a79911eef2620f16b3dfe2850a8).

@ 3bf0c63f:aefa459d

# Comprimido desodorante No episódio sei-lá-qual de Aleixo FM Bruno Aleixo diz que os bêbados sempre têm as melhores idéias e daí conta uma idéia que ele teve quando estava bêbado: um comprimido que funciona como desodorante. Ao invés de passar o desodorante spray ou roll-on a pessoa pode só tomar o comprimido e pronto, é muito mais prático e no tempo de frio a pessoa pode vestir a roupa mais rápido, sem precisar ficar passando nada com o tronco todo nu. Quando o Busto lhe pergunta sobre a possibilidade de algo assim ser fabricado ele diz que não sabe, que não é cientista, só tem as idéias. Essa passagem tão boba de um programa de humor esconde uma verdade sobre a doutrina cientística que permeia a sociedade. A doutrina segundo a qual é da ciência que vêm as inovações tecnológicas e de todos os tipos, e por isso é preciso que o Estado tire dinheiro das pessoas trabalhadoras e dê para os cientistas. Nesse ponto ninguém mais sabe o que é um cientista, foi-se toda a concretude, ficou só o nome: "cientista". Daí vão procurar o tal cientista, é um cara que se formou numa universidade e está fazendo um mestrado. Pronto, é só dar dinheiro pra esse cara e tudo vai ficar bom. Tirando o problema da desconexão entre realidade e a tese, existe também, é claro, o problema da tese: não faz sentido, que um cientista fique procurando formas de realizar uma idéia, que não se sabe nem se é possível nem se é desejável, que ele ou outra pessoa tiveram, muito pelo contrário (mas não vou dizer aqui o que é que era para o cientista fazer porque isso seria contraditório e eu não acho que devam nem existir cientistas). O que eu queria dizer mesmo era: todo o aparato científico da nossa sociedade, todos os departamentos, universidades, orçamentos e bolsas e revistas, tudo se resume a um monte de gente tentando descobrir como fazer um comprimido desodorante.

@ 3bf0c63f:aefa459d

# Zettelkasten <https://writingcooperative.com/zettelkasten-how-one-german-scholar-was-so-freakishly-productive-997e4e0ca125> (um artigo meio estúpido, mas útil). Esta incrível técnica de salvar notas sem categorias, sem pastas, sem hierarquia predefinida, mas apenas fazendo referências de uma nota à outra e fazendo supostamente surgir uma ordem (ou heterarquia, disseram eles) a partir do caos parece ser o que faltava pra eu conseguir anotar meus pensamentos e idéias de maneira decente, veremos. Ah, e vou usar esse tal [`neuron`](https://github.com/srid/neuron) que também gera sites a partir das notas?, acho que vai ser bom.

@ 3bf0c63f:aefa459d

# Motte-and-bailey  há [aqui](http://slatestarcodex.com/2014/07/07/social-justice-and-words-words-words/) um artigo, escrito por um sujeito provavelmente esquerdista, ateu e tal, que toca num ponto importante sobre o discurso dessas esquerdas defensoras de minorias. ele introduz brevemente o conceito da _motte-and-bailey doctrine_, que é um nome bacana que deram para a estratégia que esses conhecidos e amigos seus de esquerda usam para dizer os maiores absurdos na internet e em grupos fechados esquerdistas, mas, quando confrontados por você, parecem ser mansos, inteligentes e gente boa, como você sempre esperou que fossem. o sujeito é meio confuso, mas o fato mesmo de ele ser esquerdista valida mais ainda o argumento.

@ 3bf0c63f:aefa459d

# Token-Curated Registries ## So you want to build a TCR? TCRs (Token Curated Registries) are a construct for maintaining registries on Ethereum. Imagine you have lots of scissor brands and you want a list with only the good scissors. You want to make sure only the good scissors make into that list and not the bad scissors. For that, people will tell you, you can just create a TCR of the best scissors! It works like this: some people have the token, let's call it Scissor Token. Some other person, let's say it's a scissor manufacturer, wants to put his scissor on the list, this guy must acquire some Scissor Tokens and "stake" it. Holders of the Scissor Tokens are allowed to vote on "yes" or "no". If "no", the manufactures loses his tokens to the holders, if "yes" then its tokens are kept in deposit, but his scissor brand gets accepted into the registry. Such a simple process, they say, have strong incentives for being the best possible way of curating a registry of scissors: consumers have the incentive to consult the list because of its high quality; manufacturers have the incentive to buy tokens and apply to join the list because the list is so well-curated and consumers always consult it; token holders want the registry to accept good and reject bad scissors because that good decisions will make the list good for consumers and thus their tokens more valuable, bad decisions will do the contrary. It doesn't make sense, to reject everybody just to grab their tokens, because that would create an incentive against people trying to enter the list. Amazing! How come such a simple system of voting has such enourmous features? Now we can have lists of everything so well-curated, and for that we just need Ethereum tokens! Now let's imagine a different proposal, of my own creation: SPCR, Single-person curated registries. Single-person Curated Registries are equal to TCR, except they don't use Ethereum tokens, it's just a list in a text file kept by a single person. People can apply to join, and they will have to give the single person some amount of money, the single person can reject or accept the proposal and so on. Now let's look at the incentives of SPCR: people will want to consult the registry because it is so well curated; vendors will want to enter the registry because people are consulting it; the single person will want to accept the good and reject the bad applicants because these good decisions are what will make the list valuable. Amazing! How such a single proposal has such enourmous features! SPCR are going to take over the internet! ## What TCR enthusiasts get wrong? TCR people think they can just list a set of incentives for something to work and assume that something will work. Mix that with Ethereum hype and they think theyve found something unique and revolutionary, while in fact they're just making a poor implementation of "democracy" systems that fail almost everywhere. The life is not about listing a set of "incentives" and then considering the problems solved. Almost everybody on the Earth has the incentive for being rich: being rich has a lot of advantages over being poor, however not all people get rich! Why are the incentives failing? Curating lists is a hard problem, it involves a lot of knowledge about the problem that just holding a token won't give you, it involves personal preferences, politics, it involves knowing where is the real limit between "good" and "bad". The Single Person list may have a good result if the single person doing the curation is knowledgeable and honest (yes, you can game the system to accept your uncle's scissors and not their competitor that is much better, for example, without losing the entire list reputation), same thing for TCRs, but it can also fail miserably, and it can appear to be good but be in fact not so good. In all cases, the list entries will reflect the preferences of people choosing and other things that aren't taken into the incentives equation of TCR enthusiasts. ## We don't need lists The most important point to be made, although unrelated to the incentive story, is that we don't need lists. Imagine you're looking for a scissor. You don't want someone to tell if scissor A or B are "good" or "bad", or if A is "better" than B. You want to know if, for your specific situation, or for a class of situations, A will serve well, and do that considering A's price and if A is being sold near you and all that. Scissors are the worst example ever to make this point, but I hope you get it. If you don't, try imagining the same example with schools, doctors, plumbers, food, whatever. Recommendation systems are badly needed in our world, and TCRs don't solve these at all.

@ 3bf0c63f:aefa459d

# idea: "numbeo" with satoshis This site has a crowdsourced database of cost-of-living in many countries and cities: <https://www.numbeo.com/cost-of-living/> and it sells the data people write there freely. It's wrong! Could be an fruitful idea to pay satoshis for people to provide data.

@ 3bf0c63f:aefa459d

# Lightning and its fake HTLCs Lightning is terrible but can be very good with two tweaks. ## How Lightning would work without HTLCs In a world in which HTLCs didn't exist, Lightning channels would consist only of balances. Each commitment transaction would have two outputs: one for peer `A`, the other for peer `B`, according to the current state of the channel. When a payment was being attempted to go through the channel, peers would just trust each other to update the state when necessary. For example: 1. Channel `AB`'s balances are `A[10:10]B` (in sats); 2. `A` sends a 3sat payment through `B` to `C`; 3. `A` asks `B` to route the payment. Channel `AB` doesn't change at all; 4. `B` sends the payment to `C`, `C` accepts it; 5. Channel `BC` changes from `B[20:5]C` to `B[17:8]C`; 6. `B` notifies `A` the payment was successful, `A` acknowledges that; 7. Channel `AB` changes from `A[10:10]B` to `A[7:13]B`. This in the case of a success, everything is fine, no glitches, no dishonesty. But notice that `A` could have refused to acknowledge that the payment went through, either because of a bug, or because it went offline forever, or because it is malicious. Then the channel `AB` would stay as `A[10:10]B` and `B` would have lost 3 satoshis. ## How Lightning would work with HTLCs HTLCs are introduced to remedy that situation. Now instead of commitment transactions having always only two outputs, one to each peer, now they can have HTLC outputs too. These HTLC outputs could go to either side dependending on the circumstance. Specifically, the peer that is sending the payment can redeem the HTLC after a number of blocks have passed. The peer that is receiving the payment can redeem the HTLC if they are able to provide the preimage to the hash specified in the HTLC. Now the flow is something like this: 1. Channel `AB`'s balances are `A[10:10]B`; 2. `A` sends a 3sat payment through `B` to `C`: 3. `A` asks `B` to route the payment. Their channel changes to `A[7:3:10]B` (the middle number is the HTLC). 4. `B` offers a payment to `C`. Their channel changes from `B[20:5]C` to `B[17:3:5]C`. 5. `C` tells `B` the preimage for that HTLC. Their channel changes from `B[17:3:5]C` to `B[17:8]C`. 6. `B` tells `A` the preimage for that HTLC. Their channel changes from `A[7:3:10]B` to `A[7:13]B`. Now if `A` wants to trick `B` and stop responding `B` doesn't lose money, because `B` knows the preimage, `B` just needs to publish the commitment transaction `A[7:3:10]B`, which gives him 10sat and then redeem the HTLC using the preimage he got from `C`, which gives him 3 sats more. `B` is fine now. In the same way, if `B` stops responding for any reason, `A` won't lose the money it put in that HTLC, it can publish the commitment transaction, get 7 back, then redeem the HTLC after the certain number of blocks have passed and get the other 3 sats back. ## How Lightning doesn't really work The example above about how the HTLCs work is very elegant but has a fatal flaw on it: transaction fees. Each new HTLC added increases the size of the commitment transaction and it requires yet another transaction to be redeemed. If we consider fees of 10000 satoshis that means any HTLC below that is as if it didn't existed because we can't ever redeem it anyway. In fact the Lightning protocol explicitly dictates that if HTLC output amounts are below the fee necessary to redeem them they shouldn't be created. What happens in these cases then? Nothing, the amounts that should be in HTLCs are moved to the commitment transaction miner fee instead. So considering a transaction fee of 10000sat for these HTLCs if one is sending Lightning payments below 10000sat that means they operate according to the _unsafe protocol_ described in the first section above. It is actually worse, because consider what happens in the case a channel in the middle of a route has a glitch or one of the peers is unresponsive. The other node, thinking they are operating in the _trustless protocol_, will proceed to publish the commitment transaction, i.e. close the channel, so they can redeem the HTLC -- only then they find out they are actually in the _unsafe protocol_ realm and there is no HTLC to be redeemed at all and they lose not only the money, but also the channel (which costed a lot of money to open and close, in overall transaction fees). One of the biggest features of the _trustless protocol_ are the payment proofs. Every payment is identified by a hash and whenever the payee releases the preimage relative to that hash that means the payment was complete. The incentives are in place so all nodes in the path pass the preimage back until it reaches the payer, which can then use it as the proof he has sent the payment and the payee has received it. This feature is also lost in the _unsafe protocol_: if a glitch happens or someone goes offline on the preimage's way back then there is no way the preimage will reach the payer because no HTLCs are published and redeemed on the chain. The payee may have received the money but the payer will not know -- but the payee will lose the money sent anyway. ## The end of HTLCs So considering the points above you may be sad because in some cases Lightning doesn't use these magic HTLCs that give meaning to it all. But the fact is that no matter what anyone thinks, HTLCs are destined to be used less and less as time passes. The fact that over time Bitcoin transaction fees tend to rise, and also the fact that multipart payment (MPP) are increasedly being used on Lightning for good, we can expect that soon no HTLC will ever be big enough to be actually worth redeeming and we will be at a point in which not a single HTLC is real and they're all fake. Another thing to note is that the current _unsafe protocol_ kicks out whenever the HTLC amount is below the Bitcoin transaction fee would be to redeem it, but this is not a reasonable algorithm. It is not reasonable to lose a channel and then pay 10000sat in fees to redeem a 10001sat HTLC. At which point does it become reasonable to do it? Probably in an amount many times above that, so it would be reasonable to even increase the threshold above which real HTLCs are made -- thus making their existence more and more rare. These are good things, because we don't actually need HTLCs to make a functional Lightning Network. ## We must embrace the _unsafe protocol_ and make it better So the _unsafe protocol_ is not necessarily very bad, but the way it is being done now is, because it suffers from two big problems: 1. Channels are lost all the time for no reason; 2. No guarantees of the proof-of-payment ever reaching the payer exist. The first problem we fix by just stopping the current practice of closing channels when there are no real HTLCs in them. That, however, creates a new problem -- or actually it exarcebates the second: now that we're not closing channels, what do we do with the expired payments in them? These payments should have either been canceled or fulfilled before some block x, now we're in block x+1, our peer has returned from its offline period and one of us will have to lose the money from that payment. That's fine because it's only 3sat and it's better to just lose 3sat than to lose both the 3sat and the channel anyway, so either one would be happy to eat the loss. Maybe we'll even split it 50/50! No, that doesn't work, because it creates an attack vector with peers becoming unresponsive on purpose on one side of the route and actually failing/fulfilling the payment on the other side and making a profit with that. So we actually need to know who is to blame on these payments, even if we are not going to act on that imediatelly: we need some kind of arbiter that both peers can trust, such that if one peer is trying to send the preimage or the cancellation to the other and the other is unresponsive, when the unresponsive peer comes back, the arbiter can tell them they are to blame, so they can willfully eat the loss and the channel can continue. Both peers are happy this way. If the unresponsive peer doesn't accept what the arbiter says then the peer that was operating correctly can assume the unresponsive peer is malicious and close the channel, and then blacklist it and never again open a channel with a peer they know is malicious. Again, the differences between this scheme and the current Lightning Network are that: a. In the current Lightning we always close channels, in this scheme we only close channels in case someone is malicious or in other worst case scenarios (the arbiter is unresponsive, for example). b. In the current Lightning we close the channels without having any clue on who is to blame for that, then we just proceed to reopen a channel with that same peer even in the case they were actively trying to harm us before. ## What is missing? An arbiter. The Bitcoin blockchain is the ideal arbiter, it works in the best possible way if we follow the _trustless protocol_, but as we've seen we can't use the Bitcoin blockchain because it is expensive. Therefore we need a new arbiter. That is the hard part, but not unsolvable. Notice that we don't need an absolutely perfect arbiter, anything is better than nothing, really, even an unreliable arbiter that is offline half of the day is better than what we have today, or an arbiter that lies, an arbiter that charges some satoshis for each resolution, anything. Here are some suggestions: - random nodes from the network selected by an algorithm that both peers agree to, so they can't cheat by selecting themselves. The only thing these nodes have to do is to store data from one peer, try to retransmit it to the other peer and record the results for some time. - a set of nodes preselected by the two peers when the channel is being opened -- same as above, but with more handpicked-trust involved. - some third-party cloud storage or notification provider with guarantees of having open data in it and some public log-keeping, like Twitter, GitHub or a [Nostr](https://github.com/fiatjaf/nostr) relay; - peers that get paid to do the job, selected by the fact that they own some token (I know this is stepping too close to the shitcoin territory, but could be an idea) issued in a [Spacechain](https://www.youtube.com/watch?v=N2ow4Q34Jeg); - a Spacechain itself, serving only as the storage for a bunch of `OP_RETURN`s that are published and tracked by these Lightning peers whenever there is an issue (this looks wrong, but could work). ## Key points 1. Lightning with HTLC-based routing was a cool idea, but it wasn't ever really feasible. 2. HTLCs are going to be abandoned and that's the natural course of things. 3. It is actually good that HTLCs are being abandoned, but 4. We must change the protocol to account for the existence of fake HTLCs and thus make the bulk of the Lightning Network usage viable again. ## See also - [Ripple and the problem of the decentralized commit](nostr:naddr1qqyrxcmzxa3nxv34qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cjrqar6) - [The Lightning Network solves the problem of the decentralized commit](nostr:naddr1qqyx2vekxg6rsvejqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ccs2twc)

@ 3bf0c63f:aefa459d

# IPFS problems: Conceit IPFS is trying to do many things. The IPFS leaders are revolutionaries who think they're smarter than the rest of the entire industry. The fact that they've first proposed a protocol for peer-to-peer distribution of immutable, content-addressed objects, then later tried to fix [that same problem](nostr:naddr1qqyrqen9xf3nvdpeqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cmdjnnj) using their own half-baked solution (IPNS) is one example. Other examples are their odd appeal to decentralization in a very non-specific way, their excessive [flirtation with Ethereum](nostr:naddr1qqyxxdpev5cnsvpkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cta4a2e) and their never-to-be-finished can-never-work-as-advertised _Filecoin_ project. They could have focused on just making the infrastructure for distribution of objects through hashes (not saying this would actually be a good idea, but it had some potential) over a peer-to-peer network, but in trying to reinvent the entire internet they screwed everything up.

@ 3bf0c63f:aefa459d

# There's a problem with using Git concepts for everything We've been seeing a surge in applications that use Git to store other things than code, or that are based on Git concepts and so enable "forking, merging and distributed collaboration" for things like blogs, recipes, literature, music composition, normal files in a filesystem, databases. The problem with all this is they will either: 1. assume the user will commit manually and expect that commit to be composed by a set of meaningful changes, and the commiter will also add a message to the commit, describing that set of meaningful, related changes; or 2. try to make the committing process automatic and hide it from the user, so will producing meaningless commits, based on random changes in many different files (it's not "files" if we are talking about a recipe or rows in a table, but let's say "files" for the sake of clarity) that will probably not be related and not reduceable to a meaningful commit message, or maybe the commit will contain only the changes to a single file, and its commit message would be equivalent to "updated `<name of the file>`". Programmers, when using Git, _think in Git_, i.e., they work with version control in their minds. They try hard to commit together only sets of meaningful and related changes, even when they happen to make unrelated changes in the meantime, and that's why there are commands like `git add -p` and many others. Normal people, to whom many of these git-based tools are intended to (and even programmers when out of their code-world), are much less prone to _think in Git_, and that's why another kind of abstraction for fork-merge-collaborate in non-code environments must be used.

@ 3bf0c63f:aefa459d

# Custom spreadsheets The idea was to use it to make an app that would serve as [_custom database for everything_](nostr:naddr1qqyxgcejv5unzd33qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cz3va32) and interact with the spreadsheet so people could play and calculate with their values after they were created by the custom app, something like an MS Access integrated with Excel? My first attempt that worked (I believe there was an attempt before but I have probably deleted it from everywhere) was this `react-microspreadsheet` thing (at the time called `react-spreadsheet` before I donated the npm name to someone who asked): - <https://github.com/fiatjaf/react-microspreadsheet> This was a very good spreadsheet component that did many things current "react spreadsheet" components out there don't do. It had formulas; support for that handle thing that you pulled with the mouse and it autofilled cells with a pattern; it had keyboard navigation with Ctrl, Shift, Ctrl+Shift; it had that thing through which you copy-pasted formulas and they would change their parameters depending on where you pasted them (implemented in a very poor manner because I was using and thinking about Excel in [baby mode][you-suck-at-excel] at the time). Then I tried to make it into "a small sheet you can share" kind of app through assemblymade.com, and eventually as I tried to add more things bugs began to appear. Then there was `cycle6-spreadsheet`: - <https://github.com/fiatjaf/spreadsheet-cycle6> If I remember well this was very similar to the other one, although made almost 2 years after. Despite having the same initial goal of the other (the multi-app custom database thing) it only yielded: - [Sidesheet](https://chrome.google.com/webstore/detail/sidesheet/iheklhbgdljkmijlfajakikbgemncmf), a Chrome extension that opened a spreadsheet on the side of the screen that you could use to make calculations and so on. It worked, but had too many bugs that probably caused me to give up entirely. I'm not sure which of the two spreadsheets above powers <http://sheets.alhur.es>. [you-suck-at-excel]: <https://www.youtube.com/watch?v=0nbkaYsR94c>

@ 3bf0c63f:aefa459d

# notes on "Economic Action Beyond the Extent of the Market", Per Bylund Source: <https://www.youtube.com/watch?v=7St6pCipCB0> Markets work by dividing labour, but that's not as easy as it seems in the Adam Smith's example of a pin factory, because 1. a pin factory is not a market, so there is some guidance and orientation, some sort of central planning, inside there that a market doesn't have; 2. it is not clear how exactly the production process will be divided, it is not obvious as in "you cut the thread, I plug the head". Dividing the labour may produce efficiency, but it also makes each independent worker in the process more fragile, as they become dependent on the others. This is partially solved by having a lot of different workers, so you do not depend on only one. If you have many, however, they must agree on where one part of the production process starts and where it ends, otherwise one's outputs will not necessarily coincide with other's inputs, and everything is more-or-less broken. That means some level of standardization is needed. And indeed the market has constant incentives to standardization. The statist economist discourse about standardization is that only when the government comes with a law that creates some sort of standardization then economic development can flourish, but in fact the market creates standardization all the time. Some examples of standardization include: * programming languages, operating systems, internet protocols, CPU architectures; * plates, forks, knifes, glasses, tables, chairs, beds, mattresses, bathrooms; * building with concrete, brick and mortar; * money; * musical instruments; * light bulbs; * CD, DVD, VHS formats and others alike; * services that go into every production process, like lunch services, restaurants, bakeries, cleaning services, security services, secretaries, attendants, porters; * multipurpose steel bars; * practically any tool that normal people use and require a little experience to get going, like a drilling machine or a sanding machine; etc. Of course it is not that you find standardization in all places. Specially when the market is smaller or new, standardization may have not arrived. There remains the truth, however, that division of labour has the potential of doing good. More than that: every time there are more than one worker doing the same job in the same place of a division of labour chain, there's incentive to create a new subdivision of labour. From the fact that there are at least more than one person doing the same job as another in our society we must conclude that someone must come up with an insight about an efficient way to divide the labour between these workers (and probably actually implement it), that hasn't happened for all kinds of jobs. But to come up with division of labour outside of a factory, some market actors must come up with a way of dividing the labour, actually, determining where will one labour stop and other start (and that almost always needs some adjustments and in fact extra labour to hit the tips), and also these actors must bear the uncertainty and fragility that division of labour brings when there are not a lot of different workers and standardization and all that. In fact, when an entrepreneur comes with a radical new service to the market, a service that does not fit in the current standard of division of labour, he must explain to his potential buyers what is the service and how the buyer can benefit from it and what he will have to do to adapt its current production process to bear with that new service. That's has happened not long ago with * services that take food orders from the internet and relay these to the restaurants; * hostels for cheap accommodation for young travellers; * Uber, Airbnb, services that take orders and bring homemade food from homes to consumers and similars; * all kinds of software-as-a-service; * electronic monitoring service for power generators; * mining planning and mining planning software; and many other industry-specific services. ## See also * [Profits, not wages, as the originary factor](nostr:naddr1qqyrge3hxa3rqce4qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c7x67pu) * [Per Bylund's insight](nostr:naddr1qqyxvdtzxscxzcenqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cuq3unj)

@ 3bf0c63f:aefa459d

# P2P reputation thing Each node shares a blob of the reputations they have, which includes a confidence number. The number comes from the fact that reputations are inherited from other nodes they trust and averaged by their confidence in these. Everything is mixed for plausible deniability. By default a node only shares their stuff with people they manually add, to prevent government from crawling everybody's database. Also to each added friend nodes share a different identity/pubkey (like giving a new Bitcoin address for every transaction) (derived from hip32) (and since each identity can only be contacted by one other entity the node filters incoming connections to download their database: "this identity already been used? no, yes, used with which peer?"). ## Network protocol Maybe the data uploader/offerer initiates connection to the receiver over Tor so there's only a Tor address for incoming data, never an address for a data source, i.e. everybody has an address, but only for requesting data. How to request? Post an encrypted message in an IRC room or something similar (better if messages are stored for a while) targeted to the node/identity you want to download from, along with your Tor address. Once the node sees that it checks if you can download and contacts you. The encrypted messages could have the target identity pubkey prefix such that the receiving node could try to decrypt only some if those with some probability of success. Nodes can choose to share with anyone, share only with pre-approved people, share only with people who know one of their addresses/entities (works like a PIN, you give the address to someone in the street, that person can reach you, to the next person you give another address etc., you can even have a public address and share limited data with that). ## Data model Each entry in a database should be in the following format: ``` internal_id : real_world_identifier [, real_world_identifier...] : tag ``` Which means you can either associate one or multiple real world identifier with an internal id and associate the real person designated by these identifiers with a tag. the tag should be part of the standard or maybe negotiated between peers. it can be things like `scammer`, `thief`, `tax collector` etc., or `honest`, `good dentist` etc. defining good enough labels may be tricky. `internal_id` should be created by the user who made the record about the person. At first this is not necessary, but additional bloat can be added to the protocol if the federated automated message posting boards are working in the sense that each user can ask for more information about a given id and the author of that record can contact the person asking for information and deliver free text to them with the given information. For this to work the internal id must be a public key and the information delivered must be signed with the correspondent private key, so the receiver of the information will know it's not just some spammer inventing stuff, but actually the person who originated that record.

@ 3bf0c63f:aefa459d

# gravity IPFS is nice as a personal archiving tool (edit: it's not). You store a bunch of data and make it available to the public. The problem is that no one will ever know you have that data, therefore you need a place to publish it somewhere. Gravity was an attempt of being the tool for this job. It was a website that showcased the collections from users, and it was also a command-line client that used your IPFS keys for authentication and allowed you to paste IPFS URIs and names and descriptions. The site was intended to be easy to run so you could have multiple stellar bodies aggregating content and interact with them all in a standardized manner. It also had an ActivityPub/"fediverse" integration so people could follow Gravity server users from Mastodon and friends and see new data they published as "tweets". - <https://github.com/fiatjaf/gravity> ## See also - [How IPFS is broken](nostr:naddr1qqyxgdfsxvck2dtzqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c8y87ll) - [litepub](nostr:naddr1qqyxzcecxs6x2c3sqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823czz6dgn)

@ 3bf0c63f:aefa459d

# TiddlyWiki remoteStorage [TiddlyWiki](https://tiddlywiki.com/) is very good and useful, but since at this time I used multiple computers during the week, it wouldn't work for me to use it as a single file on my computer, so I had to hack its internal tiddler saving mechanism to instead save the raw data of each tiddler to [remoteStorage](https://remotestorage.io/) and load them from that place also (ok, there was in theory a plugin system, but I had to read and understand the entire unformatted core source-code anyway). There was also a [server](https://github.com/fiatjaf/tiddlywiki-remotestorage-server) that fetched tiddlywikis from anyone's remoteStorage buckets (after authorization) and served these to the world, a quick and nice way to publish a TiddlyWiki -- which is a problem all people in TiddlyWiki struggle against. - <https://github.com/fiatjaf/tiddlywiki-remotestorage> - <https://tiddly.alhur.es/> ## See also - [hledger-web](nostr:naddr1qqyrsefkvvck2efkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cffvz7c) - [LessPass remoteStorage](nostr:naddr1qqyrsctpxfjnqepeqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cfa6z2z)

@ 3bf0c63f:aefa459d

# Democracia na América Alexis de Tocqueville escreveu um livro só elogiando o sistema político dos Estados Unidos. E mesmo tendo sido assim, e mesmo tendo escrito o seu livro quase 100 anos antes do mais precoce sinal de decadência da democracia na América, percebeu coisas que até hoje quase ninguém percebe: o mandato da suprema corte é um enorme poder, uma força centralizadora, imune ao voto popular e com poderes altamente indefinidos e por isso mesmo ilimitados. Não sei se ele concluiu, porém, que não existe nem pode existir balanço perfeito entre poderes. Sempre haverá furos. De qualquer maneira, o homem é um gênio apenas por ter percebido isso e outras coisas, como o fato da figura do presidente, também obviamente um elemento centralizador, não ser tão poderosa quanto a figura de um rei da França, por exemplo. Mas ao mesmo tempo, por entre o véu de elogios (sempre muito sóbrios) deixou escapar que provavelmente também achava que não poderia durar para sempre a fraqueza do cargo de presidente. - [Democracy as a failed open-network protocol](nostr:naddr1qqyrxvtxxf3nse3sqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ccyra4y) - [Família e propriedade](nostr:naddr1qqyrwwpnxesnqvmrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c4s2ruz) - [Liberalismo oitocentista](nostr:naddr1qqyr2wfev5uxgwpsqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c2z2jc9)

@ 3bf0c63f:aefa459d

# busca múltipla na estante virtual  A single-page app made in Elm with a Go backend that scrapped estantevirtual.com.br in real-time for search results of multiple different search terms and aggregated the results per book store, so when you want to buy many books you can find the stores that have the biggest part of what you want and buy everything together, paying less for the delivery fee. It had a very weird unicode issue I never managed to solve, something with the encoding estantevirtual.com.br used. I also planned to build the entire checkout flow directly in this UI, but then decided it wasn't worth it. The search flow only was already good enough. - <https://estantevirtual.alhur.es/> - <https://github.com/fiatjaf/estantevirtual>

@ 3bf0c63f:aefa459d

# A crappy zk-rollups explanation attempt (Considering the example of zksync.io) (Also, don't believe me on any of this.) 1. They are sidechains. 2. You move tokens to the sidechain by depositing it on an Ethereum contract. Then your account is credited in the sidechain balance. 3. Then you can make payments inside the sidechain by signing transactions and sending them to a central operator. 4. The central operator takes transactions from a bunch of people, computes the new sidechain balances state and publishes a hash of that state to the Ethereum contract. 5. The idea is that a single transaction in the blockchain contains a bunch of sidechain transactions. 6. The operator also sends to the contract an abbreviated list of the sidechain transactions. The trick is making all signatures condensed in a single zero-knowledge proof which is enough for the contract to verify that the transition from the previous state to the new is good. 7. Apparently they can fit 500 sidechain transactions in one mainchain transaction (each is 12 bytes). So I believe it's fair to say all this zk-rollup fancyness could be translated into "a system for aggregating transactions". 8. I don't understand how the zero-knowledge proof works, but in this case it is a SNARK and requires a trusted setup, which I imagine is similar to [this one](https://petertodd.org/2016/cypherpunk-desert-bus-zcash-trusted-setup-ceremony). * [On "zk-rollups" applied to Bitcoin](nostr:naddr1qqyrzd3jvymkxve5qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c2c9rut)

@ 3bf0c63f:aefa459d

# requesthub.xyz  An app that was supposed to be some kind of declarative connector between two services, one that sent webhooks and the other that accepted HTTP requests of any kind. You would proxy and transform the webhooks using RequestHub and create a new request to the other service using that data. The transformations were declared in the almighty [`jq`](https://stedolan.github.io/jq/) language. It worked and had other functions planned for the future, but I guess it was too arcane, even I was confused by it sometimes. Also it was very prone to spam (involuntary) attacks like some that did happen. Maybe it would work better in a world of anonymous satoshi payments.  Later I tried to revive it as a Trello Power-Up that would create comments on cards automatically according to some transformation rules and webhooks received. - [requesthub.xyz](https://archive.is/nGyH3) - <https://github.com/fiatjaf/requesthub.xyz> - <https://github.com/fiatjaf/requesthub-trello>

@ 3bf0c63f:aefa459d

# Eltoo Read [the paper](https://blockstream.com/eltoo.pdf), it's actually nice and small. You can read only everything up to section 4.2 and it will be enough. Done. Ok, you don't want to. Or you tried but still want to read here. Eltoo is a way of keeping payment channel state that works better than the original scheme used in _Lightning_. Since Lightning is a bunch of different protocols glued together, it can It replace just the part the previously dealed with keeping the payment channel. Eltoo works like this: A and B want a payment channel, so they create a multisig transaction with deposits from both -- or from just one, doesn't matter. That transaction is only spendable if both cooperate. So if one of them is unresponsive or non-cooperative the other must have a way to get his funds back, so they also create an **update** transaction but don't publish it to the blockchain. That update transaction spends to a **settlement** transaction that then distributes the money back to A and B as their balances say. If they are cooperative they can change the balances of the channel by just creating new **update** transactions and **settlement** transactions and number them like 1, 2, 3, 4 etc.  _Solid arrows means a transaction is presigned to spend only that previous other transaction; dotted arrows mean it's a floating transaction that can spend any of the previous._ ## Why do they need and update and a settlement transaction? Because if B publishes **update2** (in which his balances were greater) A needs some time to publish **update4** (the latest, which holds correct state of balances). Each **update** transaction can be spent by any newer **update** transaction immediately or by its own specific **settlement** transaction only after some time -- or some blocks. Hopefully you got that. ## How do they close the channel? If they're cooperative they can just agree to spend the funding transaction, that first multisig transaction I mentioned, to whatever destinations they want. If one party isn't cooperating the other can just publish the latest **update** transaction, wait a while, then publish its **settlement** transaction. ## How is this better than the previous way of keeping channel states? Eltoo is better because nodes only have to keep the last set of update and settlement transactions. Before they had to keep all intermediate state updates. ## If it is so better why didn't they do it first? Because they didn't have the idea. And also because they needed an update to the Bitcoin protocol that allowed the presigned **update** transactions to spend any of the previous **update** transactions. This protocol update is called `SIGHASH_NOINPUT`[^anyprevout], you've seen this name out there. By marking a transaction with `SIGHASH_NOINPUT` it enters a mystical state and becomes a _floating transaction_ that can be bound to any other [transaction](nostr:naddr1qqyr2e34xycnyephqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cun2wfz) as long as its unlocking script matches the locking script. ## Why can't update2 bind itself to update4 and spend that? Good question. It can. But then it can't anymore, because Eltoo uses `OP_CHECKLOCKTIMEVERIFY` to ensure that doesn't actually check not a locktime, but a sequence. It's all arcane stuff. And then Eltoo **update** transactions are numbered and their lock/unlock scripts will only match if a transaction is being spent by another one that's greater than it. ## Do Eltoo channels expire? No. ## What is that "on-chain protocol" they talk about in the paper? That's just an example to guide you through how the off-chain protocol works. Read carefully or don't read it at all. The off-chain mechanics is different from the on-chain mechanics. Repeating: the on-chain protocol is useless in the real world, it's just a didactic tool. [^anyprevout]: Later `SIGHASH_NOINPUT` was modified to fit better with Taproot and Schnorr signatures and renamed to `SIGHASH_ANYPREVOUT`.

@ 3bf0c63f:aefa459d

# Truthcoin as a spacechain To be clear, the term "spacechain" here refers only to the general concept of [blindly merge-mined (BMM)](https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5) chains without a native money-token, not including the ["spacecoins"](https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-sidechains-the-perpetual-one-way-peg-96cb2f8ac302). The basic idea is that for [Truthcoin/Hivemind](https://bitcoinhivemind.com/) to work we need 1. Balances of Votecoin tokens, i.e. a way to keep track of who owns how much of the _oracle corporation_; 2. Bitcoin tokens to be used for buying and selling prediction market shares, i.e. money to gamble; 3. A blockchain, i.e. some timestamping service that emits blocks ordered with transactions and can keep track of internal state and change the state -- including the balances of the Votecoin tokens and of the Bitcoin tokens that are assigned to individual prediction markets according to predefined rules; A spacechain, i.e. a blindly merge-mined chain, gives us 1 and 3. We can just write any logic for that and that should be very easy. It doesn't give us 2, and it also has the problem of how the spacechain users can pay the spacechain miners (which is why the spacecoins were envisioned in the first place, but we don't have spacecoins here). But remember we have votecoins already. Votecoins (VTC) should represent a share in the _oracle corporation_, which means they entitle their holders to some revenue -- even though they also burden their holders with the duty to vote in event outcomes (at the risk of losing part of their own votecoin balance) --, and they can be exchanged, so we can assume they will have _some_ value. So we could in theory use these valuable tokens to pay the spacechain miners. That wouldn't be great because it pervert their original purpose and wouldn't solve the problem 2 from above -- unless we also used the votecoins to bet in which case they wouldn't be just another shitcoin in the planet with no network effect competing against Bitcoin and would just cause harm to humanity. What we can do instead is to create a native mechanism for issuing virtual Bitcoin tokens (vBTC) in this chain, collaterized by votecoins, then we can use these vBTC to both gamble (solve problem 2) and pay miners (fix the hole in the spacechain BMM design). For example, considering the VTC to be worth 0.001 BTC, any VTC holder could put 0.005 VTC and get 0.001 vBTC, then use to gamble or sell to others who want to gamble. The VTC holder still technically owns the VTC and can and must still participate in the oracle decisions. They just have to pay the BTC back before they can claim their VTC back if they want to send it elsewhere. They stand to gain by selling vBTC if there is a premium for vBTC over BTC (i.e. people want to gamble) and then rebuying vBTC back once that premium goes away or reverts itself. For this scheme to work the chain must know the exchange rate between VTC and BTC, which can be provided by the _oracle corporation_ itself.

@ 3bf0c63f:aefa459d

# idea: Link sharing incentivized by satoshis See <https://2key.io/> and <https://www.youtube.com/watch?v=CEwRv7qw4fY&t=192s>. I think the general idea is to make a self-serving automatic referral program for individual links, but I wasn't patient enough to deeply understand neither of the above ideas. Solving fraud is an issue. People can fake clicks. One possible solution is to track conversions instead of clicks, but then it's too complex as the receiving side must do stuff and be trusted to do it correctly.

@ 3bf0c63f:aefa459d

# Haskell Monoids You've seen that `<>` syntax and noticed it is imported from `Data.Monoid`? I've always thought `<>` was a pretty complex mathematical function and it was very odd that people were using it for `Text` values, like `"whatever " <> textValue <> " end."`. It turns out `Text` is a Monoid. That means it implements the Monoid class (or typeclass), that means it has a particular way of being concatenated. Any list could be a Monoid, any abstraction you can think of for which it makes sense to concatenate could be a Monoid, and it would use the same `<>` syntax. What exactly `<>` would do with that value when concatenating depends on its typeclass implementation of Monoid. We can assume, for example, that `Text` implements Monoid by just joining the text bytes, and now we can use `<>` without getting puzzled about it.

@ 3bf0c63f:aefa459d

# O mito do objetivo O insight [deste cara](https://www.youtube.com/watch?v=dXQPL9GooyI) segundo o qual buscar objetivos fixos, além de matar a criatividade, ainda não consegue atingir o tal objetivo -- que é uma coisa na qual eu sempre acreditei, embora sem muitas confirmações e (talvez por isso) sem dizê-lo abertamente --, combina com a idéia geral de que todas as estruturas sociais que valem alguma coisa surgem do jogo e brincadeira. A seriedade, que é o oposto da brincadeira, é representada aqui pelo objetivo. Pessoas muito sérias com um planejamento e um objetivo final, tudo esquematizado. --- Na verdade esse insight é bem manjado. Até eu mesmo já o tinha mencionado, citando Taleb em [Processos Antifrágeis](nostr:naddr1qqyryv3hxfsnvvm9qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c5jshx7). E finalmente há esta tirinha que eu achei aleatoriamente e que bem o representa: [](https://dilbert.com/strip/2004-04-17)

@ 3bf0c63f:aefa459d

# Soft-forks on Bitcoin A traditional soft-fork activation plays out like this: 1. someone makes a proposal 2. if half-dozen respected Core developers like that, they implement it and talk about it 3. everybody loves the idea 4. they ship it in Bitcoin Core 5. miners turn it onA traditional soft-fork activation plays out like this: A traditional soft-fork failure plays out like this: 1. someone makes a proposal 2. if half-dozen respected Core developers do not care much about the idea, they don't do anything 3. people fight on Twitter about the merits of the idea forever A sidechain activation within [BIP-300](nostr:naddr1qq9xgunfwejkx6rpd9hqzythwden5te0ve5kzar2v9nzucm0d5pzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqr4gumtjfnp) plays out like this: 1. someone writes the sidechain software 2. if a bunch of people are interested in that, they start playing with it in test mode 3. if it is really good people launch a proposal to miners 4. miners vote yes or no

@ 3bf0c63f:aefa459d

# O Bitcoin como um sistema social humano Afinal de contas, o que é o Bitcoin? Não vou responder a essa pergunta explicando o que é uma "blockchain" ou coisa que o valha, como todos fazem muito pessimamente. [A melhor explicação em português que eu já vi está aqui](nostr:naddr1qqrky6t5vdhkjmspz9mhxue69uhkv6tpw34xze3wvdhk6q3q80cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsxpqqqp65wp3k3fu), mas mesmo assim qualquer explicação jamais será definitiva. A explicação apenas do protocolo, do que faz um programa `bitcoind` sendo executado em um computador e como ele se comunica com outros em outros computadores, e os incentivos que estão em jogo para garantir com razoável probabilidade que se chegará a um consenso sobre quem é dono de qual parte de qual transação, apesar de não ser complicada demais, exigirá do iniciante que seja compreendida muitas vezes antes que ele se possa se sentir confortável para dizer que entende um pouco. E essa parte _técnica_, apesar de ter sido o insight fundamental que gerou o evento miraculoso chamado Bitcoin, não é a parte mais importante, hoje. Se fosse, várias dessas outras moedas seriam concorrentes do Bitcoin, mas não são, e jamais poderão ser, porque elas não estão nem próximas de ter os outros elementos que compõem o Bitcoin. São eles: 1. A estrutura O Bitcoin é um sistema composto de partes independentes. Existem programadores que trabalham no protocolo e aplicações, e dia após dia novos programadores chegam e outros saem, e eles trabalham às vezes em conjunto, às vezes sem que um se dê conta do outro, às vezes por conta própria, às vezes pagos por empresas interessadas. Existem os usuários que realizam validação completa, isto é, estão rodando algum programa do Bitcoin e contribuindo para a difusão dos blocos, das transações, rejeitando usuários malignos e evitando ataques de mineradores mal-intencionados. Existem os poupadores, acumuladores ou os proprietários de bitcoins, que conhecem as possibilidades que o mundo reserva para o Bitcoin, esperam o dia em que o padrão-Bitcoin será uma realidade mundial e por isso mesmo atributem aos seus bitcoins valores muito mais altos do que os preços atuais de mercado, agarrando-se a eles. Especuladores de "criptomoedas" não fazem parte desse sistema, nem tampouco empresas que [aceitam pagamento](https://bitpay.com/) em bitcoins para imediatamente venderem tudo em troca de dinheiro estatal, e menos ainda [gente que usa bitcoins](https://www.investimentobitcoin.com/) e [a própria marca Bitcoin](https://www.xdex.com.br/) para aplicar seus golpes e coisas parecidas. 2. A cultura Mencionei que há empresas que pagam programadores para trabalharem no código aberto do BitcoinCore ou de outros programas relacionados à rede Bitcoin -- ou mesmo em aplicações não necessariamente ligadas à camada fundamental do protocolo. Nenhuma dessas empresas interessadas, porém, controla o Bitcoin, e isso é o elemento principal da cultura do Bitcoin. O propósito do Bitcoin sempre foi ser uma rede aberta, sem chefes, sem política envolvida, sem necessidade de pedir autorização para participar. O fato do próprio Satoshi Nakamoto ter voluntariamente desaparecido das discussões foi fundamental para que o Bitcoin não fosse visto como um sistema dependente dele ou que ele fosse entendido como o chefe. Em outras "criptomoedas" nada disso aconteceu. O chefe supremo do Ethereum continua por aí mandando e desmandando e inventando novos elementos para o protocolo que são automaticamente aceitos por toda a comunidade, o mesmo vale para o Zcash, EOS, Ripple, Litecoin e até mesmo para o Bitcoin Cash. Pior ainda: Satoshi Nakamoto saiu sem nenhum dinheiro, nunca mexeu nos milhares de bitcoins que ele gerou nos primeiros blocos -- enquanto os líderes dessas porcarias supramencionadas cobraram uma fortuna pelo direito de uso dos seus primeiros usuários ou estão aí a até hoje receber dividendos. Tudo isso e mais outras coisas -- a mentalidade anti-estatal e entusiasta de sistemas p2p abertos dos membros mais proeminentes da comunidade, por exemplo -- faz com que um ar de liberdade e suspeito de tentativas de centralização da moeda sejam percebidos e execrados. 3. A história A noção de que o Bitcoin não pode ser controlado por ninguém passou em 2017 por [dois testes](https://www.forbes.com/sites/ktorpey/2019/04/23/this-key-part-of-bitcoins-history-is-what-separates-it-from-competitors/#49869b41ae5e) e saiu deles muito reforçada: o primeiro foi a divisão entre Bitcoin (BTC) e Bitcoin Cash (BCH), uma obra de engenharia social que teve um sucesso mediano em roubar parte da marca e dos usuários do verdadeiro Bitcoin e depois a tentativa de tomada por completo do Bitcoin promovida por mais ou menos as mesmas partes interessadas chamada SegWit2x, que fracassou por completo, mas não sem antes atrapalhar e difundir mentiras para todos os lados. Esses dois fracassos provaram que o Bitcoin, mesmo sendo uma comunidade desorganizada, sem líderes claros, está imune à [captura por grupos interessados](https://en.wikipedia.org/wiki/Regulatory_capture), o que é mais um milagre -- ou, como dizem, um [ponto de Schelling](https://en.wikipedia.org/wiki/Focal_point_(game_theory)). Esse período crucial na história do Bitcoin fez com ficasse claro que _hard-forks_ são essencialmente incompatíveis com a natureza do protocolo, de modo que no futuro não haverá a possibilidade de uma sugestão como a de imprimir mais bitcoins do que o que estava programado sejam levadas a sério (mas, claro, sempre há a possibilidade da cultura toda se perder, as pessoas esquecerem a história e o Bitcoin ser cooptado, eis a importância da auto-educação e da difusão desses princípios).

@ 3bf0c63f:aefa459d

# Liberalismo oitocentista Quando comecei a ler sobre "liberalismo" na internet havia sempre umas listas de livros recomendados, uns Ludwig von Mises, Milton Friedman e Alexis de Tocqueville. "A Democracia na América". Pra mim parecia estranho aquele papo de democracia quando eu estava interessado era em como funcionaria um mercado livre, sem regulações e tal. Parece que Tocqueville era uma herança do mesmo povo que adorava a expressão "liberalismo clássico". O liberalismo clássico era uma coisa política que ia contra a monarquia e em favor da democracia, e aí Tocqueville se encaixava muito bem. Poucos anos se passaram e tudo mudou. Agora acho que alguém lendo na internet não vai ver menção nenhuma a Tocqueville ou liberalismo clássico, essa chatice de democracia e suas [chatices legalistas](nostr:naddr1qqyr2df58qekxce3qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c0n53d9). O "libertarianismo", também um nome infeliz, tomou conta de tudo, e cresceu muito mais do que o movimento liberal-da-internet jamais imaginou que seria possível. Os libertários brasileiros são anarquistas, detestam a democracia, reconhecem nela um [vetor de ataque](nostr:naddr1qqyrxvtxxf3nse3sqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ccyra4y) dos socialistas a qualquer pontinha de livre-mercado que exista -- e às liberdades individuais dos cidadãos (este aqui ainda um ponto em comum com os liberais oitocentistas). São inclusive muito mais propensos a defender a monarquia do que a democracia. E isso é uma coisa boa. Finalmente uma pessoa pode defender princípios razoáveis de livre-mercado e individualismo sem precisar se associar com o movimento setecentistas e oitocentista que fez coisas boas, mas também foi responsável por coisas horríveis como a revolução francesa e todos os seus absurdos, e de onde saiu todo o movimento socialista. - [Democracia na América](nostr:naddr1qqyrzc3ev3jn2vrpqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c8ynvrd)

@ 3bf0c63f:aefa459d

# A chatura Kelsen Já presenciei várias vezes este mesmo fenômeno: há um grupo de amigos ou proto-amigos conversando alegremente sobre o conservadorismo, o tradicionalismo, o anti-comunismo, o liberalismo econômico, o livre-mercado, a filosofia olavista. É um momento incrível porque para todos ali é sempre tão difícil encontrar alguém com quem conversar sobre esses assuntos. Eis que um deles fez faculdade de direito. Tendo feito faculdade de direito por acreditar que essa lhe traria algum conhecimento (já que todos os filósofos de antigamente faziam faculdade de direito!) esse sujeito que fez faculdade de direito, ao contrário dos demais, não toma conhecimento de que a sua faculdade é uma nulidade, uma vergonha, uma época da sua vida jogada fora -- e crê que são valiosos os conteúdos que lhe foram transmitidos pelos professores que estão ali para ajudar os alunos a se preparem para o exame da OAB. Começa a falar de Kelsen. A teoria pura do direito, hermenêutica, filosofia do direito. A conversa desanda. Ninguém sabe o que dizer. A filosofia pura do direito não está errada porque é apenas uma lógica pura, e como tal não pode ser refutada; e por não ter qualquer relação com o mundo não há como puxar um outro assunto a partir dela e sair daquele território. Os jovens filósofos perdem ali as próximas duas horas falando de Kelsen, Kelsen. Uma presença que os ofende, que parece errada, que tem tudo para estar errada, mas está certa. Certa e inútil, ela lhes devora as idéias, que são digeridas pela teoria pura do direito. É imperativo estabelecer esta regra: só é permitido falar de Kelsen se suas idéias não forem abordadas ou levadas em conta. Apenas elogios ou ofensas serão tolerados: Kelsen era um bom homem; Kelsen era um bobão. Pronto. --- Eis aqui um exemplo gravado do fenômeno descrito acima: <https://www.youtube.com/watch?v=CKb8Ij5ThvA:> o Flavio Morgenstern todo simpático, elogiando o outro, falando coisas interessantes sobre o mundo; e o outro, que devia ser amigo dele antes de entrar para a faculdade de direito, começa a falar de Kelsen, com bastante confiança de que aquilo é relevante, e dá-lhe Kelsen, filosofia do direito, toda essa chatice tremenda.