@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# Soft-fork activation through `bitcoind` competition Or: how to activate [_Drivechain_](nostr:naddr1qq9xgunfwejkx6rpd9hqzythwden5te0ve5kzar2v9nzucm0d5pzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqr4gumtjfnp). Imagine a world in which there are 10 different `bitcoind` flavors, as described in [`bitcoind` decentralization](nostr:naddr1qqyxzcfevscxzvnrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823chus9ym). Now how do you enable a soft-fork? Flavor 1 enables it. Seeing that nothing bad happened, flavor 2 enables it. Then flavor 3 enables it. And so on. When what is perceived by miners to be a big chunk of support for the proposal, a miner can try to mine a block that contains the new feature. No need for a flag day or a centralized decision making process that depends on one or two courageous leaders to enable a timer. --- This probably sounds silly, and maybe is.

@ 3bf0c63f:aefa459d

# Programming quibbles * [About CouchDB](nostr:naddr1qqyrwepevf3n2wf5qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c0jq39e) * [my personal approach on using `let`, `const` and `var` in javascript](nostr:naddr1qqyrxcmxvyun2vr9qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cvj9k9l) * [A crappy course on torrents](nostr:naddr1qqyrwdfevfjnxefcqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cuskhxf) * [Multi-service Graph Reputation protocol](nostr:naddr1qqyxxefex9nryvf3qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cpwsxjw) * [The monolithic approach to CouchDB views](nostr:naddr1qqyrswrpvdsnsc3nqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823car67ph) * [My stupid introduction to Haskell](nostr:naddr1qqyrxveevscrqcmrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cxd5qyk) * [The unit test bubble](nostr:naddr1qqyrjerxxyukgvm9qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cqu7c5h) * [There's a problem with using Git concepts for everything](nostr:naddr1qqyxyd3nx3sngepcqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cpp5kem) * [On the state of programs and browsers](nostr:naddr1qqyxgdfe8qexvd34qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cd7nk4m) * [Rust's `.into()` is a strictly bad thing](nostr:naddr1qqyrzd3kx9snzdesqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cvlm2vc)

@ 3bf0c63f:aefa459d

# How to fight a war without a State (The title is misleading.) > I don't see how you can successfully resist an invasion without a centralized entity to coordinate things on a high level. This is the argument used every time the topic of war is raised in a conversation that involved talks of anarchism and ending the State, and it did not fail to show up again in a conversation about Russia's invasion of Ukraine now. Turns out there is a simple answer: if there was no State there would be no invasion because if you assume Ukrainian people wouldn't be able to organize a defense then you much more have to assume that the Russian people won't organize an attack. The answer is unsatisfactory because there may be a Russian state organizing the attack while there is no Ukrainian State to organize the defense (because somehow the Ukrainian libertarians succeeded in ending the State just inside the borders of Ukraine). In this case it may be that the Russian State will occupy Ukraine and now the Ukrainian people will have to pay taxes and submit to psychopath politicians again, and Ukrainian libertarians will have another State to fight against. ### The nature of the State This situation, if it ever happened, would showcase again the nature of the State, which is, as described by Franz Oppenheimer, the apparatus formed by a group that conquered the another group. In this case the Russian high politicians and military conquered the people of Ukraine -- just like they had conquered the Russian peoples (or taken the control of the Russian government from others that conquered these peoples before). ### What has changed? If you compare the situation of Ukrainian people before the Ukrainian State ended and after the Russia dominated, has it worsen significantly? No. Maybe it is a little worse because the Russian State is worse than the Ukrainian State, but it could have been better if Ukraine had been conquered by some other country (could also have been worse). ### What is to be done? There is no real conclusion, i.e. I don't know what to do about Russia vs Ukraine. In this specific case maybe it makes sense to join the Ukraine government to defend against Russia -- if you think the Ukrainian government is so much better than the Russian. But to what point? I have no idea. The fight against the State will have to continue in any case. ### Not necessarily For the purposes of the reasoning above we granted that the Russian State would successfully invade and conquer Stateless Ukraine, but that is not certain. Many people have imagined ways in which a stateless society could fight back an organized army, and these ideas are not more absurd than some of the things we see in the real State vs State war.

@ 3bf0c63f:aefa459d

# A crappy course on torrents In 8 points[^twitterlink]: 1. You start seeding a file -- that means you split the file in a certain way, hash the pieces and wait. 2. If anyone connects to you (either by TCP or UDP -- and now there's the webRTC transport) and ask for a piece you'll send it. 3. Before downloading anything leechers must understand how many pieces exist and what are they -- and other things. For that exists the .torrent file, it contains the final hash of the file, metadata about all files, the list of pieces and hash of each. 4. To know where you are so people can connect to you[^nathole], there exists an HTTP (or UDP) server called "tracker". A list of trackers is also contained in the .torrent file. 5. When you add a torrent to your client, it gets a list of peers from the trackers. Then you try to connect to them (and you keep getting peers from the trackers while simultaneously sending data to the tracker like "I'm downloading, I have x bytes already" or "I'm seeding"). 6. Magnet links contain a tracker URL and a hash of the metadata contained in the .torrent file -- with that you can safely download the same data that should be inside a .torrent file -- but now you ask it from a peer before requesting any actual file piece. 7. DHTs are an afterthought and I don't know how important they are for the torrent ecosystem (trackers work just fine). They intend to replace the centralized trackers with message passing between DHT peers (DHT peers are different and independent from file-download peers). 8. All these things (.torrent files, tracker messages, messages passed between peers) are done in a peculiar encoding format called "bencode" that is just a slightly less verbose, less readable JSON. [^twitterlink]: Posted first as [this Twitter thread](https://twitter.com/fiatjaf/status/1282108860405297153). [^nathole]: Also your torrent client must be accessible from the external internet, NAT hole-punching is almost a myth.

@ 3bf0c63f:aefa459d

# Formula for making games with satoshis I think the only way to do in-game sats and make the game more interesting instead of breaking the mechanics is by doing something like 1. Asking everybody to pay the same amount to join; 2. They get that same amount inside the game as balances; 3. They must use these balances to buy items to win the game; 4. The money they used becomes available as in-game rewards for other players; 5. They must spend some money otherwise they just lose all the time; 6. They can't use too much because if they run out of money they are eliminated. If you think about it, that's how poker mostly works, and it's one of the few games in which paying money to play makes the game more interesting and not less. In _Poker_: 1. Everybody pays the same amount to join. 2. Everybody gets that amount in tokens or whatever, I don't know, this varies; 3. Everybody must pay money to bet on each hand; 4. The money used on each round is taken by the round winner; 5. If you don't bet you can't play the rounds, you're just eliminated; 6. If you go all-in all the time like a mad person you'll lose. In a game like _Worms_, for example, this could be something like: 1. Idem; 2. Idem; 3. You must use money to buy guns and ammunitions; 4. Whatever you spent goes to a pot for the winners or each round -- or maybe it goes to the people that contributed in killing you; 5. If you don't buy any guns you're useless; 6. If you spend everything on a single gun that's probably unwise. You can also apply this to games like _Counter-Strike_ or _Dota_ or even _Starcraft_ or [Bolo](nostr:naddr1qqzxymmvduq3zamnwvaz7tmxd9shg6npvchxxmmdqgsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8grqsqqqa28xcgpk4) and probably to most games as long as they have a fixed duration with a fixed set of players. The formula is not static nor a panacea. There is room for creativity on what each player can spend their money in and how the spent money is distributed during the game. Some hard task of balancing and incentivizing is still necessary so the player that starts winning doesn't automatically win for having more money as the game goes on.

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# Ver Jesus com os olhos da carne Olavo: "Ver Jesus com os olhos da carne, sobretudo vê-Lo operando milagres, é altíssimo conhecimento espiritual. Muitos o receberam, mas nem todos o aceitaram. A fé, às vezes, não é só saber algo que você ainda não viu. É permanecer fiel a algo que você viu e que tudo em volta o induz a negar." Me lembrou do episódio do flautista n'O Vento dos Salgueiros.

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# Reisman on opportunity cost If I bought things for 10 and sold them for 20 did I earn a profit of 10? -- Yes, says common sense. -- No, says the economist, because you could have bought a bond that yielded you some return with those initial 10 then spent your time working for someone else instead of working in your sales business. If that yielded more money than 10 then you actually had a loss. That is crazy, because it produces an economy in which everybody is always losing all the time, except one ideal person who makes all the correct investment decisions and thus has no opportunity cost. That person has a profit of zero. -- George Reisman in <https://www.bobmurphyshow.com/139>

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# Timeu Os quatro elementos, a esfera como a forma mais perfeita, os cinco sentidos, a dor como perturbação e o prazer como retorno, o demiurgo que cria da melhor maneira possível com a matéria que tem, o conceito de duro e mole, todas essas coisas que ensinam nas escolas e nos desenhos animados ou sei lá como entram na nossa consciência como se fossem uma verdade, mas sempre uma verdade provisória, infantil -- como os nomes infantis dos dedos (mata-piolho, fura-bolo etc.) --, que mesmo as crianças sabem que não é verdade mesmo. Parece que todas essas coisas estão nesse livro. Talvez até mesmo a classificação dos cinco dedos como mata-piolho e tal, mas talvez eu tenha dormido nessa parte. Me pergunto se essas coisas não eram ensinadas tradicionalmente na idade média como sendo verdade absoluta (pois afinal estava lá o Platão dizendo, em sua única obra) e persistiram até hoje numa tradição que se mantém aos trancos e barrancos, contra tudo e contra todos, sem ninguém saber como, um conhecimento em que ninguém acredita mas acha bonito mesmo assim, harmonioso, e vem despida de suas origens e fontes primárias e de todo o seu contexto perturbar o entendimento do mundo pelas crianças.

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# A podridão É razoável dizer que há três tipos de reações à menção do nome [O que é Bitcoin?](nostr:naddr1qqrky6t5vdhkjmspz9mhxue69uhkv6tpw34xze3wvdhk6q3q80cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsxpqqqp65wp3k3fu) no Brasil: 1. A reação das pessoas velhas Muito sabiamente, as pessoas velhas que já ouviram falar de Bitcoin o encaram ou como uma coisa muito distante e reservada ao conhecimento dos seus sobrinhos que entendem de computador ou como um golpe que se deve temer e do qual o afastamento é imperativo, e de qualquer modo isso não as deve afetar mesmo então para que perder o seu tempo. Essas pessoas estão erradas: nem o sobrinho que entende de computador sabe nada sobre Bitcoin, nem o Bitcoin é um golpe, e nem é o Bitcoin uma coisa totalmente irrelevante para elas. É razoável ter cautela diante do desconhecido, no que as pessoas velhas fazem bem, mas creio eu que também muito do medo que essas pessoas têm vem da ignorância que foi criada e difundida durante os primeiros 10 anos de Bitcoin por jornalistas analfabetos e desinformados em torno do assunto. 2. A reação das pessoas pragmáticas "Já tenho um banco e já posso enviar dinheiro, pra que Bitcoin? O quê, eu ainda tenho que pagar para transferir bitcoins? Isso não é vantagem nenhuma!" Enquanto querem parecer muito pragmáticas e racionais, essas pessoas ignoram vários aspectos das suas próprias vidas, a começar pelo fato de que o uso dos bancos comuns não é gratuito, e depois que a existência desse sistema financeiro no qual elas se crêem muito incluídas e confortáveis é baseada num grande esquema chamado Banco Central, que tem como um dos seus fundamentos a possibilidade da inflação ilimitada da moeda, que torna todas as pessoas mais pobres, incluindo essas mesmas, tão pragmáticas e racionais. Mais importante é notar que essas pessoas tão racionais foram também ludibriadas pela difusão da ignorância sobre Bitcoin como sendo um sistema de transferência de dinheiro. O Bitcoin não é e não pode ser um sistema de transferência de dinheiro porque ele só pode transferir-se a si mesmo, não pode transferir "dinheiro" no sentido comum dessa palavra (tenho em mente o dinheiro comum no Brasil, os reais). O fato de que haja hoje pessoas que conseguem "transferir dinheiro" usando o Bitcoin é uma coisa totalmente inesperada: a existência de pessoas que trocam bitcoins por reais (e outros dinheiros de outros lugares) e vice-versa. Não era necessário que fosse assim, não estava determinado em lugar nenhum, 10 anos atrás, que haveria demanda por um bem digital sem utilidade imediata nenhuma, foi assim por um milagre. Porém, o milagre só estará completo quando esses bitcoins se tornarem eles mesmo o dinheiro comum. E aí assim será possível usar o sistema Bitcoin para transferir dinheiro de fato. Antes disso, chamar o Bitcoin de sistema de pagamentos ou qualquer coisa que o valha é perverter-lhe o sentido, é confundir um acidente com a essência da coisa. 3. A reação dos jovens analfabetos Os jovens analfabetos são as pessoas que usam a expressão "criptos" e freqüentam sítios que dão notícias totalmente irrelevantes sobre "criptomoedas" o dia inteiro. Não sei muito bem como eles vivem porque não lhes suporto a presença, mas são pessoas que estão muito empolgadas com toda a "onda das criptomoedas" e acham tudo muito incrível, tão incrível que acabam se interessando e então comprando todos os tokens vagabundos que inventam. Usam a palavra "decentralizado", um anglicismo muito feio que deveria significar que não existe um centro controlador da moeda x ou y e que o seu protocolo continuaria funcionando mesmo que vários operadores saíssem do ar, mas como o aplicam aos tokens que são literalmente emitidos por um centro controlador com uma figura humana no centro que toma todas as decisões sobre tudo -- como o Ethereum e conseqüentemente todos os milhares de tokens ERC20 criados dentro do sistema Ethereum -- essa palavra não faz mais sentido. Na sua empolgação e completo desconhecimento sobre como um ente nocivo poderia destruir cadauma das suas criptomoedas tão decentralizadas, ou como mesmo sem ninguém querer uma falha fundamental no protocolo e no sistema de incentivos poderia pôr tudo abaixo, sem imaginar que toda a valorização do token XYZ pode ter sido fabricada de caso pensado pelos seus próprios emissores ou só ser mesmo uma bolha, acabam esses jovens por igualar o token XYZ, ou ETH, BCH ou o que for, ao Bitcoin, ignorando todas as diferenças qualitativas e apenas mencionando de leve as quantitativas. Misturada à sua empolgação, e como um bônus, surge a perspectiva de ficar rico. Se um desses por algum golpe de sorte surfou em alguma bolha como a de 2017 e conseguiu multiplicar um dinheiro por 10 comprando e vendendo EOS, já começa logo a usar como argumento para convencer os outros de que "criptomoedas são o futuro" o fato de que ele ficou rico. Não subestime a burrice humana. --- Há jovens no grupo das pessoas velhas, velhas no grupo das pessoas jovens, pessoas que não estão em nenhum dos grupos e pessoas que estão em mais de um grupo, isso não importa.

