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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# 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

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

# The flaw of "just use paypal/coinbase" arguments For the millionth time I read somewhere that "custodial bitcoin is not bitcoin" and that "if you're going to use custodial, better use Paypal". No, actually it was "better use Coinbase", but I had heard the "PayPal" version in the past. There are many reasons why using PayPal is not the same as using a custodial Bitcoin service or wallet that are obvious and not relevant here, such as the fact that you can't have Bitcoin balances on Bitcoin (or maybe now you can? but you can't send it around); plus all the reasons that are also valid for Coinbase such as you having to give all your data and selfies of yourself and your government documents and so on -- but let's ignore these reasons for now. The most important reason why it isn't the same thing is that when you're using Coinbase you are stuck in Coinbase. Your Coinbase coins cannot be used to pay anyone that isn't in Coinbase. So Coinbase-style custodianship doesn't help Bitcoin. If you want to move out of Coinbase you have to withdraw from Coinbase. Custodianship on Lightning is of a very different nature. You can pay people from other custodial platforms and people that are hosting their own Lightning nodes and so on. That kind of custodianship doesn't do any harm to anyone, doesn't fracture the network, doesn't reduce the network effect of Lightning, in fact it increases it.

# A entrevista da Flávia Tavares com o Olavo de Carvalho Não li todas as reclamações que o Olavo fez, mas li algumas. Também não li toda a matéria que saiu na Época, porque não tive paciência, mas assisti aos dois vídeos da entrevista que o Olavo publicou. Tendo lido primeiro as muitas reclamações do Olavo, esperei encontrar no vídeo uma pessoa falsa, que fingiu-se de amigável para obter informações que usaria depois para destruir a imagem do Olavo, mas não vi nada disso. Claro que ela poderia ter me enganado também, se enganou ao Olavo. Mas na matéria em si, também não vi nada além de sinceridade -- talvez não excelência jornalística, mas nada que eu não esperasse de qualquer matéria de qualquer revista. Flavia Tavares não entendeu muitas coisas, mas não fingiu que não entendeu nada, foi simples e honestamente Flavia Tavares, como ela mesma declarou no final do vídeo da entrevista: "olha, eu não fingi nada aqui, viu?". --- O mais importante de tudo isso, porém, são as partes da matéria que apresentam idéias difíceis de conceber, como as que Olavo tem sobre o governo mundial ou a disseminação da pedofilia. Em toda discussão pública ou privada, essas idéias são proibidas. Muita gente pode concordar que a esquerda não presta, mas ninguém em sã consciência admitirá a possibilidade de que haja qualquer intenção significativa de implantação de um governo mundial ou da disseminação da pedofilia. A mesma carinha de deboche que seu amigo esquerdista faria à simples menção desses assuntos é a que Flavia Tavares usa no seu texto quando quer mostrar que Olavo é meio tantã. A carinha de deboche vem desacompanhada de qualquer reflexão séria ou tentativa de refutação, sempre. --- Link da tal matéria: <http://epoca.globo.com/sociedade/noticia/2017/10/olavo-de-carvalho-o-guru-da-direita-que-rejeita-o-que-dizem-seus-fas.html?utm_source=twitter&utm_medium=social&utm_campaign=post> Vídeos: <https://www.youtube.com/watch?v=C0TUsKluhok,> <https://www.youtube.com/watch?v=yR0F1haQ07Y&t=5s>

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

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

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

