28.1 Release Notes ===================== Bitcoin Core version 28.1 is now available from: - 🌐 <https://bitcoincore.org/bin/bitcoin-core-28.1> - 🧲 <magnet:?xt=urn:btih:60837ded9c7e11b2a44f2ae7bc8e6fe3a3d7ee5c&dn=bitcoin-core-28.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http://bitcoincore.org/bin/> This release includes new features, various bug fixes and performance improvements, as well as updated translations. Please report bugs using the issue tracker at GitHub: <https://github.com/bitcoin/bitcoin/issues> To receive security and update notifications, please subscribe to: <https://bitcoincore.org/en/list/announcements/join/> How to Upgrade ============== If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes in some cases), then run the installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on macOS) or `bitcoind`/`bitcoin-qt` (on Linux). Upgrading directly from a version of Bitcoin Core that has reached its EOL is possible, but it might take some time if the data directory needs to be migrated. Old wallet versions of Bitcoin Core are generally supported. Running Bitcoin Core binaries on macOS requires self signing. ``` cd /path/to/bitcoin-28.x/bin xattr -d com.apple.quarantine bitcoin-cli bitcoin-qt bitcoin-tx bitcoin-util bitcoin-wallet bitcoind test_bitcoin codesign -s - bitcoin-cli bitcoin-qt bitcoin-tx bitcoin-util bitcoin-wallet bitcoind test_bitcoin ``` Compatibility ============== Bitcoin Core is supported and extensively tested on operating systems using the Linux Kernel 3.17+, macOS 11.0+, and Windows 7 and newer. Bitcoin Core should also work on most other UNIX-like systems but is not as frequently tested on them. It is not recommended to use Bitcoin Core on unsupported systems. Notable changes =============== ### P2P - When the `-port` configuration option is used, the default onion listening port will now be derived to be that port + 1 instead of being set to a fixed value (8334 on mainnet). This re-allows setups with multiple local nodes using different `-port` and not using `-bind`, which would lead to a startup failure in v28.0 due to a port collision. Note that a `HiddenServicePort` manually configured in `torrc` may need adjustment if used in connection with the `-port` option. For example, if you are using `-port=5555` with a non-standard value and not using `-bind=...=onion`, previously Bitcoin Core would listen for incoming Tor connections on `127.0.0.1:8334`. Now it would listen on `127.0.0.1:5556` (`-port` plus one). If you configured the hidden service manually in torrc now you have to change it from `HiddenServicePort 8333 127.0.0.1:8334` to `HiddenServicePort 8333 127.0.0.1:5556`, or configure bitcoind with `-bind=127.0.0.1:8334=onion` to get the previous behavior. (#31223) - #30568 addrman: change internal id counting to int64_t ### Key - #31166 key: clear out secret data in DecodeExtKey ### Build - #31013 depends: For mingw cross compile use `-gcc-posix` to prevent library conflict - #31502 depends: Fix CXXFLAGS on NetBSD ### Test - #31016 test: add missing sync to feature_fee_estimation.py - #31448 fuzz: add cstdlib to FuzzedDataProvider - #31419 test: fix MIN macro redefinition - #31563 rpc: Extend scope of validation mutex in generateblock ### Doc - #31007 doc: add testnet4 section header for config file ### CI - #30961 ci: add LLVM_SYMBOLIZER_PATH to Valgrind fuzz job ### Misc - #31267 refactor: Drop deprecated space in `operator""_mst` - #31431 util: use explicit cast in MultiIntBitSet::Fill() Credits ======= Thanks to everyone who directly contributed to this release: - fanquake - Hennadii Stepanov - laanwj - MarcoFalke - Martin Zumsande - Marnix - Sebastian Falbesoner As well as to everyone that helped with translations on [Transifex](https://www.transifex.com/bitcoin/bitcoin/).

# 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.

27.2 Release Notes ===================== Bitcoin Core version 27.2 is now available from: - 🌐 <https://bitcoincore.org/bin/bitcoin-core-27.2/> - 🧲 <magnet:?xt=urn:btih:f21febdf8c54d2a9b09ed54f7eebb909537fb7b0&dn=bitcoin-core-27.2&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http%3A%2F%2Fbitcoincore.org%2Fbin%2F> This release includes various bug fixes and performance improvements, as well as updated translations. Please report bugs using the issue tracker at GitHub: <https://github.com/bitcoin/bitcoin/issues> To receive security and update notifications, please subscribe to: <https://bitcoincore.org/en/list/announcements/join/> How to Upgrade ============== If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes in some cases), then run the installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on macOS) or `bitcoind`/`bitcoin-qt` (on Linux). Upgrading directly from a version of Bitcoin Core that has reached its EOL is possible, but it might take some time if the data directory needs to be migrated. Old wallet versions of Bitcoin Core are generally supported. Compatibility ============== Bitcoin Core is supported and extensively tested on operating systems using the Linux Kernel 3.17+, macOS 11.0+, and Windows 7 and newer. Bitcoin Core should also work on most other Unix-like systems but is not as frequently tested on them. It is not recommended to use Bitcoin Core on unsupported systems. Notable changes =============== ### P2P - #30394 net: fix race condition in self-connect detection ### Init - #30435 init: change shutdown order of load block thread and scheduler ### RPC - #30357 Fix cases of calls to FillPSBT errantly returning complete=true ### PSBT - #29855 psbt: Check non witness utxo outpoint early ### Test - #30552 test: fix constructor of msg_tx ### Doc - #30504 doc: use proper doxygen formatting for CTxMemPool::cs ### Build - #30283 upnp: fix build with miniupnpc 2.2.8 - #30633 Fixes for GCC 15 compatibility ### CI - #30193 ci: move ASan job to GitHub Actions from Cirrus CI - #30299 ci: remove unused bcc variable from workflow Credits ======= Thanks to everyone who directly contributed to this release: - Ava Chow - Cory Fields - Martin Zumsande - Matt Whitlock - Max Edwards - Sebastian Falbesoner - Vasil Dimov - willcl-ark As well as to everyone that helped with translations on [Transifex](https://www.transifex.com/bitcoin/bitcoin/).

This week, it finally happened: I still had a Lightning channel open with a node that hadn't been online for the better part of a year now, so I decided to close the channel unilaterally. But force-closing a channel means you have to broadcast the latest commitment transaction, the pre-set fee of which was only ~1 sat/vB for this one. With LND, if the channel is created as an [anchor channel](https://lightning.engineering/posts/2021-01-28-lnd-v0.12/) (by default only since version 0.12), then the commitment transaction contains small extra outputs (currently 330 sats), which let either channel partner spend one of them into a child transaction that can be created with higher fees to pay for the parent transaction (CPFP). LND even has a built-in command for that: `lncli wallet bumpclosefee` However, this channel was created in the old-school way, and was thus stuck with its low fee. In fact, even the local bitcoin node refused to accept the transaction into its own mempool, so the bitcoin p2p network didn't even know it existed. So how do we get out of this pickle? ## The solution Enter the [mempool.space Accelerator](https://mempool.space/accelerator). It is essentially an automated way to create agreements with various mining pools to mine your low-fee transaction in exchange for an out-of-band payment. Mempool.space coordinates these agreements and out-of-band payments with miners and gets a share from the overall fee for that. Now, if you're in the same situation as I was, you might search for the ID of your closing transaction and find that mempool.space cannot find it. Remember how the local bitcoin node (with mostly default settings) didn't accept it in the first place? ### 1. Get the transaction to be broadcast In your `bitcoin.conf`, add the following line: minrelaytxfee=0 This sets the minimum fee to 0, meaning it will accept and broadcast your transactions, no matter how low the fee is. Restart `bitcoind` and wait a little bit. LND will retry broadcasting the closing transaction every minute or so until it succeeds. At some point you should be able to find it on mempool.space. ### 2. Use the Accelerator to confirm it Once you can see the transaction on [mempool.space](https://mempool.space), you can just click the "Accelerate" button next to the ETA. This will bring you to a page that shows you the estimated share of miners that will include your transaction in their blocks, as well as some acceleration fee options for various transaction fee levels, which you can pay for via the Lightning Network, of course. If you haven't looked into this service before (which I had), then the fees might be a bit of a surprise to you. This thing is **not** cheap! Bumping my fee from 1 sat/vB to ~9 sats/vB cost a whopping 51,500 sats (31 USD that day). Bumping it higher only seemed to add the difference in the transaction fee itself, so the service seems to have cost a flat 50K sats at the time. Unfortunately, this channel wasn't particularly large, so the acceleration fee amounted to ~9% of my remaining channel balance. But 91% of something is better than 100% of nothing, so I actually felt pretty good about it. Next, you will see something like this: [](https://image.nostr.build/76151cc2ae06a93a8fcd97102bf4fa63541f8f3bd19800b96ff1070c9450945c.png) Time to lean back and let the miners work for you. In my case, the ETA was eerily precise. It told me that it would take ~56 minutes to confirm the transaction, and almost exactly an hour later it was mined. ### 3. Wait Now that our transaction is confirmed, our channel is not closed immediately, of course. The [time lock of the HTLC](https://docs.lightning.engineering/the-lightning-network/multihop-payments/hash-time-lock-contract-htlc) protects our channel partner from us broadcasting an old channel state in which our balance might be higher than in the latest state. In my case, it was set to 144 blocks, i.e. ~24 hours. So I checked back the next day, et voilá: channel closed and balance restored. 🥳