@ 3bf0c63f:aefa459d

# jq-finder Made with [jq-web](nostr:naddr1qqyrzvrzxqcx2dfsqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c90hqwz), a tool to explore JSON using `jq` queries that build intermediate results so you can inspect each step of the process.  - <https://jq.alhur.es/finder/> - <https://github.com/fiatjaf/jq-finder>

@ 3bf0c63f:aefa459d

# trackingco.de Setting up Google Analytics for a bunch of very small projects was a big hassle for me, the bureaucracy involved in creating Google Analytics projects/pages/websites involved something like 4 or 5 forms, and then I always got confused when I went to browse the most simple stats (pageviews, sessions, referrers), and the page was slow to open, had more information than was needed or desirable and so on. And finally there was always a ton of referrer spam (people who used the referrer tracking function of Google Analytics to insert their own sites there somehow and get me to click them). Then I tried to use the only alternative that existed at the time: gaug.es, but although it was better it wasn't as better as it could be. I wanted a very minimalistic thing. And it was too expensive (for my standards). So I wrote my own, in React, specifically aimed to people who have a lot of small websites they wanted to track, using [Bulma](https://bulma.io/) for the styles, [react-dnd](https://react-dnd.github.io/react-dnd/) to make nice reorderable cards with the information and the most efficient scheme for storing the smallest amount of data possible in the database (first CouchDB, then migrated to Postgres later) while still providing session tracking and an optional way to assign points to each action a visitor may perform in a website.   At its height I personally used it with more than 20 projects. There were some other users, but the only one that actually used it besides me was <https://eternum.io/> (although I didn't charge them). I set up a very low pricing range and tried to market it in all the usual "hacker" sites, but never get any attention. At its last days I started pricing it in Bitcoin, but it made no difference. Then all of a sudden about 5 different "minimalistic" website tracking and tools very similar to trackingco.de began to show up on Hacker News and they got a ton of interest and users. They weren't better than trackingco.de as far as I know. It was frustrating. - <https://github.com/fiatjaf/trackingco.de> ## See also - [microanalytics](nostr:naddr1qqyr2cfcv56nvdtyqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ct57qq4)

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# Economics Just a bunch of somewhat-related notes. * [notes on "Economic Action Beyond the Extent of the Market", Per Bylund](nostr:naddr1qqyxxepsx3skgvenqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cf5cy3p) * [Mises' interest rate theory](nostr:naddr1qqyr2dtrxycr2dmrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c97asm3) * [Profits, not wages, as the originary factor](nostr:naddr1qqyrge3hxa3rqce4qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c7x67pu) * [Reisman on opportunity cost](nostr:naddr1qqyrswtr89nxvepkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cwx7t3v) * [Money Supply Measurement](nostr:naddr1qqyr2v3cxcunserzqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cya65m9) * [Per Bylund's insight](nostr:naddr1qqyxvdtzxscxzcenqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cuq3unj) * [Maybe a new approach to the Austrian Business Cycle Theory, some disorganized thoughts](nostr:naddr1qqyrvdecvccxxcejqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cl9wc86) * [An argument according to which fractional-reserve banking is merely theft and nothing else](nostr:naddr1qqyrywt9v5exydenqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cfks90r) * [Conjecture and criticism](nostr:naddr1qqyrqde5x9snqvfnqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ce4glh8) * [Qual é o economista? (piadas)](nostr:naddr1qqyx2vmrx93xgdpjqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c0ckmsx) * [UBI calculations](nostr:naddr1qqyryenpxe3ryvf4qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cuurj42) * [Donations on the internet](nostr:naddr1qqyrqwp4xsmnsvtxqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cex8903)

@ 3bf0c63f:aefa459d

# Agentes racionais Existe essa discussão entre economistas sobre o comportamento de um agente ser "racional" ou não. O julgamento da racionalidade é feito em vista de um "modelo" concebido pelo economista. Cada economista usa um modelo diferente. Daí ficam todos discutindo a racionalidade ou irracionalidade de certo agente. A solução é perguntar: racional segundo quais critérios?

@ 3bf0c63f:aefa459d

# Gŕecia Antiga e homosexualismo cultural Se na Grécia Antiga o homosexualismo era tão comum, não seria isso um argumento definitivo contra o pessoal que hoje afirma que o homosexualismo é natural e que 0.1%/1%/10%/25% das pessoas são homosexuais por natureza? Se na Gŕecia Antiga havia muito mais de 25% de homosexuais e aqui até ontem eram menos de 1% (e agora subiu?) isso tudo não é evidência fortíssima de que o homosexualismo é mesmo cultural?

@ 3bf0c63f:aefa459d

# Bitcoin, not you Bitcoin is not here to delight you. Bitcoin doesn't exist so you can receive money and trustlessly verify that you received money in your own node, which you _use_. Bitcoin is not about your desire of being "self-sovereign" and "your own bank". Bitcoin is a gift from God that will bring the end of all inflation, all its other characteristics are secondary. Bitcoin is not money if not for the others.

@ 3bf0c63f:aefa459d

# Temperos "Templates as a service", or "temperaas", changed to "temperos" later because it was a nice pun in Portuguese. The ideas was that it would take an URL with any file and some querystring parameters, then replace `{{paramName}}` with the parameters from the querystring and serve it, all stateless. Created to make it easy for people to embed scripts on [Websites For Trello](nostr:naddr1qqyrydpkvverwvehqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c9d4yku) (but of course it was too hard for most people). - <https://github.com/fiatjaf/temperos> - <https://temperos.alhur.es/>

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# Qual é o economista? (piadas) O economista americano rapper ficou triste quando sua banda brasileira favorita encerrou suas atividades por crer que a demanda por discos de rap seria cada vez pior. Resposta: Robert Lucas e as expectativas dos Racionais. O economista inglês queria muito arrumar uma namorada. Resposta: John Maynard Keynes e a demanda afetiva. Quando o filho do economista austríaco chegou em casa todo sujo ele sem nem pensar ordenou que o moleque fosse tomar banho. Resposta: Friedrich Hayek e a ordem espontânea. O economista americano tinha muito orgulho de ter em sua casa um valiosíssimo quadro de um impressionista francês. Resposta: Milton Friedman e o Monet raríssimo. O economista austríaco jurou aos seus filhos que todos eles se mudariam para Brasília. Resposta: Eugen von Böhm-Bawerk e o “eu juro” da capital. O economista alemão organizou um evento meio sertanejo meio religioso e colocou como organizador uma executiva que tinha quebrado suas últimas 4 empresas por má administração. Resposta: Karl Marx e a expo-oração da que mais-falia.

@ 3bf0c63f:aefa459d

# Firefox in comparison with Chrome as of 2018 Better - Faster page loads - Displays `<table>`s better by default - Using the same browser on multiple places actually makes your experience better, because you can list and send tabs from one device to another - Firefox for Android is vastly superior: - It is much faster - It allows you to install browser extensions, which means you get to use uBlock Origin on Android - It allows you to send and receive tabs from the desktop - It has a built-in QR code scanner - Telegram notifications actually work - I'm not forced to see the neverending super-animated left-inclined special Google Doodles on my new tab page Basically the same thing - JavaScript speed - Overall stability - JavaScript new features support - All major browser extensions seem to be available for both platforms (although I'm not a huge extensions user so I don't know) Worse - Chrome has that nice OpenSearch support that allows you to type the beggining of a site's URL, hit tab and then perform a search query on that site if it supports OpenSearch (Firefox has OpenSearch support, but it works differently, in I way that feels odd to me) - Developer tools are much slower, so I use Chromium for debugging JavaScript apps and nothing more - CodeMirror doesn't allow me to paste using the middle-click on Linux, while in Chrome it does, who knows why? There's an issue open on GitHub, but no solution for the near future (I'm forced to call `xsel -p -o | xsel -b` before pasting stuff from the terminal)

@ 3bf0c63f:aefa459d

# Não tem solução O melhor presidente dos últimos 50 anos, o melhor congresso, o melhor governador, os melhores ministros, um resultado eleitoral muito melhor do que o melhor dos meus sonhos e nada acontece. A única solução que nos resta é o Bitcoin. Vale talvez a pena dar a vida pra tentar popularizar esse negócio.

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# Libertarianism, left and right, a worthless thought Every person is either in the left or in the right. You can see it by the way they do they manage their lives and their families. "Libertarianism" is not in that same category, because you can't manage your life or your family in a libertarian way. Libertarianism is a purely political idea, it only applies to what the State can do or if it should exist or not, nothing else. People who are from the left or from the right can be libertarian. People from these two camps can also not be libertarian, and then their political goals and ideals would be just an extrapolation of their views on family management. They will see the State as the big father, an image inherit from the media and other people, and go with it: if the State is the father of our big family, it should behave in regards to his children, the citizens, just like I would behave in regards to my children. ## Related - <https://www.bobmurphyshow.com/episodes/ep-159-gregory-gordon-on-left-vs-right-libertarianism/> - <https://mises.org/wire/why-theres-left-right-divide-among-libertarians>

@ 3bf0c63f:aefa459d

