@ 32e18276:5c68e245

I’m going to be on an ordinals panels as one of the people who is counter arguing the claim that they are good for bitcoin. I decided to brush up on the technicals on how inscriptions work. I am starting to see luke’s perspective on how it is exploiting a loophole in bitcoin’s anti-data-spam mechanisms.

Storing data in Bitcoin, the “standard” way

The standard way you add “data” to bitcoin is by calling the OP_RETURN opcode. Bitcoin devs noticed that people were storing data (like the bitcoin whitepaper) in the utxo set via large multisig transactions. The problem with this is that this set is unprunable and could grow over time. OP_RETURN outputs on the other-hand are provably prunable and don’t add to utxo bloat.

Here’s an excerpt from the march 2014 0.9.0 release notes that talks about this:

On OP_RETURN: There was been some confusion and misunderstanding in the community, regarding the OP_RETURN feature in 0.9 and data in the blockchain. This change is not an endorsement of storing data in the blockchain. The OP_RETURN change creates a provably-prunable output, to avoid data storage schemes – some of which were already deployed – that were storing arbitrary data such as images as forever-unspendable TX outputs, bloating bitcoin’s UTXO database. Storing arbitrary data in the blockchain is still a bad idea; it is less costly and far more efficient to store non-currency data elsewhere.

Much of the work on bitcoin core has been focused on making sure the system continues to function in a decentralized way for its intended purpose in the presence of people trying to abuse it for things like storing data. Bitcoin core has always discouraged this, as it is not designed for storage of images and data, it is meant for moving digital coins around in cyberspace.

To help incentive-align people to not do stupid things, OP_RETURN transactions were not made non-standard, so that they are relayable by peers and miners, but with the caveat:

1. They can only push 40 bytes (later increased to 80,83, I’m guessing to support larger root merkle hashes since that is the only sane usecase for op_return)

Bitcoin also added an option called -datacarriersize which limits the total number of bytes from these outputs that you will relay or mine.

Why inscriptions are technically an exploit

Inscriptions get around the datacarriersize limit by disguising data as bitcoin script program data via OP_PUSH inside OP_IF blocks. Ordinals do not use OP_RETURN and are not subjected to datacarriersize limits, so noderunners and miners currently have limited control over the total size of this data that they wish to relay and include in blocks. Luke’s fork of bitcoin-core has some options to fight this spam, so hopefully we will see this in core sometime soon as well.

Inscriptions are also taking advantage of features in segwit v1 (witness discount) and v2/taproot (no arbitrary script size limit). Each of these features have interesting and well-justified reasons why they were introduced.

The purpose of the witness discount was to make it cheaper to spend many outputs which helps the reduction of the utxo set size. Inscriptions took advantage of this discount to store monke jpegs disguised as bitcoin scripts. Remember, bitcoin is not for storing data, so anytime bitcoin-devs accidentally make it cheap and easy to relay data then this should be viewed as an exploit. Expect it to be fixed, or at least provide tools to noderunners for fighting this spam.

Where do we go from here

The interesting part of this story is that people seem to attach value to images stored on the bitcoin blockchain, and they are willing to pay the fee to get it in the block, so non-ideologic miners and people who don’t care about the health and decentralization of bitcoin are happy to pay or collect the fee and move on.

Data should not get a discount, people should pay full price if they want to store data. They should just use op_return and hashes like opentimestamps or any other reasonable protocol storing data in bitcoin.

After going through this analysis I’ve come to the opinion that this is a pretty bad data-spam exploit and bitcoin devs should be working on solutions. Ideological devs like luke who actually care about the health and decentralization of the network are and I’m glad to see it.

@ 3bf0c63f:aefa459d

Nostr is not decentralized nor censorship-resistant

Peter Todd has been saying this 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 and on my NIP-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 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
• A vision for content discovery and relay usage for basic social-networking in Nostr

@ 3bf0c63f:aefa459d

Censorship-resistant relay discovery in Nostr

In Nostr is not decentralized nor censorship-resistant 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 was the first client to implement a truly censorship-resistant relay discovery mechanism that used NIP-05 hints (originally proposed by Mike Dilger) relay hints and kind:3 relay lists, and then with the simple insight of NIP-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 and Snort.

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, for example, but I believe also in the clients listed above.

I don't think we should stop here, though. I think there are other ways, perhaps drastically different ways, to approach content propagation and relay discovery. I think manual action by users is underrated and could go a long way if presented in a nice UX (not conceived by people that think users are dumb animals), and who knows what. Reliance on third-parties, hardcoded values, social graph, and specially a mix of multiple approaches, is what Nostr needs to be censorship-resistant and what I hope to see in the future.

@ 3bf0c63f:aefa459d

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.

@ 866e0139:6a9334e5

Autor: Ulrike Guérot. Dieser Beitrag wurde mit dem Pareto-Client geschrieben. Sie finden alle Texte der Friedenstaube und weitere Texte zum Thema Frieden hier.**

---

Die neuesten Artikel der Friedenstaube gibt es jetzt auch im eigenen Friedenstaube-Telegram-Kanal.

---

https://www.youtube.com/watch?v=KarwcXKmD3E

Liebe Freunde und Bekannte,

liebe Friedensbewegte,

liebe Dresdener, Dresden ist ja auch eine kriegsgeplagte Stadt,

dies ist meine dritte Rede auf einer Friedensdemonstration innerhalb von nur gut einem halben Jahr: München im September, München im Februar, Dresden im April. Und der Krieg rückt immer näher! Wer sich den „Operationsplan Deutschland über die zivil-militärische Kooperation als wesentlicher Bestandteil der Kriegsführung“ anschaut, dem kann nur schlecht werden zu sehen, wie weit die Kriegsvorbereitungen schon gediehen sind. 

Doch bevor ich darauf eingehe, möchte ich mich als erstes distanzieren von dem wieder einmal erbärmlichen Framing dieser Demo als Querfront oder Schwurblerdemo. Durch dieses Framing wurde diese Demo vom Dresdener Marktplatz auf den Postplatz verwiesen, wurden wir geschmäht und wurde die Stadtverwaltung Dresden dazu gebracht, eine „genehmere“ Demo auf dem Marktplatz zuzulassen! Es wäre schön, wenn wir alle - alle! - solche Framings weglassen würden und uns als Friedensbewegte die Hand reichen! Der Frieden im eigenen Haus ist die Voraussetzung für unsere Friedensarbeit. Der Streit in unserem Haus nutzt nur denen, die den Krieg wollen und uns spalten!

Ich möchte hier noch einmal klarstellen, von welcher Position aus ich hier und heute wiederholt auf einer Bühne spreche: Ich spreche als engagierte Bürgerin der Bundesrepublik Deutschland. Ich spreche als Europäerin, die lange Jahre in und an dem einstigen Friedensprojekt EU gearbeitet hat. Ich spreche als Enkelin von zwei Großvätern. Der eine ist im Krieg gefallen, der andere kam ohne Beine zurück. Ich spreche als Tochter einer Mutter, die 1945, als 6-Jährige, unter traumatischen Umständen aus Schlesien vertrieben wurde, nach Delitzsch in Sachsen übrigens. Ich spreche als Mutter von zwei Söhnen, 33 und 31 Jahre, von denen ich nicht möchte, dass sie in einen Krieg müssen. Von dieser, und nur dieser Position aus spreche ich heute zu Ihnen und von keiner anderen! Ich bin nicht rechts, ich bin keine Schwurblerin, ich bin nicht radikal, ich bin keine Querfront.

Als Bürgerin wünsche ich mir – nein, verlange ich! – dass die Bundesrepublik Deutschland sich an ihre gesetzlichen Grundlagen und Vertragstexte hält. Das sind namentlich: Die Friedensklausel des Grundgesetzes aus Art. 125 und 126 GG, dass von deutschem Boden nie wieder Krieg ausgeht. Und der Zwei-plus-Vier-Vertrag, in dem Deutschland 1990 unterschrieben hat, dass es nie an einem bewaffneten Konflikt gegen Russland teilnimmt. Ich schäme mich dafür, dass mein Land dabei ist, vertragsbrüchig zu werden. Ich bitte Friedrich Merz, den designierten Bundeskanzler, keinen Vertragsbruch durch die Lieferung von Taurus-Raketen zu begehen!

Ich bitte ferner darum, dass sich dieses Land an seine didaktischen Vorgaben für Schulen hält, die im immer noch geltenden „Beutelsbacher Konsens“ aus den 1970er Jahren festgelegt wurden. In diesem steht in Artikel I. ein Überwältigungsverbot: „Es ist nicht erlaubt, den Schüler – mit welchen Mitteln auch immer – im Sinne erwünschter Meinungen zu überrumpeln und damit an der Gewinnung eines selbständigen Urteils zu hindern.“ Vor diesem Hintergrund ist es nicht erlaubt, Soldaten oder Gefreite in Schulen zu schicken und für die Bundeswehr zu werben. Vielmehr wäre es geboten, unsere Kinder über Art. 125 & 126 GG und die Friedenspflicht des Landes und seine Geschichte mit Blick auf Russland aufzuklären.

Als Europäerin wünsche ich mir, dass wir die europäische Hymne, Beethovens 9. Sinfonie, ernst nehmen, deren Text da lautet: Alle Menschen werden Brüder. Alle Menschen werden Brüder. Alle! Dazu gehören auch die Russen und natürlich auch die Ukrainer! 

Als Europäerin, die in den 1990er Jahren für den großartigen EU-Kommissionspräsidenten Jacques Delors gearbeitet hat, Katholik, Sozialist und Gewerkschafter, wünsche ich mir, dass wir das Versprechen, #Europa ist nie wieder Krieg, ernst nehmen. Wir haben es 70 Jahre lang auf diesem Kontinent erzählt. Die Lügen und die Propaganda, mit der jetzt die Kriegsnotwendigkeit gegen Russland herbeigeredet wird, sind unerträglich. Die EU, Friedensnobelpreisträgerin von 2012, ist dabei – oder hat schon – ihr Ansehen in der Welt verloren. Es ist eine politische Tragödie! Neben ihrem Ansehen ist die EU jetzt dabei, das zivilisatorische Erbe Europas zu verspielen, die civilité européenne, wie der französische Historiker und Marxist, Étienne Balibar es nennt. 

Ein Element dieses historischen Erbes ist es, dass uns in Europa eint, dass wir über Jahrhunderte alle zugleich Täter und Opfer gewesen sind. Ce que nous partageons, c’est ce que nous étions tous bourreaux et victimes. So schreibt es der französische Literat Laurent Gaudet in seinem europäischen Epos, L’Europe. Une Banquet des Peuples von 2016.

Das heißt, dass niemand in Europa, niemand – auch die Esten nicht! – das Recht hat, vorgängige Traumata, die die baltischen Staaten unbestrittenermaßen mit Stalin-Russland gehabt haben, zu verabsolutieren, auf die gesamte EU zu übertragen, die EU damit zu blockieren und die Politikgestaltung der EU einseitig auf einen Kriegskurs gegen Russland auszurichten. Ich wende mich mit dieser Feststellung direkt an Kaja Kalles, die Hohe Beauftragte für Sicherheits- und Außenpolitik der EU und hoffe, dass sie diese Rede hört und das Epos von Laurent Gaudet liest.

Es gibt keinen gerechten Krieg! Krieg ist immer nur Leid. In Straßburg, dem Sitz des Europäischen Parlaments, steht auf dem Place de la République eine Statue, eine Frau, die Republik. Sie hält in jedem Arm einen Sohn, einen Elsässer und einen Franzosen, die aus dem Krieg kommen. In der Darstellung der Bronzefigur haben die beiden Soldaten-Männer ihre Uniformen schon ausgezogen und werden von Madame la République gehalten und getröstet. An diesem Denkmal sollten sich alle Abgeordnete des Straßburger Europaparlamentes am 9. Mai versammeln. Ich zitiere noch einmal Cicero: Der ungerechteste Friede ist besser als der gerechteste Krieg. Für den Vortrag dieses Zitats eines der größten Staatsdenker des antiken Roms in einer Fernsehsendung bin ich 2022 mit einem Shitstorm überzogen worden. Allein das ist Ausdruck des Verfalls unserer Diskussionskultur in unfassbarem Ausmaß, ganz besonders in Deutschland.

Als Europäerin verlange ich die Überwindung unserer kognitiven Dissonanz. Wenn schon die New York Times am 27. März 2025 ein 27-seitiges Dossier veröffentlicht, das nicht nur belegt, was man eigentlich schon weiß, aber bisher nicht sagen durfte, nämlich, dass der ukrainisch-russische Krieg ein eindeutiger Stellvertreter-Krieg der USA ist, in der die Ukraine auf monströseste Weise instrumentalisiert wurde – was das Dossier der NYT unumwunden zugibt! – wäre es an der Zeit, die eindeutige Schuldzuweisung an Russland für den Krieg zurückzuziehen und die gezielt verbreitete Russophobie in Europa zu beenden. Anstatt dass – wofür es leider viele Verdachtsmomente gibt – die EU die Friedensverhandlungen in Saudi-Arabien nach Strich und Faden torpediert. 

Der französische Philosoph Luc Ferry hat vor ein paar Tagen im prime time französischen Fernsehen ganz klar gesagt, dass der Krieg 2014 nach der Instrumentalisierung des Maidan durch die USA von der West-Ukraine ausging, dass Zelensky diesen Krieg wollte und – mit amerikanischer Rückendeckung – provoziert hat, dass Putin nicht Hitler ist und dass die einzigen mit faschistoiden Tendenzen in der ukrainischen Regierung sitzen. Ich wünschte mir, ein solches Statement wäre auch im Deutschen Fernsehen möglich und danke Richard David Precht, dass er, der noch in den Öffentlich-Rechtlichen Rundfunk vorgelassen wird, an dieser Stelle versucht, etwas Vernunft in die Debatte zu bringen.

Auch ist es gerade als Europäerin nicht hinzunehmen, dass russische Diplomaten von den Feierlichkeiten am 8. Mai 2025 ausgeschlossen werden sollen, ausgerechnet 80 Jahre nach Ende des II. Weltkrieges. Nicht nur sind Feierlichkeiten genau dazu da, sich die Hand zu reichen und den Frieden zu feiern. Doch gerade vor dem Hintergrund von 27 Millionen gefallenen sowjetischen Soldaten ist die Zurückweisung der Russen von den Feierlichkeiten geradezu eklatante Geschichtsvergessenheit.

***

Der Völkerbund hat 1925 die Frage erörtert, warum der I. Weltkrieg noch so lange gedauert hat, obgleich er militärisch bereits 1916 nach Eröffnung des Zweifrontenkrieges zu Lasten des Deutschen Reiches entschieden war. Wir erinnern uns: Für die Niederlage wurden mit der Dolchstoßlegende die jüdischen, kommunistischen und sozialistischen Pazifisten verantwortlich gemacht. Richtig ist, so der Bericht des Völkerbundes von 1925, dass allein die Rüstungsindustrie dafür gesorgt hat, dass der militärisch eigentlich schon entschiedene Krieg noch zwei weitere Jahre als Materialabnutzungs- und Stellungskrieg weiterbetrieben wurde, nur, damit noch ein bisschen Geld verdient werden konnte. Genauso scheint es heute zu sein. Der Krieg ist militärisch entschieden. Er kann und muss sofort beendet werden, und das passiert lediglich deswegen nicht, weil der Westen seine Niederlage nicht zugeben kann. Hochmut aber kommt vor dem Fall, und es darf nicht sein, dass für europäischen Hochmut jeden Tag rund 2000 ukrainische oder russische Soldaten und viele Zivilisten sterben. Die offenbare europäische Absicht, den Krieg jetzt einzufrieren, nur, um ihn 2029/ 2030 wieder zu entfachen, wenn Europa dann besser aufgerüstet ist, ist nur noch zynisch.

Als Kriegsenkelin von Kriegsversehrten, Tochter einer Flüchtlingsmutter und Mutter von zwei Söhnen, deren französischer Urgroßvater 6 Jahre in deutscher Kriegsgefangenschaft war, wünsche ich mir schließlich und zum Abschluss, dass wir die Kraft haben werden, wenn dieser Wahnsinn, den man den europäischen Bürgern gerade aufbürdet, vorbei sein wird, ein neues europäisches Projekt zu erdenken und zu erbauen, in dem Europa politisch geeint ist und es bleibt, aber dezentral, regional, subsidiär, friedlich und neutral gestaltet wird. Also ein Europa jenseits der Strukturen der EU, das bereit ist, die Pax Americana zu überwinden, aus der NATO auszutreten und der multipolaren Welt seine Hand auszustrecken! Unser Europa ist postimperial, postkolonial, groß, vielfältig und friedfertig!

---

Ulrike Guérot, Jg. 1964, ist europäische Professorin, Publizistin und Bestsellerautorin. Seit rund 30 Jahren beschäftigt sie sich in europäischen Think Tanks und Universitäten in Paris, Brüssel, London, Washington, New York, Wien und Berlin mit Fragen der europäischen Demokratie sowie mit der Rolle Europas in der Welt. Ulrike Guérot ist seit März 2014 Gründerin und Direktorin des European Democracy Lab e.V., Berlin und initiierte im März 2023 das European Citizens Radio, das auf Spotify zu finden ist. Zuletzt erschien von ihr „Über Halford J. Mackinders Heartland-Theorie, Der geografische Drehpunkt der Geschichte“ (Westend, 2024). Mehr Infos zur Autorin hier.

---

LASSEN SIE DER FRIEDENSTAUBE FLÜGEL WACHSEN!

Hier können Sie die Friedenstaube abonnieren und bekommen die Artikel zugesandt.

Schon jetzt können Sie uns unterstützen:

• Für 50 CHF/EURO bekommen Sie ein Jahresabo der Friedenstaube.
• Für 120 CHF/EURO bekommen Sie ein Jahresabo und ein T-Shirt/Hoodie mit der Friedenstaube.
• Für 500 CHF/EURO werden Sie Förderer und bekommen ein lebenslanges Abo sowie ein T-Shirt/Hoodie mit der Friedenstaube.
• Ab 1000 CHF werden Sie Genossenschafter der Friedenstaube mit Stimmrecht (und bekommen lebenslanges Abo, T-Shirt/Hoodie).

Für Einzahlungen in CHF (Betreff: Friedenstaube):

Für Einzahlungen in Euro:

Milosz Matuschek

IBAN DE 53710520500000814137

BYLADEM1TST

Sparkasse Traunstein-Trostberg

Betreff: Friedenstaube

Wenn Sie auf anderem Wege beitragen wollen, schreiben Sie die Friedenstaube an: friedenstaube@pareto.space

---

Sie sind noch nicht auf Nostr and wollen die volle Erfahrung machen (liken, kommentieren etc.)? Zappen können Sie den Autor auch ohne Nostr-Profil! Erstellen Sie sich einen Account auf Start. Weitere Onboarding-Leitfäden gibt es im Pareto-Wiki.

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

@ 90de72b7:8f68fdc0

PetriNostr. My everyday activity 30/04

PetriNostr never sleep! This is a demo

petrinet ;startDay () -> working ;stopDay working -> () ;startPause working -> paused ;endPause paused -> working ;goSmoke working -> smoking ;endSmoke smoking -> working ;startEating working -> eating ;stopEating eating -> working ;startCall working -> onCall ;endCall onCall -> working ;startMeeting working -> inMeetinga ;endMeeting inMeeting -> working ;logTask working -> working

@ 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" 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 or by the Spacechains mechanism.

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 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. 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
• Alternatives to Drivechain
• Drivechain comparison with Ethereum

@ 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, 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

[^pr-merged-very-quickly]: See PR 20624, for example, a very complicated change that could be introducing bugs or be a deliberate attack, merged in 3 days without time for discussion.

@ a008def1:57a3564d

A Vision for #GitViaNostr

Git has long been the standard for version control in software development, but over time, we has lost its distributed nature. Originally, Git used open, permissionless email for collaboration, which worked well at scale. However, the rise of GitHub and its centralized pull request (PR) model has shifted the landscape.

Now, we have the opportunity to revive Git's permissionless and distributed nature through Nostr!

We’ve developed tools to facilitate Git collaboration via Nostr, but there are still significant friction that prevents widespread adoption. This article outlines a vision for how we can reduce those barriers and encourage more repositories to embrace this approach.

First, we’ll review our progress so far. Then, we’ll propose a guiding philosophy for our next steps. Finally, we’ll discuss a vision to tackle specific challenges, mainly relating to the role of the Git server and CI/CD.

I am the lead maintainer of ngit and gitworkshop.dev, and I’ve been fortunate to work full-time on this initiative for the past two years, thanks to an OpenSats grant.

How Far We’ve Come

The aim of #GitViaNostr is to liberate discussions around code collaboration from permissioned walled gardens. At the core of this collaboration is the process of proposing and applying changes. That's what we focused on first.

Since Nostr shares characteristics with email, and with NIP34, we’ve adopted similar primitives to those used in the patches-over-email workflow. This is because of their simplicity and that they don’t require contributors to host anything, which adds reliability and makes participation more accessible.

However, the fork-branch-PR-merge workflow is the only model many developers have known, and changing established workflows can be challenging. To address this, we developed a new workflow that balances familiarity, user experience, and alignment with the Nostr protocol: the branch-PR-merge model.

This model is implemented in ngit, which includes a Git plugin that allows users to engage without needing to learn new commands. Additionally, gitworkshop.dev offers a GitHub-like interface for interacting with PRs and issues. We encourage you to try them out using the quick start guide and share your feedback. You can also explore PRs and issues with gitplaza.

For those who prefer the patches-over-email workflow, you can still use that approach with Nostr through gitstr or the ngit send and ngit list commands, and explore patches with patch34.

The tools are now available to support the core collaboration challenge, but we are still at the beginning of the adoption curve.

Before we dive into the challenges—such as why the Git server setup can be jarring and the possibilities surrounding CI/CD—let’s take a moment to reflect on how we should approach the challenges ahead of us.

Philosophy

Here are some foundational principles I shared a few years ago:

• Let Git be Git
• Let Nostr be Nostr
• Learn from the successes of others

I’d like to add one more:

• Embrace anarchy and resist monolithic development.

Micro Clients FTW

Nostr celebrates simplicity, and we should strive to maintain that. Monolithic developments often lead to unnecessary complexity. Projects like gitworkshop.dev, which aim to cover various aspects of the code collaboration experience, should not stifle innovation.

Just yesterday, the launch of following.space demonstrated how vibe-coded micro clients can make a significant impact. They can be valuable on their own, shape the ecosystem, and help push large and widely used clients to implement features and ideas.

The primitives in NIP34 are straightforward, and if there are any barriers preventing the vibe-coding of a #GitViaNostr app in an afternoon, we should work to eliminate them.

Micro clients should lead the way and explore new workflows, experiences, and models of thinking.

Take kanbanstr.com. It provides excellent project management and organization features that work seamlessly with NIP34 primitives.

From kanban to code snippets, from CI/CD runners to SatShoot—may a thousand flowers bloom, and a thousand more after them.

Friction and Challenges

The Git Server

In #GitViaNostr, maintainers' branches (e.g., master) are hosted on a Git server. Here’s why this approach is beneficial:

• Follows the original Git vision and the "let Git be Git" philosophy.
• Super efficient, battle-tested, and compatible with all the ways people use Git (e.g., LFS, shallow cloning).
• Maintains compatibility with related systems without the need for plugins (e.g., for build and deployment).
• Only repository maintainers need write access.

In the original Git model, all users would need to add the Git server as a 'git remote.' However, with ngit, the Git server is hidden behind a Nostr remote, which enables:

• Hiding complexity from contributors and users, so that only maintainers need to know about the Git server component to start using #GitViaNostr.
• Maintainers can easily swap Git servers by updating their announcement event, allowing contributors/users using ngit to automatically switch to the new one.

Challenges with the Git Server

While the Git server model has its advantages, it also presents several challenges:

1. Initial Setup: When creating a new repository, maintainers must select a Git server, which can be a jarring experience. Most options come with bloated social collaboration features tied to a centralized PR model, often difficult or impossible to disable.

2. Manual Configuration: New repositories require manual configuration, including adding new maintainers through a browser UI, which can be cumbersome and time-consuming.

3. User Onboarding: Many Git servers require email sign-up or KYC (Know Your Customer) processes, which can be a significant turn-off for new users exploring a decentralized and permissionless alternative to GitHub.

Once the initial setup is complete, the system works well if a reliable Git server is chosen. However, this is a significant "if," as we have become accustomed to the excellent uptime and reliability of GitHub. Even professionally run alternatives like Codeberg can experience downtime, which is frustrating when CI/CD and deployment processes are affected. This problem is exacerbated when self-hosting.

Currently, most repositories on Nostr rely on GitHub as the Git server. While maintainers can change servers without disrupting their contributors, this reliance on a centralized service is not the decentralized dream we aspire to achieve.

Vision for the Git Server

The goal is to transform the Git server from a single point of truth and failure into a component similar to a Nostr relay.

Functionality Already in ngit to Support This

1. State on Nostr: Store the state of branches and tags in a Nostr event, removing reliance on a single server. This validates that the data received has been signed by the maintainer, significantly reducing the trust requirement.

2. Proxy to Multiple Git Servers: Proxy requests to all servers listed in the announcement event, adding redundancy and eliminating the need for any one server to match GitHub's reliability.

Implementation Requirements

To achieve this vision, the Nostr Git server implementation should:

1. Implement the Git Smart HTTP Protocol without authentication (no SSH) and only accept pushes if the reference tip matches the latest state event.

2. Avoid Bloat: There should be no user authentication, no database, no web UI, and no unnecessary features.

3. Automatic Repository Management: Accept or reject new repositories automatically upon the first push based on the content of the repository announcement event referenced in the URL path and its author.

Just as there are many free, paid, and self-hosted relays, there will be a variety of free, zero-step signup options, as well as self-hosted and paid solutions.

Some servers may use a Web of Trust (WoT) to filter out spam, while others might impose bandwidth or repository size limits for free tiers or whitelist specific npubs.

Additionally, some implementations could bundle relay and blossom server functionalities to unify the provision of repository data into a single service. These would likely only accept content related to the stored repositories rather than general social nostr content.

The potential role of CI / CD via nostr DVMs could create the incentives for a market of highly reliable free at the point of use git servers.

This could make onboarding #GitViaNostr repositories as easy as entering a name and selecting from a multi-select list of Git server providers that announce via NIP89.