# A Lightning penalty transaction It was a cold day and I remembered that this `lightningd` node I was running on my local desktop to work on [poncho](https://github.com/fiatjaf/poncho) actually had mainnet channels in it. Two channels, both private, bought on https://lnbig.com/ a while ago when I was trying to conduct an anonymous griefing attack on big nodes of the network just to prove it was possible (the attempts proved unsuccessful after some hours and I gave up). It is always painful to close channels because paying fees hurts me psychologically, and then it hurts even more to be left with a new small UTXO that will had to be spent to somewhere but that can barely pay for itself, but it also didn't make sense to just leave the channels there and risk forgetting them and losing them forever, so I had to do something. One of the channels had 0 satoshis on my side, so that was easy. Mutually closed and I don't have to think anymore about it. The other one had 10145 satoshis on my side -- out of a total of 100000 satoshis. Why can't I take my part all over over Lightning and leave the full channel UTXO to LNBIG? I wish I could do that, I don't want a small UTXO. I was not sure about it, but if the penalty reserve was 1% maybe I could take out abou 9000 satoshis and then close it with 1000 on my side? But then what would I do with this 1000 sat UTXO that would remain? Can't I donate it to miners or something? I was in the middle of this thoughts stream when it came to me the idea of causing a penalty transaction to give those abundant 1000 sat to Mr. LNBIG as a donation for his excellent services to the network and the cause of Bitcoin, and for having supported the development of https://sbw.app/ and the hosted channels protocol. Unfortunately `lightningd` doesn't have a command `triggerpenaltytransaction` or `trytostealusingoldstate`, so what I did was: First I stopped `lightningd` then copied the database to elsewhere: ``` cp ~/.lightningd/bitcoin/lightningd.sqlite3 ~/.lightning/bitcoin/lightningd.sqlite3.bak ``` then I restarted `lightningd` and fighted against the way-too-aggressive MPP splitting algorithm the `pay` command uses to pay invoices, but finally managed to pull about 9000 satoshis to my [Z Bot](https://t.me/zebedeebot) that lives on the terrible (but still infinitely better than Twitter DMs) "webk" flavor of the Telegram web application and which is linked to my against-bitcoin-ethos-country-censoring [ZEBEDEE Wallet](https://zbd.gg/). The operation wasn't smooth but it didn't take more than 10 invoices and `pay` commands.  With the money out and safe elsewhere, I stopped the node again, moved the database back with a reckless ``` mv ~/.lightning/bitcoin/lightningd.sqlite3.bak ~/.lightningd/bitcoin/lightningd.sqlite3 ``` and restarted it, but to prevent my `lightningd` from being super naïve and telling LNBIG that it had an old state (I don't know if this would happen) which would cause LNBIG to close the channel in a boring way, I used the `--offline` flag which apparently causes the node to not do any external connections. Finally I checked my balance using `lightning-cli listfunds` and there it was, again, the 10145 satoshis I had at the start! A fantastic money creation trick, comparable to the ones central banks execute daily.  I was ready to close the channel now, but the `lightning-cli close` command had an option for specifying how many seconds I would wait for a mutual close before proceeding to a unilateral close. There is no `forceclose` command like Éclair hasor anything like that. I was afraid that even if I gave LNBIG one second it would try to do boring things, so I paused to consider how could I just broadcast the commitment transaction manually, looked inside the SQLite database and the `channels` table with its millions of columns with cryptic names in the unbearable `.schema` output, imagined that `lightningd` maybe wouldn't know how to proceed to take the money from the `to-local` output if I managed to broadcast it manually (and in the unlikely event that LNBIG wouldn't broadcast the penalty transaction), so I decided to just accept the risk and call ``` lightning-cli close 706327x1588x0 1 ``` But it went well. The `--offline` flag apparently really works, as it just considered LNBIG to be offline and 1 second later I got the desired result.  My happiness was complete when I saw the commitment transaction with my output for 10145 satoshis published on the central database of Bitcoin, [blockstream.info](https://blockstream.info/tx/e5ceedadb98f612e5f3830985ebafd1cf1cae560b03eb5876a1fa1b14cfd0384?expand).  Then I went to eat something and it seems LNBIG wasn't offline or sleeping, he was certainly looking at all the logs from his 274 nodes in a big room full of monitors, very alert and eating an apple while drinking coffee, ready to take action, for when I came back, minutes later, I could see it, again on the single source of truth for the Bitcoin blockchain, the Blockstream explorer. I've refreshed the page and there it was, a small blue link right inside the little box that showed my `to-local` output, a notice saying it had been spent -- not by my `lightningd` since that would have to wait 9000 blocks, but by the same transaction that spent the other output, from which I could be very sure it was it, the glorious, mighty, unforgiving [**penalty transaction**](https://blockstream.info/tx/80ab328c77cbd554598c3a7b322af520a77d1687b27badfa969d2c419de785d7?input:1&expand), splitting the earth, showing itself in all its power, and taking my 10145 satoshis to their rightful owner. 