# Thomas Kuhn sequer menciona o "método científico" O que define uma ciência é o recorte de uma realidade a partir de um paradigma que todos os que entram no campo daquela ciência aceitam como verdade. Pronto. O "método científico" não é nem necessário nem suficiente (apesar de que ele mesmo precisa pressupor uma série de axiomas para funcionar, do contrário a pessoa ficaria tendo que testar cada sílaba dos seus experimentos e cada um desses testes seria impossível de realizar pois eles necessariamente precisariam de outros conhecimentos prévios etc.). Por isso - a física teórica pode ser uma ciência embora não faça experimentos; - e a economia pode ser uma ciência embora não faça experimentos (tá bom, existem pessoas que insistem em fazer "experimentos" em economia, mas que na verdade são só uma enorme perda de tempo baseada em estatísticas, mas isso não importa, até essas coisas podem ter algum valor desde que não se as entenda como sendo parte de um método científico); - e a história pode ser uma ciência, por mais estranho que isso pareça, bastando apenas que o historiador junte fatos de antigamente tendo como pressuposto um paradigma, por exemplo, de que existe um sentido da história, ou sei lá (não acho que exista essa ciência da história hoje em dia, me parece que cada historiador está fazendo uma coisa diferente, sem muitos paradigmas além do bom senso); - e a biologia pode ser uma ciência mesmo consistindo unicamente num longo esforço de classificação, e de fato é hoje, já que vê cada espécie e suas partes como frutos de um processo evolutivo cujas bases constituem um paradigma, e nega outras visões, como a teleologia. - [Método científico](nostr:naddr1qqyr2wf3vgmx2dmrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823chtnaca) - [A estrutura paradigmática da ciência](nostr:naddr1qqyrzdfsxyuxye3cqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c4awxqq) - [Um algoritmo imbecil da evolução](nostr:naddr1qqyryv35xsunwvfnqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c45a0t3)

@ 3bf0c63f:aefa459d

# Filemap [filemap](https://filemap.xyz/) solves the problem of sending and receiving files to and from non-tech people when you don't have a text communication channel with them. [](https://xkcd.com/949/) Imagine you want to send files to your grandfather, or you don't use Facebook and your younger cousin who only uses Facebook and doesn't know what is email wants to send you some pictures, it's pretty hard to get a file-sharing channel between people if they're not in the same network. If even the people have a way to upload the files to some hosting service and then share the link everything would still work, but you're not going to write `somehostingservice.com/wHr4y7vFGh0` to your grandfather -- or expect your cousin to do that for you and send you an SMS with dozens of those links. Solution: * Upload your files to https://filemap.xyz/ (you can either upload directly or share links to things already uploaded -- or even links to pages) and pin them to your grandfather's house address; then tell your grandfather to open https://filemap.xyz/ and look for his address. Done. * Tell your younger cousin to visit filemap.xyz and upload all the files to his address, later you open the site and look for his address. There are your files. --- Initially this used [ipfs-dropzone](nostr:naddr1qqyrjvrx8p3xyvesqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cwpfruw), but IPFS is broken, os I migrated to [WebTorrent](https://webtorrent.io/), but that required the file sender to be online hosting its own file and the entire idea of this service was to make something _easy_, so I migrated to Firebase Hosting, which is also terrible and has a broken API, but at least is capable of hosting files. Should have used something like S3. - <https://github.com/fiatjaf/filemap.xyz> - <https://filemap.xyz/>

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# Bitcoin Hivemind This page is a work in progress. For now, please head on to https://bitcoinhivemind.com/.

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# Músicas grudentas e conversas Uma vez que você ouviu uma música grudenta e ela volta, inteira, com toda a melodia e a harmonia, muitos dias depois, contra a sua vontade. Mas uma conversa é impossível de lembrar. Por quê?

@ 3bf0c63f:aefa459d

# Que vença o melhor Nos esportes e jogos em geral, existe uma constante preocupação em balancear os incentivos e atributos do jogo, as regras do esporte em si e as regras das competições para que o melhor vença, ou, em outras palavras, para que sejam minimizados os outros fatores exceto a habilidade mais pura quanto possível no jogo em questão. O mundo fora dos jogos, porém, nem sempre pode ter suas regras mudadas por um ente que as controla e está imbuído da vontade e dos meios para escolher as melhores regras possíveis para a obtenção dos resultados acima. Aliás, é muitas vezes essa possibilidade é até impensável. Mesmo quando ela é pensável e levada em conta os fatores que operam no mundo real não são facilmente identificáveis, eles são muitos, e mudam o tempo todo. Mais do que isso, ao contrário de um jogo em que o objetivo é praticamente o mesmo para todo mundo, os objetivos de cada agente no mundo real são diferentes e incontáveis, e as "competições" que cada um está disputando são diferentes e muitas, cada minúsculo ato de suas vidas compreendendo várias delas simultaneamente. Da mesma forma, é impossível conceber até mesmo o conceito de "melhor" para que se deseje que ele vença. Mesmo assim é comum encontrarmos em várias situações gente que parte do princípio de que se Fulano está num certo lugar (por exemplo, um emprego muito bom) e Beltrano não isso se deve ao fato de Fulano ter sido melhor que Beltrano. Está aí uma crítica à idéia da meritocracia (eu tinha me esquecido que essa palavra existia).

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# About CouchDB In [this][1] talk from 2009, Michael Miller highlights some of the core features of CouchDB, those that would make it appeal to the developer public: * Bi-directional incremental replication * Custom views built with Javascript functions and saved to disk * Filtered replication, so users can get part of the data * Couchapps: lightweight web apps served directly from the database ## What is the state of these awesome features today, 2016? The **replication protocol**, which supports multi-master, has changed little, and has received criticism, but, as it is, it is the only open replication protocol out there, the only one that stands the fight, and the only one people were able to implement in the browser. PouchDB is probably the main reason people adopt CouchDB today. There are other things that talk that same replication protocol, so that's a thing. **Continuous replication**, however, is too heavy, uses too much memory, and I don't think the idea of keeping two or more CouchDB databases in continuous replication today is good as it sounded back then. **Custom views** always seemed to me as a gift from heavens, the solution to the dilemma between normalization and data duplication, they should be fast and flexible and support any use-case. That's how it sounds in that Miller presentation. However, today most CouchDB seem to be approaching views as just a confusing complicated hard way to do simple queries, like getting a list of items by the name of the category they're in, and other boring queries you can imagine. This whole problem gave rise to the [Cloudant Query Language][2] and [pouchdb-find][3]. The second advertises itself as _"inspired by MongoDB, it provides a simple API with operators like `$gt` (greater-than) and `$eq` (equals), so you can write less code to achieve the same performance as the map/reduce API"_. In other words: everybody seem to be looking at CouchDB as just a very poor and limited MongoDB. To be fair, that is in fact the only sane way to approach CouchDB views, as other approaches, like the [monolithic][4], cannot be used with a lot of data, and you must be sure your blocks of data will not get too big if you're willing to put them in massive documents. **Filtered replication** was implemented, but it is slow to the point that no one recommends that you use them. I imagine the original idea was to mix filtered replication with Couchapps to make full-featured applications that the users would run on their own CouchDB instances, syncing back and forth from centralized CouchDB instances. This idea would have been even more powerful if done with PouchDB on the user side -- since, I guess, no one has ever succeeded in distributing a CouchDB application to end users that ran their own CouchDB --, however the inefficiency of filtered replication made all these dreams come apart. From the ruins of filtered replication emerged the db-per-user idea, which is the same filtered replication, but in such a way that a user owns the entire database and controls a PouchDB instance that replicates to and from that centralized database. The server may do things with the data stored in the CouchDB under its control, but the user at the same time has a copy of the entire data and it supposedly can work with it offline. This is a great idea, but if we look closely, it is much more limited than the original vision. About **Couchapps**, the special database features that powered them in the first place were left aside as offline-first database-per-user PouchDB apps started to gain hearts and minds, and on the other side apps that would rely on a single server started to require features, like sophisticated authorization and per-document access control, that could only be provided by putting a normal server in front of CouchDB. Like what happened to views, this is a sad thing. By trying to do things in the "regular" way, CouchDB users ignored CouchDB innovative ideas and made it look like a limited weird piece of software that lacks so many features that you must write [a ton of middleware][5] (that, of course, cannot be run inside CouchDB, what a limited server it is) to make it do simple stuff. I must say, before it is too late, that I'm not in the big enterprise game, so I don't know how (if any) enormous software companies are using CouchDB and how it is working for them, this is just my impression from the low end of things. [1]: <https://www.youtube.com/watch?v=engrF-7z8Q4> [2]: <https://docs.cloudant.com/cloudant_query.html> [3]: <https://nolanlawson.github.io/pouchdb-find/> [4]: <https://trello.com/c/qlL3HS5u/111-the-monolithic-approach-to-couchdb-views> [5]: <https://www.npmjs.com/browse/keyword/couchdb>

@ 3bf0c63f:aefa459d

# Processos Antifrágeis Há esse conceito, criado pelo genial [Nassim Nicholas Taleb](http://www.edge.org/memberbio/nassim_nicholas_taleb), que diz respeito a processos nos quais a curva de retorno em relação a uma variável aleatória é convexa, ou seja, o retorno tende a ser maior quanto mais aleatoriedade for adicionada ao processo.  Disso aí, o próprio [Taleb tira uma conclusão](http://wayback.archive.org/web/20130407070713/http://www.edge.org/conversation/understanding-is-a-poor-substitute-for-convexity-antifragility) que resolve a questão da pesquisa científica propositada contra a sorte, sobre quais levam a melhores resultados práticos e invenções. Escreve ele: > A história da sorte versus conhecimento é a seguinte: Ironicamente, temos imensamente mais evidência de resultados (descobertas úteis) ligados à sorte do que de resultados vindos da prática teleológica (de _telos_, “objetivo”), exceto na física — mesmo depois de descontarmos o sensacionalismo. Em alguns campos opacos e não-lineares, como a medicina ou a engenharia, as exceções teleológicas são a minoria, assim como são um pequeno número de remédios projetados. Isto nos deixa numa contradição de que chegamos até aqui graças ao puro acaso não-direcionado, mas ao mesmo tempo criamos programas de pesquisa que miram num progresso com direção definida, baseado em narrativas sobre o passado. E, o que é pior, estamos totalmente conscientes desta inconsistência. Por outro lado, pura sorte não poderia produzir melhorias _sempre_. Processos de tentativa e erro (que são os que produzem as descobertas “por sorte”) têm um elemento _erro_, e erros, diz Taleb, causam explosões de avião, quedas de edifícios e perda de conhecimento. A resposta, portanto, está na _antifragilidade_: as áreas onde a sorte vence a teleologia são as áreas onde estão em jogo sistemas complexos, onde os nexos causais são desconhecidos ou obscuros — e são as áreas onde a curva de retornos é convexa. > Vejamos a mais sombria de todas, a culinária, que depende inteiramente da heurística da tentativa e erro, já que ainda não nos foi possível projetar um prato direto de equações químicas ou descobrir, por engenharia reversa, gostos a partir de tabelas nutricionais. Pega-se o hummus, adiciona-se um ingrediente, digamos, uma pimenta, prova-se para ver se há uma melhora no gosto e guarda-se a receita, se o gosto for bom, ou descarta-se-á. Imprescindivelmente temos a opção, e não a obrigação, de guardar o resultado, o que nos deixa reter a parte superior da curva e nos impede de sermos lesados pelos retornos adversos. A conclusão geral é que, para obter os melhores resultados na invenção de tecnologias, deve-se usar a experimentação sem exageros e cálculos quando se identificar uma área antifrágil, e usar a pesquisa rígida e cheia de provas matemáticas (ou o equivalente) quando a área for frágil. ## A inovação capitalista Um processo antifrágil importantíssimo deste mundo é a **inovação capitalista** (dói-me usar este termo já tão mal-gasto e mal-definido por aí). Não falo, como alguns, da invenção de _novas tecnologias_, mas, como outros, da invenção de novas formas de usar as coisas (qualquer coisa) para melhorar a vida de alguém, de alguma forma — e aqui incluem-se pequenas adaptações de tecnologias antigas que dão origem a novas tecnologias não muito diferentes das antigas, e incluem-se também o oferecimento de algum serviço, trabalho ou produto já existente, mas de uma nova forma, possivelmente melhor para seu provável consumidor. Este tipo de inovação é, segundo me parece, o poder mais subestimado dos mercados livres, é irreplicável em laboratórios de pesquisa tecnológica (só pode surgir mesmo na vida real, da cabeça de quem está envolvido com o problema real que a inovação soluciona), e é o que gerou idéias como o restaurante self-service, a terceirização dos serviços de construção civil ou o Google. Esse tipo de inovação (ao contrário do sentido de inovação ligado a pesquisas caríssimas em universidades ou megaempresas, identificada pela famigerada sigla P&amp;D) é antifrágil porque não custa muito ao indivíduo, não requer investimentos gigantescos ou qualquer coisa assim, porque é normalmente apenas uma adaptação do que ele próprio já faz. Para a sociedade, não representa custo algum: o serviço novo é oferecido paralelamente ao serviço antigo, seus consumidores potenciais podem escolher o que mais lhes agrada, e rejeitar o outro. Se a nova solução não for satisfatória os mecanismos automáticos do mercado (o prejuízo simples) encarregam-se automaticamente de remover aquela novidade — e, automaticamente, o indivíduo que a criou pode se voltar ao seu processo antigo, ou a uma nova invenção. Ao mesmo tempo em que cometer um erro numa tentativa de inovação é barato e não atrapalha ninguém, um acerto pode ter conseqüências que melhoram enormemente a vida de muita gente. O restaurante self-service, por exemplo, provavelmente teve sua implementação tentada por restaurantes de serviço à la carte várias vezes, em vários formatos diferentes, sem muito prejuízo para o restaurante, que podia continuar com seu serviço à la carte (no Brasil, senão o inventor dessa modalidade de restaurante ao menos um dos seus grandes expoentes, estas tentativas ocorreram durante a década de 80). Mas, quando enfim deu certo, promoveu melhoras enormes na qualidade de vida de milhares de pessoas — que podem pagar mais barato e comer apenas o que querem e quanto querem, dentro de uma gama maior de opções, o que permite que trabalhadores de todos os tipos comam melhor todos os dias, fiquem mais felizes e gastem menos.