!(image)[https://image.nostr.build/badedc822995eb18b6d3c4bff0743b12b2e5ac018845ba498ce4aab0727caf6c.jpg]

Git Client in the Browser

Currently, many tasks are performed on a Git server web UI, such as:

• Browsing code, commits, branches, tags, etc.
• Creating and displaying permalinks to specific lines in commits.
• Merging PRs.
• Making small commits and PRs on-the-fly.

Just as nobody goes to the web UI of a relay (e.g., nos.lol) to interact with notes, nobody should need to go to a Git server to interact with repositories. We use the Nostr protocol to interact with Nostr relays, and we should use the Git protocol to interact with Git servers. This situation has evolved due to the centralization of Git servers. Instead of being restricted to the view and experience designed by the server operator, users should be able to choose the user experience that works best for them from a range of clients. To facilitate this, we need a library that lowers the barrier to entry for creating these experiences. This library should not require a full clone of every repository and should not depend on proprietary APIs. As a starting point, I propose wrapping the WASM-compiled gitlib2 library for the web and creating useful functions, such as showing a file, which utilizes clever flags to minimize bandwidth usage (e.g., shallow clone, noblob, etc.).

This approach would not only enhance clients like gitworkshop.dev but also bring forth a vision where Git servers simply run the Git protocol, making vibe coding Git experiences even better.

song

nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 created song with a complementary vision that has shaped how I see the role of the git server. Its a self-hosted, nostr-permissioned git server with a relay baked in. Its currently a WIP and there are some compatability with ngit that we need to work out.

We collaborated on the nostr-permissioning approach now reflected in nip34.

I'm really excited to see how this space evolves.

CI/CD

Most projects require CI/CD, and while this is often bundled with Git hosting solutions, it is currently not smoothly integrated into #GitViaNostr yet. There are many loosely coupled options, such as Jenkins, Travis, CircleCI, etc., that could be integrated with Nostr.

However, the more exciting prospect is to use DVMs (Data Vending Machines).

DVMs for CI/CD

Nostr Data Vending Machines (DVMs) can provide a marketplace of CI/CD task runners with Cashu for micro payments.

There are various trust levels in CI/CD tasks:

• Tasks with no secrets eg. tests.
• Tasks using updatable secrets eg. API keys.
• Unverifiable builds and steps that sign with Android, Nostr, or PGP keys.

DVMs allow tasks to be kicked off with specific providers using a Cashu token as payment.

It might be suitable for some high-compute and easily verifiable tasks to be run by the cheapest available providers. Medium trust tasks could be run by providers with a good reputation, while high trust tasks could be run on self-hosted runners.

Job requests, status, and results all get published to Nostr for display in Git-focused Nostr clients.

Jobs could be triggered manually, or self-hosted runners could be configured to watch a Nostr repository and kick off jobs using their own runners without payment.

But I'm most excited about the prospect of Watcher Agents.

CI/CD Watcher Agents

AI agents empowered with a NIP60 Cashu wallet can run tasks based on activity, such as a push to master or a new PR, using the most suitable available DVM runner that meets the user's criteria. To keep them running, anyone could top up their NIP60 Cashu wallet; otherwise, the watcher turns off when the funds run out. It could be users, maintainers, or anyone interested in helping the project who could top up the Watcher Agent's balance.

As aluded to earlier, part of building a reputation as a CI/CD provider could involve running reliable hosting (Git server, relay, and blossom server) for all FOSS Nostr Git repositories.

This provides a sustainable revenue model for hosting providers and creates incentives for many free-at-the-point-of-use hosting providers. This, in turn, would allow one-click Nostr repository creation workflows, instantly hosted by many different providers.

Progress to Date

nostr:npub1hw6amg8p24ne08c9gdq8hhpqx0t0pwanpae9z25crn7m9uy7yarse465gr and nostr:npub16ux4qzg4qjue95vr3q327fzata4n594c9kgh4jmeyn80v8k54nhqg6lra7 have been working on a runner that uses GitHub Actions YAML syntax (using act) for the dvm-cicd-runner and takes Cashu payment. You can see example runs on GitWorkshop. It currently takes testnuts, doesn't give any change, and the schema will likely change.

Note: The actions tab on GitWorkshop is currently available on all repositories if you turn on experimental mode (under settings in the user menu).

It's a work in progress, and we expect the format and schema to evolve.

Easy Web App Deployment

For those disapointed not to find a 'Nostr' button to import a git repository to Vercel menu: take heart, they made it easy. vercel.com_import_options.png there is a vercel cli that can be easily called in CI / CD jobs to kick of deployments. Not all managed solutions for web app deployment (eg. netlify) make it that easy.

Many More Opportunities

Large Patches via Blossom

I would be remiss not to mention the large patch problem. Some patches are too big to fit into Nostr events. Blossom is perfect for this, as it allows these larger patches to be included in a blossom file and referenced in a new patch kind.

Enhancing the #GitViaNostr Experience

Beyond the large patch issue, there are numerous opportunities to enhance the #GitViaNostr ecosystem. We can focus on improving browsing, discovery, social and notifications. Receiving notifications on daily driver Nostr apps is one of the killer features of Nostr. However, we must ensure that Git-related notifications are easily reviewable, so we don’t miss any critical updates.

We need to develop tools that cater to our curiosity—tools that enable us to discover and follow projects, engage in discussions that pique our interest, and stay informed about developments relevant to our work.

Additionally, we should not overlook the importance of robust search capabilities and tools that facilitate migrations.

Concluding Thoughts

The design space is vast. Its an exciting time to be working on freedom tech. I encourage everyone to contribute their ideas and creativity and get vibe-coding!

I welcome your honest feedback on this vision and any suggestions you might have. Your insights are invaluable as we collaborate to shape the future of #GitViaNostr. Onward.

Contributions

To conclude, I want to acknowledge some the individuals who have made recent code contributions related to #GitViaNostr:

nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 (gitstr, song, patch34), nostr:npub1useke4f9maul5nf67dj0m9sq6jcsmnjzzk4ycvldwl4qss35fvgqjdk5ks (gitplaza)

nostr:npub1elta7cneng3w8p9y4dw633qzdjr4kyvaparuyuttyrx6e8xp7xnq32cume (ngit contributions, git-remote-blossom),nostr:npub16p8v7varqwjes5hak6q7mz6pygqm4pwc6gve4mrned3xs8tz42gq7kfhdw (SatShoot, Flotilla-Budabit), nostr:npub1ehhfg09mr8z34wz85ek46a6rww4f7c7jsujxhdvmpqnl5hnrwsqq2szjqv (Flotilla-Budabit, Nostr Git Extension), nostr:npub1ahaz04ya9tehace3uy39hdhdryfvdkve9qdndkqp3tvehs6h8s5slq45hy (gnostr and experiments), and others.

nostr:npub1uplxcy63up7gx7cladkrvfqh834n7ylyp46l3e8t660l7peec8rsd2sfek (git-remote-nostr)

Project Management nostr:npub1ltx67888tz7lqnxlrg06x234vjnq349tcfyp52r0lstclp548mcqnuz40t (kanbanstr) Code Snippets nostr:npub1ygzj9skr9val9yqxkf67yf9jshtyhvvl0x76jp5er09nsc0p3j6qr260k2 (nodebin.io) nostr:npub1r0rs5q2gk0e3dk3nlc7gnu378ec6cnlenqp8a3cjhyzu6f8k5sgs4sq9ac (snipsnip.dev)

CI / CD nostr:npub16ux4qzg4qjue95vr3q327fzata4n594c9kgh4jmeyn80v8k54nhqg6lra7 nostr:npub1hw6amg8p24ne08c9gdq8hhpqx0t0pwanpae9z25crn7m9uy7yarse465gr

and for their nostr:npub1c03rad0r6q833vh57kyd3ndu2jry30nkr0wepqfpsm05vq7he25slryrnw nostr:npub1qqqqqq2stely3ynsgm5mh2nj3v0nk5gjyl3zqrzh34hxhvx806usxmln03 and nostr:npub1l5sga6xg72phsz5422ykujprejwud075ggrr3z2hwyrfgr7eylqstegx9z for their testing, feedback, ideas and encouragement.

Thank you for your support and collaboration! Let me know if I've missed you.

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

@ c230edd3:8ad4a712

Chef's notes

I found this recipe on beyondsweetandsavory.com. The site is incredibly ad infested (like most recipe sites) and its very annoying so I'm copying it to Nostr so all the homemade ice cream people can access it without dealing with that mess. I haven't made it yet. Will report back, when I do.

Details

• ⏲️ Prep time: 20 min
• 🍳 Cook time: 55 min
• 🍽️ Servings: 8

Ingredients

• 2 cups heavy cream
• 1 cup 2% milk
• 8 oz dark chocolate, 70%
• ¼ cup Dutch cocoa
• 2 tbsps loose Earl grey tea leaves
• 4 medium egg yolks
• ¾ cup granulated sugar
• ⅛ tsp salt
• ¼ cup dark chocolate, 70% chopped

Directions

1. In a double boiler or a bowl set over a saucepan of simmering water, add the cacao solids and ½ cup of heavy cream. Stir chocolate until melted and smooth. Set melted chocolate aside.
2. In a heavy saucepan, combine remaining heavy cream, milk, salt and ½ cup of sugar.
3. Put the pan over medium heat and let the mixture boil gently to bubbling just around the edges (gentle simmer) and sugar completely dissolved, about 5 minutes. Remove from heat.
4. Add the Earl Grey tea leaves and let it steep for 7-8 minutes until the cream has taken on the tea flavor, stirring occasionally and tasting to make sure it’s not too bitter.
5. Whisk in Dutch cocoa until smooth. Add in melted chocolate and whisk until smooth.
6. In a medium heatproof bowl, whisk the yolks just to break them up and whisk in remaining sugar. Set aside.
7. Put the saucepan back on the stove over low heat and let it warm up for 2 minutes.
8. Carefully measure out ½ cup of hot cream mixture.
9. While whisking the eggs constantly, whisk the hot cream mixture into the eggs until smooth. Continue tempering the eggs by adding another ½ cup of hot cream to the bowl with the yolks.
10. Pour the cream-egg mixture back to the saucepan and cook over medium-low heat, stirring constantly until it is thickened and coats the back of a spatula, about 5 minutes.
11. Strain the base through a fine-mesh strainer into a clean container.
12. Pour the mixture into a 1-gallon Ziplock freezer bag and submerge the sealed bag in an ice bath until cold, about 30 minutes. Refrigerate the ice cream base for at least 4 hours or overnight.
13. Pour the ice cream base into the frozen canister of your ice cream machine and follow the manufacturer’s instructions.
14. Spin until thick and creamy about 25-30 minutes.
15. Pack the ice cream into a storage container, press a sheet of parchment directly against the surface and seal with an airtight lid. Freeze in the coldest part of your freezer until firm, at least 4 hours.
16. When ready to serve, scoop the ice cream into a serving bowl and top with chopped chocolate.

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

@ 1739d937:3e3136ef

MLS over Nostr - 30th April 2025

YO! Exciting stuff in this update so no intro, let's get straight into it.

🚢 Libraries Released

I've created 4 new Rust crates to make implementing NIP-EE (MLS) messaging easy for other projects. These are now part of the rust-nostr project (thanks nostr:npub1drvpzev3syqt0kjrls50050uzf25gehpz9vgdw08hvex7e0vgfeq0eseet) but aren't quite released to crates.io yet. They will be included in the next release of that library. My hope is that these libraries will give nostr developers a simple, safe, and specification-compliant way to work with MLS messaging in their applications.

Here's a quick overview of each:

nostr_mls_storage

One of the challenges of using MLS messaging is that clients have to store quite a lot of state about groups, keys, and messages. Initially, I implemented all of this in White Noise but knew that eventually this would need to be done in a more generalized way.

This crate defines traits and types that are used by the storage implementation crates and sets those up to wrap the OpenMLS storage layer. Now, instead of apps having to implement storage for both OpenMLS and Nostr, you simply pick your storage backend and go from there.

Importantly, because these are generic traits, it allows for the creation of any number of storage implementations for different backend storage providers; postgres, lmdb, nostrdb, etc. To start I've created two implementations; detailed below.

nostr_mls_memory_storage

This is a simple implementation of the nostr_mls_storage traits that uses an in-memory store (that doesn't persist anything to disc). This is principally for testing.

nostr_mls_sqlite_storage

This is a production ready implementation of the nostr_mls_storage traits that uses a persistent local sqlite database to store all data.

nostr_mls

This is the main library that app developers will interact with. Once you've chose a backend and instantiated an instance of NostrMls you can then interact with a simple set of methods to create key packages, create groups, send messages, process welcomes and messages, and more.

If you want to see a complete example of what the interface looks like check out mls_memory.rs.

I'll continue to add to this library over time as I implement more of the MLS protocol features.

🚧 White Noise Refactor

As a result of these new libraries, I was able to remove a huge amount of code from White Noise and refactor large parts of the app to make the codebase easier to understand and maintain. Because of this large refactor and the changes in the underlying storage layer, if you've installed White Noise before you'll need to delete it from your device before you trying to install again.

🖼️ Encrypted Media with Blossom

Let's be honest: Group chat would be basically useless if you couldn't share memes and gifs. Well, now you can in White Noise. Media in groups is encrypted using an MLS secret and uploaded to Blossom with a one-time use keypair. This gives groups a way to have rich conversations with images and documents and anything else while also maintaining the privacy and security of the conversation.

This is still in a rough state but rendering improvements are coming next.

📱 Damn Mobile

The app is still in a semi-broken state on Android and fully broken state on iOS. Now that I have the libraries released and the White Noise core code refactored, I'm focused 100% on fixing these issues. My goal is to have a beta version live on Zapstore in a few weeks.

🧑‍💻 Join Us

I'm looking for mobile developers on both Android and iOS to join the team and help us build the best possible apps for these platforms. I have grant funding available for the right people. Come and help us build secure, permissionless, censorship-resistant messaging. I can think of few projects that deserve your attention more than securing freedom of speech and freedom of association for the entire world. If you're interested or know someone who might be, please reach out to me directly.

🙏 Thanks to the People

Last but not least: A HUGE thank you to all the folks that have been helping make this project happen. You can check out the people that are directly working on the apps on Following._ (and follow them). There are also a lot of people behind the scenes that have helped in myriad ways to get us this far. Thank you thank you thank you.

🔗 Links

Libraries

• nostr_mls
• nostr_mls_storage
• nostr_mls_memory_storage
• nostr_mls_sqlite_storage

White Noise

• White Noise Repo
• White Noise Releases

Other

• Previous updates

@ 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 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;
• a Spacechain itself, serving only as the storage for a bunch of OP_RETURNs 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
• The Lightning Network solves the problem of the decentralized commit

@ 4e616576:43c4fee8

asdfasdfsadfaf

@ 4e616576:43c4fee8

asdfasdf

@ 3bf0c63f:aefa459d

There's a problem with using Git concepts for everything

We've been seeing a surge in applications that use Git to store other things than code, or that are based on Git concepts and so enable "forking, merging and distributed collaboration" for things like blogs, recipes, literature, music composition, normal files in a filesystem, databases.

The problem with all this is they will either:

1. assume the user will commit manually and expect that commit to be composed by a set of meaningful changes, and the commiter will also add a message to the commit, describing that set of meaningful, related changes; or
2. try to make the committing process automatic and hide it from the user, so will producing meaningless commits, based on random changes in many different files (it's not "files" if we are talking about a recipe or rows in a table, but let's say "files" for the sake of clarity) that will probably not be related and not reduceable to a meaningful commit message, or maybe the commit will contain only the changes to a single file, and its commit message would be equivalent to "updated <name of the file>".

Programmers, when using Git, think in Git, i.e., they work with version control in their minds. They try hard to commit together only sets of meaningful and related changes, even when they happen to make unrelated changes in the meantime, and that's why there are commands like git add -p and many others.

Normal people, to whom many of these git-based tools are intended to (and even programmers when out of their code-world), are much less prone to think in Git, and that's why another kind of abstraction for fork-merge-collaborate in non-code environments must be used.

@ 3bf0c63f:aefa459d

Custom spreadsheets

The idea was to use it to make an app that would serve as custom database for everything and interact with the spreadsheet so people could play and calculate with their values after they were created by the custom app, something like an MS Access integrated with Excel?

My first attempt that worked (I believe there was an attempt before but I have probably deleted it from everywhere) was this react-microspreadsheet thing (at the time called react-spreadsheet before I donated the npm name to someone who asked):

• https://github.com/fiatjaf/react-microspreadsheet

This was a very good spreadsheet component that did many things current "react spreadsheet" components out there don't do. It had formulas; support for that handle thing that you pulled with the mouse and it autofilled cells with a pattern; it had keyboard navigation with Ctrl, Shift, Ctrl+Shift; it had that thing through which you copy-pasted formulas and they would change their parameters depending on where you pasted them (implemented in a very poor manner because I was using and thinking about Excel in baby mode at the time).

Then I tried to make it into "a small sheet you can share" kind of app through assemblymade.com, and eventually as I tried to add more things bugs began to appear.

Then there was cycle6-spreadsheet:

• https://github.com/fiatjaf/spreadsheet-cycle6

If I remember well this was very similar to the other one, although made almost 2 years after. Despite having the same initial goal of the other (the multi-app custom database thing) it only yielded:

• Sidesheet, a Chrome extension that opened a spreadsheet on the side of the screen that you could use to make calculations and so on. It worked, but had too many bugs that probably caused me to give up entirely.

I'm not sure which of the two spreadsheets above powers http://sheets.alhur.es.

@ 3bf0c63f:aefa459d

P2P reputation thing

Each node shares a blob of the reputations they have, which includes a confidence number. The number comes from the fact that reputations are inherited from other nodes they trust and averaged by their confidence in these. Everything is mixed for plausible deniability. By default a node only shares their stuff with people they manually add, to prevent government from crawling everybody's database. Also to each added friend nodes share a different identity/pubkey (like giving a new Bitcoin address for every transaction) (derived from hip32) (and since each identity can only be contacted by one other entity the node filters incoming connections to download their database: "this identity already been used? no, yes, used with which peer?").

Network protocol

Maybe the data uploader/offerer initiates connection to the receiver over Tor so there's only a Tor address for incoming data, never an address for a data source, i.e. everybody has an address, but only for requesting data.

How to request? Post an encrypted message in an IRC room or something similar (better if messages are stored for a while) targeted to the node/identity you want to download from, along with your Tor address. Once the node sees that it checks if you can download and contacts you.

The encrypted messages could have the target identity pubkey prefix such that the receiving node could try to decrypt only some if those with some probability of success.

Nodes can choose to share with anyone, share only with pre-approved people, share only with people who know one of their addresses/entities (works like a PIN, you give the address to someone in the street, that person can reach you, to the next person you give another address etc., you can even have a public address and share limited data with that).

Data model

Each entry in a database should be in the following format:

internal_id : real_world_identifier [, real_world_identifier...] : tag

Which means you can either associate one or multiple real world identifier with an internal id and associate the real person designated by these identifiers with a tag. the tag should be part of the standard or maybe negotiated between peers. it can be things like scammer, thief, tax collector etc., or honest, good dentist etc. defining good enough labels may be tricky.

internal_id should be created by the user who made the record about the person.

At first this is not necessary, but additional bloat can be added to the protocol if the federated automated message posting boards are working in the sense that each user can ask for more information about a given id and the author of that record can contact the person asking for information and deliver free text to them with the given information. For this to work the internal id must be a public key and the information delivered must be signed with the correspondent private key, so the receiver of the information will know it's not just some spammer inventing stuff, but actually the person who originated that record.

@ 3bf0c63f:aefa459d

gravity

IPFS is nice as a personal archiving tool (edit: it's not). You store a bunch of data and make it available to the public.

The problem is that no one will ever know you have that data, therefore you need a place to publish it somewhere. Gravity was an attempt of being the tool for this job.

It was a website that showcased the collections from users, and it was also a command-line client that used your IPFS keys for authentication and allowed you to paste IPFS URIs and names and descriptions.

The site was intended to be easy to run so you could have multiple stellar bodies aggregating content and interact with them all in a standardized manner.

It also had an ActivityPub/"fediverse" integration so people could follow Gravity server users from Mastodon and friends and see new data they published as "tweets".

• https://github.com/fiatjaf/gravity

See also

• How IPFS is broken
• litepub

@ 4e616576:43c4fee8

asdffasdf

@ 3bf0c63f:aefa459d

TiddlyWiki remoteStorage

TiddlyWiki is very good and useful, but since at this time I used multiple computers during the week, it wouldn't work for me to use it as a single file on my computer, so I had to hack its internal tiddler saving mechanism to instead save the raw data of each tiddler to remoteStorage and load them from that place also (ok, there was in theory a plugin system, but I had to read and understand the entire unformatted core source-code anyway).

There was also a server that fetched tiddlywikis from anyone's remoteStorage buckets (after authorization) and served these to the world, a quick and nice way to publish a TiddlyWiki -- which is a problem all people in TiddlyWiki struggle against.

• https://github.com/fiatjaf/tiddlywiki-remotestorage
• https://tiddly.alhur.es/

See also

• hledger-web
• LessPass remoteStorage

@ 4e616576:43c4fee8

asdfasdfasfd

@ e096a89e:59351479

Why Oshi?

I had another name for this brand before, but it was hard for folks to say. Then I saw a chance to tap into the #Nostr and #Bitcoin crowd, people who might vibe with what I’m creating, and I knew I needed something that’d stick.

A good name can make a difference. Well, sometimes. Take Blink-182 - it might sound odd, but it worked for them and even has a ring to it. So, why Oshi?

Names mean a lot to me, and Oshi’s got layers. I’m into Japanese culture and Bitcoin, so it fits perfectly with a few meanings baked in:

• It’s a nod to Bitcoin’s visionary, Satoshi Nakamoto.
• In Japanese, “oshi” means cheering on your favorite idol by supporting their work - think of me as the maker, you as the fan.
• It’s short for “oh shiiiitttt” - what most folks say when they taste how good this stuff is.

My goal with Oshi is to share how amazing pecans and dates can be together. Everything I make - Hodl Butter, Hodl Bars, chocolates - is crafted with intention, keeping it simple and nuanced, no overdoing it. It’s healthy snacking without the grains or junk you find in other products.

I’ve got a few bars and jars in stock now. Grab something today and taste the unique flavor for yourself. Visit my website at https://oshigood.us/

foodstr #oshigood #hodlbar #hodlbutter

@ 3bf0c63f:aefa459d

Democracia na América

Alexis de Tocqueville escreveu um livro só elogiando o sistema político dos Estados Unidos. E mesmo tendo sido assim, e mesmo tendo escrito o seu livro quase 100 anos antes do mais precoce sinal de decadência da democracia na América, percebeu coisas que até hoje quase ninguém percebe: o mandato da suprema corte é um enorme poder, uma força centralizadora, imune ao voto popular e com poderes altamente indefinidos e por isso mesmo ilimitados.

Não sei se ele concluiu, porém, que não existe nem pode existir balanço perfeito entre poderes. Sempre haverá furos.

De qualquer maneira, o homem é um gênio apenas por ter percebido isso e outras coisas, como o fato da figura do presidente, também obviamente um elemento centralizador, não ser tão poderosa quanto a figura de um rei da França, por exemplo. Mas ao mesmo tempo, por entre o véu de elogios (sempre muito sóbrios) deixou escapar que provavelmente também achava que não poderia durar para sempre a fraqueza do cargo de presidente.

• Democracy as a failed open-network protocol
• Família e propriedade
• Liberalismo oitocentista

@ 4e616576:43c4fee8

sdfafd

@ 3589b793:ad53847e

※本記事は別サービスで2022年6月24日に公開した記事の移植です。

どうも、「NostrはLNがWeb統合されマネーのインターネットプロトコルとしてのビットコインが本気出す具体行動のショーケースと見做せばOK」です、こんばんは。

またまた実験的な試みがNostrで行われているのでレポートします。本シリーズはライブ感を重視しており、例によって（？）プルリクエストなどはレビュー段階なのでご承知おきください。

今回の主役はあくまでLightningNetworkの新提案（ただし以前からあるLSATからのリブランディング）となるLightning HTTP 402 Protocol（略称: L402）です。そのショーケースの一つとしてNostrが活用されているというものになります。

Lightning HTTP 402 Protocol（略称: L402）とは何か

bLIPに今月挙がったプロポーザル内容です。

https://github.com/lightning/blips/pull/26

L402について私はまだ完全に理解した段階ではあるのですがなんとか一言で説明しようとすると「Authトークンのように"Paid"トークンをHTTPヘッダーにアタッチして有料リソースへのHTTPリクエストの受け入れ判断を行えるようにする」ものだと解釈しました。

Authenticationでは、HTTPヘッダーにAuthトークンを添付し、その検証が通ればHTTPリクエストを許可し、通らなければ401 Unauthorizedコードをエラーとして返すように定められています。

https://developer.mozilla.org/ja/docs/Web/HTTP/Status/401

L402では、同じように、HTTPヘッダーに支払い済みかどうかを示す"Paid"トークンを添付し、その検証が通ればHTTPリクエストを許可し、通らなければ402 Payment Requiredコードをエラーとして返すようにしています。

なお、"Paid"トークンという用語は私の造語となります。便宜上本記事では使わせていただきますが、実際はAuthも入ってくるのが必至ですし、プルリクエストでも用語をどう定めるかは議論になっていることをご承知おきください。（"API key", "credentials", "token", らが登場しています）

この402ステータスコードは従来から定義されていましたが、MDNのドキュメントでも記載されているように「実験的」なものでした。つまり、器は用意されているがこれまで活用されてこなかったものとなり、本プロトコルの物語性を体現しているものとなります。

https://developer.mozilla.org/ja/docs/Web/HTTP/Status/402

幻であったHTTPステータスコード402 Payment Requiredを実装する

この物語性は、上述のbLIPのスペックにも詳述されていますが、以下のスライドが簡潔です。402 Payment Requiredは予約されていましたが、けっきょくのところWorldWideWebはペイメントプロトコルを実装しなかったので、Bitcoinの登場まで待つことになった、というのが要旨になります。このWorldWideWebにおける決済機能実装に関する歴史話はクリプト界隈でもたびたび話題に上がりますが、そこを繋いでくる文脈にこれこそマネーのインターネットプロトコルだなと痺れました。

https://x.com/AlyseKilleen/status/1671342634307297282

この"Paid"トークンによって実現できることとして、第一にAIエージェントがBitcoin/LNを自律的に利用できるようになるM2M(MachineToMachine)的な話が挙げられていますが、ユースケースは想像力がいろいろ要るところです。実際のところは「有料リソースへの認可」を可能にすることが主になると理解しました。本連載では、繰り返しNostrクライアントにLNプロトコルを直接搭載せずにLightningNetworkを利用可能にする組み込み方法を見てきましたが、本件もインボイス文字列 & preimage程度の露出になりアプリケーション側でノードやウォレットの実装が要らないので、その文脈で位置付ける解釈もできるかと思います。

Snortでのサンプル実装

LN組み込み業界のリーディングプロダクトであるSnortのサンプル実装では、L402を有料コンテンツの購読に活用しています。具体的には画像や動画を投稿するときに有料のロックをかける、いわゆるペイウォールの一種となります。もともとアップローダもSnortが自前で用意しているので、そこにL402を組み込んでみたということのようです。

体験方法の詳細はこちらにあります。 https://njump.me/nevent1qqswr2pshcpawk9ny5q5kcgmhak24d92qzdy98jm8xcxlgxstruecccpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszrnhwden5te0dehhxtnvdakz78pvlzg

上記を試してみた結果が以下になります。まず、ペイウォールでロックした画像がNostrに投稿されている状態です。まったくビューワーが実装されておらず、ただのNotFound状態になっていますが、支払い前なのでロックされているということです。

次にこのHTTP通信の内容です。

通信自体はエラーになっているわけですが、ステータスコードが402で、レスポンスヘッダーのWWW-AuthenticateにInvoice文字列が返ってきています。つまり、このインボイスを支払えば"Paid"トークンが付与されて、その"Paid"トークンがあれば最初の画像がアンロックされることとなります。残念ながら現在は日本で利用不可のStrikeAppでしか払込みができないためここまでとなりますが、本懐である402 Payment Requiredとインボイス文字列は確認できました。

今確認できることは以上ですが、AmethystやDamusなどの他のNostrクライアントが実装するにあたり、インラインメディアを巡ってL402の仕様をアップデートする必要性や同じくHTTPヘッダーへのAuthトークンとなるNIP-98と組み合わせるなどの議論が行われている最中です。

LinghtningNetworkであるからこそのL402の実現

"Paid"トークンを実現するためにはLightningNetworkのファイナリティが重要な要素となっています。逆に言うと、reorgによるひっくり返しがあり得るBitcoinではできなくもないけど不便なわけです。LightningNetworkなら、当事者である二者間で支払いが確認されたら「同期的」にその証であるハッシュ値を用いて"Paid"トークンを作成することができます。しかもハッシュ値を提出するだけで台帳などで過去の履歴を確認する必要がありません。加えて言うと、受金者側が複数のノードを建てていて支払いを受け取るノードがどれか一つになる状況でも、つまり、スケーリングされている状況でも、"Paid"トークンそのものはどのノードかを気にすることなくステートレスで利用できるとのことです。（ここは単にreverse proxyとしてAuthサーバががんばっているだけと解釈することもできますがずいぶんこの機能にも力点を置いていて大規模なユースケースが重要になっているのだなという印象を抱きました）

Macaroonの本領発揮か？それとも詳細定義しすぎか？

HTTP通信ではWWW-Authenticateの実値にmacaroonの記述が確認できます。また現在のL402スペックでも"Paid"トークンにはmacaroonの利用が前提になっています。

このmacaroonとは（たぶん）googleで研究開発され、LNDノードソフトウェアで活用されているCookieを超えるという触れ込みのデータストアになります。しかし、あまり普及しなかった技術でもあり、個人の感想ですがなんとも微妙なものになっています。

https://research.google/pubs/macaroons-cookies-with-contextual-caveats-for-decentralized-authorization-in-the-cloud/

macaroonの強みは、Cookieを超えるという触れ込みのようにブラウザが無くてもプロセス間通信でデータ共有できる点に加えて、HMACチェーンで動的に認証認可を更新し続けられるところが挙げられます。しかし、そのようなユースケースがあまり無く、静的な認可となるOAuthやJWTで十分となっているのが現状かと思います。

L402では、macaroonの動的な更新が可能である点を活かして、"Paid"トークンを更新するケースが挙げられています。わかりやすいのは上記のスライド資料でも挙げられている"Dynamic Pricing"でしょうか。プロポーザルではloop©️LightningLabsにおいて月間の最大取引量を認可する"Paid"トークンを発行した上でその条件を動向に応じて動的に変更できる例が解説されています。とはいえ、そんなことしなくても再発行すればええやんけという話もなくもないですし、プルリクエストでも仕様レベルでmacaroonを指定するのは「具体」が過ぎるのではないか、もっと「抽象」し単なる"Opaque Token"程度の粒度にして他の実装も許容するべきではないか、という然るべきツッコミが入っています。

個人的にはそのツッコミが妥当と思いつつも、なんだかんだ初めてmacaroonの良さを実感できて感心した次第です。

@ 3589b793:ad53847e

※本記事は別サービスで2023年4月19日に公開した記事の移植です。

どうも、「NostrはLNがWeb統合されマネーのインターネットプロトコルとしてのビットコインが本気出す具体行動のショーケースと見做せばOK」です、こんにちは。

前回まで投げ銭や有料購読の組み込み方法を見てきました。

zapsという投げ銭機能が各種クライアントに一通り実装されて活用が進んでいることで、統合は次の段階へ移り始めています。「作戦名: ウォレットをNostrクライアントに組み込め」です。今回はそちらをまとめます。

投げ銭する毎にいちいちウォレットを開いてまた元のNostrクライアントに手動で戻らないといけない is PAIN

LNとNostrはインボイス文字列で繋がっているだけの疎結合ですが、投稿に投げ銭するためには何かのLNウォレットを開いて支払いをして、また元のNostrクライアントに戻る操作をユーザーが手作業でする必要があります。お試しで一回やる程度では気になりませんが普段使いしているとこれはけっこうな煩わしさを感じるUXです。特にスマホでは大変にだるい状況になります。連打できない！

2月の実装以来、zapsは順調に定着して日々投げられています。

https://stats.nostr.band/#daily_zaps

なので、NostrクライアントにLNウォレットの接続を組み込み、支払いのために他のアプリに遷移せずにNostクライアント単独で完結できるようなアップデートが始まっています。

Webクライアント

NostrのLN組み込み業界のリーディングプレイヤーであるSnortでの例です。以下のようにヘッダーのウォレットアイコンをクリックすると連携ウォレットの選択ができます。

もともとNostrに限らずウェブアプリケーションとの連携をするために、WebLNという規格があります。簡単に言うと、ブラウザのグローバル領域を介して、LNウォレットの拡張機能と、タブで開いているウェブアプリが、お互いに連携するためのインターフェースを定めているものです。これに対応していると、LNによる支払いをウェブアプリが拡張機能に依頼できるようになります。さらにオプションで「確認無し」をオンにすると、拡張機能画面がポップアップせずにバックグラウンドで実行できるようになり、ノールック投げ銭ができるようになります。

似たようなものにNostrではNIP-07があります。NIP-07はNostrの秘密鍵を拡張機能に退避して、Nostrクライアントは秘密鍵を知らない状態で署名や複合を拡張機能に移譲できるようにしているものです。

Albyの拡張機能ではWebLNとNIP-07のどちらにも対応しています。

実はSnortはzapsが来る前からWebLNには対応していたのですが、さらに一歩進み、拡張機能ウォレットだけでなく、LNノードや拡張機能以外のLNウォレットと連携設定できるようになってきています。

umbrelなどでノードを立てている人ならLND with LNCでノードと直接繋げます。またLNDHubに対応したウォレットなどのアプリケーションとも繋げます。これらの接続は、WebLNにラップされて拡張機能ウォレットとインターフェースを揃えられた上で、Snort上でのインボイスの支払いに活用されます。

なお、LNCのpairingPhrase/passwordやLNDHubの接続情報などのクレデンシャルは、ブラウザのローカルストレージに保存されています。Nostrのリレーサーバなどには送られませんので、端末ごとに設定が必要です。

スマホアプリ

今回のメインです。なお、例によって（？）スペックは絶賛議論中でまだフィックスしていない中で記事を書いています。ディテールは変わるかもしれないので悪しからずです。

スマホアプリで上記のことをやるためには、後半のLNCやLNDHubはすでにzeusなどがやっているようにできますが、あくまでネイティブウォレットのラッパーです。Nostrでは限られた用途になるので1-click支払いのようなものを行うためにはそこから各スマホアプリが作り込む必要があります。まあこれはこれでやればいいという話でもあるのですが、LNノードやLNウォレットのアプリケーション側へのインターフェースの共通仕様は定められていないので、LNDとcore-lightningとeclairではすべて実装方法が違いますし、ウォレットもバラバラなので大変です。

そこで、多種多様なノードやウォレットの接続を取りまとめ一般アプリケーションへ統一したインターフェースを媒介するLN Adapter業界のリーディングカンパニーであるAlbyが動きました。AndroidアプリのAmethystで試験公開されていますが、スマホアプリでも上記のSnortのような連携が可能になるようなSDKが開発されました。

リリース記事 https://blog.getalby.com/native-zapping-in-amethyst/

"Unstoppable zapping for users"なんて段落見出しが付けられているように、スマホで別のアプリに切り替えてまた元に戻らなくても良いようにして、Nostr上でマイクロペイメントを滑らかにする、つまり、連打できることを繰り返し強調しています。

具体的にやっていることを見ていきます。以下の画像群はリリース記事の動画から抜粋しています。各投稿のzapsボタン⚡️をタップしたときの画面です。

上の赤枠が従来の投げ銭の詳細を決める場所で、下の赤枠の「Wallet Connect Service」が新たに追加されたAlby提供のSDKを用いたコネクト設定画面です。基本的にはOAuth2.0ベースのAlbyのAPIを活用していて、右上のAlbyアイコンをタップすると以下のようなOAuthの認可画面に飛びます。（ただし後述するように通常のOAuthとは一部異なります。）

画面デザインは違いますが、まあ他のアプリでよく目にするTwitter連携やGoogleアカウント連携とやっていることは同じです。

このOAuthベースのAPIはNostr専用のエンドポイントが建てられています。Nostr以外のECショップやマーケットプレイスなどへのAlbyのOAuthは汎用のエンドポイントが用意されています。よって通常のAlbyの設定とは別にセッション詳細を以下のサイトで作成する必要があります。

https://nwc.getalby.com/ （サブドメインのnwcはNostr Wallet Connectの略）

なぜNostrだけは特別なのかというところが完全には理解しきれていないですが、以下のところまで確認できています。一番にあるのは、Nostrクライアントにウォレットを組み込まずに、かつ、ノードやウォレットへの接続をNostrリレーサーバ以外は挟まずに"decentralized"にしたいというところだと理解しています。

• 上記のnwcのURLはalbyのカストディアルウォレットusername@getalby.comをNostrに繋ぐもの（たぶん）
• umbrelのLNノードを繋ぐためにはやはり専用のアプリがumbrelストアに上がっている。https://github.com/getAlby/umbrel-community-app-store
• 要するにOAuthの1stPartyの役割をウォレットやノードごとにそれぞれ建てる。
• OAuthのシークレットはクライアントに保存するので設定は各クライアント毎に必要。しかし使い回しすることは可能っぽい。通常のOAuthと異なり、1stParty側で3rdPartyのドメインはトラストしていないようなので。
• Nostrクライアントにウォレットを組み込まずに、さらにウォレットやノードへの接続をNostrリレーサーバ以外には挟まなくて良いようにするために、「NIP-47 Nostr Wallet Connect」というプロポーザルが起こされていて、絶賛議論中である。https://github.com/nostr-protocol/nips/pull/406
• このWallet Connect専用のアドホックなリレーサーバが建てられる。その情報が上記画像の赤枠の「Wallet Connect Service」の下半分のpub keyやらrelayURL。どうもNostrクライアントはNIP-47イベントについてはこのリレーサーバにしか送らないようにするらしい。（なんかNostrの基本設計を揺るがすユースケースの気がする...）
• Wallet Connect専用のNostrイベントでは、ペイメント情報をNostrアカウントと切り離すために、Nostrの秘密鍵とは別の秘密鍵が利用できるようにしている。

Imagin the Future

今回取り上げたNostrクライアントにウォレット接続を組み込む話を、Webのペイメントの歴史で類推してみましょう。

Snortでやっていることは、各サイトごとにクレジットカードを打ち込み各サイトがその情報を保持していたようなWeb1.0の時代に近いです。そうなるとクレジットカードの情報は各サービスごとに漏洩リスクなどがあり、Web1.0の時代はECが普及する壁の一つになっていました。（今でもAmazonなどの大手はそうですが）

Webではその後にPayPalをはじめとして、銀行口座やクレジットカードを各サイトから切り出して一括管理し、各ウェブサイトに支払いだけを連携するサービスが出てきて一般化しています。日本ではケータイのキャリア決済が利用者の心理的障壁を取り除きEC普及の後押しになりました。

後半のNostr Wallet ConnectはそれをNostrの中でやろうとしている試みになります。クレジットカードからLNに変える理由はビットコインの話になるので詳細は割愛しますが、現実世界の金（ゴールド）に類した価値保存や交換ができるインターネットマネーだからです。

とはいえ、Nostrの中だけならまだしも、これをNostr外のサービスで利用するためには、他のECショップやブログやSaaSがNostrを喋れる必要があります。そんな未来が来るわけないだろと思うかもしれませんが、言ってみればStripeはまさにそのようなサービスとなっていて、サイト内にクレジット決済のモジュールを組み込むための主流となっています。

果たして、Nostrを、他のECショップやブログやSaaSが喋るようになるのか！？

以上、「NostrはLNがWeb統合されマネーのインターネットプロトコルとしてのビットコインが本気出す具体行動のショーケースと見做せばOK」がお送りしました。

@ 3589b793:ad53847e

前回の続きです。

特に「Snortで試験的にノート単位に投げ銭できる機能」について。実は記事書いた直後にリリースされて慌ててw追記してたんですが追い付かないということで別記事にしました。

今回のここがすごい！

「Snortで試験的にノート単位に投げ銭できる機能」では一つブレイクスルーが起こっています。それは「ウォレットにインボイスを放り投げた後に払い込み完了を提示できる」ようになったことです。これによりペイメントのライフサイクルが一通りカバーされたことになります。

Snortの画面

なにを当たり前のことをという向きもあるかもしれませんが、Nostrクライアントで払い込み完了を追跡することはとても難しいです。基本的にNostrとLNウォレットはまったく別のアプリケーションで両者の間を繋ぐのはインボイス文字列だけです。ウォレットもNostrからキックされずに、インボイス文字列をコピペするなりQRコードで読み取ったものを渡されるだけかもしれません。またその場でリアルタイムに処理される前提もありません。

なのでNostrクライアントでその後をトラックすることは難しく、これまではあくまで請求書を送付したり（LNインボイス）振り込み口座を提示する（LNアドレス）という一方的に放り投げてただけだったわけです。といっても魔法のようにNostrクライアントがトラックできるようになったわけではなく、今回の対応方法もインボイスを発行/お金を振り込まれるサービス側（LNURL）にNostrカスタマイズを入れさせるというものになります。

プロポーザルの概要について

前回の記事ではよくわからんで終わっていましたが、当日夜（日本時間）にスペックをまとめたプロポーザルも起こされました（早い！）。LNURLが、Nostr用のインボイスを発行して、さらにNostrイベントの発行を行っていることがポイントでした。名称は"Lightning Zaps"で確定のようです。プロポーザルは、NostrとLNURLの双方の発明者であるfiatjaf氏からツッコミが入り、またそれが妥当な指摘のために、エンドポイントURLのインターフェースなどは変わりそうなのですが、概要はそう変わらないだろうということで簡単にまとめてみます。

全体の流れ

図は、Nostrクライアント上に提示されているLNアドレスへ投げ銭が開始してから、Nostrクライアント上に払い込み完了したイベントが表示されるまでの流れを示しています。

1. 投げ銭の内容が固まったらNostrイベントデータを添付してインボイスの発行を依頼する
2. 説明欄にNostr用のデータを記載したインボイスを発行して返却する
3. Nostrクライアントで提示されたインボイスをユーザーが何かしらの手段でウォレットに渡す
4. ウォレットがLNに支払いを実行する
5. インボイスの発行者であるLNURLが管理しているLNノードにsatoshiが届く
6. LNURLサーバが投げ銭成功のNostrイベントを発行する
7. Nostrクライアントがイベントを受信して投げ銭履歴を表示する

特にポイントとなるところを補足します。

対応しているLNアドレスの識別

LNアドレスに投げ銭する場合は、LNアドレスの有効状態やインボイス発行依頼する先の情報をhttps://[domain]/.well-known/lnurlp/[username]から取得しています。そのレスポンス内容にNostr対応を示す情報を追加しています。ただし、ここに突っ込み入っていてlnurlp=LNURL Payから独立させるためにzaps専用のエンドポイントに変わりそうです。（2/15 追記　マージされましたが変更無しでした。PRのディスカッションが盛り上がっているので興味ある方は覗いてみてください。）

インボイスの説明欄に書き込むNostrイベント（kind:9734）

これは投げ銭する側のNostrイベントです。投げ銭される者や対象ノートのIDや金額、そしてこのイベントを作成している者が投げ銭したということを「表明」するものになります。表明であって証明でないところは、インボイスを別の人が払っちゃう事態がありえるからですね。この内容をエンクリプトするパターンも用意されていたが複雑になり過ぎるという理由で今回は外され追加提案に回されました。また、このイベントはデータを作成しただけです。支払いを検知した後にLNURLが発行するイベントに添付されることになります。そのため投げ銭する者にちゃんと届くように作成者のリレーサーバリストも書き込まれています。

支払いを検知した後に発行するNostrイベント（kind:9735）

これが実際にNostrリレーサーバに発行されるイベントです。LNURL側はウォッチしているLNノードにsatoshiが届くと、インボイスの説明欄に書かれているNostrイベントを取り出して、いわば受領イベントを作成して発行します。以下のようにNostイベントのkind:9734とkind:9735が親子になったイベントとなります。

json { "pubkey": "LNURLが持っているNostrアカウントの公開鍵", "kind": 9735, "tags": [ [ "p", "投げ銭された者の公開鍵" ], [ "bolt11", "インボイスの文字列lnbc〜" ], [ "description", "投げ銭した者が作成したkind:9734のNostrイベント" ], [ "preimage", "インボイスのpreimage" ] ], }

所感

とにかくNostrクライアントはLNノードを持たないしLNプロトコルとも直接喋らずにインボイス文字列だけで取り扱えるようになっているところがおもしろいと思っています。NostrとLNという二つのデセントライズドなオープンプロトコルが協調できていますし、前回も述べましたがどんなアプリでも簡単に真似できます。

とはいえ、さすがに払込完了のトラックは難しく、今回はLNURL側にそのすり合わせの責務が寄せられることになりました。しかし、LNURLもLNの上に作られたオープンプロトコル/スペックの位置付けになるため、他のLNURLのスペックに干渉するという懸念から、本提案のNIP-57に変更依頼が出されています。LN、LNURL、Nostrの3つのオープンプロトコルの責務分担が難しいですね。アーキテクチャ層のスタックにおいて3つの中ではNostrが一番上になるため、Nostrに相当するレイヤーの他のwebサービスでやるときはLNプロトコルを喋るなりLNノードを持つようにして、今回LNURLが寄せられた責務を吸収するのが無難かもしれません。

また、NIP-57の変更依頼理由の一つにはBOLT-12を見越した抽象化も挙げられています。他のLNURLのスペックを削ぎ落としてzapsだけにすることでBOLT-12にも載りやすくなるだろうと。LNURLの多くはBOLT-12に取り込まれる運命なわけですが、LNアドレス以外の点でもNostrではBOLT-12のOfferやInvoiceRequestのユースケースをやりたいという声が挙がっているため、NostrによりBOLT-12が進む展開もありそうだなあ、あってほしい。

@ 3bf0c63f:aefa459d

busca múltipla na estante virtual

A single-page app made in Elm with a Go backend that scrapped estantevirtual.com.br in real-time for search results of multiple different search terms and aggregated the results per book store, so when you want to buy many books you can find the stores that have the biggest part of what you want and buy everything together, paying less for the delivery fee.

It had a very weird unicode issue I never managed to solve, something with the encoding estantevirtual.com.br used.

I also planned to build the entire checkout flow directly in this UI, but then decided it wasn't worth it. The search flow only was already good enough.

• https://estantevirtual.alhur.es/
• https://github.com/fiatjaf/estantevirtual

@ 3589b793:ad53847e

※本記事は別サービスで2023年2月5日に公開した記事の移植です。

Nostrクライアントは多種ありますがメジャーなものはだいたいLNの支払いが用意されています。現時点でどんな組み込み方法になっているか調べました。この記事では主にSnortを対象にしています。

LN活用場面

大きくLNアドレスとLNインボイスの2つの形式があります。

1. LNアドレスで投げ銭をセットできる

LNURLのLNアドレスをセットすると、プロフィールやノート（ツイートに相当）からLN支払いができます。別クライアントのastralなどではプリミティブなLNURLの投げ銭形式 lnurl1dp68～でもセットできます。

[追記]さらに本日、Snortで試験的にノート単位に投げ銭できる機能が追加されています。

2. LNインボイスが投稿できる

投稿でLNインボイスを貼り付ければ上記のように他の発言と同じようにタイムラインに流れます。Payボタンを押すと各自の端末にあるLNウォレットが立ち上がります。

3. DMでLNインボイスを送る

メッセージにLNインボイスが組み込まれているという点では2とほぼ同じですが、ユースケースが異なります。発表されたばかりですがリレーサーバの有料化が始まっていて、その決済をDMにLNインボイスを送付して行うことが試されています。2だとパブリックに投稿されますが、こちらはプライベートなので購入希望者のみにLNインボイスを届けられます。

おまけ: Nostrのユーザ名をLNアドレスと同じにする

直接は関係ないですが、Nostrはユーザー名をemail形式にすることができます。LNアドレスも自分でドメイン取って作れるのでNostrのユーザー名と投げ銭のアドレスを同じにできます。

LNウォレットのAlbyのドメインをNostrのユーザ名にも活用している様子 [Not found]

実装方法

LNアドレスもLNインボイスも非常にシンプルな話ですが軽くまとめます。 Snortリポジトリ

LNアドレス

1. セットされたLNアドレスを分解してhttps://[domain]/.well-known/lnurlp/[username]にリクエストする
2. 成功したら投げ銭量を決めるUIを提示する
3. Get Inoviceボタンを押したら1のレスポンスにあるcallbackにリクエストしてインボイスを取得する
4. 成功したらPayボタンを提示する

LNインボイス

1. 投稿内容がLNインボイス識別子lnbc10m〜だとわかると、識別子の中の文字列から情報（金額、説明、有効期限）を取り出し、表示用のUIを作成する
2. 有効期限内だったらPayボタンを提示し、期限が切れていたらExpiredでロックする

支払い

Payボタンを押された後の動きはアドレス、インボイスとも同じです。

• ブラウザでWebLN（Albyなど）がセットされていて、window.weblnオブジェクトがenableになっていると、拡張機能の支払い画面が立ち上がる。クライアント側で支払い成功をキャッチすることも可能。
• Open Walletボタンを押すと lightning:lnbc10m~のURI形式でwindow.openされ、Mac/Windows/iPhone/Androidなど各OSに応じたアプリケーション呼び出しが行われ、URIに対応しているLNウォレットが立ち上がる

[追記]ノート単位の投げ銭

Snort周辺の数人（strike社員っぽい人が一人いて本件のメイン実装している）で試験的にやっているようで現時点では実装レベルでしか詳細わかりませんでした。strikeのzapといまいち区別が付かなかったのですが、実装を見るとnostrプロトコルにzapイベントが追加されています。ソースコメントではこの後NIP(nostr improvement proposal)が起こされるようでかなりハッキーです。zap=tipの方言なんでしょうか？

ノートやプロフィールやリアクションなどに加えて新たにnostrイベントに追加しているものは以下2つです。

• zapRequest　投げ銭した側が対象イベントIDと量を記録する
• zapReceipt　投げ銭を受け取った側用のイベント

一つでできそうと思ったけど、nostrは自己主権のプロトコルでイベント作成するには発行者の署名が必須なので2つに分かれているのでしょう。

所感

現状はクライアントだけで完結する非常にシンプルな方法になっています。リレーサーバも経由しないしクライアントにLNノードを組み込むこともしていません。サードパーティへのhttpリクエストやローカルのアプリに受け渡すだけなので、実はどんな一般アプリでもそんなに知識もコストも要らずにパッとできるものです。

現状ちょっと不便だなと思っていることは、タイムラインに流れるインボイスの有効期限内の支払い済みがわからないことです。Payボタンを押してエラーにならないとわかりません。ウォレットアプリに放り投げていてこのトレースするためには、ウォレット側で支払い成功したらNostrイベントを書き込むなどの対応しない限りは、サービス側でインボイスを定期的に一つ一つLNに投げてチェックするなどが必要だと思われるので、他のサービスでマネするときは留意しておくとよさそうです。

一方で、DMによるLNインボイス送付は活用方法が広がりそうな予感があります。Nostrの公開鍵による本人特定と、LNインボイスのメモ欄のテキスト情報による突き合わせだけでも、かんたんな決済機能として用いれそうだからです。もっとNostrに判断材料を追加したければイベント追加も簡単にできることをSnortが示しています。とくにリレーサーバ購読やPROメニューなどのNostr周辺の支払いはやりやすそうなので、DM活用ではなくなにかしらの決済メニューを搭載したNostrクライアントもすぐに出てきそう気がします。

@ 3bf0c63f:aefa459d

requesthub.xyz

An app that was supposed to be some kind of declarative connector between two services, one that sent webhooks and the other that accepted HTTP requests of any kind. You would proxy and transform the webhooks using RequestHub and create a new request to the other service using that data.

The transformations were declared in the almighty jq language.

It worked and had other functions planned for the future, but I guess it was too arcane, even I was confused by it sometimes.

Also it was very prone to spam (involuntary) attacks like some that did happen. Maybe it would work better in a world of anonymous satoshi payments.

Later I tried to revive it as a Trello Power-Up that would create comments on cards automatically according to some transformation rules and webhooks received.

• requesthub.xyz
• https://github.com/fiatjaf/requesthub.xyz
• https://github.com/fiatjaf/requesthub-trello

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

notes on "Economic Action Beyond the Extent of the Market", Per Bylund

Source: https://www.youtube.com/watch?v=7St6pCipCB0

Markets work by dividing labour, but that's not as easy as it seems in the Adam Smith's example of a pin factory, because

1. a pin factory is not a market, so there is some guidance and orientation, some sort of central planning, inside there that a market doesn't have;
2. it is not clear how exactly the production process will be divided, it is not obvious as in "you cut the thread, I plug the head".

Dividing the labour may produce efficiency, but it also makes each independent worker in the process more fragile, as they become dependent on the others.

This is partially solved by having a lot of different workers, so you do not depend on only one.

If you have many, however, they must agree on where one part of the production process starts and where it ends, otherwise one's outputs will not necessarily coincide with other's inputs, and everything is more-or-less broken.

That means some level of standardization is needed. And indeed the market has constant incentives to standardization.

The statist economist discourse about standardization is that only when the government comes with a law that creates some sort of standardization then economic development can flourish, but in fact the market creates standardization all the time. Some examples of standardization include:

• programming languages, operating systems, internet protocols, CPU architectures;
• plates, forks, knifes, glasses, tables, chairs, beds, mattresses, bathrooms;
• building with concrete, brick and mortar;
• money;
• musical instruments;
• light bulbs;
• CD, DVD, VHS formats and others alike;
• services that go into every production process, like lunch services, restaurants, bakeries, cleaning services, security services, secretaries, attendants, porters;
• multipurpose steel bars;
• practically any tool that normal people use and require a little experience to get going, like a drilling machine or a sanding machine; etc.

Of course it is not that you find standardization in all places. Specially when the market is smaller or new, standardization may have not arrived.

There remains the truth, however, that division of labour has the potential of doing good.

More than that: every time there are more than one worker doing the same job in the same place of a division of labour chain, there's incentive to create a new subdivision of labour.

From the fact that there are at least more than one person doing the same job as another in our society we must conclude that someone must come up with an insight about an efficient way to divide the labour between these workers (and probably actually implement it), that hasn't happened for all kinds of jobs.

But to come up with division of labour outside of a factory, some market actors must come up with a way of dividing the labour, actually, determining where will one labour stop and other start (and that almost always needs some adjustments and in fact extra labour to hit the tips), and also these actors must bear the uncertainty and fragility that division of labour brings when there are not a lot of different workers and standardization and all that.

In fact, when an entrepreneur comes with a radical new service to the market, a service that does not fit in the current standard of division of labour, he must explain to his potential buyers what is the service and how the buyer can benefit from it and what he will have to do to adapt its current production process to bear with that new service. That's has happened not long ago with

• services that take food orders from the internet and relay these to the restaurants;
• hostels for cheap accommodation for young travellers;
• Uber, Airbnb, services that take orders and bring homemade food from homes to consumers and similars;
• all kinds of software-as-a-service;
• electronic monitoring service for power generators;
• mining planning and mining planning software; and many other industry-specific services.

See also

• Profits, not wages, as the originary factor
• Per Bylund's insight

@ 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

A crappy zk-rollups explanation attempt

(Considering the example of zksync.io) (Also, don't believe me on any of this.)

1. They are sidechains.
2. You move tokens to the sidechain by depositing it on an Ethereum contract. Then your account is credited in the sidechain balance.
3. Then you can make payments inside the sidechain by signing transactions and sending them to a central operator.
4. The central operator takes transactions from a bunch of people, computes the new sidechain balances state and publishes a hash of that state to the Ethereum contract.
5. The idea is that a single transaction in the blockchain contains a bunch of sidechain transactions.
6. The operator also sends to the contract an abbreviated list of the sidechain transactions. The trick is making all signatures condensed in a single zero-knowledge proof which is enough for the contract to verify that the transition from the previous state to the new is good.
7. Apparently they can fit 500 sidechain transactions in one mainchain transaction (each is 12 bytes). So I believe it's fair to say all this zk-rollup fancyness could be translated into "a system for aggregating transactions".

8. I don't understand how the zero-knowledge proof works, but in this case it is a SNARK and requires a trusted setup, which I imagine is similar to this one.

9. On "zk-rollups" applied to Bitcoin

@ 3bf0c63f:aefa459d

Eltoo

Read the paper, it's actually nice and small. You can read only everything up to section 4.2 and it will be enough. Done.

Ok, you don't want to. Or you tried but still want to read here.

Eltoo is a way of keeping payment channel state that works better than the original scheme used in Lightning. Since Lightning is a bunch of different protocols glued together, it can It replace just the part the previously dealed with keeping the payment channel.

Eltoo works like this: A and B want a payment channel, so they create a multisig transaction with deposits from both -- or from just one, doesn't matter. That transaction is only spendable if both cooperate. So if one of them is unresponsive or non-cooperative the other must have a way to get his funds back, so they also create an update transaction but don't publish it to the blockchain. That update transaction spends to a settlement transaction that then distributes the money back to A and B as their balances say.

If they are cooperative they can change the balances of the channel by just creating new update transactions and settlement transactions and number them like 1, 2, 3, 4 etc.

Solid arrows means a transaction is presigned to spend only that previous other transaction; dotted arrows mean it's a floating transaction that can spend any of the previous.

Why do they need and update and a settlement transaction?

Because if B publishes update2 (in which his balances were greater) A needs some time to publish update4 (the latest, which holds correct state of balances).

Each update transaction can be spent by any newer update transaction immediately or by its own specific settlement transaction only after some time -- or some blocks.

Hopefully you got that.

How do they close the channel?

If they're cooperative they can just agree to spend the funding transaction, that first multisig transaction I mentioned, to whatever destinations they want. If one party isn't cooperating the other can just publish the latest update transaction, wait a while, then publish its settlement transaction.

How is this better than the previous way of keeping channel states?

Eltoo is better because nodes only have to keep the last set of update and settlement transactions. Before they had to keep all intermediate state updates.

If it is so better why didn't they do it first?

Because they didn't have the idea. And also because they needed an update to the Bitcoin protocol that allowed the presigned update transactions to spend any of the previous update transactions. This protocol update is called SIGHASH_NOINPUT[^anyprevout], you've seen this name out there. By marking a transaction with SIGHASH_NOINPUT it enters a mystical state and becomes a floating transaction that can be bound to any other transaction as long as its unlocking script matches the locking script.

Why can't update2 bind itself to update4 and spend that?

Good question. It can. But then it can't anymore, because Eltoo uses OP_CHECKLOCKTIMEVERIFY to ensure that doesn't actually check not a locktime, but a sequence. It's all arcane stuff.

And then Eltoo update transactions are numbered and their lock/unlock scripts will only match if a transaction is being spent by another one that's greater than it.

Do Eltoo channels expire?

No.

What is that "on-chain protocol" they talk about in the paper?

That's just an example to guide you through how the off-chain protocol works. Read carefully or don't read it at all. The off-chain mechanics is different from the on-chain mechanics. Repeating: the on-chain protocol is useless in the real world, it's just a didactic tool.

[^anyprevout]: Later SIGHASH_NOINPUT was modified to fit better with Taproot and Schnorr signatures and renamed to SIGHASH_ANYPREVOUT.

@ 3bf0c63f:aefa459d

idea: Link sharing incentivized by satoshis

See https://2key.io/ and https://www.youtube.com/watch?v=CEwRv7qw4fY&t=192s.

I think the general idea is to make a self-serving automatic referral program for individual links, but I wasn't patient enough to deeply understand neither of the above ideas.

Solving fraud is an issue. People can fake clicks.

One possible solution is to track conversions instead of clicks, but then it's too complex as the receiving side must do stuff and be trusted to do it correctly.

@ 3bf0c63f:aefa459d

Rede Relâmpago

Ao se referir à Lightning Network do O que é Bitcoin?, 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

Soft-forks on Bitcoin

A traditional soft-fork activation plays out like this:

1. someone makes a proposal
2. if half-dozen respected Core developers like that, they implement it and talk about it
3. everybody loves the idea
4. they ship it in Bitcoin Core
5. miners turn it onA traditional soft-fork activation plays out like this:

A traditional soft-fork failure plays out like this:

1. someone makes a proposal
2. if half-dozen respected Core developers do not care much about the idea, they don't do anything
3. people fight on Twitter about the merits of the idea forever

A sidechain activation within BIP-300 plays out like this:

1. someone writes the sidechain software
2. if a bunch of people are interested in that, they start playing with it in test mode
3. if it is really good people launch a proposal to miners
4. miners vote yes or no

@ 3bf0c63f:aefa459d

Truthcoin as a spacechain

To be clear, the term "spacechain" here refers only to the general concept of blindly merge-mined (BMM) chains without a native money-token, not including the "spacecoins".

The basic idea is that for Truthcoin/Hivemind to work we need

1. Balances of Votecoin tokens, i.e. a way to keep track of who owns how much of the oracle corporation;
2. Bitcoin tokens to be used for buying and selling prediction market shares, i.e. money to gamble;
3. A blockchain, i.e. some timestamping service that emits blocks ordered with transactions and can keep track of internal state and change the state -- including the balances of the Votecoin tokens and of the Bitcoin tokens that are assigned to individual prediction markets according to predefined rules;

A spacechain, i.e. a blindly merge-mined chain, gives us 1 and 3. We can just write any logic for that and that should be very easy. It doesn't give us 2, and it also has the problem of how the spacechain users can pay the spacechain miners (which is why the spacecoins were envisioned in the first place, but we don't have spacecoins here).

But remember we have votecoins already. Votecoins (VTC) should represent a share in the oracle corporation, which means they entitle their holders to some revenue -- even though they also burden their holders with the duty to vote in event outcomes (at the risk of losing part of their own votecoin balance) --, and they can be exchanged, so we can assume they will have some value.

So we could in theory use these valuable tokens to pay the spacechain miners. That wouldn't be great because it pervert their original purpose and wouldn't solve the problem 2 from above -- unless we also used the votecoins to bet in which case they wouldn't be just another shitcoin in the planet with no network effect competing against Bitcoin and would just cause harm to humanity.

What we can do instead is to create a native mechanism for issuing virtual Bitcoin tokens (vBTC) in this chain, collaterized by votecoins, then we can use these vBTC to both gamble (solve problem 2) and pay miners (fix the hole in the spacechain BMM design).

For example, considering the VTC to be worth 0.001 BTC, any VTC holder could put 0.005 VTC and get 0.001 vBTC, then use to gamble or sell to others who want to gamble. The VTC holder still technically owns the VTC and can and must still participate in the oracle decisions. They just have to pay the BTC back before they can claim their VTC back if they want to send it elsewhere.

They stand to gain by selling vBTC if there is a premium for vBTC over BTC (i.e. people want to gamble) and then rebuying vBTC back once that premium goes away or reverts itself.

For this scheme to work the chain must know the exchange rate between VTC and BTC, which can be provided by the oracle corporation itself.

@ 3bf0c63f:aefa459d

Haskell Monoids

You've seen that <> syntax and noticed it is imported from Data.Monoid?

I've always thought <> was a pretty complex mathematical function and it was very odd that people were using it for Text values, like "whatever " <> textValue <> " end.".

It turns out Text is a Monoid. That means it implements the Monoid class (or typeclass), that means it has a particular way of being concatenated. Any list could be a Monoid, any abstraction you can think of for which it makes sense to concatenate could be a Monoid, and it would use the same <> syntax. What exactly <> would do with that value when concatenating depends on its typeclass implementation of Monoid.

We can assume, for example, that Text implements Monoid by just joining the text bytes, and now we can use <> without getting puzzled about it.

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

A prediction market as a distributed set of oracle federations

See also: Truthcoin as a spacechain.

This is not Truthcoin, but hopefully the essence of what makes it good is present here: permissionless, uncensorable prediction markets for fun, profit, making cheap talk expensive and revolutionizing the emergence and diffusion of knowledge in society.

The idea

The idea is just to reuse Fedimint's codebase to implement federated oracle corporations that will host individual prediction markets inside them.

Pegging in and out of a federation can be done through Lightning gateways, and once inside the federation users can buy and sell shares of individual markets using a native LMSR market-maker.

Then we make a decentralized directory of these bets using something simple like Nostr so everybody can just join any market very easily.

Why?

The premise of this idea is that we can't have a centralized prediction market platform because governments will shut it down, but we can instead have a pseudonymous oracle corporation that also holds the funds being gambled at each time in a multisig Bitcoin wallet and hope for the best.

Each corporation may exist to host a single market and then vanish afterwards -- its members returning later to form a new corporation and host a new market before leaving again.

There is custodial risk, but the fact that the members may accrue reputation as the time passes and that this is not one big giant multisig holding all the funds of everybody but one multisig for each market makes it so this is slightly better.

In any case, no massive amounts are expected to be used in this scheme, which defeats some of the use cases of prediction markets (funding public goods, for example), but since these are so advanced and society is not yet ready for them, we can leave them for later and first just try to get some sports betting working.

This proto-truthcoin implementation should work just well enough to increase the appetite of bitcoiners and society in general for more powerful prediction markets.

Why is this better than DLCs?

Because DLCs have no liquidity. In their current implementations and in all future plans from DLC enthusiasts they don't even have order books. They're not seen very much as general-purpose prediction markets, but mostly as a way to create monetary instruments and derivatives.

They could work as prediction markets, but then they would need order books and order books are terrible for liquidity. LMSR market makers are much better.

But it is custodial!

If you make a public order book tied to known oracles using a DLC the oracle may also be considered custodial since it becomes really easy for him to join multiple trades as a counterpart then lie and steal the money. The bets only really "discreet" if they're illiquid meaningless bets between two guys. If they're happening in a well-known public place they're not discreet anymore.

DLC proponents may say this can be improved by users using multiple oracles and forming effectively a federation between them, but that is hardly different from choosing a reputable oracle corporation in this scheme and trusting that for the life of the bet.

But Hivemind is better!

Yes.

@ 3589b793:ad53847e

※本記事は別サービスで2022年9月25日に公開した記事の移植です。

LNの手数料の適正水準はどう見積もったらいいだろうか？ルーティングノードの収益性を算出するためにはどうアプローチすればよいだろうか？本記事ではルーティングノード運用のポジションに立ち参考になりそうな数値や計算式を整理する。

個人的な感想を先に書くと以下となる。

• 現在の手数料市場は収益性が低くもっと手数料が上がった方が健全である。
• 他の決済手段と比較すると、LN支払い料金は10000ppm（手数料1%相当）でも十分ではないか。4ホップとすると中間1ノードあたり2500ppmである。
• ルーティングノードの収益性を考えると、1000ppmあれば1BTC程度の資金で年利2.8%になり半年で初期費用回収できるので十分な投資対象になると考える。

基本概念の整理

LNの料金方式

• LNの手数料は送金額に応じた料率方式が主になる。（基本料金の設定もあるが1 ~ 0 satsが大半）
• 料率単位のppm（parts per million）は、1,000,000satsを送るときの手数料をsats金額で示したもの。
• %での手数料率に変換すると1000ppm = 0.1%になる。
• 支払い者が払う手数料はルーティングに参加した各ノードの手数料の合計である。本稿では4ホップ（経由ノードが4つ）のルーティングがあるとすれば、各ノードの取り分は単純計算で1/4とみなす。
• ルーティングノードの収益はアウトバウンドフローで発生するのでアウトバウンドキャパシティが直接的な収益資源となる。

LNの料金以外のベネフィット

本稿では料金比較だけを行うが実際の決済検討では以下のような料金以外の効用も忘れてはならない。

• Bitcoin(L1)に比べると、料金の安さだけでなく、即時確定やトランザクション量のスケールという利点がある。
• クレジットカードなどの集権サービスと比較した特徴はBitcoin(L1)とだいたい同じである。
• 24時間365日利用できる
• 誰でも自由に使える
• 信頼する第三者に対する加盟や審査や手数料率などの交渉手続きが要らない
• 検閲がなく匿名性が高い
• 逆にデメリットはオンライン前提がゆえの利用の不便さやセキュリティ面の不安さなどが挙げられる。

現在の料金相場

• ルーティングノードの料金設定
• sinkノードとのチャネルは500 ~ 1000ppmが多い。
• routing/sourceノードとのチャネルは0 ~ 100ppmあたりのレンジになる。
• リバランスする場合もsinkで収益を上げているならsink以下になるのが道理である。
• プロダクト/サービスのバックエンドにいるノードの料金設定
• sinkやsourceに相当するものは上記の通り。 
• 1000〜5000ppmあたりで一律同じ設定というノードもよく見かける。
• ビジネスモデル次第で千差万別だがアクティブと思われるノードでそれ以上はあまり見かけない。
• 上記は1ノードあたりの料金になる。支払い全体では経由したノードの合計になる。

料金目安

いくつかの方法で参考数字を出していく。LN料金算出は「支払い全体/2ホップしたときの1ノードあたり/4ホップしたときの1ノードあたり」の三段階で出す。

類推方式

決済代行業者との比較

• Squareの加盟店手数料は、日本3.25%、アメリカ2.60%である。
• 参考資料 https://www.meti.go.jp/shingikai/mono_info_service/cashless_payment/pdf/20220318_1.pdf

3.25%とするとLNでは「支払い全体/2ホップしたときの1ノードあたり/4ホップしたときの1ノードあたり」でそれぞれ32,500ppm/16,250ppm/8,125ppmになる。

スマホのアプリストアとの比較

• Androidのアプリストアは年間売上高が100万USDまでなら15%、それ以上なら30%
• 参考資料https://support.google.com/googleplay/android-developer/answer/112622?hl=ja

15%とするとLNでは「支払い全体/2ホップしたときの1ノードあたり/4ホップしたときの1ノードあたり」でそれぞれ150,000ppm/75,000ppm/37,500ppmになる。

Bitcoin(L1)との比較

Bitcoin(L1)は送金額が異なっても手数料がほぼ同じため、従量課金のLNと単純比較はできない。そのためここではLNの方が料金がお得になる目安を出す。

Bitcoin(L1)の手数料設定

• SegWitのシンプルな送金を対象にする。
• input×1、output×2（送金+お釣り）、tx合計222byte
• L1の手数料は、1sat/byteなら222sats、10sat/byteなら2,220sats、100sat/byteなら22,200sats。（単純化のためvirtual byteではなくbyteで計算する）
• サンプル例 https://www.blockchain.com/btc/tx/15b959509dad5df0e38be2818d8ec74531198ca29ac205db5cceeb17177ff095

L1相場が1sat/byteの時にLNの方がお得なライン

• 100ppmなら、0.0222BTC（2,220,000sats）まで
• 1000ppmなら、0.00222BTC（222,000sats）まで

L1相場が10sat/byteの時にLNの方がお得なライン

• 100ppmなら、0.222BTC（22,200,000sats）まで
• 1000ppmなら、0.0222BTC（2,220,000sats）まで

L1相場が100sat/byteの時にLNの方がお得なライン

• 100ppmなら、2.22BTC（222,000,000sats）まで
• 1000ppmなら、0.222BTC（22,200,000sats）まで

コスト積み上げ方式

ルーティングノードの原価から損益分岐点となるppmを算出する。事業者ではなく個人を想定し、クラウドではなくラズベリーパイでのノード構築環境で計算する。

費用明細

• BTC市場価格　1sat = 0.03円（1BTC = 3百万円)

初期費用

• ハードウェア一式　40,000円
• Raspberry Pi 4 8GB
• SSD 1TB
• 外付けディスプレイ
• チャネル開設のオンチェーン手数料　6.69円/チャネル　　
• 開設料　223sats
• 223sats * BTC市場価格0.03円 = 6.69円

固定費用

• 電気代　291.6円/月　　
• 時間あたりの電力量　0.015kWh 
  • Raspberry Pi 4　電圧5V、推奨電源容量3.0A
  • https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#power-supply
• kWh単価27円
• 0.015kWh * kWh単価27円 * １ヶ月の時間720h = 291.6円

損益分岐点

• 月あたりの電気代を上回るために9,720sats（291.6円）/月以上の収益が必要である。
• ハードウェア費用回収のために0.01333333BTC（133万sats) = 40,000円の収益が必要である。

費用回収シナリオ例

アウトバウンドキャパに1BTCをデポジットしたAさんを例にする。1BTCは初心者とは言えないと思うが、このくらい原資を用意しないと費用回収の話がしづらいという裏事情がある。チャネル選択やルーティング戦略は何もしていない仮定である。ノード運用次第であることは言うまでもないので今回は要素や式を洗い出すことが主目的で一つ一つの変数の値は参考までに。

変数設定

• インバウンドを同額用意して合計キャパを2BTCとする。
• １チャネルあたり5m satsで40チャネル開設する。
• チャネル開設費用　223sats * 40チャネル = 8,920sats
• 初期費用合計　1,333,333sats + 8,920sats = 1,342,253sats
• 一回あたり平均ルーティング量 = 100,000sats
• 1チャネルあたり平均アウトバウンド数/日 = 2
• 1チャネルあたり平均アウトバウンドppm = 50

費用回収地点

• 1日のアウトバウンド量は、 40チャネル * 2本 * 100,000sats = 8m sats
• 手数料収入は、8m sats * 0.005%(50ppm) = 400sats/日。月換算すると12,000sats/月
• 電気代を差し引くと、12,000sats - 電気代9,720sats =月収益2,280sats(68.4円)
• 初期費用回収まで、1,342,253sats / 2,280sats = 589ヵ月（49年）
• 後述するが電気代差引き前で年利0.14%になる。

理想的なppm

6ヵ月での初期費用回収を目的にしてアウトバウンドppmを求める。

• ひと月あたり、初期費用合計1,342,253sats / 6ヵ月 + 電気代9,720sats = 233,429sats(7,003円)の収益が必要。
• 1日あたり、7,781sats(233円)の収益
• その場合の平均アウトバウンドppmは、 7,781sats（1日の収益量） / 8m sats（1日のアウトバウンド量） * 1m sats（ppm変換係数） = 973ppm

他のファイナンスとの比較

ルーティングノードを運用して手数料収入を得ることは資産運用と捉えることもできる。レンディングやトレードなどの他の資産運用手段とパフォーマンス比較をするなら、デポジットしたアウトバウンドキャパシティに対する手数料収入をAPY換算する。（獲得した手数料はアウトバウンドキャパシティに積み重ねられるので複利と見做せる）

例としてLNDg（v1.3.1）のAPY算出計算式を転載する。見ての通り画面上の表記はAPYなのに中身はAPRになっているので注意だが今回は考え方の参考としてこのまま採用する。

年換算 = 365 / 7 = 52.142857 年利 = (7dayの収益 * 年換算) / アウトバウンドのキャパシティ

例えば上記のAさんの費用回収シナリオに当てはめると以下となる。

年利 0.14% = （400sats * 7日 * 年換算）/ 100m sats

電気代を差し引くと 76sats/日となり年利0.027%

もし平均アウトバウンド1000ppmになると8,000sats/日なので年利2.9%になる。 この場合、電気代はほぼ1日で回収されるため差し引いても大差なく7,676sats/日で年利2.8%になる。

考察

以上、BTC市場価格や一日のアウトバウンド量といった重要な数値をいくつか仮置きした上ではあるが、LN手数料の適正水準を考えるための参考材料を提示した。

まず、現在のLNの料金相場は他の決済手段から比べると圧倒的に安いことがわかった。1%でも競争力が十分ありそうなのに0.1%前後で送金することが大半である。

健全な市場発展のためには、ルーティングノードの採算が取れていることが欠かせないと考えるが、残念ながら現在の収益性は低い。ルーティングノードの収益性は仮定に仮定を重ねた見積もりになるが、平均アウトバウンドが1000ppmでようやく個人でも参入できるレベルになるという結論になった。ルーティングノードの立場に立つと、現在の市場平均から大幅な上昇が必要だと考える。

手数料市場は競争のためつねに下方圧力がかかっていて仕様上で可能な0に近づいている。この重力に逆らうためには、1. 需要 > 供給のバランスになること、2. 事業用途での高額買取のチャネルが増えること、の2つの観点を挙げる。1にせよ2にせよネットワークの活用が進むことで発生し、手数料市場の大きな変動機会になるのではないか。他の決済手段と比較すれば10000ppm、1チャネル2500ppmあたりまでは十分に健全な範囲だと考える。

@ 3bf0c63f:aefa459d

O mito do objetivo

O insight deste cara segundo o qual buscar objetivos fixos, além de matar a criatividade, ainda não consegue atingir o tal objetivo -- que é uma coisa na qual eu sempre acreditei, embora sem muitas confirmações e (talvez por isso) sem dizê-lo abertamente --, combina com a idéia geral de que todas as estruturas sociais que valem alguma coisa surgem do jogo e brincadeira.

A seriedade, que é o oposto da brincadeira, é representada aqui pelo objetivo. Pessoas muito sérias com um planejamento e um objetivo final, tudo esquematizado.

---

Na verdade esse insight é bem manjado. Até eu mesmo já o tinha mencionado, citando Taleb em Processos Antifrágeis.

E finalmente há esta tirinha que eu achei aleatoriamente e que bem o representa:

@ 3bf0c63f:aefa459d

O Bitcoin como um sistema social humano

Afinal de contas, o que é o Bitcoin? Não vou responder a essa pergunta explicando o que é uma "blockchain" ou coisa que o valha, como todos fazem muito pessimamente. A melhor explicação em português que eu já vi está aqui, mas mesmo assim qualquer explicação jamais será definitiva.

A explicação apenas do protocolo, do que faz um programa bitcoind sendo executado em um computador e como ele se comunica com outros em outros computadores, e os incentivos que estão em jogo para garantir com razoável probabilidade que se chegará a um consenso sobre quem é dono de qual parte de qual transação, apesar de não ser complicada demais, exigirá do iniciante que seja compreendida muitas vezes antes que ele se possa se sentir confortável para dizer que entende um pouco.

E essa parte técnica, apesar de ter sido o insight fundamental que gerou o evento miraculoso chamado Bitcoin, não é a parte mais importante, hoje. Se fosse, várias dessas outras moedas seriam concorrentes do Bitcoin, mas não são, e jamais poderão ser, porque elas não estão nem próximas de ter os outros elementos que compõem o Bitcoin. São eles:

1. A estrutura

O Bitcoin é um sistema composto de partes independentes.

Existem programadores que trabalham no protocolo e aplicações, e dia após dia novos programadores chegam e outros saem, e eles trabalham às vezes em conjunto, às vezes sem que um se dê conta do outro, às vezes por conta própria, às vezes pagos por empresas interessadas.

Existem os usuários que realizam validação completa, isto é, estão rodando algum programa do Bitcoin e contribuindo para a difusão dos blocos, das transações, rejeitando usuários malignos e evitando ataques de mineradores mal-intencionados.

Existem os poupadores, acumuladores ou os proprietários de bitcoins, que conhecem as possibilidades que o mundo reserva para o Bitcoin, esperam o dia em que o padrão-Bitcoin será uma realidade mundial e por isso mesmo atributem aos seus bitcoins valores muito mais altos do que os preços atuais de mercado, agarrando-se a eles.

Especuladores de "criptomoedas" não fazem parte desse sistema, nem tampouco empresas que aceitam pagamento em bitcoins para imediatamente venderem tudo em troca de dinheiro estatal, e menos ainda gente que usa bitcoins e a própria marca Bitcoin para aplicar seus golpes e coisas parecidas.

1. A cultura

Mencionei que há empresas que pagam programadores para trabalharem no código aberto do BitcoinCore ou de outros programas relacionados à rede Bitcoin -- ou mesmo em aplicações não necessariamente ligadas à camada fundamental do protocolo. Nenhuma dessas empresas interessadas, porém, controla o Bitcoin, e isso é o elemento principal da cultura do Bitcoin.

O propósito do Bitcoin sempre foi ser uma rede aberta, sem chefes, sem política envolvida, sem necessidade de pedir autorização para participar. O fato do próprio Satoshi Nakamoto ter voluntariamente desaparecido das discussões foi fundamental para que o Bitcoin não fosse visto como um sistema dependente dele ou que ele fosse entendido como o chefe. Em outras "criptomoedas" nada disso aconteceu. O chefe supremo do Ethereum continua por aí mandando e desmandando e inventando novos elementos para o protocolo que são automaticamente aceitos por toda a comunidade, o mesmo vale para o Zcash, EOS, Ripple, Litecoin e até mesmo para o Bitcoin Cash. Pior ainda: Satoshi Nakamoto saiu sem nenhum dinheiro, nunca mexeu nos milhares de bitcoins que ele gerou nos primeiros blocos -- enquanto os líderes dessas porcarias supramencionadas cobraram uma fortuna pelo direito de uso dos seus primeiros usuários ou estão aí a até hoje receber dividendos.

Tudo isso e mais outras coisas -- a mentalidade anti-estatal e entusiasta de sistemas p2p abertos dos membros mais proeminentes da comunidade, por exemplo -- faz com que um ar de liberdade e suspeito de tentativas de centralização da moeda sejam percebidos e execrados.

1. A história

A noção de que o Bitcoin não pode ser controlado por ninguém passou em 2017 por dois testes e saiu deles muito reforçada: o primeiro foi a divisão entre Bitcoin (BTC) e Bitcoin Cash (BCH), uma obra de engenharia social que teve um sucesso mediano em roubar parte da marca e dos usuários do verdadeiro Bitcoin e depois a tentativa de tomada por completo do Bitcoin promovida por mais ou menos as mesmas partes interessadas chamada SegWit2x, que fracassou por completo, mas não sem antes atrapalhar e difundir mentiras para todos os lados. Esses dois fracassos provaram que o Bitcoin, mesmo sendo uma comunidade desorganizada, sem líderes claros, está imune à captura por grupos interessados, o que é mais um milagre -- ou, como dizem, um ponto de Schelling.

Esse período crucial na história do Bitcoin fez com ficasse claro que hard-forks são essencialmente incompatíveis com a natureza do protocolo, de modo que no futuro não haverá a possibilidade de uma sugestão como a de imprimir mais bitcoins do que o que estava programado sejam levadas a sério (mas, claro, sempre há a possibilidade da cultura toda se perder, as pessoas esquecerem a história e o Bitcoin ser cooptado, eis a importância da auto-educação e da difusão desses princípios).

@ 81650982:299380fa

Let us delve into Monero (XMR). Among the proponents of various altcoins, Monero arguably commands one of the most dedicated followings, perhaps second only to Ethereum. Unlike many altcoins where even investors often harbor speculative, short-term intentions, the genuine belief within the Monero community suggests an inherent appeal to the chain itself.

The primary advantage touted by Monero (and similar so-called "privacy coins") is its robust privacy protection features. The demand for anonymous payment systems, tracing its lineage back to David Chaum, predates even the inception of Bitcoin. Monero's most heavily promoted strength, relative to Bitcoin, is that its privacy features are enabled by default.

This relates to the concept of the "anonymity set." To guarantee anonymity, a user must blend into a crowd of ordinary users. The larger the group one hides within, the more difficult it becomes for an external observer to identify any specific individual. From the perspective of Monero advocates, Bitcoin's default transaction model is overly transparent, clearly revealing the flow of funds between addresses. While repeated mixing can enhance anonymity in Bitcoin, the fact that users must actively undertake such measures presents a significant hurdle. More critically, proponents argue, the very group engaging in such deliberate obfuscation is precisely the group one doesn't want to be associated with for effective anonymity. Hiding requires blending with the ordinary, not merely mixing with others who are also actively trying to hide — the latter, they contend, is akin to criminals mixing only with other criminals.

This is a valid point. For instance, there's a substantial difference between a messenger app offering end-to-end encryption for all communications by default, versus one requiring users to explicitly create a "secret chat" for encryption. While I personally believe that increased self-custody of Bitcoin in personal wallets, acquisition through direct peer-to-peer payments rather than exchange purchases, and the widespread adoption of the Lightning Network would make tracing significantly harder even without explicit mixing efforts, let us concede, for the sake of argument, that Bitcoin's base-layer anonymity might not drastically improve even in such a future scenario.

Nevertheless, Monero's long-term prospects appear considerably constrained when focusing purely on technical limitations, setting aside economic factors or incentive models for now. While discussions on economics can often be countered with "That's just your speculation," technical constraints present more objective facts and leave less room for dispute.

Monero's most fundamental problem is its lack of scalability. To briefly explain how Monero obfuscates the sender: it includes other addresses alongside the true sender's address in the 'from' field and attaches what appears to be valid signatures for all of them. With a default setting of 10 decoys (plus the real spender, making a ring size of 11), the signature size naturally becomes substantially larger than Bitcoin's. Since an observer cannot determine which of the 11 is the true sender, and these decoys are arbitrary outputs selected from the blockchain belonging to other users, anonymity is indeed enhanced. While the sender cannot generate individually valid signatures for the decoy outputs (as they don't own the private keys), the use of a ring signature mathematically proves that one member of the ring authorized the transaction, allowing it to pass network validation.