# localchat A server that creates instant chat rooms with [Server-Sent Events](https://en.wikipedia.org/wiki/Server-sent_events) and normal HTTP `POST` requests (instead of WebSockets which are an overkill most of the times). It defaults to a room named as your public IP, so if two machines in the same LAN connect they'll be in the same chat automatically -- but then you can also join someone else's LAN if you need. This is supposed to be useful.  - <https://github.com/fiatjaf/localchat> - <https://localchat.bigsun.xyz/> ## See also - [Filemap](nostr:naddr1qqyrwcekv33rze3kqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c23ya8a)

# hyperscript-go A template rendering library similar to [hyperscript](https://github.com/dominictarr/hyperscript) for Go. Better than writing HTML and Golang templates. - <https://github.com/fiatjaf/hyperscript-go> ### See also - [tempreites](nostr:naddr1qqyrgvpjxf3kzep3qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cs7qvaw)

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

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

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

# O que é Bitcoin? Todo guia infeliz sobre Bitcoin começa com esta pergunta manjada, e normalmente já vai respondendo que é uma "moeda virtual"[^moeda_virtual], um conceito estúpido que não esclarece nada. Esqueça esse papo. Bitcoin não é uma moeda. Bitcoin é um protocolo[^protocolo]. Por que então dizem que é uma moeda? Porque essas pessoas muito apressadinhas gostam de dizer que tudo que é facilmente divisível e transferível, e cujas várias unidades são idênticas umas às outras, é uma moeda. Então, nesse sentido, Bitcoin é uma moeda, mas ignore esse papo de moeda. O protocolo Bitcoin diz que existem "créditos" (ou "pontos", ou "unidades") que podem ser transferidas entre os participantes, e vários computadores, cada um operando independentemente do outro, desde que sigam o protocolo (ou seja: que estejam todos rodando o mesmo programa, ou programas compatíveis), estarão sempre em acordo a respeito de quem gastou cada crédito e como gastou. É basicamente essa a idéia: um monte de "pontos virtuais" que são transferidos de uns para outros, sem que exista uma entidade organizadora, "o dono do Bitcoin", "o chefe supremo do Bitcoin", que controle nada, coordene nada, ou tenha poder sobre essas transferências. ## Como funciona Imagine vários computadores rodando o mesmo programa (ou programas compatíveis). Agora imagine que esses programas se comunicam entre si através da internet: eles enviam mensagens uns para os outros e esperam respostas. De vez em quando a resposta não vem, ou vem num formato que o programa não entende, isso significa que o outro computador saiu do ar, ou está rodando uma versão incompatível do programa, e aí todos os outros vão ignorá-lo. Mas em geral a resposta vem certinha e todos conseguem falar com todos. Agora que você imaginou isso, fica fácil imaginar, por exemplo, que cada um desses computadores mantém uma lista de todos os bitcoins existentes e quem tem cada um. Eles pegam a lista dos outros computadores na rede e depois a vão atualizando à medida que novas transações vão sendo feitas. Toda vez que alguém quer fazer alguma transação, ele deve fazê-la por meio de um desses computadores, a pessoa chega no computador que está rodando o programa e diz: "sou fulano, tenho x bitcoins, e quero enviá-los para tal lugar", o programa vai lá e envia essa mensagem para os outros computadores, que atualizam a sua lista. Fim. Essa seria uma versão ingênua do protocolo, que funcionaria se todos os participantes fossem muito honestos e ninguém jamais tentasse gastar os bitcoins que não têm. Pra uma coisa dessas funcionar no mundo real teve de entrar a grande invenção do Bitcoin, o insight genial do Satoshi Nakamoto, que é a tal cadeia de blocos, conhecida por aí como _blockchain_. Funciona assim: ao invés de cada computador manter uma lista de onde está cada bitcoin, cada computador mantém a tal cadeia de blocos. Um "bloco" é só um nome bonitinho para um conjunto de dados. Cada bloco é composto por uma referência ao bloco anterior e uma lista de transações. Como eles contém uma referência ao anterior, existe uma seqüência, uma fila indiana, e o computador pode ficar tranqüilo sabendo a ordem das transações (as transações que aconteceram no terceiro bloco são posteriores às que aconteceram no segundo bloco, por exemplo) e saber que os mesmos bitcoins não foram gastos duas vezes seguidas pela mesma pessoa, o que seria inválido. Quando aparece um novo bloco, é só todos os computadores conferirem se não existe nenhuma transação inválida ali e, caso exista, rejeitarem aquele bloco por inteiro e esperarem que o próximo descarte aquela transação inválida e venha certinho. ## Quem faz os blocos Em tese, qualquer um dos computadores pode fazer o próximo bloco. A idéia é que cada pessoa que queira fazer uma transação vai lá e usa um computador da rede para enviar a sua proposta de transação ("quero transferir bitcoins para tal lugar e tal") para todos os demais, e que, quando alguém for fazer um bloco, pegue todas essas propostas de transação que forem válidas e as coloque no bloco que então será aceito por todos os outros computadores e incluído na cadeia global de blocos. Essa cadeia global tem que ser exatamente igual em todos os computadores. Na prática, existe uma regra que faz com que nem todos consigam fazer blocos: é que o _hash_ dos dados do bloco + um número mágico deve ser menor do que um valor muito pequeno `x`. O número mágico é um número qualquer que o computador que está tentando fazer o bloco pode ajustar, por tentativa e erro, para que o _hash_ saia de um jeito que ele queira. O `x` pode ser maior ou menor de acordo com a freqüência dos últimos blocos produzidos. Quanto menor for `x`, mais estatisticamente difícil é encontrar um número mágico que, junto com os dados do bloco, tenha um _hash_ menor do que `x`. Ou seja: para fazer um bloco, muitos números mágicos diferentes devem ser tentados até que seja encontrado algum que satisfaça as condições. **O que é um _hash_?** Um hash é uma função matemática que é fácil fazer para um lado e difícil de fazer para o outro. A multiplicação, por exemplo, é fácil de fazer e fácil de fazer, e sua operação contrária, a divisão, também (tanto é que qualquer um com papel e caneta consegue, tem aquela coisa de ir passando os números pra baixo e subtraindo e tal). Já uma operação de exponenciação -- um número elevado a 1000, por exemplo -- é fácil de fazer, mas pra desfazer só com tentativa e erro (e é por tentativa e erro que o computador ou a calculadora fazem). No caso do Bitcoin, o computador que está tentando produzir um bloco tem que achar um número tal que `(esse número mágico + fatores predeterminados do bloco) elevados a 50` resultem num valor menor do que `fator de dificuldade`, um outro fator predeterminado pelo estado geral da cadeia de blocos. Suponha que um computador acha um número `1798465042647412146620280340569649349251249`, por exemplo, e ele é menor do que o `fator de dificuldade`. Ele então diz para os outros: "aqui está meu bloco, o hash do meu bloco é `1798465042647412146620280340569649349251249`, os fatores `predeterminados do bloco` são `4` (esses fatores todo mundo pode conferir), e meu número mágico é `3`. `(4 + 3) elevado a 50` é `1798465042647412146620280340569649349251249`, como todos podem conferir, então meu bloco é válido". Então todos aceitam aquele bloco como válido e começam a tentar achar o número mágico para o próximo bloco (e desta vez os fatores do bloco são diferentes, já que um novo bloco foi adicionado à cadeia e fez com que tudo mudasse). As regras para a definição de `x` fazem com que na média cada novo bloco fique pronto em 10 minutos. Logo, se há apenas um computador tentando produzir blocos, o protocolo dirá que `x` seja relativamente alto, de modo que esse computador conseguirá, em 10 minutos, na média, encontrar um número mágico. Se, porém, milhares de computadores superpotentes estiverem tentando produzir blocos, `x` será ajustado para um valor muito mais baixo, de modo que o esforço de todos esses computadores fazendo milhares de tentativas-e-erros por segundo só conseguirá encontrar um número mágico a cada 10 minutos. Hoje existem computadores feitos especialmente para procurar números mágicos que conseguem calcular hashes muito mais rápido do que o seu computador caseiro, o que torna inviável que qualquer pessoa não especializada tente produzir blocos, veja este gráfico da evolução da quantidade de hashes que são tentados a cada segundo. Por algum motivo convencionou-se chamar os computadores que se empenham em fazer novos blocos de "mineradores". ## Se dois computadores da rede fizerem blocos ao mesmo tempo, qual dos dois vale? Se você já sabe quem faz os blocos fica fácil imaginar que isso é um pouco improvável. Mas mesmo assim pode acontecer. Mesmo que os blocos não fiquem prontos exatamente no mesmo instante, problemas podem acontecer porque os outros computadores da rede receberão os dois novos blocos em ordens diferentes, e aí não vai dar pra determinar qual vale ou qual deixa de valer assim, pela ordem. Os computadores então ficam num estado de indeterminação acerca das duas cadeias de blocos possíveis, A e B, digamos, ambas idênticas até o bloco de número 723, mas diferentes no que diz respeito ao bloco 724, para o qual há duas alternativas. O protocolo determina que a cadeia que tenha mais trabalho realizado é a que vale, mas durante algum tempo podemos ter um estado em que alguns computadores da rede só sabem da existência do bloco A, enquanto outros só sabem da existência do bloco B, o que é uma grande confusão que só pode ser resolvida pelo advento do próximo bloco, o 725. Como cada bloco se refere a um bloco anterior, é necessário que um desses dois blocos 724 seja escolhido pelos mineradores para ser o "pai" do bloco 725 quando o número mágico for encontrado e ele for feito. Mesmo que cada minerador escolha um pai diferente, desse processo sairá provavelmente apenas um bloco 725, e quando ele for espalhado ele determinará, pela sua ascendência, qual foi o bloco 724 que ficou valendo. Caso dois ou mais blocos 725 sejam produzidos ao mesmo tempo, o sistema continua nesse estado de indecisão até o 726, e assim por diante. Por este motivo não se deve confiar que uma transação está concretizada pra valer mesmo só porque ela foi incluída num bloco. Você não tem como saber se existe um outro bloco alternativo que será preferido ao seu até que pelo menos mais alguns blocos tenham sido adicionados. # Transações Muitas pessoas acreditam que existem endereços e que esses endereços têm um dono e ele é o dono dos bitcoins. Esta crença errônea é resultado de uma analogia com bancos tradicionais e contas bancárias (as contas são endereços que têm um dono e guardam dinheiro). Na verdade assim que as transações são incluídas num bloco elas não "ficam em um endereço", mas vagando num grande limbo de transações. Deste limbo elas podem ser retiradas por qualquer pessoa que cumpra as condições que foram previamente especificadas pelo criador da transação. Uma analogia mais útil do que a analogia das contas bancárias é a analogia do dinheiro: imagine que você tem uma nota de 20 dinheiros e você quer usá-la pra pagar 10 dinheiros a outrem. Você precisa quebrar aquela nota de 20 em duas de 10 e aí uma fica com você e a outra com a outra pessoa, ou, se você tiver duas notas de 5, você pode juntar as duas e dar para a outra pessoa. Todas essas notas que você está gastando têm uma história prévia: elas vieram de algum lugar em algum momento para o seu controle. Transações com Bitcoin também são assim: você precisa mencionar especificamente uma transação anterior. Por exemplo, 1. Carlos paga 10 bitcoins a Dandara, Dandara agora tem uma transação no valor de 10 2. Elisa paga 17 bitcoins a Dandara, Dandara tem uma transação no valor de 10 e uma no valor de 17 3. Dandara paga 23 bitcoins a Felipe, ela junta suas duas transações e faz duas novas, uma no valor de 23, que vai para o controle de Felipe, e outra no valor de 4, que volta para o seu controle, Dandara agora tem uma transação no valor de 4, Felipe tem uma transação no valor de 23 4. Felipe paga 14 bitcoins a Geraldo, ele divide sua transação em duas, uma no valor de 14 e outra no valor de 9, e assim por diante Uma diferença, porém, é que no Bitcoin ninguém sabe quem é o dono da nota, você apenas sabe que pode gastá-la, caso você realmente possa (se uma transação prévia especifica uma condição que você pode cumprir, você deve cumprir aquela condição no momento em que estiver mencionando a transação prévia). Por isso uma carteira Bitcoin pode dizer que você "tem" um número x de bitcoins: a carteira sabe quais chaves privadas você controla e quais transações, dentre todas as transações não-gastas de toda a blockchain, podem ser gastas usando aquela chave. Uma forma comum de transação é que especifica a condição `qualquer pessoa que tiver a chave privada capaz de assinar a chave pública cujo hash vai aqui dito pode gastar esta transação`. Outras condições comuns são as que especificam `n` chaves, das quais `m` precisam assinar a transação para que ela seja gasta (por exemplo, entre Fulano, Beltrano e Ciclano, quaisquer dois deles precisam concordar, mas não um só), o famoso _multisig_. ## Canal de pagamento Um _payment channel_, ou _via de pagamento_, ou _canal de pagamento_ é uma seqüência de promessas de pagamento feitas entre dois usuários de Bitcoin que não precisam ser publicados na blockchain e por isso são instantâneas e grátis. Antes que você se pergunte o que acontece se alguém descumprir a promessa, devo dizer que "promessa" é um termo ruim, porque promessas de verdade podem ser quebradas, mas estas promessas são auto-cumpríveis, elas são transações assinadas que podem ser resgatadas a qualquer momento pelo destinatário bastando que ele as publique na blockchain. A idéia é que na maioria das vezes você não vai precisar disso, e pode continuar fazendo transações novas que invalidam as antigas até que você decida publicar a última transação válida. Deste modo seu dinheiro está seguro numa via de pagamento O grande problema é que caso a outra parte decida roubar e publicar uma transação antiga, você precisa aparecer num espaço de tempo razoável (isto depende do combinado entre os dois usuários, mas acho que o padrão é 24 horas) e publicar a última transação. Existem incentivos para impedir que alguém tente roubar (por exemplo, quem tentar roubar e for pego perde todo o dinheiro que estava naquela via) e outros mecanismos, como as atalaias que vigiam as vias de pagamentos dos outros pra ver se ninguém está roubando. Exemplo: 1. Ângela e Bóris decidem criar uma via de pagamento, pois esperam realizar muitos pagamentos de pequeno valor entre eles, tanto de ida quanto de volta, ao longo de vários meses 2. Ângela cria uma transação para um endereço compartilhado entre ela e Bóris, no valor de 1000 satoshis, e desse endereço ela e Bóris criam uma transação devolvendo os 1000 para Ângela 3. Ao resolver pagar 200 satoshis para Bóris, eles criam uma nova transação que transfere 800 para Ângela e 200 para Bóris 4. Agora Bóris quer pagar 17 satoshis para Ângela, eles criam uma nova transação que transfere 817 para Ângela e 173 para Bóris 5. E assim por diante eles vão criando novas transações que invalidam as anteriores e vão alterando o "saldo" da via de pagamento. Quando qualquer um dos dois quiser sacar o dinheiro que tem no saldo é só publicar a última transação e pronto. A [rede Relâmpago](nostr:naddr1qqyr2wp4x3jkxvnpqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c2tt64h) é uma grande rede de canais de pagamento que permite que pessoas façam pagamentos para pessoas não diretamente ligadas a elas por canais diretos, mas através de uma rota que percorre vários canais de outrem e ajusta seus saldos. # Existem outras criptomoedas além do Bitcoin? Pra começar, jamais use essa palavra de novo. "criptomoeda" é ainda pior do que "moeda virtual"[^moeda_virtual]. Agora, respondendo: sim, de certo modo existem, são chamadas as "altcoins" ou "shitcoins" ("moedas de cocô", tradução amigável), porque elas são, de fato, grandes porcarias. De outro modo, pode-se dizer que elas não são comparáveis ao Bitcoin, porque só pode haver uma moeda num livre mercado de moedas, e esse posto já é do Bitcoin, e também porque o Bitcoin é livre, sem donos, sem grandes poderes que o controlam, o que não se pode dizer de nenhuma altcoin. Depois que o Bitcoin foi inventado e seu _insight_ genial foi assimilado pela comunidade interessada, milhares de pessoas copiaram o protocolo, com pequenas modificações, para criar suas próprias moedas. Assim surgiram Litecoin, Ethereum e muitas outras. No fundo são apenas cópias do Bitcoin que tentam melhorá-lo de algum modo ou adicionar outras funções. # Veja também: * [Aos poucos, e aí tudo de uma vez](https://fiatjaf.com/aos-poucos.html), Parker Lewis * [Não tem solução](nostr:naddr1qqyrswtxxdnxgdtrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823csj44kn) * [A podridão](nostr:naddr1qqyrydehxscrxvfkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cy2fdqc) * [O Bitcoin como um sistema social humano](nostr:naddr1qqyrwdfcx5ek2c3eqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cafzf9f) * [Rede Relâmpago](nostr:naddr1qqyr2wp4x3jkxvnpqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c2tt64h) --- [^protocolo]: Neste contexto, um protocolo é um conjunto de regras (inventadas arbitrariamente ou surgidas dos usos e costumes ao longo do tempo) que permitem que dois computadores diferentes se entendam e saibam que tipo de mensagens e comportamentos esperar dos demais. [^moeda_virtual]: Virtual? Virtual era pra significar uma coisa que não é ainda "atual", ou seja, que ainda não se concretizou na realidade. Mas como nossos amigos falantes da língüa portuguesa quiseram que isso passasse também a significar qualquer coisa que aconteça em um computador, "moeda virtual" ficou sendo uma moeda que existe no computador. O Bitcoin claramente é uma moeda que existe no computador, mas mesmo assim esse conceito é confuso. Uma transferência bancária tradicional também não é "dinheiro virtual"? Ela acontece no computador, mas você ainda não pegou as notas de papel ali na sua mão, então é virtual. Chamar só o Bitcoin de moeda virtual pode talvez criar a impressão de que é o Bitcoin é um brinquedinho, como por exemplo as moedas virtuais que existem dentro do universo de jogos de simulação, como, sei lá, World of Warcraft.

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