@ 3bf0c63f:aefa459d

# Revista Educativa Uma revista que traz resumos de grandes descobertas ciêntíficas e explica sua utilidade e relevância, explica os problemas e os "desafios" da sociedade moderna, faz propaganda de reciclagem e outras coisas supostamente boas ao meio-ambiente, e uma seção: "Quero ser cientista para... ajudar o mundo? Descobrir uma coisa muito boa? Escrever uma revista como esta?". Que grande bobagem.

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# Blockchains are not decentralized data storage People are used to saying and thinking that blockchains provide immutable data storage. Then many times they add a caveat that says blockchains are very expensive, so we can't really store too much data on them, but we can still store some data if we really want and are ok with paying for it. But the fact is that blockchains cannot ever be used to store anything. The purpose of blockchains is to keep track of some state that everybody must agree upon at all times, and arbitrary data that anyone may have wanted to backup there is not relevant to anyone else[^relevant] and thus there are no incentives for anyone else to keep track of that. In other words: if you backup your personal pictures as `OP_RETURN` outputs on Bitcoin, people may delete that and your backup will be void[^op-return-invalid-outputs]. Another thing blockchains supposedly do is to "broadcast" something. For example, nodes may delete the `OP_RETURN` outputs, but at least they have to verify these first, and spread they over the network, so you can broadcast your data and be sure everybody will get it. About this we can say two things: 1, if this happens, it's not a property of blockchains, but of the Bitcoin transaction sharing network that operates outside of the blockchain. 2, if you try to use that network for purposes that are irrelevant for the functioning of the Bitcoin protocol there is no incentive for other nodes to cooperate and they may ignore you. The above points may sound weird and you may be prompted to answer: but you can do all that today and there is no actual mechanism to stop anyone from broadcasting irrelevant crap!, and that is true. My point here is only that if you're thinking about blockchains as being this data-broadcast-storage mechanism you're thinking about them wrong, that is not an essential part of any blockchain. In other words: the incentives are not aligned for blockchains to be used like that (unless you come up with a scheme that makes data from everyone else to be relevant to everybody), in the long term such things are not expected to work and insisting on doing them will result in either your application or protocol that stores data on the blockchain to crash or in the death of the given blockchain (I hope Bitcoin haters don't read this). (This is a counterpoint to myself on [idea: Rumple](nostr:naddr1qqr8yatdwpkx2qg3waehxw309anxjct5dfskvtnrdaksygpm7rrrljungc6q0tuh5hj7ue863q73qlheu4vywtzwhx42a7j9n5psgqqqw4rsfyk3p9), which was a protocol idea that relied on a blockchain storing irrelevant data.) [^relevant]: For example, all Bitcoin transactions are relevant to all Bitcoin users because as a user the total supply and the ausence of double-spends are relevant, and also the fact that any of these transactions may end up being ancestors of transactions that you might receive in the future. [^op-return-invalid-outputs]: Of course you can still backup your pictures as invalid `P2PKH` outputs or something like that, then it will be harder for people to spot your data as irrelevant, but this is not a feature, it's a bug of Bitcoin that enables someone to spam other nodes in a way they can't detect it. If people started doing this a lot it would break Bitcoin.

@ 3bf0c63f:aefa459d

# Donations on the internet (This was written in the context of donations to people who do free stuff on the internet, open-source software and so on.) Donations are broken not because "few people care", but because it's an unsolvable information problem: no one knows how much they should be donating and to whom, and it would be impossible to even think about the perfect donation strategy, much more impossible to execute it. I use a ton of free services and consume tons of different contents from multiple sources, but it only occurred me to donate to some. And I'm probably donating too much to these, while zero to all others, or maybe too few even to the few ones I donate to. I cannot know. In the world of ideals there is a correct amount that each donor should be giving to each contributor in every single item in the full production structure of something the donors care about, but this is not a mathematical problem, it's the statement of an impossibility. Maybe <https://mises.org/library/superman-needs-agent> is related.

@ 3bf0c63f:aefa459d

# The illusion of checks and balances The website history.com has [a list of some of the most important "checks and balances"](https://www.history.com/topics/us-government/checks-and-balances) put in place by the United States Constitution. Here are some of them and how they are not real _checks_, they're flawed and easily bypassed by malicious peers that manage to enter the network. > The president (head of the executive branch) serves as commander in chief of the military forces, but Congress (legislative branch) appropriates funds for the military and votes to declare war. As it has happened [multiple times](https://en.wikipedia.org/wiki/Declaration_of_war_by_the_United_States#Undeclared_wars), the United States has engaged in many undeclared wars -- and many other military encounters that don't get enough media coverage and weren't even formally acknowledged by the Congress. > Congress has the power of the purse, as it controls the money used to fund any executive actions. There's a separate power called Federal Reserve which is more-or-less under the influence of the executive branch that is controlled by a single man and has the power of creating unlimited money. It was softly abused by the executive branch since its creation, but since 2008 it has been increasingly having its scope expanded from just influencing the banking sector to also directly using its money to buy all sorts of things and influence all sorts of markets and other actors. > Veto power. Once Congress has passed a bill, the president has the power to veto that bill. In turn, Congress can override a regular presidential veto by a two-thirds vote of both houses. If you imagine that both the executive and the legislative are 100% dedicated to go against each other the president could veto all bills, but then the legislative could enact them all anyway. Congress has the absolute power here (which can be justified by fact that the congress itself is split into multiple voters, but still this "veto" rule seems more like a gimmick to obscure the process than any actual check). > The Supreme Court and other federal courts (judicial branch) can declare laws or presidential actions unconstitutional, in a process known as judicial review. This rule gives absolute power to the Supreme Court over any matter. It can use their own personal judgement to veto any bill, cancel any action by the executive, reinterpret any existing law in any manner. There's no check against bad interpretations or judgements, so any absurd thing must be accepted. This should be obvious, and yet the entire system which most people believe to be "checked" is actually dependent on the good will and sanity of the judicial branch. > In turn, the president checks the judiciary through the power of appointment, which can be used to change the direction of the federal courts If the president and congress are being attacked by the judicial power, this isn't of much help as its effects are very long term. On the other hand, a president can single-handedly and arbitrarily use this rule to slowly poison the judicial system such that will turn malicious for the rest of the system after some time. > By passing amendments to the Constitution, Congress can effectively check the decisions of the Supreme Court. What is written in the Constitution can be easily ignored or misread by the members of the Supreme Court without any way for these interpretations to be checked or reverted. Basically the Supreme Court has absolute power over all things if we consider this. > Congress (considered the branch of government closest to the people) can impeach both members of the executive and judicial branches. Again (like in the presidential veto rule), this gives the congress unlimited power. There are no checks here -- except of course the fact that the congress is composed by multiple different voting heads of which a majority has to agree for the congress to do anything, which is the only thing preventing overabuse of this rule. --- As shown above, most rules that compose the "checks and balances" system can be abused and if given enough time they will. They aren't real checks. Ultimately, the stability and decency of a [democracy](nostr:naddr1qqyrxvtxxf3nse3sqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ccyra4y) relies on the majority rule (so congress votes are never concentrated in dictatorial measures) and the common sense of the powerful people (president and judges). There probably hasn't been a single year in any democracy in which one of these powers didn't abused or violated one of the rules, but still in most cases the overall system stays in place because of the general culture, splitted views about most issues, overall common sense and fear of public shame. The checks and balances system itself is an illusion. All the complex "democracy" construct depends on the goodwill of all the participants and have only worked so far (when it did) by miracle and by the power of human cooperation and love.

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# Conjecture and criticism I heard about this epistemological method _conjecture and criticism_ in [this video](https://www.youtube.com/watch?v=OPP_sYY2RPg). Oddly, it was portrayed as something that goes against the Austrian method by Paul Sztorc, while the other guy, JW Weatherman, was championing the "praxeological" method of pure logical deduction from first principles as the basis of all economic knowledge. It has always seemed to me that this pure logical reasoning was somewhat weird, specially in light of Carl Menger's _empiricism_ (which is not the same empiricism from modern sciences). Conjecture and criticism seems to fit better with Menger's method and whatever Austrians actually do. No one really reasons with pure logical deduction. What people do is spot something in the real world and try to come up with a reasonable explanation that is logically consistent. The entire logical impenetrability of every Austrian theory comes after the theory is conceived (conjected?) by a human mind, not -- like some praxeological claims would imply -- deducted as if by a computer. - [A Causa](nostr:naddr1qqyryvtrv5enyc3eqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c2jlyzx)

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# Castas hindus em nova chave Shudras buscam o máximo bem para os seus próprios corpos; vaishyas o máximo bem para a sua própria vida terrena e a da sua família; kshatriyas o máximo bem para a sociedade e este mundo terreno; brâmanes buscam o máximo bem.

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# nix Pra instalar o [neuron](797984e3.md) fui forçado a baixar e instalar o [nix](https://nixos.org/download.html). Não consegui me lembrar por que não estava usando até hoje aquele maravilhoso sistema de instalar pacotes desde a primeira vez que tentei, anos atrás. Que sofrimento pra fazer funcionar com o `fish`, mas até que bem menos sofrimento que da outra vez. Tive que instalar um tal de `fish-foreign-environment` (usando o próprio nix!, já que a outra opção era o `oh-my-fish` ou qualquer outra porcaria dessas) e aí usá-lo para aplicar as definições de shell para bash direto no `fish`. E aí lembrei também que o `/nix/store` fica cheio demais, o negócio instala tudo que existe neste mundo a partir do zero. É só para computadores muito ricos, mas vamos ver como vai ser. Estou gostando do neuron (veja, estou usando como diário), então vou ter que deixar o nix aí.

@ 3bf0c63f:aefa459d