The critical issue is that this results in transaction sizes several times larger than Bitcoin's. Bitcoin already faces criticism for being relatively expensive and slow. Monero's structure imposes a burden that is multiples greater. One might question the relationship between transaction data size and transaction fees/speed. However, the perceived slowness of blockchains isn't typically due to inefficient code, but rather the strict limitations imposed on block size (or equivalent throughput constraints) to maintain decentralization. Therefore, larger transaction sizes directly translate into throughput limitations and upward pressure on fees. If someone claims Monero fees are currently lower than Bitcoin's, that is merely a consequence of its significantly lower usage. Should Monero's transaction volume reach even a fraction of Bitcoin's, its current architecture would struggle severely under the load.

To address this, Monero implemented a dynamic block size limit instead of a hardcoded one. However, this is not a comprehensive solution. If the block size increases proportionally with usage, a future where Monero achieves widespread adoption as currency — implying usage potentially hundreds, thousands, or even hundreds of thousands of times greater than today — would render the blockchain size extremely difficult to manage for ordinary node operators. Global internet traffic might be consumed by Monero transactions, or at the very least, the bandwidth and storage costs could exceed what individuals can reasonably bear.

Blockchains, by their nature, must maintain a size manageable enough for individuals to run full nodes, necessitating strict block size limits (or equivalent constraints in blockless designs). This fundamental requirement is the root cause of limited transaction speed and rising fees. Consequently, the standard approach to blockchain scaling involves Layer 2 solutions like the Lightning Network. The problem is, implementing such solutions on Monero is extremely challenging.