# Things a coalition of evil miners can do on Bitcoin If a miner coalition has 75% of hashrate for 6 months they can steal coins from a [Drivechain](nostr:naddr1qq9xgunfwejkx6rpd9hqzythwden5te0ve5kzar2v9nzucm0d5pzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqr4gumtjfnp) without any risk, that's what the drivechain haters say. What other evil things can a coalition of 75% hashrate do in 6 months? - steal money from all open Lightning nodes on the network by opening channels to them, mining 3 blocks, spending the funds out on Lightning instantly, then rolling back the 3 blocks and canceling the channel. - the above would eventually -- but not instantly and only after many steals have happened (even if they're not all perfectly coordinated and instant) -- cause Lightning to shrink in size a lot and become more of a closed friends network than truly open. - only mine empty blocks and cause the mempool to be enormously clogged. - refuse to use the mempool, force a proprietary API for transaction propagation with zero transparency and force other miners to use that same infrastructure too and extract a fee from them. - censor anything and force other miners to censor too, at the threat of orphaning their blocks. - easily cause so much confusion in the mining process that Bitcoin is deemed unusable and price falls drastically, miners can then buy at low price.

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

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

# The problem with DIDs _Decentralized Identifiers_ are supposedly a standard that will allow anyone (or anything) to have an online identity. The DID is a URI like `did:<method>:<data>` in which `<method>` determines how to interpret the `<data>`. The data is generally a public key in some cryptographic system or shitcoin blockchain, or a naked key, or a DNS-backed web address. Some of the DID proponents argue that this is for maximum interoperability, since any new system can be supported under the same standard, i.e. supposedly an application could "support DIDs" (as some would say) and that would allow anyone to just paste their DID string there and that would refer to something. There are [a gazillion](https://w3c.github.io/did-spec-registries/#did-methods) of different DID "methods", most of them are probably barely used. What does it mean for an application to "support" DIDs, then? For the interoperability argument to make any sense that must mean that the application must understand all the "methods" -- which involves understanding all cryptographic protocols and reading and interpreting data from a gazillion different blockchains and also understanding the specifics of each method, since the data of each blockchain or website and so on must also be interpreted according to the rules of the method. It must be clear from the paragraph above that the DID goal is is unimplementable and therefore will either fail horribly by lack of adoption; or it will have to be changed to something else (for example everybody will start accepting just `did:key` and ignore others and that will _be_ the standard); or it will become a centralized thing with all supporting applications using a single set of libraries that have built-in support for all methods by calling centralized servers that return the final product of processing the DID data for each method. ## See also: - [The problem with ION](nostr:naddr1qqyrvcnrvfjkvvf3qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823czjscmz)

