@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 450f1fea:d9473ecc

A German article, published by lawyer Viviane Fisher, available [here](https://2020news.de/bomb-shell-wie-die-italienischen-richter-auf-linie-gebracht-wurden/), proves corruption in the Italian judiciary against Covid injection victims. The whole article is available below, translated to English, and chillingly underlines the need for initiatives like [We The People](nostr:naddr1qqxnzdesxuunydfexumnzdfjqgsy2rclafajlcqg428lgue5rzk3ru6y7vqqlhapju9vwqr9m9rnanqrqsqqqa28s2qdjt) where the general public removes judicial matters from totally corrupt judiciaries. Listen to the article: https://media.nostr.build/av/201d5c6cb80e815f7e42777037230b9bc5c231b13aa3653825f44553062703a3.mp3 ### Bomb Shell: How the Italian judges were brought into line. Italian journalist [Andrea Zambrano](https://lanuovabq.it/it/andrea-zambrano) has discovered what may have been one of the reasons for the almost unanimous rulings in favor of vaccination narratives and against fundamental individual rights throughout Italy: a decision-making guide penned by the Italian Supreme Court. Text modules from the "Report for judges number 103 on legislative novelties of October 28, 2021", with which future lawsuits should be rejected, have found themselves as hot tracks in various judgments. With explanations on the topics of "*safe and effective vaccines*", "*constitutional conformity of the measures*", "*just obligation for oneself and others*", the judges were sworn in to the state narrative, which in Italy included mandatory vaccination for people over 50 years of age and for all healthcare workers, all teachers, law enforcement officers and all employees of the judiciary, as well as extremely strict 2G rules. The statements were based on false assumptions regarding a "*general consensus of the scientific community on the efficacy and safety*" of so-called "*vaccinations*". In part, these assumptions had already been refuted on October 28, 2021, but at the very least there was clear evidence of reasonable doubt about the accuracy of the presentation. The judge's report categorized the "*vaccines*" as absolutely safe and by definition effective, citing the unanimous conviction of all scientists. Compulsory vaccination - out of loyalty to the Republic - is fair and just, both for the vaccinated person and for others. The constitutional requirements were complied with in every case. On this line of argument, the discriminated, injured, disabled citizens and employees without the solidary green passport had to appear like a horde of baselessly rebellious egomaniacs to the judges called upon to rule in civil, criminal and administrative cases. The legally non-binding but impressive decision guide did not come from any judges but from the Italian Supreme Court, the equivalent of the German Federal Court of Justice. The Italian Supreme Court is responsible for the systematic and analytical review of case law and draws up maxims, reports and reviews of everything that is pronounced in the name of the Italian people. What would have happened if this vademecum, this guide to action for judges, had not existed? Would individual judges then have made greater use of their autonomy, which is particularly pronounced in Italy? In Italy, judges are appointed by a body of judges, the National Council of Judges, so their careers are not dependent on the mercy of the Minister of Justice, as they are in Germany. They are, however, dependent on the goodwill of their fellow judges. What is piquant in this context is that the chairman of the National Council of Judges is the President of the Republic, [Sergio Mattarella](https://www.google.com/search?client=safari&sca_esv=59f9c62adf8353ec&rls=en&q=Sergio+Mattarella&stick=H4sIAAAAAAAAAONgVuLSz9U3ME4uMLQsesRoyi3w8sc9YSmdSWtOXmNU4-IKzsgvd80rySypFJLgYoOy-KR4uJC08SxiFQxOLUrPzFfwTSwpSSxKzclJBACoVJrUWgAAAA&sa=X&ved=2ahUKEwijy-eAhaOEAxXFqP0HHfx-ABYQzIcDKAB6BAgmEAE), who, together with the then Prime Minister Mario Draghi, constantly proclaimed the fairy tale of safe and effective "*vaccination*" to the public. The two of them repeatedly told the population like a prayer wheel: "*If you don't get vaccinated, you kill yourself and others.*" The document in question, entitled "*The vaccination against Covid-19 and the obligation of the Green Pass in the current constitutional and legislative framework*", which is exclusively available in full to [La Nuova Bussola Quotidiana](https://lanuovabq.it/it/la-cassazione-dettava-la-linea-sugli-effetti-avversi-trascurabili) magazine, bears the signature of Judge Maria Acierno and her deputy Antonietta Scrima. The same document can be found in a slightly condensed version in the 2021 Yearbook, the collection of publications and files of the Supreme Court for the year 2021 ([printed there](https://lanuovabq.it/storage/docs/volume-iv-2021-massimario-civile-approfondimenti-tematici.pdf) from page 116 onwards).  It was written in October 2021, in the middle of the vaccination campaign to administer the third dose. This was the time when the scientific literature was already casting serious doubt on both the efficacy and the risk-free nature of the vaccination. The Astrazeneca product had already been rejected as unsuitable for mass use due to the occurrence of thromboses. The ninth report by AIFA, the Italian regulatory authority, available at the time pointed to 608 deaths following COVID-19 vaccinations. This alarming development was not included in the text written by Judge Milena D'Oriano. The most recently published yearbook for 2022 contains no updates on the topic, and the 2023 yearbook is not yet available to the public. The use of the vaccines to implement the vaccination obligation and the 2G rule constituted an off-label use in Italy, as it was used to allegedly prevent a viral infection with SARS CoV2 instead of only to prevent a severe course of COVID-19.  The conviction expressed in the action guide and thus conveyed to the judges is that "*all legal acts in the first phase of the emergency, such as the Emergency Ordinance, the D.P.C.M., and the ordinances of the Ministry of Health have also entailed restrictions on rights and constitutional freedoms*", but that these have been borne by the "*concern of authoritative jurists*". The difficult relationship between "*compulsory vaccination and the burden of vaccination*" requires the "*expression of the individual's duty of solidarity towards the community*" to be weighed against the "*expression of the individual's right to self-determination*". It is clear that, if one contrasts a supposedly risk-free "vaccination" that protects everyone with the seemingly excessive, individual self-determination excesses of the "vaccination opponents", a decision in favor of the solidarity-based vaccination requirement of a "small prick" is likely to be made. "*Self-determination is certainly a valuable asset, but it can exceed limits based on the duty of solidarity in the interest of the community*," writes Judge D'Oriano, concluding that "*the periodic bulletins on the course of the epidemic by the ISS (...) prove that vaccination prophylaxis is effective both in containing the symptoms of the disease, drastically reducing the risk of severe syndromes and in preventing the transmission of the infection*". The ISS, or Instituto Superiore de la Sanità, is the Italian equivalent of the RKI and attracted attention during the crisis by unleashing a huge shitstorm against its own critical employees who dared to express doubts about the safety of the "vaccinations" in the summer of 2022. Just as in Germany the word of the PEI and RKI about safe and effective "vaccination" was and is considered irrefutable - despite a large number of contradictory expert opinions such as those presented in the Solden trial - only the officially announced findings should be relevant to the Italian judges' decisions. However, why then did Judge D'Oriano not also take note of the EMA documents that had already appeared on the AIFA website on December 21, 2020, on the eve of the mass vaccination campaign, proving the inability of the Pfizer "vaccine" to prevent infection, giving the lie to Draghi's infamous catchphrase "*They don't get vaccinated - he, she gets infected and dies*"? Further evidence of substantial problems with the "vaccines" came from science and industry: The British Medical Journal published the news on February 10, 2022 that vaccinated people could become infected just as easily as unvaccinated people. Lancet publications also showed that the effectiveness against symptomatic Covid infection in vaccinated people decreases rapidly until it drops completely after about 6-7 months and even becomes negative. Wolfgang Philipp, Director of the European Health Agency HERA, told the European Parliamentary Committee of Inquiry into COVID19: "*If you want to have a vaccine that prevents transmission, good luck. We have not managed to find it, it is not yet available*". By order of the US Food and Drug Administration (FDA), Pfizer was forced to submit a report on its pharmacovigilance, which was conducted from December 1, 2020 to February 28, 2021. It revealed that "there were a total of 42,000 cases containing 158,000 reported adverse reactions, of which 25,000 were from Italy alone". None of this was included in the judge's report in 2022. Following the Supreme Court's assessment, the judges dismissed most of the lawsuits filed by citizens for suspension of work and wages due to their refusal to submit to the - allegedly constitutional - solidarity act of vaccination. The magazine La Bussola names cases: e.g. the tragic story of young Runa Cody and his unexplained death from pericarditis. The mother had already brought many documents to the courtroom in June 2021 proving the occurrence of perimyocarditis after "vaccination" by providing Aifa documents. The response of the competent judge in Civitavecchia was: "*At the time of administration and even today, the scientific literature on this subject was extremely scarce or absent*". Although deaths and harm had already been documented in international pharmacovigilance and addressed by renowned scientists, the Supreme Court report of October 28, 2021 shows a willingness to completely deny the existence of significant adverse effects. It relies exclusively on the latest available AIFA report of October 22, 2021, which later turned out to be manipulated. Worrying information about serious side effects has been deliberately suppressed by the decision-makers, which is now the subject of proceedings before the court in Rome and the ministerial court for former health minister Roberto Speranza, 2020News reported. On page 13 of the guide to action for their fellow judges, judges Maria Acierno and Antonietta Scripa write: "*It is scientifically proven and recognized that vaccines are one of the most effective preventive measures with a particularly high risk-benefit ratio and a very relevant ethical value as an expression of the duty of solidarity*". And - to justify compliance with Article 32 of the Constitution - they point out that "according to the Constitution, compulsory health treatment complies with the requirements of Article 32 if it is aimed at improving or maintaining the state of health of the subject to whom it is addressed and does not affect the health of the recipient". The constitutionality of compulsory vaccination could therefore only be claimed if all the already known and dramatically emerging multiple harms were consistently denied or if the sacrifice of the individual for the collective could be affirmed in a false risk-benefit assessment. In reality, however, the risk must be weighed up on an individual basis: the risk of the individual becoming infected with the virus and ending up in hospital in danger of death must be assessed in comparison to the (alleged) benefits they would gain from a "vaccination". On page 18 of the report, the judges state: "*In terms of safety, the monitoring carried out by AIFA through the pharmacovigilance system, which collects and evaluates all adverse event reports, shows a perfectly acceptable risk-benefit balance, since the harms resulting from the administration of the vaccine for SARS COV 2, which, given the extreme rarity of occurrence, must be considered rare and correlatable events that meet a statistical normality criterion with a very low and slightly higher incidence of short-term adverse reactions than has been known for years for ordinary vaccines*". They conclude that a possible Covid vaccination obligation, which would be provided for by law, would most likely have to be considered constitutional. A judge who would have wanted to counter such a convincing assessment of the factual and legal situation presented by the highest authority with his own arguments would have had to fear being exposed to similar hostility as the alleged "*anti-vaccinationists*" themselves.  How many judges have trusted this official and authoritative Supreme Court report and therefore dismissed the claims of the many victims who were forced to be vaccinated? It is high time to update the report with all the evidence that has emerged in the meantime and thus provide judges, public prosecutors and lawyers with better guidance for the legal proceedings. Not only with regard to the alleged effectiveness, but also and especially with regard to the high risks of the "vaccinations". Have other countries also been influenced in this way from "the very top"? We are staying on top of the issue.

@ f240c9c2:6c0c0a86

noStrudel、早いし機能も充実していてとても良いクライアント。でも個人的に画面下部のタブバーがごちゃっとしてるのが気に入らなかったので、雑にUIを破壊してみた。 ついでにフォントサイズがちょっと小さくて見づらかったので気持ち大きくした。 ## before  ## after  ## ブックマークレット版 ```js javascript:applyStyle%3D()%3D%3E%7B(customStyle%3Ddocument.createElement(%22style%22)).innerText%3D%60%20body%7Bfont-size%3Alarger%3B%7Dbutton%5Baria-label%3D%22Launchpad%22%5D%7Bdisplay%3Anone%3B%7Dbutton%5Baria-label%3D%22New%20Note%22%5D%7Bposition%3Aabsolute%3Bwidth%3A4rem%3Bheight%3A4rem%3Bbottom%3A4rem%3Bright%3A1.25rem%3Bborder-radius%3A50%25%3B%7D%60%2Cdocument.getElementsByTagName(%22head%22).item(0).appendChild(customStyle)%7D%2C-1%3D%3D%3Dwindow.location.href.search(%2F%5C%2F%5C%2Fnostrudel%5C.ninja%2F)%3Falert(%22noStrudelで実行しなはれ～%22)%3AapplyStyle()%3Bvoid(0); ``` [追加用リンク](javascript:applyStyle%3D()%3D%3E%7B(customStyle%3Ddocument.createElement(%22style%22)).innerText%3D%60%20body%7Bfont-size%3Alarge%3B%7Dbutton%5Baria-label%3D%22Launchpad%22%5D%7Bdisplay%3Anone%3B%7Dbutton%5Baria-label%3D%22New%20Note%22%5D%7Bposition%3Aabsolute%3Bwidth%3A4rem%3Bheight%3A4rem%3Bbottom%3A4rem%3Bright%3A1.25rem%3Bborder-radius%3A50%25%3B%7D%60%2Cdocument.getElementsByTagName(%22head%22).item(0).appendChild(customStyle)%7D%2C-1%3D%3D%3Dwindow.location.href.search(%2F%5C%2F%5C%2Fnostrudel%5C.ninja%2F)%3Falert(%22nostrudelで実行しなはれ～%22)%3AapplyStyle()%3Bvoid(0);) ## UserStyle版 「iOS Safariだからユーザースタイルとか使えなさそ〜」と思い込んでたら[普通に使えた](https://blog.kentokanai.net/userscripts/)のでブックマークレットにする必要なかった。 ```css /* ==UserStyle== @name noStrudelCustomStyle @include https://nostrudel.ninja/* ==/UserStyle== */ body{font-size:larger;} button[aria-label="Launchpad"]{display:none;} button[aria-label="New Note"]{position:absolute;width:4rem;height:4rem;bottom:4rem;right:1.25rem;border-radius:50%;} ``` [保存用リンク](https://gist.githubusercontent.com/ikanoasi10/1592ba02de4eeea13fb84c09ebdc5299/raw/2408427bc5eba6a1af07c794d113ec79a849e5c5/noStrudelCustomStyle.css)

@ d1d17471:5b15ed44

Nostrプロトコルを利用したアプリケーションの開発に役立つ資料をまとめていく場です。 ## プロトコル仕様書 ### nostr-protocol/nips https://github.com/nostr-protocol/nips Nostrプロトコルの仕様を定めるNIPs(Nostr Implementation Possibilities)を取りまとめるリポジトリ。 また、issue・PRは新規NIPの提案や既存NIPの改善などに関する議論を交わす場となっている。 必須仕様はすべて **NIP-01** にまとまっているので、まずはNIP-01を読みましょう ### nips-ja https://github.com/nostr-jp/nips-ja NIPsの日本語訳プロジェクト。 ## プロトコルの解説 ### Web記事 - [Nostrプロトコル(damus)を触ってみた](https://qiita.com/gpsnmeajp/items/77eee9535fb1a092e286) - [Nostr の面白さをエンジニア目線で解説してみる](https://zenn.dev/mattn/articles/cf43423178d65c) - [Nostr Scrapbox](https://scrapbox.io/nostr/) ### 書籍 - [Hello, Nostr! 先住民が教えるNostrの歩き方](https://nip-book.nostr-jp.org/book/1/) - [learn-nostr-by-crafting](https://github.com/nostr-jp/learn-nostr-by-crafting): 本書内記事「手を動かして学ぶNostrプロトコル」の演習用リポジトリ - [Hello, Nostr! Yo Bluesky! 分散SNSの最前線](https://nip-book.nostr-jp.org/book/2/) - [learn-nostr-by-crafting-2](https://github.com/nostr-jp/learn-nostr-by-crafting-2): 本書内記事「演習！作ってみよう「日本語 TL のぞき窓」の演習用リポジトリ - [Software Design誌 連載「新時代の分散SNS Nostr」(2023年7月号~12月号)](https://gihyo.jp/magazine/SD/backnumber) - 第1回(7月号)〜第3回(9月号): Nostrプロトコルやアプリケーションの紹介 - 第4回(10月号): Nostrプロトコルの解説 - 第5回(11月号), 第6回(12月号): Nostrアプリケーションの実装解説 ### 動画 - [分散型SNSプロトコル nostrの解説](https://www.youtube.com/watch?v=vB905DhX9nQ) ## ライブラリ ### nostr-tools https://github.com/nbd-wtf/nostr-tools Nostrアプリケーションの開発で頻出する処理を提供するJS/TSライブラリ。 - 秘密鍵の生成・秘密鍵から公開鍵への変換 - イベントの署名・検証 - リレーとの通信(イベント購読・発行) - bech32形式識別子(`npub`, `nsec`, `nevent`などから始まる識別子、NIP-19)のencode/decode - ドメイン認証(NIP-05)の検証 - etc... ### NDK https://github.com/nostr-dev-kit/ndk Nostrプロトコルに対する、nostr-toolsよりも高いレイヤの抽象を提供するJS/TSライブラリ [ドキュメント](https://ndk.fyi/docs/) ### rx-nostr https://github.com/penpenpng/rx-nostr イベント購読をはじめとするNostrリレーとのやり取りを、RxのSubscriptionとして扱えるようにするJS/TSライブラリ。 [ドキュメント](https://penpenpng.github.io/rx-nostr/) ### nostr-fetch https://github.com/jiftechnify/nostr-fetch Nostrリレーから過去のイベントを取得する機能を提供するJS/TSライブラリ。最新のReplaceable Eventの取得にも便利。 (リレーから過去のイベントを正確に取得しようと思うと、落とし穴が多くて意外と大変。詳細は[こちら](https://speakerdeck.com/jiftechnify/nostrnorirekaralou-renakusubetenoibentowoqu-tutekuruji-shu)) ### rust-nostr https://github.com/rust-nostr/nostr Rust向けにNostrプロトコル全般の抽象を提供するライブラリ。機能ごとにクレートが分割されている。 - nostr: Nostrプロトコルの低レイヤの実装 - nostr-sdk: nostrクレートをベースとする、より高レイヤの抽象。クライアントの実装向け - nostr-database: Nostrイベントの永続化処理に関する抽象。 - etc また、さまざまなプログラミング言語向けのbindingが提供されている ### go-nostr https://github.com/nbd-wtf/go-nostr Nostrプロトコル全般の抽象を提供するGoライブラリ。 ### eventstore https://github.com/fiatjaf/eventstore Nostrイベントの永続化処理に関する抽象を提供するGoライブラリ。 ### khatru https://github.com/fiatjaf/khatru Go向けのNostrリレー実装用のフレームワーク。

@ b3e43e8c:e3068b5f

ああテストだよテストだよ

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# 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

@ 3bf0c63f:aefa459d

 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>

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# IPFS problems: Community I was an avid IPFS user until yesterday. Many many times I asked simple questions for which I couldn't find an answer on the internet in the #ipfs IRC channel on Freenode. Most of the times I didn't get an answer, and even when I got it was rarely by someone who knew IPFS deeply. I've had issues go unanswered on js-ipfs repositories for year – one of these was raising awareness of a problem that then got fixed some months later by a complete rewrite, I closed my own issue after realizing that by myself some couple of months later, I don't think the people responsible for the rewrite were ever acknowledge that he had fixed my issue. Some days ago I asked some questions about how the IPFS protocol worked internally, sincerely trying to understand the inefficiencies in finding and fetching content over IPFS. I pointed it would be a good idea to have a drawing showing that so people would understand the difficulties (which I didn't) and wouldn't be pissed off by the slowness. I was told to read the whitepaper. I had already the whitepaper, but read again the relevant parts. The whitepaper doesn't explain anything about the DHT and how IPFS finds content. I said that in the room, was told to read again. Before anyone misread this section, I want to say I understand it's a pain to keep answering people on IRC if you're busy developing stuff of interplanetary importance, and that I'm not paying anyone nor I have the right to be answered. On the other hand, if you're developing a super-important protocol, financed by many millions of dollars and a lot of people are hitting their heads against your software and there's no one to help them; you're always busy but never delivers anything that brings joy to your users, something is very wrong. I sincerely don't know what IPFS developers are working on, I wouldn't doubt they're working on important things if they said that, but what I see – and what many other users see (take a look at the IPFS Discourse forum) is bugs, bugs all over the place, confusing UX, and almost no help.

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# Método científico o método científico não pode ser aplicado senão numa meia dúzia de casos, e no entanto ei-nos aqui, pensando nele para tudo. "formule hipóteses e teste-as independentemente", "obtenha uma quantidade de dados estatisticamente significante", teste, colete dados, mensure. não é que de repente todo mundo resolveu calcular desvios-padrão, mas sim que é comum, para as pessoas mais cultas, nível Freakonomics, acharem que têm que testar e coletar dados, e nunca jamais confiar na sua "intuição" ou, pior, num raciocínio que pode parecer certo, mas na verdade é enormemente enganador. sim, é verdade que raciocínios com explicações aparentemente sensatas nos são apresentados todos os dias -- para um exemplo fácil é só imaginar um comentarista de jornal, ou até uma matéria inocente de jornal, aliás, melhor pensar num comentarista da GloboNews --, e sim, é verdade que a maioria dessas explicações é falsa. o que está errado é achar que só o que vale é testar hipóteses. você não pode testar a explicação aparentemente sensata que o taxista te fornece sobre a crise brasileira, deve então anotá-la para testar depois? mantê-la para sempre no cabedal das teorias ainda por testar? e a explicação das redinhas que economizam água quando instaladas na torneira? essa dá pra testar, então você vai comprar um relógio de água e deixar a torneira ligada lá 5 horas com a redinha, depois 5 horas sem a redinha? obviamente não vai funcionar se você abrir o mesmo tanto, você vai precisar de um critério melhor: a satisfação da pessoa que está lavando as mãos com o resultado final _versus_ a quantidade de água gasta. daí você precisaria de muitas pessoas, mas satisfação é uma coisa imensurável, nem adianta tentar fazer entrevistas antes e depois com as pessoas. o certo então, é o quê? procurar um estudo científico publicado numa revista **de qualidade** (porque tem aquelas revistas que aceitam estudos gerados por computador, então é melhor tomar cuidado) que fala sobre redinhas? como saber se a redinha é a mesma que você comprou? e agora que você já comprou, o resultado do experimento importa? (claro: pode ser que a redinha faça gastar mais água, você nunca saberá até que faça o experimento). por que não, ao invés de condenar todos os raciocínios como enganadores e mandar que as pessoas façam experimentos científicos, ensinar a fazer raciocínios certos?

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# Trello Attachment Editor A static JS app that allowed you to authorize with your Trello account, fetch the board structure, find attachments, edit them in the browser then replace them in the cards. Quite a nice thing. I believe it was done to help with [Websites For Trello](nostr:naddr1qqyrydpkvverwvehqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c9d4yku) attached scripts and CSS files. - <https://github.com/fiatjaf/trello-attachments> - <https://fiatjaf.github.io/trello-attachments/#/login> ### See also - [Temperos](nostr:naddr1qqyrvvpevgurzwfeqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cvyhzdz)

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

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