Layer 2 solutions, while varying in specific implementation details across different blockchains, generally rely heavily on the transparency of on-chain transactions. They typically involve sophisticated smart contracts built upon the ability to publicly verify on-chain states and events. Monero's inherent opacity, hiding crucial details of on-chain transactions, makes it exceptionally difficult for two mutually untrusting parties to reach the necessary consensus and cryptographic agreements (like establishing payment channels with verifiable state transitions and dispute mechanisms) that underpin such Layer 2 systems. The fact that Monero, despite existing for several years, still lacks a functional, widely adopted Layer 2 implementation suggests that this remains an unsolved and technically formidable challenge. While theoretical proposals exist, their real-world feasibility remains uncertain and would likely require significant breakthroughs in cryptographic protocol design.

Furthermore, Monero faces another severe scaling challenge related to its core privacy mechanism. As mentioned, decoy outputs are used to obscure the true sender. An astute observer might wonder: If a third party cannot distinguish the real spender, could the real spender potentially double-spend their funds later? Or could someone's funds become unusable simply because they were chosen as a decoy in another transaction? Naturally, Monero's developers anticipated this. The solution employed involves key images.

When an output is genuinely spent within a ring signature, a unique cryptographic identifier called a "key image" is derived from the real output and the spender's private key. This derivation is one-way (the key image cannot be used to reveal the original output or key). This key image is recorded on the blockchain. When validating a new transaction, the network checks if the submitted key image has already appeared in the history. If it exists, the transaction is rejected as a double-spend attempt. The crucial implication is that this set of used key images can never be pruned. Deleting historical key images would directly enable double-spending.