# Rede Relâmpago Ao se referir à _Lightning Network_ do [O que é Bitcoin?](nostr:naddr1qqrky6t5vdhkjmspz9mhxue69uhkv6tpw34xze3wvdhk6q3q80cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsxpqqqp65wp3k3fu), nós, brasileiros e portugueses, devemos usar o termo "Relâmpago" ou "Rede Relâmpago". "Relâmpago" é uma palavra bonita e apropriada, e fácil de pronunciar por todos os nossos compatriotas. Chega de anglicismos desnecessários. Exemplo de uma conversa hipotética no Brasil usando esta nomenclatura: – Posso pagar com Relâmpago? – Opa, claro! Vou gerar um boleto aqui pra você. Repare que é bem mais natural e fácil do que a outra alternativa: – Posso pagar com láitenim? – Leite ninho?

# The illusion of note-taking Most ideas come to me while I'm nowhere near a computer, so it's impossible to note them all down. Even this one -- the realization of the illusion that many people have, including me, that it's possible to note down all our ideas in a ["zettelkasten"][797984e3] that will contain the history of all our insights -- is only noted later, with great distress since I forgot the other thoughts that lead to it and now am wasting time mentioning these unknowns forever lost.

# mcldsp A tool that migrates data from a [c-lightning](https://github.com/ElementsProject/lightning/) SQLite3 database into PostgreSQL so one can keep Lightning channels and everything but change the underlying database. It's a mostly manual thing, and I keep following changes in the database schema on c-lightning's GitHub repo so I can update the migration specs whenever needed. - <https://github.com/fiatjaf/mcldsp> ## See also - [Sparko](nostr:naddr1qqyx2vpnvs6nze3jqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c362tx2) - [trustedcoin](nostr:naddr1qqyx2wp4vgekgwfsqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c04z53s)

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