# Como conversar com esquerdistas (notas de uma conversa com P.S., 12/3/17) Escutar o que ele está falando. E se o discurso dele é só uma coleção de lugares-comuns da esquerda (como deve ser, provavelmente), não tem problema. Fazer perguntas que tentam esclarecer o sentimento por trás do discurso (por exemplo, perguntar se o esquerdista tem medo de que Michel Temer vá empobrecer o Estado), e se a resposta for, de novo, um discurso pronto, repetir o processo (por exemplo, perguntar se o esquerdista tem medo de que o Estado pobre não poderá prover educação para a população), até chegar às raízes íntimas da inquietação que aquele esquerdista sente que tem alguma relação com aquele ponto. Quando chega-se a esse ponto, o serviço já está feito. O serviço de neutralizar a neurose para deixar a pessoa lidar com suas causas que se escondiam por baixo de um mar de racionalizações e discursos políticos. Um exemplo é o de que a pessoa foi assaltada. Nos momentos que se seguiram ao assalto, o sentimento de impotência e desorientação que ela experimentou era grande demais para ser tolerado ("por que eu? por que agora?") e então ela usou discursos que tinha ouvido para criar uma explicação para tudo aquilo, e a explicação acabou sendo a de que a falta de educação básica é que cria assaltantes, e essa educação precisa ser fornecida pelo Estado etc. Também não precisa ser tão traumático assim. Pode ser um fato que não envolveu nenhuma violência física, como a dor que ela sentiu ao ouvir um tio, que era professor infantil, numa roda de conversa, narrar, com alguma tristeza que ele tentava esconder, o fato de que fora demitido. Talvez este seja o processo que Olavo tentou fazer, sempre sem sucesso (já que, imagino, sem muito empenho), ao perguntar às pessoas "de onde elas tiraram essa idéia". É bastante importante, talvez a parte mais importante, a cada momento deste processo (e de todos, mas estamos falando deste), notar em nós mesmos que o que o que estamos fazendo, essas perguntas todas, é de certa forma também um discurso (perceba que tem até um manual ensinando, que é este texto mesmo), e que ele também deve ter suas origens neuróticas.

@ 3bf0c63f:aefa459d

# The "Drivechain will replace altcoins" argument The argument that [Drivechain](nostr:naddr1qq9xgunfwejkx6rpd9hqzythwden5te0ve5kzar2v9nzucm0d5pzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqr4gumtjfnp) will replace shitcoins is _not_ that people will [sell their shitcoins](https://twitter.com/craigwarmke/status/1680371502246514688) or that the existing shitcoins will instantly vanish. The argument is about a change _at the margin_ that eventually ends up killing the shitcoins or reducing them to their original insignificance. **What does "at the margin" mean?** For example, when the price of the coconut drops a little in relation to bananas, does that mean that everybody will stop buying bananas and will buy only coconuts now? No. Does it mean there will be [zero](https://twitter.com/GoingParabolic/status/1680319173744836609) increase in the amount of coconuts sold? Also no. What happens is that there is a small number of people who would have preferred to buy coconuts if only they were a little less expensive but end up buying bananas instead. When the price of coconut drops these people buy coconuts and don't buy bananas. The argument is that the same thing will happen when Drivechain is activated: there are some people today (yes, believe me) that would have preferred to work within the Bitcoin ecosystem but end up working on shitcoins. In a world with Drivechain these people would be working on the Bitcoin ecosystem, for the benefit of Bitcoin and the Bitcoiners. Why would they prefer Bitcoin? Because Bitcoin has a bigger network-effect. When these people come, they increase Bitocin's network-effect even more, and if they don't go to the shitcoins they reduce the shitcoins' network-effect. Those changes in network-effect contribute to bringing others who were a little further from the margin and the thing compounds until the shitcoins are worthless. Who are these people at the margin? I don't know, but they certainly exist. I would guess the Stark people are one famous example, but there are many others. In the past, examples included Roger Ver, Zooko Wilcox, Riccardo Spagni and Vitalik Buterin. And before you start screaming that these people are shitcoiners (which they are) imagine how much bigger Bitcoin could have been today if they and their entire communities (yes, I know, of awful people) were using and working for Bitcoin today. Remember that phrase about Bitcoin being for enemies? ### But everything that has been invented in the altcoin world is awful, we don't need any of that! You and me should not be the ones judging what is good and what is not for others, but both you and me and others will benefit if these things can be done in a way that increases Bitcoin network-effect and pays fees to Bitcoin miners. Also, there is a much stronger point you may have not considered: if you believe all altcoiners are scammers that means we have only seen the things that were invented by scammers, since all honest people that had good ideas decided to not implement them as the only way to do it would be to create a scammy shitcoin. One example is [Bitcoin Hivemind](nostr:naddr1qqyxs6tkv4kkjmnyqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cd3vm3c). If it is possible to do these ideas without creating shitcoins we may start to see new things that are actually good.

@ 3bf0c63f:aefa459d

# Scala is such a great language Scala is amazing. The type system has the perfect balance between flexibility and powerfulness. `match` statements are great. You can write imperative code that looks very nice and expressive (and I haven't tried writing purely functional things yet). Everything is easy to write and cheap and neovim integration works great. But Java is not great. And the fact that Scala is a JVM language doesn't help because over the years people have written stuff that depends on Java libraries -- and these Java libraries are not as safe as the Scala libraries, they contain reflection, slowness, runtime errors, all kinds of horrors. Scala is also very tightly associated with Akka, the actor framework, and Akka is a giant collection of anti-patterns. Untyped stuff, reflection, dependency on JVM, basically a lot of javisms. I just arrived and I don't know anything about the Scala history or ecosystem or community, but I have the impression that Akka has prevent more adoption of Scala from decent people that aren't Java programmers. But luckily there is a solution -- or two solutions: ScalaJS is a great thing that exists. It transpiles Scala code into JavaScript and it runs on NodeJS or in a browser! Scala Native is a much better deal, though, it compiles to LLVM and then to binary code and you can have single binaries that run directly without a JVM -- not that the single JARs are that bad though, they are great and everybody has Java so I'll take that anytime over C libraries or NPM-distributed software, but direct executables even better. Scala Native just needs a little more love and some libraries and it will be the greatest thing in a couple of years.

@ 3bf0c63f:aefa459d

# idea: Hosted-channels Lightning wallet that runs in the browser Communicates over HTTP with a server that is actually connected to the Lightning Network, but generates preimages and onions locally, doing everything like the [Hosted Channels protocol](https://github.com/btcontract/hosted-channels-rfc) says. Just the communication method changes. Could use this library: <https://www.npmjs.com/package/bolt04>

@ 3bf0c63f:aefa459d

# A Canção do Cavaleiro Bolsonaro > em meio ao caos, às trevas e à imundície > da esquerda atroz, que a pó a nação reduz > surge um guerreiro cavalgando as planícies > pra libertar a Terra de Santa Cruz > > tendo sua liberdade ameaçada > o povo prostra-se em pia oração > deus lhes envia com armadura prateada > o herói Jair, dos justos o bastião > > Bolsonaro mito > Bolsonaro mito > defende a liberdade neste conflito > > à serpente vermelha quem resiste? > são China e ONU seus braços de terror > mas Bolsomito com sua espada em riste > rasga o inimigo com a audácia de um condor > > por sua honra não se acovarda ou falha > imbuído está de intrepidez viril > vá Bolsonaro, vença essa batalha! > destrua o mal, salve o povo do Brasil > > Bolsonaro mito > Bolsonaro mito > defende a liberdade neste conflito Letra de Paulo Kogos, cantada por ele em <https://www.youtube.com/watch?v=b1BBY9e-__s>

@ 3bf0c63f:aefa459d

# Cultura Inglesa e aprendizado extra-escolar Em 2005 a Cultura Inglesa me classificou como nível 2 em proficiência de inglês, numa escala de 1 a 14 ou coisa parecida. De modo que eu precisaria de 6 anos de aulas com eles pra ficar bom. 2 anos depois, sem fazer nenhuma aula ou ter qualquer tipo de treinamento intensivo eu era capaz de compreender textos técnicos em inglês sem nenhuma dificuldade. Mais 2 anos e eu era capaz de compreender qualquer coisa e me expressar com razoável qualidade. Tudo isso pra documentar mais um exemplo, que poderia passar despercebido, de aprendizado de tipo escolar que se deu fora de uma escola.

@ 3bf0c63f:aefa459d

# IPFS problems: Pinning "Pin" is a nice word the IPFS team has come up with to designate the act of telling your node to store some content permanently and don't garbage-collect it. The idea is that you'll store everything you fetch and reroute this to others automatically, but every once in a while all content you have on your node that is not explicitly "pinned" will be erased, so you shouldn't worry about storing too much of other people's things, but also can contribute to keep alive content you like. Pinning has a big problem, however: you can't know what you've pinned. Every pin you add is going to be saved on your computer, you won't be able to unpin stuff because you don't know what is what, in the end you'll be left with a disk full of pinned stuff and probably lose that disk or delete everything to open up space for other things after getting frustrated with the entire IPFS experiment. Examine the incentives in this model: we're relying on sharing being made by people that do that unwillingly and unknowngly. Users spend electricity on nodes that are supposed to be always running and serving content to others. Links are only kept unbroken if someone decides to pin them, but since there's no order, the pins are doomed to be erased everywhere.

@ 3bf0c63f:aefa459d

# Maybe a new approach to the Austrian Business Cycle Theory, some disorganized thoughts This approach is loosely based on the guido-hulsmann concept of "cluster of errors" and on general ideas about capital heterogeneity taken from Lachmann. * Interest is just another price. Let's consider just flow of money and changes in relative prices instead. * Monetary policy is just one possible cause of relative prices misalignment. * The base interest rate is not very important, if there's a big flow of money to one specific sector that's what matters. There will be an unsustainable boom there. * Of course if there's a general reduction in interest rates that means there's a general flow of money to multiple sectors (those with lengthier production processes) or even disequilibria inside sectors towards more roundaboutness in an unsustainable manner (to talk about sectors is an oversimplification, these things don't exist in fact). * The standard ABCT formulation gives too much importance to the banking sector, as if it had a role in the economy much more important than anything else. That may not be the case. And even without banks at all still boom-bust cycles would happen if a new flow of printed money is directed somewhere (anywhere). This new approach solves: * Critiques of the theory like "oh, entrepreneurs are rational, they will know the monetary policy and don't overinvest" because now we can make it clear that they will follow relative prices. * The problem with talking about one single interest rate, as in the real world there multiple interest rates -- or in fact multiple interest rates for each agent at each point on time. * The problem with hayekian triangles. We can ignore these now because the concept of a general lengthening of a general production process is not the characteristic of the cycle anymore. That is just one possible example of cycle -- one that's probably very rare. * Garrison's powerpoint fundamental problem: it ignores the fundamental insight from Solow's growth model according to which economic growth can't be explained by considering just aggregate savings/investments. ### Networks of circles of production Instead of thinking in triangles[^hayekiantriangles] we can think in networks of circles of variable sizes. If we imagine there's a circle which represents one kind of good produced and for some reason there's an stimulus for the production of that good (for example, a governmental program that uses newly-printed money to subsidize loans for that specifically) that circle will get bigger. In the process of getting bigger it will also make bigger the circles that were already around it, and the biggerness will gradually spread. That means new investment is being made on each of these industries, malinvestiment. People and resources are migrating from other, more distant circles, to these circles nearer the epicenter of malinvestment. Representing the cycle that way we're free to oversimplify as you can just say: the real world is like this, but with many more circles and more complex relationships between them. You can also alternate between considering the circles sectors, industries or individual companies. ### No sequential "steps" of production, just plans Instead of imagining production princesses with discrete sequential steps we should also consider actually just plans. Entrepreneurs predict there will be demand and predict there well be suppliers with reasonable prices for them to complete a plan. The plan can be arbitrarily divided into production and sale of a good, but actually often these parts are not so simply detached from each other. In the network of circles the plan can be visualized as one circle looking around and seeing the other circles and estimating their future behavior. The boom stops and the bust happens when the predictions fail. They fail because the unsustainable stimulus that was causing some of the circles to increase continuously stops. [^hayekiantriangles]: Hayekian triangles: <https://wiki.mises.org/wiki/Hayekian_triangle>

@ 3bf0c63f:aefa459d

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.

@ 3bf0c63f:aefa459d