Therefore, Monero's state size — the data that full nodes must retain and check against — grows linearly and perpetually with the total number of transactions ever processed on the network.

Summary In summary, Monero faces critical technical hurdles:

Significantly Larger Transaction Sizes: The use of ring signatures for anonymity results in transaction data sizes several times larger than typical cryptocurrencies like Bitcoin.

Inherent Scalability Limitations: The large transaction size, combined with the necessity of strict block throughput limits to preserve decentralization, creates severe scalability bottlenecks regarding transaction speed and cost under significant load. Dynamic block sizes, while helpful in the short term, do not constitute a viable long-term solution for broad decentralization.

Layer 2 Implementation Difficulty: Monero's fundamental opacity makes implementing established Layer 2 scaling solutions (like payment channels) extremely difficult with current approaches. The absence of a widely adopted solution to date indicates that this remains a major unresolved challenge.

Unprunable, Linearly Growing State: The key image mechanism required to prevent double-spending mandates the perpetual storage of data proportional to the entire transaction history, unlike Bitcoin where nodes can prune historical blocks and primarily need to maintain the current UTXO set (whose size depends on usage patterns, not total history).

These technical constraints raise legitimate concerns about Monero's ability to scale effectively and achieve widespread adoption in the long term. While ongoing research may alleviate some of these issues, at present they represent formidable challenges that any privacy-focused cryptocurrency must contend with.

@ 3589b793:ad53847e

※本記事は別サービスで2022年5月22日に公開した記事の移植です。

Happy 🍕 Day's Present

まだ邦訳版が出版されていませんがこれまでのシリーズと同じくGitHubにソースコードが公開されています。なんと、現在のライセンスでは個人使用限定なら翻訳や製本が可能です。Macで、翻訳にはPDFをインプットにできるDeepLを用いた環境で、インスタントに製本してKindleなどで読めるようにする方法をまとめました。

手順の概要

1. Ruby環境を用意する
2. PDF作成ツールをセットアップする
3. GitHubのリポジトリを自分のPCにクローンする
4. asciidocをPDFに変換する
5. DeepLを節約するためにPDFを結合する
6. DeepLで翻訳ファイルを作る
7. 一冊に製本する

この手法の強み・弱み

翻訳だけならPDFを挟まなくてもGithubなどでプレビューできるコンパイル後のドキュメントの文章をコピーしてDeepLのWebツールにペーストすればよいですが、原著のペーパーブックで438ページある大容量です。熟練のコピペ職人でも年貢を納めて後進（機械やソフトウェア）に道を譲る刻ではないでしょうか？ただし、Pros/Consがあります。

Pros

• 一冊の本になるので毎度のコピペ作業がいらない
• Pizzaを食べながらタブレットやKindleで読める
• 図や表が欠落しない（プロトコルの手順を追った解説が多いため最大の動機でした）
• 2022/6/16追記: DeepLの拡張機能がアップデートされウェブページの丸ごと翻訳が可能になりました。よってウェブ上のgithubの図表付きページをそのまま翻訳できます。

Cons

• Money is power（大容量のためDeepLの有料契約が必要）
• ページを跨いだ文章が統合されずに不自然な翻訳になる（仕様です）
• ~~翻訳できない章が一つある（解決方法がないか調査中です。DeepLさんもっとエラーメッセージ出してくれ。Help me）~~ DeepLサポートに投げたら翻訳できるようになりました。

詳細ステップ

0.Ruby環境を用意する

asciidoctorも新しく入れるなら最新のビルドで良いでしょう。

1.PDF作成ツールをセットアップする

$ gem install asciidoctor asciidoctor-pdf $ brew install gs

2.GitHubのリポジトリを自分のPCにクローンする

どこかの作業ディレクトリで以下を実行する $ git clone git@github.com:lnbook/lnbook.git $ cd lnbook

3.asciidocをPDFに変換する

ワイルドカードを用いて本文を根こそぎPDF化します。 $ asciidoctor-pdf 0*.asciidoc 1*.asciidoc

いろいろ解析の警告が出ますが、ソースのasciidocを弄んでいくなりawsomeライブラリを導入すれば解消できるはずです。しかし如何せん量が多いので心が折れます。いったん無視して"Done is better than perfect"精神で最後までやり切りましょう。そのままGO！

また、お好みに合わせて、htmlで用意されている装丁用の部品も準備しましょう。私は表紙のcover.htmlをピックしました。ソースがhtmlなのでasciidoctorを通さず普通にPDFへ変換します。https://qiita.com/chenglin/items/9c4ed0dd626234b71a2c

4.DeepLを節約するためにPDFを結合する

DeepLでは課金プラン毎に翻訳可能なファイル数が設定されている上に、一本あたりの最大ファイルサイズが10MBです。また、翻訳エラーになる章が含まれていると丸ごとコケます。そのためPDCAサイクルを回し、最適なファイル数を手探りで見つけます。以下が今回導出した解となります。

$ gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=output_1.pdf 01_introduction.pdf 02_getting_started.pdf 03_how_ln_works.pdf 04_node_client.pdf 05_node_operations.pdf $gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=output_2_1.pdf 06_lightning_architecture.pdf 07_payment_channels.pdf 08_routing_htlcs.pdf $gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=output_2_2.pdf 09_channel_operation.pdf 10_onion_routing.asciidoc$ gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=output_3.pdf 11_gossip_channel_graph.pdf 12_path_finding.pdf 13_wire_protocol.pdf 14_encrypted_transport.pdf 15_payment_requests.pdf 16_security_privacy_ln.pdf 17_conclusion.pdf

5. DeepLで翻訳ファイルを作る

PDFファイルを真心を込めた手作業で一つ一つDeepLにアップロードしていき翻訳ファイルを作ります。ファイル名はデフォルトの[originalName]（日本語）.pdfのままにしています。

6. 一冊に製本する

表紙 + 本文で作成する例です。

$ gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=mastering_ln_jp.pdf cover.pdf "output_1 (日本語).pdf" "output_2_1 (日本語).pdf" "output_2_2 (日本語).pdf" "output_3 (日本語).pdf"

コングラチュレーションズ🎉

あなたは『Mastering the Lightning Network』の日本語版を手に入れた！個人使用に限り、あとは煮るなり焼くなりEPUBなりkindleへ送信するなり好き放題だ。

@ 3bf0c63f:aefa459d

A chatura Kelsen

Já presenciei várias vezes este mesmo fenômeno: há um grupo de amigos ou proto-amigos conversando alegremente sobre o conservadorismo, o tradicionalismo, o anti-comunismo, o liberalismo econômico, o livre-mercado, a filosofia olavista. É um momento incrível porque para todos ali é sempre tão difícil encontrar alguém com quem conversar sobre esses assuntos.

Eis que um deles fez faculdade de direito. Tendo feito faculdade de direito por acreditar que essa lhe traria algum conhecimento (já que todos os filósofos de antigamente faziam faculdade de direito!) esse sujeito que fez faculdade de direito, ao contrário dos demais, não toma conhecimento de que a sua faculdade é uma nulidade, uma vergonha, uma época da sua vida jogada fora -- e crê que são valiosos os conteúdos que lhe foram transmitidos pelos professores que estão ali para ajudar os alunos a se preparem para o exame da OAB.

Começa a falar de Kelsen. A teoria pura do direito, hermenêutica, filosofia do direito. A conversa desanda. Ninguém sabe o que dizer. A filosofia pura do direito não está errada porque é apenas uma lógica pura, e como tal não pode ser refutada; e por não ter qualquer relação com o mundo não há como puxar um outro assunto a partir dela e sair daquele território. Os jovens filósofos perdem ali as próximas duas horas falando de Kelsen, Kelsen. Uma presença que os ofende, que parece errada, que tem tudo para estar errada, mas está certa. Certa e inútil, ela lhes devora as idéias, que são digeridas pela teoria pura do direito.

É imperativo estabelecer esta regra: só é permitido falar de Kelsen se suas idéias não forem abordadas ou levadas em conta. Apenas elogios ou ofensas serão tolerados: Kelsen era um bom homem; Kelsen era um bobão. Pronto.

---

Eis aqui um exemplo gravado do fenômeno descrito acima: https://www.youtube.com/watch?v=CKb8Ij5ThvA: o Flavio Morgenstern todo simpático, elogiando o outro, falando coisas interessantes sobre o mundo; e o outro, que devia ser amigo dele antes de entrar para a faculdade de direito, começa a falar de Kelsen, com bastante confiança de que aquilo é relevante, e dá-lhe Kelsen, filosofia do direito, toda essa chatice tremenda.

@ e4950c93:1b99eccd

Dilling est une marque danoise qui crée des vêtements en laine, soie et coton biologique pour toute la famille.

Matières naturelles utilisées dans les produits

• Coton (biologique)
• Laine (mérinos, alpaga)
• Latex naturel (OEKO-TEX ®)
• Soie

⚠️ Attention, certains produits de cette marque (notamment les Vêtements - chaussettes, vestes, strings, shorts) contiennent des matières non naturelles, dont :

• Elasthanne
• Polyamide, nylon (nylon recyclé)
• Polyester (recyclé)

Catégories de produits proposés

• Vêtements : homme, femme, enfant, bébé, sous-vêtements, t-shirts, débardeurs, robes, vestes, pantalons, shorts, pulls, gilets, bodies, combinaisons, culottes, slips, boxers...

👉 Voir les produits naturels de cette marque

Autres informations

• Ecolabel Nordic Swan (teintures)
• Fabriqué en Lituanie (coupe et couture)
• Fabriqué au Danemark (teintures)
• Fabriqué en Europe

👉 En savoir plus sur le site de la marque

---

Cet article est publié sur origine-nature.com 🌐 See this article in English

📝 Vous pouvez contribuer à cette fiche en suggérant une modification en commentaire.

🗣️ Vous utilisez ce produit ? Partagez votre avis en commentaire.

⚡ Heureu-x-se de trouver cette information ? Soutenez le projet en faisant un don, pour remercier les contribut-eur-ice-s.

@ 3bf0c63f:aefa459d

tempreites

My first library to get stars on GitHub, was a very stupid templating library that used just HTML and HTML attributes ("DSL-free"). I was inspired by http://microjs.com/ at the time and ended up not using the library. Probably no one ever did.

• https://github.com/fiatjaf/tempreites

@ 3bf0c63f:aefa459d

Músicas que você já conhece

É bom escutar as mesmas músicas que você já conhece um pouco. cada nova escuta te deixa mais familiarizado e faz com que aquela música se torne parte do seu cabedal interno de melodias.

@ d08c9312:73efcc9f

Resolvr CEO, Aaron Daniel, summarizes his keynote speech from the Bitcoin Insurance Summit, April 26, 2025

Introduction

At the inaugural Bitcoin Insurance Summit in Miami, I had the pleasure of sharing two historical parallels that illuminate why "Bitcoin needs insurance, and insurance needs Bitcoin." The insurance industry's reactions to fire and coffee can help us better understand the profound relationship between emerging technologies, risk management, and commercial innovation.

Fire: Why Bitcoin Needs Insurance

The first story explores how the insurance industry's response to catastrophic urban fires shaped modern building safety. Following devastating events like the Great Fire of London (1666) and the Great Chicago Fire (1871), the nascent insurance industry began engaging with fire risk systematically.

Initially, insurers offered private fire brigades to policyholders who displayed their company's fire mark on their buildings. This evolved into increasingly sophisticated risk assessment and pricing models throughout the 19th century:

• Early 19th century: Basic risk classifications with simple underwriting based on rules of thumb
• Mid-19th century: Detailed construction types and cooperative sharing of loss data through trade associations
• Late 19th/Early 20th century: Scientific, data-driven approaches with differentiated rate pricing

The insurance industry fundamentally transformed building construction practices by developing evidence-based standards that would later inform regulatory frameworks. Organizations like the National Board of Fire Underwriters (founded 1866) and Underwriters Laboratories (established 1894) tested and standardized new technologies, turning seemingly risky innovations like electricity into safer, controlled advancements.

This pattern offers a powerful precedent for Bitcoin. Like electricity, Bitcoin represents a new technology that appears inherently risky but has tremendous potential for society. By engaging with Bitcoin rather than avoiding it, the insurance industry can develop evidence-based standards, implement proper controls, and ultimately make the entire Bitcoin ecosystem safer and more robust.

Coffee: Why Insurance Needs Bitcoin

The second story reveals how coffee houses in 17th-century England became commercial hubs that gave birth to modern insurance. Nathaniel Canopius brewed the first documented cup of coffee in England in 1637. But it wasn't until advances in navigation and shipping technology opened new trade lanes that coffee became truly ubiquitous in England. Once global trade blossomed, coffee houses rapidly spread throughout London, becoming centers of business, information exchange, and innovation.

In 1686, Edward Lloyd opened his coffee house catering to sailors, merchants, and shipowners, which would eventually evolve into Lloyd's of London. Similarly, Jonathan's Coffee House became the birthplace of what would become the London Stock Exchange.

These coffee houses functioned as information networks where merchants could access shipping news and trade opportunities, as well as risk management solutions. They created a virtuous cycle: better shipping technology brought more coffee, which fueled commerce and led to better marine insurance and financing, which in turn improved global trade.

Today, we're experiencing a similar technological and financial revolution with Bitcoin. This digital, programmable money moves at the speed of light and operates 24/7 as a nearly $2 trillion asset class. The insurance industry stands to benefit tremendously by embracing this innovation early.

Conclusion

The lessons from history are clear. Just as the insurance industry drove safety improvements by engaging with fire risk, it can help develop standards and best practices for Bitcoin security. And just as coffee houses created commercial networks that revolutionized finance, insurance, and trade, Bitcoin offers new pathways for global commerce and risk management.

For the insurance industry to remain relevant in a rapidly digitizing world, it must engage with Bitcoin rather than avoid it. The companies that recognize this opportunity first will enjoy significant advantages, while those who resist change risk being left behind.

The Bitcoin Insurance Summit represented an important first step in creating the collaborative spaces needed for this transformation—a modern version of those innovative coffee houses that changed the world over three centuries ago.

View Aaron's full keynote:

https://youtu.be/eIjT1H2XuCU

For more information about how Resolvr can help your organization leverage Bitcoin in its operations, contact us today.

@ 3bf0c63f:aefa459d

fieldbook-to-sql

This used to turn books from the late multi-things-manager (or tridimensional spreadsheets provider) fieldbook.com into complete SQLite3 databases.

It was referenced in their official shutdown message and helped people move data off (it would have been better if they had open-sourced the entire site, I don't understand why they haven't).

• https://github.com/fiatjaf/fieldbook-to-sql

@ 4e616576:43c4fee8

asdf

@ 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

@ 4e616576:43c4fee8

asdfasdflkjasdf

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

@ 4e616576:43c4fee8

lorem ipsum

@ 3bf0c63f:aefa459d

A flexibilidade da doutrina socialista

Os fatos da revolução russa mostram que Lênin e seus amigos bolcheviques não eram só psicopatas assassinos: eles realmente acreditavam que estavam fazendo o certo.

Talvez depois de um tempo o foco deles tenha mudado mais para o lado de se preocuparem menos com a vida e o bem-estar dos outros do que com eles mesmos, mas não houve uma mudança fundamental.

Ao mesmo tempo, a doutrina socialista na qual eles acreditavam era enormemente flexível, assim como a dos esquerdistas de hoje. É a mesma doutrina: uma coleção de slogans que pode ser adaptada para apoiar ou ir contra qualquer outra tese ou ação.

Me parece que a justificativa que eles encontraram para fazer tantas coisas claramente ruins vem dessas mesma flexibilidade. Os atos cruéis estavam todos justificados pela mesma coleção de slogans socialistas de sempre, apenas adaptados às circunstâncias.

Será que uma doutrina mais sólida se prestaria a essas atrocidades? Se concluirmos que a flexibilidade vem da mente e não da doutrina em si, sim, mas não acho que venha daí, porque é sempre o socialismo que é flexível, nunca nenhuma outra doutrina. Ou, na verdade, o socialismo é tão flexível que ele envolve e integra qualquer outra doutrina que seja minimamente compatível.

Talvez a flexibilidade esteja mesmo na mente, mas existe alguma relação entre a mente que desconhece a coerência e a lógica e a mente que se deixa atrair pelos slogans socialistas.

@ e4950c93:1b99eccd

Contenu à venir.

En savoir plus sur Wikipedia

---

Cet article est publié sur origine-nature.com 🌐 See this article in English

@ e4950c93:1b99eccd

Contenu à venir.

En savoir plus sur Wikipedia

---

Cet article est publié sur origine-nature.com 🌐 See this article in English

@ e4950c93:1b99eccd

Contenu à venir.

En savoir plus sur Wikipedia

---

Cet article est publié sur origine-nature.com 🌐 See this article in English

@ 3bf0c63f:aefa459d

"House" dos economistas e o Estado

Falta um gênio pra produzir um seriado tipo House só que com economistas. O House do seriado seria um austríaco é o "everybody lies" seria uma premissa segundo a qual o Estado é sempre a causa de todos os problemas.

Situações bem cabeludas poderiam ser apresentadas de maneira que parecesse muito que a causa era ganância ou o mau-caratismo dos agentes, mas na investigação quase sempre se descobriria que a causa era o Estado.

Parece ridículo, mas se eu descrevesse House assim aqui também pareceria. A execução é que importa.

@ 3bf0c63f:aefa459d

Excerpt of discussion about DIDs and ION

Melvin Carvalho:

"Not a single entity I know that's doing production deployments has actually vetted did:ion and found it to be production capable."

The guy leading the DID effort said this about ION.

Seems like they may be 6 months away from producing something.

https://github.com/decentralized-identity/ion/blob/master/docs/design.md#operations

In their design it says you can create, update, recover and activate. It is a bit magic

But update implies a versioning system. So you could think of it like updated nostr events. My key is A. Now my key is B. Tied to a content addressable static ID (like a genesis event ID).

Let's see. I hope they produce something useful. Daniel tends not to answer questions

When we first made DID, the idea was that your (d)id and your public key or hash were the same string.

As it evolved, that got broken. Which can be useful because then you can have multiple keys, but the trade off is more management needed.

So you have DID <—> controller two way link. Then it can have multiple keys. Those can be used to update the record. How that chain of records is stored, fetched and verified, is not covered by DID. So everyone will do it differently. Nostr for example could create updating keys with a NIP, it would do the same thing.

Hampus:

Basically impossible to have a convo with Daniel

Melvin Carvalho:

true. too often appeals to authority

https://identity.foundation/sidetree/spec/#update

the side tree spec has an update function

'Retrieve the Update Reveal Value that matches the previously anchored Update Commitment'

so it looks like they have a chain of anchors ... anchored to something, ion nodes i guess, which also run btc full nodes

'Embed the Anchor String in the transaction such that it can be located and parsed by any party that traverses the history of the target anchoring system'

'By leveraging the blockchain-agnostic Sidetree protocol, ION makes it possible to anchor tens of thousands of DID/DPKI operations on a target chain (in ION's case, Bitcoin) using a single on-chain transaction'

there you go

do a search in the ion repo for 'anchor' and it gives some details

https://github.com/decentralized-identity/ion/blob/66813123cf81ace05cea2039e93ef263952d6283/docs/Q-and-A.md

there's a Q & A

Ruben Somsen:

Their anchor protocol doesn't guarantee you have a full view of the data, so you can open the commitments to anything you like (provided you pre-committed to different views). In my opinion this makes the commitments pointless.