# `kind:1` maximalism and the future of other stuff and Nostr decentralization These two problems exist on Nostr today, and they look unrelated at first: 1. People adding more stuff to `kind:1` notes, such as making them editable, or adding special corky syntax thas has to be parsed and rendered in complicated UIs; 2. The _discovery_ of "other stuff" content (i.e. long-form articles, podcasts, calendar events, livestreams etc) is hard due to the fact that most people only use microblogging clients and they often don't appear there for them. Point **2** above has 3 different solutions: - **a.** Just publish everything as `kind:1` notes; - **b.** Publish different things as different kinds, but make microblogging clients fetch all the event kinds from people you follow, then render them natively or use NIP-31, or NIP-89 to point users to other clients that would render them better; - **c.** Publish different things as different kinds, and reference them in `kind:1` notes that would act as announcements to these other events, also relying on NIP-31 and NIP-89 for displaying references and recommending other clients. Solution **a** is obviously very bad, so I won't address it. For a while I have believed solution **b** was the correct one, and many others seem to tacitly agree with it, given that some clients have been fetching more and more event kinds and going out of their way to render them in the same feed where only `kind:1` notes were originally expected to be. I don't think clients doing that is necessarily bad, but I do think this have some centralizing effects on the protocol, as it pushes clients to become bigger and bigger, raising the barrier to entry into the `kind:1` realm. And also in the past I have talked about the fact that I disliked that some clients would display my long-form articles as if they were normal `kind:1` notes and just dump them into the feeds of whoever was following me: nostr:nevent1qqsdk90k9k30vtzwpj6grxys9mvsegu5kkwd4jmpyhlmtjnxet2rvggprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdqy8hwumn8ghj7mn0wd68ytnddaksygpm7rrrljungc6q0tuh5hj7ue863q73qlheu4vywtzwhx42a7j9n5hae35c These and other reasons have made me switch my preference to solution **c**, as it gives the most flexibility to the publisher: whoever wants to announce stuff so it can be _discovered_ can, whoever doesn't don't have to. And it allows microblogging clients the freedom to render just render tweets and having a straightforward barrier between what they can render and what is just a link to an external app or webapp (of course they can always opt to render the referenced content in-app if they want). It also makes the case for microapps more evident. If all microblogging clients become superapps that can render recipe events perfectly why would anyone want to use a dedicated recipes app? I guess there are still reasons, but blurring the line between content kinds in superapps would definitely remove some of the reasons and eventually kill all the microapps. --- That brings us back to point **1** above (the overcomplication of `kind:1` events): if solution **c** is what we're going to, that makes `kind:1` events very special in Nostr, and not just another kind among others. Microblogging clients become the central plaza of Nostr, thus protecting their neutrality and decentralization much more important. Having a lot of clients with different userbases, doing things in slightly different ways, is essential for that decentralization. It's ok if Nostr ends up having just 2 recipe-sharing clients, but it must have dozens of microblogging clients -- and maybe not even full-blown microblogging clients, but other apps that somehow deal with `kind:1` events in multiple ways. It's ok if implementing a client for public audio-rooms is very hard and complicated, but at the same time it should be very simple to write a client that can render a `kind:1` note referencing an audio-room and linking to that dedicated client. I hope you got my point and agreed because this article is ended.

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. [Excepteur](nostr:nprofile1qyt8wumn8ghj7mn0wd68yetvd96x2uewdaexwtcpz4mhxue69uhhyetvv9ujuat50phjummwv5hsqgqmcu9qzj9n7vtd5vl78jyly037wxkyl7vcqflvwy4eqhxjfa4yzyzh27uu) sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. Lorem ipsum dolor sit amet, [consectetur](https://en.wikipedia.org/wiki/Lorem_ipsum) adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo [consequat](nostr:naddr1qvzqqqr4gupzpwcpwjhzrfk2cxs2nj9543htlkjkeegkqhp3tvvzf9ctcf6lwgu6qqgrjvmyv93nwcmxvvukgdmxxfjn2eqwafx). ## A sub heading goes a long way Lorem ipsum dolor sit amet, [consectetur](https://en.wikipedia.org/wiki/Lorem_ipsum) adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut [aliquip ex](npub1qlsc3g0lsl8pw8230w8d9wm6xxcax3f6pkemz5measrmwfxjxteslf2hac) ea commodo [consequat](nprofile1qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgkwaehxw309aex2mrp0yhx6mmnw3ezuur4vghsqgq8uxy2rlu8ect365tm3mftk733k8f52wsdkwc4x70vq7mjf53j7v7hknv0).

25.0 Release Notes ================== Bitcoin Core version 25.0 is now available from: - 🌐 <https://bitcoincore.org/bin/bitcoin-core-25.0/> - 🧲 <magnet:?xt=urn:btih:092358777175c4306602f9b1b523738df4b4610b&dn=bitcoin-core-25.0&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http%3A%2F%2Fbitcoincore.org%2Fbin%2F> This release includes new features, various bug fixes and performance improvements, as well as updated translations. Please report bugs using the issue tracker at GitHub: <https://github.com/bitcoin/bitcoin/issues> To receive security and update notifications, please subscribe to: <https://bitcoincore.org/en/list/announcements/join/> How to Upgrade ============== If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes in some cases), then run the installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on macOS) or `bitcoind`/`bitcoin-qt` (on Linux). Upgrading directly from a version of Bitcoin Core that has reached its EOL is possible, but it might take some time if the data directory needs to be migrated. Old wallet versions of Bitcoin Core are generally supported. Compatibility ============== Bitcoin Core is supported and extensively tested on operating systems using the Linux kernel, macOS 10.15+, and Windows 7 and newer. Bitcoin Core should also work on most other Unix-like systems but is not as frequently tested on them. It is not recommended to use Bitcoin Core on unsupported systems. Notable changes =============== P2P and network changes ----------------------- - Transactions of non-witness size 65 bytes and above are now allowed by mempool and relay policy. This is to better reflect the actual afforded protections against CVE-2017-12842 and open up additional use-cases of smaller transaction sizes. (#26265) New RPCs -------- - The scanblocks RPC returns the relevant blockhashes from a set of descriptors by scanning all blockfilters in the given range. It can be used in combination with the getblockheader and rescanblockchain RPCs to achieve fast wallet rescans. Note that this functionality can only be used if a compact block filter index (-blockfilterindex=1) has been constructed by the node. (#23549) Updated RPCs ------------ - All JSON-RPC methods accept a new [named parameter](https://github.com/bitcoin/bitcoin/blob/master/doc/JSON-RPC-interface.md#parameter-passing) called `args` that can contain positional parameter values. This is a convenience to allow some parameter values to be passed by name without having to name every value. The python test framework and `bitcoin-cli` tool both take advantage of this, so for example: ```sh bitcoin-cli -named createwallet wallet_name=mywallet load_on_startup=1 ``` Can now be shortened to: ```sh bitcoin-cli -named createwallet mywallet load_on_startup=1 ``` - The `verifychain` RPC will now return `false` if the checks didn't fail, but couldn't be completed at the desired depth and level. This could be due to missing data while pruning, due to an insufficient dbcache or due to the node being shutdown before the call could finish. (#25574) - `sendrawtransaction` has a new, optional argument, `maxburnamount` with a default value of `0`. Any transaction containing an unspendable output with a value greater than `maxburnamount` will not be submitted. At present, the outputs deemed unspendable are those with scripts that begin with an `OP_RETURN` code (known as 'datacarriers'), scripts that exceed the maximum script size, and scripts that contain invalid opcodes. - The `testmempoolaccept` RPC now returns 2 additional results within the "fees" result: "effective-feerate" is the feerate including fees and sizes of transactions validated together if package validation was used, and also includes any modified fees from prioritisetransaction. The "effective-includes" result lists the wtxids of transactions whose modified fees and sizes were used in the effective-feerate (#26646). - `decodescript` may now infer a Miniscript descriptor under P2WSH context if it is not lacking information. (#27037) - `finalizepsbt` is now able to finalize a transaction with inputs spending Miniscript-compatible P2WSH scripts. (#24149) Changes to wallet related RPCs can be found in the Wallet section below. Build System ------------ - The `--enable-upnp-default` and `--enable-natpmp-default` options have been removed. If you want to use port mapping, you can configure it using a .conf file, or by passing the relevant options at runtime. (#26896) Updated settings ---------------- - If the `-checkblocks` or `-checklevel` options are explicitly provided by the user, but the verification checks cannot be completed due to an insufficient dbcache, Bitcoin Core will now return an error at startup. (#25574) - Ports specified in `-port` and `-rpcport` options are now validated at startup. Values that previously worked and were considered valid can now result in errors. (#22087) - Setting `-blocksonly` will now reduce the maximum mempool memory to 5MB (users may still use `-maxmempool` to override). Previously, the default 300MB would be used, leading to unexpected memory usage for users running with `-blocksonly` expecting it to eliminate mempool memory usage. As unused mempool memory is shared with dbcache, this also reduces the dbcache size for users running with `-blocksonly`, potentially impacting performance. - Setting `-maxconnections=0` will now disable `-dnsseed` and `-listen` (users may still set them to override). Changes to GUI or wallet related settings can be found in the GUI or Wallet section below. New settings ------------ - The `shutdownnotify` option is used to specify a command to execute synchronously before Bitcoin Core has begun its shutdown sequence. (#23395) Wallet ------ - The `minconf` option, which allows a user to specify the minimum number of confirmations a UTXO being spent has, and the `maxconf` option, which allows specifying the maximum number of confirmations, have been added to the following RPCs in #25375: - `fundrawtransaction` - `send` - `walletcreatefundedpsbt` - `sendall` - Added a new `next_index` field in the response in `listdescriptors` to have the same format as `importdescriptors` (#26194) - RPC `listunspent` now has a new argument `include_immature_coinbase` to include coinbase UTXOs that don't meet the minimum spendability depth requirement (which before were silently skipped). (#25730) - Rescans for descriptor wallets are now significantly faster if compact block filters (BIP158) are available. Since those are not constructed by default, the configuration option "-blockfilterindex=1" has to be provided to take advantage of the optimization. This improves the performance of the RPC calls `rescanblockchain`, `importdescriptors` and `restorewallet`. (#25957) - RPC `unloadwallet` now fails if a rescan is in progress. (#26618) - Wallet passphrases may now contain null characters. Prior to this change, only characters up to the first null character were recognized and accepted. (#27068) - Address Purposes strings are now restricted to the currently known values of "send", "receive", and "refund". Wallets that have unrecognized purpose strings will have loading warnings, and the `listlabels` RPC will raise an error if an unrecognized purpose is requested. (#27217) - In the `createwallet`, `loadwallet`, `unloadwallet`, and `restorewallet` RPCs, the "warning" string field is deprecated in favor of a "warnings" field that returns a JSON array of strings to better handle multiple warning messages and for consistency with other wallet RPCs. The "warning" field will be fully removed from these RPCs in v26. It can be temporarily re-enabled during the deprecation period by launching bitcoind with the configuration option `-deprecatedrpc=walletwarningfield`. (#27279) - Descriptor wallets can now spend coins sent to P2WSH Miniscript descriptors. (#24149) GUI changes ----------- - The "Mask values" is a persistent option now. (gui#701) - The "Mask values" option affects the "Transaction" view now, in addition to the "Overview" one. (gui#708) REST ---- - A new `/rest/deploymentinfo` endpoint has been added for fetching various state info regarding deployments of consensus changes. (#25412) Binary verification ---- - The binary verification script has been updated. In previous releases it would verify that the binaries had been signed with a single "release key". In this release and moving forward it will verify that the binaries are signed by a _threshold of trusted keys_. For more details and examples, see: https://github.com/bitcoin/bitcoin/blob/master/contrib/verify-binaries/README.md (#27358) Low-level changes ================= RPC --- - The JSON-RPC server now rejects requests where a parameter is specified multiple times with the same name, instead of silently overwriting earlier parameter values with later ones. (#26628) - RPC `listsinceblock` now accepts an optional `label` argument to fetch incoming transactions having the specified label. (#25934) - Previously `setban`, `addpeeraddress`, `walletcreatefundedpsbt`, methods allowed non-boolean and non-null values to be passed as boolean parameters. Any string, number, array, or object value that was passed would be treated as false. After this change, passing any value except `true`, `false`, or `null` now triggers a JSON value is not of expected type error. (#26213) Credits ======= Thanks to everyone who directly contributed to this release: - 0xb10c - 721217.xyz - @RandyMcMillan - amadeuszpawlik - Amiti Uttarwar - Andrew Chow - Andrew Toth - Anthony Towns - Antoine Poinsot - Aurèle Oulès - Ben Woosley - Bitcoin Hodler - brunoerg - Bushstar - Carl Dong - Chris Geihsler - Cory Fields - David Gumberg - dergoegge - Dhruv Mehta - Dimitris Tsapakidis - dougEfish - Douglas Chimento - ekzyis - Elichai Turkel - Ethan Heilman - Fabian Jahr - FractalEncrypt - furszy - Gleb Naumenko - glozow - Greg Sanders - Hennadii Stepanov - hernanmarino - ishaanam - ismaelsadeeq - James O'Beirne - jdjkelly@gmail.com - Jeff Ruane - Jeffrey Czyz - Jeremy Rubin - Jesse Barton - João Barbosa - JoaoAJMatos - John Moffett - Jon Atack - Jonas Schnelli - jonatack - Joshua Kelly - josibake - Juan Pablo Civile - kdmukai - klementtan - Kolby ML - kouloumos - Kristaps Kaupe - laanwj - Larry Ruane - Leonardo Araujo - Leonardo Lazzaro - Luke Dashjr - MacroFake - MarcoFalke - Martin Leitner-Ankerl - Martin Zumsande - Matt Whitlock - Matthew Zipkin - Michael Ford - Miles Liu - mruddy - Murray Nesbitt - muxator - omahs - pablomartin4btc - Pasta - Pieter Wuille - Pttn - Randall Naar - Riahiamirreza - roconnor-blockstream - Russell O'Connor - Ryan Ofsky - S3RK - Sebastian Falbesoner - Seibart Nedor - sinetek - Sjors Provoost - Skuli Dulfari - SomberNight - Stacie Waleyko - stickies-v - stratospher - Suhas Daftuar - Suriyaa Sundararuban - TheCharlatan - Vasil Dimov - Vasil Stoyanov - virtu - w0xlt - willcl-ark - yancy - Yusuf Sahin HAMZA As well as to everyone that helped with translations on [Transifex](https://www.transifex.com/bitcoin/bitcoin/).

28.0 Release Notes ================== Bitcoin Core version 28.0 is now available from: - 🌐 <https://bitcoincore.org/bin/bitcoin-core-28.0/> - 🧲 <magnet:?xt=urn:btih:e18e92024fc9d4026cf8cdef174f03c24080fd1f&dn=bitcoin-core-28.0&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http://bitcoincore.org/bin/> This release includes new features, various bug fixes and performance improvements, as well as updated translations. Please report bugs using the issue tracker at GitHub: <https://github.com/bitcoin/bitcoin/issues> To receive security and update notifications, please subscribe to: <https://bitcoincore.org/en/list/announcements/join/> How to Upgrade ============== If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes in some cases), then run the installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on macOS) or `bitcoind`/`bitcoin-qt` (on Linux). Upgrading directly from a version of Bitcoin Core that has reached its EOL is possible, but it might take some time if the data directory needs to be migrated. Old wallet versions of Bitcoin Core are generally supported. Running Bitcoin Core binaries on macOS requires self signing. ``` cd /path/to/bitcoin-28.0/bin xattr -d com.apple.quarantine bitcoin-cli bitcoin-qt bitcoin-tx bitcoin-util bitcoin-wallet bitcoind test_bitcoin codesign -s - bitcoin-cli bitcoin-qt bitcoin-tx bitcoin-util bitcoin-wallet bitcoind test_bitcoin ``` Compatibility ============== Bitcoin Core is supported and extensively tested on operating systems using the Linux Kernel 3.17+, macOS 11.0+, and Windows 7 and newer. Bitcoin Core should also work on most other UNIX-like systems but is not as frequently tested on them. It is not recommended to use Bitcoin Core on unsupported systems. Notable changes =============== Testnet4/BIP94 support ----- Support for Testnet4 as specified in [BIP94](https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki) has been added. The network can be selected with the `-testnet4` option and the section header is also named `[testnet4]`. While the intention is to phase out support for Testnet3 in an upcoming version, support for it is still available via the known options in this release. (#29775) Windows Data Directory ---------------------- The default data directory on Windows has been moved from `C:\Users\Username\AppData\Roaming\Bitcoin` to `C:\Users\Username\AppData\Local\Bitcoin`. Bitcoin Core will check the existence of the old directory first and continue to use that directory for backwards compatibility if it is present. (#27064) JSON-RPC 2.0 Support -------------------- The JSON-RPC server now recognizes JSON-RPC 2.0 requests and responds with strict adherence to the [specification](https://www.jsonrpc.org/specification). See [JSON-RPC-interface.md](https://github.com/bitcoin/bitcoin/blob/master/doc/JSON-RPC-interface.md#json-rpc-11-vs-20) for details. (#27101) JSON-RPC clients may need to be updated to be compatible with the JSON-RPC server. Please open an issue on GitHub if any compatibility issues are found. libbitcoinconsensus Removal --------------------------- The libbitcoin-consensus library was deprecated in 27.0 and is now completely removed. (#29648) P2P and Network Changes ----------------------- - Previously if Bitcoin Core was listening for P2P connections, either using default settings or via `bind=addr:port` it would always also bind to `127.0.0.1:8334` to listen for Tor connections. It was not possible to switch this off, even if the node didn't use Tor. This has been changed and now `bind=addr:port` results in binding on `addr:port` only. The default behavior of binding to `0.0.0.0:8333` and `127.0.0.1:8334` has not been changed. If you are using a `bind=...` configuration without `bind=...=onion` and rely on the previous implied behavior to accept incoming Tor connections at `127.0.0.1:8334`, you need to now make this explicit by using `bind=... bind=127.0.0.1:8334=onion`. (#22729) - Bitcoin Core will now fail to start up if any of its P2P binds fail, rather than the previous behaviour where it would only abort startup if all P2P binds had failed. (#22729) - UNIX domain sockets can now be used for proxy connections. Set `-onion` or `-proxy` to the local socket path with the prefix `unix:` (e.g. `-onion=unix:/home/me/torsocket`). (#27375) - UNIX socket paths are now accepted for `-zmqpubrawblock` and `-zmqpubrawtx` with the format `-zmqpubrawtx=unix:/path/to/file` (#27679) - Additional "in" and "out" flags have been added to `-whitelist` to control whether permissions apply to inbound connections and/or manual ones (default: inbound only). (#27114) - Transactions having a feerate that is too low will be opportunistically paired with their child transactions and submitted as a package, thus enabling the node to download 1-parent-1-child packages using the existing transaction relay protocol. Combined with other mempool policies, this change allows limited "package relay" when a parent transaction is below the mempool minimum feerate. Topologically Restricted Until Confirmation (TRUC) parents are additionally allowed to be below the minimum relay feerate (i.e., pay 0 fees). Use the `submitpackage` RPC to submit packages directly to the node. Warning: this P2P feature is limited (unlike the `submitpackage` interface, a child with multiple unconfirmed parents is not supported) and not yet reliable under adversarial conditions. (#28970) Mempool Policy Changes ---------------------- - Transactions with version number set to 3 are now treated as standard on all networks (#29496), subject to opt-in Topologically Restricted Until Confirmation (TRUC) transaction policy as described in [BIP 431](https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki). The policy includes limits on spending unconfirmed outputs (#28948), eviction of a previous descendant if a more incentive-compatible one is submitted (#29306), and a maximum transaction size of 10,000vB (#29873). These restrictions simplify the assessment of incentive compatibility of accepting or replacing TRUC transactions, thus ensuring any replacements are more profitable for the node and making fee-bumping more reliable. - Pay To Anchor (P2A) is a new standard witness output type for spending, a newly recognised output template. This allows for key-less anchor outputs, with compact spending conditions for additional efficiencies on top of an equivalent `sh(OP_TRUE)` output, in addition to the txid stability of the spending transaction. N.B. propagation of this output spending on the network will be limited until a sufficient number of nodes on the network adopt this upgrade. (#30352) - Limited package RBF is now enabled, where the proposed conflicting package would result in a connected component, aka cluster, of size 2 in the mempool. All clusters being conflicted against must be of size 2 or lower. (#28984) - The default value of the `-mempoolfullrbf` configuration option has been changed from 0 to 1, i.e. `mempoolfullrbf=1`. (#30493) Updated RPCs ------------ - The `dumptxoutset` RPC now returns the UTXO set dump in a new and improved format. Correspondingly, the `loadtxoutset` RPC now expects this new format in the dumps it tries to load. Dumps with the old format are no longer supported and need to be recreated using the new format to be usable. (#29612) - AssumeUTXO mainnet parameters have been added for height 840,000. This means the `loadtxoutset` RPC can now be used on mainnet with the matching UTXO set from that height. (#28553) - The `warnings` field in `getblockchaininfo`, `getmininginfo` and `getnetworkinfo` now returns all the active node warnings as an array of strings, instead of a single warning. The current behaviour can be temporarily restored by running Bitcoin Core with the configuration option `-deprecatedrpc=warnings`. (#29845) - Previously when using the `sendrawtransaction` RPC and specifying outputs that are already in the UTXO set, an RPC error code of `-27` with the message "Transaction already in block chain" was returned in response. The error message has been changed to "Transaction outputs already in utxo set" to more accurately describe the source of the issue. (#30212) - The default mode for the `estimatesmartfee` RPC has been updated from `conservative` to `economical`, which is expected to reduce over-estimation for many users, particularly if Replace-by-Fee is an option. For users that require high confidence in their fee estimates at the cost of potentially over-estimating, the `conservative` mode remains available. (#30275) - RPC `scantxoutset` now returns 2 new fields in the "unspents" JSON array: `blockhash` and `confirmations`. See the scantxoutset help for details. (#30515) - RPC `submitpackage` now allows 2 new arguments to be passed: `maxfeerate` and `maxburnamount`. See the subtmitpackage help for details. (#28950) Changes to wallet-related RPCs can be found in the Wallet section below. Updated REST APIs ----------------- - Parameter validation for `/rest/getutxos` has been improved by rejecting truncated or overly large txids and malformed outpoint indices via raising an HTTP_BAD_REQUEST "Parse error". These requests were previously handled silently. (#30482, #30444) Build System ------------ - GCC 11.1 or later, or Clang 16.0 or later, are now required to compile Bitcoin Core. (#29091, #30263) - The minimum required glibc to run Bitcoin Core is now 2.31. This means that RHEL 8 and Ubuntu 18.04 (Bionic) are no-longer supported. (#29987) - `--enable-lcov-branch-coverage` has been removed, given incompatibilities between lcov version 1 & 2. `LCOV_OPTS` should be used to set any options instead. (#30192) Updated Settings ---------------- - When running with `-alertnotify`, an alert can now be raised multiple times instead of just once. Previously, it was only raised when unknown new consensus rules were activated. Its scope has now been increased to include all kernel warnings. Specifically, alerts will now also be raised when an invalid chain with a large amount of work has been detected. Additional warnings may be added in the future. (#30058) Changes to GUI or wallet related settings can be found in the GUI or Wallet section below. Wallet ------ - The wallet now detects when wallet transactions conflict with the mempool. Mempool-conflicting transactions can be seen in the `"mempoolconflicts"` field of `gettransaction`. The inputs of mempool-conflicted transactions can now be respent without manually abandoning the transactions when the parent transaction is dropped from the mempool, which can cause wallet balances to appear higher. (#27307) - A new `max_tx_weight` option has been added to the RPCs `fundrawtransaction`, `walletcreatefundedpsbt`, and `send`. It specifies the maximum transaction weight. If the limit is exceeded during funding, the transaction will not be built. The default value is 4,000,000 WU. (#29523) - A new `createwalletdescriptor` RPC allows users to add new automatically generated descriptors to their wallet. This can be used to upgrade wallets created prior to the introduction of a new standard descriptor, such as taproot. (#29130) - A new RPC `gethdkeys` lists all of the BIP32 HD keys in use by all of the descriptors in the wallet. These keys can be used in conjunction with `createwalletdescriptor` to create and add single key descriptors to the wallet for a particular key that the wallet already knows. (#29130) - The `sendall` RPC can now spend unconfirmed change and will include additional fees as necessary for the resulting transaction to bump the unconfirmed transactions' feerates to the specified feerate. (#28979) - In RPC `bumpfee`, if a `fee_rate` is specified, the feerate is no longer restricted to following the wallet's incremental feerate of 5 sat/vb. The feerate must still be at least the sum of the original fee and the mempool's incremental feerate. (#27969) GUI Changes ----------- - The "Migrate Wallet" menu allows users to migrate any legacy wallet in their wallet directory, regardless of the wallets loaded. (gui#824) - The "Information" window now displays the maximum mempool size along with the mempool usage. (gui#825) Low-level Changes ================= Tests ----- - The BIP94 timewarp attack mitigation is now active on the `regtest` network. (#30681) - A new `-testdatadir` option has been added to `test_bitcoin` to allow specifying the location of unit test data directories. (#26564) Blockstorage ------------ - Block files are now XOR'd by default with a key stored in the blocksdir. Previous releases of Bitcoin Core or previous external software will not be able to read the blocksdir with a non-zero XOR-key. Refer to the `-blocksxor` help for more details. (#28052) Chainstate ---------- - The chainstate database flushes that occur when blocks are pruned will no longer empty the database cache. The cache will remain populated longer, which significantly reduces the time for initial block download to complete. (#28280) Dependencies ------------ - The dependency on Boost.Process has been replaced with cpp-subprocess, which is contained in source. Builders will no longer need Boost.Process to build with external signer support. (#28981) Credits ======= Thanks to everyone who directly contributed to this release: - 0xb10c - Alfonso Roman Zubeldia - Andrew Toth - AngusP - Anthony Towns - Antoine Poinsot - Anton A - Ava Chow - Ayush Singh - Ben Westgate - Brandon Odiwuor - brunoerg - bstin - Charlie - Christopher Bergqvist - Cory Fields - crazeteam - Daniela Brozzoni - David Gumberg - dergoegge - Edil Medeiros - Epic Curious - Fabian Jahr - fanquake - furszy - glozow - Greg Sanders - hanmz - Hennadii Stepanov - Hernan Marino - Hodlinator - ishaanam - ismaelsadeeq - Jadi - Jon Atack - josibake - jrakibi - kevkevin - kevkevinpal - Konstantin Akimov - laanwj - Larry Ruane - Lőrinc - Luis Schwab - Luke Dashjr - MarcoFalke - marcofleon - Marnix - Martin Saposnic - Martin Zumsande - Matt Corallo - Matthew Zipkin - Matt Whitlock - Max Edwards - Michael Dietz - Murch - nanlour - pablomartin4btc - Peter Todd - Pieter Wuille - @RandyMcMillan - RoboSchmied - Roman Zeyde - Ryan Ofsky - Sebastian Falbesoner - Sergi Delgado Segura - Sjors Provoost - spicyzboss - StevenMia - stickies-v - stratospher - Suhas Daftuar - sunerok - tdb3 - TheCharlatan - umiumi - Vasil Dimov - virtu - willcl-ark As well as to everyone that helped with translations on [Transifex](https://www.transifex.com/bitcoin/bitcoin/).

# How to do curation and businesses on Nostr Suppose you want to start a Nostr business. You might be tempted to make a closed platform that reuses Nostr identities and grabs (some) content from the external Nostr network, only to imprison it inside your thing -- and then you're going to run an amazing AI-powered algorithm on that content and "surface" only the best stuff and people will flock to your app. This will be specially good if you're going after one of the many unexplored niches of Nostr in which reading immediately from people you know doesn't work as you generally want to discover new things from the outer world, such as: - food recipe sharing; - sharing of long articles about varying topics; - markets for used goods; - freelancer work and job offers; - specific in-game lobbies and matchmaking; - directories of accredited professionals; - sharing of original music, drawings and other artistic creations; - restaurant recommendations - and so on. But that is not the correct approach and damages the freedom and interoperability of Nostr, posing a centralization threat to the protocol. Even if it "works" and your business is incredibly successful it will just enshrine you as the head of a _platform_ that controls users and thus is prone to all the bad things that happen to all these platforms. Your company will start to display ads and shape the public discourse, you'll need a big legal team, the FBI will talk to you, advertisers will play a big role and so on. If you are interested in Nostr today that must be because you appreciate the fact that it is not owned by any companies, so it's safe to assume you don't want to be that company that owns it. **So what should you do instead?** Here's an idea in two steps: 1. **Write a Nostr client tailored to the niche you want to cover** If it's a music sharing thing, then the client will have a way to play the audio and so on; if it's a restaurant sharing it will have maps with the locations of the restaurants or whatever, you get the idea. Hopefully there will be a NIP or a NUD specifying how to create and interact with events relating to this niche, or you will write or contribute with the creation of one, because without interoperability this can't be Nostr. The client should work independently of any special backend requirements and ideally be open-source. It should have a way for users to configure to which relays they want to connect to see "global" content -- i.e., they might want to connect to `wss://nostr.chrysalisrecords.com/` to see only the latest music releases accredited by that label or to `wss://nostr.indiemusic.com/` to get music from independent producers from that community. 2. **Run a relay that does all the magic** This is where your value-adding capabilities come into play: if you have that magic sauce you should be able to apply it here. Your service -- let's call it `wss://magicsaucemusic.com/` -- will charge people or do some KYM (know your music) validation or use some very advanced AI sorcery to filter out the spam and the garbage and display the best content to your users who will request the global feed from it (`["REQ", "_", {}]`), and this will cause people to want to publish to your relay while others will want to read from it. You set your relay as the default option in the client and let things happen. Your relay is like your "website" and people are free to connect to it or not. You don't own the network, you're just competing against other websites on a leveled playing field, so you're not responsible for it. Users get seamless browsing across multiple websites, unified identities, a unified interface (that could be different in a different client) and social interaction capabilities that work in the same way for all, and **they do not depend on you, therefore they're more likely to trust you**. --- Does this centralize the network still? But this a simple and easy way to go about the matter and scales well in all aspects. Besides allowing users to connect to specific relays for getting a feed of curated content, such clients should also do all kinds of "social" (i.e. following, commenting etc) activities (if they choose to do that) using the outbox model -- i.e. if I find a musician I like under `wss://magicsaucemusic.com` and I decide to follow them I should keep getting updates from them even if they get banned from that relay and start publishing on `wss://nos.lol` or `wss://relay.damus.io` or whatever relay that doesn't even know anything about music. The hardcoded defaults and manual typing of relay URLs can be annoying. But I think it works well at the current stage of Nostr development. Soon, though, we can create events that recommend other relays or share relay lists specific to each kind of activity so users can get in-app suggestions of relays their friends are using to get their music from and so on. That kind of stuff can go a long way.

# 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".

# a way to do an open and permissionless mesh network I don't have much experience with that so maybe this is all a stupid, but I think that routing in mesh networks is never scalable. It basically always requires all the nodes to keep a full view of the network in order to route packages -- and often there is no incentive for them to do that either. And then the thing is easily spammable but either that problem doesn't happen because the mesh never gets big enough or it has a central committee that decides who can join. The biggest example is, of course, the big ICANN-controlled IP network, that gets all the negatives of being centrally controlled while weirdly getting also all the negatives of being a kinda-decentralized peer-to-peer ad-hoc network between indepent ISPs. A good solution that makes kinda-decentralized (at least open and permissionless) routing possible and replaces node addresses with pubkeys could get rid of ICANN. Once that is done, ad-hoc peering would become more seamless and ISPs wouldn't have to be so big, clunky and centralized, they could slowly split, and non-comercial entities could join the party too by basically just plugging a cable or pointing an antenna at the correct place. ## What is it? One very dumb solution that came to my mind that has a chance of working is one in which each **node** as a keypair and to be reachable by others they announce their address -- for example, using some kind of DNS (on a [spacechain]?) or by directly communicating their address through some other means -- as their public key plus some "routing hints". The _routing hints_ are just pubkeys of other nodes _known to be_ **routers**. Known to whom? Well, this would require some schelling points to naturally appear and the network would be ordered around them, but you are never forced to use them, you have to include as many routing hints as required to ensure that all the people you want to connect to you will eventually be able to, but nothing is ever 100% guaranteed. Such network could probably work with a pure _onion routing_ scheme with all its privacy benefits in some cases; degrading to a _trampoline onion routing_ scheme otherwise, which means it will just be slightly less private the more trampolines you have to use. And every node has to keep track of just a set of routes from them to a bunch of _known routers_ (or trampolines, which in my mind are mostly the same nodes, but are slightly different roles). ## Example Suppose **A** is trying to connect to **B**. **A** is a home computer in the city of Évora, Portugal. **B** is a home computer in the city of Udine, Italy. There is a route (we, the narrator, know) between them that goes like this: **A**--_Ev_--_Li_--_Al_--_Ro_--_Sm_--_Ve_--_Ud_--**B**, in which _Ev_ means the node of an ISP in Évora which directly serves **A**, _Li_ means a big node in Lisboa, _Al_ a node in Algiers, _Ro_ a node in Rome, _Sm_ a node in San Marino, _Ve_ a node in Venice and _Ud_ a gateway node in the mesh of Udine to which **B** is connected. There could be many other routes, but we'll ignore them for now. **B** could have published his address as `<pubkey-B>?hint=<pubkey-Ud>,<pubkey-Ve>,<pubkey-Sm>,<pubkey-Ro>`, which would mean **A** would only have to know a route from _Ev_ up to _Ro_. If _Ro_ is known to be a big router, **A** could easily have a route cached there, and could discover other routes by asking around every now and then too. It wouldn't take a lot of space to have routes cached to some thousands of different known big nodes like that. Then **A** can just wrap an onion with all the coordinates and the message inside and hand it to _Ev_ and it would reach **B**. Inside the message she would also include the full route for a message to be sent back. However, even if **A** doesn't have a route to _Ro_, it could still hope that _Li_ would have, then she could make a special "trampoline" onion that goes _Ev_--_Li_ and then when _Li_ receives it it sees a request to forward the next packet to _Ro_, so _Li_ has the freedom to choose a route from itself to _Ro_ (as long as it knows _Ro_, of course) and from there **A**'s message continues. The same trampolining can exist on **B**'s side, if **B** doesn't have a route from _Ud_ to _Ro_, but knows _Ro_ is likely to have one up to _Ud_ -- or if **B** feels it's not worth including so many hints when most big nodes will have routes to _Ud_, for example, it can publish his address as `<pubkey-B>?hint=<pubkey-Ud>*<pubkey-Ro>` meaning that one should find a route up to _Ro_ and from there ask _Ro_ to trampoline it up to _Ud_. Or, if **B** doesn't expect _Ud_ to be very well-known, but _Sm_ yes, then it could do `<pubkey-B>?hint=<pubkey-Ud>,<pubkey-Sm>*<pubkey-Ro>`. Again, this is just one hint, in practice it would have to have a lot (maybe 10, 20?) other hints, in a tree structure that this querystring syntax isn't very suited for encoding: ``` Ud Tr Pu Za Li Sm * Ro Ba Mi La Ge * Mo Tu ``` (Remember, we're using city name abbreviations here, but each of these would be a specific node, with a specific public key, supposed for the example to be in such a city, but nothing prevents them from being in different cities or that multiple nodes exist in the same city.) ## Summary Basically packets go from node to node, in a sequence established by the sender -- with optional trampolines in between -- until they get to the target. Target responds in the same route. Nodes can be anyone. Focal points form around big nodes, but they can be replaced easily, the receivers just have to stop using them in their hints, so the network is flexible and open.

26.2 Release Notes ================== Bitcoin Core version 26.2 is now available from: - 🌐 <https://bitcoincore.org/bin/bitcoin-core-26.2/> - 🧲 <magnet:?xt=urn:btih:9f9db55bc8fcfe0081904613a4f54cdfe306c789&dn=bitcoin-core-26.2&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http%3A%2F%2Fbitcoincore.org%2Fbin%2F> This release includes new features, various bug fixes and performance improvements, as well as updated translations. Please report bugs using the issue tracker at GitHub: <https://github.com/bitcoin/bitcoin/issues> To receive security and update notifications, please subscribe to: <https://bitcoincore.org/en/list/announcements/join/> How to Upgrade ============== If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes in some cases), then run the installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on macOS) or `bitcoind`/`bitcoin-qt` (on Linux). Upgrading directly from a version of Bitcoin Core that has reached its EOL is possible, but it might take some time if the data directory needs to be migrated. Old wallet versions of Bitcoin Core are generally supported. Compatibility ============== Bitcoin Core is supported and extensively tested on operating systems using the Linux kernel, macOS 11.0+, and Windows 7 and newer. Bitcoin Core should also work on most other Unix-like systems but is not as frequently tested on them. It is not recommended to use Bitcoin Core on unsupported systems. Notable changes =============== ### Script - #29853: sign: don't assume we are parsing a sane TapMiniscript ### P2P and network changes - #29691: Change Luke Dashjr seed to dashjr-list-of-p2p-nodes.us - #30085: p2p: detect addnode cjdns peers in GetAddedNodeInfo() ### RPC - #29869: rpc, bugfix: Enforce maximum value for setmocktime - #28554: bugfix: throw an error if an invalid parameter is passed to getnetworkhashps RPC - #30094: rpc: move UniValue in blockToJSON - #29870: rpc: Reword SighashFromStr error message ### Build - #29747: depends: fix mingw-w64 Qt DEBUG=1 build - #29985: depends: Fix build of Qt for 32-bit platforms with recent glibc - #30151: depends: Fetch miniupnpc sources from an alternative website - #30283: upnp: fix build with miniupnpc 2.2.8 ### Misc - #29776: ThreadSanitizer: Fix #29767 - #29856: ci: Bump s390x to ubuntu:24.04 - #29764: doc: Suggest installing dev packages for debian/ubuntu qt5 build - #30149: contrib: Renew Windows code signing certificate Credits ======= Thanks to everyone who directly contributed to this release: - Antoine Poinsot - Ava Chow - Cory Fields - dergoegge - fanquake - glozow - Hennadii Stepanov - Jameson Lopp - jonatack - laanwj - Luke Dashjr - MarcoFalke - nanlour - willcl-ark As well as to everyone that helped with translations on [Transifex](https://www.transifex.com/bitcoin/bitcoin/).

# 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)

27.1 Release Notes ===================== Bitcoin Core version 27.1 is now available from: - 🌐 <https://bitcoincore.org/bin/bitcoin-core-27.1/> - 🧲 <magnet:?xt=urn:btih:9e7fa35808fee6efc004a4d3b28e5cf9ce7770f2&dn=bitcoin-core-27.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http://bitcoincore.org/bin/> This release includes various bug fixes and performance improvements, as well as updated translations. Please report bugs using the issue tracker at GitHub: <https://github.com/bitcoin/bitcoin/issues> To receive security and update notifications, please subscribe to: <https://bitcoincore.org/en/list/announcements/join/> How to Upgrade ============== If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes in some cases), then run the installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on macOS) or `bitcoind`/`bitcoin-qt` (on Linux). Upgrading directly from a version of Bitcoin Core that has reached its EOL is possible, but it might take some time if the data directory needs to be migrated. Old wallet versions of Bitcoin Core are generally supported. Compatibility ============== Bitcoin Core is supported and extensively tested on operating systems using the Linux Kernel 3.17+, macOS 11.0+, and Windows 7 and newer. Bitcoin Core should also work on most other Unix-like systems but is not as frequently tested on them. It is not recommended to use Bitcoin Core on unsupported systems. Notable changes =============== ### Miniscript - #29853 sign: don't assume we are parsing a sane TapMiniscript ### RPC - #29869 rpc, bugfix: Enforce maximum value for setmocktime - #29870 rpc: Reword SighashFromStr error message - #30094 rpc: move UniValue in blockToJSON ### Indexes - #29776 Fix #29767, set m_synced = true after Commit() ### Gui - #gui812 Fix create unsigned transaction fee bump - #gui813 Don't permit port in proxy IP option ### Test - #29892 test: Fix failing univalue float test ### P2P - #30085 p2p: detect addnode cjdns peers in GetAddedNodeInfo() ### Build - #29747 depends: fix mingw-w64 Qt DEBUG=1 build - #29859 build: Fix false positive CHECK_ATOMIC test - #29985 depends: Fix build of Qt for 32-bit platforms with recent glibc - #30097 crypto: disable asan for sha256_sse4 with clang and -O0 - #30151 depends: Fetch miniupnpc sources from an alternative website - #30216 build: Fix building fuzz binary on on SunOS / illumos - #30217 depends: Update Boost download link ### Doc - #29934 doc: add LLVM instruction for macOS < 13 ### CI - #29856 ci: Bump s390x to ubuntu:24.04 ### Misc - #29691 Change Luke Dashjr seed to dashjr-list-of-p2p-nodes.us - #30149 contrib: Renew Windows code signing certificate Credits ======= Thanks to everyone who directly contributed to this release: - Antoine Poinsot - Ava Chow - Cory Fields - dergoegge - fanquake - furszy - Hennadii Stepanov - Jon Atack - laanwj - Luke Dashjr - MarcoFalke - nanlour - Sjors Provoost - willcl-ark As well as to everyone that helped with translations on [Transifex](https://www.transifex.com/bitcoin/bitcoin/).

# Why relay hints are important Recently [Coracle has removed support](nostr:nevent1qqsfmgthccjuz7quucel20wjanh80sp8nxf5ujgpj5hwdzk8japavzgpzemhxue69uhky6t5vdhkjmn9wgh8xmmrd9skcq3qjlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qca68ht) for following relay hints in Nostr event references. Supposedly Coracle is now relying only on public key hints and `kind:10002` events to determine where to fetch events from a user. That is a catastrophic idea that destroys much of Nostr's flexibility for no gain at all. * Someone makes a post inside a community (either a NIP-29 community or a NIP-87 community) and others want to refer to that post in discussions in the external Nostr world of `kind:1`s -- now that cannot work because the person who created the post doesn't have the relays specific to those communities in their outbox list; * There is a discussion happening in a niche relay, for example, a relay that can only be accessed by the participants of a conference for the duration of that conference -- since that relay is not in anyone's public outbox list, it's impossible for anyone outside of the conference to ever refer to these events; * Some big public relays, say, _relay.damus.io_, decide to nuke their databases or periodically delete old events, a user keeps using that big relay as their outbox because it is fast and reliable, but chooses to archive their old events in a dedicated archival relay, say, _cellar.nostr.wine_, while prudently not including that in their outbox list because that would make no sense -- now it is impossible for anyone to refer to old notes from this user even though they are publicly accessible in _cellar.nostr.wine_; * There are [topical relays](nostr:naddr1qqyrze35vscrzvfcqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c0z85e2) that curate content relating to niche (non-microblogging) topics, say, cooking recipes, and users choose to publish their recipes to these relays only -- but now they can't refer to these relays in the external Nostr world of `kind:1`s because these topical relays are not in their outbox lists. * Suppose a user wants to maintain two different identities under the same keypair, say, one identity only talks about soccer in English, while the other only talks about art history in French, and the user very prudently keeps two different `kind:10002` events in two different sets of "indexer" relays (or does it in some better way of announcing different relay sets) -- now one of this user's audiences cannot ever see notes created by him with their other persona, one half of the content of this user will be inacessible to the other half and vice-versa. * If for any reason a relay does not want to accept events of a certain kind a user may publish to other relays, and it would all work fine if the user referenced that externally-published event from a normal event, but now that externally-published event is not reachable because the external relay is not in the user's outbox list. * If someone, say, Alex Jones, is hard-banned everywhere and cannot event broadcast `kind:10002` events to any of the commonly used index relays, that person will now appear as banned in most clients: in an ideal world in which clients followed `nprofile` and other relay hints Alex Jones could still live a normal Nostr life: he would print business cards with his `nprofile` instead of an `npub` and clients would immediately know from what relay to fetch his posts. When other users shared his posts or replied to it, they would include a relay hint to his personal relay and others would be able to see and then start following him on that relay directly -- now Alex Jones's events cannot be read by anyone that doesn't already know his relay.

Report of how the money Jack donated to the cause in December 2022 is being spent. # Bounties given ## June 2024 - Darashi: 5,000,000 - maintaining nos.today, searchnos, search.nos.today and other experiments - Toshiya: 5,000,000 - keeping the NIPs repo clean and other stuff ## May 2024 - James: 3,500,000 - https://github.com/jamesmagoo/nostr-writer - Yakihonne: 5,000,000 - spreading the word in Asia - Dashu: 9,000,000 - https://github.com/haorendashu/nostrmo ## February 2024 - Viktor: 5,000,000 - https://github.com/viktorvsk/saltivka and https://github.com/viktorvsk/knowstr - Eric T: 5,000,000 - https://github.com/tcheeric/nostr-java - Semisol: 5,000,000 - https://relay.noswhere.com/ and https://hist.nostr.land relays - Sebastian: 5,000,000 - Drupal stuff and [nostr-php](https://github.com/swentel/nostr-php) work - tijl: 5,000,000 - [Cloudron](https://forum.cloudron.io/topic/11146/khatru-pyramid-a-nostr-relay/12), Yunohost and [Fraidycat](https://github.com/kickscondor/fraidycat/pull/269) attempts - Null Kotlin Dev: 5,000,000 - AntennaPod [attempt](https://github.com/AntennaPod/AntennaPod/pull/6945) ## December 2023 - hzrd: 5,000,000 - Nostrudel - awayuki: 5,000,000 - NOSTOPUS illustrations - bera: 5,000,000 - getwired.app - Chris: 5,000,000 - resolvr.io - NoGood: 10,000,000 - nostrexplained.com stories ## October 2023 - SnowCait: 5,000,000 - https://nostter.vercel.app/ and other tools - Shaun: 10,000,000 - https://yakihonne.com/, events and work on Nostr awareness - Derek Ross: 10,000,000 - spreading the word around the world - fmar: 5,000,000 - https://github.com/frnandu/yana - The Nostr Report: 2,500,000 - curating stuff - james magoo: 2,500,000 - the Obsidian plugin: https://github.com/jamesmagoo/nostr-writer ## August 2023 - Paul Miller: 5,000,000 - JS libraries and cryptography-related work - **BOUNTY** tijl: 5,000,000 - https://github.com/github-tijlxyz/wikinostr - gzuus: 5,000,000 - https://nostree.me/ ## July 2023 - syusui-s: 5,000,000 - rabbit, a tweetdeck-like Nostr client: https://syusui-s.github.io/rabbit/ - kojira: 5,000,000 - Nostr fanzine, Nostr discussion groups in Japan, hardware experiments - darashi: 5,000,000 - https://github.com/darashi/nos.today, https://github.com/darashi/searchnos, https://github.com/darashi/murasaki - jeff g: 5,000,000 - https://nostr.how and https://listr.lol, plus other contributions - cloud fodder: 5,000,000 - https://nostr1.com (open-source) - utxo.one: 5,000,000 - https://relaying.io (open-source) - Max DeMarco: 10,269,507 - https://www.youtube.com/watch?v=aA-jiiepOrE - **BOUNTY** optout21: 1,000,000 - https://github.com/optout21/nip41-proto0 (proposed nip41 CLI) - **BOUNTY** Leo: 1,000,000 - https://github.com/leo-lox/camelus (an old relay thing I forgot exactly) ## June 2023 - **BOUNTY**: Sepher: 2,000,000 - a webapp for making lists of anything: https://pinstr.app/ - **BOUNTY**: Kieran: 10,000,000 - implement gossip algorithm on Snort, implement all the other nice things: manual relay selection, following hints etc. - Mattn: 5,000,000 - a myriad of projects and contributions to Nostr projects: https://github.com/search?q=owner%3Amattn+nostr&type=code - **BOUNTY**: lynn: 2,000,000 - a simple and clean git nostr CLI written in Go, compatible with William's original git-nostr-tools; and implement threaded comments on https://github.com/fiatjaf/nocomment. - Jack Chakany: 5,000,000 - https://github.com/jacany/nblog - **BOUNTY**: Dan: 2,000,000 - https://metadata.nostr.com/ ## April 2023 - **BOUNTY**: Blake Jakopovic: 590,000 - event deleter tool, NIP dependency organization - **BOUNTY**: koalasat: 1,000,000 - display relays - **BOUNTY**: Mike Dilger: 4,000,000 - display relays, follow event hints (Gossip) - **BOUNTY**: kaiwolfram: 5,000,000 - display relays, follow event hints, choose relays to publish (Nozzle) - Daniele Tonon: 3,000,000 - Gossip - bu5hm4nn: 3,000,000 - Gossip - **BOUNTY**: hodlbod: 4,000,000 - display relays, follow event hints ## March 2023 - Doug Hoyte: 5,000,000 sats - https://github.com/hoytech/strfry - Alex Gleason: 5,000,000 sats - https://gitlab.com/soapbox-pub/mostr - verbiricha: 5,000,000 sats - https://badges.page/, https://habla.news/ - talvasconcelos: 5,000,000 sats - https://migrate.nostr.com, https://read.nostr.com, https://write.nostr.com/ - **BOUNTY**: Gossip model: 5,000,000 - https://camelus.app/ - **BOUNTY**: Gossip model: 5,000,000 - https://github.com/kaiwolfram/Nozzle - **BOUNTY**: Bounty Manager: 5,000,000 - https://nostrbounties.com/ ## February 2023 - styppo: 5,000,000 sats - https://hamstr.to/ - sandwich: 5,000,000 sats - https://nostr.watch/ - **BOUNTY**: Relay-centric client designs: 5,000,000 sats https://bountsr.org/design/2023/01/26/relay-based-design.html - **BOUNTY**: Gossip model on https://coracle.social/: 5,000,000 sats - Nostrovia Podcast: 3,000,000 sats - https://nostrovia.org/ - **BOUNTY**: Nostr-Desk / Monstr: 5,000,000 sats - https://github.com/alemmens/monstr - Mike Dilger: 5,000,000 sats - https://github.com/mikedilger/gossip ## January 2023 - ismyhc: 5,000,000 sats - https://github.com/Galaxoid-Labs/Seer - Martti Malmi: 5,000,000 sats - https://iris.to/ - Carlos Autonomous: 5,000,000 sats - https://github.com/BrightonBTC/bija - Koala Sat: 5,000,000 - https://github.com/KoalaSat/nostros - Vitor Pamplona: 5,000,000 - https://github.com/vitorpamplona/amethyst - Cameri: 5,000,000 - https://github.com/Cameri/nostream ## December 2022 - William Casarin: 7 BTC - splitting the fund - pseudozach: 5,000,000 sats - https://nostr.directory/ - Sondre Bjellas: 5,000,000 sats - https://notes.blockcore.net/ - Null Dev: 5,000,000 sats - https://github.com/KotlinGeekDev/Nosky - Blake Jakopovic: 5,000,000 sats - https://github.com/blakejakopovic/nostcat, https://github.com/blakejakopovic/nostreq and https://github.com/blakejakopovic/NostrEventPlayground

# 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.

# 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>

25.2 Release Notes ================== Bitcoin Core version 25.2 is now available from: <https://bitcoincore.org/bin/bitcoin-core-25.2> This release includes various bug fixes and performance improvements, as well as updated translations. Please report bugs using the issue tracker at GitHub: <https://github.com/bitcoin/bitcoin/issues> To receive security and update notifications, please subscribe to: <https://bitcoincore.org/en/list/announcements/join/> How to Upgrade ============== If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes in some cases), then run the installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on macOS) or `bitcoind`/`bitcoin-qt` (on Linux). Upgrading directly from a version of Bitcoin Core that has reached its EOL is possible, but it might take some time if the data directory needs to be migrated. Old wallet versions of Bitcoin Core are generally supported. Compatibility ============== Bitcoin Core is supported and extensively tested on operating systems using the Linux kernel, macOS 10.15+, and Windows 7 and newer. Bitcoin Core should also work on most other Unix-like systems but is not as frequently tested on them. It is not recommended to use Bitcoin Core on unsupported systems. Notable changes =============== ### Gui - gui#774 Fix crash on selecting "Mask values" in transaction view ### RPC - #29003 rpc: fix getrawtransaction segfault ### Wallet - #29176 wallet: Fix use-after-free in WalletBatch::EraseRecords - #29510 wallet: `getrawchangeaddress` and `getnewaddress` failures should not affect keypools for descriptor wallets ### P2P and network changes - #29412 p2p: Don't process mutated blocks - #29524 p2p: Don't consider blocks mutated if they don't connect to known prev block Credits ======= Thanks to everyone who directly contributed to this release: - Martin Zumsande - Sebastian Falbesoner - MarcoFalke - UdjinM6 - dergoegge - Greg Sanders As well as to everyone that helped with translations on [Transifex](https://www.transifex.com/bitcoin/bitcoin/).

26.1 Release Notes ================== Bitcoin Core version 26.1 is now available from: - 🌐 <https://bitcoincore.org/bin/bitcoin-core-26.1/> - 🧲 <magnet:?xt=urn:btih:1cae6d38169395d3e841d61c6f6afe25de2edaf9&dn=bitcoin-core-26.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http%3A%2F%2Fbitcoincore.org%2Fbin%2F> This release includes various bug fixes and performance improvements, as well as updated translations. Please report bugs using the issue tracker at GitHub: <https://github.com/bitcoin/bitcoin/issues> To receive security and update notifications, please subscribe to: <https://bitcoincore.org/en/list/announcements/join/> How to Upgrade ============== If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes in some cases), then run the installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on macOS) or `bitcoind`/`bitcoin-qt` (on Linux). Upgrading directly from a version of Bitcoin Core that has reached its EOL is possible, but it might take some time if the data directory needs to be migrated. Old wallet versions of Bitcoin Core are generally supported. Compatibility ============== Bitcoin Core is supported and extensively tested on operating systems using the Linux kernel, macOS 11.0+, and Windows 7 and newer. Bitcoin Core should also work on most other Unix-like systems but is not as frequently tested on them. It is not recommended to use Bitcoin Core on unsupported systems. Notable changes =============== ### Wallet - #28994 wallet: skip BnB when SFFO is enabled - #28920 wallet: birth time update during tx scanning - #29176 wallet: Fix use-after-free in WalletBatch::EraseRecords - #29510 wallet: getrawchangeaddress and getnewaddress failures should not affect keypools for descriptor wallets ### RPC - #29003 rpc: fix getrawtransaction segfault - #28784 rpc: keep .cookie file if it was not generated ### Logs - #29227 log mempool loading progress ### P2P and network changes - #29200 net: create I2P sessions using both ECIES-X25519 and ElGamal encryption - #29412 p2p: Don't process mutated blocks - #29524 p2p: Don't consider blocks mutated if they don't connect to known prev block ### Build - #29127 Use hardened runtime on macOS release builds. - #29195 build: Fix -Xclang -internal-isystem option ### CI - #28992 ci: Use Ubuntu 24.04 Noble for asan,tsan,tidy,fuzz - #29080 ci: Set HOMEBREW_NO_INSTALLED_DEPENDENTS_CHECK to avoid unrelated failures - #29610 ci: Fix "macOS native" job ### Miscellaneous - #28391 refactor: Simplify CTxMempool/BlockAssembler fields, remove some external mapTx access - #29179 test: wallet rescan with reorged parent + IsFromMe child in mempool - #28791 snapshots: don't core dump when running -checkblockindex after loadtxoutset - #29357 test: Drop x modifier in fsbridge::fopen call for MinGW builds - #29529 fuzz: restrict fopencookie usage to Linux & FreeBSD Credits ======= Thanks to everyone who directly contributed to this release: - dergoegge - fanquake - furszy - glozow - Greg Sanders - Hennadii Stepanov - Jon Atack - MarcoFalke - Mark Friedenbach - Martin Zumsande - Murch - Roman Zeyde - stickies-v - UdjinM6 As well as to everyone that helped with translations on [Transifex](https://www.transifex.com/bitcoin/bitcoin/).

27.0 Release Notes ================== Bitcoin Core version 27.0 is now available from: - 🌐 <https://bitcoincore.org/bin/bitcoin-core-27.0/> - 🧲 <magnet:?xt=urn:btih:2b2d123e5e831b245fb1dc5b8b71f89de4a90d00&dn=bitcoin-core-27.0&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http://bitcoincore.org/bin/> This release includes new features, various bug fixes and performance improvements, as well as updated translations. Please report bugs using the issue tracker at GitHub: <https://github.com/bitcoin/bitcoin/issues> To receive security and update notifications, please subscribe to: <https://bitcoincore.org/en/list/announcements/join/> How to Upgrade ============== If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes in some cases), then run the installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on macOS) or `bitcoind`/`bitcoin-qt` (on Linux). Upgrading directly from a version of Bitcoin Core that has reached its EOL is possible, but it might take some time if the data directory needs to be migrated. Old wallet versions of Bitcoin Core are generally supported. Compatibility ============== Bitcoin Core is supported and extensively tested on operating systems using the Linux Kernel 3.17+, macOS 11.0+, and Windows 7 and newer. Bitcoin Core should also work on most other Unix-like systems but is not as frequently tested on them. It is not recommended to use Bitcoin Core on unsupported systems. Notable changes =============== libbitcoinconsensus ------------------- - libbitcoinconsensus is deprecated and will be removed for v28. This library has existed for nearly 10 years with very little known uptake or impact. It has become a maintenance burden. The underlying functionality does not change between versions, so any users of the library can continue to use the final release indefinitely, with the understanding that Taproot is its final consensus update. In the future, libbitcoinkernel will provide a much more useful API that is aware of the UTXO set, and therefore be able to fully validate transactions and blocks. (#29189) mempool.dat compatibility ------------------------- - The `mempool.dat` file created by -persistmempool or the savemempool RPC will be written in a new format. This new format includes the XOR'ing of transaction contents to mitigate issues where external programs (such as anti-virus) attempt to interpret and potentially modify the file. This new format can not be read by previous software releases. To allow for a downgrade, a temporary setting `-persistmempoolv1` has been added to fall back to the legacy format. (#28207) P2P and network changes ----------------------- - BIP324 v2 transport is now enabled by default. It remains possible to disable v2 by running with `-v2transport=0`. (#29347) - Manual connection options (`-connect`, `-addnode` and `-seednode`) will now follow `-v2transport` to connect with v2 by default. They will retry with v1 on failure. (#29058) - Network-adjusted time has been removed from consensus code. It is replaced with (unadjusted) system time. The warning for a large median time offset (70 minutes or more) is kept. This removes the implicit security assumption of requiring an honest majority of outbound peers, and increases the importance of the node operator ensuring their system time is (and stays) correct to not fall out of consensus with the network. (#28956) Mempool Policy Changes ---------------------- - Opt-in Topologically Restricted Until Confirmation (TRUC) Transactions policy (aka v3 transaction policy) is available for use on test networks when `-acceptnonstdtxn=1` is set. By setting the transaction version number to 3, TRUC transactions request the application of limits on spending of their unconfirmed outputs. These restrictions simplify the assessment of incentive compatibility of accepting or replacing TRUC transactions, thus ensuring any replacements are more profitable for the node and making fee-bumping more reliable. TRUC transactions are currently nonstandard and can only be used on test networks where the standardness rules are relaxed or disabled (e.g. with `-acceptnonstdtxn=1`). (#28948) External Signing ---------------- - Support for external signing on Windows has been disabled. It will be re-enabled once the underlying dependency (Boost Process), has been replaced with a different library. (#28967) Updated RPCs ------------ - The addnode RPC now follows the `-v2transport` option (now on by default, see above) for making connections. It remains possible to specify the transport type manually with the v2transport argument of addnode. (#29239) Build System ------------ - A C++20 capable compiler is now required to build Bitcoin Core. (#28349) - MacOS releases are configured to use the hardened runtime libraries (#29127) Wallet ------ - The CoinGrinder coin selection algorithm has been introduced to mitigate unnecessary large input sets and lower transaction costs at high feerates. CoinGrinder searches for the input set with minimal weight. Solutions found by CoinGrinder will produce a change output. CoinGrinder is only active at elevated feerates (default: 30+ sat/vB, based on `-consolidatefeerate`×3). (#27877) - The Branch And Bound coin selection algorithm will be disabled when the subtract fee from outputs feature is used. (#28994) - If the birth time of a descriptor is detected to be later than the first transaction involving that descriptor, the birth time will be reset to the earlier time. (#28920) Low-level changes ================= Pruning ------- - When pruning during initial block download, more blocks will be pruned at each flush in order to speed up the syncing of such nodes. (#20827) Init ---- - Various fixes to prevent issues where subsequent instances of Bitcoin Core would result in deletion of files in use by an existing instance. (#28784, #28946) - Improved handling of empty `settings.json` files. (#29144) Credits ======= Thanks to everyone who directly contributed to this release: - 22388o⚡️ - Aaron Clauson - Amiti Uttarwar - Andrew Toth - Anthony Towns - Antoine Poinsot - Ava Chow - Brandon Odiwuor - brunoerg - Chris Stewart - Cory Fields - dergoegge - djschnei21 - Fabian Jahr - fanquake - furszy - Gloria Zhao - Greg Sanders - Hennadii Stepanov - Hernan Marino - iamcarlos94 - ismaelsadeeq - Jameson Lopp - Jesse Barton - John Moffett - Jon Atack - josibake - jrakibi - Justin Dhillon - Kashif Smith - kevkevin - Kristaps Kaupe - L0la L33tz - Luke Dashjr - Lőrinc - marco - MarcoFalke - Mark Friedenbach - Marnix - Martin Leitner-Ankerl - Martin Zumsande - Max Edwards - Murch - muxator - naiyoma - Nikodemas Tuckus - ns-xvrn - pablomartin4btc - Peter Todd - Pieter Wuille - Richard Myers - Roman Zeyde - Russell Yanofsky - Ryan Ofsky - Sebastian Falbesoner - Sergi Delgado Segura - Sjors Provoost - stickies-v - stratospher - Supachai Kheawjuy - TheCharlatan - UdjinM6 - Vasil Dimov - w0xlt - willcl-ark As well as to everyone that helped with translations on [Transifex](https://www.transifex.com/bitcoin/bitcoin/).

# 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)

# 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.

# 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)

# 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.

## Nostr for The Great Orchestra of Christmas Charity  This Sunday, 28.01.2024 at 18:00 - 19:00 UTC we're inviting you to take pare in a very unique #zapathon Nostrians taking part in this special zapathon that will play in tune with thousands of people playing together with The Great Orchestra of Christmas Charity on their 32nd Grand Finale! Hence the name #orchestrathon **The goal of #orchestrathon is to support the goal of this years Grand Finale, which is: funding equipment for diagnosing, monitoring and rehabilitating lung diseases of patients in pulmonology wards for children and adults in Poland** **That means all bitcoin from zaps will be converted to PLN and donated to The Great of Christmas Charity foundation.** What's The Great Orchestra of Christmas Charity? What is the 32nd Grand Finale?! You'll find all of those answers on Geyser project story, or a few paragraphs below 👇 Now coming back to #orchestrathon... ### What Is #Orchestrathon This Nostr account is a was generated on Geyser and is tied to Geyser project: [Bitcoiners support The Great Orchestra of Christmas Charity](https://geyser.fund/project/greatorchestraofchristmascharity/overview) **That means all zaps sent to this account are at the same time funding Geyser campaing.** So not only you will contribute to the goal in the project, also all the zap comments will be visable there. Ain't that crazy? We can use this campaign **as one giant #orchestrathon client!**  ### Rules are simple: 1. On Sunday at 18.00 - 19.00 we all connect to our relays to join the #orchestrathon 2. For the whole hour - **you can zap this profile**, our posts or comments as crazy! 3. At 19.00 it's culmination of both #orchestrathon and Grand Finale All Nostrians who zap will receive [special badges](https://badges.page/p/npub1cpmvpsqtzxl4px44dp4544xwgu0ryv2lscl3qexq42dfakuza02s4fsapc), depending on the zapped amount (in total):  On Sunday there will be lot's of concerts and events happening all day, culminating with Grand Finale closing at 19.00. We will try to launch a stream on [zap.stream](https://zap.stream/), so we can enjoy Grand Finale and concerts together! This #orchestrathon and Geyser fundraise is organised by Dwadzieścia Jeden, a community of polish Bitcoiners. More about us and Proof of Work in the project story 👇 We're not only Bitcoiners, are also Nostrians, follow us: Dwadzieścia Jeden account: @npub1cpmvpsqtzxl4px44dp4544xwgu0ryv2lscl3qexq42dfakuza02s4fsapc Saunter: @npub1m0sxqk5uwvtjhtt4yw3j0v3k6402fd35aq8832gp8kmer78atvkq9vgcru Fmar: @npub1xpuz4qerklyck9evtg40wgrthq5rce2mumwuuygnxcg6q02lz9ms275ams JesterHodl: @npub18s59mqct7se3xkhxr3epkagvuydwtvhpsacj67shrta8eknynegqttz5c3 Tomek K: @npub14wxtsrj7g2jugh70pfkzjln43vgn4p7655pgky9j9w9d75u465pqvagcye Tom Chojnacki: @npub1m0sxqk5uwvtjhtt4yw3j0v3k6402fd35aq8832gp8kmer78atvkq9vgcru Gracjan Pietras: @npub1trkudtnp7jg3tmy4sz8mepmgs5wdxk9x2esgts25mgkyecrse7js6ptss5 Tomek Waszczyk @npub1ah8phwmfyl2lakr23kt95kea3yavpt4m3cvppawuwkatllnrm4eqtuwdmk # Original Geyser project story ## Saving Lives and Preserving Health  [Dwadzieścia Jeden](https://twitter.com/21BitcoinPolska) a polish node in decentralised bitcoin communities network [Twenty One](https://twentyone.world/), is proud to facilitate bitcoin fundraising for **the biggest, non-governmental, non-profit, charity in Poland — The Great Orchestra of Christmas Charity**. For the past 31 years, GOCC continuously fundraises money for pediatric and elderly care in Poland. Each year, a culmination of the raise occurs during the last Sunday of January in the shape of **The Grand Finale** — a joyful day that when tens of thousands volunteers worldwide, especially kids and teenagers, go on the streets to gather money for the cause, giving donors hear-shaped stickers with logo of the foundation. If you're in Poland on that day, basically every person you'll meet on the street will proudly wear GOCC heart.  The same hear-shaped stickers can be seen in every hospital in Poland on thousands of high quality medical equipment bought by The Great Orchestra. **There is not a single polish family that hasn't benefited in some way from this equipment**, and it saved thousands of lives, especially the little ones.   ## 32nd Grand Finale Goal This year, 32rd Grand Finale will take place on 28th of January. The aim of the 32nd Grand Finale is **post-pandemic lung diseases — the raised funds will be used to purchase equipment for children's and adults' respiratory units.** The Foundation plans to purchase: * equipment for diagnostic imaging, i.a. MRI and ultrasound equipment, * equipment for functional diagnosis, i.a. polysomnographs and portable spirometers, * equipment for endoscopic diagnosis, i.a. navigational bronchoscopy systems and bronchoscopes * equipment for rehabilitation - equipment for pulmonary rehabilitation used in the treatment of patients after lung transplantation * equipment for thoracic surgery, e.g. electrocoagulation systems and cryoprobes. ## The Great Orchestra of Proof of Work * **31 years** of non-stop fundraising for state-of-the-art saving life equipment, [running medical and educational programmes](https://en.wosp.org.pl/medycyna/programy) and [humanitarian aid](https://en.wosp.org.pl/pomagamy) * 2 billion PLN or **~11,781 BTC** raised in total * [Areas of help](https://en.wosp.org.pl/medycyna): children's cardiac surgery, oncology, geriatrics, neonatology, children's nephrology, children's and young people's mental health services, ambulances for children's hospitals, volunteer firefighters & search & rescue units * [Last year Grand Finale](https://en.wosp.org.pl/aktualnosci/ponad-240-milionow-na-walke-z-sepsa) raised over PLN 240 million (**1,410 BTC**) for a goal to fight sepsis * You can check how money from 2022 report (224 376 706 PLN or **~1,321.69 BTC**) raise were spent [here](https://geyser.fund/project/greatorchestraofchristmascharity) (although it's in polish) * In addition to work focused on Poland, [GOCC fundraised money for hospitals in Ukraine and provided substantial humanitarian aid for Ukrainian refugees](https://en.wosp.org.pl/pomagamy/pomagamy-ukrainie), [Polish-Belarusian border crisis](https://en.wosp.org.pl/aktualnosci/wosp-zakonczyla-dzialania-na-granicy), Turkey earthquake victims and more * GOCC is the most-trusted Polish organization and is at the top of the list as the most trusted public entities in Poland  ## What We'll Do With Gathered Funds Gathered bitcoin will be converted to PLN by a polish exchange [Quark](https://quark.house/en/) and donated to The Great Orchestra of Christmas Charity after The Grand Finale which takes place on January 28th.  ## Dwadzieścia Jeden Proof of Work We're a group of polish pleb Bitcoiners that started organising ourselves about 2 years ago. Our activities include: * organising regular [bitcoin meetups](https://www.meetup.com/pl-PL/bitcoin-warsaw) in several cities in Poland, also Nostr meetup in Warsaw * organising [Bitcoin FilmFest and European Halving Party](https://bitcoinfilmfest.com/) in Warsaw * orangepilling and maintaining [map of polish bitcoin merchants in Poland on btcmap.org](https://btcmap.org/community/dwadzie%C5%9Bcia-jeden) * [translating bitcoin FOSS to polish language](https://geyser.fund/project/bitcoininpolish) * [writing and translating articles to polish](https://europeanbitcoiners.com/tag/po/) * giving [talks on bitcoin](https://youtu.be/-DHee2eJKr4?t=1301) * volounteering for helping with bitcoin payments and running bitcoin workshops on non-conferences (eg. [Weekend of Capitalism](https://weekendkapitalizmu.pl/)) * working in human rights centered NGOs and [promoting bitcoin as a tool for protecting human rights](https://youtu.be/MPhkDCd-h2E?si=waZRxu6yxp5-np8O) * ...and we're just starting! ## Find Out More * [Official GOCC website](https://en.wosp.org.pl/) * [Wikipedia page about GOCC](https://en.wikipedia.org/wiki/Great_Orchestra_of_Christmas_Charity) ## Gallery           

# 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)

# 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.

# 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)

# `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/

# 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).

# Gerador de tabelas de todos contra todos I don't remember exactly when I did this, but I think a friend wanted to do software that would give him money over the internet without having to work. He didn't know how to program. He mentioned this idea he had which was some kind of football championship manager solution, but I heard it like this: a website that generated a round-robin championship table for people to print. It is actually not obvious to anyone how to do it, it requires an algorithm that people will not reach casually while thinking, and there was no website doing it in Portuguese at the time, so I made this and it worked and it had a couple hundred daily visitors, and it even generated money from Google Ads (not much)! First it was a Python web app running on Heroku, then Heroku started charging or limiting the amount of free time I could have on their platform, so I migrated it to a static site that ran everything on the client. Since I didn't want to waste my Python code that actually generated the tables I used [Brython](https://brython.info/) to run Python on JavaScript, which was an interesting experience. In hindsight I could have just taken one of the many `round-robin` JavaScript libraries that exist on NPM, so eventually after a couple of more years I did that. I also removed Google Ads when Google decided it had so many requirements to send me the money it was impossible, and then the money started to vanished. - <https://github.com/fiatjaf/tabelas.alhur.es> - <https://tabelas.alhur.es/>

# How being "flexible" can bloat a protocol (A somewhat absurd example, but you'll get the idea) Iimagine some client decides to add support for a variant of nip05 that checks for values at /.well-known/nostr.yaml besides /.well-known/nostr.json. "Why not?", they think, "I like YAML more than JSON, this can't hurt anyone". Then some user makes a nip05 file in YAML and it will work on that client, they will think their file is good since it works on that client. When the user sees that other clients are not recognizing their YAML file, they will complain to the other client developers: "Hey, your client is broken, it is not supporting my YAML file!". The developer of the other client, astonished, replies: "Oh, I am sorry, I didn't know that was part of the nip05 spec!" The user, thinking it is doing a good thing, replies: "I don't know, but it works on this other client here, see?" Now the other client adds support. The cycle repeats now with more users making YAML files, more and more clients adding YAML support, for fear of providing a client that is incomplete or provides bad user experience. The end result of this is that now nip05 extra-officially requires support for both JSON and YAML files. Every client must now check for /.well-known/nostr.yaml too besides just /.well-known/nostr.json, because a user's key could be in either of these. A lot of work was wasted for nothing. And now, going forward, any new clients will require the double of work than before to implement.

# 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._

# Trelew A CLI tool for navigating Trello boards. It used **vorpal** for an "immersive" experience and was pretty good.  - <https://github.com/fiatjaf/trelew>

# superform.xyz This was an app that allowed people to create micro apps powered by forms. Actually just one form I believe. The idea was for the micro apps to be really micro. For example, you want a list of people, but you can only have at most 10 people in the list. Your app could keep a state with list of people already added and reject any other submissions above the specified limit. This would be done with 3 lines of code and provide an automatic form for people to fill with expected data. Another example, you wanted to create a list of people that would go to an event and each would have to bring one item from a list: you created an initial state of a list of the items that should be brought, then specified a form where people could write their names and select the item they would bring, then code that for each submitted form added the name of the person plus the item they would bring to the state while also removing the selected item from the available items. Also 3 or 4 lines of data. Something like this can't be done anywhere else. But also of course it would be arcane and frighten normal people and so on (although I do believe some "normal" people would be able to use such a thing if they needed it, just like they learn to write complex Excel formulas and still don't call themselves programmers). - <https://github.com/fiatjaf/superform.xyz> ## See also - [Etleneum](nostr:naddr1qqyrjcny8qcn2ve4qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823crwzz2w), as it is basically the same core idea of a mutable state that is affected by calls, but Etleneum introduces (and actually forces the usage of) money, both in the sense that it acts as an escrow for contract results and that it mandates the payment of a small amount with each call, so it ends up not serving the same purposes.

# sitio A static site generator that works with imperative code instead of declarative templates and directory structures. It assumes nothing and can be used to transform anything into HTML pages. It uses React so it can be used to generate single-page apps too if you want -- and normal sites that work like single-page apps. It also provides helpers for reading Markdown files, like all static site generator does. A long time after creating this and breaking it while trying to add too many features at once I realized Gatsby also had an imperative engine underlying the default declarative interface that could be used and it was pretty similar to `sitio`. That both made me happy to have arrived at the same results of such an acclaimed tool and sad for the same reason, as Gatsby is the worse static site generator ever created considering user experience. - <https://github.com/fiatjaf/sitio>

# Personagens de jogos e símbolos A sensação de "ser" um personagem em um jogo ou uma brincadeira talvez seja o mais próximo que eu tenha conseguido chegar do entendimento de um símbolo religioso. A hóstia consagrada é, segundo a religião, o corpo de Cristo, mas nossa mente moderna só consegue concebê-la como sendo uma representação do corpo de Cristo. Da mesma forma outras culturas e outras religiões têm símbolos parecidos, inclusive nos quais o próprio participante do ritual faz o papel de um deus ou de qualquer coisa parecida. "Faz o papel" é de novo a interpretação da mente moderna. O sujeito ali _é_ a coisa, mas ele ao mesmo tempo que é também sabe que não é, que continua sendo ele mesmo. Nos jogos de videogame e brincadeiras infantis em que se encarna um personagem o jogador _é_ o personagem. não se diz, entre os jogadores, que alguém está "encenando", mas que ele _é_ e pronto. nem há outra denominação ou outro verbo. No máximo "encarnando", mas já aí já é vocabulário jornalístico feito para facilitar a compreensão de quem está de fora do jogo.

# jiq-web Made with [jq-web](nostr:naddr1qqyrzvrzxqcx2dfsqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c90hqwz), a tool to explore JSON using `jq` that works like [jiq](nostr:naddr1qqyrqvfjv33rxcenqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cd86z7d).  - <https://jq.alhur.es/jiq/> - <https://github.com/fiatjaf/jiq-web> ## See also - [jq-finder](nostr:naddr1qqyryvejvycn2cnpqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ccw20rx)

# The unit test bubble Look at the following piece of Go code: ``` func NewQuery(query []rune) *Query { q := &Query{ query: &[]rune{}, complete: &[]rune{}, } _ = q.Set(query) return q } func NewQueryWithString(query string) *Query { return NewQuery([]rune(query)) } ``` It is taken from a GitHub project with over 2000 stars. Now take a look at these unit tests for the same package: ``` func TestNewQuery(t *testing.T) { var assert = assert.New(t) v := []rune(".name") q := NewQuery(v) assert.Equal(*q.query, []rune(".name")) assert.Equal(*q.complete, []rune("")) } func TestNewQueryWithString(t *testing.T) { var assert = assert.New(t) q := NewQueryWithString(".name") assert.Equal(*q.query, []rune(".name")) assert.Equal(*q.complete, []rune("")) } ``` Now be honest: what are these for? Is this part of an attack to eat all GitHub storage and head them to bankruptcy? ## Also * [my personal approach on using `let`, `const` and `var` in javascript](nostr:naddr1qqyrxcmxvyun2vr9qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cvj9k9l)

# IPFS problems: Inefficiency Imagine you have two IPFS nodes and unique content, created by you, in the first one. From the second, you can connect to the first and everyhing looks right. You then try to fetch that content. After some seconds it starts coming, the progress bar begins to move, that's slow, very slow, doing an rsync would have been 20 times faster. The progress bar halts. You investigate, the second node is not connected to the first anymore. Why, if that was the only source for the file we're trying to fetch? It remains a mistery to this day. You reconnect manually, the progress bar moves again, halts, you're disconnected again. Instead of reconnecting you decide to add the second node to the first node's "Bootstrap" list. I once tried to run an IPFS node on a VPS and store content on S3. There are two S3 datastore plugins available. After fixing some issues in one of them, recompiling go-ipfs, figuring out how to read settings from the IPFS config file, creating an init profile and recompiling again I got the node running. It worked. My idea was to host a bunch of data on that node. Data would be fetched from S3 on demand so there would be cheap and fast access to it from any IPFS node or gateway. IPFS started doing hundreds of calls to S3 per minute – something I wouldn't have known about if I hadn't inserted some log statements in the plugin code, I mean before the huge AWS bill arrived. Apparently that was part of participation on the DHT. Adjusting some settings turned my node into a listen-only thing as I intended, but I'm not 100% sure it would work as an efficient content provider, and I'll never know, as the memory and CPU usage got too high for my humble VPS and I had to turn it down.

# Ripple and the problem of the decentralized commit This is about [Ryan Fugger's Ripple](nostr:naddr1qqyxgenyxe3rzvf4qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c8pp8zu). The summary is: unless everybody is good and well-connected at all times a transaction can always be left in a half-committed state, which creates confusion, erodes trust and benefits no one. If you're unconvinced consider the following protocol flow: 1. A finds a route (A--B--C--D) between her and D somehow; 2. A "prepares" a payment to B, tells B to do the same with C and so on (to prepare means to give B a conditional IOU that will be valid as long as the full payment completes); 3. When the chain of prepared messages reaches D, D somehow "commits" the payment. 4. After the commit, A now _really does_ owe B and so on, and D _really_ knows it has been effectively paid by A (in the form of debt from C) so it can ship goods to A. The most obvious (but wrong) way of structuring this would be for the entire payment chain to be dependent on the reveal of some secret. For example, the "prepare" messages could contain something like "I will pay you as long as you know `p` such that `sha256(p) == h`". The payment flow then starts with D presenting A with an invoice that contains `h`, so D knows `p`, but no one else knows. A can then send the "prepare" message to B and B do the same until it reaches D. When it reaches D, D can be sure that C will pay him because he knows `p` such that `sha256(p) == h`. He then reveals `p` to C, C now reveals it to B and B to A. When A gets it it has a proof that D has received his payment, therefore it is happy to settle it later with B and can prove to an external arbitrator that he has indeed paid D in case D doesn't deliver his products. ## Issues with the naïve flow above ### What if D never reveals `p` to C? Then no one knows what happened. And then 10 years later he arrives at C's house (remember they are friends or have a trust relationship somehow) and demands his payment, and shows `p` to her in a piece of paper. Or worse: go directly to the court and shows C's message that says "I will pay you as long as you know `p` such that `sha256(p) == h`" (but with an actual number instead of "h") and the corresponding `p`. Now the judge has to decide in favor of D. Now C was supposed to do the same with B, but C is not playing with this anymore, has lost all contact with B after they did their final settlement many years ago, no one was expecting this. This clearly can't work. There must be a timeout for these payments. ### What if we have a timeout? Now what if we say the payment expires in one hour. D cannot hold the payment hostage and reveal `p` after 10 years. It must either reveal it before the timeout or conditional IOU will be void. Solves everything! Except no, now it's the time we reach the most dark void of the protocol, the flaw that sucks its life into the abyss: subjectivity and ambiguity. The big issue is that we don't have an independent judge to assert, for example, that D has indeed "revealed" `p` to C in time. C must acknowledge that voluntarily. C could do it using messages over the internet, but these messages are not reliable. C is not reliable. Clocks are not synchronized. Also if we now require C to confirm it has received `p` from D then the "prepare" message means nothing, as for D now just knowing `p` is not enough to claim before an arbitrator that C owes her -- because, again, D also must prove it has shown `p` to C before the timeout, therefore it needs a new signed acknowledgement from C, or from some other party. Let's see a few examples. ### Subjectivity and perverse incentives D could send `p` to C, and C acknowledge it, but then when C goes to B and send it B will not acknowledge it, and claim it's past the time. Now C loses money. Maybe C can not acknowledge it received anything from D before checking first with B? But B will have to check with A too! And it subverts the entire flow of the thing. And now A has a "proof of payment" (knowledge of `p`) without even having to acknowledge anything! In this case knowing `p` or not becomes meaningless as everybody knows `p` without acknowleding it to anyone else. But even if A is honest and sends an "acknowledge" message to B, now B can just sit quiet and enjoy the credit it has just earned from A without ever acknowleding anything to C. It's perverted incentives in every step. ### Ambiguity But isn't this a protocol based on trust?, you ask, isn't C trusting that B will behave honestly already? Therefore if B is dishonest C just has to acknowledge his loss and break his chain of trust with B. No, because C will not know what happened. B can say "I could have sent you an acknowledgement, but was waiting for A, and A didn't send anything" and C won't ever know if that was true. Or B could say "what? You didn't send me `p` at all", and that could be true. B could have been offline when A sent it, there could have been a broken connection or many other things, and B continues: "I was waiting for you to present me with `p`, but you didn't, therefore the payment timed out, you can't come here with `p` now, because now A won't accept it anymore from me". That could be true or could be false, who knows? Therefore it is impossible for trust relationships and reputations to be maintained in such a system without "good fences".[^ln-solution][^ln-issue] [^ln-solution]: The [Lightning Network has a solution](nostr:naddr1qqyx2vekxg6rsvejqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ccs2twc) for the problem of the decentralized commit. [^ln-issue]: Ironically this same ambiguity problem [is being faced by the Lightning Network community](https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002826.html) when trying to create a reputation/payment system to prevent routing abuses. It seems simple when you first think about it: "let each node manage its own trust", but in fact it is somewhat impossible.

# jq-web I took [`jq`](https://stedolan.github.io/jq/)'s C code and compiled it with [Emscripten](http://kripken.github.io/emscripten-site/), then added a wrapper so it would run on a browser with either `asm.js` or WebAssembly. I believe I needed it for [requesthub.xyz](nostr:naddr1qqyxxdf38ycrswfcqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cal6jdg) but I'm not sure I ever used it there. I also intended to use it on another (secret) project that relied on heavy data manipulation on the client, but it turned out to be too slow for that so I opted to use JavaScript directly. Later I used it for a client-side [Etleneum](nostr:naddr1qqyrjcny8qcn2ve4qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823crwzz2w) simulator, but removed it later as it was impossible to replicate most of the Etleneum functionality on the client so the simulator was too broken and confusing. - <https://github.com/fiatjaf/jq-web> ## See also -

# Cadeias, crimes e cidadãos de bem A idéia de ficar dentro duma dessas penitenciárias superlotadas é aterrorizante para qualquer cidadão de bem, logo, nenhum cidadão de bem comete crimes puníveis dessa maneira. Mas os cidadãos de bem já não os cometeriam de qualquer modo, é um outro tipo de gente, que não o cidadão de bem, que comete os piores crimes (não quero dizer que o "cidadão de bem" é melhor do que o outro absolutamente, estou só usando um conceito mais-ou-menos identificável). O problema disso é que todos esses mesmos cidadãos de bem imaginam que a existência da cadeia e da punição-padrão movida pelo Estado afasta do crime milhões de pessoas que, sem isso, cometeriam crimes horríveis, mas que com isso vivem vidas normais. A verdade, me parece, é que quem fica assim tão aterrorizado com a idéia da cadeia e da punição-padrão é a pessoa que já por natureza não cometeria esses crimes.

# Alternatives to Drivechain If Drivechain doesn't get soft-forked into Bitcoin, the alternatives people are left with are: * Altcoins. People who want super-powers (privacy, smart contracts, cheap transactions) move their stake to shitcoins. This doesn't make much sense because even if altcoins had the necessary technology they wouldn't have the base money with which to use the technology, but still this remains an option. * Fully-custodial and trusted systems. Instead of moving their money to a sidechain secured by Drivechain people can use a centralized service with much less safety and subject to all kinds of regulations, hacks and government takedowns. * Federated sidechains, which are the same as custodial systems, but with distributed trust and maybe less, maybe more government involvement. * Less secure sidechain-like constructions, like sidechains secured by a multisig of a fixed set of entities with names, or BTC tokens in other blockchains guaranteed by a collateral denominated in shitcoins which tends to zero. * Corporate takeover. Big banks and giant corporations start buying all the coins and exposing part of them through their closed systems to normal people. Instead of an open network and free market as everybody expected, all meaningful activity now happens inside these legacy evil entities that are already sold to governments from the start. Every time one person goes against Drivechain without proposing something else better, they're condemning bitcoiners to one or many of the above forever.

# Drivechain comparison with Ethereum Ethereum and other "smart contract platforms" capable of running turing-complete code and "developer-friendly" mindset and community have been running for years and they were able to produce a very low number of potentially useful "contracts". What are these contracts, actually? (Considering Ethereum, but others are similar:) they are sidechains that run inside the Ethereum blockchain (and thus their verification and data storage are forced upon all Ethereum nodes). Users can peg-in to a contract by depositing money on it and peg-out by making a contract operation that sends money to a normal Ethereum address. Now be generous and imagine these platforms are able to produce 3 really cool, useful ideas (out of many thousands of attempts): [Bitcoin](nostr:naddr1qqyryveexumnyd3kqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c7nywz4) can copy these, turn them into 3 different sidechains, each running fixed, specific, optimized code. Bitcoin users can now opt to use these platforms by transferring coins to it – all that without damaging the nodes or the consensus protocol that has been running for years, and without forcing anyone to be aware of these chains. The process of turning a useful idea into a sidechain doesn't come spontaneously, and can't be done by a single company (like often happens in Ethereum-land), it must be acknowledge by a rough consensus in the Bitcoin community that that specific sidechain with that specific design is a desirable thing, and ultimately approved by miners, as they're the ones that are going to be in charge of that.

# Thafne venceu o Soletrando 2008. As palavras que Thafne teve que soletrar: "ocioso", "hermético", "glossário", "argênteo", "morfossintaxe", "infra-hepático", "hagiológio". Enquanto isso Eder recebia: "intramuscular", "destilação", "inabitável", "subcutâneo", "homogeneidade", "predecessor", "displicência", "subconsciência", "psicroestesia" (isto segundo [o site da folha][0], donde certamente faltam algumas palavras de Thafne). Sério, "argênteo"? Não é errado dizer que a Globo tentou promover o menino pobre da escola pública do sertão contra a riquinha de Curitiba. O mais espetacular disto é que deu errado e o Brasil inteiro torceu pela Thafne, o que se verifica com uma simples busca no Google. Eis aqui alguns exemplos: * [O problema de Thafne][1] traz comentários tentando incriminar o governo do Estado de Minas Gerais com a vitória forçada de Eder. * [este vídeo mostrando os erros do programa e a vitória triunfal, embora parcial, de Thafne,][2] traz a brilhante descrição "globo de puleira quis complicar a vida da menina!!!!!!!!!!!!!!!!!!!!!!" * [este vídeo, com o mesmo conteúdo,][3], porém chamado "Thafne versus Luciano Huck, o confronto do século", tem, além disto, vários comentários de francos torcedores de Thafne: * "Nossa isso é burrice porq o doutor falou duas vezes como o luciano não prestou atenção logo thafine deu duas patadas no luciano... Proxima luciano presta atenção na pronuncia" * "ele nao pronunciou errado porque é burro, isso foi pra manipular o resultado" * "Gabriel o Bostador ficou pianinho. Babaca do krl" * "Pena que ela perdeu :(" * "verdade... ela que ganhou, o outro só ficou com o título :S" * "A menina deu um banho nesse que além de idiota é BURRO." * e muitos, muitos outros. * [Globo Erra e Luciano Huck dá Vexame][4], um breve artigo descrevendo alguns dos pontos em que Eder foi favorecido. * [esta comunidade do Orkut][5], apenas a maior dentre várias que foram criadas. O movimento de apoio a Thafne é um exemplo entre poucos de união total da nação em prol de uma causa. [0]: <http://www1.folha.uol.com.br/ilustrada/2008/05/407470-aluno-de-escola-publica-de-minas-vence-soletrando-huck-da-vexame.shtml> [1]: <https://misenews.wordpress.com/2012/06/22/o-problema-de-thafne/> [2]: <https://www.youtube.com/watch?v=lNW_QAiptsY> [3]: <https://www.youtube.com/watch?v=Va8XxXgnY-c> [4]: <https://www.putsgrilo.com.br/televisao/soletrando-globo-erra-e-luciano-huck-da-vexame/> [5]: <http://orkut.google.com/c54999457.html>

# IPFS-dropzone Instead of uploading the dropped files to an URL, this subclass of [Dropzone.js](http://www.dropzonejs.com/) publishes them to [IPFS](https://ipfs.io/) with [js-ipfs](https://github.com/ipfs/js-ipfs) (no running local nodes needed). - <https://github.com/fiatjaf/ipfs-dropzone> ## See also - [How IPFS is broken](nostr:naddr1qqyxgdfsxvck2dtzqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c8y87ll)

# Replacing the web with something saner This is a simplification, but let's say that basically there are just 3 kinds of websites: 1. Websites with content: text, images, videos; 2. Websites that run full apps that do a ton of interactive stuff; 3. Websites with some interactive content that uses JavaScript, or "mini-apps"; In a saner world we would have 3 different ways of serving and using these. 1 would be "the web" (and it was for a while, although I'm not claiming here that the past is always better and wanting to get back to the glorious old days). 1 would stay as "the web", just static sites, styled with CSS, no JavaScript whatsoever, but designers can still thrive and make they look pretty. Or it could also be something like [Gemini](https://gemini.circumlunar.space/). Maybe the two protocols could coexist. 2 would be downloadable native apps, much easier to write and maintain for developers (considering that multi-platform and cross-compilation is easy today and getting easier), faster, more polished experience for users, more powerful, integrates better with the computer. (Remember that since no one would be striving to make the same app run both on browsers and natively no one would have any need for Electron or other inefficient bloated solutions, just pure native UI, like the Telegram app, have you seen that? It's fast.) But 2 is mostly for apps that people use every day, something like Google Docs, email (although email is also broken technology), Netflix, Twitter, Trello and so on, and all those hundreds of niche SaaS that people pay monthly fees to use, each tailored to a different industry (although most of functions they all implement are the same everywhere). What do we do with dynamic open websites like StackOverflow, for example, where one needs to not only read, but also search and interact in multiple ways? What about that website that asks you a bunch of questions and then discovers the name of the person you're thinking about? What about that mini-app that calculates the hash of your provided content or shrinks your video, or that one that hosts your image without asking any questions? All these and tons of others would fall into category 3, that of instantly loaded apps that you don't have to install, and yet they run in a sandbox. The key for making category 3 worth investing time into is coming up with some solid grounds, simple enough that anyone can implement in multiple different ways, but not giving the app too much choices. Telegram or Discord bots are super powerful platforms that can accomodate most kinds of app in them. They can't beat a native app specifically made with one purpose, but they allow anyone to provide instantly usable apps with very low overhead, and since the experience is so simple, intuitive and fast, users tend to like it and sometimes even pay for their services. There could exist a protocol that brings apps like that to the open world of (I won't say "web") domains and the websockets protocol -- with multiple different clients, each making their own decisions on how to display the content sent by the servers that are powering these apps. Another idea is that of [Alan Kay](https://www.quora.com/Should-web-browsers-have-stuck-to-being-document-viewers/answer/Alan-Kay-11): to design a nice little OS/virtual machine that can load these apps and run them. Kinda like browsers are today, but providing a more well-thought, native-like experience and framework, but still sandboxed. And I add: abstracting away details about design, content disposition and so on. --- These 3 kinds of programs could coexist peacefully. 2 are just standalone programs, they can do anything and each will be its own thing. 1 and 3, however, are still similar to browsers of today in the sense that you need clients to interact with servers and show to the user what they are asking. But by simplifying everything and separating the scopes properly these clients would be easy to write, efficient, small, the environment would be open and the internet would be saved. ## See also - [On the state of programs and browsers](nostr:naddr1qqyxgdfe8qexvd34qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cd7nk4m)

# A biblioteca infinita Agora esqueci o nome do conto de Jorge Luis Borges em que a tal biblioteca é descrita, ou seus detalhes específicos. Eu tinha lido o conto e nunca havia percebido que ele matava a questão da aleatoriedade ser capaz de produzir coisas valiosas. Precisei mesmo da [Wikipédia](https://en.wikipedia.org/wiki/Infinite_monkey_theorem) me dizer isso. Alguns anos atrás levantei essa questão para um grupo de amigos sem saber que era uma questão tão batida e baixa. No meu exemplo era um cachorro andando sobre letras desenhadas e não um macaco numa máquina de escrever. A minha conclusão da discussão foi que não importa o que o cachorro escrevesse, sem uma inteligência capaz de compreender aquilo nada passaria de letras aleatórias. Borges resolve tudo imaginando uma biblioteca que contém tudo o que o cachorro havia escrito durante todo o infinito em que fez o experimento, e portanto contém todo o conhecimento sobre tudo e todas as obras literárias possíveis -- mas entre cada página ou frase muito boa ou pelo menos legívei há toneladas de livros completamente aleatórios e uma pessoa pode passar a vida dentro dessa biblioteca que contém tanto conhecimento importante e mesmo assim não aprender nada porque nunca vai achar os livros certos. > Everything would be in its blind volumes. Everything: the detailed history of the future, Aeschylus' The Egyptians, the exact number of times that the waters of the Ganges have reflected the flight of a falcon, the secret and true nature of Rome, the encyclopedia Novalis would have constructed, my dreams and half-dreams at dawn on August 14, 1934, the proof of Pierre Fermat's theorem, the unwritten chapters of Edwin Drood, those same chapters translated into the language spoken by the Garamantes, the paradoxes Berkeley invented concerning Time but didn't publish, Urizen's books of iron, the premature epiphanies of Stephen Dedalus, which would be meaningless before a cycle of a thousand years, the Gnostic Gospel of Basilides, the song the sirens sang, the complete catalog of the Library, the proof of the inaccuracy of that catalog. Everything: but for every sensible line or accurate fact there would be millions of meaningless cacophonies, verbal farragoes, and babblings. Everything: but all the generations of mankind could pass before the dizzying shelves – shelves that obliterate the day and on which chaos lies – ever reward them with a tolerable page. Tenho a impressão de que a publicação gigantesca de artigos, posts, livros e tudo o mais está transformando o mundo nessa biblioteca. Há tanta coisa pra ler que é difícil achar o que presta. As pessoas precisam parar de escrever.

# Ryan Fugger's Ripple Before XRP, the shitcoin, bought it, "Ripple" was used by Ryan Fugger as the name for his [project to create a peer-to-peer network of trust channels for money transfer](http://ripple.ryanfugger.com/). The basic idea is that Alice trusts Bob personally, Bob trusts Carol personally and Carol trusts David personally, therefore it is possible for Alice to send a payment to David by creating debt across A--B, B--C and C--D. Later either payments in the opposite direction (not necessarily from David to Alice, as the network can have trust relationships to multiple other peers in a complex graph) would maybe clear that debt (or not), but ultimately Bob would expect Alice to pay him in kind to settle the debt, Carol would expect Bob to pay her in kind and David would expect Carol to pay him in kind. The system above works quite well inside a centralized trusted platform like Fugger's own Ripplepay website (even when it was supposed to be just proof-of-concept, it ended up being actually used to facilitate payments across small communities), but that cannot scale as participants would all rely on it and ultimately have to blindly trust that platform.[^trust-ripplepay] If a truly peer-to-peer system could be designed, it would have a chance of scaling across the entire society and the ability to enable truly open payments over the internet, an unreachable goal unless you use either a credit card provider, which is bureaucratic, unsafe, expensive, taxable, not private at all and cumbersome -- or [Bitcoin](nostr:naddr1qqrky6t5vdhkjmspz9mhxue69uhkv6tpw34xze3wvdhk6q3q80cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsxpqqqp65wp3k3fu), which is awesome and excel in all aspects except scalability for day-to-day transactions. The protocol can take many forms, but essentially it goes like this: 1. A finds a route (A--B--C--D) between her and D somehow; 2. A "prepares" a payment to B, tells B to do the same with C and so on (to prepare means to give B a conditional IOU that will be valid as long as the full payment completes); 3. When the chain of prepared messages reaches D, D somehow "commits" the payment. 4. After the commit, A now _really does_ owe B and so on, and D _really_ knows it has been effectively paid by A (in the form of debt from C) so it can ship goods to A. The step 3 is the point in which [the problem of the decentralized commit](nostr:naddr1qqyrxcmzxa3nxv34qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cjrqar6) arises. Fugger and the original Ripple community failed to solve the problem of the decentralized commit, which is required for such a system to be deployed. Not to blame them, as they've recognized the problem (unlike other people that had the same idea later[^clueless-people]) and documented many sub-optimal solutions[^decentralized-commit]. No one thinks about it in these terms, but the Bitcoin Lightning Network is itself a Ripple-like system with [an embedded solution to the problem of the decentralized commit](nostr:naddr1qqyxgenyxe3rzvf4qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c8pp8zu). [^trust-ripplepay]: You may ask why is it bad to trust a central point if all this is already based on trust relationships between peers. If the platform goes malicious peers can jump out and resolve things on their own! But that's not so simple, it's not obvious when the platform will be malicious or not, it's not clear what to do if the platform deletes data or change history. Ultimately it cannot scale because even if it was very trustworthy you wouldn't want the entire global economy resting upon Ryan Fugger's webserver, nor does he want that. [^clueless-people]: See, for example, [LedgerLoops](http://ledgerloops.com/), [Offst](https://www.offsetcredit.org/) and [Settle](http://web.archive.org/web/20180103202635/https://settle.network/). [^decentralized-commit]: The [old Ripple wiki](http://ripple.ryanfugger.com/Protocol/Index.html) lists the "registry commit method" (which requires trust in a third-party), the "bare commit method" (which is not an atomic commit) and the "blockchain commit method" (which publishes transactions to the Bitcoin blockchain and so does not scale.

# ZBD Social If you have a closed system, a platform with users inside that login with name and password, it's not hard to introduce "social network" features into it. It was always the plan at ZEBEDEE to introduce such a thing, but much better than a closed social network just for ZBD users is if one such a thing can plug into the outer world of Nostr. Therefore [ZBD Social](https://zbd.gg) is both an internal social network and a network that is open to the external world through Nostr. The ZBD app already includes a custodial Bitcoin Lightning wallet and the target userbase doesn't want to care about keys and prefers email and password as the login mechanism to a trusted platform, therefore the ZBD Social is a custodial Nostr client. ZBD users also may be running their app on low-spec phones and low bandwidth, and since the key is already custodial it makes more sense to have all the Nostr logic for each ZBD user to be done on a ZEBEDEE server, instead of in the device itself, therefore the Social section on the ZBD app is just a thin client to an internal API. ## Doing the correct thing given the constraints In order for Nostr to scale, people must be able to host their notes in whatever relay they want and their followers must still be able to find these. With that goal in mind, the ZBD Social server keeps track of all associations it can find -- in event hints, kind 3 and kind 10002 events, `nprofile` and `nevent` codes and the bare fact that a given event from someone was found in a given relay -- and uses that information to estimate the best possible set of relays to be used to fetch notes for each Nostr user, along with some variance to account for the fact that these sets are dynamic. Whenever a ZBD user wants to read notes from any external Nostr user -- either because they've opened on that user's profile or because they follow that user and are browsing their classic "home feed" with notes from everybody they follow -- the ZBD Social backend will gather the best relays for that given user and open new subscriptions -- if there isn't already a subscription open -- for that user. If there are already other subscriptions open for other users in that same relay, the subscriptions will be merged in order to not spam external relays. As they come in, notes from external users are cached in a way that they are automatically evicted as soon as memory is low and they haven't been accessed for a while. Browsing through old notes is done through paging these cached notes, indexed by author. ## The `wss://nostr.zbd.gg` relay The ZBD relay stores all events emitted by ZBD users. It runs [strfry](https://github.com/hoytech/strfry) with a plugin that makes it interact with the rest of the backend. It is replicated accross multiple instances using strfry's native syncing capabilities and serves both as a normal relay interface to which external Nostr clients can talk normally and as a database that can be queried by the internal backend (turns out strfry is not only a Nostr relay, it is also a mechanism to turn LMDB into a cloud-native datastore). This makes it easy to have a dedicated tab on the app with the feed of all the other ZBD users, which is effectively the same as browsing just `wss://nostr.zbd.gg` from any other Nostr client -- see, for example, [Coracle](https://coracle.social/relays/nostr.zbd.gg), [nostrrr](https://nostrrr.com/relay/nrelay1qqxxummnw3ezu7nzvshxwecdqzt3k), [nostr.com](https://nostr.com/r/nostr.zbd.gg) or using the [CLI](https://github.com/fiatjaf/nak): `nak req -l 10 --stream wss://nostr.zbd.gg | jq`. It also contributes to the future world of Nostr in which niche relays can be browsed individually to enhance the experience of normal social interactions. For any given note, for example, you should be able to see "what are the ZBD users commenting about this" or "what are the gold enthusiasts saying" and so on. ## Ideas for the future Being a Nostr custodian in a platform that offers Lightning payment services and other third-party integrations for its existing userbase, it's easy to see how ZEBEDEE can start bridging Nostr into more things inside its domain. For example, in the future ZEBEDEE could offer a way for game vendors to plug in a social networking layer into their games and that wouldn't be just an API to a proprietary platform, but a bridge to the real Nostr world that integrates seamlessly with the ZBD app for ZBD users, but works in Nostr-native mode for any Nostr user. Another use case could be powering social features for music and entertainment apps. Another very obvious use case is a NIP-58 badges system that games and other "gamified" services and apps can use. In a not distant future, I imagine we'll see also integrations with the ZBD browser extension and NIP-07, Nostr features with the Telegram and Discord bots, and NIP-53 integration with [ZBD Streamer](https://docs.zebedee.io/docs/zbd-streamer/overview/) (but I am _not_ officially announcing anything).

# litepub A Go library that abstracts all the burdensome ActivityPub things and provides just the right amount of helpers necessary to integrate an existing website into the "fediverse" (what an odious name). Made for the [gravity]() integration. - <https://godoc.org/github.com/fiatjaf/litepub> ## See also -

# Precautionary Principle The [precautionary principle](https://en.wikipedia.org/wiki/Precautionary_principle) that people, including Nassim Nicholas Taleb, love and treat as some form of wisdom, is actually just a justification for arbitrary acts. In a given situation for which there's no sufficient knowledge, either A or B can be seen as risky or precautionary measures, there's no way to know except if you have sufficient knowledge. --- Someone could reply saying, for example, that the known risk of A is tolerable to the unknown, probably magnitudes bigger, risk of B. Unless you know better or at least have a logical explanation for the risks of B (a thing "scientists" don't have because they notoriously dislike making logical claims), in which case you do know something and is not invoking the precautionary principle anymore, just relying on your logical reasoning – and that can be discussed and questioned by others, undermining your intended usage of the label "precautionary principle" as a magic cover for your actions.

# Liquidificador A fragilidade da comunicação humana fica clara quando alguém liga o liquidificador.

# Setting up a handler for `nostr:` links on your Desktop, even if you don't use a native client This is the most barebones possible, it will just open a web browser at `https://nostr.guru/` with the contents of the `nostr:` link. Create this file at `~/.local/share/applications/nostr-opener.desktop`: ``` [Desktop Entry] Exec=/home/youruser/nostr-opener %u Name=Nostr Browser Type=Application StartupNotify=false MimeType=x-scheme-handler/nostr; ``` (Replace "youruser" with your username above.) This will create a default handler for `nostr:` links. It will be called with the link as its first argument. Now you can create the actual program at `~/nostr-opener`. For example: ```python #!/usr/bin/env python import sys import webbrowser nip19 = sys.argv[1][len('nostr:'):] webbrowser.open(f'https://nostr.guru/{nip19}') ``` Remember to make it executable with `chmod +x ~/nostr-opener`.

# A estrutura paradigmática da ciência N'_A estrutura das revoluções científicas_, Thomas Kuhn descreve como surge uma ciência: um monte de gente fica tentando descobrir como uma coisa funciona a partir da sua própria experiência e escreve livros descrevendo isso. Cada um fala uma coisa completamente diferente, várias escolas de pensamento surgem e se combatem, até que por algum motivo uma mudança qualitativa aparece e faz com que todos concordem com uma base comum -- exceto é claro os que não concordam e esses são sumariamente expulsos do convívio dos demais --, os vários grupos deixam de existir ou se reformulam para que suas teses específicas passem a ter como base aquele novo paradigma, e então todo mundo passa a se comunicar por artigos que pressupõem várias coisas que eles têm em comum, e não mais por livros que partem dos menores princípios e tentam explicar tudo. É um belo paradigma para compreender como a ciência funciona, e explica o estado real das coisas muito melhor do que o vômito ideológico dos cientistas mirins da internet que repetem asneiras sobre o "método científico". mas o problema que me ocorreu foi: quem garante que esse paradigma representa realmente um avanço? Será que o desejo de concordar e se sentir incluído não foi o que fez com que todos os envolvidos o aceitassem? Não digo nem que essa nova descoberta esteja errada, mas ela -- e sua aceitação como novo paradigma -- criam um recorte da realidade dentro do qual aquela nova ciência que surge estará fadada a operar dali em diante, mas quem disse que esse recorte é mesmo o melhor lugar para que todos operem? Talvez uma idéia melhor seria que as pessoas avaliassem aquele novo paradigma, mas não mergulhassem de cabeça nele. Uma hipótese alternativa do porquê esse recorte e surgimento da ciência acontece: ela é mais fácil de ser abarcada pela burocracia universitária e empregar mentes medíocres na "pesquisa" uma coisa pequena e sem importância que já está ali dada pelo próprio conceito da ciência e não será nenhuma descoberta nova. - [Método científico](nostr:naddr1qqyr2wf3vgmx2dmrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823chtnaca) - [Thomas Kuhn sequer menciona o "método científico"](nostr:naddr1qqyryd3jv5enyd3cqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c3zmtlu)

# Profits, not wages, as the originary factor Adam Smith says that there were first workers earning wages, but then came the capitalists and extracted profits from those wages. But in fact if that primitive state ever existed there were no workers, but entrepreneursearning profit. And since they were not capitalists ("capitalist" defined as someone that buys with the intent of selling) they were earning an infinite rate of profit. When capitalists came they were responsible for introducing costs (investment) reducing thus the rate of profit -- and the more capitalistic the society the smaller the rate of profits. -- George Reisman in <https://www.bobmurphyshow.com/139>

# Veterano não é dono de bixete "VETERANO NÃO É DONO DE BIXETE". A frase em letras garrafais chama a atenção dos transeuntes neófitos. Paira sobre um cartaz amarelo que lista várias reclamações contra os "trotes machistas", que, na opinião do responsável pelo cartaz, "não é brincadeira, é opressão". Eis aí um bizarro exemplo de como são as coisas: primeiro todos os universitários aprovam a idéia do trote, apoiam sua realização e até mesmo desejam sofrer o trote -- com a condição de o poderem aplicar eles mesmos depois --, louvam as maravilhas do mundo universitário, onde a suprema sabedoria se esconde atrás de rituais iniciáticos fora do alcance da imaginação do homem comum e rude, do pobre e do filhinho-de-papai das faculdades privadas; em suma: fomentam os mais baixos, os mais animalescos instintos, a crueldade primordial, destroem em si mesmos e nos colegas quaisquer valores civilizatórios que tivessem sobrado ali, ficando todos indistingüíveis de macacos agressivos e tarados. Depois vêm aí com um cartaz protestar contra os assédios -- que sem dúvida acontecem em larguíssima escala -- sofridos pelas calouras de 17 anos e que, sendo também novatas no mundo universitário, ainda conservam um pouco de discernimento e pudor. A incompreensão do fenômeno, porém, é tão grande, que os trotes não são identificados como um problema mental, uma doença que deve ser tratada e eliminada, mas como um sintoma da opressão machista dos homens às mulheres, um produto desta civilização paternalista que, desde que Deus é chamado "o Pai" e não "a Mãe", corrompe a benéfica, pura e angélica natureza do homem primitivo e o torna esta tão torpe criatura. Na opinião dos autores desse cartaz é preciso, pois, continuar a destruir o que resta da cultura ocidental, e então esperar que haja trotes menos opressores.

# A flexibilidade da doutrina socialista Os fatos da revolução russa mostram que Lênin e seus amigos bolcheviques não eram só psicopatas assassinos: eles realmente acreditavam que estavam fazendo o certo. Talvez depois de um tempo o foco deles tenha mudado mais para o lado de se preocuparem menos com a vida e o bem-estar dos outros do que com eles mesmos, mas não houve uma mudança fundamental. Ao mesmo tempo, a doutrina socialista na qual eles acreditavam era enormemente flexível, assim como a dos esquerdistas de hoje. É a mesma doutrina: uma coleção de slogans que pode ser adaptada para apoiar ou ir contra qualquer outra tese ou ação. Me parece que a justificativa que eles encontraram para fazer tantas coisas claramente ruins vem dessas mesma flexibilidade. Os atos cruéis estavam todos justificados pela mesma coleção de slogans socialistas de sempre, apenas adaptados às circunstâncias. Será que uma doutrina mais sólida se prestaria a essas atrocidades? Se concluirmos que a flexibilidade vem da mente e não da doutrina em si, sim, mas não acho que venha daí, porque é sempre o socialismo que é flexível, nunca nenhuma outra doutrina. Ou, na verdade, o socialismo é tão flexível que ele envolve e integra qualquer outra doutrina que seja minimamente compatível. Talvez a flexibilidade esteja mesmo na mente, mas existe alguma relação entre a mente que desconhece a coerência e a lógica e a mente que se deixa atrair pelos slogans socialistas.

# Washer A CLI tool for generating fulltext indexes and using them to query files later based on a library called `whoosh`[^whoosh]. I made this to help me search my [git-annex](https://git-annex.branchable.com/) files, but never really used it.  - <https://github.com/fiatjaf/washer> [^whoosh]: <https://pypi.org/project/Whoosh/>

# My stupid introduction to Haskell While I was writing my first small program on Haskell (really simple, but functional webapp) in December 2017 I only knew vaguely what was the style of things, some basic notions about functions, pure functions and so on (I've read about a third of [LYAH](http://learnyouahaskell.com/chapters)). An enourmous amount of questions began to appear in my head while I read tutorials and documentation. Here I present some of the questions and the insights I got that solved them. Technically, they may be wrong, but they helped me advance in the matter, so I'm writing them down while I still can -- If I keep working with Haskell I'll probably get to know more and so my new insights will replace the previous ones, and the new ones won't be useful for total begginers anymore. --- Here we go: - **Why do modules have odd names?** - modules are the things you import, like `Data.Time.Clock` or `Web.Scotty`. - packages are the things you install, like 'time' or 'scotty' - packages can contain any number of modules they like - a module is just a collection of functions - a package is just a collection of modules - a package is just name you choose to associate your collection of modules with when you're publishing it to Hackage or whatever - the module names you choose when you're writing a package can be anything, and these are the names people will have to `import` when they want to use you functions - if you're from Javascript, Python or anything similar, you'll expect to be importing/writing the name of the package directly in your code, but in Haskell you'll actually be writing the name of the module, which may have nothing to do with the name of the package - people choose things that make sense, like for `aeson` instead of `import Aeson` you'll be doing `import Data.Aeson`, `import Data.Aeson.Types` etc. why the `Data`? because they thought it would be nice. dealing with JSON is a form of dealing with data, so be it. - you just have to check the package documentation to see which modules it exposes. - **What is `data User = User { name :: Text }`?** - a data type definition. means you'll have a function `User` that will take a Text parameter and output a `User` record or something like that. - you can also have `Animal = Giraffe { color :: Text } | Human { name :: Text }`, so you'll have two functions, Giraffe and Human, each can take a different set of parameters, but they will both yield an Animal. - then, in the functions that take an Animal parameter you must typematch to see if the animal is a giraffe or a human. - **What is a monad?** - a monad is a context, an environment. - when you're in the context of a monad you can write imperative code. - you do that when you use the keyword `do`. - in the context of a monad, all values are prefixed by the monad type, - thus, in the `IO` monad all `Text` is `IO Text` and so on. - some monads have a relationship with others, so values from that monad can be turned into values from another monad and passed between context easily. - for exampĺe, [scotty](https://www.stackage.org/haddock/lts-9.18/scotty-0.11.0/Web-Scotty.html)'s `ActionM` and `IO`. `ActionM` is just a subtype of `IO` or something like that. - when you write imperative code inside a monad you can do assignments like `varname <- func x y` - in these situations some transformation is done by the `<-`, I believe it is that the pure value returned by `func` is being transformed into a monad value. so if `func` returns `Text`, now varname is of type `IO Text` (if we're in the IO monad). - so it will not work (and it can be confusing) if you try to concatenate functions like `varname <- transform $ func x y`, but you can somehow do - `varname <- func x y` - `othervarname <- transform varname` - or you can do other fancy things you'll get familiar with later, like `varname <- fmap transform $ func x y` - why? I don't know. - **How do I deal with Maybe, Either or other crazy stuff?** "ok, I understand what is a Maybe: it is a value that could be something or nothing. but how do I use that in my program?" - you don't! you turn it into other thing. for example, you use [fromMaybe](http://hackage.haskell.org/package/base-4.10.1.0/docs/Data-Maybe.html#v:fromMaybe), a function that takes a default value and that's it. if your `Maybe` is `Just x` you get `x`, if it is `Nothing` you get the default value. - using only that function you can already do whatever there is to be done with Maybes. - you can also manipulate the values inside the `Maybe`, for example: - if you have a `Maybe Person` and `Person` has a `name` which is `Text`, you can apply a function that turns `Maybe Person` into `Maybe Text` AND ONLY THEN you apply the default value (which would be something like the `"unnamed"`) and take the name from inside the `Maybe`. - basically these things (`Maybe`, `Either`, `IO` also!) are just tags. they tag the value, and you can do things with the values inside them, or you can remove the values. - besides the example above with Maybes and the `fromMaybe` function, you can also remove the values by using `case` -- for example: - `case x of` - `Left error -> error` - `Right success -> success` - `case y of` - `Nothing -> "nothing!"` - `Just value -> value` - (in some cases I believe you can't remove the values, but in these cases you'll also don't need to) - for example, for values tagged with the IO, you can't remove the IO and turn these values into pure values, but you don't need that, you can just take the value from the outside world, so it's a IO Text, apply functions that modify that value inside IO, then output the result to the user -- this is enough to make a complete program, any complete program. - **JSON and interfaces (or instances?)** - using [Aeson](https://hackage.haskell.org/package/aeson-1.2.3.0/docs/Data-Aeson.html) is easy, you just have to implement the `ToJSON` and `FromJSON` interfaces. - "interface" is not the correct name, but I don't care. - `ToJSON`, for example, requires a function named `toJSON`, so you do - `instance ToJSON YourType where` - `toJSON (YourType your type values) = object []` ... etc. - I believe lots of things require interface implementation like this and it can be confusing, but once you know the mystery of implementing functions for interfaces everything is solved. - `FromJSON` is a little less intuitive at the beggining, and I don't know if I did it correctly, but it is working here. Anyway, if you're trying to do that, I can only tell you to follow the types, copy examples from other places on the internet and don't care about the meaning of symbols. ## See also * [Haskell Monoids](nostr:naddr1qqyrzcmrvcmrqwtpqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cktq992)

# Idéia de um sistema jurídico centralizado, mas com um pouco de lógica um processo, é, essencialmente, imagino eu na minha ingenuidade leiga, um apelo que se faz ao juiz para que este reconheça certos fatos como probantes de um certo fenômeno tipificado por uma certa lei. imagino então o seguinte: uma petição não é mais um enorme documento escrito numa linguagem nojenta com referências a leis e a evidências factuais espalhadas segundo a (in) capacidade ensaística do advogado, mas apenas um esquema lógico - talvez até um diagrama desenhado (ou talvez quem sabe uma série de instruções compreensíveis por um computador?) - mostrando a ligação entre a lei e os fatos e os pedidos, por exemplo: 1. a lei tal diz que ninguém pode vender 2. fulano vendeu cigarros 3. é prova de que fulano vendeu cigarros ia foto tirada na rua tal no dia tal que mostra fulano vendendo cigarros 4. a mesma lei pede que fulano pague uma multa este exemplo está ainda muito verborrágico, mas é só um exemplo simples. coisas mais complicadas precisariam de outras formas de expressão caso queiramos evitar as longas dissertações jurídicas em voga. a idéia é que o esquema acima vale por si. um proto-juiz pode julgá-lo como válido ou inválido apenas pela sua lógica interna. a outra parte do julgamento seria a ligação desse esquema com a realidade externa: anexados à petição viriam as evidências. no caso, anexada ao ponto 3 viria uma foto do fulano. ao ponto 1 também precisa ser anexado o texto da lei referida, mas isto pode ser feito automaticamente pelo número da lei. uma vez que tenhamos um esquema lógico válido um outro proto-juiz, ou vários outros, pode julgar individualmente cada evidência: ver se o texto da lei confere com a interpretação feita no ponto 1, e se a foto anexada ao ponto 3 é mesmo a foto do réu vendendo cigarro e não a de um urso comendo laranjas. cada um desses julgamentos pode ser feito sem que o proto-juiz tenha conhecimento do resto das coisas do processo: o primeiro proto-juiz não precisa ver a foto ou a lei, o segundo não precisa ver o esquema lógico ou a foto, o terceiro não precisa ver a lei nem o esquema lógico, e mesmo assim teríamos um julgamento de procedência ou não da petição ao final, o mais impessoal e provavelmente o mais justo possível. a defesa consistiria em apontar erros no esquema lógico ou falhas no nexo entre a realidade é o esquema. por exemplo: 3. uma foto assim não é uma prova de que fulano vendeu, ele podia estar só passando lá perto. * ele estava de fato só passando lá perto. do que é prova este documento mostrando seu comparecimento a uma aula do curso de direito da UFMG no mesmo horário. --- perdoem-me se estiver falando besteira, mas são 5h e estou ainda dormindo. obviamente há vários pontos problemáticos aí, e quero entendê-los, mas a forma geral me parece bem razoável. o que descrevi acima é uma proposta, digamos, de sistema jurídico que não se diferencia em nada do nosso sistema jurídico atual, exceto na forma (não no sentido escolástico). é também uma tentativa de compreender sua essência. as vantagens desse formato ao atual são muitas: - menos papel, coisas pra ler, repetição infinita de citações legais e longuíssimas dissertações escritas por advogados analfabetos que destroem a língua e a inteligência de todos - diminuição drástica do tempo gasto por cada juiz em cada processo - diminuição do poder de cada juiz (se cada ato de julgamento humano necessário em cada processo pode ser feito por qualquer juiz, sem conhecimento dos outros aspectos do mesmo processo, tudo é muito mais rápido, e cada julgamento desses pode ser feito por vários juízes diferentes, escolhidos aleatoriamente) - diminuição da pomposidade de casa juiz: com menos poder e obrigações maus simples, um juiz não precisa ser mais uma pessoa especial que ganha milhões, pode ser uma pessoa comum, um proto-juiz, ganhando menos (o que possibilitaria até ter mais desses e aumentar a confiabilidade de cada julgamento) - os juízes podem trabalhar da casa deles e a qualquer momento - passa a ter sentido a existência de um sistema digital de processos (porque é ridículo que o sistema digital atual seja só uma forma de passar documentos do Word de um lado para o outro) - o fim das audiências de conciliação, que são uma monstruosidade criada apenas pela necessidade de diminuir a quantidade de processos em tramitação e acabam retirandobo sentido da justiça (as partes são levemente pressionadas a ignorar a validade ou não das suas posições e fazer um acordo, sob pena de o juiz ficar com raiva delas depois) milhares de precauções devem ser tomadas caso um sistema desses vá ser implantado (ahahah), talvez manter uma forma de julgamento tradicional, de corpo presente e com um juiz ou júri que tem conhecimento de toda situação, mas apenas para processos que chegarem até certo ponto, e assim por diante. ## Ver também * [P2P reputation thing](nostr:naddr1qqyrqv3cxumnydfsqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cnjc88q) para um fundamento de um sistema jurídico anárquico.

# Rust's `.into()` is a strictly bad thing It just makes the code unreadable for no gain. Instead of defining methods with readable and meaningful names for transforming objects into other objects and calling those, the `.into()` bad practice just teaches everybody to write `.into()` everywhere, making the code impossible to read without a superpowered editor -- and sometimes [even with it](https://github.com/rust-lang/rust-analyzer/issues/15315).

# A memória está nas coisas A memória está nas coisas, mas se você tiver muitas memórias já mesma coisa parece que uma se sobrepõe à outra, de modo que se vive quiser acumular mais memórias é melhor mudar de casa todo ano.

# Bitcoin A collection of notes related to Bitcoin. - [Bitcoin, not you](nostr:naddr1qqyryvrpxuekyefcqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cvwmmjc) - [Drivechain](nostr:naddr1qq9xgunfwejkx6rpd9hqzythwden5te0ve5kzar2v9nzucm0d5pzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqr4gumtjfnp) - [My personal experience (as a complete ignorant) of the blocksize debate in 2017](nostr:naddr1qqyx2c33vdnrsdfeqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c9833j5) - [Bitcoin transactions explained](nostr:naddr1qqyr2e34xycnyephqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cun2wfz) - [Eltoo](nostr:naddr1qqyxvenyvejnwdejqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c6qlqxc) - [On "zk-rollups" applied to Bitcoin](nostr:naddr1qqyrzd3jvymkxve5qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c2c9rut) - [`bitcoind` decentralization](nostr:naddr1qqyxzcfevscxzvnrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823chus9ym)

# Família e propriedade A idéia tradicional de família está associada a propriedades imobiliárias fixas, passadas de geração a geração. Com propriedades sendo partidas, desfeitas, vendidas e divididas entre os filhos a idéia de família -- um nome associado a um lugar -- torna-se vaga e perde-se no ar. Acho que isso não vale apenas para a nobreza medieval, mas mesmo para as famílias plebéias, e não valeu quase nunca para as sociedades do novo mundo. Acho que até seria compatível com a compra e venda de terras, que seriam compreendidas como uma família mudando de lugar, mas não com a divisão igualitária das propriedades da família entre vários filhos e assim sucessivamente. Nunca antes tinha-me ocorrido este excelente e quase-óbvio insight que está escrito em "A Democracia na América", de Alexis de Tocqueville.

# Sistemas legais anárquicos São poucos os exemplos de sistemas legais claramente anárquicos que nós temos, e são sempre de tempos muito remoto, da idade média ou por aí. Me vêm à cabeça agora o sistema islandês, o somaliano, o irlandês e as cortes dos mercadores da Europa continental. Esses exemplos, embora sempre pareçam aos olhos de um libertário convicto a prova cabal de que a sociedade sem o Estado é capaz de fazer funcionar sistemas legais eficientes, complexos e muito melhores e mais baratos do que os estatais, a qualquer observador não entusiasmado vão parecer meio anacrônicos: são sempre coisas que envolvem família, clãs, chefes de família, comunidades pequenas -- fatores quase sempre ausentes na sociedade hoje --, o que dá espaço para que a pessoa pense (e eu confesso que isso também sempre me incomodou) que nada disso funcionaria hoje, são bonitos, mas sistemas que só funcionariam nos tempos de antigamente, o Estado com seu sistema judiciário é a evolução natural e necessária de tudo isso e assim por diante. Vale lembrar, porém, que os exemplos que nós temos provavelmente não surgiram espontamente, eles mesmos foram o resultado de uma evolução lenta mas constante do sistema legal das suas respectivas comunidades. Se não tivessem sido interrompidos pela intervenção de algum Estado, esses sistemas teriam continuado evoluindo e hoje, quem sabe, seriam redes complexas altamente eficientes, que, por que não, juntariam tecnologias similares à internet com segurança de dados, algoritmos maravilhosos de reputação e voto, tudo decentralizado, feito por meio de protocolos concorrentes mas padronizados -- talvez, se tivessem tido um pouquinho mais de tempo, cada um desses sistemas legais anárquicos teria desenvolvido meios de evitar a conquista ou a concorrência desleal de um Estado, ou pelo menos do Estado como nós o conhecemos hoje.

# Webvatar Like **Gravatar**, but using profile images from websites tagged with "microformats-2" tags, like people from the indiewebcamp movement liked. It falled back to favicon, gravatar and procedural avatar generators. No one really used this, despite people saying they liked it. Since I was desperate to getting some of my programs appreciated by someone I even bought a domain. It was sad, but an enriching experience. - <https://github.com/fiatjaf/webvatar.com> - <http://webvatar.com> ### See also - [jekmentions](nostr:naddr1qqyrvcmxxgmn2cnpqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823crzww00) - [questo.email](nostr:naddr1qqyrvvpnveskzvnrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ce8mca6)

# microanalytics A replacement for Google Analytics that run inside a CouchDB, when CouchDB still was a potential platform for hosting of simple apps and easily distribution of apps with data. It also had a CLI app for browsing the data with nice CLI charts.  - <https://github.com/fiatjaf/microanalytics> - <https://github.com/fiatjaf/microanalytics-cli> ### See also - [About CouchDB](nostr:naddr1qqyrwepevf3n2wf5qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c0jq39e) - [trackingco.de](nostr:naddr1qqyxgwt9xuck2dn9qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cqnzcdc)

# A vision for content discovery and relay usage for basic social-networking in Nostr Or how to make a basic "social-networking" application using the [Nostr](nostr:naddr1qqzkummnw3eqzythwden5te0ve5kzar2v9nzucm0d5pzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqr4gusz7vna) protocol that is safe and promotes decentralization. ## The basic app views Suppose a basic "social-networking" app is like Twitter. In that, one has basically 3 views: - A **home feed** that shows all notes from everybody you follow; - A **profile view** from a specific user that shows all notes from that user; - A **replies view** that shows all replies to one specific note. Some Nostr clients may want to also provide another view, the **global feed** which shows posts from _everybody_. ## A simple classification of relays And suppose that all existing relays can be classified in 3 groups (according to one's subjective evaluation): - **spammy relays**, in which people of any kind can post whatever they want with no filters at all; - **safe relays**, in which there are some barriers to entry, like requiring a fee, or requiring some cumbersome user registration process, and spammers or people who post bad things are banned -- but this is still a relay fundamentally open to anyone (although this is also subjective depending on the kind of restrictions); - **closed relays**, in which only certain kinds of people enter, for example, members of a group of friends or a closed online community. ## How to follow and find posts from a given profile To follow someone on Nostr, it is necessary to know one or more relays in which that person is publishing their notes, otherwise it is impossible to fetch anything from them. When a user starts to follow someone, that may be done through 4 different ways: 1. from seeing that person in the app 2. using an `nprofile` URI 3. using a NIP-05 address 4. using a bare pubkey ('npub`) Situation 1 may happen when that person is seen in the replies of yours or someone else's post, on a global feed post, or from a note referenced or republished from them by someone else. When that happens, it is expected that the references (in `e` and `p` tags) contain relay URLs. We must them inject that information to tentatively associate that person with a relay URL at that first contact. In situations 2 and 3 both the `nprofile` and the NIP-05 addresses should contain a list of preferred relays for that person, so we can bootstrap the relay list for that person based on that. In situation 4 there is no relay list, so we must either prompt the user through an annoying popup or something -- or it can try searching for that pubkey in one of their known relays. This remains an option for the other methods too. Once we have relay URLs for a given profile we can use these relays to query notes from that pubkey. As time passes that user may migrate to other relays, or it may become known that the user is also posting to other relays. To make sure these things are discovered, we must pay attention to hints sent in tags of all events seen everywhere -- from anyone --, and also events of kind 2 and 3, and upgrade our local database that has the knowledge of relationship between profiles and relays accordingly. ## Rendering the app views From what we've gathered until now, we can easily render the **home feed** and the **profile view**. To do that it just uses local information about relationships between profiles and relays and fetch notes: - for the **home feed**, from all people we're following; - for the **profile view**, from just that specific profile. Since we'll be asking for very specific data from these relays, we do not care about where they're **safe** or not. They will never send us spam (and if they do that will just be filtered out since it wouldn't match our strict filter). Now whenever the user clicks on a note we will want to display the **replies view**. In this case we will just query only the **safe** and the **closed relays**, since otherwise spam might be injected into the application. The same principle applies to the **global feed** view. ## Other heuristics and corner cases There are probably many corner cases not covered in this document. This was meant to just describe one way that seems to me to be sufficiently robust for a decentralized Nostr. For example, how to display a note that was referenced by someone? If it has a relay hint we query that relay. If it doesn't we can try the relays associated with the person who have just mentioned it, or the same relay we've just seen the note that mentioned it -- as, when mentioning it, one might have published it directly to their own relays -- and so on. But all this may fail and then it is probably not a big deal. ## Final thoughts More important than all, is that we must keep in mind that Nostr is just a very loose set of servers with basically no connection between them, there are no guarantees of anything, and the process of keeping connected to others and finding content must be addressed through many different hackish attempts. To write Nostr applications and to use Nostr one must embrace the inherent chaos.

# O VAR é o grande equalizador Não tenho acompanhado o futebol desde 2013 ou 2014, mas me parece que, como poderia ter sido previsto, o VAR tem favorecido os times pequenos ou marginais em detrimento dos demais. É lógico: se os juízes favoreriam mais o Flamengo e o Corinthians, e depois os grandes de Rio e São Paulo, em detrimento dos demais, o VAR, por minimamente mais justo que seja, aparentará favorecer os outros. * [Viva o mata-mata](nostr:naddr1qqyrgcnyv9nrsv35qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c7h66hy)

# O voto negativo É simples: Você pode escolher entre votar em um candidato qualquer, como todos fazemos normalmente, ou tirar um voto de um político que não quer que seja eleito de jeito nenhum. A possibilidade de votarmos negativamente duas vezes é muito interessante também. Outro motivo para implementar essa inovação na democracia: é muito mais divertido que o voto nulo.

# Democracy as a failed open-network protocol In the context of protocols for peer-to-peer open computer networks -- those in which new actors can freely enter and immediately start participating in the protocol --, without any central entity, specially without any central human mind judging things from the top --, it's common for decisions about the protocol to be thought taking in consideration all the possible ways a rogue peer can disrupt the entire network, abuse it, make the experience terrible for others. The protocol design must account for all incentives in play and how they will affect each participant, always having in mind that each participant may be acting in a purely egoistical self-interested manner, not caring at all about the health of the network (even though most participants won't be like that). So a protocol, to be successful, must have incentives aligned such that self-interested actors cannot profit by hurting others and will gain most by cooperating (whatever that means in the envisaged context), or there must be a way for other peers to detect attacks and other kinds of harm or attempted harm and neutralize these. Since computers are very fast, protocols can be designed to be executed many times per day by peers involved, and since the internet is a very open place to which people of various natures are connected, many open-network protocols with varied goals have been tried in large scale and most of them failed and were shut down (or kept existing, but offering a bad experience and in a much more limited scope than they were expected to be). Often the failure of a protocol leads to knowledge about its shortcomings being more-or-less widespread and agreed upon, and these lead to the development of a better protocol the next time something with similar goals is tried. Ideally **democracies** are supposed to be an open-entry network in the same sense as these computer networks, and although that is a noble goal, it's one full of shortcomings. Democracies are supposed to the governing protocol of States that have the power to do basically anything with the lives of millions of citizens. One simple inference we may take from the history of computer peer-to-peer protocols is that the ones that work better are those that are simple and small in scope (**Bitcoin**, for example, is very simple; **BitTorrent** is also very simple and very limited in what it tries to do and the number of participants that get involved in each run of the protocol). Democracies, as we said above, are the opposite of that. Besides being in a very hard position to achieve success as an open protocol, democracies also suffer from the fact that they take a long time to run, so it's hard to see where it is failing every time. The fundamental incentives of democracy, i.e. the rules of the protocol, posed by the separation of powers and checks-and-balances are basically the same in every place and in every epoch since the XIII century, and even today most people who dedicate their lives to the subject still don't see how [they're completely flawed](nostr:naddr1qqyrzc3nvenxxdpkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cjc4mf0). The system of checks and balances was thought from the armchair of a couple of political theorists who had never done anything like that in their lives, didn't have any experience dealing with very adversarial environments like the internet -- and probably couldn't even imagine that the future users of their network were going to be creatures completely different than themselves and their fellow philosophers and aristocrats who all shared the same worldview (and how fast that future would come!). ## Also * [The illusion of checks and balances](nostr:naddr1qqyrzc3nvenxxdpkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cjc4mf0)

# The place of Drivechain in Bitcoin's future James O'Beirne wrote this [nice little article](https://delvingbitcoin.org/t/thoughts-on-scaling-and-consensus-changes-2023/32) that contains a bunch of statements that should have been obvious to anyone who thought a little about Bitcoin's future, as they were obvious for Hal Finney in 2009 already. Basically the article says that the Bitcoin blockchain won't scale for the entire world population to use it. It will so much not scale that even "offchain" solutions like Lightning and Ark will not scale and they basically lose usefulness as more adoption happens and fees rise. Given that, Bitcoin has only two paths (and now this is not James speaking anymore): either it will die or it will have to scale using custodians. ## Can Bitcoin die? Yes, Bitcoin can die, and if Bitcoin fails to get some level of mass adoption soon enough I believe it will die. Governments all around the world gave us 14 years of advantage to try to get Bitcoin to become this money medium-of-exchange store-of-value thing, or at least an investment vehicle or savings-technology that is super valuable and with widespread ownership, but now it is starting to move. CBDCs have been talked about for a while, but now they are really starting to happen. Regulated and compliant fiat proprietary services like Venmo have grown under capture by governments, in some places the government itself has launched their own cool app-like totally regulated spyware fiat money transmission things, like the ridiculous PIX in Brazil, which is now widely adopted, and -- I believe surprisingly for all the UX designers out there -- people have learned to use QR codes. The point is that, given a little bit of more time, governments can start to encroach on Bitcoin's space, making it more and more regulated until it either dies or becomes a very useless thing. Some Bitcoiners think Bitcoin has already won, this can't be further from the truth. Others think Bitcoin must not be mass adopted, it must stay as this niche and mostly useless currency digital asset thing or I don't really understand what they think. These people are wrong. There are also people who think Bitcoin should not be used by normal people as money, it should keep being adopted, but only as a store-of-value: this is also completely wrong, since Bitcoin's value tends to decrease as soon as owners realize Bitcoin is losing its chances of becoming actual money. ## Scaling To not die, Bitcoin must become more used. The current thesis accepted by most "maximalists" is that Bitcoin will continue to be thought of as an investment and its price will keep increasing, the price movements will bring more attention to it in a virtuous cycle. Eventually enough people will _want_ to hold it so they will start accepting it as a payment for goods and services and then it can start to be used as money. Assuming that will happen, we'll be faced with a problem: as people try to use it as money they will necessarily, by lack of other options, have to use some custodial solution or some proto-custodial solution, maybe using Lightning as a settlement layer between big custodians[^1]? I don't know. No one is happy with that solution, and rightfully so, since it is very dangerous. A small set of custodians can easily be captured by governments and they can slowly turn Bitcoin into fiat money like they did with gold. In other words: without Drivechain, Bitcoin will be a fragile success in the best case and dead in the worst case scenario. ## Enter Drivechain [Drivechain](nostr:naddr1qq9xgunfwejkx6rpd9hqzythwden5te0ve5kzar2v9nzucm0d5pzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqr4gumtjfnp) basically brings two things to the table: In the best case scenario of the non-Drivechain world, we would be in a fragile position with easily-capturable custodians. With Drivechain, we can create a bunch of decentralized sidechains, backed by the same mining process that is assumed to be decentralized already for Bitcoin to even work, and we gain orders of magnitude of more room to make censorship-resistant open transactions that don't require tax IDs or selfies and can't be stopped or regulated by governments. Bitcoin can scale as it normally would, but it's much more resilient. The other thing we get are improvements for the "dying" part. If Drivechain is successful, it may end up bringing much more people to Bitcoin. [Hivemind](https://bitcoinhivemind.com/) by itself may attract lots of users and capital that has been prevented from betting on predictions anywhere in the fiat world since always; Zcash or Monero sidechains can easily bring all the "cryptocurrency" enthusiasts that care about privacy and have long ago decided that Bitcoin isn't for them, these people are interested in some immediate feature, that now Bitcoin can provide them with; other sidechains, like Ethereum-like chains, can also contribute to [slowly bring in some of the users](nostr:naddr1qqyrjdtz8yerxvfjqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cnm0fdz) of these chains[^2]. Why would we want these people to come to Bitcoin? Because they will increase Bitcoin's network-effect, increase the satoshi price, and these changes would contribute for more people to start looking at Bitcoin and using Bitcoin and so on and so forth. More users, more network-effect, bigger price, will contribute for Bitcoin not being easily regulated and killed by governments. In other words: with Drivechain will be a resilient success in the worst case and a complete and total world dominator money in the best case. [^1]: I actually think Bitcoiners should put more thought on how to create a custodian network that scales easily without having to be centralized in a small set of providers like [Lightning](nostr:naddr1qqyrqdr989jnsvf5qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cjxzu6c) is, and this is kind of the point of James's article too. [^2]: Yes, I do think the entirety of the Ethereum ecosystem is a waste of time and money, but clearly there are dozens of people and money that disagree with me. And if they can't harm me with their stupidity then they will definitely make our money stronger. Besides that, it's not as if there aren't already many stupid people or even evil, horrible criminals using Bitcoin.

# IPFS problems: Too much immutability Content-addressing is unusable with an index or database that describes each piece of content. Since IPFS is fully content-addressable, nothing can be done with it unless you have a non-IPFS index or database, or an internal protocol for dynamic and updateable links. The IPFS [conceit](nostr:naddr1qqyxyeryx93kxv3nqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cwxek0q) made then go with the with the second option, which proved to be [a failure](nostr:naddr1qqyrvcnx8y6nwwtpqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cz8tlwh). They even incentivized the creation of a [database powered by IPFS](https://github.com/orbitdb/orbit-db), which couldn't be more misguided.

# A violência é uma forma de comunicação A violência é uma forma de comunicação: um serial killer, um pai que bate no filho, uma briga de torcidas, uma sessão de tortura, uma guerra, um assassinato passional, uma briga de bar. Em todos esses se pode enxergar uma mensagem que está tentando ser transmitida, que não foi compreendida pelo outro lado, que não pôde ser expressa, e, quando o transmissor da mensagem sentiu que não podia ser totalmente compreendido em palavras, usou essa outra forma de comunicação. Quando uma ofensa em um bar descamba para uma briga, por exemplo, o que há é claramente uma tentativa de uma ofensa maior ainda pelo lado do que iniciou a primeira, a briga não teria acontecido se ele a tivesse conseguido expressar em palavras tão claras que toda a audiência de bêbados compreendesse, o que estaria além dos limites da linguagem, naquele caso, o soco com o mão direita foi mais eficiente. Poderia ser também a defesa argumentativa: "eu não sou um covarde como você está dizendo" -- mas o bar não acreditaria nessa frase solta, a comunicação não teria obtido o sucesso desejado. A explicação para o fato da redução da violência à medida em que houve progresso da civilização está na melhora da eficiência da comunicação humana: a escrita, o refinamento da expressão lingüística, o aumento do alcance da palavra falada com rádio, a televisão e a internet. Se essa eficiência diminuir, porque não há mais acordo quanto ao significado das palavras, porque as pessoas não estão nem aí para se o que escrevem é bom ou não, ou porque são incapazes de compreender qualquer coisa, deve aumentar proporcionalmente a violência.

# Problemas com Russell Kirk A idéia central da “política da prudência[^1]” de Russell Kirk me parece muito correta, embora tenha sido melhor formulada pior no seu enorme livro do que em uma pequena frase do joanadarquista Lucas Souza: “o conservadorismo é importante, porque tem muita gente com idéia errada por aí, e nós podemos não saber distingüi-las”. Porém, há alguns problemas que precisam ser esclarecidos, ou melhor explicados, e que me impedem de enxergar os seus argumentos como refutação final do meu já tão humilde (embora feroz) anarquismo. São eles: I Percebo alguma coisa errada, não sei bem onde, entre a afirmação de que toda ideologia é ruim, ou “todas as ideologias causam confusão[^2]”, e a proposta conservadora de “conservar o mundo da ordem que herdamos, ainda que em estado imperfeito, de nossos ancestrais[^3]”. Ora, sem precisar cair em exemplos como o do partido conservador inglês -- que conservava a política inglesa sempre onde estava, e se alternava no governo com o partido trabalhista, que a levava cada vez mais um pouco à esquerda --, está embutida nessa frase, talvez, a idéia, que ao mesmo tempo é clara e ferrenhamente combatida pelos próprios conservadores, de que a história é da humanidade é uma história de progresso linear rumo a uma situação melhor. Querer conservar o mundo da ordem que herdamos significa conservar também os vários erros que podem ter sido cometidos pelos nossos ancestrais mais recentes, e conservá-los mesmo assim, acusando toda e qualquer tentativa de propôr soluções a esses erros de ideologia? Ou será que conservar o mundo da ordem é escolher um período determinado que seja tido como o auge da história humana e tentar restaurá-lo em nosso próprio tempo? Não seria isto ideologia? Ou, ainda, será que conservar o mundo da ordem é selecionar, entre vários períodos do passado, alguns pedaços que o conservador considerar ótimos em cada sociedade, fazer dali uma mistura de sociedade ideal baseada no passado e então tentar implementá-la? Quem saberia dizer quais são as partes certas? II Sobre a questão do que mantém a sociedade civil coesa, Russell Kirk, opondo-a à posição libertária de que o nexo da sociedade é o autointeresse, declara que a posição conservadora é a de que “a sociedade é uma comunidade de almas, que une os mortos, os vivos e os ainda não nascidos, e que se harmoniza por aquilo que Aristóteles chamou de amizade e os cristãos chamam de caridade ou amor ao próximo”. Esta é uma posição muito correta, mas me parece estar em contradição com a defesa do Estado que ele faz na mesma página e na seguinte. O que me parece errado é que a sociedade não pode ser, ao mesmo tempo, uma “comunidade baseada no amor ao próximo” e uma comunidade que “requer não somente que as paixões dos indivíduos sejam subjugadas, mas que, mesmo no povo e no corpo social, bem como nos indivíduos, as inclinações dos homens, amiúde, devam ser frustradas, a vontade controlada e as paixões subjugadas” e, pior, que “isso somente pode ser feito por um poder exterior”. Disto aí podemos tirar que, da mesma forma que Kirk define a posição libertária como sendo a de que o autointeresse é que mantém a sociedade civil coesa, a posição conservadora seria então a de que essa coesão vem apenas do Estado, e não de qualquer ligação entre vivos e mortos, ou do amor ao próximo. Já que, sem o Estado, diz, ele, citando Thomas Hobbes, a condição do homem é “solitária, pobre, sórdida, embrutecida e curta”? [^1]: este é o nome do livro e também um outro nome que ele dá para o próprio conservadorismo (p.99). [^2]: p. 101 [^3]: p. 102

 A command line utility to create and manage personal graphs, then write them to dot and make images with graphviz. It manages a bunch of YAML files, one for each entity in the graph. Each file lists the incoming and outgoing links it has (could have listen only the outgoing, now that I'm tihnking about it). Each run of the tool lets you select from existing nodes or add new ones to generate a single link type from one to one, one to many, many to one or many to many -- then updates the YAML files accordingly. It also includes a command that generates graphs with graphviz, and it can accept a template file that lets you customize the `dot` that is generated and thus the graphviz graph. # rel - <https://github.com/fiatjaf/rel>

# GraphQL vs REST Today I saw this: https://github.com/stickfigure/blog/wiki/How-to-(and-how-not-to)-design-REST-APIs And it reminded me why GraphQL is so much better. It has also reminded me why HTTP is so confusing and awful as a protocol, especially as a protocol for structured data APIs, with all its status codes and headers and bodies and querystrings and content-types -- but let's not talk about that for now. People complain about GraphQL being great for frontend developers and bad for backend developers, but I don't know who are these people that apparently love reading guides like the one above of how to properly construct ad-hoc path routers, decide how to properly build the JSON, what to include and in which circumstance, what status codes and headers to use, all without having any idea of what the frontend or the API consumer will want to do with their data. It is a much less stressful environment that one in which we can just actually perform the task and fit the data in a preexistent schema with types and a structure that we don't have to decide again and again while anticipating with very incomplete knowledge the usage of an extraneous person -- i.e., an environment with GraphQL, or something like GraphQL. By the way, I know there are some people that say that these HTTP JSON APIs are not the real REST, but that is irrelevant for now.

# nostr - Notes and Other Stuff Transmitted by Relays The simplest open protocol that is able to create a censorship-resistant global "social" network once and for all. It doesn't rely on any trusted central server, hence it is resilient; it is based on cryptographic keys and signatures, so it is tamperproof; it does not rely on P2P techniques, therefore it works. ## Very short summary of how it works, if you don't plan to read anything else: Everybody runs a client. It can be a native client, a web client, etc. To publish something, you write a post, sign it with your key and send it to multiple relays (servers hosted by someone else, or yourself). To get updates from other people, you ask multiple relays if they know anything about these other people. Anyone can run a relay. A relay is very simple and dumb. It does nothing besides accepting posts from some people and forwarding to others. Relays don't have to be trusted. Signatures are verified on the client side. ## This is needed because other solutions are broken: ### The problem with Twitter - Twitter has ads; - Twitter uses bizarre techniques to keep you addicted; - Twitter doesn't show an actual historical feed from people you follow; - Twitter bans people; - Twitter shadowbans people. - Twitter has a lot of spam. ### The problem with Mastodon and similar programs - User identities are attached to domain names controlled by third-parties; - Server owners can ban you, just like Twitter; Server owners can also block other servers; - Migration between servers is an afterthought and can only be accomplished if servers cooperate. It doesn't work in an adversarial environment (all followers are lost); - There are no clear incentives to run servers, therefore they tend to be run by enthusiasts and people who want to have their name attached to a cool domain. Then, users are subject to the despotism of a single person, which is often worse than that of a big company like Twitter, and they can't migrate out; - Since servers tend to be run amateurishly, they are often abandoned after a while — which is effectively the same as banning everybody; - It doesn't make sense to have a ton of servers if updates from every server will have to be painfully pushed (and saved!) to a ton of other servers. This point is exacerbated by the fact that servers tend to exist in huge numbers, therefore more data has to be passed to more places more often; - For the specific example of video sharing, ActivityPub enthusiasts realized it would be completely impossible to transmit video from server to server the way text notes are, so they decided to keep the video hosted only from the single instance where it was posted to, which is similar to the Nostr approach. ### The problem with SSB (Secure Scuttlebutt) - It doesn't have many problems. I think it's great. In fact, I was going to use it as a basis for this, but - its protocol is too complicated because it wasn't thought about being an open protocol at all. It was just written in JavaScript in probably a quick way to solve a specific problem and grew from that, therefore it has weird and unnecessary quirks like signing a JSON string which must strictly follow the rules of [_ECMA-262 6th Edition_](https://www.ecma-international.org/ecma-262/6.0/#sec-json.stringify); - It insists on having a chain of updates from a single user, which feels unnecessary to me and something that adds bloat and rigidity to the thing — each server/user needs to store all the chain of posts to be sure the new one is valid. Why? (Maybe they have a good reason); - It is not as simple as Nostr, as it was primarily made for P2P syncing, with "pubs" being an afterthought; - Still, it may be worth considering using SSB instead of this custom protocol and just adapting it to the client-relay server model, because reusing a standard is always better than trying to get people in a new one. ### The problem with other solutions that require everybody to run their own server - They require everybody to run their own server; - Sometimes people can still be censored in these because domain names can be censored. ## How does Nostr work? - There are two components: __clients__ and __relays__. Each user runs a client. Anyone can run a relay. - Every user is identified by a public key. Every post is signed. Every client validates these signatures. - Clients fetch data from relays of their choice and publish data to other relays of their choice. A relay doesn't talk to another relay, only directly to users. - For example, to "follow" someone a user just instructs their client to query the relays it knows for posts from that public key. - On startup, a client queries data from all relays it knows for all users it follows (for example, all updates from the last day), then displays that data to the user chronologically. - A "post" can contain any kind of structured data, but the most used ones are going to find their way into the standard so all clients and relays can handle them seamlessly. ## How does it solve the problems the networks above can't? - **Users getting banned and servers being closed** - A relay can block a user from publishing anything there, but that has no effect on them as they can still publish to other relays. Since users are identified by a public key, they don't lose their identities and their follower base when they get banned. - Instead of requiring users to manually type new relay addresses (although this should also be supported), whenever someone you're following posts a server recommendation, the client should automatically add that to the list of relays it will query. - If someone is using a relay to publish their data but wants to migrate to another one, they can publish a server recommendation to that previous relay and go; - If someone gets banned from many relays such that they can't get their server recommendations broadcasted, they may still let some close friends know through other means with which relay they are publishing now. Then, these close friends can publish server recommendations to that new server, and slowly, the old follower base of the banned user will begin finding their posts again from the new relay. - All of the above is valid too for when a relay ceases its operations. - **Censorship-resistance** - Each user can publish their updates to any number of relays. - A relay can charge a fee (the negotiation of that fee is outside of the protocol for now) from users to publish there, which ensures censorship-resistance (there will always be some Russian server willing to take your money in exchange for serving your posts). - **Spam** - If spam is a concern for a relay, it can require payment for publication or some other form of authentication, such as an email address or phone, and associate these internally with a pubkey that then gets to publish to that relay — or other anti-spam techniques, like hashcash or captchas. If a relay is being used as a spam vector, it can easily be unlisted by clients, which can continue to fetch updates from other relays. - **Data storage** - For the network to stay healthy, there is no need for hundreds of active relays. In fact, it can work just fine with just a handful, given the fact that new relays can be created and spread through the network easily in case the existing relays start misbehaving. Therefore, the amount of data storage required, in general, is relatively less than Mastodon or similar software. - Or considering a different outcome: one in which there exist hundreds of niche relays run by amateurs, each relaying updates from a small group of users. The architecture scales just as well: data is sent from users to a single server, and from that server directly to the users who will consume that. It doesn't have to be stored by anyone else. In this situation, it is not a big burden for any single server to process updates from others, and having amateur servers is not a problem. - **Video and other heavy content** - It's easy for a relay to reject large content, or to charge for accepting and hosting large content. When information and incentives are clear, it's easy for the market forces to solve the problem. - **Techniques to trick the user** - Each client can decide how to best show posts to users, so there is always the option of just consuming what you want in the manner you want — from using an AI to decide the order of the updates you'll see to just reading them in chronological order. ## FAQ - **This is very simple. Why hasn't anyone done it before?** I don't know, but I imagine it has to do with the fact that people making social networks are either companies wanting to make money or P2P activists who want to make a thing completely without servers. They both fail to see the specific mix of both worlds that Nostr uses. - **How do I find people to follow?** First, you must know them and get their public key somehow, either by asking or by seeing it referenced somewhere. Once you're inside a Nostr social network you'll be able to see them interacting with other people and then you can also start following and interacting with these others. - **How do I find relays? What happens if I'm not connected to the same relays someone else is?** You won't be able to communicate with that person. But there are hints on events that can be used so that your client software (or you, manually) knows how to connect to the other person's relay and interact with them. There are other ideas on how to solve this too in the future but we can't ever promise perfect reachability, no protocol can. - **Can I know how many people are following me?** No, but you can get some estimates if relays cooperate in an extra-protocol way. - **What incentive is there for people to run relays?** The question is misleading. It assumes that relays are free dumb pipes that exist such that people can move data around through them. In this case yes, the incentives would not exist. This in fact could be said of DHT nodes in all other p2p network stacks: what incentive is there for people to run DHT nodes? - **Nostr enables you to move between server relays or use multiple relays but if these relays are just on AWS or Azure what’s the difference?** There are literally thousands of VPS providers scattered all around the globe today, there is not only AWS or Azure. AWS or Azure are exactly the providers used by single centralized service providers that need a lot of scale, and even then not just these two. For smaller relay servers any VPS will do the job very well.

# A estrutura lógica do livro didático Todos os livros didáticos e cursos expõem seus conteúdos a partir de uma organização lógica prévia, um esquema de todo o conteúdo que julgam relevante, tudo muito organizadinho em tópicos e subtópicos segundo a ordem lógica que mais se aproxima da ordem natural das coisas. Imagine um sumário de um manual ou livro didático. A minha experiência é a de que esse método serve muito bem para ninguém entender nada. A organização lógica perfeita de um campo de conhecimento é o resultado **final** de um estudo, não o seu início. As pessoas que escrevem esses manuais e dão esses cursos, mesmo quando sabem do que estão falando (um acontecimento aparentemente raro), o fazem a partir do seu próprio ponto de vista, atingido após uma vida de dedicação ao assunto (ou então copiando outros manuais e livros didáticos, o que eu chutaria que é o método mais comum). Para o neófito, a melhor maneira de entender algo é através de imersões em micro-tópicos, sem muita noção da posição daquele tópico na hierarquia geral da ciência. * [Revista Educativa](nostr:naddr1qqyxgvfcxajkxe3cqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cfx0trx), um exemplo de como não ensinar nada às crianças. * [Zettelkasten](nostr:naddr1qqyrwwfh8yurgefnqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c7qmjrw), a ordem surgindo do caos, ao invés de temas se encaixando numa ordem preexistentes.

# Boardthreads This was a very badly done service for turning a Trello list into a helpdesk UI. Surprisingly, it had more paying users than [Websites For Trello](nostr:naddr1qqyrydpkvverwvehqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c9d4yku), which I was working on simultaneously and dedicating much more time to it. The Neo4j database I used for this was a very poor choice, it was probably the cause of all the bugs.  -<https://github.com/fiatjaf/boardthreads>

# Channels without HTLCs HTLCs below the dust limit are not possible, because they're uneconomical. So currently whenever a payment below the dust limit is to be made Lightning peers adjust their commitment transactions to pay that amount as fees in case the channel is closed. That's a form of reserving that amount and incentivizing peers to resolve the payment, either successfully (in case it goes to the receiving node's balance) or not (it then goes back to the sender's balance). SOLUTION I didn't think too much about if it is possible to do what I think can be done in the current implementation on Lightning channels, but in the context of Eltoo it seems possible. Eltoo channels have UPDATE transactions that can be published to the blockchain and SETTLEMENT transactions that spend them (after a relative time) to each peer. The barebones script for UPDATE transactions is something like (copied from the paper, because I don't understand these things): ``` OP_IF # to spend from a settlement transaction (presigned) 10 OP_CSV 2 As,i Bs,i 2 OP_CHECKMULTISIGVERIFY OP_ELSE # to spend from a future update transaction <Si+1> OP_CHECKLOCKTIMEVERIFY 2 Au Bu 2 OP_CHECKMULTISIGVERIFY OP_ENDIF ``` During a payment of 1 satoshi it could be updated to something like (I'll probably get this thing completely wrong): ``` OP_HASH256 <payment_hash> OP_EQUAL OP_IF # for B to spend from settlement transaction 1 in case the payment went through # and they have a preimage 10 OP_CSV 2 As,i1 Bs,i1 2 OP_CHECKMULTISIGVERIFY OP_ELSE OP_IF # for A to spend from settlement transaction 2 in case the payment didn't went through # and the other peer is uncooperative <now + 1day> OP_CHECKLOCKTIMEVERIFY 2 As,i2 Bs,i2 2 OP_CHECKMULTISIGVERIFY OP_ELSE # to spend from a future update transaction <Si+1> OP_CHECKLOCKTIMEVERIFY 2 Au Bu 2 OP_CHECKMULTISIGVERIFY OP_ENDIF OP_ENDIF ``` Then peers would have two presigned SETTLEMENT transactions, 1 and 2 (with different signature pairs, as badly shown in the script). On SETTLEMENT 1, funds are, say, 999sat for A and 1001sat for B, while on SETTLEMENT 2 funds are 1000sat for A and 1000sat for B. As soon as B gets the preimage from the next peer in the route it can give it to A and them can sign a new UPDATE transaction that replaces the above gimmick with something simpler without hashes involved. If the preimage doesn't come in viable time, peers can agree to make a new UPDATE transaction anyway. Otherwise A will have to close the channel, which may be bad, but B wasn't a good peer anyway.

# 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.

# Um algoritmo imbecil da evolução Suponha que você queira escrever a palavra BANANA partindo de OOOOOO e usando só alterações aleatórias das letras. As alterações se dão por meio da multiplicação da palavra original em várias outras, cada uma com uma mudança diferente. No primeiro período, surgem BOOOOO e OOOOZO. E então o ambiente decide que todas as palavras que não começam com um B estão eliminadas. Sobra apenas BOOOOO e o algoritmo continua. É fácil explicar conceber a evolução das espécies acontecendo dessa maneira, se você controlar sempre a parte em que o ambiente decide quem vai sobrar. Porém, há apenas duas opções: 1. Se o ambiente decidir as coisas de maneira aleatória, a chance de você chegar na palavra correta usando esse método é tão pequena que pode ser considerada nula. 2. Se o ambiente decidir as coisas de maneira pensada, caímos no //design inteligente//. Acredito que isso seja uma enunciação decente do argumento ["no free lunch"](https://en.wikipedia.org/wiki/No_free_lunch_in_search_and_optimization) aplicado à crítica do darwinismo por William Dembski. A resposta darwinista consiste em dizer que não existe essa BANANA como objetivo final. Que as palavras podem ir se alterando aleatoriamente, e o que sobrar sobrou, não podemos dizer que um objetivo foi atingido ou deixou de sê-lo. E aí os defensores do design inteligente dirão que o resultado ao qual chegamos não pode ter sido fruto de um processo aleatório. BANANA é qualitativamente diferente de AYZOSO, e aí há várias maneiras de "provar" que sim usando modelos matemáticos e tal. Fico com a impressão, porém, de que essa coisa só pode ser resolvida como sim ou não mediante uma discussão das premissas, e chega um ponto em que não há mais provas matemáticas possíveis, apenas subjetividade. Daí eu me lembro da minha humilde solução ao problema do cão que aperta as teclas aleatoriamente de um teclado e escreve as obras completas de Shakespeare: mesmo que ele o faça, nada daquilo terá sentido sem uma inteligência de tipo humano ali para lê-las e perceber que não se trata de uma bagunça, mas sim de um texto com sentido para ele. O milagre se dá não no momento em que o cão tropeça no teclado, mas no momento em que o homem olha para a tela. Se o algoritmo da evolução chegou à palavra BANANA ou UXJHTR não faz diferença pra ela, mas faz diferença para nós, que temos uma inteligência humana, e estamos observando aquilo. O homem também pensaria que há //algo// por trás daquele evento do cão que digita as obras de Shakespeare, e como seria possível alguém em sã consciência pensar que não?

# Money Supply Measurement What if we measured money supply measured by probability of being spent -- or how near it is to the point in which it is spent? bonds could be money if they're treated as that by their owners, but they are likely to be not near the spendpoint as cash, other assets can also be considered money but they might be even farther.

# 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.

# WelcomeBot The first bot ever created for Trello. It invited to a public board automatically anyone who commented on a card he was added to. - <https://github.com/fiatjaf/welcomebot> - <https://trello.com/welcomebot>

# Sol e Terra A Terra não gira em torno do Sol. Tudo depende do ponto de referência e não existe um ponto de referência absoluto. Só é melhor dizer que a Terra gira em torno do Sol porque há outros planetas fazendo movimentos análogos e aí fica mais fácil para todo mundo entender os movimentos tomando o Sol como ponto de referência.

# A list of things artificial intelligence is not doing If AI is so good why can't it: - write good glue code that wraps a documented HTTP API? - make good translations using available books and respective published translations? - extract meaningful and relevant numbers from news articles? - write mathematical models that fit perfectly to available data better than any human? - play videogames without cheating (i.e. simulating human vision, attention and click speed)? - turn pure HTML pages into pretty designs by generating CSS - predict the weather - calculate building foundations - determine stock values of companies from publicly available numbers - smartly and automatically test software to uncover bugs before releases - predict sports matches from the ball and the players' movement on the screen - continuously improve niche/local search indexes based on user input and and reaction to results - control traffic lights - predict sports matches from news articles, and teams and players' history This was posted first on [Twitter](https://twitter.com/fiatjaf/status/1477942802805837827).

# Reclamações - [Como não houve resposta, estou enviando de novo](nostr:naddr1qqyx2wfhvy6r2vejqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ct53y8g) - [Democracia na América](nostr:naddr1qqyrzc3ev3jn2vrpqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c8ynvrd) - [A "política" é a arena da vitória do estatismo](nostr:naddr1qqyx2wpnxdsnyvmpqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ccp2rh9) - [A biblioteca infinita](nostr:naddr1qqyryd3hv5crywp5qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ce8r2jh) - [Família e propriedade](nostr:naddr1qqyrwwpnxesnqvmrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c4s2ruz) - [Memórias de quando eu aprendi a ler](nostr:naddr1qqyrjve4vgunwctyqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cfdtahp) - [A chatura Kelsen](nostr:naddr1qqyr2df58qekxce3qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c0n53d9) - [O VAR é o grande equalizador](nostr:naddr1qqyxxwf5vesnywrpqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c7j5n5x) - [Não tem solução](nostr:naddr1qqyrswtxxdnxgdtrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823csj44kn) - [A estrutura lógica do livro didático](nostr:naddr1qqyrxv3j8qenxe3eqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ctyr464) - ["House" dos economistas e o Estado](nostr:naddr1qqyxxdfnv5cxyef4qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cdlmhy7) - [Revista Educativa](nostr:naddr1qqyxgvfcxajkxe3cqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cfx0trx) - [Cultura Inglesa e aprendizado extra-escolar](nostr:naddr1qqyr2errxcursvmzqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c8yqzwv) - [Veterano não é dono de bixete](nostr:naddr1qqyxvdm9v5ex2dmyqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823crahz92) - [Personagens de jogos e símbolos](nostr:naddr1qqyr2ctpv5crxdnpqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c60jj0x) - [Músicas grudentas e conversas](nostr:naddr1qqyr2etyvcunxve5qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cu35467) - [Obra aqui do lado](nostr:naddr1qqyxgd33vs6kzvf5qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c8vsd0u) - [Propaganda](nostr:naddr1qqyxgvtrxpjxgdtxqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cyzfj30) - [Ver Jesus com os olhos da carne](nostr:naddr1qqyrjdek8q6ngcfhqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c0zzevd) - [Processos Antifrágeis](nostr:naddr1qqyryv3hxfsnvvm9qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c5jshx7) - [Cadeias, crimes e cidadãos de bem](nostr:naddr1qqyrydt9xsuxxwryqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cgq9tqq) - [Castas hindus em nova chave](nostr:naddr1qqyrzcnyxyexxetpqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cqsz60h) - [Método científico](nostr:naddr1qqyr2wf3vgmx2dmrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823chtnaca) - [Xampu](nostr:naddr1qqyx2wphvccngwfeqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c5lczq3) - [Thafne venceu o Soletrando 2008.](nostr:naddr1qqyrgef5vdskvvr9qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cwxwyt5) - [Empreendendorismo de boteco](nostr:naddr1qqyrgc33v56kzdesqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cx5t67v) - [Problemas com Russell Kirk](nostr:naddr1qqyxzct9v33rjvp4qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cu9j032) - [Pequenos problemas que o Estado cria para a sociedade e que não são sempre lembrados](nostr:naddr1qqyrzdpexajkzenzqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ck07uru)

# The Lightning Network solves the problem of the decentralized commit Before reading this, see [Ripple and the problem of the decentralized commit](nostr:naddr1qqyrxcmzxa3nxv34qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cjrqar6). The Bitcoin Lightning Network can be thought as a system similar to Ripple: there are conditional IOUs (HTLCs) that are sent in "prepare"-like messages across a route, and a secret `p` that must travel from the final receiver backwards through the route until it reaches the initial sender and possession of that secret serves to prove the payment as well as to make the IOU hold true. The difference is that if one of the parties don't send the "acknowledge" in time, the other has a trusted third-party with its own clock (that is the clock that is valid for everybody involved) to complain immediately at the timeout: the Bitcoin blockchain. If C has `p` and B isn't acknowleding it, C tells the Bitcoin blockchain and it will force the transfer of the amount from B to C. ## Differences (or 1 upside and 3 downside) 1. The Lightning Network differs from a "pure" Ripple network in that when we send a "prepare" message on the Lightning Network, unlike on a pure Ripple network we're not just promising we will owe something -- instead we are putting the money on the table already for the other to get if we are not responsive. 2. The feature above removes the trust element from the equation. We can now have relationships with people we don't trust, as the Bitcoin blockchain will serve as an automated escrow for our conditional payments and no one will be harmed. Therefore it is much easier to build networks and route payments if you don't always require trust relationships. 3. However it introduces the cost of the capital. A ton of capital must be made available in channels and locked in HTLCs so payments can be routed. This leads to potential issues like the ones described in <https://twitter.com/joostjgr/status/1308414364911841281>. 4. Another issue that comes with the necessity of using the Bitcoin blockchain as an arbiter is that it may cost a lot in fees -- much more than the value of the payment that is being disputed -- to enforce it on the blockchain.[^closing-channels-for-nothing] ## Solutions Because the downsides listed above are so real and problematic -- and much more so when attacks from malicious peers are taken into account --, some have argued that the Lightning Network must rely on at least some trust between peers, which partly negate the benefit. The introduction of [purely trust-backend channels](https://gist.github.com/btcontract/d4122a79911eef2620f16b3dfe2850a8) is the next step in the reasoning: if we are trusting already, why not make channels that don't touch the blockchain and don't require peers to commit large amounts of capital? The reason is, again, the ambiguity that comes from [the problem of the decentralized commit](nostr:naddr1qqyrxcmzxa3nxv34qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cjrqar6). Therefore [hosted channels](https://gist.github.com/btcontract/d4122a79911eef2620f16b3dfe2850a8) can be good when trust is required only from one side, like in the final hops of payments, but they cannot work in the middle of routes without eroding trust relationships between peers (however they can be useful if employed as channels between two nodes ran by the same person). The next solution is [a revamped pure Ripple network](nostr:naddr1qqr8yatdwpkx2qg3waehxw309anxjct5dfskvtnrdaksygpm7rrrljungc6q0tuh5hj7ue863q73qlheu4vywtzwhx42a7j9n5psgqqqw4rsfyk3p9), one that solves the problem of the decentralized commit in a different way. [^closing-channels-for-nothing]: That is even true when, for reasons of the payment being so small that it doesn't even deserve an actual HTLC that can be enforced on the chain (as per the protocol), even then the channel between the two nodes will be closed, only to make it very clear that there was a disagreement. Leaving it online would be harmful as one of the peers could repeat the attack again and again. This is a proof that [ambiguity, in case of the pure Ripple network](nostr:naddr1qqyrxcmzxa3nxv34qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cjrqar6), is a very important issue.

# Reasons for miners to not steal See [Drivechain](nostr:naddr1qq9xgunfwejkx6rpd9hqzythwden5te0ve5kzar2v9nzucm0d5pzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqr4gumtjfnp) for an introduction. Here we'll just have a list of reasons why miners would not steal: - they will lose future fees from that specific drivechain: you can discount all future fees and condense them into a single present number in order to do some mathematical calculation. - they may lose future fees from all other Drivechains, if the users assume they will steal from those too. - Bitcoin will be devalued if they steal, because: - Bitcoin is worth more if it has Drivechains working, because it is more useful, has more use-cases, more users. Without Drivechains it necessarily has to be worth less. - Bitcoin has more fee revenue if has Drivechains working, which means it has a bigger chance of surviving going forward and being more censorship-resistant and resistant to State attacks, therefore it has to worth more if Drivechains work and less if they don't. - Bitcoin is worth more if the public perception is that Bitcoin miners are friendly and doing their work peacefully instead of being a band of revolted peons that are constantly threating to use their 75% hashrate to do evil things such as: - double-spending attacks; - censoring of transactions for a certain group of people; - selfish mining. - if Bitcoin is devalued its price is bound to fall, meaning that miners will lose on - their future mining rewards; - their ASIC investiment; - the same coins they are trying to steal from the drivechain. - if a mining pool tries to steal, they will risk losing their individual miners to other pools that don't. - whenever a steal attempt begins, the coins in the drivechain will lose value (if the steal attempt is credible their price will drop quite substantially), which means that if a coalition of miners really try to steal, there is an incentive for another coalition of miners to buy some devalued coins and then stop the steal.

# idea: a website for feedback exchange I thought a community of people sharing feedback on mutual interests would be a good thing, so as always I broadened and generalized the idea and mixed with my old criticue-inspired idea-feedback project and turned it into a "token". You give feedback on other people's things, they give you a "point". You can then use that point to request feedback from others. This could be made as an [Etleneum](nostr:naddr1qqyrjcny8qcn2ve4qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823crwzz2w) contract so these points were exchanged for satoshis using the shitswap contract (yet to be written). In this case all the Bitcoin/Lightning side of the website must be hidden until the user has properly gone through the usage flow and earned points. If it was to be built on Etleneum then it needs to emphasize the login/password login method instead of the lnurl-auth method. And then maybe it could be used to push lnurl-auth to normal people, but with a different name.

bolt12 problems =============== - clients can't programatically build new offers by changing a path or query params (services like zbd.gg or lnurl-pay.me won't work) - impossible to use in a load-balanced custodian way -- since offers would have to be pregenerated and tied to a specific lightning node. - the existence of fiat currency fields makes it so wallets have to fetch exchange rates from somewhere on the internet (or offer a bad user experience), using HTTP which hurts user privacy. - the vendor field is misleading, can be phished very easily, not as safe as a domain name. - onion messages are an improvement over fake HTLC-based payments as a way of transmitting data, for sure. but we must decide if they are (i) suitable for transmitting all kinds of data over the internet, a replacement for tor; or (ii) not something that will scale well or on which we can count on for the future. if there was proper incentivization for data transmission it could end up being (i), the holy grail of p2p communication over the internet, but that is a very hard problem to solve and not guaranteed to yield the desired scalability results. since not even hints of attempting to solve that are being made, it's safer to conclude it is (ii). bolt12 limitations ------------------ - not flexible enough. there are some interesting fields defined in the spec, but who gets to add more fields later if necessary? very unclear. - services can't return any actionable data to the users who paid for something. it's unclear how business can be conducted without an extra communication channel. bolt12 illusions ---------------- - recurring payments is not really solved, it is just a spec that defines intervals. the actual implementation must still be done by each wallet and service. the recurring payment cannot be enforced, the wallet must still initiate the payment. even if the wallet is evil and is willing to initiate a payment without the user knowing it still needs to have funds, channels, be online, connected etc., so it's not as if the services could rely on the payments being delivered in time. - people seem to think it will enable pushing payments to mobile wallets, which it does not and cannot. - there is a confusion of contexts: it looks like offers are superior to lnurl-pay, for example, because they don't require domain names. domain names, though, are common and well-established among internet services and stores, because these services have websites, so this is not really an issue. it is an issue, though, for people that want to receive payments in their homes. for these, indeed, bolt12 offers a superior solution -- but at the same time bolt12 seems to be selling itself as a tool for merchants and service providers when it includes and highlights features as recurring payments and refunds. - the privacy gains for the receiver that are promoted as being part of bolt12 in fact come from a separate proposal, blinded paths, which should work for all normal lightning payments and indeed are a very nice solution. they are (or at least were, and should be) independent from the bolt12 proposal. a separate proposal, which can be (and already is being) used right now, also improves privacy for the receiver very much anway, it's called trampoline routing.

# Músicas novas e conhecidas Quando for ouvir música de fundo, escolha músicas bem conhecidas. Para ouvir músicas novas, reserve um tempo e ouça-as com total atenção. Uma coisa similar é dirigir por caminhos conhecidos versus dirigir em lugares novos. a primeira opção te permite fazer coisas enquanto dirige "de fundo", a segunda requer atenção total. Com músicas, tenho errado constantemente em achar que posso conhecer músicas novas ao mesmo tempo em que me dedico a outras tarefas. ## See also: * [Músicas que você já conhece](nostr:naddr1qqyxxvn9xquxgcn9qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c839sxv)

# ijq An interactive REPL for `jq` with smart helpers (for example, it automatically assigns each line of input to a variable so you can reference it later, it also always referenced the previous line automatically). - <https://github.com/fiatjaf/ijq> ## See also - [jiq](nostr:naddr1qqyrqvfjv33rxcenqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cd86z7d) - [jq-web](nostr:naddr1qqyrzvrzxqcx2dfsqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c90hqwz)

# idea: clarity.fm on Lightning Getting money from clients very easily, dispatching that money to "world class experts" (what a silly way to market things, but I guess it works) very easily are the job for Bitcoin and the Lightning Network. ### EDIT 2020-09-04 My idea was that people would advertise themselves, so you would book an hour with people you know already, but it seems that clarify.fm has gone through the route of offering a "catalog of experts" to potential clients, all full of verification processes probably and marketing. So I guess this is not a thing I can do. Actually I did <https://s4a.etleneum.com/> (on [Etleneum](nostr:naddr1qqyrjcny8qcn2ve4qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823crwzz2w)) that is somewhat similar, but of course doesn't have the glamour and network effect and marketing -- also it's just text, when in Clarity is fancy calls. Thinking about it, this is just a simple and obvious idea: just copy things from the fiat world and make them on Lightning, but maybe it is still worth pointing these out as there are hundreds of developers out there trying to make yet another lottery game with Lightning. It may also be a good idea to not just copy fiat-businesses models, but also change them experimenting with new paradigms, like [idea: Patreon, but simple, and without subscription](nostr:naddr1qqyrgcnrvcmxxc3hqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c3cfczc).