# A memória humana e as databases A comparação entre uma database e a memória humana é trivial, todo mundo pensa. Os exemplos das letras de música e dos rostos humanos citados [neste trabalhinho acadêmico boboca][1] fazem muito sentido: de fato a analogia entre index keys e trechos de música ou rostos humanos parece explicar fenômenos que experimentamos. O que me parece loucura é a simplificação, o reducionismo, que povoa a mente dos [responsáveis por essas analogias][2]. O fato de que uma database tem uma lista de _keys_ enquanto a memória humana tem um mecanismo de busca vago, _context-sensitive_, que opera com dicas soltas e ora funciona ora não funciona -- não é argumento para afirmar que o computador é melhor do que a memória humana. Claro, todos esses cientistas vão dizer que a memória humana tem uma eficiência enorme, porque ela armazena muito mais dados do que os computadores blablablá, mas em tese ela pode ser reimplementada usando os algoritmos de databases que nós já usamos. A imagem simplificada da memória humana que se faz é a seguinte: quando vimos uma coisa qualquer, um menino pulando um muro, ela nos lembra de outras coisas relacionadas, uma certa vez em que nós mesmos pulamos um muro, o muro que estamos pensando em construir, umas brincadeiras parecidas com pular muro, os motivos que já levaram outras pessoas a pular muro, um filme que tinha cenas de meninos travessos, a muralha da China, uma imagem de assaltante que não está pulando nenhum muro, uma casa da mesma cor do muro. Simples: nosso cérebro pega os dados dos sentidos e com eles faz uma busca na memória. A questão toda é: quais "dados dos sentidos"? Como é que o coitado do cérebro sabe que é pra procurar um muro, e não uma parede qualquer, ou os tijolos separados, ou o cimento, o barro de onde são feitos os tijolos? Isto sem contar a distinção, que é outro problema, que fazemos entre a mancha colorida a que chamamos muro e a outra mancha colorida a que chamamos menino, dentre infinitas outras, porque isto é outro problema. Mas a escolha dos dados que vão ser usados na busca que será feita na memória é crucial para o sucesso da operação, e nenhum computador saberia escolher. Alguém vai argumentar que um mecanismo de _computer vision_ poderia identificar um menino e um muro na cena e encontrar no banco de dados várias coisas relacionadas a meninos e várias coisas relacionadas a muros, mas temos que concordar que não é nada nem próximo disto que a mente humana faz. O assaltante, por exemplo, só seria encontrado se, no ato de indexá-lo, já colocássemos lá "atravessar obstáculos" e, putz, como tirar esta mesma frase de uma imagem de um menino perto de um muro? Mesmo que a _computer vision_ seja ótima e consiga, como decidir entre a query "atravessar obstáculos" e "correr risco físico", "desafiar-se a si mesmo", "chegar mais alto", "invadir propriedade privada", "brincar", "tentar impressionar as meninas", "lutar para ser aceito entre seus pares", "mostrar que sabe", "chegar primeiro" e infinitos outros sentimentos, motivações, expectativas e processos que podem estar em curso naquela subida de muro? Não é nada disso que a mente humana faz, eu dizia, porque a _computer vision_ pode identificar o muro e o menino e o ato do menino de subir o muro, mas e quando a atenção humana foca no material que constitui o muro, a cor do muro ou a planta que está nascendo no meio do muro? Ou no reboque malfeito do muro, a casa que imagina haver atrás do muro? Cada foco destes, cuja causa também não vem ao caso aqui, deveria produzir _queries_ bem diferentes. Há vários outros pontos que poderiam ser levantados aqui contra o reducionismo e a simplificação da analogia entre a memória humana e uma database simples, e o erro que é igualá-las, mas me perdi, e acho que se você entendeu os pontos que levantei acima saberá encontrar vários outros exemplos nos quais o funcionamento da memória humana ultrapassa em complexidade qualquer algoritmo infinitamente -- e uso aqui "infinitamente" em sentido estritamente literal. [1]: <http://www.iosrjournals.org/iosr-jce/papers/Vol15-issue2/G01525053.pdf?id=8449> [2]: <https://www.edge.org/response-detail/11799>

@ 3bf0c63f:aefa459d

# Bitcoin is not inherently volatile ## A response to https://gist.github.com/fernandonm/81cb21bdce0910055de32b98ee4119e1 This piece from Fernando Nieto claims that _any asset that is expected to constantly appreciate in value_ -- as Bitcoin is expected to, as its supply is strictly fixed, the other option is for Bitcoin to die, but we're not considering that hypothesis -- _will **necessarily** be very volatile_. It is not clear what "volatile" means, but we'll assume it means the market value of this asset will vary against the market value of all the other things strongly and annoyingly enough to make it useless as a unit of account. We can't just consider "the price of Bitcoin against the Dollar", it must be against "everything", otherwise we could just assume the volatily was happening on the Dollar side, not on the Bitcoin side. > The value of an asset can only grow due to _uncertain future returns_ becoming increasingly certain as time passes. Any future value expectation is priced in from the very moment it becomes certain. Hence, the same uncertainty inherent to investiments expected to provide a return -- e.g. an increase in the value of each bitcoin -- makes them _inherently volatile_. This is the claim, and also considered an explanation as it says "the article could end here", but the explanation is missing one piece, which is given many paragraphs below: > Even if sometimes you may appreciate a return exceeding the cost of volatily risk, returns are always offset at the margin by the costs of holding the asset. If any asset offered a risk adjusted return opportunity clearly more attractive than the rest, that would be immediately arbitraged away (...) The essence of the argument is that _there cannot be_ an asset that increases in value without risk, otherwise that value increase would be arbitraged away. In other words, if Bitcoin is to increase in value constantly and predictably accross the years, then its price should be arbitraged away in a manner ~~~ (This was never finished and I don't remember what I was going to say.)

@ 3bf0c63f:aefa459d

# idea: An open log-based HTTP database for any use case A single, read/write open database for everything in the world. * A hosted database that accepts anything you put on it and stores it in order. * Anyone can update it by adding new stuff. * To make sense of the data you can read only the records that interest you, in order, and reconstruct a local state. * Each updater pays a fee (anonymously, in satoshis) to store their piece of data. * It's a single store for everything in the world. ### Cost and price estimates Prices for guaranteed storage for 3 years: 20 satoshis = 1KB 20 000 000 = 1GB <https://www.elephantsql.com/> charges $10/mo for 1GB of data, 3 600 000 satoshis for 3 years If 3 years is not enough, people can move their stuff to elsewhere when it's time, or pay to keep specific log entries for more time. ### Other considerations * People provide a unique id when adding a log so entries can be prefix-matched by it, like `myapp.something.random` * When fetching, instead of just fetching raw data, add (paid?) option to fetch and apply a `jq` map-reduce transformation to the matched entries

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

## O custo-Ricardinho Sei que o Atlético tem vários problemas. Sei que várias reclamações que vários atleticanos diferentes fazem têm fundamento e que os vários problemas do Atlético se misturam e fazem o time jogar mal, absurdamente mal, como jogou hoje contra o Internacional. Mas vou me dar o direito de ignorar todas os diversos tipos de falhas e problemas do Atlético e atribuir tudo de mau que nos aconteceu recentemente a um único elemento: Ricardinho. Breve história do campeonato atleticano O campeonato começou com o Atlético jogando bonito e vencendo com facilidade os inimigos, com um time leve, que passava a bola rápido, jogava no contra-ataque, um ataque rápido, toques rápidos ou enfiadas de bola dos volantes faziam com que Tardelli e Éder saíssem na cara do gol a todo instante e tudo era felicidade. Mas aí vieram os problemas, aos poucos: o time não conseguia utilizar toda a sua rapidez contra adversários muito fechados. Dessa maneira veio o empate contra o Santo André, o empate com o Botafogo, o empate contra o Vitória, uma vitória suada contra o Fluminense (que jogou fechado no Mineirão), a derrota catastrófica para um Goiás que nem encostou na bola direito. E a derrota para o Flamengo no Maracanã. Nessas, inventaram que o Atlético ia mal contra times fechados porque não sabia tocar a bola, tocar a bola de lado, "procurando um espaço", faltava ao Atlético, diziam, uma figura centralizadora, que parasse o jogo, parasse a correria, distribuisse com inteligência a bola, para que o Atlético furasse a defesa adversária com inteligência e paciência, e não com correria como vivia tentando. Inventaram isso, e começaram a acreditar - acho que todas as pessoas começaram a acreditar, inclusive o Celso Roth e eu mesmo. E onde estava a solução: no camisa 10. ### A paciência ricardiana Jamais apreciei a idéia fixa que havia (e talvez, infelizmente, ainda haja) na cabeça da maioria dos torcedores do Atlético, de que um time só é bom quando tem um "camisa 10", cujas características são conhecidas por todos: tem o poder mágico de arrumar o meio-de-campo, dar criatividade ao time, lançar a bola e passá-la com plasticidade e leveza e resolver todos os problemas; mas cujos exemplos no futebol brasileiro e mundial são muito escassos. Essa fixação, creio eu, não é um fenômeno natural: é conseqüência direta do imbróglio Ziza-Gallardo do ano do centenário. Foi lá que inventaram esse negócio de camisa 10 e aí ficou nessa até recentemente (ou até agora). O próprio presidente do Atlético, Alexandre Kalil, disse em entrevista concedida antes de contratar Ricardinho que o único exemplo que era apontado quando se perguntava sobre quem poderia ser o tal camisa 10 que a torcida tanto queria era Ricardinho. Ricardinho, Ricardinho, Ricardinho. O nome se confunde com o número da camisa. Ricardinho, essa entidade mística, pirilâmpica e luminosa que transforma times rápidos e burros em times inteligentes. E trouxeram o tal camisa 10. O único exemplar vivo e o único que a torcida aceitaria: Ricardinho. E ele foi saudado exatamente como a solução para o problema da correria. Ricardinho era a expressão da "paciência". ### Segue a história Se esqueceram, porém, que a inteligência de Ricardinho não era gratuita. Ela nos era dada em troca da velocidade, da leveza do time, dos passes rápidos, das enfiadas de bola, da correria que confundia o adversário, das jogadas que surgiam sem que os próprios jogadores soubessem como. As jogadas do Atlético pararam de surgir naturalmente. Agora teriam que partir todas elas da cabeça da mente pensante centralizada: Ricardinho. Mas isso era secundário. Agora o problema principal estava resolvido: havia o camisa 10 e poderíamos "passar a bola" e "encontrar um espaço". As vitórias vieram de novo. Contra Barueri e Santos, que foram times abertos, o Atlético jogou sem seu camisa 10 e foi muito bem. Contra São Paulo, jogou na retranca, e aí funcionou a paciência ricardiana. E contra Vitória o Atlético passou a bola, passou a bola, passou a bola o jogo inteiro e conseguiu fazer um mísero gol, contra um time atestadamente ruim, e justamente numa jogada de velocidade louca e não-pensada que não contou com a participação de Ricardinho. E aí Ricardinho passou a ser o centro do time. E simultaneamente a coisa desandou. Fluminense, Flamengo, Coritiba e Internacional. Ricardinho, por melhor jogador que seja (perceba: eu jamais diria que se trata de um mal jogador, pelo contrário), não consegue, sozinho, pensar em tudo, arrumar espaços onde não se pode arrumar, com o time todo lento e parado. O time joga em função dele, e por isso está parado, sempre parado, morto. E não há espaço que apareça. É por isso que perdemos jogos em que dominamos completamente a bola: dominamo-la, mas não há mais o que fazer com a bola, porque as jogadas loucas da correria não saíam mais, porque não havia correria, porque tudo o que se deve fazer quando se tem um camisa 10 no time é tocar para o camisa 10. E passar a bola. Passar a bola, passar a bola. ### Os times fechados A coisa desandou com Ricardinho, é certo, porque o Atlético não consegue vencer times fechados. Os que discordarem de meu ponto vão lembrar que o time sem Ricardinho - que era outro time, era a correria e tal - também não conseguia vencer adversários fechados. É verdade. Mas deve-se levar em conta não só o resultado final, mas as chances, porque futebol não é exato, mas também não é aleatório, é probabilístico: em um duelo entre dois times, um bom e um ruim, não se pode afirmar que o bom vai vencer, mas se pode ter quase certeza de que, em se jogando 10 vezes, o time melhor vencerá mais de 5 partidas, só pra dar um exemplo. Então a pergunta é: o time antigo do Atlético, aquele que perdeu para aquele Goiás retrancado até a alma no Mineirão, era ou não era melhor do que o atual, que perdeu, pelo mesmo placar para o incrivelmente retrancado Internacional no Mineirão? E a resposta é: Era. O time antigo, o time da correria e da burrice, o time sem camisa-10-pensante, era melhor. Eu sei disso, você sabe disso, toda a torcida sabe disso. Naquela ocasião [<http://www.youtube.com/watch?v=SvY9G3975MA]> a torcida não vaiou o time como o fez contra o Internacional, e isso é a indicação de que a torcida preferia aquele time, e de que aquele era um time melhor do que o atual e também melhor do que o Goiás, mesmo tendo perdido - o que não se pode dizer do time atual em relação ao Internacional. O total de chances criadas naquele jogo por aquele time, criadas quase que sem se saber por que, tudo no meio da correria, é a prova de que o time antigo era melhor. É a prova de que um time orientado para tocar a bola para o camisa 10 não funciona. ### Soluções possíveis Sei que não há mais tempo de salvar o ano, mas como mesmo que houvesse tempo de nada adiantaria eu escrever aqui qualquer sugestão, vou escrever mesmo assim e quem sabe fica aí pro próximo ano, ou quem sabe fica aí só pra eu e mais meia dúzia lermos e fim. É certo que o Atlético não pode continuar jogando assim como está. A velocidade tem que voltar. Tem que voltar a correria e a loucura (não que Ricardinho deva ser mandado embora, apesar de eu achar essa uma boa idéia, mas ele precisa ser reposicionado no time). Então como fica o problema do furo da retranca adversária? Perguntando a quem sabe mais de futebol do que eu, arranjei duas soluções possíveis: (a) chutar de fora da área: ora, o Atlético tem vários pretensos chutadores de longa distância: o próprio Ricardinho, Evandro, Corrêa, Tardelli, Éder e até o Jonílson. Mas não chuta. Não entendo o porquê disso. Até vinha chutando em algumas partidas aí, mas parou, e a parada coincide mais ou menos com as partidas de nosso maior desgosto (essas últimas aí). O Flamengo só faz gol chutando de fora da área ou em jogada individual, não tem uma jogada coletiva (ou pelo menos não teve nos jogos que eu vi: contra Barueri, Atlético e Náutico). (b) correr no fundo e cruzar pro meio da pequena área: essa é a melhor jogada do futebol, funciona quase sempre, é muito melhor do que os cruzamentos normais que se vê pedir pelas arquibancadas do Mineirão, é bela de se ver e, creio, fácil de se fazer. Mas é fácil só pra quem está acostumado a ela. Em várias oportunidades hoje mesmo contra o Internacional nossos jogadores poderiam tê-la feito, Corrêa, Márcio Araújo e Éder Luís poderiam tê-la feito, mas não sabem, sei lá, não querem fazer. O único jogador que faz esse tipo de jogada atualmente, mesmo assim só de vez em quando, é o Thiago Feltri (lembre-se dos dois pênaltis que ele sofreu recentemente), mas todo mundo vaia o sujeito. Há, porém, um jogador que já passou pelo Atlético e que sabia fazer esse tipo de jogada com maestria. Não que ele seja a solução de tudo, mas acho que seria uma excelente peça no elenco: Danilinho. O problema de Danilinho é a estigma que pesa sobre ele, a de torcedores preconceituosos que o incluem entre um agrupamento místico e inerentemente ruim chamado "geração Série B", uma grande bobagem que inventaram aí. Acabou-se o que eu tinha pra dizer.