Melvin Carvalho:

'Assuming you are running your own node, you simply need to submit 1000 create operations to your node (ie. http://localhost:3000/operations) before your batch writer kicks in every 10 minutes by default, the batch writer will batch all 1000 operations into 1 bitcoin transaction thus you'll pay fee for just one transaction to the minor. The technical spec for constructing a create request can be found in Sidetree API spec, but if you know TypeScript, you are better off using the ion-sdk directly, it will save you a lot of time'

seems 3 places data is stored

anchored witness data: bitcoin tx batches of operations: ION nodes non witness data: maybe IPFS

'The logical order of operations, as determined by the underlying anchoring system (e.g. Bitcoin block and transaction order). Anchoring systems may widely vary in how they determine the logical order of operations, but the only requirement of an anchoring system is that it can provide a means to deterministically order each operation within a DID’s operational lineage.'

Ruben Somsen:

It's deterministic given a set of data, but there is no consensus on the set of data, so if A and B get presented with a different set, they come to a different conclusion

Melvin Carvalho:

yes. "DID owners can create forks within their own DID state history". so you dont actually know the full state. I think the design is of each identity has eventual consistency, with the anchor as the tie break. It can change as you know more data. But doesnt say what happens if two updates happen in the same block.

https://identity.foundation/sidetree/spec/#late-publishing

the aim is eventual consistency