# Como não houve resposta, estou enviando de novo Recebi um email assim, dizendo a mesma coisa repetida. Eu havia recebido já da primeira vez, mas como era só uma informação já esperada, julguei que não precisava responder dizendo "chegou, obrigado!" e não o fiz. Reconheço, porém, que dada a instabilidade desses serviços de email nunca ninguém sabe se a mensagem chegou ou não. Ela pode ter sido jogada na lixeira do spam, ou pode ter falhado por outros motivos, e aí não existe um jeito garantido de saber se houve falha, é um enorme problema sempre. Por isso a necessidade de uma resposta "chegou, obrigado!". Mas não podemos parar por aí. A resposta "chegou, obrigado!" também está sujeita aos mesmos trâmites e riscos da mensagem original. Seria necessário, porém, que assim que a outra pessoa recebesse o "chegou, obrigado!" deveria então responder com um "recebi a sua confirmação". Caso não o fizesse, eu poderia achar que a minha mensagem não havia chegado e dias depois enviá-la de novo: "como não houve resposta à minha confirmação, estou enviando de novo". E assim por diante (eu ia escrever mais um parágrafo só pelo drama, mas desisti. Já deu pra entender). --- - [Ripple and the problem of the decentralized commit](nostr:naddr1qqyrxcmzxa3nxv34qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cjrqar6), esta situação que acabo de viver é mais um exemplo prático disto.