@ 3bf0c63f:aefa459d

# Doing automatic payouts to users on the Lightning Network No service wants to keep users balances forever or "become a custodian", as that may have some complications dependending on who is doing it. But the sad truth is that there is no way to do automatic payouts to users on the Lightning Network. So if you're running a marketplace or a game of some kind that takes sats from some users, does something, then sends sats out to other users, you must keep a table with balances for each user. -- But I can ask for a Lightning Address! No, you can't, because mobile users of noncustodial wallets do not have those things generally, and that's not the purpose of Lightning Addresses anyway. Well, of course you _can_, but what I'm trying to say is that you shouldn't, as that is an anti-practice that will cause people to not want to use your service or force them into custodial providers -- which may be ok for them, but may not be. -- So if I ignore the concerns above I can do this with Lightning Addresses, right? Not really, because payments can fail. The user might input an invalid Lightning Address, or the Lightning Address may stop working after a while. Or even if it is working and online your payout can still fail for many reason inherent to Lightning. That means you need to keep a table of balances for your users anyway. It doesn't matter. Since you are already keeping a table of balances, now it's your chance to bring back the mobile noncustodial wallet users into a greater standard that accomodates everybody: [LUD-14](https://github.com/fiatjaf/lnurl-rfc/blob/luds/14.md). Wallets [can implement LUD-14 support](https://twitter.com/hampus_s/status/1433103395632582656) and then be made to withdraw balances from your service automatically every time they're turned on or periodically or upon manual request from the user. That limits the amount of user balance you'll have to keep on your service (but you can also add more rules around that, for example, automatically confiscating balances that stay parked too long, or putting a hard limit on the balance size for each user). -- But with Lightning Addresses I can do _instant_ payouts! Yes, you can, but that's why [LUD-15](https://github.com/fiatjaf/lnurl-rfc/blob/luds/15.md) exists: for all custodial providers, noncustodial wallets that rely on some kind of friendly server or coordinator (like Breez, Blixt or Phoenix) or even noncustodial providers running some kind of homemade server, you can dispatch these requests that cause them to withdraw the money automatically, which makes the experience similar to instant payouts -- and better, since then the payment requests can be more meaningful and say they are withdrawals from your service instead of saying that you're donating money to them (which is what most Lightning Address payments really mean).

@ 3bf0c63f:aefa459d

# sitios.xyz Based on [sitio](nostr:naddr1qqyrjctyxg6nvepnqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ccsaa3c), this was supposed to be the successor of [Websites For Trello](nostr:naddr1qqyrydpkvverwvehqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c9d4yku). From the old landing page: > sítios.xyz is a hosted static site generator based on sitio. It is capable of building websites by fetching content from other services and arranging them in pages. It can be used to build any sort of blog or site. > > It supports fetching content from Trello, Dropbox, Evernote and arbitrary URLs. You can use just one of these providers, or mix them all in your site. > > How it works > > Basically, you just have to point to an URL of the site, like /posts, for example, and assign a provider to it. The trello:list provider, for example, will fetch all cards on a Trello list and create a page for each of them under /posts/:card-name and finish with an index, optionally paginated, on /posts itself. > > You can repeat this process for other content from other sources, or even just point the root URL, / to some provider and be done with it. > > Fast > > The generated websites are super fast, as they're served as HTML files directly, no server-rendering involved. Also, due to sitio capabilities, they have instant navigation enabled by default, which uses JavaScript to fetch just the content of the pages, instead of performing a full reload. > > Customization > > Since the way pages are rendered -- their HTML structure -- is standardized by classless, custom theming and styling is simple to do using just CSS and JavaScript, and there are some themes available already for you to choose. > > If you want custom HTML or a provider for which we don't have support yet, that's easy to add. Please let's us know using the chat below! > No lock-in > > The code that renders the sites is just a very minimal sitio script with the plugins you choose. These are all open-source and you can export your site and render it by yourself if you don't want to use sítios.xyz anymore. - <http://web.archive.org/web/20180416143134/https://sitios.xyz/> - <https://github.com/fiatjaf/sitios.xyz>

@ 3bf0c63f:aefa459d

# As estrelas As estrelas são buracos nas esferas celestiais, buracos através dos quais nos é permitido ver a brilhante luz dos céus. (_Rome_, a série.)

@ 3bf0c63f:aefa459d

# Bolo It seems that from 1987 to around 2000 there was a big community of people who played this game called ["Bolo"][wikipedia]. It was a game in which people controlled a tank and killed others while trying to capture bases in team matches. Always 2 teams, from 2 to 16 total players, games could last from 10 minutes to 12 hours. I'm still trying to understand all this. The game looks silly from some [videos][videos] you can find today, but apparently it was very deep in strategy because people developed [strategy][strategy-guide] [guides][pillbox-guide] and [wrote][letter-1] [extensively][letter-2] about it and [Netscape even supported `bolo:` URLs][clickable-links] out of the box. > The two most important elements on the map are pillboxes and bases. Pillboxes are originally neutral, meaning that they shoot at every tank that happens to get in its range. They shoot fast and with deadly accuracy. You can shoot the pillbox with your tank, and you can see how damaged it is by looking at it. Once the pillbox is subdued, you may run over it, which will pick it up. You may place the pillbox where you want to put it (where it is clear), if you've enough trees to build it back up. > Trees are harvested by sending your man outside your tank to forest the trees. Your man (also called a builder) can also lay mines, build roads, and build walls. Once you have placed a pillbox, it will not shoot at you, but only your enemies. Therefore, pillboxes are often used to protect your bases. That quote was taken from this ["augmented FAQ"][augmented-faq] written by some user. Apparently there were many FAQs for this game. A FAQ is after all just a simple, clear and direct to the point way of writing about anything, previously known as [summa][summa][^summa-k], it doesn't have to be related to any actually frequently asked question. More unexpected Bolo writings include [an etiquette guide][etiquette], an [anthropology study][anthropology] and [some wonderings on the reverse pill war tactic][reverse-pill]. [videos]: https://www.youtube.com/results?search_query=winbolo [wikipedia]: https://en.wikipedia.org/wiki/Bolo_(1987_video_game) [clickable-links]: http://web.archive.org/web/19980214020327/http://boloweb.stanford.edu/BoloWeb.html [faq]: https://web.archive.org/web/20070518233700/http://bishop.mc.duke.edu/bolo/guides/stuartfaq.html [letter-1]: http://web.archive.org/web/19961214060949/http://rost.abo.fi/~gpappas/Bolo/News/mikael-bl.html [letter-2]: http://web.archive.org/web/19961214060959/http://rost.abo.fi/~gpappas/Bolo/News/mikael-kev.html [strategy-guide]: http://web.archive.org/web/19961214052754/http://rost.abo.fi/~gpappas/Bolo/guide.html [etiquette]: http://web.archive.org/web/19961214052805/http://rost.abo.fi/~gpappas/Bolo/etiquette.html [pillbox-guide]: http://web.archive.org/web/19961214052818/http://rost.abo.fi/~gpappas/Bolo/PBguide/pbguide1.html [anthropology]: http://web.archive.org/web/19961214052830/http://rost.abo.fi/~gpappas/Bolo/anthropology.html [reverse-pill]: http://web.archive.org/web/19990428023004/http://powered.cs.yale.edu:8000/%7Ebayliss/bolo.html [augmented-faq]: http://web.archive.org/web/19970118071637/http://rost.abo.fi/~gpappas/Bolo/faq.html [summa]: https://en.wikipedia.org/wiki/Summa [^summa-k]: It's not the same thing, but I couldn't help but notice the similarity.

@ 3bf0c63f:aefa459d