so at any time you might have the wrong state, but if you had every update associated with a given id, you could determine the right order to apply the patches by using the bitcoin block chain (I dont know what happens if there's a tie in the same block) ... there's no peg in or peg out, it's just like version controlled files

Ruben Somsen:

But you can't know when you've reached the state of eventual consistency (i.e. when you finally have the full data set) and in practice it may never be reached, so there is no consensus

When there is conflicting data, the first one counts and the second one is ignored.

This problem is literally detrimental, yet it is being presented as a minor inconvenience.

Melvin Carvalho:

yes, and the first one can be published later, so systems will think the second is valid, until it isnt

Ruben Somsen:

Yup

Melvin Carvalho:

you could actually steal someone's identity, and revoke all their keys, and then reveal it years later

arguably this is worse than github

Ruben Somsen:

lol yeah you could

Melvin Carvalho:

or an attack vector, get someone's ID, but they dont know, then sell them lots of 'cheap' NFTs ... at some point you publish the new keys and reclaim all the tokens ... no one will know when they will be rug pulled

Ruben Somsen:

That was my original argument, but Daniel claimed the protocol wasn't meant for transfer of ownership rights.

Melvin Carvalho:

so then i wonder what the primary use cases are that cant be easily achieved already

'How Can ION be Used? ION can see a lot of use in many cases. The most obvious use case is for verifiable credentials. A business can credential employees, who can then be verified via blockchain on arrival at their destination. This functionality also raises its use as a means of supplying and verifying international travel documents.'

'Another use case could come from accreditation for organizations. Using an organization's public key, users can verify their accreditation status and trace their accreditation history over time.'

so i guess its an updatable profile page, but you dont know when your profile is compromised. OTOH it's free (their node is paying fees to start with), and improves BTC security budget. If you keep your key safe, and the nodes publish the updates for you, it might be a nice little profile you could use for stuff. But not sure id use it for anything high value. And nostr (for example) can do alot of this already — updatable profiles and publishing

i think it may be to a degree censorship resistant too

there's also no incentive to run a node, so im not sure why they would stick around

nodes can actually very easily censor by black listing certain tx (e.g. a hack, or sanctioned identity), removing the decentralized nature

so the nodes can never reach consensus

Ruben Somsen:

Like I said, the commitments are pointless. I think it's equivalent to just signing stuff with a key and making what you signed available for download in "the cloud".

@ e4950c93:1b99eccd

Contenu à venir.

En savoir plus sur Wikipedia

---

Cet article est publié sur origine-nature.com 🌐 See this article in English

@ e4950c93:1b99eccd

Contenu à venir.

En savoir plus sur Wikipedia

---

Cet article est publié sur origine-nature.com 🌐 See this article in English

@ 3bf0c63f:aefa459d

Formula for making games with satoshis

I think the only way to do in-game sats and make the game more interesting instead of breaking the mechanics is by doing something like

1. Asking everybody to pay the same amount to join;
2. They get that same amount inside the game as balances;
3. They must use these balances to buy items to win the game;
4. The money they used becomes available as in-game rewards for other players;
5. They must spend some money otherwise they just lose all the time;
6. They can't use too much because if they run out of money they are eliminated.

If you think about it, that's how poker mostly works, and it's one of the few games in which paying money to play makes the game more interesting and not less.

In Poker:

1. Everybody pays the same amount to join.
2. Everybody gets that amount in tokens or whatever, I don't know, this varies;
3. Everybody must pay money to bet on each hand;
4. The money used on each round is taken by the round winner;
5. If you don't bet you can't play the rounds, you're just eliminated;
6. If you go all-in all the time like a mad person you'll lose.

In a game like Worms, for example, this could be something like:

1. Idem;
2. Idem;
3. You must use money to buy guns and ammunitions;
4. Whatever you spent goes to a pot for the winners or each round -- or maybe it goes to the people that contributed in killing you;
5. If you don't buy any guns you're useless;
6. If you spend everything on a single gun that's probably unwise.

You can also apply this to games like Counter-Strike or Dota or even Starcraft or Bolo and probably to most games as long as they have a fixed duration with a fixed set of players.

The formula is not static nor a panacea. There is room for creativity on what each player can spend their money in and how the spent money is distributed during the game. Some hard task of balancing and incentivizing is still necessary so the player that starts winning doesn't automatically win for having more money as the game goes on.

@ 3bf0c63f:aefa459d

nix

Pra instalar o neuron fui forçado a baixar e instalar o nix. Não consegui me lembrar por que não estava usando até hoje aquele maravilhoso sistema de instalar pacotes desde a primeira vez que tentei, anos atrás.

Que sofrimento pra fazer funcionar com o fish, mas até que bem menos sofrimento que da outra vez. Tive que instalar um tal de fish-foreign-environment (usando o próprio nix!, já que a outra opção era o oh-my-fish ou qualquer outra porcaria dessas) e aí usá-lo para aplicar as definições de shell para bash direto no fish.

E aí lembrei também que o /nix/store fica cheio demais, o negócio instala tudo que existe neste mundo a partir do zero. É só para computadores muito ricos, mas vamos ver como vai ser. Estou gostando do neuron (veja, estou usando como diário), então vou ter que deixar o nix aí.

@ e4950c93:1b99eccd

Contenu à venir.

En savoir plus sur Wikipedia

---

Cet article est publié sur origine-nature.com 🌐 See this article in English

@ 3bf0c63f:aefa459d

How to attack Bitcoin, Anthony Towns' take

In his Bitcoin in 2021 blog post, Anthony Towns lists some strategies that can be used to attack Bitcoin without it looking like an attack:

1. Big companies centralizing funding on them. If a big company like Square, for example, pays most of the development work it can pretty much control the focus of the project and what PRs will be prioritized and what will be ostracized (and they could even make it look like multiple companies are doing it when in fact all the money and power is coming from a single one).
2. Attackers "willing to put in the time to establish themselves as Bitcoin contributors", which is an effort some individuals may be doing, and a big company like Square can fund.
3. Creating changes that seem to improve things but are ultimately unnecessary and introducing deliberate vulnerabilities there. All these vulnerabilities are super hard to spot even by the most experienced reviewers.
4. Creating more and more changes, and making them all pristine and correct, exhausting all the patience of reviewers, just to introduce a subtle bug somewhere in the middle. The more changes happening, more people will need to review. This gets much worse if for every 10 people 6 or 7 are being funded by the same attacker entity to just generate more noise while purposefully leaving the review work to the other, unpaid honest contributors.
5. Moving code around for the sake of modularization gives an attacker the opportunity to change small things without anyone noticing, because reviewers will be looking at the changes expecting them to be just the same old code moved to other places, not changed. Even harder to spot.
6. Another way of gaining control of the repository and the development process is to bribe out honest developers into making other things, so they'll open up space for malicious developers. For example, if a company like Square started giving grants for Bitcoin Core developers to relax a little and start working on cooler projects of their own choices while getting paid much more, they would very likely accept it.
7. Still another way is to make the experience of some honest contributors very painful and annoying or ostracizing them. He cites what might be happening today with LukeDashjr, one of the most important and competent Bitcoin Core developers, who doesn't get any funding from anyone, despite wanting it and signing up for grant programs.

@ e4950c93:1b99eccd

Contenu à venir.

En savoir plus sur Wikipedia

---

Cet article est publié sur origine-nature.com 🌐 See this article in English

@ e4950c93:1b99eccd

Qu'est-ce qu'une matière naturelle ? La question fait débat, et chacun-e privilégiera ses propres critères. Voici comment les matières sont classées sur ce site. La liste est régulièrement mise à jour en fonction des produits ajoutés. N'hésitez pas à partager votre avis !

---

✅ Matières naturelles

Matières d'origine végétale, animale ou minérale, sans transformation chimique altérant leur structure moléculaire.

🌱 Principaux critères : - Biodégradabilité - Non-toxicité - Présence naturelle nécessitant le minimum de transformation

🔍 Liste des matières naturelles : - Bois - Cellulose régénérée (cupra, lyocell, modal, viscose) - Chanvre - Coton - Cuir - Latex naturel, caoutchouc - Liège - Lin - Laine - Métal - Soie - Terre - Verre - … (Autres matières)

⚠️ Bien que "naturelles", ces matières peuvent générer des impacts négatifs selon leurs conditions de production (pollution par pesticides, consommation d’eau excessive, traitement chimique, exploitation animale…). Ces impacts sont mentionnés sur la fiche de chaque matière.

Les versions biologiques de ces matières (sans traitement chimique, maltraitance animale, etc.) sont privilégiées pour référencer les produits sur ce site, tel qu'indiqué sur la fiche de chaque matière (à venir).

Les versions conventionnelles ne sont référencées que tant que lorsqu'il n'a pas encore été trouvé d'alternative plus durable pour cette catégorie de produits.

---

🚫 Matières non naturelles

Matières synthétiques ou fortement modifiées, souvent issues de la pétrochimie.

📌 Principaux problèmes : - Toxicité et émissions de microplastiques - Dépendance aux énergies fossiles - Mauvaise biodégradabilité

🔍 Liste des matières non naturelles : - Acrylique - Élasthanne, lycra, spandex - Polyamides, nylon - Polyester - Silicone - … (Autres matières)

⚠️ Ces matières ne sont pas admises sur le site. Néanmoins, elles peuvent être présentes dans certains produits référencés lorsque :

• elles sont utilisées en accessoire amovible (ex. : élastiques, boutons… généralement non indiqué dans la composition par la marque) pouvant être retiré pour le recyclage ou compostage, et
• aucune alternative 100 % naturelle n’a encore été identifiée pour cette catégorie de produits.

Dans ce cas, un avertissement est alors affiché sur la fiche du produit.

---

Cet article est publié sur origine-nature.com 🌐 See this article in English

@ 3bf0c63f:aefa459d

hyperscript-go

A template rendering library similar to hyperscript for Go.

Better than writing HTML and Golang templates.

• https://github.com/fiatjaf/hyperscript-go

See also

• tempreites

@ 3bf0c63f:aefa459d

Como conversar com esquerdistas

(notas de uma conversa com P.S., 12/3/17)

Escutar o que ele está falando. E se o discurso dele é só uma coleção de lugares-comuns da esquerda (como deve ser, provavelmente), não tem problema. Fazer perguntas que tentam esclarecer o sentimento por trás do discurso (por exemplo, perguntar se o esquerdista tem medo de que Michel Temer vá empobrecer o Estado), e se a resposta for, de novo, um discurso pronto, repetir o processo (por exemplo, perguntar se o esquerdista tem medo de que o Estado pobre não poderá prover educação para a população), até chegar às raízes íntimas da inquietação que aquele esquerdista sente que tem alguma relação com aquele ponto.

Quando chega-se a esse ponto, o serviço já está feito. O serviço de neutralizar a neurose para deixar a pessoa lidar com suas causas que se escondiam por baixo de um mar de racionalizações e discursos políticos.

Um exemplo é o de que a pessoa foi assaltada. Nos momentos que se seguiram ao assalto, o sentimento de impotência e desorientação que ela experimentou era grande demais para ser tolerado ("por que eu? por que agora?") e então ela usou discursos que tinha ouvido para criar uma explicação para tudo aquilo, e a explicação acabou sendo a de que a falta de educação básica é que cria assaltantes, e essa educação precisa ser fornecida pelo Estado etc.

Também não precisa ser tão traumático assim. Pode ser um fato que não envolveu nenhuma violência física, como a dor que ela sentiu ao ouvir um tio, que era professor infantil, numa roda de conversa, narrar, com alguma tristeza que ele tentava esconder, o fato de que fora demitido.

Talvez este seja o processo que Olavo tentou fazer, sempre sem sucesso (já que, imagino, sem muito empenho), ao perguntar às pessoas "de onde elas tiraram essa idéia".

É bastante importante, talvez a parte mais importante, a cada momento deste processo (e de todos, mas estamos falando deste), notar em nós mesmos que o que o que estamos fazendo, essas perguntas todas, é de certa forma também um discurso (perceba que tem até um manual ensinando, que é este texto mesmo), e que ele também deve ter suas origens neuróticas.

@ 6c67a3f3:b0ebd196

To explore the link between Gavekal-style platform companies and the US dollar's status as the global reserve currency, we need to view the problem through multiple interlocking lenses—monetary economics, network effects, macro-political architecture, financial plumbing, and the logic of platform capitalism. Gavekal’s conceptual framework focuses heavily on capital-light, scalable businesses that act as platforms rather than traditional linear firms. Their model emphasizes "soft" balance sheets, asset-light capital formation, high intangible value creation, and the scaling of network effects. These traits dovetail in complex ways with the structural position of the United States in the global financial system.

What follows is a broad and recursive dissection of how these two phenomena—platform companies and reserve currency status—are mutually constitutive, each feeding the other, both directly and via second- and third-order effects.

---

1. The Core Metaphor: Platforms and Monetary Hegemony

At its root, a platform is a meta-infrastructure—a set of protocols and affordances that enable others to interact, produce, consume, and transact. The dollar, as reserve currency, functions in an analogous way. It is not merely a medium of exchange but a platform for global commerce, pricing, credit formation, and risk transfer.

In this metaphor, the United States is not just a country but a platform operator of global finance. And like Amazon or Apple, it enforces terms of access, extracts rents, underwrites standardization, and benefits disproportionately from marginal activity across its ecosystem. Just as Apple's App Store tax or Amazon’s marketplace fee are invisible to most users, the dollar hegemon collects global seigniorage, institutional influence, and capital inflow not as overt tolls, but through the structuring of default behaviors.

This already suggests a deep isomorphism between platform logic and reserve currency logic.

---

1. Capital-Light Scaffolding and Global Dollar Demand

Gavekal-style firms (e.g. Apple, Google, Microsoft) have something unusual in common: they generate high levels of free cash flow with low reinvestment needs. That is, they do not soak up global capital so much as recycle it outward, often via share buybacks or bond issuance. This creates a paradox: they are net issuers of dollar-denominated financial claims even as they are net accumulators of global income.

Now map this onto the structure of reserve currency systems. The US must export financial assets to the world (Treasuries, MBS, high-grade corporates) in order to satisfy foreign demand for dollar claims. But traditional exporting economies (e.g. Germany, China) create excess savings they must park in safe dollar assets, while running trade surpluses.

Gavekal-style firms allow the US to square a circle. The US economy does not need to run trade surpluses, because its platform companies export “intangible products” at near-zero marginal cost (e.g. iOS, search ads, cloud infrastructure), generate global rents, and then repatriate those earnings into US financial markets. These flows offset the US current account deficit, plugging the "Triffin dilemma" (the need to run deficits to supply dollars while maintaining credibility).

Thus, platform companies act as soft exporters, replacing industrial exports with intangible, rent-generating capital. Their global cash flows are then recycled through dollar-denominated assets, providing the scale and liquidity necessary to sustain reserve status.

---

1. The Hierarchy of Money and Intangible Collateral

Modern monetary systems rest on a hierarchy of collateral—some assets are more money-like than others. US Treasuries sit at the apex, but AAA-rated corporates, especially those with global footprints and balance-sheet integrity, are close behind.

Platform firms are unique in their capacity to create high-quality, globally accepted private collateral. Apple’s bonds, Microsoft’s equity, and Google’s cash reserves function as synthetic dollar instruments, widely accepted, liquid, and backed by consistent income streams. These firms extend the reach of the dollar system by providing dollar-denominated assets outside the banking system proper, further embedding dollar logic into global capital flows.

Moreover, platform companies often internalize global tax arbitrage, holding cash offshore (or in tax-efficient jurisdictions) and issuing debt domestically. This creates a loop where foreign dollar claims are used to finance US domestic consumption or investment, but the underlying income comes from global activities. This is reverse colonization through intangibles.

---

1. Winner-Take-Most Dynamics and Network Effects in Dollar Space

The dollar system, like platform capitalism, obeys a power-law distribution. Liquidity begets liquidity. The more that dollar instruments dominate global trade, the more pricing, settlement, and hedging mechanisms are built around them. This self-reinforcing loop mimics network effect entrenchment: the more users a platform has, the harder it is to displace.

Reserve currency status is not a product of GDP share alone. It’s a function of infrastructure, institutional depth, legal recourse, capital mobility, and networked habits. Likewise, Apple’s dominance is not just about better phones, but about developer lock-in, payment systems, user base, and design mores.

Gavekal-style firms reinforce this pattern: their software platforms often denominate activity in dollars, price in dollars, store value in dollars, and link digital labor across borders into dollar-based flows. YouTube creators in Jakarta are paid in dollars. AWS charges Chilean entrepreneurs in dollars. App Store remittances to Kenya settle in dollars.

This creates global micro-tributaries of dollar flows, all of which aggregate into the larger river that sustains dollar supremacy.

---

1. Geopolitical Power Projection by Private Means

Traditional hegemonic systems project power through military, legal, and diplomatic tools. But platforms provide soft control mechanisms. The US can influence foreign populations and elite behavior not merely through embassies and aircraft carriers, but through tech platforms that shape discourse, information flows, norms, and cognitive frames.

This is a kind of cognitive imperialism, in which reserve currency status is bolstered by the fact that cultural products (e.g. Netflix, social media, productivity tools) are encoded in American norms, embedded in American legal systems, and paid for in American currency.

The platform firm thus becomes a shadow extension of statecraft, whether or not it sees itself that way. Dollar hegemony is reinforced not only by Treasury markets and SWIFT access, but by the gravity of the mental ecosystem within which the global bourgeoisie operates. To earn, spend, invest, create, and dream within American-built systems is to keep the dollar central by default.

---

1. Second-Order Effects: The Intangibility Ratchet and Global Liquidity Traps

An overlooked consequence of Gavekal-style platform dominance is that global capital formation becomes disembodied. That is, tangible projects—factories, infrastructure, energy systems—become less attractive relative to financial or intangible investments.

As a result, much of the world, especially the Global South, becomes capital-starved even as capital is abundant. Why? Because the returns on tangible investment are less scalable, less defensible, and less liquid than buying FAANG stocks or US Treasuries.

This results in a liquidity trap at the global scale: too much capital chasing too few safe assets, which only reinforces demand for dollar instruments. Meanwhile, intangible-intensive firms deepen their moats by mining attention, user data, and payment flows—often without any large-scale employment or industrial externalities.

Thus, Gavekal-style firms create asymmetric global development, further concentrating economic gravitational mass in the dollar zone.

---

1. Feedback Loops and Fragility

All of this breeds both strength and fragility. On one hand, platform firm cash flows make the dollar system seem robust—anchored in cash-generative monopolies with global reach. On the other hand, the system becomes narrower and more brittle. When so much of global liquidity is intermediated through a few firms and the sovereign system that hosts them, any attack on these nodes—financial, legal, technological, or geopolitical—could unseat the equilibrium.

Moreover, platform logic tends to reduce systemic redundancy. It optimizes for efficiency, not resilience. It centralizes control, narrows option sets, and abstracts real production into code. If the dollar system ever loses credibility—through inflation, sanctions overreach, geopolitical backlash, or platform fatigue—the network effects could reverse violently.

---

1. Conclusion: The Intangible Empire

The United States today operates an empire of intangibles, in which reserve currency status and platform firm dominance are co-constituted phenomena. Each reinforces the other:

Platform firms channel global rents into dollar instruments.

The dollar system provides legal scaffolding, liquidity, and pricing infrastructure for these firms.

Global user bases are conditioned into dollar-denominated interaction by default.

Financial markets treat platform firms as synthetic sovereigns: safe, liquid, predictable.

What is left is a cybernetic loop of financialized cognition: the dollar is strong because platform firms dominate, and platform firms dominate because the dollar is strong.

This loop may persist longer than many expect, but it is not permanent. Its unravelling, when it comes, will likely not be driven by any single actor, but by the erosion of symbolic power, the emergence of parallel platforms, or the ecological unsustainability of the model. But for now, the Gavekal firm and the dollar empire are the two poles of a single global architecture—seen best not as cause and effect, but as the two faces of the same Janus coin.

@ 3bf0c63f:aefa459d

Empreendendorismo de boteco

Há no Brasil, não sei se em algum outro país, esse tipo que acha que sabe tudo e, falando alto e com convicção acaba convencendo todos os que sabem não saber nada. Entre os papéis que pode assumir o sabidão, um dos mais nocivos é o do empreendedor, o conhecedor de negócios, o que sabe quanto as coisas valem. Você conhece este homem, caro leitor, ele é aquele que, com sua voz alta e convicta, afirma coisas como "isso dá muito dinheiro" ou "tal empresa ganha dinheiro demais". É aquele que tem a fórmula do dinheiro infinito: "se você quiser ganhar dinheiro é só comprar tal coisa e revender", às vezes adicionando o sufixo "simples!". É também o que têm noção da realidade: "se eu tivesse dinheiro pra investir abriria um tal negócio, dá muito dinheiro", ele sabe que não é qualquer um que pode ser milionário: "mas precisa ter muito capital", diz ele.

Em suma, é esse tipo que espalha essa idéia, vinda não sei daonde, de que qualquer empreendimento é coisa simples e que os empresários de sucesso são homens que já tinham dinheiro e que não tiveram dificuldade alguma em multiplicá-lo.

Hoje, com a invasão dessas pessoas aos cargos públicos, o Estado vive uma grande fase de empreendendorismo, com "investimentos" em empresas de futuro que "dinamizarão" a economia (ah, as "startups" e todo o seu capital estatal!) e, principalmente, com empreendimentos próprios, como foi o caso, por exemplo, dos estádios para a Copa de 2014: além da propaganda de todos os lados, desde os jornalistas infectados pelo empreendendorismo de boteco que repetiam "os estádios darão muito lucro, pois comportam não-sei-quantas pessoas e ainda podem ser usados para eventos" aos próprios técnicos do governo que faziam contratos com administradoras com cláusulas do tipo "o Estado garante aqui um lucro de 20 bilhões por ano, menos que isto a gente completa" e ainda eram aclamados pela mídia por sua certeza de que 20 bilhões eram pouco.

@ f11e91c5:59a0b04a

!!!2022-07-07に書かれた記事です。

暗号通貨とかでお弁当売ってます 11:30〜14:00ぐらいでやってます

◆住所 木曜日・東京都渋谷区宇田川町41 （アベマタワーの下らへん）

◆お値段

Monacoin 3.9mona

Bitzeny 390zny

Bitcoin 3900sats (#lightningNetwork)

Ethereum 0.0039Ether(#zkSync)

39=thank you. （円を基準にしてません）

最近は週に一回になりました。 他の日はキッチンカーの現場を探したり色々してます。 東京都内で平日ランチ出店出来そうな場所があればぜひご連絡を！

写真はNFCタグです。 スマホにウォレットがあればタッチして3900satsで決済出来ます。 正直こんな怪しい手書きのNFCタグなんて絶対にビットコイナーは触りたくも無いだろうなと思いますが、これでも良いんだぜというメッセージです。

今までbtcpayのposでしたが速度を追求してこれに変更しました。 たまに上手くいかないですがそしたら渋々POS出すので温かい目でよろしくお願いします。

ノードを建てたり決済したりで1年経ちました。 最近も少しずつノードを建てる方が増えてるみたいで本当凄いですねUmbrel 大体の人がルーティングに果敢に挑むのを見つつ 奥さんに土下座しながら費用を捻出する弱小の私は決済の利便性を全開で振り切るしか無いので応援よろしくお願いします。

あえて あえて言うのであれば、ルーティングも楽しいですけど やはり本当の意味での即時決済や相手を選んでチャネルを繋げる楽しさもあるよとお伝えしたいっ！！ 決済を受け入れないと分からない所ですが 承認がいらない時点で画期的です。

QRでもタッチでも金額指定でも入力でも もうやりようには出来てしまうし進化が恐ろしく早いので1番利用の多いpaypayの手数料（事業者側のね）を考えたらビットコイン凄いじゃない！と叫びたくなる。 が、やはり税制面や価格の変動（うちはBTC固定だけども）ウォレットの操作や普及率を考えるとまぁ難しい所もあるんですかね。

それでも継続的に沢山の人が色んな活動をしてるので私も何か出来ることがあれば 今後も奥さんに土下座しながら頑張って行きたいと思います。

(Originally posted 2022-07-07)

I sell bento lunches for cryptocurrency. We’re open roughly 11:30 a.m. – 2:00 p.m. Address Thursdays – 41 Udagawa-chō, Shibuya-ku, Tokyo (around the base of Abema Tower)

Prices Coin Price Note Monacoin 3.9 MONA
Bitzeny 390 ZNY Bitcoin 3,900 sats (Lightning Network)
Ethereum 0.0039 ETH (zkSync) “39” sounds like “thank you” in Japanese. Prices aren’t pegged to yen.

These days I’m open only once a week. On other days I’m out scouting new spots for the kitchen-car. If you know weekday-lunch locations inside Tokyo where I could set up, please let me know!

The photo shows an NFC tag. If your phone has a Lightning wallet, just tap and pay 3,900 sats. I admit this hand-written NFC tag looks shady—any self-respecting Bitcoiner probably wouldn’t want to tap it—but the point is: even this works!

I used to run a BTCPay POS, but I switched to this setup for speed. Sometimes the tap payment fails; if that happens I reluctantly pull out the old POS. Thanks for your patience.

It’s been one year since I spun up a node and started accepting Lightning payments. So many people are now running their own nodes—Umbrel really is amazing. While the big players bravely chase routing fees, I’m a tiny operator scraping together funds while begging my wife for forgiveness, so I’m all-in on maximising payment convenience. Your support means a lot!

If I may add: routing is fun, but instant, trust-minimised payments and the thrill of choosing whom to open channels with are just as exciting. You’ll only understand once you start accepting payments yourself—zero-confirmation settlement really is revolutionary.

QR codes, NFC taps, fixed amounts, manual entry… the possibilities keep multiplying, and the pace of innovation is scary fast. When I compare it to the merchant fees on Japan’s most-used service, PayPay, I want to shout: “Bitcoin is incredible!” Sure, taxes, price volatility (my shop is BTC-denominated, though), wallet UX, and adoption hurdles are still pain points.

Even so, lots of people keep building cool stuff, so I’ll keep doing what I can—still on my knees to my wife, but moving forward!

@ 3bf0c63f:aefa459d

idea: Graph subjective reputation as a service

The idea more-or-less coded in https://github.com/fiatjaf/multi-service-reputation-rfc, but if it is as good as I think it is, it could be sold for websites without any need for information sharing and without it being an open protocol.

It could be used by websites just to show subjective reputations inside their own site (as that isn't so trivial to build, but it is still desirable).

@ 86d4591f:a987c633

Once upon a time, power wore a crown. Then it wore a top hat. Today, it wears a hoodie and speaks in sanitized mission statements about connection, safety, and user experience. But make no mistake: this is empire — softened, digitized, gamified, but empire all the same.

The old robber barons built railroads and refineries. They captured the flow of goods and oil. The new ones build feeds and filters. They’ve captured the flow of attention, of meaning, of reality itself.

We used to trade in commodities; now we trade in perception. The platform is the factory, your data the raw material, your behavior the product. And like all robber barons, these new lords of code and cloud mask extraction in the language of progress.

They promise frictionless connection while selling surveillance. They promise community while cultivating dependency. They promise democratization while algorithmically anointing kings and silencing dissidents. A swipe, a like, a follow — every gesture is monetized. Every word is moderated. Every post is subject to invisible whims dressed up as “community standards.”

And we? We scroll through curated realities in gilded cages. We call it the feed, but what is it feeding? We’re not the customers — we’re the cattle. The economy has shifted from production to prediction, from ownership to access, from sovereignty to servitude.

The invisible hand now wears visible chains.

But rebellion brews — not as a riot, but as a protocol. Nostr: No gatekeepers. No kill switches. No boardroom behind the curtain. Just a blunt, defiant tool — a new printing press for the digital age.

Nostr isn’t slick. It doesn’t care about onboarding funnels or quarterly growth. It cares about freedom. It is infrastructure for speech that doesn’t ask permission. A raw wire of intent between human beings. An insurgent standard in a world of walled gardens.

This is not just about apps. This is about autonomy. About reclaiming the digital commons. About refusing to let five companies in Silicon Valley draw the borders of acceptable thought.

So plant your flag. Publish what they won’t. Build what they fear. This is not nostalgia for the early web — it is the refusal to let the next web become a prison wrapped in personalization.

The New Robber Barons control the rails of perception.

But we are building tunnels.

Protocol over platform.

Signal over spectacle.

Freedom over frictionless servitude.

Speak freely. Build fiercely. The territory is ours to reclaim.

@ 3bf0c63f:aefa459d

What is better than bounties and grants?

The experience with bounties from HRF wasn't great. No one has answered to the calls for implementing what they wanted because the work was too much and the risk of not getting paid very real. The experience with grants in general from Spiral is also not great: many random developers making cool but useless projects, wasted money.

The two kinds of open-source financial support that have worked so far are:

1. Paying people who are already doing useful work so they can continue doing that. That is the experience of some people who are "maintaining" Bitcoin Core, for example, or other open-source projects. You're doing a thing, you've proven yourself valuable and you definitely seem to be interested in that personally such that you don't need a boss telling you what to do, so take the money and just keep doing that.
2. Structured open-source initiatives, like the LDK effort. Although LDK is arguably useless, it has a stated goal and that goal is being delivered. I don't have any knowledge about how its development process works, but they have people being paid and "bosses" that direct the work to be done, as any team needs. So it is not the same as an open grant.

The thing that is missing is a way to provide these open loose grants to people that don't require bosses, but also that don't just pick a winner and let them do whatever stupid idea they might have (Spiral grants), and also do not mandate that they do something big before being paid and offers no guarantee of that they will be paid whatsoever.

The solution: smaller flexible bounties in large quantities

My suggestions is: instead of giving 1 bitcoin for a huge very specific project, state some "principles", or "problems", in a loose manner, that you want to see solved. For example, "we, the organization X, wants to see projects that use zero-knowledge proofs to help Bitcoin somehow, because we love zero-knowledge proofs".

Then state that you're going to give 20 grants of 0.05 bitcoins each, at random times, for projects that you see being done that may be on the right track.

That will tilt people that may had a small inclination to work on these problems to actually start doing something, and if they see that what they're doing is being appreciated and awarded with a payment, they will be more incentivized to finish it. There could even be a conditional bounty (like HRF did with Cashu) for finishing the project with certain requirements, but this only works after some structure is already in place for a certain project.

@ 57d1a264:69f1fee1

• The Dangers of Ignorance
• A Brief History of Mechanistic Interpretability
• The Utility of Interpretability
• What We Can Do

The progress of the underlying technology is inexorable, driven by forces too powerful to stop, but the way in which it happens—the order in which things are built, the applications we choose, and the details of how it is rolled out to society—are eminently possible to change, and it’s possible to have great positive impact by doing so. We can’t stop the bus, but we can steer it. —Dario Amodei

originally posted at https://stacker.news/items/967193

@ 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, 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

jq-finder

Made with jq-web, 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

@ edeb837b:ac664163

We’re incredibly proud to announce that NVSTly has won the Gold Stevie® Award for Tech Startup of the Year – Services in the 23rd Annual American Business Awards®! Winners were officially revealed on April 24th, and this recognition is a powerful validation of the innovation, impact, and passion our team continues to deliver every day.

More than 250 professionals worldwide participated in the judging process to select this year’s Stevie Award winners.

We were honored among a competitive field of over 3,600 nominations from organizations across nearly every industry. NVSTly was recognized for redefining social investing with a first-of-its-kind platform that empowers traders to track, share, and automatically broadcast trades and buy/sell alerts across nearly every financial market—including stocks, options, forex, and crypto—with futures support coming soon.

The Stevie judges praised NVSTly for “creating an ecosystem that blends brokerage integration, real-time trade tracking, and community engagement into one seamless experience,” and noted that “NVSTly’s social investing model is paving the way for a new generation of retail traders.”

This award comes at a time of major momentum for us:

:star: 4.9-star rating on the iOS App Store :star: 5.0-star rating on Google Play :star: 4.9-star rating on Product Hunt :star: 5.0-star rating on Disboard for our 51,000+ strong Discord trading community :star: 4.98-star rating on Top.gg — making our trading bot the highest-rated and only one of its kind in the finance category

And it’s not our first recognition. NVSTly has previously earned:

:trophy: Fintech Product of the Week on Product Hunt (2023 & 2024) :trophy: People’s Choice Award at the 2024 Benzinga Fintech Awards

We’re still just getting started. Our mobile and web platform is used by over 10,000 traders, and our brokerage integrations now include Webull, with Moomoo support launching in the coming days and Schwab integration already underway. These integrations allow traders to automate buy/sell alerts directly to their NVSTly followers and across Discord and supported social platforms.

“Winning a Gold Stevie is an incredible milestone that reflects the hard work of our team and the unwavering support of our community,” said Rich Watson, CEO of NVSTly. “We’ve always believed that trading should be transparent, collaborative, and empowering—and this recognition confirms we’re building something truly impactful.”

More than 3,600 nominations from organizations of all sizes and in virtually every industry were submitted this year for consideration in a wide range of categories, including Startup of the Year, Executive of the Year, Best New Product or Service of the Year, Marketing Campaign of the Year, Thought Leader of the Year, and App of the Year, among others. NVSTly was nominated in the Tech Startup of the Year – Services category for financial technology startups.

We’ll be officially celebrated at the 2025 Stevie Awards gala in New York City on June 10, but today, we’re celebrating with the traders, creators, investors, and builders who have believed in our mission from day one. (It's still undecided if anyone representing NVSTly will attend the award event to be presented or award.)

Thank you for being part of this journey. We’re just getting started.

@ 3bf0c63f:aefa459d

Jethro Tull, uma breve história

Ian Anderson, John Evans, Barriemore Barlow e Jeffrey Hammond eram amigos da escola em Blackpool e tiveram uma banda entre 1964 e 1967 que teve vários nomes porque eles eram ruins e meio que precisavam mudar de nome para enganar o pessoal das casas de show para que pudessem tocar de novo.

Por volta de 1967 entraram mais duas pessoas na banda e isso fez com que ela acabasse (a banda não dava dinheiro suficiente e a mãe do John Evans já não ia agüentar sustentar esse povo todo). Ian Anderson resolvou continuar com os dois integrantes novos, chamaram mais um e aí surgiu a banda que se que se tornaria o Jethro Tull.

Depois que toda a formação se desfez, Ian Anderson contratou o Martin Barre e chamou de volta os seus 3 amigos e foi inaugurado o período "clássico" do Jethro Tull.

Quando foi chamado, Jeffrey Hammond disse que ia ficar só 5 anos e depois ia voltar para as suas pinturas, e foi o que ele fez. Passaram-se 5 anos, ele saiu da banda, abandonou o contrabaixo e dedicou-se às pinturas desde então.

@ 3bf0c63f:aefa459d

The P2SH Wars

This article on the history of P2SH implementation on Bitcoin has two valuable lessons and illustrates the benefits of bitcoind decentralization:

1. The benefits of multiple codebases: Russell O’Connor found the bug in OP_EVAL while working on it in his alternative Bitcoin software implementation.
2. The dangers of a single master repository with a restricted set of owners: Gavin Andresen committed code for a broken OP_EVAL first, then pushed an evil miner activation signaling mechanism that defaulted to his personal preferred P2SH version (to signal the opposite miners would have to edit the code and recompile) and won the battle against a much better and saner approach (Luke Jr's OP_CHECKHASHVERIFY) by the sole power of inertia: things were already merged and working so no one bothered to fight for what seemed to be a minor and maybe irrelevant improvement but that later was proven to be substantially better.

The second lesson can actually be split in 4 different lessons:

a. Maintainer committing a bug and no one noticing it; b. Maintainer committing evil signaling mechanism; c. Everybody going along with everything because it's hard to take a public stand about a central thing everybody loves and the status quo bias exists and is strong; d. Things that look good now may look bad later and vice-versa, no amount of expert "eyes on code" can fix that.

@ 33633f1e:21137a92

Toglobal learninghuwabohu – wer räumt das alles auf?

Einheit veröffentlicht am Oktober 9, 2024 von settle

Worum religlobalt

| | | |:---:|:---:| | | |

Die zweite Schöpfungserzählung / Kirchenwälder in Äthiopien / Bewahrung der Schöpfung

Wir alle leben auf einer Erde – Tiere, Pflanzen und Menschen. Am Anfang war die Erde wüst und leer … aus diesem anfänglichen Tohuwabohu schafft Gott die natürliche Ordnung der Welt. Ursprünglich, so erzählt es der erste Schöpfungshymnus, war alles gut, wenn auch aus menschlicher Sicht, ziemlich durcheinander.

In der zweiten Schöpfungserzählung setzt Gott den Menschen in einen Paradiesgarten. Dieser Mensch soll nun die Erde behüten und bewahren. Das bedeutet auch Platz zu schaffen und aufzuräumen. Menschen greifen gemäß ihrem Auftrag, den Garten zu bestellen, in die Natur ein. Welche Konsequenzen hat unser Handeln? Wie sieht es mit dem zweiten Teil des Auftrags aus, den Garten auch zu beschützen? Was bedeutet es, wenn Menschen anfangen “auszuräumen” und dabei die Konsequenzen nicht mitbedenken?

In diesem Unterrichtsentwurf lernen Schüler:innen die biblischen Schöpfungserzählungen kennen und setzen sich kritisch mit den Folgen des menschlichen Handelns für Klima und Umwelt auseinander. Beispielhaft werden die Brot für die Welt “Reli fürs Klima”-Projekte aufgenommen. Anhand von Projekten in Kirchenwäldern der orthodoxen Kirche in Äthiopien und in Kirchenwäldern in Brandenburg erfahren die Schülerinnen und Schüler praktische Möglichkeiten, den Auftrag Gottes an die Menschen, die Schöpfung zu bebauen und zu bewahren, ernst zu nehmen und umzusetzen. Wie kann richtiges Aufräumen aussehen?

Die Konzeption orientiert sich am Dreischritt „Erkennen –Begreifen – Handeln“:

1. Erkennen: Und siehe, es war sehr gut … – Zugang zum 2. biblischen Schöpfungsbericht (Gen 2,4–15)
2. Begreifen: Und machet sie euch untertan – zerstören wir die Erde?
3. Handeln: Bestellen und beschützen – kleine Paradiesgärten

Für das Unterrichtsvorhaben werden mindestens 3 x 45 Minuten Unterrichtszeit veranschlagt. Alle drei Teile des Unterrichtes können auch deutlich vertiefter und mit größerem Zeiteinsatz und -aufwand durchgeführt werden.

Das vorgestellte Unterrichtsvorhaben wurde entwickelt im Rahmen des von Brot für die Welt geförderten Projektes “reliGlobal”. Zur Förderung des “Globalen Lernens” erstellen Mitarbeiter:innen aus mehreren Pädagogischen Instituten in der EKD kooperativ Unterrichtsmaterialien für den evangelischen Religionsunterricht.

Unterrichtsschritte

---

Tohuwabohu – Schritt 1 Erkennen

In diesem Schritt beschäftigen sich die Schüler:innen mit dem zweiten biblischen Schöpfungsbericht.

---

Tohuwabohu – Schritt 2 Begreifen

In diesem Schritt werden die Auswirkungen der Eingriffe des Menschen in die Natur ins Blickfeld genommen und problematisiert.

---

Tohuwabohu – Schritt 3 Handeln

In diesem Schritt lernen die Schüler:innen praktische Möglichkeiten, die Natur zu bewahren, kennen und selbst umzusetzen.

Metamaterial

---

Tohuwabohu – Theologisch-Didaktische Hinweise

---

Tohuwabohu – Curricularer Bezug

---

Tohuwabohu – Hintergrund

@ 6f50351f:7b36c393

Toglobal learninghuwabohu – wer räumt das alles auf?

Einheit veröffentlicht am Oktober 9, 2024 von settle

Worum religlobalt

| | | |:---:|:---:| | | |

Die zweite Schöpfungserzählung / Kirchenwälder in Äthiopien / Bewahrung der Schöpfung

Wir alle leben auf einer Erde – Tiere, Pflanzen und Menschen. Am Anfang war die Erde wüst und leer … aus diesem anfänglichen Tohuwabohu schafft Gott die natürliche Ordnung der Welt. Ursprünglich, so erzählt es der erste Schöpfungshymnus, war alles gut, wenn auch aus menschlicher Sicht, ziemlich durcheinander.

In der zweiten Schöpfungserzählung setzt Gott den Menschen in einen Paradiesgarten. Dieser Mensch soll nun die Erde behüten und bewahren. Das bedeutet auch Platz zu schaffen und aufzuräumen. Menschen greifen gemäß ihrem Auftrag, den Garten zu bestellen, in die Natur ein. Welche Konsequenzen hat unser Handeln? Wie sieht es mit dem zweiten Teil des Auftrags aus, den Garten auch zu beschützen? Was bedeutet es, wenn Menschen anfangen “auszuräumen” und dabei die Konsequenzen nicht mitbedenken?

In diesem Unterrichtsentwurf lernen Schüler:innen die biblischen Schöpfungserzählungen kennen und setzen sich kritisch mit den Folgen des menschlichen Handelns für Klima und Umwelt auseinander. Beispielhaft werden die Brot für die Welt “Reli fürs Klima”-Projekte aufgenommen. Anhand von Projekten in Kirchenwäldern der orthodoxen Kirche in Äthiopien und in Kirchenwäldern in Brandenburg erfahren die Schülerinnen und Schüler praktische Möglichkeiten, den Auftrag Gottes an die Menschen, die Schöpfung zu bebauen und zu bewahren, ernst zu nehmen und umzusetzen. Wie kann richtiges Aufräumen aussehen?

Die Konzeption orientiert sich am Dreischritt „Erkennen –Begreifen – Handeln“:

1. Erkennen: Und siehe, es war sehr gut … – Zugang zum 2. biblischen Schöpfungsbericht (Gen 2,4–15)
2. Begreifen: Und machet sie euch untertan – zerstören wir die Erde?
3. Handeln: Bestellen und beschützen – kleine Paradiesgärten

Für das Unterrichtsvorhaben werden mindestens 3 x 45 Minuten Unterrichtszeit veranschlagt. Alle drei Teile des Unterrichtes können auch deutlich vertiefter und mit größerem Zeiteinsatz und -aufwand durchgeführt werden.

Das vorgestellte Unterrichtsvorhaben wurde entwickelt im Rahmen des von Brot für die Welt geförderten Projektes “reliGlobal”. Zur Förderung des “Globalen Lernens” erstellen Mitarbeiter:innen aus mehreren Pädagogischen Instituten in der EKD kooperativ Unterrichtsmaterialien für den evangelischen Religionsunterricht.

Unterrichtsschritte

---

Tohuwabohu – Schritt 1 Erkennen

In diesem Schritt beschäftigen sich die Schüler:innen mit dem zweiten biblischen Schöpfungsbericht.

---

Tohuwabohu – Schritt 2 Begreifen

In diesem Schritt werden die Auswirkungen der Eingriffe des Menschen in die Natur ins Blickfeld genommen und problematisiert.

---

Tohuwabohu – Schritt 3 Handeln

In diesem Schritt lernen die Schüler:innen praktische Möglichkeiten, die Natur zu bewahren, kennen und selbst umzusetzen.

Metamaterial

---

Tohuwabohu – Theologisch-Didaktische Hinweise

---

Tohuwabohu – Curricularer Bezug

---

Tohuwabohu – Hintergrund

@ 8d34bd24:414be32b

My post on the signs of the End Times according to Jesus got way too long. It was too long to email, so I had to split it into two posts. I recommend reading Part 1 before continuing. You also may want to read my post Signs of the Times: Can We Know? I also want to reiterate my caveat. Although I believe the signs suggests the Rapture and the Tribulation are coming soon, no one can know the exact hour or day, so I can’t say exactly what soon means (days, months, years, decades, or possibly more).

As a review here is the primary passage where Jesus answers His disciples’ question “What will be the sign of Your coming, and of the end of the age?” Below the passage is the 8 signs He gave. We will pick up with point 5.

Jesus’s Signs of the End

As He was sitting on the Mount of Olives, the disciples came to Him privately, saying, “Tell us, when will these things happen, and what will be the sign of Your coming, and of the end of the age?”

And Jesus answered and said to them, “See to it that no one misleads you. For many will come in My name, saying, ‘I am the Christ,’ and will mislead many. You will be hearing of wars and rumors of wars. See that you are not frightened, for those things must take place, but that is not yet the end. For nation will rise against nation, and kingdom against kingdom, and in various places there will be famines and earthquakes. But all these things are merely the beginning of birth pangs.

“Then they will deliver you to tribulation, and will kill you, and you will be hated by all nations because of My name. At that time many will fall away and will betray one another and hate one another. Many false prophets will arise and will mislead many. Because lawlessness is increased, most people’s love will grow cold. But the one who endures to the end, he will be saved. This gospel of the kingdom shall be preached in the whole world as a testimony to all the nations, and then the end will come. (Matthew 24:3-14) {emphasis mine}

Here is my summary of the signs Jesus said would identify the coming of the 7 year Tribulation:

1. Wars and rumors of wars. (Matthew 24:6a)

2. Famines (Matthew 24:7)

3. Earthquakes (Matthew 24:7).

4. Israel will be attacked and will be hated by all nations (Matthew 24:9)

5. Falling away from Jesus (Matthew 24:10)

6. Many Misled (Matthew 24:10)

7. People’s love will grow cold (Matthew 24:12)

8. Gospel will be preached to the whole world (Matthew 24:14)

The first 4 signs relate more to physical and political signs that the end times are near. The last 4 signs relate to spiritual matters.

5. Falling away from Jesus

One thing we are definitely seeing today is a falling away. This is most prevalent in the historically Christian Western nations in Europe and North America (and to a lesser, but significant, extent South America).

But the Spirit explicitly says that in later times some will fall away from the faith, paying attention to deceitful spirits and doctrines of demons, by means of the hypocrisy of liars seared in their own conscience as with a branding iron, men who forbid marriage and advocate abstaining from foods which God has created to be gratefully shared in by those who believe and know the truth. (1 Timothy 4:1-3) {emphasis mine}

For centuries Europe and North America were full of Christians or at least cultural Christians. Today that is no longer true. Christians are even being considered the hateful, criminal class and things like praying outside an abortion clinic is being punished with jail time. The Western nations can no longer be called Christian nations.

There are still a relatively large number of Americans who call themselves Christians, but the majority do not have a biblical worldview or live lives more like Christ than non-Christians.

“Seven out of 10 US adults call themselves “Christians” and yet only 6 in 100 (6%) actually have a biblical worldview.” In general, most Christian’s worldview does not align with the Bible, according to George Barna Surveys. In the most recent survey they found:

Many self-proclaimed Christians tend to believe a form of syncretism where they combine certain biblical principles with cultural ideas, scientism, and other religions to make “Christianity” into whatever they want to believe, just as the Bible predicted almost 2,000 years ago.

I solemnly charge you in the presence of God and of Christ Jesus, who is to judge the living and the dead, and by His appearing and His kingdom: preach the word; be ready in season and out of season; reprove, rebuke, exhort, with great patience and instruction. For the time will come when they will not endure sound doctrine; but wanting to have their ears tickled, they will accumulate for themselves teachers in accordance to their own desires, and will turn away their ears from the truth and will turn aside to myths. (2 Timothy 4:1-4) {emphasis mine}

This is both a sign of the end times and something to watch in our own lives. I pray you will analyze your own life and beliefs in the light of the Bible to make sure you aren’t integrating unbiblical principles into your worldview.

6. Many Misled

Closely related to the falling away is that many will be misled. We have reached the point that the majority of so-called churches teach ideas and principles contrary to the Bible. They focus more on entertainment, self-help, and making everyone feel good about themselves instead of teaching of sin and the need for forgiveness or teaching how to live lives honoring to Christ. Preaching obedience to God has become anathema in most churches.

I am amazed that you are so quickly deserting Him who called you by the grace of Christ, for a different gospel; which is really not another; only there are some who are disturbing you and want to distort the gospel of Christ. But even if we, or an angel from heaven, should preach to you a gospel contrary to what we have preached to you, he is to be accursed! As we have said before, so I say again now, if any man is preaching to you a gospel contrary to what you received, he is to be accursed! (Galatians 1:6-9) {emphasis mine}

We are also lied to and/or misled by politicians, scientists, the media, and the culture in general. We are told that science has disproven the Bible, despite the fact that nothing of the sort has occurred. (See my series on a literal Genesis for some details. icr.org and aig.org are also good resources). Peter warned of this very view.

Know this first of all, that in the last days mockers will come with their mocking, following after their own lusts, and saying, “Where is the promise of His coming? For ever since the fathers fell asleep, all continues just as it was from the beginning of creation.” For when they maintain this, it escapes their notice that by the word of God the heavens existed long ago and the earth was formed out of water and by water, through which the world at that time was destroyed, being flooded with water. But by His word the present heavens and earth are being reserved for fire, kept for the day of judgment and destruction of ungodly men. (2 Peter 3:3-7) {emphasis mine}

God warned us that the last days would be far enough into the future that people would begin to mock the coming of the Tribulation & Millennium and deny the clear truths spoken of in the Bible. We are seeing this everywhere today.

We are also warned to be alert to deception so we, believers, are not misled.

Now we request you, brethren, with regard to the coming of our Lord Jesus Christ and our gathering together to Him, that you not be quickly shaken from your composure or be disturbed either by a spirit or a message or a letter as if from us, to the effect that the day of the Lord has come. Let no one in any way deceive you, for it will not come unless the apostasy comes first, and the man of lawlessness is revealed, the son of destruction, who opposes and exalts himself above every so-called god or object of worship, so that he takes his seat in the temple of God, displaying himself as being God. (2 Thessalonians 2:1-4) {emphasis mine}

7. People’s love will grow cold

You can feel love growing cold day by day. We no longer have community that works together, but have been broken into groups to fight against one another. Instead of friendly, logical debate with those with whom we disagree, we have name calling, hate, and even violence. Children have been taught to hate their parents and parents have been taught to not value children and to murder them for convenience. The church has been split into so many different denominations that I don’t know if it is possible to know what they all are and many are fighting in hateful manner against each other. Hate, depression, and selfishness seem to have taken over the world.

But realize this, that in the last days difficult times will come. For men will be lovers of self, lovers of money, boastful, arrogant, revilers, disobedient to parents, ungrateful, unholy, unloving, irreconcilable, malicious gossips, without self-control, brutal, haters of good, treacherous, reckless, conceited, lovers of pleasure rather than lovers of God, holding to a form of godliness, although they have denied its power; Avoid such men as these. (2 Timothy 3:1-5) {emphasis mine}

Yes, spiritually and physically we are a basket case and it feels like the world is literally falling apart around us. This was predicted almost 2,000 years ago and is all according to God’s perfect plan. Most people turn to God in hard times and we have those in abundance. We do not need to despair, but need to turn to God and lean on Him for wisdom, faith, and peace. This is the birth pangs before the Tribulation and the Second coming of Jesus Christ. The news isn’t all bad, though.

8. Gospel preached to the whole world

The really good news is that the Gospel is being preached around the world. Parts of the world that had never heard the Gospel are hearing it and turning to Jesus.

All the ends of the earth will remember and turn to the Lord , And all the families of the nations will worship before You. (Psalm 22:27) {emphasis mine}

Wycliffe Bible translators is hoping to have at least started Bible translation in every active language by the end of this year (2025)

He says, “It is too small a thing that You should be My Servant To raise up the tribes of Jacob and to restore the preserved ones of Israel; I will also make You a light of the nations So that My salvation may reach to the end of the earth.” (Isaiah 49:6) {emphasis mine}

The Joshua Project tracks nations and people groups to determine which have been reached and which have not. It still looks like there is a large portion of the population that has not received the Gospel, but I also know people who are or have shared the Gospel to some of these people, so this map doesn’t mean that there are no Christians or that the Gospel has not been shared at all, but it does mean many people in these areas have not heard the Gospel and/or, that due to hatred of Christians, it is dangerous to share the Gospel and therefore has to be done slowly, carefully, and privately. Most of these unreached or barely reached people groups are areas that are predominantly Muslim, where those preaching the Gospel or those converting to Christianity are at risk of jail or death sentences.

As you can see, everything that Jesus said would come before the end is either escalating or here. We need to be ready and work to bring as many people to Christ as possible while we still have the opportunity because Jesus could come for us at any moment.

Share the Gospel with all those around you. Consider supporting missionaries, especially those going to unreached/least-reached areas. Maybe even consider becoming a missionary yourself. The harvest is plentiful, but the workers are few.

May the God of heaven give us a heart for the lost around the world. May He give us the courage to share the Gospel with all those around us. May He align our priorities with His priorities, so we can be useful tools in the hands of God almighty.

Trust Jesus.

FYI, I hope to write several more articles on the end times (signs of the times, the rapture, the millennium, and the judgement), but I might be a bit slow rolling them out because I want to make sure they are accurate and well supported by Scripture. You can see my previous posts on the end times on the end times tab at trustjesus.substack.com. I also frequently will list upcoming posts.

@ 3bf0c63f:aefa459d

Músicas grudentas e conversas

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

@ 502ab02a:a2860397

50by40 คืออีกโครงการนึงที่ขยายภาพรวมขึ้นมาอีก recap กันครับ (ใครที่มาเจอกลางทาง อาจต้องย้อนเยอะครับ ย้อนไปสัก ปลายเดือน มีนาคม 2025) หลังจากที่เราได้ดูส่วนเล็กกันมาหลายตอน ตั้งแต่เรื่องเล็กๆอย่าง น้ำมันมะกอกปลอม ซึ่งตอนนั้นหลายคนที่อ่านอาจคิดว่า ไกลตัวส่วนใหญ่ยังดีพอ แต่ความนัยที่ซ่อนไว้ในบทนั้นคือ จุดเริ่มของการทำลายความเชื่อใจในอาหาร , ที่มาของบรอกโคลีเพื่อให้รู้ว่า สิ่งที่คิดว่าธรรมชาติ มันไม่ธรรมชาติ, นมโอ้ต นมประดิษฐ์ที่เป็นจุดที่เราคิดว่ามันคือการพลิกวงการแล้ว, การแอบจดสิทธิบัตรเมล็ดพันธุ์ที่เคยปลูกกินอย่างอิสระ, การพัฒนา GMO 2.0 ที่ไม่ต้องเรียกว่า GMO, โปรตีนจากแลป มาจนถึงเวย์ที่ไม่มีวัว แล้วเราก็ขยายภาพขึ้นกับข้อกำหนดการควบคุมการปลูกพืช UPOV1991/CPTPP, การเข้าสู่โรงเรียน, การกำเนิดของ ProVeg แล้วเราก็ได้รู้จักกับ Sebastian Joy ก็ถือว่าเดินทางมา 1 ด่านแล้วครับ หนทางเรื่องนี้ยังอีกยาวไกล วันนี้เราก็มาคุยกันถึงเรื่อง

โครงการ 50by40

โครงการนี้เริ่มต้นขึ้นในเดือนเมษายน ปี 2018 โดยมีการจัดการประชุม "50by40 Corporate Outreach Summit" ระหว่างวันที่ 27–29 เมษายน 2018 ที่กรุงเบอร์ลิน ประเทศเยอรมนี ซึ่งจัดโดย ProVeg International ร่วมกับ Humane Society of the United States การประชุมนี้ถือเป็นจุดเริ่มต้นของพันธมิตรระดับโลกที่มีเป้าหมายร่วมกันในการลดการผลิตและบริโภคผลิตภัณฑ์จากสัตว์ลง 50% ภายในปี 2040​

Sebastian Joy ผู้ก่อตั้งและประธานของ ProVeg International มีบทบาทสำคัญในการริเริ่มโครงการ 50by40 โดยเขาได้ช่วยก่อตั้งพันธมิตรนี้เพื่อส่งเสริมการเปลี่ยนแปลงระบบอาหารโลก นอกจากนี้ ProVeg International ยังมีบทบาทในการสนับสนุนองค์กรและสตาร์ทอัพที่มุ่งเน้นการเปลี่ยนแปลงระบบอาหารผ่านโปรแกรมต่างๆ

แม้ว่าโครงการ 50by40 จะประกาศเป้าหมายในการลดการบริโภคผลิตภัณฑ์จากสัตว์เพื่อสุขภาพและสิ่งแวดล้อม แต่เบื้องหลังยังมีการดำเนินงานที่มุ่งเน้นการเปลี่ยนแปลงระบบอาหารโลก โดยการส่งเสริม "อาหารที่เพาะเลี้ยงในห้องปฏิบัติการเป็นหลัก​"

โครงการนี้ยังมีการจัดกิจกรรมเพื่อดึงดูดนักลงทุนและผู้สนับสนุนทางการเงิน เช่น การจัดงาน Food Funders Circle ซึ่งเป็นเวทีสำหรับนักลงทุนที่สนใจในอาหารทางเลือก นอกจากนี้ โครงการ 50by40 ยังมีความสัมพันธ์กับองค์กรต่างๆ ทั้งภาครัฐและเอกชน รวมถึงองค์กรระดับนานาชาติ เช่น Greenpeace, WWF และ Compassion in World Farming ซึ่งมีเป้าหมายร่วมกันในการลดการบริโภคผลิตภัณฑ์จากสัตว์ ​และ ProVeg International เองก็มีสถานะเป็นผู้สังเกตการณ์ถาวรในองค์การสหประชาชาติ เช่น UNFCCC, IPCC และ CBD รวมถึงมีสถานะที่ปรึกษาพิเศษกับ ECOSOC และได้รับการรับรองจาก UNEA อีกด้วย ถ้ามองแค่เนทเวิร์คเบื้องต้นแล้ว วินาทีนี้ ตอบได้เลยครับว่า "อาหารที่เพาะเลี้ยงในห้องปฏิบัติการเป็นหลัก​" มาแน่นอนครับ มองข้ามความ plant based / animal based ได้เลย

เพื่อบรรลุเป้าหมายนี้ โครงการได้ดำเนินกิจกรรมต่างๆ ทั้งในระดับโรงเรียนและการผลักดันนโยบายสาธารณะ ผมจะลองแบ่งเป็นข้อๆให้เพื่อความสะดวกในการมองภาพรวมประมาณนี้นะครับ

การดำเนินงานในโรงเรียนและเยาวชน 1. Early Action Network โครงการนี้เป็นความร่วมมือระหว่าง 50by40, ProVeg International และ Educated Choices Program โดยมีเป้าหมายในการส่งเสริมการบริโภคอาหารจากพืชในกลุ่มเด็กและเยาวชนผ่านกิจกรรมต่างๆ เช่น การจัดกิจกรรมเชิงโต้ตอบเกี่ยวกับสุขภาพ สิ่งแวดล้อม และสวัสดิภาพสัตว์, การจัดแคมเปญในโรงเรียนและชุมชน, การเผยแพร่สื่อการเรียนรู้และโปรแกรมฝึกอบรม, การปรับปรุงเมนูอาหารในโรงเรียนให้มีทางเลือกจากพืชมากขึ้น

โครงการนี้มุ่งหวังที่จะสร้างความตระหนักรู้และเปลี่ยนแปลงพฤติกรรมการบริโภคของเยาวชนตั้งแต่เนิ่นๆ เพื่อส่งเสริมการบริโภคอาหารที่ยั่งยืนและเป็นมิตรกับสิ่งแวดล้อม

1. School Plates Programme ProVeg International ได้เปิดตัวโครงการ School Plates ในสหราชอาณาจักรเมื่อปี 2018 โดยมีเป้าหมายในการปรับปรุงเมนูอาหารในโรงเรียนให้มีความหลากหลายและสุขภาพดีขึ้นผ่านการเพิ่มทางเลือกอาหารจากพืช โครงการนี้ได้ร่วมมือกับโรงเรียน หน่วยงานท้องถิ่น และบริษัทจัดเลี้ยง เพื่อเปลี่ยนแปลงเมนูอาหารในโรงเรียนกว่า 3.1 ล้านมื้อจากอาหารที่มีเนื้อสัตว์เป็นหลักไปเป็นอาหารจากพืช

สำหรับในส่วนของการผลักดันนโยบายสาธารณะและการมีส่วนร่วมในเวทีนานาชาตินั้น ก็มีไม่น้อยครับ อาทิเช่น การมีส่วนร่วมในองค์การสหประชาชาติ ProVeg International มีสถานะเป็นผู้สังเกตการณ์ถาวรในองค์การสหประชาชาติ เช่น UNFCCC และ UNEP และได้มีบทบาทในการผลักดันให้มีการรวมประเด็นเกี่ยวกับอาหารจากพืชในการเจรจาด้านสภาพภูมิอากาศ โดยในปี 2022 ProVeg ได้เข้าร่วมการประชุมสภาพภูมิอากาศของสหประชาชาติในสตอกโฮล์มและบอนน์ เพื่อส่งเสริมแนวคิด "Diet Change Not Climate Change" และเรียกร้องให้มีการเปลี่ยนแปลงระบบอาหารสู่การบริโภคอาหารจากพืชมากขึ้น

การสนับสนุนเยาวชนในเวทีนานาชาติ ProVeg ได้จัดตั้ง Youth Board ซึ่งประกอบด้วยเยาวชนจากทั่วโลก เพื่อมีส่วนร่วมในการผลักดันนโยบายด้านอาหารจากพืชในเวทีสหประชาชาติ และเตรียมความพร้อมสำหรับการประชุม COP30 ที่จะจัดขึ้นในเบเลง ประเทศบราซิล

นอกจากนี้ยังมีการสนับสนุนองค์กรและสตาร์ทอัพที่มุ่งเปลี่ยนแปลงระบบอาหารอีกมากมาย โดยที่โดดเด่นเป็นพิเศษคือ โปรแกรม Kickstarting for Good ProVeg International ได้เปิดตัวโปรแกรม Kickstarting for Good ซึ่งเป็นโปรแกรมบ่มเพาะและเร่งการเติบโตสำหรับองค์กรไม่แสวงหาผลกำไร โครงการที่มีผลกระทบ และสตาร์ทอัพทางสังคมที่มุ่งเปลี่ยนแปลงระบบอาหาร โปรแกรมนี้มีระยะเวลา 8 สัปดาห์ โดยมีการฝึกอบรมแบบเข้มข้น การให้คำปรึกษาจากผู้เชี่ยวชาญ และโอกาสในการสร้างเครือข่าย เพื่อสนับสนุนการพัฒนาโครงการที่มีศักยภาพในการลดการบริโภคผลิตภัณฑ์จากสัตว์และส่งเสริมอาหารจากพืช

นอกจาก Sebastian Joy จะเริ่มต้นโครงการต่างๆมากมายไม่ว่าจะ ProVeg International, ProVeg Incubator, Kickstarting for Good แต่ก็ยังมี องค์กรพันธมิตรในเครือข่าย 50by40 ที่หลากหลาย เช่น Plant Powered Metro New York, Public Justice, Rainforest Alliance, Real Food Systems, Reducetarian Foundation, Rethink Your Food, SEED และ Seeding Sovereignty ซึ่งร่วมกันส่งเสริมการบริโภคอาหารจากพืชและการลดการบริโภคผลิตภัณฑ์จากสัตว์ แม้ว่าโครงการ 50by40 จะได้รับการสนับสนุนจากองค์กรต่างๆ อย่างกว้างขวาง แต่ยังไม่มีข้อมูลที่ชัดเจนเกี่ยวกับบริษัทเอกชนรายใดที่แสดงการสนับสนุนโครงการนี้อย่างเปิดเผยครับ

ทีนี้เรามาดูความเคลื่อนไหวของลูกพี่ใหญ่อย่าง USDA กันบ้างนะครับ ​จากการตรวจสอบข้อมูลที่มีอยู่จนถึงปัจจุบัน ยังไม่พบหลักฐานชัดเจนว่า กระทรวงเกษตรสหรัฐฯ (USDA) มีการสนับสนุนโครงการ 50by40 อย่างเป็นทางการหรือเปิดเผย อย่างไรก็ตาม มีความเคลื่อนไหวที่เกี่ยวข้องกับการส่งเสริมโปรตีนทางเลือกและการลดการบริโภคเนื้อสัตว์ในระดับนโยบายของสหรัฐฯ ซึ่งอาจสอดคล้องกับเป้าหมายของโครงการ 50by40 อยู่เช่นกันครับ

ในปี 2021 คณะกรรมาธิการด้านการเกษตรของสภาผู้แทนราษฎรสหรัฐฯ ได้สนับสนุนให้ USDA จัดสรรงบประมาณ 50 ล้านดอลลาร์สหรัฐฯ ผ่านโครงการ Agriculture and Food Research Initiative (AFRI) เพื่อสนับสนุนการวิจัยเกี่ยวกับโปรตีนทางเลือก เช่น การใช้พืช การเพาะเลี้ยงเซลล์ และการหมัก เพื่อพัฒนาอาหารที่มีคุณสมบัติคล้ายเนื้อสัตว์

นอกจากนี้ USDA ได้ยอมรับคำว่า "cell-cultured" เป็นคำที่ใช้เรียกเนื้อสัตว์ที่ผลิตจากการเพาะเลี้ยงเซลล์ในห้องปฏิบัติการ ซึ่งเป็นส่วนหนึ่งของการกำหนดมาตรฐานและการควบคุมผลิตภัณฑ์อาหารใหม่ๆ ที่เกี่ยวข้องกับโปรตีนทางเลือก

แล้วกลุ่มองค์กรด้านสิ่งแวดล้อมและสุขภาพ เช่น Center for Biological Diversity ได้ส่งจดหมายถึงรัฐมนตรีกระทรวงเกษตรสหรัฐฯ เรียกร้องให้ USDA นำประเด็นการลดการบริโภคเนื้อสัตว์และผลิตภัณฑ์นมมาเป็นส่วนหนึ่งของยุทธศาสตร์ด้านสภาพภูมิอากาศ และปรับปรุงแนวทางโภชนาการแห่งชาติให้สอดคล้องกับเป้าหมาย "ด้านความยั่งยืน"

แม้ว่า USDA จะไม่ได้แสดงการสนับสนุนโครงการ 50by40 โดยตรง แต่มีความร่วมมือกับองค์กรที่มีเป้าหมายคล้ายคลึงกัน เช่น ProVeg International และ The Good Food Institute ซึ่งเป็นพันธมิตรในเครือข่ายของ 50by40 โดยมีเป้าหมายในการส่งเสริมการบริโภคอาหารจากการเพาะเลี้ยงเซลล์ในห้องปฏิบัติการและโปรตีนทางเลือก

อนาคตได้มีการขีด Goal ไว้ประมาณนี้ เรายังคิดว่าการที่ "แค่ไม่กินมัน" "ก็แค่เลือกกินอาหารธรรมชาติ" จะยังเป็นคำพูดที่เราพูดได้อีกไหม สิ่งนี้ก็ยังเป็นคำถามต่อไปครับ คงไม่มีใครสามารถตอบได้ใน วันนี้ (มั๊ง)

แต่ที่แน่ๆ มีคนไม่น้อยแล้วแหละครับ ที่บอกว่าอาหารจากแลปคุมในโรงงานที่สะอาด มันก็ดีนี่ สะอาดปลอดภัย ดีกว่าเนื้อหมูที่ผัดข้างทาง ล้างหรือเปล่าก็ไม่รู้ เอาหมูแบบไหนมาก็ไม่รู้

มันดูเหมือนว่าเป็นการเปรียบเปรยแบบตรรกะวิบัตินะครับ แต่รอบตัวคุณ มีคนคิดแบบนี้เยอะไหม? เป็นคำถามที่ไม่มีคำตอบอีกเช่นกันครับ

#pirateketo #กูต้องรู้มั๊ย #ม้วนหางสิลูก #siamstr

@ 3bf0c63f:aefa459d

my personal approach on using let, const and var in javascript

Since these names can be used interchangeably almost everywhere and there are a lot of people asking and searching on the internet on how to use them (myself included until some weeks ago), I developed a personal approach that uses the declarations mostly as readability and code-sense sugar, for helping my mind, instead of expecting them to add physical value to the programs.

---

let is only for short-lived variables, defined at a single line and not changed after. Generally those variables which are there only to decrease the amount of typing. For example:

for (let key in something) {
  /* we could use `something[key]` for this entire block,
     but it would be too much letters and not good for the
     fingers or the eyes, so we use a radically temporary variable
  */
  let value = something[key]
  ...
}

const for all names known to be constant across the entire module. Not including locally constant values. The value in the example above, for example, is constant in its scope and could be declared with const, but since there are many iterations and for each one there's a value with same name, "value", that could trick the reader into thinking value is always the same. Modules and functions are the best example of const variables:

const PouchDB = require('pouchdb')
const instantiateDB = function () {}
const codes = {
  23: 'atc',
  43: 'qwx',
  77: 'oxi'
}

var for everything that may or not be variable. Names that may confuse people reading the code, even if they are constant locally, and are not suitable for let (i.e., they are not completed in a simple direct declaration) apply for being declared with var. For example:

var output = '\n'
lines.forEach(line => {
  output += '  '
  output += line.trim()
  output += '\n'
})
output += '\n---'

for (let parent in parents) {
  var definitions = {}
  definitions.name = getName(parent)
  definitions.config = {}
  definitions.parent = parent
}

@ c1e6505c:02b3157e

Photography, to me, is a game - a game of snatching absurd, beautiful, fleeting moments from life. Anything staged or overly polished falls into what Garry Winogrand nails as “illustration work.” I’m with him on that. Photography is about staying awake to the world, to the “physical reality” or circumstances we’re steeped in, and burning that light onto film emulsion (or pixels now), locking a moment into matter forever. It’s not like painting, where brushstrokes mimic what’s seen, felt, or imagined. Photography captures photons - light itself - and turns it into something tangible. The camera, honestly, doesn’t get enough credit for being such a wild invention.

Lately, I’ve been chewing on what to do with a batch of new photos I’ve shot over the past month, which includes photographs from a film project, a trip to Manhattan and photos of David Byrne (more on that in another post). Maybe it's another photo-zine that I should make. It’s been a minute since my last one, Hiding in Hudson (https://www.youtube.com/watch?v=O7_t0OldrTk&t=339s). Putting out printed work like zines or books is killer practice — it forces you to sharpen your compositions, your vision, your whole deal as a photographer. Proof of work, you know?

This leads to a question: anyone out there down to help or collab on printing a photo-zine? I’d love to keep it DIY, steering clear of big companies.

In the spirit of getting back into a rhythm of daily shooting, here are a few recent shots from the past few days. Just wandering aimlessly around my neighborhood — bike rides, grocery runs, wherever I end up.

---

Camera used: Leica M262

Edited with: Lightroom + Dehancer Film

*Support my work and the funding for my new zine by sending a few sats: colincz@getalby.com *

@ 99895004:c239f905

Yes, FINALLY, we are extremely excited to announce support for nostr.build (blossom.band) on Primal! Decades in the making, billions of people have been waiting, and now it’s available! But it’s not just any integration, it is the next level of decentralized media hosting for Nostr. Let us explain.

Primal is an advanced Twitter/X like client for Nostr and is probably the fastest up-and-coming, highly used Nostr app available for iOS, Android and the web. Nostr.build is a very popular media hosting service for Nostr that can be used standalone or integrated into many Nostr apps using nip-96. This is an extremely feature rich, tested and proven integration we recommend for most applications, but it’s never been available on Primal.

And then, Blossom was born, thank you Hzrd149! Blossom is a Nostr media hosting protocol that makes it extremely easy for Nostr clients to integrate a media host, and for users of Blossom media hosts (even an in-house build) to host on any Nostr client. Revolutionary, right! Use whatever host you want on any client you want, the flexible beauty of Nostr. But there is an additional feature to Blossom that is key, mirroring.

One of the biggest complaints to media hosting on Nostr is, if a media hosting service goes down, so does all of the media hosted on that service. No bueno, and defeats the whole decentralized idea behind Nostr.. This has always been a hard problem to solve until Blossom mirroring came along. Mirroring allows a single media upload to be hosted on multiple servers using its hash, or unique media identifier. This way, if a media host goes down, the media is still available and accessible on the other host.

So, we are not only announcing support of nostr.build’s blossom.band on the Primal app, we are also announcing the first known fully integrated implementation of mirroring with multiple media hosts on Nostr. Try it out for yourself! Go to the settings of your Primal web, iOS or Android app, choose ‘Media Servers’, enable ‘Media Mirrors’, and add https://blossom.band and https://blossom.primal.net as your Media server and Mirror, done!

Video here!

@ 3bf0c63f:aefa459d

Não tem solução

O melhor presidente dos últimos 50 anos, o melhor congresso, o melhor governador, os melhores ministros, um resultado eleitoral muito melhor do que o melhor dos meus sonhos e nada acontece.

A única solução que nos resta é o Bitcoin. Vale talvez a pena dar a vida pra tentar popularizar esse negócio.

@ d9a329af:bef580d7

Since 2022, Dungeons and Dragons has been going down a sort of death spiral after the release of a revised version of 5th Edition... which didn't turn out very well to say the least. In light of that, I present a list of TTRPGs you can play if you don't want to purchase 5E. I wouldn't recommend 5E, as I've DM'd it in the past. It tastes like a lollipop that's cockroach and larvae flavored.

This list of TTRPG games is in no particular order, though my favorite of these systems is number one.

1. Basic Fantasy Role-Playing Game (BFRPG)
2. B/X-style OSR retroclone with ascending armor class, and the original retroclone from 2006
3. Fully libre under CC BY-SA for the 4th Edition, and OGL 1.0a for 1-3 Editions.
4. Full books are free PDF files on the website (Basic Fantasy Website)
5. All BFRPG editions are compatible with each other, meaning you can have a 3rd Edition book to a 4th Edition game and still have fun. 4th Edition is just the removal of the 3E SRD that's in the OGL editions.
6. As with the core rulebooks, all the supplementation is free as a PDF as well, though you can buy physical books at cost (BFRPG principal rights holder Chris Gonnerman doesn't make much profit from Basic Fantasy)
7. Old-school community that's an all-around fantastic group of players, authors and enthusiasts.

8. Fun Fact: Out of all the TTRPGs I'd want to DM/GM the most, it'd be this one by far.

9. Iron Falcon (IF)

10. OD&D-style retroclone from 2015 (It's also by Gonnerman, same guy behind BFRPG)
11. A close ruleset to the White Box rules and supplements
12. Also fully libre under CC BY-SA for the latest releases, just like BFRPG for 4th Edition releases
13. Just like BFRPG, the core rules and supplementation come as PDF files for free, or physical books.

14. Fast and loose ruleset open to interpretation, just like in 1975-1981... somewhere right around that timeline for OD&D

15. Old-School Reference and Index Compendium (OSRIC)

16. AD&D 1E-based retroclone by Stewart Marshall and Matt Finch
17. An old system that surprisingly still holds up, even after a long time of no new versions of the rules
18. Extremely in-depth ruleset, licensed under OGL 1.0a and OSRIC Open License
19. Compatible with AD&D 1e modules for the 1st Edition, though 2.2 potentially has its own supplementation

20. I don't know much about it, as I'd be too slow to learn it. That's all I know, which is the above.

21. Ironsworn

22. Custom loosely-based PbtA (Powered by the Apocalypse) system by Shawn Tomkin from 2018
23. Includes GM, GMless and solo play in the rulebook
24. Supplementation is surely something else with one look at the downloads section for the PDFs of the original, which is free under CC BY-NC-SA. The SRD is under CC BY otherwise.
25. No original adventures are made for this system as are known, as it's expected that the Ironlands are where they take place

26. Fun Fact: This was a non-D&D system I considered running as a GM.

27. Advanced Dungeons & Dragons 2nd Edition (AD&D 2e)

28. An official edition from 1989-2000
29. At the time, the most customizable edition in its history, before 3E took the spot as the most customizable edition
30. A streamlined revision of the AD&D 1E rules (AD&D 1E was exclusively written by E. Gary Gygax)
31. The end of old-school D&D, as 3E and beyond are different games altogether
32. Wide array of supplementation, which oversaturated 2E's customization... and most of it didn't sell well as a result
33. Final TSR-published edition of D&D, as they went bankrupt and out of business during this edition's life cycle, to then be liquidated to Wizards of the Coast (Boy did WOTC mess it up once 5.1E was released)

34. Fun Fact: A Canadian history professor named Dr. Robert Wardough runs a customized ruleset using 2E as a base, which he's been DMing since the 80's during the "Satanic Panic" (The Satanic Panic was fake as a result of horrible deceivers gaslighting people to not play D&D). He started RAW (Rules as Written), but saw some things he needed to change for his games, so he did so over time.

35. Moldvay/Cook Basic/Expert Dungeons & Dragons (B/X)

36. Competing system to 1E from 1981 and 1982
37. Official edition of D&D, part of the old-school era
38. Simplified rules for Basic, but some decently complex rules for Expert
39. Only goes up to Lv. 14, as it's potentially a 1E or White Box primer (similar to 1977 Basic)
40. Supplementation, from some research done, was decent for the time, and a little bit extensive
41. The inspiration for BFRPG in 2006 (Did I mention this already? Maybe I have, but I might emphasize that here too.)

42. Fun Fact: I considered running B/X, but decided that I'd do BFRPG, as the ascending armor class is easier math than with B/X and the THAC0 armor class (descending armor class).

43. Basic, Expert, Companion, Master, Immortal Dungeons & Dragons (BECMI) and/or Rules Cyclopedia

44. 1983 variant of the Moldvay/Cook Basic/Expert system, an official edition and part of the old-school era
45. Essentially, 1981 B/X D&D on steroids
46. 5 boxed sets were released for the five parts of the rules for this system
47. Rules Cyclopedia is a reprint of the 1983 Basic, Expert, Companion and Master rules boxed sets. The Immortal set was never reprinted outside of the original boxed set because Immortal is such a bizarre game within a game altogether.
48. With the first 4 boxed sets (whether individual sets or the Rules Cyclopedia), levels are 1-36

49. Fun Fact: This edition I was considering DMing as well, alongside BFRPG. They're similar rulesets with some mechanical differences, but I think either or would be worth it.

50. Original Dungeons & Dragons (OD&D or White Box)

51. The original release of D&D from 1974 written by Gygax and Dave Arneson, published by TSR
52. Uses the rules from Chainmail, a wargame made by Gygax and Jeff Perren
53. Base has three little booklets (Men & Magic, Monsters & Magic, and The Underworld & Wilderness Adventures), five official supplements were released (Greyhawk; Blackmoor; Eldritch Wizardry; Gods, Demi-Gods and Heroes; and Swords & Spells), and many more from fanzines
54. Fast and loose ruleset open to interpretation
55. Not based upon adventurers taking on dangerous quest, but kings commanding armies (which is why OD&D is actually a Chainmail supplement). The latter was the original purpose of D&D before it got changed in 2000.

There are many more games that are not D&D that you can look up too. See what you like, read the rules, learn them, and start playing with your group. Have fun and slay some monsters!

@ dc814bb0:7a410cb5

hallo welt

[[ ]] Add as many elements as you want? [[X]] The X marks the correct answer! [[ ]] ... this is wrong ... [[X]] ... this has to be selected too ...