# Per Bylund's insight The firm doesn't exist because, like [Coase said](https://en.wikipedia.org/?curid=83030), it is inefficient to operate in a fully open-market and production processes need some bubbles of central planning. Instead, what happens is that a firm is created because an entrepreneur is doing a new thing (and here I imagine that doing an old thing in a new context also counts as doing a new thing, but I didn't read his book), and for that new thing there is no market, there are no specialized workers offering the services needed, nor other businesses offering the higher-order goods that entrepreneur wants, so he must do all by himself. So the entrepreneur goes and hires workers and buys materials more generic than he wanted and commands these to build what he wants exactly. It is less efficient than if he could buy the precise services and goods he wanted and combine those to yield the product he envisaged, but it accomplishes the goal. Later, when that specific market evolves, it's natural that specialized workers and producers of the specific factors begin to appear, and the market gets decentralized.

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

# idea: Patreon, but simple, and without subscription Basically instead of a subscription and becoming member of something, you just get a forum for your inner circle and people get lnurl-pay codes they can use to donate. Some amount of donations is required to remain in the group (like x per month), but if you donate more than that on the beginning you can stay until your credits expire. Every time someone donates a notice is posted in the group page. Perhaps that could be an [@lntxbot](https://t.me/lntxbot) feature.

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

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

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

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