# Mises' interest rate theory Inspired by [Bob Murphy's thesis](http://consultingbyrpm.com/uploads/Dissertation.pdf) against the "pure time preference theory" (see also this [series of podcasts](https://www.bobmurphyshow.com/episodes/ep-31-capital-and-interest-in-the-austrian-tradition-part-3-of-3/)) -- or blatantly copying it -- here are some thoughts on Mises' most wrong take: * Mises asserts that the market rate of interest is _not_ the originary rate of interest, because the market rate involves entrepreneurial decisions, risk, uncertainty etc. No one lends money with 100% guarantee that it will be paid back in the market and so. But if that is true, where can we see that originary interest? We're supposed to account for its existence and be sure that it is logically there in every trade between present and future, because it's a _category of action_. But then it seems odd to me that it has anything to do with the actual interest. * Mises criticizes the notion of "profit" from classical economists because it mashed together gains deriving from speculation, risk, other stuff and originary interest -- but that's only because he assumes originary interest as a given (because it's a category of action and so on). If he didn't he could have just not cited originary interest in the list of things that give rise to "profit" and all would be fine. * Mixing the two points above, it seems very odd to think that we should look for interest as a component of profit. It seems indeed to be very classifical-economist take. It would be still compatible with Mises'sworldview -- indeed more compatible -- that we looked for profit as a component of interest: when someone lends some 100 and is paid 110 that is profit. Plain simple. Why he did that and why the other person paid isn't for the economist to analyse, or to dissect the extra 10 into 9 interest, 1 risk remuneration or anything like that. If the borrower hadn't paid it would be a 100 loss or a 109 loss? * In other moments, Mises talks about the originary rate of interest being the same for all things: apples and bicycles and anything else. But wasn't each person supposed to have its own valuation of each good -- including goods in the present and in the future? Is Mises going to say that it's impossible for someone to value an orange in the future more than a bycicle in the future in comparison with these same goods in the present? (The very "more" in the previous sentence shows us that Mises was incurring in cardinal value calculations when coming up with this theory -- and I hadn't noticed it until after I finished typing the phrase.) In other words: what if someone prefers orange, bycicle, bycicle in the future, orange in the future? That doesn't seem to fit. What is the rate of interest? * Also, on the point above, what if someone has different rates of interest for goods in different timeframes? For example, someone may prefer a bycicle now a little more than a bycicle tomorrow, but very very much more than a bycicle in two days. That also breaks the notion of "originary interest" as an universal rate. * Now maybe I misunderstood everything, maybe Mises was talking about originary interest as a rate defined by the market. And he clearly says that. That if the rate of interest is bigger on some market entrepreneurs will invest capital in that one until it equalizes with rates in other markets. But all that fits better with the plain notion of profit than with this poorly-crafted notion of originary interest. If you're up to defining and (Mises forbid?) measuring the neutral rate of interest you'll have to arbitrarily choose some businesses to be part of the "market" while excluding others. * By the way, wasn't originary interest a category of action? How can a category of action be defined and ultimately _fixed_ by entrepreneurial action in a market?

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# Memórias de quando eu aprendi a ler A professora ensinou um método segundo o qual para ler uma sílaba, por exemplo, _to_, dizíamos rápido o nome das duas letras, cada vez mais rápido, _tê ó tê ó t-ó tó_, até acharmos o som correto da sílaba. Até hoje não sei se esse é o "método fônico". Não me lembro jamais de ter que decorar uma tabela de pares de letras e sons resultantes ("b com a, bá; bê com é, bé" etc.). Outra memória que eu tenho é de que essa técnica de falar as letras rápido foi fundamental para eu ter certeza de que sabia ler e estava lendo, mas de alguma eu já sabia ler antes de aprender a técnica, porque eu era capaz de, por exemplo, saber antes de qualquer coisa que _ca_ era uma exceção à regra. Mesmo assim eu me lembro de passar muitas horas repetindo letras e confirmando que a técnica funcionava.

@ 3bf0c63f:aefa459d

# piln Piln was a prepaid IPFS pinning service you could use anonymously and instantaneously with the Bitcoin payments over the Lightning Network. Similar to <https://eternum.io/>, but anonymous, loginless and very very cheap. The cheapness wouldn't scale because it needed a local HD to store data, couldn't work with services like S3 because IPFS is very bad ([I actually tried to make it work](https://github.com/fiatjaf/go-ds-s3)). Discontinued because IPFS is terrible. - <https://piln.xyz/> - <https://github.com/fiatjaf/piln> ## See also - [How IPFS is broken](nostr:naddr1qqyxgdfsxvck2dtzqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c8y87ll)

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# my personal approach on using `let`, `const` and `var` in javascript Since these names can be used interchangeably almost everywhere and there are a lot of people asking and searching on the internet on how to use them (myself included until some weeks ago), I developed a personal approach that uses the declarations mostly as readability and code-sense sugar, for helping my mind, instead of expecting them to add physical value to the programs. --- `let` is only for short-lived variables, defined at a single line and not changed after. Generally those variables which are there only to decrease the amount of typing. For example: for (let key in something) { /* we could use `something[key]` for this entire block, but it would be too much letters and not good for the fingers or the eyes, so we use a radically temporary variable */ let value = something[key] ... } `const` for all _names_ known to be constant across the entire module. Not including locally constant values. The `value` in the example above, for example, is constant in its scope and could be declared with `const`, but since there are many iterations and for each one there's a value with same **name**, "value", that could trick the reader into thinking `value` is always the same. Modules and functions are the best example of `const` variables: const PouchDB = require('pouchdb') const instantiateDB = function () {} const codes = { 23: 'atc', 43: 'qwx', 77: 'oxi' } `var` for everything that may or not be variable. Names that may confuse people reading the code, even if they are constant locally, and are not suitable for `let` (i.e., they are not completed in a simple direct declaration) apply for being declared with `var`. For example: var output = '\n' lines.forEach(line => { output += ' ' output += line.trim() output += '\n' }) output += '\n---' for (let parent in parents) { var definitions = {} definitions.name = getName(parent) definitions.config = {} definitions.parent = parent }

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# lnchannels A browser for public Lightning Network channels that updates daily, shows some unexpected charts and tries to use some chain analysis and other heuristics to determine who opened the channels, who closed, what was the state of the closure, what node software each entity is using and other things. It consists of a Python script that fetches and does things with data before saving it to a Postgres database, a [Postgrest](https://postgrest.org/en/v7.0.0/) server and a static site that gets data from Postgrest. - <https://raw.githubusercontent.com/fiatjaf/lnchannels/master/lnchannels-home.png> - <https://github.com/fiatjaf/lnchannels> - <https://ln.bigsun.xyz/>

@ 3bf0c63f:aefa459d

# The P2SH Wars [This article on the history of P2SH implementation on Bitcoin][battle-for-p2sh] has two valuable lessons and illustrates the benefits of [`bitcoind` decentralization](nostr:naddr1qqyxzcfevscxzvnrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823chus9ym): 1. The benefits of multiple codebases: Russell O’Connor found the bug in `OP_EVAL` while working on it in his alternative Bitcoin software implementation. 2. The dangers of a single master repository with a restricted set of owners: Gavin Andresen committed code for a broken `OP_EVAL` first, then pushed an evil miner activation signaling mechanism that defaulted to his personal preferred P2SH version (to signal the opposite miners would have to edit the code and recompile) and won the battle against a much [better and saner][lukes-tweet] approach (Luke Jr's [`OP_CHECKHASHVERIFY`][bip-17]) by the sole power of inertia: things were already merged and working [so no one bothered to fight][p2sh-votes] for what seemed to be a minor and maybe irrelevant improvement but that later was proven to be substantially better. The second lesson can actually be split in 4 different lessons: a. Maintainer committing a bug and no one noticing it; b. Maintainer committing evil signaling mechanism; c. Everybody going along with everything because it's hard to take a public stand about a central thing everybody loves and the _status quo_ bias exists and is strong; d. Things that look good now may look bad later and vice-versa, no amount of expert "eyes on code" can fix that. [battle-for-p2sh]: https://bitcoinmagazine.com/articles/the-battle-for-p2sh-the-untold-story-of-the-first-bitcoin-war [bip-17]: https://github.com/bitcoin/bips/blob/master/bip-0017.mediawiki [lukes-tweet]: https://twitter.com/LukeDashjr/status/1138196760290111488 [p2sh-votes]: https://en.bitcoin.it/wiki/P2SH_Votes

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# idea: Graph subjective reputation as a service The idea more-or-less coded in <https://github.com/fiatjaf/multi-service-reputation-rfc>, but if it is as good as I think it is, it could be sold for websites without any need for information sharing and without it being an open protocol. It could be used by websites just to show subjective reputations inside their own site (as that isn't so trivial to build, but it is still desirable).

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# Etleneum A programmable escrow for satoshis with self-contained stateful micro-apps defined with Lua anyone can create and call to deposit money while simultaneously changing their state. Also known as "the centralized smart contract platform", in opposition to the supposedly "decentralized" Ethereum platform. The "smart contracting" features of Etleneum are very similar to the ones on Ethereum. - <https://etleneum.com/> - <https://www.coindesk.com/why-this-dev-built-a-centralized-ethereum-on-top-of-bitcoins-lightning-network>

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# Google, Uber e ostracismo Pensando sobre como o Google poderia implementar uma solução "pure software" para o problema dos programinhas de carona paga -- já que agora parece que o Waze vai virar tipo um Uber -- me vi pensando em que poderia haver punições bastante severas e para-legais para infratores dos regulamentos internos do serviço. Digamos, por exemplo, que é proibido pelas regras do serviço que o motorista ou o passageiro agridam um ao outro de qualquer maneira. Para ser qualificado como um potencial usuário, tanto o motorista quanto o passageiro devem ser usuários de longa data dos serviços do Google, possuir um email no Gmail com trocentas mensagens sendo recebidas e enviadas todos os dias, um enorme arquivo, coisas guardadas no Google Drive e/ou outros serviços do Google sendo usados. Caso o sujeito agrida o motorista, roube-o ou faça qualquer outra coisa não-permitida, o Google pode, imediatamente, cancelar seu acesso a todos os serviços. Depois, com mais calma, pode-se tentar alguma coisa por meio da justiça estatal, mas essa punição seria tão imediata e tão incondicional (bom, poderia haver um julgamento interno dentro do Google para avaliar o que aconteceu mesmo, mas pronto, nada de milanos na justiça penal e depois uma punição fajuta qualquer.) Esse tipo de punição imediata já desencorajaria a maioria dos infratores, imagino eu. É a própria idéia anarquista da punição por ostracismo. O cara fica excluído da sociedade até que a sociedade (neste caso, o Google) decida perdoá-lo por qualquer motivo. A partir daí é possível imaginar que os outros vários "silos" deste mundo -- Facebook, Vivo, Diamond Mall, SuperNosso -- possam também aderir, caso concordem com o julgamento do Google, e vice-versa, e também impedirem o infrator de usar os seus serviços. Mas o grande tchans disto aqui é que esse processo pode começar com um único agente, desde que ele seja grande o suficiente para que a sua ostracização, sozinha, já seja uma punição quase suficiente para o infrator.

@ 3bf0c63f:aefa459d

# Obra aqui do lado Tem quase um ano que estão fazendo uma obra aqui do lado e eu não ganhei nenhuma indenização. Numa sociedade sem Estado isso jamais teria acontecido.

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# Gold is not useless If there's something all common people believe about gold is that it is useless[^1]. Austrian economists and libertarians in general that argue against central banks or defend a primitive gold standard are often charged with that accusation: that gold is useless, it has no use in the industry, it serves no purpose besides ornamental, so it is a silly commodity, a luxurious one, and that it would be almost immoral to have such a thing in a so central position in an economy such as the position of money. I've seen libertarians in general argue such things as: "it is used in some dental operations", which means people make dental prosthesis of gold, something that fits in same category of jewelry, I would say. There's also the argument of electronic connectors. That's something that appears to be true, but wouldn't suffice the anti-gold arguments. The fact remains that, besides its uses as money -- because gold is still considered to be a form money even now that it doesn't have that position formally in any country (otherwise it wouldn't be considered as an "investment" or "value store" everywhere) -- gold is used mainly for ornamental purposes[^2]. All that is a hassle for libertarians in general. Even the Mises Regression Theory wouldn't solve that problem of people skeptical of gold due to its immoral nature. That problem is solved once you read what is written in the chapter 17 from Richard Cantillon's _Essay on Economic Theory[^3]_ (page 103): > Gold and silver are capable of serving not only the same purpose as tin and copper, but also most of the purposes of lead and iron. They have this further advantage over other metals in that they are not consumed by fire and are so durable that they may be considered permanent. It is not surprising, therefore, that the men who found the other metals useful, valued gold and silver even before they were used in exchange. So gold is indeed useful. Everybody should already know that. You can even do forks and spoons with gold. You can do furniture with gold, and many other useful stuff. As soon as you grasp this, gold is useful again. It is an useful commodity. Answering the next question becomes easy: why isn't anyone making gold forks anywhere? The questioner already knows the answer: because it is too expensive for that. And now the Regression Theory comes with its full force: why is it expensive? Because it has gained a lot of value in the process of becoming money. The value of gold as money is much greater than as a metal used in fork production. --- [^1]: see <http://www.salon.com/2014/02/02/ignore_sean_hannity_gold_is_useless_partner/> or all answers on <https://www.quora.com/Why-is-gold-considered-so-precious-and-why-does-it-have-such-high-prices>. [^2]: this <https://en.wikipedia.org/wiki/Gold#Modern_applications> section on the Wikipedia page for gold is revealing. [^3]: <https://mises.org/library/essay-economic-theory-0>

@ 3bf0c63f:aefa459d

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