Some Bitcoiners, me included, were fooled by hyperbolic discourse that presented Lightning as some magical scaling solution with no flaws. This is an attempt to list some of the actual flaws uncovered after 5 years of experience. The point of this article is not to say Lightning is a complete worthless piece of crap, but only to highlight the fact that Bitcoin needs to put more focus on developing and thinking about other scaling solutions (such as Drivechain, less crappy and more decentralized trusted channels networks and statechains).

Unbearable experience

Maintaining a node is cumbersome, you have to deal with closed channels, allocating funds, paying fees unpredictably, choosing new channels to open, storing channel state backups -- or you'll have to delegate all these decisions to some weird AI or third-party services, it's not feasible for normal people.

Channels fail for no good reason all the time

Every time nodes disagree on anything they close channels, there have been dozens, maybe hundreds, of bugs that lead to channels being closed in the past, and implementors have been fixing these bugs, but since these node implementations continue to be worked on and new features continue to be added we can be quite sure that new bugs continue to be introduced.

Trimmed (fake) HTLCs are not sound protocol design

What would you tell me if I presented a protocol that allowed for transfers of users' funds across a network of channels and that these channels would pledge to send the money to miners while the payment was in flight, and that these payments could never be recovered if a node in the middle of the hop had a bug or decided to stop responding? Or that the receiver could receive your payment, but still claim he didn't, and you couldn't prove that at all?

These are the properties of "trimmed HTLCs", HTLCs that are uneconomical to have their own UTXO in the channel presigned transaction bundles, therefore are just assumed to be there while they are not (and their amounts are instead added to the fees of the presigned transaction).

Trimmed HTLCs, like any other HTLC, have timelocks, preimages and hashes associated with them -- which are properties relevant to the redemption of actual HTLCs onchain --, but unlike actual HTLCs these things have no actual onchain meaning since there is no onchain UTXO associated with them. This is a game of make-believe that only "works" because (1) payment proofs aren't worth anything anyway, so it makes no sense to steal these; (2) channels are too expensive to setup; (3) all Lightning Network users are honest; (4) there are so many bugs and confusion in a Lightning Network node's life that events related to trimmed HTLCs do not get noticed by users.

Also, so far these trimmed HTLCs have only been used for very small payments (although very small payments probably account for 99% of the total payments), so it is supposedly "fine" to have them. But, as fees rise, more and more HTLCs tend to become fake, which may make people question the sanity of the design.

Tadge Dryja, one of the creators of the Lightning Network proposal, has been critical of the fact that these things were allowed to creep into the BOLT protocol.

Routing

Routing is already very bad today even though most nodes have a basically 100% view of the public network, the reasons being that some nodes are offline, others are on Tor and unreachable or too slow, channels have the balance shifted in the wrong direction, so payments fail a lot -- which leads to the (bad) solution invented by professional node runners and large businesses of probing the network constantly in order to discard bad paths, this creates unnecessary load and increases the risk of channels being dropped for no good reason.

As the network grows -- if it indeed grow and not centralize in a few hubs -- routing tends to become harder and harder.

While each implementation team makes their own decisions with regard to how to best way to route payments and these decisions may change at anytime, it's worth noting, for example, that CLN will use MPP to split up any payment in any number of chunks of 10k satoshis, supposedly to improve routing success rates. While this often backfires and causes payments to fail when they should have succeeded, it also contributes to making it so there are proportionally more fake HTLCs than there should be, as long as the threshold for fake HTLCs is above 10k.

Payment proofs are somewhat useless

Even though payment proofs were seen by many (including me) as one of the great things about Lightning, the sad fact is that they do not work as proofs if people are not aware of the fact that they are proofs. Wallets do all they can to hide these details from users because it is considered "bad UX" and low-level implementors do not care very much to talk about them at all. There have been attempts from Lightning Labs to get rid of the payment proofs entirely (which at the time to me sounded like a terrible idea, but now I realize they were not wrong).

Here's a piece of anecdote: I've personally witnessed multiple episodes in which Phoenix wallet released the preimage without having actually received the payment (they did receive a minor part of the payment, but the payment was split in many parts). That caused my service, @lntxbot, to mark the outgoing payment as complete, only then to have to endure complaints from the users because the receiver side, Phoenix, had not received the full amount. In these cases, if the protocol and the idea of preimages as payment proofs be respected, should I have been the one in charge of manually fixing user balances?

Another important detail: when an HTLC is sent and then something goes wrong with the payment the channel has to be closed in order to redeem that payment. When the redeemer is on the receiver side, the very act of redeeming should cause the preimage to be revealed and a proof of payment to be made available for the sender, who can then send that back to the previous hop and the payment is proven without any doubt. But when this happens for fake HTLCs (which is the vast majority of payments, as noted above) there is no place in the world for a preimage and therefore there are no proofs available. A channel is just closed, the payer loses money but can't prove a payment. It also can't send that proof back to the previous hop so he is forced to say the payment failed -- even if it wasn't him the one who declared that hop a failure and closed the channel, which should be a prerequisite. I wonder if this isn't the source of multiple bugs in implementations that cause channels to be closed unnecessarily. The point is: preimages and payment proofs are mostly a fiction.

Another important fact is that the proofs do not really prove anything if the keypair that signs the invoice can't be provably attached to a real world entity.

LSP-centric design

The first Lightning wallets to show up in the market, LND as a desktop daemon (then later with some GUIs on top of it like Zap and Joule) and Anton's BLW and Eclair wallets for mobile devices, then later LND-based mobile wallets like Blixt and RawTX, were all standalone wallets that were self-sufficient and meant to be run directly by consumers. Eventually, though, came Breez and Phoenix and introduced the "LSP" model, in which a server would be trusted in various forms -- not directly with users' funds, but with their privacy, fees and other details -- but most importantly that LSP would be the primary source of channels for all users of that given wallet software. This was all fine, but as time passed new features were designed and implemented that assumed users would be running software connected to LSPs. The very idea of a user having a standalone mobile wallet was put out of question. The entire argument for implementation of the bolt12 standard, for example, hinged on the assumption that mobile wallets would have LSPs capable of connecting to Google messaging services and being able to "wake up" mobile wallets in order for them to receive payments. Other ideas, like a complicated standard for allowing mobile wallets to receive payments without having to be online all the time, just assume LSPs always exist; and changes to the expected BOLT spec behavior with regards to, for example, probing of mobile wallets.

Ark is another example of a kind of LSP that got so enshrined that it become a new protocol that depends on it entirely.

Protocol complexity

Even though the general idea of how Lightning is supposed to work can be understood by many people (as long as these people know how Bitcoin works) the Lightning protocol is not really easy: it will take a long time of big dedication for anyone to understand the details about the BOLTs -- this is a bad thing if we want a world of users that have at least an idea of what they are doing. Moreover, with each new cool idea someone has that gets adopted by the protocol leaders, it increases in complexity and some of the implementors are kicked out of the circle, therefore making it easier for the remaining ones to proceed with more and more complexity. It's the same process by which Chrome won the browser wars, kicked out all competitors and proceeded to make a supposedly open protocol, but one that no one can implement as it gets new and more complex features every day, all envisioned by the Chrome team.

Liquidity issues?

I don't believe these are a real problem if all the other things worked, but still the old criticism that Lightning requires parking liquidity and that has a cost is not a complete non-issue, specially given the LSP-centric model.

I was an avid IPFS user until yesterday. Many many times I asked simple questions for which I couldn't find an answer on the internet in the #ipfs IRC channel on Freenode. Most of the times I didn't get an answer, and even when I got it was rarely by someone who knew IPFS deeply. I've had issues go unanswered on js-ipfs repositories for year – one of these was raising awareness of a problem that then got fixed some months later by a complete rewrite, I closed my own issue after realizing that by myself some couple of months later, I don't think the people responsible for the rewrite were ever acknowledge that he had fixed my issue.

Some days ago I asked some questions about how the IPFS protocol worked internally, sincerely trying to understand the inefficiencies in finding and fetching content over IPFS. I pointed it would be a good idea to have a drawing showing that so people would understand the difficulties (which I didn't) and wouldn't be pissed off by the slowness. I was told to read the whitepaper. I had already the whitepaper, but read again the relevant parts. The whitepaper doesn't explain anything about the DHT and how IPFS finds content. I said that in the room, was told to read again.

Before anyone misread this section, I want to say I understand it's a pain to keep answering people on IRC if you're busy developing stuff of interplanetary importance, and that I'm not paying anyone nor I have the right to be answered. On the other hand, if you're developing a super-important protocol, financed by many millions of dollars and a lot of people are hitting their heads against your software and there's no one to help them; you're always busy but never delivers anything that brings joy to your users, something is very wrong. I sincerely don't know what IPFS developers are working on, I wouldn't doubt they're working on important things if they said that, but what I see – and what many other users see (take a look at the IPFS Discourse forum) is bugs, bugs all over the place, confusing UX, and almost no help.

This is about Ryan Fugger's Ripple.

The summary is: unless everybody is good and well-connected at all times a transaction can always be left in a half-committed state, which creates confusion, erodes trust and benefits no one.

If you're unconvinced consider the following protocol flow:

1. A finds a route (A--B--C--D) between her and D somehow;
2. A "prepares" a payment to B, tells B to do the same with C and so on (to prepare means to give B a conditional IOU that will be valid as long as the full payment completes);
3. When the chain of prepared messages reaches D, D somehow "commits" the payment.
4. After the commit, A now really does owe B and so on, and D really knows it has been effectively paid by A (in the form of debt from C) so it can ship goods to A.

The most obvious (but wrong) way of structuring this would be for the entire payment chain to be dependent on the reveal of some secret. For example, the "prepare" messages could contain something like "I will pay you as long as you know p such that sha256(p) == h".

The payment flow then starts with D presenting A with an invoice that contains h, so D knows p, but no one else knows. A can then send the "prepare" message to B and B do the same until it reaches D.

When it reaches D, D can be sure that C will pay him because he knows p such that sha256(p) == h. He then reveals p to C, C now reveals it to B and B to A. When A gets it it has a proof that D has received his payment, therefore it is happy to settle it later with B and can prove to an external arbitrator that he has indeed paid D in case D doesn't deliver his products.

Issues with the naïve flow above

What if D never reveals p to C?

Then no one knows what happened. And then 10 years later he arrives at C's house (remember they are friends or have a trust relationship somehow) and demands his payment, and shows p to her in a piece of paper. Or worse: go directly to the court and shows C's message that says "I will pay you as long as you know p such that sha256(p) == h" (but with an actual number instead of "h") and the corresponding p. Now the judge has to decide in favor of D.

Now C was supposed to do the same with B, but C is not playing with this anymore, has lost all contact with B after they did their final settlement many years ago, no one was expecting this.

This clearly can't work. There must be a timeout for these payments.

What if we have a timeout?

Now what if we say the payment expires in one hour. D cannot hold the payment hostage and reveal p after 10 years. It must either reveal it before the timeout or conditional IOU will be void. Solves everything!

Except no, now it's the time we reach the most dark void of the protocol, the flaw that sucks its life into the abyss: subjectivity and ambiguity.

The big issue is that we don't have an independent judge to assert, for example, that D has indeed "revealed" p to C in time. C must acknowledge that voluntarily. C could do it using messages over the internet, but these messages are not reliable. C is not reliable. Clocks are not synchronized. Also if we now require C to confirm it has received p from D then the "prepare" message means nothing, as for D now just knowing p is not enough to claim before an arbitrator that C owes her -- because, again, D also must prove it has shown p to C before the timeout, therefore it needs a new signed acknowledgement from C, or from some other party.

Let's see a few examples.

Subjectivity and perverse incentives

D could send p to C, and C acknowledge it, but then when C goes to B and send it B will not acknowledge it, and claim it's past the time. Now C loses money.

Maybe C can not acknowledge it received anything from D before checking first with B? But B will have to check with A too! And it subverts the entire flow of the thing. And now A has a "proof of payment" (knowledge of p) without even having to acknowledge anything! In this case knowing p or not becomes meaningless as everybody knows p without acknowleding it to anyone else.

But even if A is honest and sends an "acknowledge" message to B, now B can just sit quiet and enjoy the credit it has just earned from A without ever acknowleding anything to C. It's perverted incentives in every step.

Ambiguity

But isn't this a protocol based on trust?, you ask, isn't C trusting that B will behave honestly already? Therefore if B is dishonest C just has to acknowledge his loss and break his chain of trust with B.

No, because C will not know what happened. B can say "I could have sent you an acknowledgement, but was waiting for A, and A didn't send anything" and C won't ever know if that was true. Or B could say "what? You didn't send me p at all", and that could be true. B could have been offline when A sent it, there could have been a broken connection or many other things, and B continues: "I was waiting for you to present me with p, but you didn't, therefore the payment timed out, you can't come here with p now, because now A won't accept it anymore from me". That could be true or could be false, who knows?

Therefore it is impossible for trust relationships and reputations to be maintained in such a system without "good fences".¹²

Or how to make a basic "social-networking" application using the Nostr protocol that is safe and promotes decentralization.

The basic app views

Suppose a basic "social-networking" app is like Twitter. In that, one has basically 3 views:

• A home feed that shows all notes from everybody you follow;
• A profile view from a specific user that shows all notes from that user;
• A replies view that shows all replies to one specific note.

Some Nostr clients may want to also provide another view, the global feed which shows posts from everybody.

A simple classification of relays

And suppose that all existing relays can be classified in 3 groups (according to one's subjective evaluation):

• spammy relays, in which people of any kind can post whatever they want with no filters at all;
• safe relays, in which there are some barriers to entry, like requiring a fee, or requiring some cumbersome user registration process, and spammers or people who post bad things are banned -- but this is still a relay fundamentally open to anyone (although this is also subjective depending on the kind of restrictions);
• closed relays, in which only certain kinds of people enter, for example, members of a group of friends or a closed online community.

How to follow and find posts from a given profile

To follow someone on Nostr, it is necessary to know one or more relays in which that person is publishing their notes, otherwise it is impossible to fetch anything from them.

When a user starts to follow someone, that may be done through 4 different ways:

1. from seeing that person in the app
2. using an nprofile URI
3. using a NIP-05 address
4. using a bare pubkey ('npub`)

Situation 1 may happen when that person is seen in the replies of yours or someone else's post, on a global feed post, or from a note referenced or republished from them by someone else. When that happens, it is expected that the references (in e and p tags) contain relay URLs. We must them inject that information to tentatively associate that person with a relay URL at that first contact.

In situations 2 and 3 both the nprofile and the NIP-05 addresses should contain a list of preferred relays for that person, so we can bootstrap the relay list for that person based on that.

In situation 4 there is no relay list, so we must either prompt the user through an annoying popup or something -- or it can try searching for that pubkey in one of their known relays. This remains an option for the other methods too.

Once we have relay URLs for a given profile we can use these relays to query notes from that pubkey. As time passes that user may migrate to other relays, or it may become known that the user is also posting to other relays. To make sure these things are discovered, we must pay attention to hints sent in tags of all events seen everywhere -- from anyone --, and also events of kind 2 and 3, and upgrade our local database that has the knowledge of relationship between profiles and relays accordingly.

Rendering the app views

From what we've gathered until now, we can easily render the home feed and the profile view. To do that it just uses local information about relationships between profiles and relays and fetch notes:

• for the home feed, from all people we're following;
• for the profile view, from just that specific profile.

Since we'll be asking for very specific data from these relays, we do not care about where they're safe or not. They will never send us spam (and if they do that will just be filtered out since it wouldn't match our strict filter).

Now whenever the user clicks on a note we will want to display the replies view. In this case we will just query only the safe and the closed relays, since otherwise spam might be injected into the application. The same principle applies to the global feed view.

Other heuristics and corner cases

There are probably many corner cases not covered in this document. This was meant to just describe one way that seems to me to be sufficiently robust for a decentralized Nostr.

For example, how to display a note that was referenced by someone? If it has a relay hint we query that relay. If it doesn't we can try the relays associated with the person who have just mentioned it, or the same relay we've just seen the note that mentioned it -- as, when mentioning it, one might have published it directly to their own relays -- and so on. But all this may fail and then it is probably not a big deal.

Final thoughts

More important than all, is that we must keep in mind that Nostr is just a very loose set of servers with basically no connection between them, there are no guarantees of anything, and the process of keeping connected to others and finding content must be addressed through many different hackish attempts. To write Nostr applications and to use Nostr one must embrace the inherent chaos.

This was a thing done in a brief period I liked the idea of "indiewebcamp", a stupid movement of people saying everybody should have their site and post their lives in it.

From the GitHub postmortem:

questo.email was a service that integrated email addresses into the indieweb ecosystem by providing email-to-note and email-to-webmention triggers, which could be used for people to comment through webmention using their email addresses, and be replied, and also for people to send messages from their sites directly to the email addresses of people they knew; Questo also worked as an IndieAuth provider that used people's email addresses and Mozilla Persona.

It was live from December 2014 through December 2015.

Here's how the home page looked:

• https://github.com/fiatjaf/questo.email

See also

• jekmentions, another thing related to "indieweb"

It seems that from 1987 to around 2000 there was a big community of people who played this game called "Bolo". It was a game in which people controlled a tank and killed others while trying to capture bases in team matches. Always 2 teams, from 2 to 16 total players, games could last from 10 minutes to 12 hours. I'm still trying to understand all this.

The game looks silly from some videos you can find today, but apparently it was very deep in strategy because people developed strategy guides and wrote extensively about it and Netscape even supported bolo: URLs out of the box.

The two most important elements on the map are pillboxes and bases. Pillboxes are originally neutral, meaning that they shoot at every tank that happens to get in its range. They shoot fast and with deadly accuracy. You can shoot the pillbox with your tank, and you can see how damaged it is by looking at it. Once the pillbox is subdued, you may run over it, which will pick it up. You may place the pillbox where you want to put it (where it is clear), if you've enough trees to build it back up. Trees are harvested by sending your man outside your tank to forest the trees. Your man (also called a builder) can also lay mines, build roads, and build walls. Once you have placed a pillbox, it will not shoot at you, but only your enemies. Therefore, pillboxes are often used to protect your bases.

That quote was taken from this "augmented FAQ" written by some user. Apparently there were many FAQs for this game. A FAQ is after all just a simple, clear and direct to the point way of writing about anything, previously known as summa¹, it doesn't have to be related to any actually frequently asked question.

More unexpected Bolo writings include an etiquette guide, an anthropology study and some wonderings on the reverse pill war tactic.

Before reading this, see Ripple and the problem of the decentralized commit.

The Bitcoin Lightning Network can be thought as a system similar to Ripple: there are conditional IOUs (HTLCs) that are sent in "prepare"-like messages across a route, and a secret p that must travel from the final receiver backwards through the route until it reaches the initial sender and possession of that secret serves to prove the payment as well as to make the IOU hold true.

The difference is that if one of the parties don't send the "acknowledge" in time, the other has a trusted third-party with its own clock (that is the clock that is valid for everybody involved) to complain immediately at the timeout: the Bitcoin blockchain. If C has p and B isn't acknowleding it, C tells the Bitcoin blockchain and it will force the transfer of the amount from B to C.

Differences (or 1 upside and 3 downside)

1. The Lightning Network differs from a "pure" Ripple network in that when we send a "prepare" message on the Lightning Network, unlike on a pure Ripple network we're not just promising we will owe something -- instead we are putting the money on the table already for the other to get if we are not responsive.

2. The feature above removes the trust element from the equation. We can now have relationships with people we don't trust, as the Bitcoin blockchain will serve as an automated escrow for our conditional payments and no one will be harmed. Therefore it is much easier to build networks and route payments if you don't always require trust relationships.

3. However it introduces the cost of the capital. A ton of capital must be made available in channels and locked in HTLCs so payments can be routed. This leads to potential issues like the ones described in https://twitter.com/joostjgr/status/1308414364911841281.

4. Another issue that comes with the necessity of using the Bitcoin blockchain as an arbiter is that it may cost a lot in fees -- much more than the value of the payment that is being disputed -- to enforce it on the blockchain.¹

Solutions

Because the downsides listed above are so real and problematic -- and much more so when attacks from malicious peers are taken into account --, some have argued that the Lightning Network must rely on at least some trust between peers, which partly negate the benefit.

The introduction of purely trust-backend channels is the next step in the reasoning: if we are trusting already, why not make channels that don't touch the blockchain and don't require peers to commit large amounts of capital?

The reason is, again, the ambiguity that comes from the problem of the decentralized commit. Therefore hosted channels can be good when trust is required only from one side, like in the final hops of payments, but they cannot work in the middle of routes without eroding trust relationships between peers (however they can be useful if employed as channels between two nodes ran by the same person).

The next solution is a revamped pure Ripple network, one that solves the problem of the decentralized commit in a different way.

The simplest open protocol that is able to create a censorship-resistant global "social" network once and for all.

It doesn't rely on any trusted central server, hence it is resilient; it is based on cryptographic keys and signatures, so it is tamperproof; it does not rely on P2P techniques, therefore it works.

Very short summary of how it works, if you don't plan to read anything else:

Everybody runs a client. It can be a native client, a web client, etc. To publish something, you write a post, sign it with your key and send it to multiple relays (servers hosted by someone else, or yourself). To get updates from other people, you ask multiple relays if they know anything about these other people. Anyone can run a relay. A relay is very simple and dumb. It does nothing besides accepting posts from some people and forwarding to others. Relays don't have to be trusted. Signatures are verified on the client side.

This is needed because other solutions are broken:

The problem with Twitter

• Twitter has ads;
• Twitter uses bizarre techniques to keep you addicted;
• Twitter doesn't show an actual historical feed from people you follow;
• Twitter bans people;
• Twitter shadowbans people.
• Twitter has a lot of spam.

The problem with Mastodon and similar programs

• User identities are attached to domain names controlled by third-parties;
• Server owners can ban you, just like Twitter; Server owners can also block other servers;
• Migration between servers is an afterthought and can only be accomplished if servers cooperate. It doesn't work in an adversarial environment (all followers are lost);
• There are no clear incentives to run servers, therefore they tend to be run by enthusiasts and people who want to have their name attached to a cool domain. Then, users are subject to the despotism of a single person, which is often worse than that of a big company like Twitter, and they can't migrate out;
• Since servers tend to be run amateurishly, they are often abandoned after a while — which is effectively the same as banning everybody;
• It doesn't make sense to have a ton of servers if updates from every server will have to be painfully pushed (and saved!) to a ton of other servers. This point is exacerbated by the fact that servers tend to exist in huge numbers, therefore more data has to be passed to more places more often;
• For the specific example of video sharing, ActivityPub enthusiasts realized it would be completely impossible to transmit video from server to server the way text notes are, so they decided to keep the video hosted only from the single instance where it was posted to, which is similar to the Nostr approach.

The problem with SSB (Secure Scuttlebutt)

• It doesn't have many problems. I think it's great. In fact, I was going to use it as a basis for this, but
• its protocol is too complicated because it wasn't thought about being an open protocol at all. It was just written in JavaScript in probably a quick way to solve a specific problem and grew from that, therefore it has weird and unnecessary quirks like signing a JSON string which must strictly follow the rules of ECMA-262 6th Edition;
• It insists on having a chain of updates from a single user, which feels unnecessary to me and something that adds bloat and rigidity to the thing — each server/user needs to store all the chain of posts to be sure the new one is valid. Why? (Maybe they have a good reason);
• It is not as simple as Nostr, as it was primarily made for P2P syncing, with "pubs" being an afterthought;
• Still, it may be worth considering using SSB instead of this custom protocol and just adapting it to the client-relay server model, because reusing a standard is always better than trying to get people in a new one.

The problem with other solutions that require everybody to run their own server

• They require everybody to run their own server;
• Sometimes people can still be censored in these because domain names can be censored.

How does Nostr work?

• There are two components: clients and relays. Each user runs a client. Anyone can run a relay.
• Every user is identified by a public key. Every post is signed. Every client validates these signatures.
• Clients fetch data from relays of their choice and publish data to other relays of their choice. A relay doesn't talk to another relay, only directly to users.
• For example, to "follow" someone a user just instructs their client to query the relays it knows for posts from that public key.
• On startup, a client queries data from all relays it knows for all users it follows (for example, all updates from the last day), then displays that data to the user chronologically.
• A "post" can contain any kind of structured data, but the most used ones are going to find their way into the standard so all clients and relays can handle them seamlessly.

How does it solve the problems the networks above can't?

• Users getting banned and servers being closed

  • A relay can block a user from publishing anything there, but that has no effect on them as they can still publish to other relays. Since users are identified by a public key, they don't lose their identities and their follower base when they get banned.
  • Instead of requiring users to manually type new relay addresses (although this should also be supported), whenever someone you're following posts a server recommendation, the client should automatically add that to the list of relays it will query.
  • If someone is using a relay to publish their data but wants to migrate to another one, they can publish a server recommendation to that previous relay and go;
  • If someone gets banned from many relays such that they can't get their server recommendations broadcasted, they may still let some close friends know through other means with which relay they are publishing now. Then, these close friends can publish server recommendations to that new server, and slowly, the old follower base of the banned user will begin finding their posts again from the new relay.
  • All of the above is valid too for when a relay ceases its operations.

• Censorship-resistance

  • Each user can publish their updates to any number of relays.
  • A relay can charge a fee (the negotiation of that fee is outside of the protocol for now) from users to publish there, which ensures censorship-resistance (there will always be some Russian server willing to take your money in exchange for serving your posts).

• Spam

  • If spam is a concern for a relay, it can require payment for publication or some other form of authentication, such as an email address or phone, and associate these internally with a pubkey that then gets to publish to that relay — or other anti-spam techniques, like hashcash or captchas. If a relay is being used as a spam vector, it can easily be unlisted by clients, which can continue to fetch updates from other relays.

• Data storage

  • For the network to stay healthy, there is no need for hundreds of active relays. In fact, it can work just fine with just a handful, given the fact that new relays can be created and spread through the network easily in case the existing relays start misbehaving. Therefore, the amount of data storage required, in general, is relatively less than Mastodon or similar software.
  • Or considering a different outcome: one in which there exist hundreds of niche relays run by amateurs, each relaying updates from a small group of users. The architecture scales just as well: data is sent from users to a single server, and from that server directly to the users who will consume that. It doesn't have to be stored by anyone else. In this situation, it is not a big burden for any single server to process updates from others, and having amateur servers is not a problem.

• Video and other heavy content

  • It's easy for a relay to reject large content, or to charge for accepting and hosting large content. When information and incentives are clear, it's easy for the market forces to solve the problem.

• Techniques to trick the user

  • Each client can decide how to best show posts to users, so there is always the option of just consuming what you want in the manner you want — from using an AI to decide the order of the updates you'll see to just reading them in chronological order.

FAQ

• This is very simple. Why hasn't anyone done it before?

I don't know, but I imagine it has to do with the fact that people making social networks are either companies wanting to make money or P2P activists who want to make a thing completely without servers. They both fail to see the specific mix of both worlds that Nostr uses.

• How do I find people to follow?

First, you must know them and get their public key somehow, either by asking or by seeing it referenced somewhere. Once you're inside a Nostr social network you'll be able to see them interacting with other people and then you can also start following and interacting with these others.

• How do I find relays? What happens if I'm not connected to the same relays someone else is?

You won't be able to communicate with that person. But there are hints on events that can be used so that your client software (or you, manually) knows how to connect to the other person's relay and interact with them. There are other ideas on how to solve this too in the future but we can't ever promise perfect reachability, no protocol can.

• Can I know how many people are following me?

No, but you can get some estimates if relays cooperate in an extra-protocol way.

• What incentive is there for people to run relays?

The question is misleading. It assumes that relays are free dumb pipes that exist such that people can move data around through them. In this case yes, the incentives would not exist. This in fact could be said of DHT nodes in all other p2p network stacks: what incentive is there for people to run DHT nodes?

• Nostr enables you to move between server relays or use multiple relays but if these relays are just on AWS or Azure what’s the difference?

There are literally thousands of VPS providers scattered all around the globe today, there is not only AWS or Azure. AWS or Azure are exactly the providers used by single centralized service providers that need a lot of scale, and even then not just these two. For smaller relay servers any VPS will do the job very well.

A sensação de "ser" um personagem em um jogo ou uma brincadeira talvez seja o mais próximo que eu tenha conseguido chegar do entendimento de um símbolo religioso.

A hóstia consagrada é, segundo a religião, o corpo de Cristo, mas nossa mente moderna só consegue concebê-la como sendo uma representação do corpo de Cristo. Da mesma forma outras culturas e outras religiões têm símbolos parecidos, inclusive nos quais o próprio participante do ritual faz o papel de um deus ou de qualquer coisa parecida.

"Faz o papel" é de novo a interpretação da mente moderna. O sujeito ali é a coisa, mas ele ao mesmo tempo que é também sabe que não é, que continua sendo ele mesmo.

Nos jogos de videogame e brincadeiras infantis em que se encarna um personagem o jogador é o personagem. não se diz, entre os jogadores, que alguém está "encenando", mas que ele é e pronto. nem há outra denominação ou outro verbo. No máximo "encarnando", mas já aí já é vocabulário jornalístico feito para facilitar a compreensão de quem está de fora do jogo.

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

Who will build the roads? Em Lagoa Santa, as mais novas e melhores ruas -- que na verdade acabam por formar enormes teias de bairros que se interligam -- são construídas pelos loteadores que querem as ruas para que seus lotes valham mais -- e querem que outras pessoas usem as ruas também. Também são esses mesmos loteadores que colocam os postes de luz e os encanamentos de água, não sem antes terem que se submeter a extorsões de praxe praticadas por COPASA e CEMIG.

Se ao abrir um loteamento, condomínio, prédio um indivíduo ou uma empresa consegue sem muito problema passar rua, eletricidade, água e esgoto, por que não seria possível existir livre-concorrência nesses mercados? Mesmo aquela velha estória de que é ineficiente passar cabos de luz duplicados para que companhias elétricas possam competir já me parece bobagem.

No episódio sei-lá-qual de Aleixo FM Bruno Aleixo diz que os bêbados sempre têm as melhores idéias e daí conta uma idéia que ele teve quando estava bêbado: um comprimido que funciona como desodorante. Ao invés de passar o desodorante spray ou roll-on a pessoa pode só tomar o comprimido e pronto, é muito mais prático e no tempo de frio a pessoa pode vestir a roupa mais rápido, sem precisar ficar passando nada com o tronco todo nu. Quando o Busto lhe pergunta sobre a possibilidade de algo assim ser fabricado ele diz que não sabe, que não é cientista, só tem as idéias.

Essa passagem tão boba de um programa de humor esconde uma verdade sobre a doutrina cientística que permeia a sociedade. A doutrina segundo a qual é da ciência que vêm as inovações tecnológicas e de todos os tipos, e por isso é preciso que o Estado tire dinheiro das pessoas trabalhadoras e dê para os cientistas. Nesse ponto ninguém mais sabe o que é um cientista, foi-se toda a concretude, ficou só o nome: "cientista". Daí vão procurar o tal cientista, é um cara que se formou numa universidade e está fazendo um mestrado. Pronto, é só dar dinheiro pra esse cara e tudo vai ficar bom.

Tirando o problema da desconexão entre realidade e a tese, existe também, é claro, o problema da tese: não faz sentido, que um cientista fique procurando formas de realizar uma idéia, que não se sabe nem se é possível nem se é desejável, que ele ou outra pessoa tiveram, muito pelo contrário (mas não vou dizer aqui o que é que era para o cientista fazer porque isso seria contraditório e eu não acho que devam nem existir cientistas).

O que eu queria dizer mesmo era: todo o aparato científico da nossa sociedade, todos os departamentos, universidades, orçamentos e bolsas e revistas, tudo se resume a um monte de gente tentando descobrir como fazer um comprimido desodorante.

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.

outro dia o comentarista Falcão, da Globo, disse, sobre o título do São Paulo: [i]"um jogo se ganha com um bom ataque, um campeonato se ganha com uma boa defesa"[/i], e foi deveras assustador pensar no que se transformou o futebol com o sistema de disputa do campeonato brasileiro por pontos corridos. um esporte em que vencia quem fazia mais gols está se transformando num esporte em que vence quem leva menos gols. é o sistema de pontos corridos - que premia a constância, o time que perde menos, mesmo que isso signifique empatar todos os jogos fora de casa em 0x0 e vencer todos em casa por 1x0. o sistema de pontos corridos premia o futebol feio, covarde, ou - como também é conhecido o futebol retranqueiro - o "equilíbrio".

eis que o futebol brasileiro, resolvendo seguir a linha européia, institui a disputa por pontos corridos e se transforma numa cópia malfeita e pobre do chato futebol europeu. e perde-se tudo que tínhamos de aqui que eles não tinham lá (é claro, os europeus têm mais estrutura, mais dinheiro, mais tudo), a ousadia, os brios, a coragem, a categoria e o escambau.

daí falam que o sistema de pontos corridos é mais justo. é mais justo porque dá o título aos times que jogaram melhor durante o campeonato, os mais regulares. mas ninguém disse por que não é justo premiar os times que conseguem vencer na semifinal e na final, o time que consegue ser pior o campeonato inteiro e no final tirar forças não sei de onde pra vencer aquele que era (ou parecia ser) bem melhor do que ele, o time que dá a volta por cima, o time que - mesmo não sendo regular - sabe jogar em decisões, sabe se segurar em um estádio com 80 mil torcendo contra e sabe aproveitar quando há 80 mil torcendo a favor e matar o adversário. o melhor time é o que vai ganhando pontinhos em jogos bobos e no final junta tudo e a soma dá mais do que os pontinhos do adversário ou é o time que consegue entrar num estádio numa final e derrotar, cara a cara, o adversário?

e quem disse que futebol é regularidade? repare que não se ouve mais a expressão desde o início dos pontos corridos, mas futebol é uma caixinha de surpresas. dos esportes que eu conheço, futebol é o único em que o último colocado pode vencer o primeiro e ninguém considerar isso um absurdo. com os pontos corridos, morrem metade dos componentes do futebol: o amor pelo ataque - conforme explicitado na supracitada afirmação de Falcão - a coragem, os brios e a emoção.

ao premiar a regularidade no futebol, pode-se estar chamando de “campeão” um time que facilmente tremeria numa final. e não é justo que um time covarde seja campeão. duvido que o São Paulo de 2007 jogaria bem numa final contra o Flamengo. e dificilmente o Corinthians de 2005 venceria uma final contra o Internacional (aliás, perdeu, moralmente, aquele jogo que foi quase uma final entre os dois).

mas se todo mundo gosta tanto assim desse campeonato de pseudo-futebol, vem aí a Copa do Mundo por pontos corridos.

Another Trello helper.

This time it allowed people to perform batch actions on multiple cards, most notably delete a lot of cards at once.

I created it because I wanted to delete a ton of spam from Boardthreads.

• https://github.com/fiatjaf/batch-for-trello
• https://batch.cardsync.xyz/

A idéia tradicional de família está associada a propriedades imobiliárias fixas, passadas de geração a geração.

Com propriedades sendo partidas, desfeitas, vendidas e divididas entre os filhos a idéia de família -- um nome associado a um lugar -- torna-se vaga e perde-se no ar.

Acho que isso não vale apenas para a nobreza medieval, mas mesmo para as famílias plebéias, e não valeu quase nunca para as sociedades do novo mundo. Acho que até seria compatível com a compra e venda de terras, que seriam compreendidas como uma família mudando de lugar, mas não com a divisão igualitária das propriedades da família entre vários filhos e assim sucessivamente.

Nunca antes tinha-me ocorrido este excelente e quase-óbvio insight que está escrito em "A Democracia na América", de Alexis de Tocqueville.

https://writingcooperative.com/zettelkasten-how-one-german-scholar-was-so-freakishly-productive-997e4e0ca125 (um artigo meio estúpido, mas útil).

Esta incrível técnica de salvar notas sem categorias, sem pastas, sem hierarquia predefinida, mas apenas fazendo referências de uma nota à outra e fazendo supostamente surgir uma ordem (ou heterarquia, disseram eles) a partir do caos parece ser o que faltava pra eu conseguir anotar meus pensamentos e idéias de maneira decente, veremos.

Ah, e vou usar esse tal neuron que também gera sites a partir das notas?, acho que vai ser bom.

The argument that Drivechain will replace shitcoins is not that people will sell their shitcoins or that the existing shitcoins will instantly vanish. The argument is about a change at the margin that eventually ends up killing the shitcoins or reducing them to their original insignificance.

What does "at the margin" mean? For example, when the price of the coconut drops a little in relation to bananas, does that mean that everybody will stop buying bananas and will buy only coconuts now? No. Does it mean there will be zero increase in the amount of coconuts sold? Also no. What happens is that there is a small number of people who would have preferred to buy coconuts if only they were a little less expensive but end up buying bananas instead. When the price of coconut drops these people buy coconuts and don't buy bananas.

The argument is that the same thing will happen when Drivechain is activated: there are some people today (yes, believe me) that would have preferred to work within the Bitcoin ecosystem but end up working on shitcoins. In a world with Drivechain these people would be working on the Bitcoin ecosystem, for the benefit of Bitcoin and the Bitcoiners.

Why would they prefer Bitcoin? Because Bitcoin has a bigger network-effect. When these people come, they increase Bitocin's network-effect even more, and if they don't go to the shitcoins they reduce the shitcoins' network-effect. Those changes in network-effect contribute to bringing others who were a little further from the margin and the thing compounds until the shitcoins are worthless.

Who are these people at the margin? I don't know, but they certainly exist. I would guess the Stark people are one famous example, but there are many others. In the past, examples included Roger Ver, Zooko Wilcox, Riccardo Spagni and Vitalik Buterin. And before you start screaming that these people are shitcoiners (which they are) imagine how much bigger Bitcoin could have been today if they and their entire communities (yes, I know, of awful people) were using and working for Bitcoin today. Remember that phrase about Bitcoin being for enemies?

But everything that has been invented in the altcoin world is awful, we don't need any of that!

You and me should not be the ones judging what is good and what is not for others, but both you and me and others will benefit if these things can be done in a way that increases Bitcoin network-effect and pays fees to Bitcoin miners.

Also, there is a much stronger point you may have not considered: if you believe all altcoiners are scammers that means we have only seen the things that were invented by scammers, since all honest people that had good ideas decided to not implement them as the only way to do it would be to create a scammy shitcoin. One example is Bitcoin Hivemind.

If it is possible to do these ideas without creating shitcoins we may start to see new things that are actually good.

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

a payments network based on trust channels

This is the description of a Lightning-like network that will work only with credit or trust-based channels and exist alongside the normal Lightning Network. I imagine some people will think this is undesirable and at the same time very easy to do (such that if it doesn't exist yet it must be because no one cares), but in fact it is a very desirable thing -- which I hope I can establish below -- and at the same time a very non-trivial problem to solve, as the history of Ryan Fugger's Ripple project and posterior copies of it show.

Read these first to get the full context:

1. Ryan Fugger's Ripple
2. Ripple and the problem of the decentralized commit
3. The Lightning Network solves the problem of the decentralized commit
4. Parallel Chains

Explanation about the name

Since we're copying the fundamental Ripple idea from Ryan Fugger and since the name "Ripple" is now associated with a scam coin called XRP, and since Ryan Fugger has changed the name of his old website "Ripplepay" to "Rumplepay", we will follow his lead here. If "Ripplepay" was the name of a centralized prototype to the open peer-to-peer network "Ripple", now that the centralized version is called "Rumplepay" the peer-to-peer version must be called "Rumple".

Now the idea

Basically we copy the Lightning Network, but without HTLCs or channels being opened and closed with funds committed to them on multisig Bitcoin transactions published to the blockchain. Instead we use pure trust relationships like the original Ripple concept.

And we use the blockchain commit method, but instead of spending an absurd amount of money to use the actual Bitcoin blockchain instead we use a parallel chain.

How exactly -- a protocol proposal attempt

It could work like this:

The parallel chain, or "Rumple Chain"

1. We define a parallel chain with a genesis block;
2. Following blocks must contain

   
   a. the ID of the previous block;
   b. a list of up to 32768 entries of arbitrary 32-byte values;
   c. an ID constituted by
       sha256(the previous block ID +
              the merkle root of all the entries)
   

3. To be mined, each parallel block must be included in the Bitcoin chain according as explained above.

Now that we have a structure for a simple "blockchain" that is completely useless, just blocks over blocks of meaningless values, we proceed to the next step of assigning meaning to these values.

The off-chain payments network, or "Rumple Network"

1. We create a network of nodes that can talk to each other via TCP messages (all details are the same as the Lightning Network, except where mentioned otherwise);
2. These nodes can create trust channels to each other. These channels are backed by nothing except the willingness of one peer to pay the other what is owed.
3. When Alice creates a trust channel with Bob (Alice trusts Bob), contrary to what happens in the Lightning Network, it's A that can immediately receive payments through that channel, and everything A receives will be an IOU from Bob to Alice. So Alice should never open a channel to Bob unless Alice trusts Bob. But also Alice can choose the amount of trust it has in Bob, she can, for example, open a very small channel with Bob, which means she will only lose a few satoshis if Bob decides to exit scam her. (in the original Ripple examples these channels were always depicted as friend relationships, and they can continue being that, but it's expected -- given the experience of the Lightning Network -- that the bulk of the channels will exist between users and wallet provider nodes that will act as hubs).
4. As Alice receive a payment through her channel with Bob, she becomes a creditor and Bob a debtor, i.e., the balance of the channel moves a little to her side. Now she can use these funds to make payments over that channel (or make a payment that combines funds from multiple channels using MPP).
5. If at any time Alice decides to close her channel with Bob, she can send all the funds she has standing there to somewhere else (for example, another channel she has with someone else, another wallet somewhere else, a shop that is selling some good or service, or a service that will aggregate all funds from all her channels and send a transaction to the Bitcoin chain on her behalf).
6. If at any time Bob leaves the network Alice is entitled by Bob's cryptographic signatures to knock on his door and demand payment, or go to a judge and ask him to force Bob to pay, or share the signatures and commitments online and hurt Bob's reputation with the rest of the network (but yes, none of these things is good enough and if Bob is a very dishonest person none of these things is likely to save Alice's funds).

The payment flow

1. Suppose there exists a route Alice->Bob->Carol and Alice wants to send a payment to Carol.
2. First Alice reads an invoice she received from Carol. The invoice (which can be pretty similar or maybe even the same as BOLT11) contains a payment hash h and information about how to reach Carol's node, optionally an amount. Let's say it's 100 satoshis.
3. Using the routing information she gathered, Alice builds an onion and sends it to Bob, at the same time she offers to Bob a "conditional IOU". That stands for a signed commitment that Alice will owe Bob an 100 satoshis if in the next 50 blocks of the Rumple Chain there appears a block containing the preimage p such that sha256(p) == h.
4. Bob peels the onion and discovers that he must forward that payment to Carol, so he forwards the peeled onion and offers a conditional IOU to Carol with the same h. Bob doesn't know Carol is the final recipient of the payment, it could potentially go on and on.
5. When Carol gets the conditional IOU from Bob, she makes a list of all the nodes who have announced themselves as miners (which is not something I have mentioned before, but nodes that are acting as miners will must announce themselves somehow) and are online and bidding for the next Rumple block. Each of these miners will have previously published a random 32-byte value v they they intend to include in their next block.
6. Carol sends payments through routes to all (or a big number) of these miners, but this time the conditional IOU contains two conditions (values that must appear in a block for the IOU to be valid): p such that sha256(p) == h (the same that featured in the invoice) and v (which must be unique and constant for each miner, something that is easily verifiable by Carol beforehand). Also, instead of these conditions being valid for the next 50 blocks they are valid only for the single next block.
7. Now Carol broadcasts p to the mempool and hopes one of the miners to which she sent conditional payments sees it and, allured by the possibility of cashing in Carol's payment, includes p in the next block. If that does not happen, Carol can try again in the next block.

Why bother with this at all?

1. The biggest advantage of Lightning is its openness

   It has been said multiple times that if trust is involved then we don't need Lightning, we can use Coinbase, or worse, Paypal. This is very wrong. Lightning is good specially because it serves as a bridge between Coinbase, Paypal, other custodial provider and someone running their own node. All these can transact freely across the network and pay each other without worrying about who is in which provider or setup.

   Rumple inherits that openness. In a Rumple Network anyone is free to open new trust channels and immediately route payments to anyone else.

   Also, since Rumple payments are also based on the reveal of a preimage it can do swaps with Lightning inside a payment route from day one (by which I mean one can pay from Rumple to Lightning and vice-versa).

2. Rumple fixes Lightning's fragility

   Lightning is too fragile.

   It's known that Lightning is vulnerable to multiple attacks -- like the flood-and-loot attack, for example, although not an attack that's easy to execute, it's still dangerous even if failed. Given the existence of these attacks, it's important to not ever open channels with random anonymous people. Some degree of trust must exist between peers.

   But one does not even have to consider attacks. The creation of HTLCs is a liability that every node has to do multiple times during its life. Every initiated, received or forwarded payment require adding one HTLC then removing it from the commitment transaction.

   Another issue that makes trust needed between peers is the fact that channels can be closed unilaterally. Although this is a feature, it is also a bug when considering high-fee environments. Imagine you pay $2 in fees to open a channel, your peer may close that unilaterally in the next second and then you have to pay another $15 to close the channel. The opener pays (this is also a feature that can double as a bug by itself). Even if it's not you opening the channel, a peer can open a channel with you, make a payment, then clone the channel, and now you're left with, say, an output of 800 satoshis, which is equal to zero if network fees are high.

   So you should only open channels with people you know and know aren't going to actively try to hack you and people who are not going to close channels and impose unnecessary costs on you. But even considering a fully trusted Lightning Network, even if -- to be extreme -- you only opened channels with yourself, these channels would still be fragile. If some HTLC gets stuck for any reason (peer offline or some weird small incompatibility between node softwares) and you're forced to close the channel because of that, there are the extra costs of sweeping these UTXO outputs plus the total costs of closing and reopening a channel that shouldn't have been closed in the first place. Even if HTLCs don't get stuck, a fee renegotiation event during a mempool spike may cause channels to force-close, become valueless or settle for very high closing fee.

   Some of these issues are mitigated by Eltoo, others by only having channels with people you trust. Others referenced above, plus the the griefing attack and in general the ability of anyone to spam the network for free with payments that can be pending forever or a lot of payments fail repeatedly makes it very fragile.

   Rumple solves most of these problems by not having to touch the blockchain at all. Fee negotiation makes no sense. Opening and closing channels is free. Flood-and-loot is a non-issue. The griefing attack can be still attempted as funds in trust channels must be reserved like on Lightning, but since there should be no theoretical limit to the number of prepared payments a channel can have, the griefing must rely on actual amounts being committed, which prevents large attacks from being performed easily.

3. Rumple fixes Lightning's unsolvable reputation issues

   In the Lightning Conference 2019, Rusty Russell promised there would be pre-payments on Lightning someday, since everybody was aware of potential spam issues and pre-payments would be the way to solve that. Fast-forward to November 2020 and these pre-payments have become an apparently unsolvable problem¹: no one knows how to implement them reliably without destroying privacy completely or introducing worse problems.

   Replacing these payments with tables of reputation between peers is also an unsolved problem², for the same reasons explained in the thread above.

4. Rumple solves the hot wallet problem

   Since you don't have to use Bitcoin keys or sign transactions with a Rumple node, only your channel trust is at risk at any time.

5. Rumple ends custodianship

   Since no one is storing other people's funds, a big hub or wallet provider can be used in multiple payment routes, but it cannot be immediately classified as a "custodian". At best, it will be a big debtor.

6. Rumple is fun

   Opening channels with strangers is boring. Opening channels with friends and people you trust even a little makes that relationship grow stronger and the trust be reinforced. (But of course, like it happens in the Lightning Network today, if Rumple is successful the bulk of trust will be from isolated users to big reliable hubs.)

Questions or potential issues

1. So many advantages, yes, but trusted? Custodial? That's easy and stupid!

   Well, an enormous part of the current Lightning Network (and also onchain Bitcoin wallets) already rests on trust, mainly trust between users and custodial wallet providers like ZEBEDEE, Alby, Wallet-of-Satoshi and others. Worse: on the current Lightning Network users not only trust, they also expose their entire transaction history to these providers³.

   Besides that, as detailed in point 3 of the previous section, there are many unsolvable issues on the Lightning protocol that make each sovereign node dependent on some level of trust in its peers (and the network in general dependent on trusting that no one else will spam it to death).

   So, given the current state of the Lightning Network, to trust peers like Rumple requires is not a giant change -- but it is still a significant change: in Rumple you shouldn't open a large trust channel with someone just because it looks trustworthy, you must personally know that person and only put in what you're willing to lose. In known brands that have reputation to lose you can probably deposit more trust, same for long-term friends, and that's all. Still it is probably good enough, given the existence of MPP payments and the fact that the purpose of Rumple is to be a payments network for day-to-day purchases and not a way to buy real estate.

2. Why would anyone run a node in this parallel chain?

   I don't know. Ideally every server running a Rumple Network node will be running a Bitcoin node and a Rumple chain node. Besides using it to confirm and publish your own Rumple Network transactions it can be set to do BMM mining automatically and maybe earn some small fees comparable to running a Lightning routing node or a JoinMarket yield generator.

   Also it will probably be very lightweight, as pruning is completely free and no verification-since-the-genesis-block will take place.

3. What is the maturity of the debt that exists in the Rumple Network or its legal status?

   By default it is to be understood as being payable on demand for payments occurring inside the network (as credit can be used to forward or initiate payments by the creditor using that channel). But details of settlement outside the network or what happens if one of the peers disappears cannot be enforced or specified by the network.

   Perhaps some standard optional settlement methods (like a Bitcoin address) can be announced and negotiated upon channel creation inside the protocol, but nothing more than that.

I took jq's C code and compiled it with Emscripten, then added a wrapper so it would run on a browser with either asm.js or WebAssembly.

I believe I needed it for requesthub.xyz but I'm not sure I ever used it there. I also intended to use it on another (secret) project that relied on heavy data manipulation on the client, but it turned out to be too slow for that so I opted to use JavaScript directly. Later I used it for a client-side Etleneum simulator, but removed it later as it was impossible to replicate most of the Etleneum functionality on the client so the simulator was too broken and confusing.

• https://github.com/fiatjaf/jq-web

See also

-

This is a simplification, but let's say that basically there are just 3 kinds of websites:

1. Websites with content: text, images, videos;
2. Websites that run full apps that do a ton of interactive stuff;
3. Websites with some interactive content that uses JavaScript, or "mini-apps";

In a saner world we would have 3 different ways of serving and using these. 1 would be "the web" (and it was for a while, although I'm not claiming here that the past is always better and wanting to get back to the glorious old days).

1 would stay as "the web", just static sites, styled with CSS, no JavaScript whatsoever, but designers can still thrive and make they look pretty. Or it could also be something like Gemini. Maybe the two protocols could coexist.

2 would be downloadable native apps, much easier to write and maintain for developers (considering that multi-platform and cross-compilation is easy today and getting easier), faster, more polished experience for users, more powerful, integrates better with the computer.

(Remember that since no one would be striving to make the same app run both on browsers and natively no one would have any need for Electron or other inefficient bloated solutions, just pure native UI, like the Telegram app, have you seen that? It's fast.)

But 2 is mostly for apps that people use every day, something like Google Docs, email (although email is also broken technology), Netflix, Twitter, Trello and so on, and all those hundreds of niche SaaS that people pay monthly fees to use, each tailored to a different industry (although most of functions they all implement are the same everywhere). What do we do with dynamic open websites like StackOverflow, for example, where one needs to not only read, but also search and interact in multiple ways? What about that website that asks you a bunch of questions and then discovers the name of the person you're thinking about? What about that mini-app that calculates the hash of your provided content or shrinks your video, or that one that hosts your image without asking any questions?

All these and tons of others would fall into category 3, that of instantly loaded apps that you don't have to install, and yet they run in a sandbox.

The key for making category 3 worth investing time into is coming up with some solid grounds, simple enough that anyone can implement in multiple different ways, but not giving the app too much choices.

Telegram or Discord bots are super powerful platforms that can accomodate most kinds of app in them. They can't beat a native app specifically made with one purpose, but they allow anyone to provide instantly usable apps with very low overhead, and since the experience is so simple, intuitive and fast, users tend to like it and sometimes even pay for their services. There could exist a protocol that brings apps like that to the open world of (I won't say "web") domains and the websockets protocol -- with multiple different clients, each making their own decisions on how to display the content sent by the servers that are powering these apps.

Another idea is that of Alan Kay: to design a nice little OS/virtual machine that can load these apps and run them. Kinda like browsers are today, but providing a more well-thought, native-like experience and framework, but still sandboxed. And I add: abstracting away details about design, content disposition and so on.

These 3 kinds of programs could coexist peacefully. 2 are just standalone programs, they can do anything and each will be its own thing. 1 and 3, however, are still similar to browsers of today in the sense that you need clients to interact with servers and show to the user what they are asking. But by simplifying everything and separating the scopes properly these clients would be easy to write, efficient, small, the environment would be open and the internet would be saved.

See also

• On the state of programs and browsers

This approach is loosely based on the guido-hulsmann concept of "cluster of errors" and on general ideas about capital heterogeneity taken from Lachmann.

• Interest is just another price. Let's consider just flow of money and changes in relative prices instead.
• Monetary policy is just one possible cause of relative prices misalignment.
• The base interest rate is not very important, if there's a big flow of money to one specific sector that's what matters. There will be an unsustainable boom there.
• Of course if there's a general reduction in interest rates that means there's a general flow of money to multiple sectors (those with lengthier production processes) or even disequilibria inside sectors towards more roundaboutness in an unsustainable manner (to talk about sectors is an oversimplification, these things don't exist in fact).
• The standard ABCT formulation gives too much importance to the banking sector, as if it had a role in the economy much more important than anything else. That may not be the case. And even without banks at all still boom-bust cycles would happen if a new flow of printed money is directed somewhere (anywhere).

This new approach solves: * Critiques of the theory like "oh, entrepreneurs are rational, they will know the monetary policy and don't overinvest" because now we can make it clear that they will follow relative prices. * The problem with talking about one single interest rate, as in the real world there multiple interest rates -- or in fact multiple interest rates for each agent at each point on time. * The problem with hayekian triangles. We can ignore these now because the concept of a general lengthening of a general production process is not the characteristic of the cycle anymore. That is just one possible example of cycle -- one that's probably very rare. * Garrison's powerpoint fundamental problem: it ignores the fundamental insight from Solow's growth model according to which economic growth can't be explained by considering just aggregate savings/investments.

Networks of circles of production

Instead of thinking in triangles¹ we can think in networks of circles of variable sizes.

If we imagine there's a circle which represents one kind of good produced and for some reason there's an stimulus for the production of that good (for example, a governmental program that uses newly-printed money to subsidize loans for that specifically) that circle will get bigger. In the process of getting bigger it will also make bigger the circles that were already around it, and the biggerness will gradually spread.

That means new investment is being made on each of these industries, malinvestiment. People and resources are migrating from other, more distant circles, to these circles nearer the epicenter of malinvestment.

Representing the cycle that way we're free to oversimplify as you can just say: the real world is like this, but with many more circles and more complex relationships between them. You can also alternate between considering the circles sectors, industries or individual companies.

No sequential "steps" of production, just plans

Instead of imagining production princesses with discrete sequential steps we should also consider actually just plans.

Entrepreneurs predict there will be demand and predict there well be suppliers with reasonable prices for them to complete a plan. The plan can be arbitrarily divided into production and sale of a good, but actually often these parts are not so simply detached from each other.

In the network of circles the plan can be visualized as one circle looking around and seeing the other circles and estimating their future behavior.

The boom stops and the bust happens when the predictions fail. They fail because the unsustainable stimulus that was causing some of the circles to increase continuously stops.

nostr:npub1ej493cmun8y9h3082spg5uvt63jgtewneve526g7e2urca2afrxqm3ndrm 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

The simplest possible service: it splitted PDF pages in half.

Created specially to solve the problem of those scanned books that come with two pages side-by-side as if they were a single page and are much harder to read on Kindle because of that.

It required me to learn about Heroku Buildpacks though, and fork or contribute to a Heroku Buildpack that embedded a mupdf binary.

• https://github.com/fiatjaf/splitpages
• https://splitpages.herokuapp.com/

O economista americano rapper ficou triste quando sua banda brasileira favorita encerrou suas atividades por crer que a demanda por discos de rap seria cada vez pior. Resposta: Robert Lucas e as expectativas dos Racionais.

O economista inglês queria muito arrumar uma namorada. Resposta: John Maynard Keynes e a demanda afetiva.

Quando o filho do economista austríaco chegou em casa todo sujo ele sem nem pensar ordenou que o moleque fosse tomar banho. Resposta: Friedrich Hayek e a ordem espontânea.

O economista americano tinha muito orgulho de ter em sua casa um valiosíssimo quadro de um impressionista francês. Resposta: Milton Friedman e o Monet raríssimo.

O economista austríaco jurou aos seus filhos que todos eles se mudariam para Brasília. Resposta: Eugen von Böhm-Bawerk e o “eu juro” da capital.

O economista alemão organizou um evento meio sertanejo meio religioso e colocou como organizador uma executiva que tinha quebrado suas últimas 4 empresas por má administração. Resposta: Karl Marx e a expo-oração da que mais-falia.

In the beginning of 2017 I didn't know Bitcoin was having a "blocksize debate". I had stopped paying attention to Bitcoin in 2014 after reading Tim Swanson's book on shitcoineiry and was surprise people even care about Bitcoin still while Ethereum and other fancy things were around.

My introduction to the subject was this interview with Andrew Stone and Andrew Clifford from Bitcoin Unlimited (still don't know who these guys are). I've listened to it and kinda liked the conspiracy theory about "a group of developers trying, against miners and users, to control the whole ecosystem by not allowing blocks to grow" (actually, if you listen to this interview that announced the creation of Blockstream and the sidechains whitepaper it does sound like a government agent bribing all the Core developers into forming a consortium that will turn Bitcoin into an Ethereum-like shitcoin under their control -- but this is just a useless digression).

Some time later I listened to this interview with Jimmy Song and was introduced to two hard forks and conspiracies and New York Agreement and got excited because I didn't care about Bitcoin (I'm ashamed to remember this feeling) and wanted to see things changing, people fighting, Bitcoin burning, for no reason. Oddly, what I grasped from the interview was that Jimmy Song was defending the agreement and expecting everybody to fulfill it.

When the day actually come and "Bitcoin Cash" forked I looked at it with pity because it looked clearly a failure from the beginning, but I still cheered for it a bit, still not knowing anything about the debate, besides the fact that blocks were bigger on BCH, which looked like a very reductionist explanation to me.

"Of course it's not just making blocks bigger, that would be too simple, they probably have a very complex plan I'm not apt to understand", I thought.

To my surprise the entire argument was actually just that: bigger blocks bigger blocks. I came to that conclusion by listening to tomwoods.com/1064, a debate in which reasonable arguments faced childish claims. That debate gave me perspective and was a clear, undisputed win from Jameson Lopp against Roger Ver.

Actually some time before that I had listened to another Tom Woods Show episode thinking it was going to be an episode about Bitcoin, but in fact it was just propaganda about a debate I had almost forgotten. And nothing about Bitcoin, everything about "Bitcoin Cash" and how there were two Bitcoins, one legitimate and the other unlegitimate.

So, from the perspective of someone that came to the debate totally fresh and only listens to the big-blocker arguments for a long time, they still don't convince anyone with some common sense (as I would like to think of myself), they just sound like mad dogs and everything goes against themselves.

Fast forward to the present and with much more understanding of the issues in place I started digging some material from 2016-2017 about the debate to try to get more context, and found this ridiculous interview with Mike Hearn. It isn't a waste of time to listen to it if you're not familiar with the debate from that time.

As I should have probably expected from my experience with Epicenter.tv, both the interviewers agree with Mike Hearn about his ridiculous claims about how (not his words) we have to subsidize the few thousand current Bitcoin users by preventing fees from increase and there are no trade-offs to doing that -- and even with everybody agreeing they all manage to sound stupid. There's not a single phrase that is defendable in the entire interview, no criticisms make any sense, it makes me feel bad for the the guy as he feels so self-assured and obviouslyright.

After knowing about these and other adventures of stupid people with high influences in the Bitcoin world trying to impose their idiocy on others it feels even more odd and unexpected to find Bitcoin in the right track. Generally in politics the most dumb wins, but apparently not in Bitcoin.

Bitcoin is a miracle.

N'A estrutura das revoluções científicas, Thomas Kuhn descreve como surge uma ciência: um monte de gente fica tentando descobrir como uma coisa funciona a partir da sua própria experiência e escreve livros descrevendo isso. Cada um fala uma coisa completamente diferente, várias escolas de pensamento surgem e se combatem, até que por algum motivo uma mudança qualitativa aparece e faz com que todos concordem com uma base comum -- exceto é claro os que não concordam e esses são sumariamente expulsos do convívio dos demais --, os vários grupos deixam de existir ou se reformulam para que suas teses específicas passem a ter como base aquele novo paradigma, e então todo mundo passa a se comunicar por artigos que pressupõem várias coisas que eles têm em comum, e não mais por livros que partem dos menores princípios e tentam explicar tudo.

É um belo paradigma para compreender como a ciência funciona, e explica o estado real das coisas muito melhor do que o vômito ideológico dos cientistas mirins da internet que repetem asneiras sobre o "método científico".

mas o problema que me ocorreu foi: quem garante que esse paradigma representa realmente um avanço? Será que o desejo de concordar e se sentir incluído não foi o que fez com que todos os envolvidos o aceitassem? Não digo nem que essa nova descoberta esteja errada, mas ela -- e sua aceitação como novo paradigma -- criam um recorte da realidade dentro do qual aquela nova ciência que surge estará fadada a operar dali em diante, mas quem disse que esse recorte é mesmo o melhor lugar para que todos operem?

Talvez uma idéia melhor seria que as pessoas avaliassem aquele novo paradigma, mas não mergulhassem de cabeça nele.

Uma hipótese alternativa do porquê esse recorte e surgimento da ciência acontece: ela é mais fácil de ser abarcada pela burocracia universitária e empregar mentes medíocres na "pesquisa" uma coisa pequena e sem importância que já está ali dada pelo próprio conceito da ciência e não será nenhuma descoberta nova.

• Método científico
• Thomas Kuhn sequer menciona o "método científico"

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

By spam I mean any undesired, automated or subjectively low-value content. You can also include harassment and other bad things in this category, it doesn't matter.

The main feed

Nostr doesn't have a problem with spam in your main feed, as you only read notes from people you follow or from relay feeds chosen manually that are likely to not have spam (of course you can also read from relays full of spam, but that would be your choice).

So this problem is solved.

The "inbox" spam

Currently it's possible, in some clients and depending on some user configuration, to spam someone by mentioning them or replying to their notes, which causes spam to show up for them in their "notifications" tab or analogous place.

The solution to this is for clients to only read mentions or replies (["REQ", "inbox", {"#p": ["<user-pubkey>"]}]) from relays marked as "read" in the user's kind:10002. These relays are also the relays other well-behaving clients will pick when mentioning someone, so by reading only from these "read" relays no one will lose any notifications.

That, per se, doesn't fix anything. The fix comes when users start to set as their "read" relays relays that filter out spam by excluding low-value throwaway pubkeys or low-value content.

What relays do this? relay.mostr.pub, for example, has this nip05 requirement that will prevent most types of spam; pyramid.fiatjaf.com/inbox, (and any other self-hosted instance) will compute an aggregated 2-level WoT filter for all relay members and only accept incoming notes from such people (it will also block hellthreads); pow.relays.land or paid relays like nostr.wine can be used as fallbacks for when people really want to reach out to someone but they can't fulfill the initial requirements.

I'm just listing some examples, but the space needs more relays that do this filtering. Specifically, it would be nice if some well-intentioned relay provider (there are many people with good hearts out there already hosting relays for free) set up some "inbox" relay (I can imagine inbox.nostr.wine or inbox.yakihonne.com or read.nos.lol) that did some basic antispam filtering by content or by excluding keys using a broader definition of high-value pubkey based on some global algorithm.

Assuming such infrastructure exists, clients should start setting up these public specialized inbox relays as the default for users that do not care, so they won't see spam as their first Nostr experience.

The reply spam

The "inbox" spam is trivial to fix, but now we move to the third and hardest of spam avenues: other people's threads.

When browsing their own threads in an ideal client a user will only be seeing replies that can be found in their own "read" relays (say, pyramid.bob.com/inbox and inbox.yakihonne.com), because that's where everybody sent their replies to and that's the only relevant place to read replies from, so they won't see any spam there.

But, when going to read someone else's thread, he will also fetch replies from their "read" relays, and these may be full of spam, like public.nostr.at, and the thread will have spam in it. How do we solve that?

If the practices outlined above become widespread, it will also become evident that, if you're seeing spam at someone else's thread that is their fault. It's their fault for not picking "read" relays correctly.

And maybe they did it on purpose, they like some specific kind of spam, so if that bothers you you shouldn't go on their threads anymore. But maybe they are just unaware of the issue, so anyone can easily inform them and they can find a better set of "read" relays.

Again, this is not to say every single user must have an ardent desire for tweaking their own relay configurations, all clients should set up sensible defaults for users, but that doesn't mean that relay configurations are meaningless and that users should have no responsibility whatsoever for their configurations and still assume everything will be great. If they misconfigure things once or if their current configuration stops working they'll have to fix it, with or without a nice client-provided AI-generated friendly advisor bot. Eventually people should stop going to someone else's house if the house is always dirty.

Local filtering

Many people will read this and complain that these relay settings are not necessary and that all filtering must be done locally, using mutes, shared mutelists or client-side WoT. To these people I must say: yes, but also no.

Yes because such client-side techniques can complement the relay filtering and catch some lucky spam content that was able to pass through the well-configured relay barrier.

Mutes and mutelists can be very good when dealing with some specific real user that is harassing or bothering others, but it obviously does not work against spambots as these will use an infinite number of public keys.

Client-side WoTs can address spambots, but they can't be the only thing a client relies on, for the simple reason that content must first be downloaded before it can be filtered. This means that in a future in which Nostr is big with no relay-based spam filtering clients would be downloading gigabytes of spam all day everyday just to filter everything locally, and that is a horrible situation. Even now a spammer can just flood a thread with >500 spam replies and that will cause the naïve relay to serve only the top 500 replies to such note, which means all the real replies will not be shown (assuming most relays are configured to hard-limit queries at 500 and no pagination is done).

Another issue with client-side WoTs is that it is a monolithic solution: while the relay-based filtering allows users to choose what kind of replies they want to see by simply picking the relays that have the desired configurations, on the client side they would probably have to change clients in order to use a different technique, not to mention the fact that many of the antispam techniques available to relays wouldn't be possible to do on a client, so the options would be much more limited.

Maybe there are other techniques for filtering spam on the client side and they should be explored, but again these would be useful only for catching last-mile spam, they can't ever be a generalized solution.

The final argument against doing everything locally is that it doesn't create the overarching incentive structured outlined in the previous section: i.e., if I'm filtering everything locally that means I do not care for the fact that other people visiting my threads will see a ton of spam, and these people are left to fend for themselves and that spirals into a tragedy of the commons situation in which every Nostr user suffers.

Há esse conceito, criado pelo genial Nassim Nicholas Taleb, que diz respeito a processos nos quais a curva de retorno em relação a uma variável aleatória é convexa, ou seja, o retorno tende a ser maior quanto mais aleatoriedade for adicionada ao processo.

Disso aí, o próprio Taleb tira uma conclusão que resolve a questão da pesquisa científica propositada contra a sorte, sobre quais levam a melhores resultados práticos e invenções. Escreve ele:

A história da sorte versus conhecimento é a seguinte: Ironicamente, temos imensamente mais evidência de resultados (descobertas úteis) ligados à sorte do que de resultados vindos da prática teleológica (de telos, “objetivo”), exceto na física — mesmo depois de descontarmos o sensacionalismo. Em alguns campos opacos e não-lineares, como a medicina ou a engenharia, as exceções teleológicas são a minoria, assim como são um pequeno número de remédios projetados. Isto nos deixa numa contradição de que chegamos até aqui graças ao puro acaso não-direcionado, mas ao mesmo tempo criamos programas de pesquisa que miram num progresso com direção definida, baseado em narrativas sobre o passado. E, o que é pior, estamos totalmente conscientes desta inconsistência.

Por outro lado, pura sorte não poderia produzir melhorias sempre. Processos de tentativa e erro (que são os que produzem as descobertas “por sorte”) têm um elemento erro, e erros, diz Taleb, causam explosões de avião, quedas de edifícios e perda de conhecimento.

A resposta, portanto, está na antifragilidade: as áreas onde a sorte vence a teleologia são as áreas onde estão em jogo sistemas complexos, onde os nexos causais são desconhecidos ou obscuros — e são as áreas onde a curva de retornos é convexa.

Vejamos a mais sombria de todas, a culinária, que depende inteiramente da heurística da tentativa e erro, já que ainda não nos foi possível projetar um prato direto de equações químicas ou descobrir, por engenharia reversa, gostos a partir de tabelas nutricionais. Pega-se o hummus, adiciona-se um ingrediente, digamos, uma pimenta, prova-se para ver se há uma melhora no gosto e guarda-se a receita, se o gosto for bom, ou descarta-se-á. Imprescindivelmente temos a opção, e não a obrigação, de guardar o resultado, o que nos deixa reter a parte superior da curva e nos impede de sermos lesados pelos retornos adversos.

A conclusão geral é que, para obter os melhores resultados na invenção de tecnologias, deve-se usar a experimentação sem exageros e cálculos quando se identificar uma área antifrágil, e usar a pesquisa rígida e cheia de provas matemáticas (ou o equivalente) quando a área for frágil.

A inovação capitalista

Um processo antifrágil importantíssimo deste mundo é a inovação capitalista (dói-me usar este termo já tão mal-gasto e mal-definido por aí). Não falo, como alguns, da invenção de novas tecnologias, mas, como outros, da invenção de novas formas de usar as coisas (qualquer coisa) para melhorar a vida de alguém, de alguma forma — e aqui incluem-se pequenas adaptações de tecnologias antigas que dão origem a novas tecnologias não muito diferentes das antigas, e incluem-se também o oferecimento de algum serviço, trabalho ou produto já existente, mas de uma nova forma, possivelmente melhor para seu provável consumidor. Este tipo de inovação é, segundo me parece, o poder mais subestimado dos mercados livres, é irreplicável em laboratórios de pesquisa tecnológica (só pode surgir mesmo na vida real, da cabeça de quem está envolvido com o problema real que a inovação soluciona), e é o que gerou idéias como o restaurante self-service, a terceirização dos serviços de construção civil ou o Google.

Esse tipo de inovação (ao contrário do sentido de inovação ligado a pesquisas caríssimas em universidades ou megaempresas, identificada pela famigerada sigla P&D) é antifrágil porque não custa muito ao indivíduo, não requer investimentos gigantescos ou qualquer coisa assim, porque é normalmente apenas uma adaptação do que ele próprio já faz.

Para a sociedade, não representa custo algum: o serviço novo é oferecido paralelamente ao serviço antigo, seus consumidores potenciais podem escolher o que mais lhes agrada, e rejeitar o outro. Se a nova solução não for satisfatória os mecanismos automáticos do mercado (o prejuízo simples) encarregam-se automaticamente de remover aquela novidade — e, automaticamente, o indivíduo que a criou pode se voltar ao seu processo antigo, ou a uma nova invenção.

Ao mesmo tempo em que cometer um erro numa tentativa de inovação é barato e não atrapalha ninguém, um acerto pode ter conseqüências que melhoram enormemente a vida de muita gente. O restaurante self-service, por exemplo, provavelmente teve sua implementação tentada por restaurantes de serviço à la carte várias vezes, em vários formatos diferentes, sem muito prejuízo para o restaurante, que podia continuar com seu serviço à la carte (no Brasil, senão o inventor dessa modalidade de restaurante ao menos um dos seus grandes expoentes, estas tentativas ocorreram durante a década de 80). Mas, quando enfim deu certo, promoveu melhoras enormes na qualidade de vida de milhares de pessoas — que podem pagar mais barato e comer apenas o que querem e quanto querem, dentro de uma gama maior de opções, o que permite que trabalhadores de todos os tipos comam melhor todos os dias, fiquem mais felizes e gastem menos.

Eis aqui um exemplo entre outros mil, extraído das minhas apostilas de aulas, de como se analisam as relações entre fatores deliberados e casuais na ação histórica. O sr, Beltrão está INFINITAMENTE ABAIXO da possibilidade de discutir essas coisas, e por isso mesmo me atribui uma simploriedade que é dele próprio e não minha:

Já citei mil vezes este parágrafo de Georg Jellinek e vou citá-lo de novo: “Os fenômenos da vida social dividem-se em duas classes: aqueles que são determinados essencialmente por uma vontade diretriz e aqueles que existem ou podem existir sem uma organização devida a atos de vontade. Os primeiros estão submetidos necessariamente a um plano, a uma ordem emanada de uma vontade consciente, em oposição aos segundos, cuja ordenação repousa em forças bem diferentes.”

Essa distinção é crucial para os historiadores e os analistas estratégicos não porque ela é clara em todos os casos, mas precisamente porque não o é. O erro mais comum nessa ordem de estudos reside em atribuir a uma intenção consciente aquilo que resulta de uma descontrolada e às vezes incontrolável combinação de forças, ou, inversamente, em não conseguir enxergar, por trás de uma constelação aparentemente fortuita de circunstâncias, a inteligência que planejou e dirigiu sutilmente o curso dos acontecimentos.

Exemplo do primeiro erro são os Protocolos dos Sábios de Sião, que enxergam por trás de praticamente tudo o que acontece de mau no mundo a premeditação maligna de um número reduzidos de pessoas, uma elite judaica reunida secretamente em algum lugar incerto e não sabido.

O que torna essa fantasia especialmente convincente, decorrido algum tempo da sua publicação, é que alguns dos acontecimentos ali previstos se realizam bem diante dos nossos olhos. O leitor apressado vê nisso uma confirmação, saltando imprudentemente da observação do fato à imputação da autoria. Sim, algumas das idéias anunciadas nos Protocolos foram realizadas, mas não por uma elite distintamente judaica nem muito menos em proveito dos judeus, cuja papel na maioria dos casos consistiu eminentemente em pagar o pato. Muitos grupos ricos e poderosos têm ambições de dominação global e, uma vez publicado o livro, que em certos trechos tem lances de autêntica genialidade estratégica de tipo maquiavélico, era praticamente impossível que nada aprendessem com ele e não tentassem por em prática alguns dos seus esquemas, com a vantagem adicional de que estes já vinham com um bode expiatório pré-fabricado. Também é impossível que no meio ou no topo desses grupos não exista nenhum judeu de origem. Basta portanto um pouquinho de seletividade deformante para trocar a causa pelo efeito e o inocente pelo culpado.

Mas o erro mais comum hoje em dia não é esse. É o contrário: é a recusa obstinada de enxergar alguma premeditação, alguma autoria, mesmo por trás de acontecimentos notavelmente convergentes que, sem isso, teriam de ser explicados pela forca mágica das coincidências, pela ação de anjos e demônios, pela "mão invisível" das forças de mercado ou por hipotéticas “leis da História” ou “constantes sociológicas” jamais provadas, que na imaginação do observador dirigem tudo anonimamente e sem intervenção humana.

As causas geradoras desse erro são, grosso modo:

Primeira: Reduzir as ações humanas a efeitos de forças impessoais e anônimas requer o uso de conceitos genéricos abstratos que dão automaticamente a esse tipo de abordagem a aparência de coisa muito científica. Muito mais científica, para o observador leigo, do que a paciente e meticulosa reconstituição histórica das cadeias de fatos que, sob um véu de confusão, remontam às vezes a uma autoria inicial discreta e quase imperceptível. Como o estudo dos fenômenos histórico-políticos é cada vez mais uma ocupação acadêmica cujo sucesso depende de verbas, patrocínios, respaldo na mídia popular e boas relações com o establishment, é quase inevitável que, diante de uma questão dessa ordem, poucos resistam à tentação de matar logo o problema com duas ou três generalizações elegantes e brilhar como sábios de ocasião em vez de dar-se o trabalho de rastreamentos históricos que podem exigir décadas de pesquisa.

Segunda: Qualquer grupo ou entidade que se aventure a ações histórico-políticas de longo prazo tem de possuir não só os meios de empreendê-las, mas também, necessariamente, os meios de controlar a sua repercussão pública, acentuando o que lhe convém e encobrindo o que possa abortar os resultados pretendidos. Isso implica intervenções vastas, profundas e duradouras no ambiente mental. [Etc. etc. etc.]

(no facebook em 17 de julho de 2013)

James O'Beirne wrote this nice little article that contains a bunch of statements that should have been obvious to anyone who thought a little about Bitcoin's future, as they were obvious for Hal Finney in 2009 already.

Basically the article says that the Bitcoin blockchain won't scale for the entire world population to use it. It will so much not scale that even "offchain" solutions like Lightning and Ark will not scale and they basically lose usefulness as more adoption happens and fees rise.

Given that, Bitcoin has only two paths (and now this is not James speaking anymore): either it will die or it will have to scale using custodians.

Can Bitcoin die?

Yes, Bitcoin can die, and if Bitcoin fails to get some level of mass adoption soon enough I believe it will die. Governments all around the world gave us 14 years of advantage to try to get Bitcoin to become this money medium-of-exchange store-of-value thing, or at least an investment vehicle or savings-technology that is super valuable and with widespread ownership, but now it is starting to move. CBDCs have been talked about for a while, but now they are really starting to happen. Regulated and compliant fiat proprietary services like Venmo have grown under capture by governments, in some places the government itself has launched their own cool app-like totally regulated spyware fiat money transmission things, like the ridiculous PIX in Brazil, which is now widely adopted, and -- I believe surprisingly for all the UX designers out there -- people have learned to use QR codes.

The point is that, given a little bit of more time, governments can start to encroach on Bitcoin's space, making it more and more regulated until it either dies or becomes a very useless thing. Some Bitcoiners think Bitcoin has already won, this can't be further from the truth. Others think Bitcoin must not be mass adopted, it must stay as this niche and mostly useless currency digital asset thing or I don't really understand what they think. These people are wrong. There are also people who think Bitcoin should not be used by normal people as money, it should keep being adopted, but only as a store-of-value: this is also completely wrong, since Bitcoin's value tends to decrease as soon as owners realize Bitcoin is losing its chances of becoming actual money.

Scaling

To not die, Bitcoin must become more used. The current thesis accepted by most "maximalists" is that Bitcoin will continue to be thought of as an investment and its price will keep increasing, the price movements will bring more attention to it in a virtuous cycle. Eventually enough people will want to hold it so they will start accepting it as a payment for goods and services and then it can start to be used as money.

Assuming that will happen, we'll be faced with a problem: as people try to use it as money they will necessarily, by lack of other options, have to use some custodial solution or some proto-custodial solution, maybe using Lightning as a settlement layer between big custodians¹? I don't know. No one is happy with that solution, and rightfully so, since it is very dangerous. A small set of custodians can easily be captured by governments and they can slowly turn Bitcoin into fiat money like they did with gold.

In other words: without Drivechain, Bitcoin will be a fragile success in the best case and dead in the worst case scenario.

Enter Drivechain

Drivechain basically brings two things to the table:

In the best case scenario of the non-Drivechain world, we would be in a fragile position with easily-capturable custodians. With Drivechain, we can create a bunch of decentralized sidechains, backed by the same mining process that is assumed to be decentralized already for Bitcoin to even work, and we gain orders of magnitude of more room to make censorship-resistant open transactions that don't require tax IDs or selfies and can't be stopped or regulated by governments. Bitcoin can scale as it normally would, but it's much more resilient.

The other thing we get are improvements for the "dying" part. If Drivechain is successful, it may end up bringing much more people to Bitcoin. Hivemind by itself may attract lots of users and capital that has been prevented from betting on predictions anywhere in the fiat world since always; Zcash or Monero sidechains can easily bring all the "cryptocurrency" enthusiasts that care about privacy and have long ago decided that Bitcoin isn't for them, these people are interested in some immediate feature, that now Bitcoin can provide them with; other sidechains, like Ethereum-like chains, can also contribute to slowly bring in some of the users of these chains². Why would we want these people to come to Bitcoin? Because they will increase Bitcoin's network-effect, increase the satoshi price, and these changes would contribute for more people to start looking at Bitcoin and using Bitcoin and so on and so forth. More users, more network-effect, bigger price, will contribute for Bitcoin not being easily regulated and killed by governments.

In other words: with Drivechain will be a resilient success in the worst case and a complete and total world dominator money in the best case.

Recently Coracle has removed support for following relay hints in Nostr event references.

Supposedly Coracle is now relying only on public key hints and kind:10002 events to determine where to fetch events from a user. That is a catastrophic idea that destroys much of Nostr's flexibility for no gain at all.

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

(This was written in the context of donations to people who do free stuff on the internet, open-source software and so on.)

Donations are broken not because "few people care", but because it's an unsolvable information problem: no one knows how much they should be donating and to whom, and it would be impossible to even think about the perfect donation strategy, much more impossible to execute it.

I use a ton of free services and consume tons of different contents from multiple sources, but it only occurred me to donate to some. And I'm probably donating too much to these, while zero to all others, or maybe too few even to the few ones I donate to. I cannot know.

In the world of ideals there is a correct amount that each donor should be giving to each contributor in every single item in the full production structure of something the donors care about, but this is not a mathematical problem, it's the statement of an impossibility.

Maybe https://mises.org/library/superman-needs-agent is related.

At the time I thought Workflowy had the ideal UI for everything. I wanted to implement my custom app maker on it, but ended up doing this: a platform for enhancing Workflowy with extra features:

• An email reminder based on dates input in items
• A website generator, similar to Websites For Trello, also based on Classless Templates

Also, I didn't remember this was also based on CouchDB and had some couchapp functionalities.

• https://flowi.es
• https://github.com/fiatjaf/flowies

A CLI tool for navigating Trello boards. It used vorpal for an "immersive" experience and was pretty good.

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

Se na Grécia Antiga o homosexualismo era tão comum, não seria isso um argumento definitivo contra o pessoal que hoje afirma que o homosexualismo é natural e que 0.1%/1%/10%/25% das pessoas são homosexuais por natureza?

Se na Gŕecia Antiga havia muito mais de 25% de homosexuais e aqui até ontem eram menos de 1% (e agora subiu?) isso tudo não é evidência fortíssima de que o homosexualismo é mesmo cultural?

Most IPFS open-source projects, libraries and apps (excluding Ethereum stuff) are things that rely heavily on dynamic data and temporary links. The most common projects you'll see when following the IPFS communities are chat rooms and similar things. I've seen dozens of these chat-rooms. There's also a famous IPFS-powered database. How can you do these things with content-addressing is a mistery. Of course they probably rely on IPNS or other external address system.

There's also a bunch of "file-sharing" on IPFS. The kind of thing people use for temporary making a file available for a third-party. There's image sharing on IPFS, pastebins on IPFS and so on. People don't seem to share the preoccupation with broken links here.

A professora ensinou um método segundo o qual para ler uma sílaba, por exemplo, to, dizíamos rápido o nome das duas letras, cada vez mais rápido, tê ó tê ó t-ó tó, até acharmos o som correto da sílaba.

Até hoje não sei se esse é o "método fônico". Não me lembro jamais de ter que decorar uma tabela de pares de letras e sons resultantes ("b com a, bá; bê com é, bé" etc.).

Outra memória que eu tenho é de que essa técnica de falar as letras rápido foi fundamental para eu ter certeza de que sabia ler e estava lendo, mas de alguma eu já sabia ler antes de aprender a técnica, porque eu era capaz de, por exemplo, saber antes de qualquer coisa que ca era uma exceção à regra. Mesmo assim eu me lembro de passar muitas horas repetindo letras e confirmando que a técnica funcionava.

These two problems exist on Nostr today, and they look unrelated at first:

1. People adding more stuff to kind:1 notes, such as making them editable, or adding special corky syntax thas has to be parsed and rendered in complicated UIs;
2. The discovery of "other stuff" content (i.e. long-form articles, podcasts, calendar events, livestreams etc) is hard due to the fact that most people only use microblogging clients and they often don't appear there for them.

Point 2 above has 3 different solutions:

• a. Just publish everything as kind:1 notes;
• b. Publish different things as different kinds, but make microblogging clients fetch all the event kinds from people you follow, then render them natively or use NIP-31, or NIP-89 to point users to other clients that would render them better;
• c. Publish different things as different kinds, and reference them in kind:1 notes that would act as announcements to these other events, also relying on NIP-31 and NIP-89 for displaying references and recommending other clients.

Solution a is obviously very bad, so I won't address it.

For a while I have believed solution b was the correct one, and many others seem to tacitly agree with it, given that some clients have been fetching more and more event kinds and going out of their way to render them in the same feed where only kind:1 notes were originally expected to be.

I don't think clients doing that is necessarily bad, but I do think this have some centralizing effects on the protocol, as it pushes clients to become bigger and bigger, raising the barrier to entry into the kind:1 realm. And also in the past I have talked about the fact that I disliked that some clients would display my long-form articles as if they were normal kind:1 notes and just dump them into the feeds of whoever was following me: nostr:nevent1qqsdk90k9k30vtzwpj6grxys9mvsegu5kkwd4jmpyhlmtjnxet2rvggprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdqy8hwumn8ghj7mn0wd68ytnddaksygpm7rrrljungc6q0tuh5hj7ue863q73qlheu4vywtzwhx42a7j9n5hae35c

These and other reasons have made me switch my preference to solution c, as it gives the most flexibility to the publisher: whoever wants to announce stuff so it can be discovered can, whoever doesn't don't have to. And it allows microblogging clients the freedom to render just render tweets and having a straightforward barrier between what they can render and what is just a link to an external app or webapp (of course they can always opt to render the referenced content in-app if they want).

It also makes the case for microapps more evident. If all microblogging clients become superapps that can render recipe events perfectly why would anyone want to use a dedicated recipes app? I guess there are still reasons, but blurring the line between content kinds in superapps would definitely remove some of the reasons and eventually kill all the microapps.

That brings us back to point 1 above (the overcomplication of kind:1 events): if solution c is what we're going to, that makes kind:1 events very special in Nostr, and not just another kind among others. Microblogging clients become the central plaza of Nostr, thus protecting their neutrality and decentralization much more important. Having a lot of clients with different userbases, doing things in slightly different ways, is essential for that decentralization.

It's ok if Nostr ends up having just 2 recipe-sharing clients, but it must have dozens of microblogging clients -- and maybe not even full-blown microblogging clients, but other apps that somehow deal with kind:1 events in multiple ways. It's ok if implementing a client for public audio-rooms is very hard and complicated, but at the same time it should be very simple to write a client that can render a kind:1 note referencing an audio-room and linking to that dedicated client.

I hope you got my point and agreed because this article is ended.

Every time someone tries to "decentralize" Git -- like many projects tried in the past to do it with BitTorrent, IPFS, ScuttleButt or custom p2p protocols -- there is always a lurking comment: "but Git is already distributed!", and then the discussion proceeds to mention some facts about how Git supports multiple remotes and its magic syncing and merging abilities and so on.

Turns out all that is true, Git is indeed all that powerful, and yet GitHub is the big central hub that hosts basically all Git repositories in the giant world of open-source. There are some crazy people that host their stuff elsewhere, but these projects end up not being found by many people, and even when they do they suffer from lack of contributions.

Because everybody has a GitHub account it's easy to open a pull request to a repository of a project you're using if it's on GitHub (to be fair I think it's very annoying to have to clone the repository, then add it as a remote locally, push to it, then go on the web UI and click to open a pull request, then that cloned repository lurks forever in your profile unless you go through 16 screens to delete it -- but people in general seem to think it's easy).

It's much harder to do it on some random other server where some project might be hosted, because now you have to add 4 more even more annoying steps: create an account; pick a password; confirm an email address; setup SSH keys for pushing. (And I'm not even mentioning the basic impossibility of offering push access to external unknown contributors to people who want to host their own simple homemade Git server.)

At this point some may argue that we could all have accounts on GitLab, or Codeberg or wherever else, then those steps are removed. Besides not being a practical strategy this pseudo solution misses the point of being decentralized (or distributed, who knows) entirely: it's far from the ideal to force everybody to have the double of account management and SSH setup work in order to have the open-source world controlled by two shady companies instead of one.

What we want is to give every person the opportunity to host their own Git server without being ostracized. at the same time we must recognize that most people won't want to host their own servers (not even most open-source programmers!) and give everybody the ability to host their stuff on multi-tenant servers (such as GitHub) too. Importantly, though, if we allow for a random person to have a standalone Git server on a standalone server they host themselves on their wood cabin that also means any new hosting company can show up and start offering Git hosting, with or without new cool features, charging high or low or zero, and be immediately competing against GitHub or GitLab, i.e. we must remove the network-effect centralization pressure.

External contributions

The first problem we have to solve is: how can Bob contribute to Alice's repository without having an account on Alice's server?

SourceHut has reminded GitHub users that Git has always had this (for most) arcane git send-email command that is the original way to send patches, using an once-open protocol.

Turns out Nostr acts as a quite powerful email replacement and can be used to send text content just like email, therefore patches are a very good fit for Nostr event contents.

Once you get used to it and the proper UIs (or CLIs) are built sending and applying patches to and from others becomes a much easier flow than the intense clickops mixed with terminal copypasting that is interacting with GitHub (you have to clone the repository on GitHub, then update the remote URL in your local directory, then create a branch and then go back and turn that branch into a Pull Request, it's quite tiresome) that many people already dislike so much they went out of their way to build many GitHub CLI tools just so they could comment on issues and approve pull requests from their terminal.

Replacing GitHub features

Aside from being the "hub" that people use to send patches to other people's code (because no one can do the email flow anymore, justifiably), GitHub also has 3 other big features that are not directly related to Git, but that make its network-effect harder to overcome. Luckily Nostr can be used to create a new environment in which these same features are implemented in a more decentralized and healthy way.

Issues: bug reports, feature requests and general discussions

Since the "Issues" GitHub feature is just a bunch of text comments it should be very obvious that Nostr is a perfect fit for it.

I will not even mention the fact that Nostr is much better at threading comments than GitHub (which doesn't do it at all), which can generate much more productive and organized discussions (and you can opt out if you want).

Search

I use GitHub search all the time to find libraries and projects that may do something that I need, and it returns good results almost always. So if people migrated out to other code hosting providers wouldn't we lose it?

The fact is that even though we think everybody is on GitHub that is a globalist falsehood. Some projects are not on GitHub, and if we use only GitHub for search those will be missed. So even if we didn't have a Nostr Git alternative it would still be necessary to create a search engine that incorporated GitLab, Codeberg, SourceHut and whatnot.

Turns out on Nostr we can make that quite easy by not forcing anyone to integrate custom APIs or hardcoding Git provider URLs: each repository can make itself available by publishing an "announcement" event with a brief description and one or more Git URLs. That makes it easy for a search engine to index them -- and even automatically download the code and index the code (or index just README files or whatever) without a centralized platform ever having to be involved.

The relays where such announcements will be available play a role, of course, but that isn't a bad role: each announcement can be in multiple relays known for storing "public good" projects, some relays may curate only projects known to be very good according to some standards, other relays may allow any kind of garbage, which wouldn't make them good for a search engine to rely upon, but would still be useful in case one knows the exact thing (and from whom) they're searching for (the same is valid for all Nostr content, by the way, and that's where it's censorship-resistance comes from).

Continuous integration

GitHub Actions are a very hardly subsidized free-compute-for-all-paid-by-Microsoft feature, but one that isn't hard to replace at all. In fact there exists today many companies offering the same kind of service out there -- although they are mostly targeting businesses and not open-source projects, before GitHub Actions was introduced there were also many that were heavily used by open-source projects.

One problem is that these services are still heavily tied to GitHub today, they require a GitHub login, sometimes BitBucket and GitLab and whatnot, and do not allow one to paste an arbitrary Git server URL, but that isn't a thing that is very hard to change anyway, or to start from scratch. All we need are services that offer the CI/CD flows, perhaps using the same framework of GitHub Actions (although I would prefer to not use that messy garbage), and charge some few satoshis for it.

It may be the case that all the current services only support the big Git hosting platforms because they rely on their proprietary APIs, most notably the webhooks dispatched when a repository is updated, to trigger the jobs. It doesn't have to be said that Nostr can also solve that problem very easily.

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

A Telegram bot I made just because I was bored and no one had done yet. I didn't have any experience with Telegram bots or running a Lightning Network node, but it turned out to be quite well-received and successful.

As I slowly included things in it, lnurl stuff, custom integrations to other apps and social features, It has a large number of commands and arcane functionality hidden in it. This opaque output of the /help command is a hint:

/start [<tutorial>]
/lnurl <lnurl>
/receive (lnurl | (any | <satoshis>) [<description>...])
/pay (lnurl <satoshis> | [now] [<invoice>] [<satoshis>])
/send [anonymously] <satoshis> [<receiver>...] [--anonymous]
/balance [apps]
/apps
/tx <hash>
/log <hash>
/transactions [<tag>] [--in] [--out]
/giveaway <satoshis>
/coinflip <satoshis> [<num_participants>]
/giveflip <satoshis> [<num_participants>]
/fundraise <satoshis> <num_participants> <receiver>...
/hide <satoshis> [<message>...] [--revealers=<num_revealers>] [--crowdfund=<num_participants>] [--public] [--private]
/reveal <hidden_message_id>
/etleneum [history | withdraw | (apps | contracts) | call <id> | <contract> [state [<jqfilter>] | subscribe | unsubscribe | <method> [<satoshis>] [<params>...]]]
/satellite <satoshis> [<message>...]
/bitclouds [create | status [<host>] | topup <satoshis> [<host>] | adopt <host> | abandon <host>]
/rub <service> <account> [<rub>]
/skype <username> [<usd>]
/bitrefill (country <country_code> | <query> [<phone_number>])
/gifts (list | [<satoshis>])
/sats4ads (on [<msat_per_character>] | off | rate | rates | broadcast <satoshis> [<text>...] [--max-rate=<maxrate>] [--skip=<offset>] | preview)
/api [full | invoice | readonly | url | refresh]
/lightningatm
/bluewallet [refresh]
/rename <name>
/toggle (ticket [<price>] | renamable [<price>] | spammy | language [<lang>] | coinflips)
/dollar <satoshis>
/moon
/help [<command>]
/stop

• https://t.me/lntxbot

Todos os livros didáticos e cursos expõem seus conteúdos a partir de uma organização lógica prévia, um esquema de todo o conteúdo que julgam relevante, tudo muito organizadinho em tópicos e subtópicos segundo a ordem lógica que mais se aproxima da ordem natural das coisas. Imagine um sumário de um manual ou livro didático.

A minha experiência é a de que esse método serve muito bem para ninguém entender nada. A organização lógica perfeita de um campo de conhecimento é o resultado final de um estudo, não o seu início. As pessoas que escrevem esses manuais e dão esses cursos, mesmo quando sabem do que estão falando (um acontecimento aparentemente raro), o fazem a partir do seu próprio ponto de vista, atingido após uma vida de dedicação ao assunto (ou então copiando outros manuais e livros didáticos, o que eu chutaria que é o método mais comum).

Para o neófito, a melhor maneira de entender algo é através de imersões em micro-tópicos, sem muita noção da posição daquele tópico na hierarquia geral da ciência.

• Revista Educativa, um exemplo de como não ensinar nada às crianças.
• Zettelkasten, a ordem surgindo do caos, ao invés de temas se encaixando numa ordem preexistentes.

See Drivechain for an introduction. Here we'll just have a list of reasons why miners would not steal:

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

• Como não houve resposta, estou enviando de novo
• Democracia na América
• A "política" é a arena da vitória do estatismo
• A biblioteca infinita
• Família e propriedade
• Memórias de quando eu aprendi a ler
• A chatura Kelsen
• O VAR é o grande equalizador
• Não tem solução
• A estrutura lógica do livro didático
• "House" dos economistas e o Estado
• Revista Educativa
• Cultura Inglesa e aprendizado extra-escolar
• Veterano não é dono de bixete
• Personagens de jogos e símbolos
• Músicas grudentas e conversas
• Obra aqui do lado
• Propaganda
• Ver Jesus com os olhos da carne
• Processos Antifrágeis
• Cadeias, crimes e cidadãos de bem
• Castas hindus em nova chave
• Método científico
• Xampu
• Thafne venceu o Soletrando 2008.
• Empreendendorismo de boteco
• Problemas com Russell Kirk
• Pequenos problemas que o Estado cria para a sociedade e que não são sempre lembrados

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

• On "zk-rollups" applied to Bitcoin

This started as a reimplementation of the Spark Wallet server (which also included the client app, copied directly) because NodeJS isn't a proper way to distribute software to end users and it was also a pain for me to install. I could do a program that ran as a single binary.

Then when c-lightning released their plugin infrastructe I made this a plugin.

And then introduced fine-grained method authorization for multiple keys, and full-blown SSE-based subscriptions for plugin events.

It is a now a single wrapper that can be used to develop apps that talk to a Lightning layer very easily, as well as a simple wallet.

It is integrated into Zeus, LNbits and https://tip.bigsun.xyz/.

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

See also

• trustedcoin

If a miner coalition has 75% of hashrate for 6 months they can steal coins from a Drivechain without any risk, that's what the drivechain haters say.

What other evil things can a coalition of 75% hashrate do in 6 months?

• steal money from all open Lightning nodes on the network by opening channels to them, mining 3 blocks, spending the funds out on Lightning instantly, then rolling back the 3 blocks and canceling the channel.
• the above would eventually -- but not instantly and only after many steals have happened (even if they're not all perfectly coordinated and instant) -- cause Lightning to shrink in size a lot and become more of a closed friends network than truly open.
• only mine empty blocks and cause the mempool to be enormously clogged.
• refuse to use the mempool, force a proprietary API for transaction propagation with zero transparency and force other miners to use that same infrastructure too and extract a fee from them.
• censor anything and force other miners to censor too, at the threat of orphaning their blocks.
• easily cause so much confusion in the mining process that Bitcoin is deemed unusable and price falls drastically, miners can then buy at low price.

In the context of protocols for peer-to-peer open computer networks -- those in which new actors can freely enter and immediately start participating in the protocol --, without any central entity, specially without any central human mind judging things from the top --, it's common for decisions about the protocol to be thought taking in consideration all the possible ways a rogue peer can disrupt the entire network, abuse it, make the experience terrible for others. The protocol design must account for all incentives in play and how they will affect each participant, always having in mind that each participant may be acting in a purely egoistical self-interested manner, not caring at all about the health of the network (even though most participants won't be like that). So a protocol, to be successful, must have incentives aligned such that self-interested actors cannot profit by hurting others and will gain most by cooperating (whatever that means in the envisaged context), or there must be a way for other peers to detect attacks and other kinds of harm or attempted harm and neutralize these.

Since computers are very fast, protocols can be designed to be executed many times per day by peers involved, and since the internet is a very open place to which people of various natures are connected, many open-network protocols with varied goals have been tried in large scale and most of them failed and were shut down (or kept existing, but offering a bad experience and in a much more limited scope than they were expected to be). Often the failure of a protocol leads to knowledge about its shortcomings being more-or-less widespread and agreed upon, and these lead to the development of a better protocol the next time something with similar goals is tried.

Ideally democracies are supposed to be an open-entry network in the same sense as these computer networks, and although that is a noble goal, it's one full of shortcomings. Democracies are supposed to the governing protocol of States that have the power to do basically anything with the lives of millions of citizens.

One simple inference we may take from the history of computer peer-to-peer protocols is that the ones that work better are those that are simple and small in scope (Bitcoin, for example, is very simple; BitTorrent is also very simple and very limited in what it tries to do and the number of participants that get involved in each run of the protocol).

Democracies, as we said above, are the opposite of that. Besides being in a very hard position to achieve success as an open protocol, democracies also suffer from the fact that they take a long time to run, so it's hard to see where it is failing every time.

The fundamental incentives of democracy, i.e. the rules of the protocol, posed by the separation of powers and checks-and-balances are basically the same in every place and in every epoch since the XIII century, and even today most people who dedicate their lives to the subject still don't see how they're completely flawed.

The system of checks and balances was thought from the armchair of a couple of political theorists who had never done anything like that in their lives, didn't have any experience dealing with very adversarial environments like the internet -- and probably couldn't even imagine that the future users of their network were going to be creatures completely different than themselves and their fellow philosophers and aristocrats who all shared the same worldview (and how fast that future would come!).

Also

• The illusion of checks and balances

` DISCLAIMER: the following design is flawed and kept only for the history.

What follows is a way to design Lightning channels that don't use standalone HTLCs at all: instead the hashlocks are the Settlement transactions themselves, so instead of a Settlement have as many outputs as pending HTLCs, instead they always have 2 outputs: the 2 peers in the channel, but there are as many pairs of Update/Settlement transactions as there are combinations of payments in-flight.

It assumes Eltoo exists and there are Update transactions that can attach to any previous Update transaction or to the funding transaction, and Settlement transactions, spendable after a CSV, one for each Update transaction.

Instead of explaining more, I'll give some examples.

Examples

In the following super-simplified notation I'll just treat the combination of Update+Settlement as one "state", otherwise this would be a mess.

Consider that Alice and Bob have a channel with a total of 100 BTC. When at rest, their channel state reads as follows:

s1[Alice 50 | Bob 50]

This is the initial state of the channel. `s1` here means the sequence of this Update/Settlement according to odd SIGHASH_NOINPUT CLTV rules which are abstracted away. In the following cases there will be `s2`, `s3` and so on.

Simple case of routed payment

Alice tries to route a payment of 7 BTC through this channel using the hash h1 = H(p1). The previous state is discarded and replaced with the following:

• current design:

  s2[Alice 43 | HTLC(if p1 then Bob else Alice after some time) 7 | Bob 50] -- where p1 is the preimage

  if the payment is fulfilled, Alice gets p1, a new state is created as s3[Alice 43 | Bob 57]; if it's canceled the state is replaced with s3[Alice 50 | Bob 50]; if Bob disappears and the timeout expires Alice closes the channel as s2[43|7 to Alice|50]; if Bob has p1, Alice disappears and the timeout expires Bob closes the channel as s2[43|7 to Bob|50].

• proposed design

  Instead of a single state that includes an HTLC as an output, we have two states that both peers will keep:

  s2[Alice 50 | Bob 50] s3[if p1 then [Alice 43| Bob 57]]

  if the payment is fulfilled, Alice gets p1, a new state is created as s4[Alice 43 | Bob 57]; if it's canceled the state is replaced with s4[Alice 50 | Bob 50]; if Bob disappears and the timeout expires Alice closes the channel as s2[50|50]; if Bob has p1, Alice disappears and the timeout expires Bob closes the channel as s3[43|57]; if Alice closes the channel without talking to Bob, but Bob has p1, he publishes s3 after her publishing s2; if Bob closes the channel without talking to Alice she sees p1 as broadcasted and is fine.

A case with 2 payments in-flight

What happens if besides the payment described above Alice then tries to route a new payment of 20 BTC using h2 = H(p2) while the previous is still pending.

• current design: I'll skip this as it's basically the same thing but with a new HTLC and everybody knows it.

• proposed design:

  Now the parties have to hold 4 transactions:

  s2[Alice 50 | Bob 50] s3[if p1 then [Alice 43 | Bob 57]] s3[if p2 then [Alice 30 | Bob 70]] s4[if p1 and p2 then [Alice 23 | Bob 77]]

  If one of the payments is fulfilled, or none, the scenarios are basically the same as in the previous case; If Alice gets p1 and publishes s3[43|57] without waiting for p2, then later p2 comes, Bob can publish s4[23|77] and don't be harmed; Other scenarios should be similar to the previous case.

A case with one pending payment in each direction

Now imagine that while Alice is routing the first payment of 7 BTC another payment comes in the opposite direction, for 11 BTC using h3 = H(p3).

• current design: I'll skip this as it's basically the same thing but with a new HTLC and everybody knows it.

• proposed design:

  s2[Alice 50 | Bob 50] s3[if p1 then [Alice 43 | Bob 57]] s3[if p3 then [Alice 61 | Bob 39]] s4[if p1 and p3 then [Alice 54 | Bob 46]]

  If one of the payments is fulfilled, or none, the scenarios are basically the same as in the previous cases; If Bob gets p1 and publishes s3[43|57] without waiting for p3, then later p3 comes to Alice, she can publish s4[54|66] and don't be harmed; Other scenarios should be similar to the previous case.

A case with 4 pending payments (you can stop reading now)

Consider now that there are two payments going to one direction and two in the other direction. And now we're going to specify the delay for each payment. The delay means the time for which we'll wait for each to be fulfilled or canceled.

h1: 7 BTC from Alice to Bob -- delay: 10 blocks h2: 20 BTC from Alice to Bob -- delay: 20 blocks h3: 11 BTC from Bob to Alice -- delay: 30 blocks h4: 5 BTC from Bob To Alice -- delay: 40 blocks

Now there are 16 transactions to be stored.
The CSV values are given on the Settlement transaction of each of these states, such that Settlements with higher sequence numbers have always time to be published.
Since the next payment expiring is the first, which will expire in 10 blocks, this entire "batch of states" have only that time to live. If it doesn't get updated with the fulfillment and/or cancellation of at least one of the pending payments and thus rewritten then the channel must be closed, probably with s2[50|50], to prevent loss of funds.

s2[Alice 50 | Bob 50] -- CSV 50
s3[if `p1` then [Alice 43 | Bob 57]] -- CSV: 40
s3[if `p2` then [Alice 30 | Bob 70]] -- CSV: 40
s3[if `p3` then [Alice 61 | Bob 39]] -- CSV: 40
s3[if `p4` then [Alice 65 | Bob 55]] -- CSV: 40
s4[if `p1` and `p2` then [Alice 23 | Bob 77]] -- CSV: 30
s4[if `p1` and `p3` then [Alice 54 | Bob 46]] -- CSV: 30
s4[if `p1` and `p4` then [Alice 48 | Bob 52]] -- CSV: 30
s4[if `p2` and `p3` then [Alice 41 | Bob 59]] -- CSV: 30
s4[if `p2` and `p4` then [Alice 35 | Bob 65]] -- CSV: 30
s4[if `p3` and `p4` then [Alice 66 | Bob 44]] -- CSV: 30
s5[if `p1` and `p2` and `p3` then [Alice 34 | Bob 66]] -- CSV: 20
s5[if `p1` and `p2` and `p4` then [Alice 28 | Bob 72]] -- CSV: 20
s5[if `p1` and `p3` and `p4` then [Alice 59 | Bob 41]] -- CSV: 20
s5[if `p2` and `p3` and `p4` then [Alice 46 | Bob 54]] -- CSV: 20
s6[if `p1` and `p2` and `p3` and `p4` then [Alice 39 | Bob 61]] -- CSV: 10

As in the previous cases, if at any time one peer tries to publish any of the Updates without waiting for remaining payments to be either canceled or fulfilled, the other peer can just wait for the missing preimage to arrive, gather the preimages they already know or which were broadcasted with the transaction and fulfill an Update that is higher in its sequence number.

Comments

Advantages:

• Any payment, no matter how small, is taken into account in the balance, no more trustfulness
• My understanding is quite poor, but I feel it's simpler than the current channels and even simpler than Eltoo channels.

Drawbacks:

• The number of needed stored transactions is 2^n for n payments in-flight.
• Big scripts in Settlement transactions that check many hashes are terrible if they ever have to be published. Is it possible to turn them into a single adaptor-signature-magic scriptless script? I hope it is, but have no idea.

It was a cold day and I remembered that this lightningd node I was running on my local desktop to work on poncho actually had mainnet channels in it. Two channels, both private, bought on https://lnbig.com/ a while ago when I was trying to conduct an anonymous griefing attack on big nodes of the network just to prove it was possible (the attempts proved unsuccessful after some hours and I gave up).

It is always painful to close channels because paying fees hurts me psychologically, and then it hurts even more to be left with a new small UTXO that will had to be spent to somewhere but that can barely pay for itself, but it also didn't make sense to just leave the channels there and risk forgetting them and losing them forever, so I had to do something.

One of the channels had 0 satoshis on my side, so that was easy. Mutually closed and I don't have to think anymore about it.

The other one had 10145 satoshis on my side -- out of a total of 100000 satoshis. Why can't I take my part all over over Lightning and leave the full channel UTXO to LNBIG? I wish I could do that, I don't want a small UTXO. I was not sure about it, but if the penalty reserve was 1% maybe I could take out abou 9000 satoshis and then close it with 1000 on my side? But then what would I do with this 1000 sat UTXO that would remain? Can't I donate it to miners or something?

I was in the middle of this thoughts stream when it came to me the idea of causing a penalty transaction to give those abundant 1000 sat to Mr. LNBIG as a donation for his excellent services to the network and the cause of Bitcoin, and for having supported the development of https://sbw.app/ and the hosted channels protocol.

Unfortunately lightningd doesn't have a command triggerpenaltytransaction or trytostealusingoldstate, so what I did was:

First I stopped lightningd then copied the database to elsewhere:

cp ~/.lightningd/bitcoin/lightningd.sqlite3 ~/.lightning/bitcoin/lightningd.sqlite3.bak

then I restarted lightningd and fighted against the way-too-aggressive MPP splitting algorithm the pay command uses to pay invoices, but finally managed to pull about 9000 satoshis to my Z Bot that lives on the terrible (but still infinitely better than Twitter DMs) "webk" flavor of the Telegram web application and which is linked to my against-bitcoin-ethos-country-censoring ZEBEDEE Wallet. The operation wasn't smooth but it didn't take more than 10 invoices and pay commands.

With the money out and safe elsewhere, I stopped the node again, moved the database back with a reckless

mv ~/.lightning/bitcoin/lightningd.sqlite3.bak ~/.lightningd/bitcoin/lightningd.sqlite3

and restarted it, but to prevent my lightningd from being super naïve and telling LNBIG that it had an old state (I don't know if this would happen) which would cause LNBIG to close the channel in a boring way, I used the --offline flag which apparently causes the node to not do any external connections.

Finally I checked my balance using lightning-cli listfunds and there it was, again, the 10145 satoshis I had at the start! A fantastic money creation trick, comparable to the ones central banks execute daily.

I was ready to close the channel now, but the lightning-cli close command had an option for specifying how many seconds I would wait for a mutual close before proceeding to a unilateral close. There is no forceclose command like Éclair hasor anything like that. I was afraid that even if I gave LNBIG one second it would try to do boring things, so I paused to consider how could I just broadcast the commitment transaction manually, looked inside the SQLite database and the channels table with its millions of columns with cryptic names in the unbearable .schema output, imagined that lightningd maybe wouldn't know how to proceed to take the money from the to-local output if I managed to broadcast it manually (and in the unlikely event that LNBIG wouldn't broadcast the penalty transaction), so I decided to just accept the risk and call

lightning-cli close 706327x1588x0 1

But it went well. The --offline flag apparently really works, as it just considered LNBIG to be offline and 1 second later I got the desired result.

My happiness was complete when I saw the commitment transaction with my output for 10145 satoshis published on the central database of Bitcoin, blockstream.info.

Then I went to eat something and it seems LNBIG wasn't offline or sleeping, he was certainly looking at all the logs from his 274 nodes in a big room full of monitors, very alert and eating an apple while drinking coffee, ready to take action, for when I came back, minutes later, I could see it, again on the single source of truth for the Bitcoin blockchain, the Blockstream explorer. I've refreshed the page and there it was, a small blue link right inside the little box that showed my to-local output, a notice saying it had been spent -- not by my lightningd since that would have to wait 9000 blocks, but by the same transaction that spent the other output, from which I could be very sure it was it, the glorious, mighty, unforgiving penalty transaction, splitting the earth, showing itself in all its power, and taking my 10145 satoshis to their rightful owner.

A common misconception of technologists when they first discover Nostr is to put too much weight on the cryptography and start worshipping the keypairs.

Secret keys are just numbers. To some people this will sound amazing, but in fact it is just a little boring. Numbers by themselves don't do anything. A simple computer script can generate a bazillion keys with no effort at all: but does that have any effect in the world? No.

The key-focused approach to Nostr is responsible for well-known slogans such as "not your keys, not your notes" or "self-sovereign identity". But these are meaningless slogans, and not only because people are not keys, but because these keys don't do anything without the means of actual action in the world.

Is a person locked in a cage "free"? If you use the key-worshipper logic then yes. That locked person is the only one who can move their own body or think their own thoughts, in the same sense that a person with a secret key is the only one who can sign things using that key (obviously). Both are "self-sovereign", blablabla.

The point is that "sovereignty" (what an unfortunate word) is meaningless if the person cannot leave the cage and do more interesting things in the world. In the same sense having a key is meaningless if you cannot publish messages to where the people you're trying to reach can read them.

Ethereum and other "smart contract platforms" capable of running turing-complete code and "developer-friendly" mindset and community have been running for years and they were able to produce a very low number of potentially useful "contracts".

What are these contracts, actually? (Considering Ethereum, but others are similar:) they are sidechains that run inside the Ethereum blockchain (and thus their verification and data storage are forced upon all Ethereum nodes). Users can peg-in to a contract by depositing money on it and peg-out by making a contract operation that sends money to a normal Ethereum address.

Now be generous and imagine these platforms are able to produce 3 really cool, useful ideas (out of many thousands of attempts): Bitcoin can copy these, turn them into 3 different sidechains, each running fixed, specific, optimized code. Bitcoin users can now opt to use these platforms by transferring coins to it – all that without damaging the nodes or the consensus protocol that has been running for years, and without forcing anyone to be aware of these chains.

The process of turning a useful idea into a sidechain doesn't come spontaneously, and can't be done by a single company (like often happens in Ethereum-land), it must be acknowledge by a rough consensus in the Bitcoin community that that specific sidechain with that specific design is a desirable thing, and ultimately approved by miners, as they're the ones that are going to be in charge of that.

2013

• tempreites

2014

• contratos.alhur.es
• microanalytics
• doulas.club
• rosetta.alhur.es
• Webvatar

2015

• Gerador de tabelas de todos contra todos
• questo.email
• jekmentions
• Websites For Trello
• Temperos
• Trello Attachment Editor
• WelcomeBot
• Classless Templates

2016

• Module Linker
• Boardthreads
• Batch for Trello
• Custom spreadsheets
• SummaDB
• Flowi.es
• Trelew
• Washer
• hyperscript-go
• jiq
• busca múltipla na estante virtual
• Splitpages
• requesthub.xyz

2017

• trackingco.de
• jq-web
• Filemap
• IPFS-dropzone
• sitio
• rel

2018

• ijq
• sitios.xyz
• hledger-web
• LessPass remoteStorage
• TiddlyWiki remoteStorage
• fieldbook-to-sql
• jq-finder
• jiq-web
• superform.xyz
• piln
• gravity
• howoldis
• litepub

2019

• Etleneum
• @lntxbot
• mcldsp
• Sparko

2020

• lnchannels
• trustedcoin
• localchat

Não li todas as reclamações que o Olavo fez, mas li algumas. Também não li toda a matéria que saiu na Época, porque não tive paciência, mas assisti aos dois vídeos da entrevista que o Olavo publicou.

Tendo lido primeiro as muitas reclamações do Olavo, esperei encontrar no vídeo uma pessoa falsa, que fingiu-se de amigável para obter informações que usaria depois para destruir a imagem do Olavo, mas não vi nada disso.

Claro que ela poderia ter me enganado também, se enganou ao Olavo. Mas na matéria em si, também não vi nada além de sinceridade -- talvez não excelência jornalística, mas nada que eu não esperasse de qualquer matéria de qualquer revista. Flavia Tavares não entendeu muitas coisas, mas não fingiu que não entendeu nada, foi simples e honestamente Flavia Tavares, como ela mesma declarou no final do vídeo da entrevista: "olha, eu não fingi nada aqui, viu?".

O mais importante de tudo isso, porém, são as partes da matéria que apresentam idéias difíceis de conceber, como as que Olavo tem sobre o governo mundial ou a disseminação da pedofilia. Em toda discussão pública ou privada, essas idéias são proibidas. Muita gente pode concordar que a esquerda não presta, mas ninguém em sã consciência admitirá a possibilidade de que haja qualquer intenção significativa de implantação de um governo mundial ou da disseminação da pedofilia. A mesma carinha de deboche que seu amigo esquerdista faria à simples menção desses assuntos é a que Flavia Tavares usa no seu texto quando quer mostrar que Olavo é meio tantã. A carinha de deboche vem desacompanhada de qualquer reflexão séria ou tentativa de refutação, sempre.

Link da tal matéria: http://epoca.globo.com/sociedade/noticia/2017/10/olavo-de-carvalho-o-guru-da-direita-que-rejeita-o-que-dizem-seus-fas.html?utm_source=twitter&utm_medium=social&utm_campaign=post Vídeos: https://www.youtube.com/watch?v=C0TUsKluhok, https://www.youtube.com/watch?v=yR0F1haQ07Y&t=5s

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.

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.

Before XRP, the shitcoin, bought it, "Ripple" was used by Ryan Fugger as the name for his project to create a peer-to-peer network of trust channels for money transfer. The basic idea is that Alice trusts Bob personally, Bob trusts Carol personally and Carol trusts David personally, therefore it is possible for Alice to send a payment to David by creating debt across A--B, B--C and C--D. Later either payments in the opposite direction (not necessarily from David to Alice, as the network can have trust relationships to multiple other peers in a complex graph) would maybe clear that debt (or not), but ultimately Bob would expect Alice to pay him in kind to settle the debt, Carol would expect Bob to pay her in kind and David would expect Carol to pay him in kind.

The system above works quite well inside a centralized trusted platform like Fugger's own Ripplepay website (even when it was supposed to be just proof-of-concept, it ended up being actually used to facilitate payments across small communities), but that cannot scale as participants would all rely on it and ultimately have to blindly trust that platform.¹

If a truly peer-to-peer system could be designed, it would have a chance of scaling across the entire society and the ability to enable truly open payments over the internet, an unreachable goal unless you use either a credit card provider, which is bureaucratic, unsafe, expensive, taxable, not private at all and cumbersome -- or Bitcoin, which is awesome and excel in all aspects except scalability for day-to-day transactions.

The protocol can take many forms, but essentially it goes like this: 1. A finds a route (A--B--C--D) between her and D somehow; 2. A "prepares" a payment to B, tells B to do the same with C and so on (to prepare means to give B a conditional IOU that will be valid as long as the full payment completes); 3. When the chain of prepared messages reaches D, D somehow "commits" the payment. 4. After the commit, A now really does owe B and so on, and D really knows it has been effectively paid by A (in the form of debt from C) so it can ship goods to A.

The step 3 is the point in which the problem of the decentralized commit arises.

Fugger and the original Ripple community failed to solve the problem of the decentralized commit, which is required for such a system to be deployed. Not to blame them, as they've recognized the problem (unlike other people that had the same idea later²) and documented many sub-optimal solutions³.

No one thinks about it in these terms, but the Bitcoin Lightning Network is itself a Ripple-like system with an embedded solution to the problem of the decentralized commit.

ZK rollups make no sense in bitcoin because there is no "cheap calldata". all data is already ~~cheap~~ expensive calldata.

There could be an onchain zk verification that allows succinct signatures maybe, but never a rollup.

What happens is: you can have one UTXO that contains multiple balances on it and in each transaction you can recreate that UTXOs but alter its state using a zk to compress all internal transactions that took place.

The blockchain must be aware of all these new things, so it is in no way "L2".

And you must have an entity responsible for that UTXO and for conjuring the state changes and zk proofs.

But on bitcoin you also must keep the data necessary to rebuild the proofs somewhere else, I'm not sure how can the third party responsible for that UTXO ensure that happens.

I think such a construct is similar to a credit card corporation: one central party upon which everybody depends, zero interoperability with external entities, every vendor must have an account on each credit card company to be able to charge customers, therefore it is not clear that such a thing is more desirable than solutions that are truly open and interoperable like Lightning, which may have its defects but at least fosters a much better environment, bringing together different conflicting parties, custodians, anyone.

There are many ideas for "covenants" (I don't think this concept helps in the specific case of examining proposals, but fine). Some people think "we" (it's not obvious who is included in this group) should somehow examine them and come up with the perfect synthesis.

It is not clear what form this magic gathering of ideas will take and who (or which ideas) will be allowed to speak, but suppose it happens and there is intense research and conversations and people (ideas) really enjoy themselves in the process.

What are we left with at the end? Someone has to actually commit the time and put the effort and come up with a concrete proposal to be implemented on Bitcoin, and whatever the result is it will have trade-offs. Some great features will not make into this proposal, others will make in a worsened form, and some will be contemplated very nicely, there will be some extra costs related to maintenance or code complexity that will have to be taken. Someone, a concreate person, will decide upon these things using their own personal preferences and biases, and many people will not be pleased with their choices.

That has already happened. Jeremy Rubin has already conjured all the covenant ideas in a magic gathering that lasted more than 3 years and came up with a synthesis that has the best trade-offs he could find. CTV is the result of that operation.

The fate of CTV in the popular opinion illustrated by the thoughtless responses it has evoked such as "can we do better?" and "we need more review and research and more consideration of other ideas for covenants" is a preview of what would probably happen if these suggestions were followed again and someone spent the next 3 years again considering ideas, talking to other researchers and came up with a new synthesis. Again, that person would be faced with "can we do better?" responses from people that were not happy enough with the choices.

And unless some famous Bitcoin Core or retired Bitcoin Core developers were personally attracted by this synthesis then they would take some time to review and give their blessing to this new synthesis.

To summarize the argument of this article, the actual question in the current CTV drama is that there exists hidden criteria for proposals to be accepted by the general community into Bitcoin, and no one has these criteria clear in their minds. It is not as simple not as straightforward as "do research" nor it is as humanly impossible as "get consensus", it has a much bigger social element into it, but I also do not know what is the exact form of these hidden criteria.

This is said not to blame anyone -- except the ignorant people who are not aware of the existence of these things and just keep repeating completely false and unhelpful advice for Jeremy Rubin and are not self-conscious enough to ever realize what they're doing.

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

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

Fediverse

First of all we have Mastodon (I often call it by this name because Mastodon is the de facto controller of the protocol), but a better name would be the Fediverse, which is ugly, but still better than ActivityPub, since "Activity" depicts a much broader protocol, conceived by the minds of unreasonable academics, unimplementable in nature, which was only partly adopted by Mastodon.

Anyway, it is very straightforward: clients talk to a single server, that server talks to other servers.

Nostr

Well, Nostr has been described elsewhere many other times, but its core new idea is that clients can talk to multiple servers, which gives us a very chaotic ecosystem of signed messages.

ATProto

Finally we have Bluesky, or, if we go by the name of the overall protocol, ATProto. Its core new idea is that the basic functions of a social networking server can be broken up in mainly 3 different kinds of servers, which then talk to each other in a pipeline.

What if instead of trying to create complicated "layer 2" setups involving noveau cryptographic techniques we just did the following:

• we take that Fedimint source code and remove the "mint" stuff, and just use their federation stuff secure coins with multisig;
• then we make a spacechain;
• and we make the federations issue multisig-btc tokens on it;
• and then we put some uniswap-like thing in there to allow these tokens to be exchanged freely.

Why?

The recent spike in fees caused by Ordinals and BRC-20 shitcoinery has shown that Lightning isn't a silver bullet. Channels are too fragile, it costs a lot to open a channel under a high fee environment, to run a routing node and so on.

People who want to keep using Lightning are instead flocking to the big Lightning custodial providers: WalletofSatoshi, ZEBEDEE, OpenNode and so on. We could leverage that trust people have in these companies (and individuals) operating shadow Lightning providers and turn each of these into a btc-token issuer. Each issue their own token, transactions flow freely. Each person can hold only assets from the issuers they trust more.

I mean this article: https://achimwarner.medium.com/thoughts-on-drivechain-i-miners-can-do-things-about-which-we-will-argue-whether-it-is-actually-a5c3c022dbd2

There are basically two claims here:

1. Some corporate interests might want to secure sidechains for themselves and thus they will bribe miners to have these activated

First, it's hard to imagine why they would want such a thing. Are they going to make a proprietary KYC chain only for their users? They could do that in a corporate way, or with a federation, like Facebook tried to do, and that would provide more value to their users than a cumbersome pseudo-decentralized system in which they don't even have powers to issue currency. Also, if Facebook couldn't get away with their federated shitcoin because the government was mad, what says the government won't be mad with a sidechain? And finally, why would Facebook want to give custody of their proprietary closed-garden Bitcoin-backed ecosystem coins to a random, open and always-changing set of miners?

But even if they do succeed in making their sidechain and it is very popular such that it pays miners fees and people love it. Well, then why not? Let them have it. It's not going to hurt anyone more than a proprietary shitcoin would anyway. If Facebook really wants a closed ecosystem backed by Bitcoin that probably means we are winning big.

2. Miners will be required to vote on the validity of debatable things

He cites the example of a PoS sidechain, an assassination market, a sidechain full of nazists, a sidechain deemed illegal by the US government and so on.

There is a simple solution to all of this: just kill these sidechains. Either miners can take the money from these to themselves, or they can just refuse to engage and freeze the coins there forever, or they can even give the coins to governments, if they want. It is an entirely good thing that evil sidechains or sidechains that use horrible technology that doesn't even let us know who owns each coin get annihilated. And it was the responsibility of people who put money in there to evaluate beforehand and know that PoS is not deterministic, for example.

About government censoring and wanting to steal money, or criminals using sidechains, I think the argument is very weak because these same things can happen today and may even be happening already: i.e., governments ordering mining pools to not mine such and such transactions from such and such people, or forcing them to reorg to steal money from criminals and whatnot. All this is expected to happen in normal Bitcoin. But both in normal Bitcoin and in Drivechain decentralization fixes that problem by making it so governments cannot catch all miners required to control the chain like that -- and in fact fixing that problem is the only reason we need decentralization.

HTLCs below the dust limit are not possible, because they're uneconomical.

So currently whenever a payment below the dust limit is to be made Lightning peers adjust their commitment transactions to pay that amount as fees in case the channel is closed. That's a form of reserving that amount and incentivizing peers to resolve the payment, either successfully (in case it goes to the receiving node's balance) or not (it then goes back to the sender's balance).

SOLUTION

I didn't think too much about if it is possible to do what I think can be done in the current implementation on Lightning channels, but in the context of Eltoo it seems possible.

Eltoo channels have UPDATE transactions that can be published to the blockchain and SETTLEMENT transactions that spend them (after a relative time) to each peer. The barebones script for UPDATE transactions is something like (copied from the paper, because I don't understand these things):

OP_IF
  # to spend from a settlement transaction (presigned)
  10 OP_CSV
  2 As,i Bs,i 2 OP_CHECKMULTISIGVERIFY
OP_ELSE
  # to spend from a future update transaction
  <Si+1> OP_CHECKLOCKTIMEVERIFY
  2 Au Bu 2 OP_CHECKMULTISIGVERIFY
OP_ENDIF

During a payment of 1 satoshi it could be updated to something like (I'll probably get this thing completely wrong):

OP_HASH256 <payment_hash> OP_EQUAL
OP_IF
    # for B to spend from settlement transaction 1 in case the payment went through
    # and they have a preimage
    10 OP_CSV
    2 As,i1 Bs,i1 2 OP_CHECKMULTISIGVERIFY
OP_ELSE
  OP_IF
    # for A to spend from settlement transaction 2 in case the payment didn't went through
    # and the other peer is uncooperative
    <now + 1day> OP_CHECKLOCKTIMEVERIFY
    2 As,i2 Bs,i2 2 OP_CHECKMULTISIGVERIFY
  OP_ELSE
    # to spend from a future update transaction
    <Si+1> OP_CHECKLOCKTIMEVERIFY
    2 Au Bu 2 OP_CHECKMULTISIGVERIFY
  OP_ENDIF
OP_ENDIF

Then peers would have two presigned SETTLEMENT transactions, 1 and 2 (with different signature pairs, as badly shown in the script). On SETTLEMENT 1, funds are, say, 999sat for A and 1001sat for B, while on SETTLEMENT 2 funds are 1000sat for A and 1000sat for B.

As soon as B gets the preimage from the next peer in the route it can give it to A and them can sign a new UPDATE transaction that replaces the above gimmick with something simpler without hashes involved.

If the preimage doesn't come in viable time, peers can agree to make a new UPDATE transaction anyway. Otherwise A will have to close the channel, which may be bad, but B wasn't a good peer anyway.

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.

A full catalog of all Brazilian doulas with data carefully scrapped from many websites that contained partial catalogs and some data manually included. All this packaged as a Couchapp and served directly from Cloudant.

This was done because the idea of doulas was good, but I spotted an issue: pregnant womwn should know many doulas before choosing one that would match well, therefore a full catalog with a lot of information was necessary.

This was a huge amount of work mostly wasted.

Many doulas who knew about this didn't like it and sent angry and offensive emails telling me to remove them. This was information one should know before choosing a doula.

See also

• About CouchDB

You may have seen the lnurl-auth spec or heard about it, but might not know how it works or what is its relationship with other lnurl protocols. This document attempts to solve that.

Relationship between lnurl-auth and other lnurl protocols

First, what is the relationship of lnurl-auth with other lnurl protocols? The answer is none, except the fact that they all share the lnurl format for specifying https URLs.

In fact, lnurl-auth is very unique in the sense that it doesn't even need a Lightning wallet to work, it is a standalone authentication protocol that can work anywhere.

How does it work

Now, how does it work? The basic idea is that each wallet has a seed, which is a random value (you may think of the BIP39 seed words, for example). Usually from that seed different keys are derived, each of these yielding a Bitcoin address, and also from that same seed may come the keys used to generate and manage Lightning channels.

What lnurl-auth does is to generate a new key from that seed, and from that a new key for each service (identified by its domain) you try to authenticate with.

That way, you effectively have a new identity for each website. Two different services cannot associate your identities.

The flow goes like this: When you visit a website, the website presents you with a QR code containing a callback URL and a challenge. The challenge should be a random value.

When your wallet scans or opens that QR code it uses the domain in the callback URL plus the main lnurl-auth key to derive a key specific for that website, uses that key to sign the challenge and then sends both the public key specific for that for that website plus the signed challenge to the specified URL.

When the service receives the public key it checks it against the challenge signature and start a session for that user. The user is then identified only by its public key. If the service wants it can, of course, request more details from the user, associate it with an internal id or username, it is free to do anything. lnurl-auth's goals end here: no passwords, maximum possible privacy.

FAQ

• What is the advantage of tying this to Bitcoin and Lightning?

  One big advantage is that your wallet is already keeping track of one seed, it is already a precious thing. If you had to keep track of a separate auth seed it would be arguably worse, more difficult to bootstrap the protocol, and arguably one of the reasons similar protocols, past and present, weren't successful.

• Just signing in to websites? What else is this good for?

  No, it can be used for authenticating to installable apps and physical places, as long as there is a service running an HTTP server somewhere to read the signature sent from the wallet. But yes, signing in to websites is the main problem to solve here.

• Phishing attack! Can a malicious website proxy the QR from a third website and show it to the user to it will steal the signature and be able to login on the third website?

  No, because the wallet will only talk to the the callback URL, and it will either be controlled by the third website, so the malicious won't see anything; or it will have a different domain, so the wallet will derive a different key and frustrate the malicious website's plan.

• I heard SQRL had that same idea and it went nowhere.

  Indeed. SQRL in its first version was basically the same thing as lnurl-auth, with one big difference: it was vulnerable to phishing attacks (see above). That was basically the only criticism it got everywhere, so the protocol creators decided to solve that by introducing complexity to the protocol. While they were at it they decided to add more complexity for managing accounts and so many more crap that in the the spec which initially was a single page ended up becoming 136 pages of highly technical gibberish. Then all the initial network effect it had, libraries and apps were trashed and nowadays no one can do anything with it (but, see, there are still people who love the protocol writing in a 90's forum with no clue of anything besides their own Java).

• We don't need this, we need WebAuthn!

  WebAuthn is essentially the same thing as lnurl-auth, but instead of being simple it is complex, instead of being open and decentralized it is centralized in big corporations, and instead of relying on a key generated by your own device it requires an expensive hardware HSM you must buy and trust the manufacturer. If you like WebAuthn and you like Bitcoin you should like lnurl-auth much more.

• What about BitID?

  This is another one that is very similar to lnurl-auth, but without the anti-phishing prevention and extra privacy given by making one different key for each service.

• What about LSAT?

  It doesn't compete with lnurl-auth. LSAT, as far as I understand it, is for when you're buying individual resources from a server, not authenticating as a user. Of course, LSAT can be repurposed as a general authentication tool, but then it will lack features that lnurl-auth has, like the property of having keys generated independently by the user from a common seed and a standard way of passing authentication info from one medium to another (like signing in to a website at the desktop from the mobile phone, for example).

Depois de quatro anos e meio sem usar xampu, e com o cabelo razoavelmente grande, dá pra perceber a enorme diferença entre não passar nada e passar L'Oréal Elsève, ou entre passar este e Seda Ceramidas Cocriações.

A diferença mais notável no primeiro caso é a de que o cabelo deixa de ter uma oleosidade natural que mantém os cachos juntos e passa a ser só uma massa amorfa de fios secos desgrenhados, um jamais tocando o outro. No segundo caso os cabelos não mais não se tocam, mas mantém-se embaraçados. Passar o condicionador para "hidratar" faz com que o cabelo fique pesado e mole, caindo para os lados.

Além do fato de que os xampus vêm sempre com as mesmas recomendações no verso ("para melhores resultados, utilize nossa linha completa"), o mais estranho é que as pessoas fazem juízos sobre os cabelos serem "secos" ou "oleosos" sendo que elas jamais os viram em um estado "natural" ou pelo menos mais próximo do natural, pelo contrário, estão sempre aplicando sobre eles um fluido secador, o xampu, e depois um fluido molhador, o condicionador, e cada um deles podendo ter efeitos diferentes sobre cada cabelo, o que deveria invalidar total e cabalmente todo juízo sobre oleosidade.

Por outro lado, embora existam, aqui e ali, discussões sobre a qualidade dos xampus e sobre qual é mais adequado a cada cabelo (embora, como deve ter ficado claro no parágrafo acima, estas discussões são totalmente desprovidas de qualquer base na realidade), não se discute a qualidade da água. A água que cada pessoa usa em seu banho deve ter um influência no mínimo igual à do xampu (ou não-xampu).

No final das contas, as pessoas passam a vida inteira usando o xampu errado, sem saber o que estão fazendo, chegando a conclusões baseadas em nada sobre os próprios cabelos e o dos outros, sem considerar os dados corretos -- aliás, sem nem cogitar que pode existir algum dado além da percepção mais imediata e o feeling de cabelereiro de cada um --, ou então trocando de xampu a cada vez que o cabelo fica de um jeito diferente, fooled by randomness.

For the millionth time I read somewhere that "custodial bitcoin is not bitcoin" and that "if you're going to use custodial, better use Paypal". No, actually it was "better use Coinbase", but I had heard the "PayPal" version in the past.

There are many reasons why using PayPal is not the same as using a custodial Bitcoin service or wallet that are obvious and not relevant here, such as the fact that you can't have Bitcoin balances on Bitcoin (or maybe now you can? but you can't send it around); plus all the reasons that are also valid for Coinbase such as you having to give all your data and selfies of yourself and your government documents and so on -- but let's ignore these reasons for now.

The most important reason why it isn't the same thing is that when you're using Coinbase you are stuck in Coinbase. Your Coinbase coins cannot be used to pay anyone that isn't in Coinbase. So Coinbase-style custodianship doesn't help Bitcoin. If you want to move out of Coinbase you have to withdraw from Coinbase.

Custodianship on Lightning is of a very different nature. You can pay people from other custodial platforms and people that are hosting their own Lightning nodes and so on.

That kind of custodianship doesn't do any harm to anyone, doesn't fracture the network, doesn't reduce the network effect of Lightning, in fact it increases it.

This was a service that took webmentions, an "indiewebcamp" thing and turned them into notes on a special directory of a GitHub repo so they would be turned into rendered comments on a GitHub website rendered by the default Jekyll generator.

I ran a server for some time and there were some 2 or 3 people using it besides me.

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

Just a bunch of somewhat-related notes.

• notes on "Economic Action Beyond the Extent of the Market", Per Bylund
• Mises' interest rate theory
• Profits, not wages, as the originary factor
• Reisman on opportunity cost
• Money Supply Measurement
• Per Bylund's insight
• Maybe a new approach to the Austrian Business Cycle Theory, some disorganized thoughts
• An argument according to which fractional-reserve banking is merely theft and nothing else
• Conjecture and criticism
• Qual é o economista? (piadas)
• UBI calculations
• Donations on the internet

We want merged-mined blockchains. We want them because it is possible to do things in them that aren't doable in the normal Bitcoin blockchain because it is rightfully too expensive, but there are other things beside the world money that could benefit from a "distributed ledger" -- just like people believed in 2013 --, like issued assets and domain names (just the most obvious examples).

On the other hand we can't have -- like people believed in 2013 -- a copy of Bitcoin for every little idea with its own native token that is mined by proof-of-work and must get off the ground from being completely valueless into having some value by way of a miracle that operated only once with Bitcoin.

It's also not a good idea to have blockchains with custom merged-mining protocol (like Namecoin and Rootstock) that require Bitcoin miners to run their software and be an active participant and miner for that other network besides Bitcoin, because it's too cumbersome for everybody.

Luckily Ruben Somsen invented this protocol for blind merged-mining that solves the issue above. Although it doesn't solve the fact that each parallel chain still needs some form of "native" token to pay miners -- or it must use another method that doesn't use a native token, such as trusted payments outside the chain.

How does it work

With the SIGHASH_NOINPUT/SIGHASH_ANYPREVOUT soft-fork¹ it becomes possible to create presigned transactions that aren't related to any previous UTXO.

Then you create a long sequence of transactions (sufficient to last for many many years), each with an nLockTime of 1 and each spending the next (you create them from the last to the first). Since their scriptSig (the unlocking script) will use SIGHASH_ANYPREVOUT you can obtain a transaction id/hash that doesn't include the previous TXO, you can, for example, in a sequence of transactions A0-->B (B spends output 0 from A), include the signature for "spending A0 on B" inside the scriptPubKey (the locking script) of "A0".

With the contraption described above it is possible to make that long string of transactions everybody will know (and know how to generate) but each transaction can only be spent by the next previously decided transaction, no matter what anyone does, and there always must be at least one block of difference between them.

Then you combine it with RBF, SIGHASH_SINGLE and SIGHASH_ANYONECANPAY so parallel chain miners can add inputs and outputs to be able to compete on fees by including their own outputs and getting change back while at the same time writing a hash of the parallel block in the change output and you get everything working perfectly: everybody trying to spend the same output from the long string, each with a different parallel block hash, only the highest bidder will get the transaction included on the Bitcoin chain and thus only one parallel block will be mined.

See also

• Drivechain

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

Piln was a prepaid IPFS pinning service you could use anonymously and instantaneously with the Bitcoin payments over the Lightning Network.

Similar to https://eternum.io/, but anonymous, loginless and very very cheap. The cheapness wouldn't scale because it needed a local HD to store data, couldn't work with services like S3 because IPFS is very bad (I actually tried to make it work).

Discontinued because IPFS is terrible.

• https://piln.xyz/
• https://github.com/fiatjaf/piln

See also

• How IPFS is broken

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.

People are used to saying and thinking that blockchains provide immutable data storage. Then many times they add a caveat that says blockchains are very expensive, so we can't really store too much data on them, but we can still store some data if we really want and are ok with paying for it.

But the fact is that blockchains cannot ever be used to store anything. The purpose of blockchains is to keep track of some state that everybody must agree upon at all times, and arbitrary data that anyone may have wanted to backup there is not relevant to anyone else¹ and thus there are no incentives for anyone else to keep track of that. In other words: if you backup your personal pictures as OP_RETURN outputs on Bitcoin, people may delete that and your backup will be void².

Another thing blockchains supposedly do is to "broadcast" something. For example, nodes may delete the OP_RETURN outputs, but at least they have to verify these first, and spread they over the network, so you can broadcast your data and be sure everybody will get it. About this we can say two things: 1, if this happens, it's not a property of blockchains, but of the Bitcoin transaction sharing network that operates outside of the blockchain. 2, if you try to use that network for purposes that are irrelevant for the functioning of the Bitcoin protocol there is no incentive for other nodes to cooperate and they may ignore you.

The above points may sound weird and you may be prompted to answer: but you can do all that today and there is no actual mechanism to stop anyone from broadcasting irrelevant crap!, and that is true. My point here is only that if you're thinking about blockchains as being this data-broadcast-storage mechanism you're thinking about them wrong, that is not an essential part of any blockchain. In other words: the incentives are not aligned for blockchains to be used like that (unless you come up with a scheme that makes data from everyone else to be relevant to everybody), in the long term such things are not expected to work and insisting on doing them will result in either your application or protocol that stores data on the blockchain to crash or in the death of the given blockchain (I hope Bitcoin haters don't read this).

(This is a counterpoint to myself on idea: Rumple, which was a protocol idea that relied on a blockchain storing irrelevant data.)

Better - Faster page loads - Displays <table>s better by default - Using the same browser on multiple places actually makes your experience better, because you can list and send tabs from one device to another - Firefox for Android is vastly superior: - It is much faster - It allows you to install browser extensions, which means you get to use uBlock Origin on Android - It allows you to send and receive tabs from the desktop - It has a built-in QR code scanner - Telegram notifications actually work - I'm not forced to see the neverending super-animated left-inclined special Google Doodles on my new tab page

Basically the same thing - JavaScript speed - Overall stability - JavaScript new features support - All major browser extensions seem to be available for both platforms (although I'm not a huge extensions user so I don't know)

Worse - Chrome has that nice OpenSearch support that allows you to type the beggining of a site's URL, hit tab and then perform a search query on that site if it supports OpenSearch (Firefox has OpenSearch support, but it works differently, in I way that feels odd to me) - Developer tools are much slower, so I use Chromium for debugging JavaScript apps and nothing more - CodeMirror doesn't allow me to paste using the middle-click on Linux, while in Chrome it does, who knows why? There's an issue open on GitHub, but no solution for the near future (I'm forced to call xsel -p -o | xsel -b before pasting stuff from the terminal)

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.

Recebi um email assim, dizendo a mesma coisa repetida. Eu havia recebido já da primeira vez, mas como era só uma informação já esperada, julguei que não precisava responder dizendo "chegou, obrigado!" e não o fiz.

Reconheço, porém, que dada a instabilidade desses serviços de email nunca ninguém sabe se a mensagem chegou ou não. Ela pode ter sido jogada na lixeira do spam, ou pode ter falhado por outros motivos, e aí não existe um jeito garantido de saber se houve falha, é um enorme problema sempre. Por isso a necessidade de uma resposta "chegou, obrigado!".

Mas não podemos parar por aí. A resposta "chegou, obrigado!" também está sujeita aos mesmos trâmites e riscos da mensagem original. Seria necessário, porém, que assim que a outra pessoa recebesse o "chegou, obrigado!" deveria então responder com um "recebi a sua confirmação". Caso não o fizesse, eu poderia achar que a minha mensagem não havia chegado e dias depois enviá-la de novo: "como não houve resposta à minha confirmação, estou enviando de novo".

E assim por diante (eu ia escrever mais um parágrafo só pelo drama, mas desisti. Já deu pra entender).

• Ripple and the problem of the decentralized commit, esta situação que acabo de viver é mais um exemplo prático disto.

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

A static site generator that works with imperative code instead of declarative templates and directory structures. It assumes nothing and can be used to transform anything into HTML pages.

It uses React so it can be used to generate single-page apps too if you want -- and normal sites that work like single-page apps.

It also provides helpers for reading Markdown files, like all static site generator does.

A long time after creating this and breaking it while trying to add too many features at once I realized Gatsby also had an imperative engine underlying the default declarative interface that could be used and it was pretty similar to sitio. That both made me happy to have arrived at the same results of such an acclaimed tool and sad for the same reason, as Gatsby is the worse static site generator ever created considering user experience.

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

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

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

Imagine you have two IPFS nodes and unique content, created by you, in the first one. From the second, you can connect to the first and everyhing looks right. You then try to fetch that content. After some seconds it starts coming, the progress bar begins to move, that's slow, very slow, doing an rsync would have been 20 times faster.

The progress bar halts. You investigate, the second node is not connected to the first anymore. Why, if that was the only source for the file we're trying to fetch? It remains a mistery to this day. You reconnect manually, the progress bar moves again, halts, you're disconnected again. Instead of reconnecting you decide to add the second node to the first node's "Bootstrap" list.

I once tried to run an IPFS node on a VPS and store content on S3. There are two S3 datastore plugins available. After fixing some issues in one of them, recompiling go-ipfs, figuring out how to read settings from the IPFS config file, creating an init profile and recompiling again I got the node running. It worked. My idea was to host a bunch of data on that node. Data would be fetched from S3 on demand so there would be cheap and fast access to it from any IPFS node or gateway.

IPFS started doing hundreds of calls to S3 per minute – something I wouldn't have known about if I hadn't inserted some log statements in the plugin code, I mean before the huge AWS bill arrived. Apparently that was part of participation on the DHT. Adjusting some settings turned my node into a listen-only thing as I intended, but I'm not 100% sure it would work as an efficient content provider, and I'll never know, as the memory and CPU usage got too high for my humble VPS and I had to turn it down.

Os quatro elementos, a esfera como a forma mais perfeita, os cinco sentidos, a dor como perturbação e o prazer como retorno, o demiurgo que cria da melhor maneira possível com a matéria que tem, o conceito de duro e mole, todas essas coisas que ensinam nas escolas e nos desenhos animados ou sei lá como entram na nossa consciência como se fossem uma verdade, mas sempre uma verdade provisória, infantil -- como os nomes infantis dos dedos (mata-piolho, fura-bolo etc.) --, que mesmo as crianças sabem que não é verdade mesmo.

Parece que todas essas coisas estão nesse livro. Talvez até mesmo a classificação dos cinco dedos como mata-piolho e tal, mas talvez eu tenha dormido nessa parte.

Me pergunto se essas coisas não eram ensinadas tradicionalmente na idade média como sendo verdade absoluta (pois afinal estava lá o Platão dizendo, em sua única obra) e persistiram até hoje numa tradição que se mantém aos trancos e barrancos, contra tudo e contra todos, sem ninguém saber como, um conhecimento em que ninguém acredita mas acha bonito mesmo assim, harmonioso, e vem despida de suas origens e fontes primárias e de todo o seu contexto perturbar o entendimento do mundo pelas crianças.

If I bought things for 10 and sold them for 20 did I earn a profit of 10?

-- Yes, says common sense. -- No, says the economist, because you could have bought a bond that yielded you some return with those initial 10 then spent your time working for someone else instead of working in your sales business. If that yielded more money than 10 then you actually had a loss.

That is crazy, because it produces an economy in which everybody is always losing all the time, except one ideal person who makes all the correct investment decisions and thus has no opportunity cost. That person has a profit of zero.

-- George Reisman in https://www.bobmurphyshow.com/139

"Vocês vêem? Vêem a história? Vêem alguma coisa? Me parece que estou tentando lhes contar um sonho -- fazendo uma tentativa inútil, porque nenhum relato de sonho pode transmitir a sensação de sonho, aquela mistura de absurdo, surpresa e espanto numa excitação de revolta tentando se impôr, aquela noção de ser tomado pelo incompreensível que é da própria essência dos sonhos..."

Ele ficou em silêncio por alguns instantes.

"... Não, é impossível; é impossível transmitir a sensação viva de qualquer época determinada de nossa existência -- aquela que constitui a sua verdade, o seu significado, a sua essência sutil e contundente. É impossível. Vivemos, como sonhamos -- sozinhos..."

• Livros mencionados por Olavo de Carvalho
• Antiga homepage Olavo de Carvalho
• Bitcoin explicado de um jeito correto e inteligível
• Reclamações

• Nostr
• Bitcoin
• How IPFS is broken
• Programming quibbles
• Economics
• Open-source software

Nostr GitHub Telegram code

Scala is amazing. The type system has the perfect balance between flexibility and powerfulness. match statements are great. You can write imperative code that looks very nice and expressive (and I haven't tried writing purely functional things yet). Everything is easy to write and cheap and neovim integration works great.

But Java is not great. And the fact that Scala is a JVM language doesn't help because over the years people have written stuff that depends on Java libraries -- and these Java libraries are not as safe as the Scala libraries, they contain reflection, slowness, runtime errors, all kinds of horrors.

Scala is also very tightly associated with Akka, the actor framework, and Akka is a giant collection of anti-patterns. Untyped stuff, reflection, dependency on JVM, basically a lot of javisms. I just arrived and I don't know anything about the Scala history or ecosystem or community, but I have the impression that Akka has prevent more adoption of Scala from decent people that aren't Java programmers.

But luckily there is a solution -- or two solutions: ScalaJS is a great thing that exists. It transpiles Scala code into JavaScript and it runs on NodeJS or in a browser!

Scala Native is a much better deal, though, it compiles to LLVM and then to binary code and you can have single binaries that run directly without a JVM -- not that the single JARs are that bad though, they are great and everybody has Java so I'll take that anytime over C libraries or NPM-distributed software, but direct executables even better. Scala Native just needs a little more love and some libraries and it will be the greatest thing in a couple of years.

Trechos de episódios da Memorabilia, ou os Ditos e Feitos Memoráveis de Sócrates, contados por Xenofonte (na edição que tem um prefácio do glorioso Pessanha) que mostram Sócrates sempre aconselhando os jovens a não praticar o homossexualismo -- nem mesmo quando encontrassem alguém que fosse belo:

— Dize-me, Xenofonte, não tinhas Critobulo na conta de jovem sábio antes que de amoroso indiscreto, homem prudente antes que insensato e temerário?

— Certamente — conveio Xenofonte.

— Pois bem, considera-o, doravante como o mais impulsivo e arrojado dos homens, capaz de desafiar o ferro e afrontar o fogo.

— Que o viste fazer — indagou Xenofonte — para acusá-lo dessa maneira?

— Pois não teve a temeridade de furtar um beijo ao filho de Alcibíades, jovem de tamanha beleza e frescor?

— Ora, isso é ato de temerário! — retrucou Xenofonte. — Estou que eu próprio bem poderia cometer semelhante temeridade.

— Desgraçado! — exclamou Sócrates. — Imaginas o que te sucederia se beijasses uma pessoa jovem e bela? Ignoras que de livre, num momento te tomarias escravo? Que pagarias caro prazeres perigosos? Que já não terias animo de perquirir o que é o belo e o bem? Que haverias de dar cabeçadas como um louco?

— Por Hércules! — retrucou Xenofonte — que terrível poder emprestas a um beijo!

— Admira-te? — perguntou Sócrates. — Não sabes que as tarântulas, que não são maiores que a moeda de meio óbolo, com o só tocar os lábios causam ao homem dores tremendas e privam-no da razão?

— Pois bem! — disse Critobulo — não usarei de coação com ninguém; se, pois, tens algo a dizer-me sobre como conquistar amigos, fala.

— Jamais — disse Sócrates — porás boca contra boca.

— Tranqüiliza-te. Não mais comprimirei os lábios a os lábios de ninguém, a menos que seja belo.

— Eis-te logo de saída, Critobulo, fazendo o contrário do que se deve. Os que são belos não suportam de bom grado essas liberdades, conquanto os tolerem os feios, convencidos de que os acham belos de alma.

Eis como se devia julgar Sócrates. Cometeu ele próprio algum mal? Merece ser tratado como perverso. Porém, se jamais deixou de ser homem de bem, será justo acusá-lo de uma depravação que não lhe cabe? Se, embora abstêmio do mal, houvesse assistido sem desaprová-los aos atos vergonhosos dos outros, estaria no direito de censurá-lo. Mas, tendo percebido que Crítias, enamorado de Eutidemo, queria gozá-lo à maneira dos que abusam do próprio corpo para satisfazer seus desejos amorosos, forcejou por demovê-lo de semelhante intento, dizendo-lhe indigno de homem livre e indecente a amigo da virtude ir como mendicante solicitar algo do objeto amado, junto ao qual cumpre sobretudo fazer-se valer, e ainda mais solicitar coisa oprobriosa. Crítias fazia ouvidos de mercador e não dava de si. Então se pretende haver Sócrates dito ante numerosa assistência e em presença de Eutidemo que Crítias lhe parecia ter tai ou qual semelhança com um porco, pois queria esfregar-se em Eutidemo como se esfregam os porcos nas pedras. Desde então Crítias se tornou inimigo jurado de Sócrates. Nomeado um dos Trinta e monoteta com Cáricles, guardou-lhe rancor e proibiu por lei o ensino da oratória. Assim atacava Sócrates. Não tendo de que acusá-lo, carregava-o com a censura que de comum se ínsimula aos filósofos e caluniava-o junto à opinião pública.

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.

Direct edits are a centralizing force on Nostr, a slippery slope that should not be accepted.

Edits are fine in other, more specialized event kinds, but the kind:1 space shouldn't be compromised with such a push towards centralization, because kind:1 is the public square of Nostr, where all focus should be on decentralization and censorship-resistance.

• Why?

Edits introduce too much complexity. If edits are widespread, all clients now have to download dozens of extra events at the same time while users are browsing a big feed of notes which are already coming from dozens of different relays using complicated outbox-model-based querying, then for each event they have to open yet another subscription to these relays -- or perform some other complicated batching of subscriptions which then requires more complexity on the event handling side and then when associating these edits with the original events. I can only imagine this will hurt apps performance, but it definitely raises the barrier to entry and thus necessarily decreases Nostr decentralization.

Some clients may be implemneted in way such that they download tons of events and then store them in a local databases, from which they then construct the feed that users see. Such clients may make edits potentially easier to deal with -- but this is hardly an answer to the point above, since such clients are already more complex to implement in the first place.

• What do you have against complex clients?

The point is not to say that all clients should be simple, but that it should be simple to write a client -- or at least as simple as physically possible.

You may not be thinking about it, but if you believe in the promise of Nostr then we should expect to see Nostr feeds in many other contexts other than on a big super app in a phone -- we should see Nostr notes being referenced from and injected in unrelated webpages, unrelated apps, hardware devices, comment sections and so on. All these micro-clients will have to implement some complicated edit-fetching logic now?

• But aren't we already fetching likes and zaps and other things, why not fetch edits too?

Likes, zaps and other similar things are optional. It's perfectly fine to use Nostr without seeing likes and/or zaps -- and, believe me, it does happen quite a lot. The point is basically that likes or zaps don't affect the content of the main post at all, while edits do.

• But edits are optional!

No, they are not optional. If edits become widespread they necessarily become mandatory. Any client that doesn't implement edits will be displaying false information to its users and their experience will be completely broken.

• That's fine, as people will just move to clients that support edits!

Exactly, that is what I expect to happen too, and this is why I am saying edits are a centralizing force that we should be fighting against, not embracing.

If you understand that edits are a centralizing force, then you must automatically agree that they aren't a desirable feature, given that if you are reading this now, with Nostr being so small, there is a 100% chance you care about decentralization and you're not just some kind of lazy influencer that is only doing this for money.

• All other social networks support editing!

This is not true at all. Bluesky has 10x more users than Nostr and doesn't support edits. Instagram doesn't support editing pictures after they're posted, and doesn't support editing comments. Tiktok doesn't support editing videos or comments after they're posted. YouTube doesn't support editing videos after they're posted. Most famously, email, the most widely used and widespread "social app" out there, does not support edits of any kind. Twitter didn't support edits for the first 15 years of its life, and, although some people complained, it didn't hurt the platform at all -- arguably it benefitted it.

If edits are such a straightforward feature to add that won't hurt performance, that won't introduce complexity, and also that is such an essential feature users could never live without them, then why don't these centralized platforms have edits on everything already? There must be something there.

• Eventually someone will implement edits anyway, so why bother to oppose edits now?

Once Nostr becomes big enough, maybe it will be already shielded from such centralizing forces by its sheer volume of users and quantity of clients, maybe not, we will see. All I'm saying is that we shouldn't just push for bad things now just because of a potential future in which they might come.

• The market will decide what is better.

The market has decided for Facebook, Instagram, Twitter and TikTok. If we were to follow what the market had decided we wouldn't be here, and you wouldn't be reading this post.

• OK, you have convinced me, edits are not good for the protocol. But what do we do about the users who just want to fix their typos?

There are many ways. The annotations spec, for example, provides a simple way to append things to a note without being a full-blown edit, and they fall back gracefully to normal replies in clients that don't implement the full annotations spec.

Eventually we could have annotations that are expressed in form of simple (human-readable?) diffs that can be applied directly to the post, but fall back, again, to comments.

Besides these, a very simple idea that wasn't tried yet on Nostr yet is the idea that has been tried for emails and seems to work very well: delaying a post after the "submit" button is clicked and giving the user the opportunity to cancel and edit it again before it is actually posted.

Ultimately, if edits are so necessary, then maybe we could come up with a way to implement edits that is truly optional and falls back cleanly for clients that don't support them directly and don't hurt the protocol very much. Let's think about it and not rush towards defeat.

Palavras e expressões que ninguém deveria usar porque não têm o sentido que as pessoas acham que têm, são apenas aportuguesamentos de palavras inglesas que por nuances da história têm um sentido ligeiramente diferente em inglês.

Cada erro é acompanhado também de uma sugestão de como corrigi-lo.

Palavras que existem em português com sentido diferente

• submissão (de trabalhos): envio, apresentação
• disrupção: perturbação
• assumir: considerar, pressupor, presumir
• realizar: perceber
• endereçar: tratar de
• suporte (ao cliente): atendimento
• suportar (uma idéia, um projeto): apoiar, financiar
• suportar (uma função, recurso, característica): oferecer, ser compatível com
• literacia: instrução, alfabetização
• convoluto: complicado.
• acurácia: precisão.
• resiliência: resistência.

Aportuguesamentos desnecessários

• estartar: iniciar, começar
• treidar: negociar, especular

Expressões

• "não é sobre...": "não se trata de..."

Ver também

• Algumas expressões e ditados excelentes da língua portuguesa, e outras não tão excelentes assim

Communicates over HTTP with a server that is actually connected to the Lightning Network, but generates preimages and onions locally, doing everything like the Hosted Channels protocol says. Just the communication method changes.

Could use this library: https://www.npmjs.com/package/bolt04

Existe essa discussão entre economistas sobre o comportamento de um agente ser "racional" ou não.

O julgamento da racionalidade é feito em vista de um "modelo" concebido pelo economista. Cada economista usa um modelo diferente. Daí ficam todos discutindo a racionalidade ou irracionalidade de certo agente.

A solução é perguntar: racional segundo quais critérios?

The first bot ever created for Trello.

It invited to a public board automatically anyone who commented on a card he was added to.

• https://github.com/fiatjaf/welcomebot
• https://trello.com/welcomebot

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.

There are way too many hours being wasted in making themes for blogs. And then comes a new blog framework, it requires new themes. Old themes can't be used because they relied on different ways of rendering the website. Everything is a mess.

Classless was an attempt at solving it. It probably didn't work because I wasn't the best person to make themes and showcase the thing.

Basically everybody would agree on a simple HTML template that could fit blogs and simple websites very easily. Then other people would make pure-CSS themes expecting that template to be in place.

No classes were needed, only a fixed structure of header. main, article etc.

With flexbox and grid CSS was enough to make this happen.

The templates that were available were all ported by me from other templates I saw on the web, and there was a simple one I created for my old website.

• https://github.com/fiatjaf/classless
• https://classless.alhur.es/
• https://classless.alhur.es/themes/

Creio que o objetivo primário da ciência é fornecer uma hipótese, uma convicção e uma fé mais seguras e que satisfaçam melhor o próprio investigador. Na medida em que o cientista procura provar qualquer coisa a alguém -- um erro em que incorri mais de uma vez --, creio que ele está se servindo da ciência para remediar uma insegurança pessoal, desviando-a do seu verdadeiro papel criativo a serviço do indivíduo.

Tornar-se Pessoa, página aleatória

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

"Pin" is a nice word the IPFS team has come up with to designate the act of telling your node to store some content permanently and don't garbage-collect it. The idea is that you'll store everything you fetch and reroute this to others automatically, but every once in a while all content you have on your node that is not explicitly "pinned" will be erased, so you shouldn't worry about storing too much of other people's things, but also can contribute to keep alive content you like.

Pinning has a big problem, however: you can't know what you've pinned. Every pin you add is going to be saved on your computer, you won't be able to unpin stuff because you don't know what is what, in the end you'll be left with a disk full of pinned stuff and probably lose that disk or delete everything to open up space for other things after getting frustrated with the entire IPFS experiment.

Examine the incentives in this model: we're relying on sharing being made by people that do that unwillingly and unknowngly. Users spend electricity on nodes that are supposed to be always running and serving content to others. Links are only kept unbroken if someone decides to pin them, but since there's no order, the pins are doomed to be erased everywhere.

This was a hierarchical database server similar to the original Firebase. Records were stored on a LevelDB on different paths, like:

• /fruits/banana/color: yellow
• /fruits/banana/flavor: sweet

And could be queried by path too, using HTTP, for example, a call to http://hostname:port/fruits/banana, for example, would return a JSON document like

{
  "color": "yellow",
  "flavor": "sweet"
}

While a call to /fruits would return

{
  "banana": {
    "color": "yellow",
    "flavor": "sweet"
  }
}

POST, PUT and PATCH requests also worked.

In some cases the values would be under a special "_val" property to disambiguate them from paths. (I may be missing some other details that I forgot.)

GraphQL was also supported as a query language, so a query like

query {
  fruits {
    banana {
      color
    }
  }
}

would return {"fruits": {"banana": {"color": "yellow"}}}.

SummulaDB

SummulaDB was a browser/JavaScript build of SummaDB. It ran on the same Go code compiled with GopherJS, and using PouchDB as the storage backend, if I remember correctly.

It had replication between browser and server built-in, and one could replicate just subtrees of the main tree, so you could have stuff like this in the server:

{
  "users": {
    "bob": {},
    "alice": {}
  }
}

And then only allow Bob to replicate /users/bob and Alice to replicate /users/alice. I am sure the require auth stuff was also built in.

There was also a PouchDB plugin to make this process smoother and data access more intuitive (it would hide the _val stuff and allow properties to be accessed directly, today I wouldn't waste time working on these hidden magic things).

The computed properties complexity

The next step, which I never managed to get fully working and caused me to give it up because of the complexity, was the ability to automatically and dynamically compute materialized properties based on data in the tree.

The idea was partly inspired on CouchDB computed views and how limited they were, I wanted a thing that would be super powerful, like, given

{
  "matches": {
    "1": {
      "team1": "A",
      "team2": "B",
      "score": "2x1",
      "date": "2020-01-02"
    },
    "1": {
      "team1": "D",
      "team2": "C",
      "score": "3x2",
      "date": "2020-01-07"
    }
  }
}

One should be able to add a computed property at /matches/standings that computed the scores of all teams after all matches, for example.

I tried to complete this in multiple ways but they were all adding much more complexity I could handle. Maybe it would have worked better on a more flexible and powerful and functional language, or if I had more time and patience, or more people.

Screenshots

This is just one very simple unfinished admin frontend client view of the hierarchical dataset.

• https://github.com/fiatjaf/summadb
• https://github.com/fiatjaf/summuladb
• https://github.com/fiatjaf/pouch-summa

Suppose you want to start a Nostr business.

You might be tempted to make a closed platform that reuses Nostr identities and grabs (some) content from the external Nostr network, only to imprison it inside your thing -- and then you're going to run an amazing AI-powered algorithm on that content and "surface" only the best stuff and people will flock to your app.

This will be specially good if you're going after one of the many unexplored niches of Nostr in which reading immediately from people you know doesn't work as you generally want to discover new things from the outer world, such as:

• food recipe sharing;
• sharing of long articles about varying topics;
• markets for used goods;
• freelancer work and job offers;
• specific in-game lobbies and matchmaking;
• directories of accredited professionals;
• sharing of original music, drawings and other artistic creations;
• restaurant recommendations
• and so on.

But that is not the correct approach and damages the freedom and interoperability of Nostr, posing a centralization threat to the protocol. Even if it "works" and your business is incredibly successful it will just enshrine you as the head of a platform that controls users and thus is prone to all the bad things that happen to all these platforms. Your company will start to display ads and shape the public discourse, you'll need a big legal team, the FBI will talk to you, advertisers will play a big role and so on.

If you are interested in Nostr today that must be because you appreciate the fact that it is not owned by any companies, so it's safe to assume you don't want to be that company that owns it. So what should you do instead? Here's an idea in two steps:

1. Write a Nostr client tailored to the niche you want to cover

If it's a music sharing thing, then the client will have a way to play the audio and so on; if it's a restaurant sharing it will have maps with the locations of the restaurants or whatever, you get the idea. Hopefully there will be a NIP or a NUD specifying how to create and interact with events relating to this niche, or you will write or contribute with the creation of one, because without interoperability this can't be Nostr.

The client should work independently of any special backend requirements and ideally be open-source. It should have a way for users to configure to which relays they want to connect to see "global" content -- i.e., they might want to connect to wss://nostr.chrysalisrecords.com/ to see only the latest music releases accredited by that label or to wss://nostr.indiemusic.com/ to get music from independent producers from that community.

1. Run a relay that does all the magic

This is where your value-adding capabilities come into play: if you have that magic sauce you should be able to apply it here. Your service -- let's call it wss://magicsaucemusic.com/ -- will charge people or do some KYM (know your music) validation or use some very advanced AI sorcery to filter out the spam and the garbage and display the best content to your users who will request the global feed from it (["REQ", "_", {}]), and this will cause people to want to publish to your relay while others will want to read from it.

You set your relay as the default option in the client and let things happen. Your relay is like your "website" and people are free to connect to it or not. You don't own the network, you're just competing against other websites on a leveled playing field, so you're not responsible for it. Users get seamless browsing across multiple websites, unified identities, a unified interface (that could be different in a different client) and social interaction capabilities that work in the same way for all, and they do not depend on you, therefore they're more likely to trust you.

Does this centralize the network still? But this a simple and easy way to go about the matter and scales well in all aspects.

Besides allowing users to connect to specific relays for getting a feed of curated content, such clients should also do all kinds of "social" (i.e. following, commenting etc) activities (if they choose to do that) using the outbox model -- i.e. if I find a musician I like under wss://magicsaucemusic.com and I decide to follow them I should keep getting updates from them even if they get banned from that relay and start publishing on wss://nos.lol or wss://relay.damus.io or whatever relay that doesn't even know anything about music.

The hardcoded defaults and manual typing of relay URLs can be annoying. But I think it works well at the current stage of Nostr development. Soon, though, we can create events that recommend other relays or share relay lists specific to each kind of activity so users can get in-app suggestions of relays their friends are using to get their music from and so on. That kind of stuff can go a long way.

For those who want a comparison, here is the comparison.

I'll start by listing how they are similar and then show some advantages of one versus the other and vice-versa.

Both are open protocols

• Anyone can run a hosted channel node or a hosted channel wallet and connect to any other hosted channel node or wallet.
• Anyone can run a Fedimint federation or any Fedimint wallet can connect to any Fedimint federation.

Of course one can also block others from connecting to them and vice-versa, but there is nothing in the protocols themselves that mandate anything. There is no central committee that must approve anything.

Both are protocols for IOU management (or what some like to call custodianship)

• On any hosted channel, one side of the channel (the "host") owes money to the the other (the "client"), i.e. the later must trust that the first won't exit scam.
• On any Fedimint federation the federation signers (the "guardians") owe money to the holders of notes, i.e. the later must trust that the first won't exit scam.

This is how both can provide scalability.

Both provide scalability

See point above. But in short they provide scalability by allowing people to transact without using the Bitcoin blockchain.

Both address the inherent sheer lack of privacy that normal custodians have

Normal custodial providers have a big privacy issue, which is that the users only tell their servers "I want to pay this invoice", so the server knows who they're paying, how much and so on.

• On a hosted channel, the host doesn't know where the client is sending payments to. The client does the onion routing just like a normal Lightning node so the host only sees an amount and the next hop in the route. Since the client may be paying using MPP (i.e. splitting the payment into multiple shards that go through different channels) they can't be sure that amount is the actual amount of any payment anyway.
• On Fedimint, although the Lightning gateway can see what is being paid and for how much, given the nature of Chaumian blindly-signed notes, there is no way to know which of the users is providing the money to pay that.

On normal custodian providers, when receiving, the users ask the server: "make an invoice for me with this amount and description", so the server knows how much they've received and if there is a meaningful description, also for what purpose.

• On a hosted channel, the invoice is generated by the client and the host only knows it must forward a payment it has received from elsewhere to a given hosted channel, it doesn't see the description and it cannot know if that is the last hop or if that amount is the exact amount being received (because of MPP).
• On Fedimint, the invoice is also generated on the client and the Lightning gateway only forwards the payment. Although it is sure that that payment is the final hop and the amount is complete, given the nature of Chaumian blindly-signed notes, there is no way to know which of the users is receiving that.

Hosted channels are much simpler

While a hosted channels host can be run by just attaching a simple process to a normal Lightning node, Fedimint is made to run in a federation so there is the overhead of setting up the federation environment with other people, each running their Fedimint server and establishing connections to them.

Similarly, the cryptography involved in Fedimint makes it so in practice only the reference implementation will ever be used, as a black box.

Hosted channels, on the other hand, are just some message passing through the same Noise protocol Lightning uses, with an occasional ECDSA signature, so it is much easiler to implement.

Fedimint custodianship is safer

Of course one highly-trusted individual is better than 3 or 5 scammers, but still, 3 or 5 averagely-trusted people are still better than 1 of the same kind. For that reason, the federation model provides a better way to store money than just putting it in one place.

IPFS was advertised to the Ethereum community since the beggining as a way to "store" data for their "dApps". I don't think this is harmful in any way, but for some reason it may have led IPFS developers to focus too much on Ethereum stuff. Once I watched a talk showing libp2p developers – despite being ignored by the Ethereum team (that ended up creating their own agnostic p2p library) – dedicating an enourmous amount of work on getting a libp2p app running in the browser talking to a normal Ethereum node.

The always somewhat-abandoned "Awesome IPFS" site is a big repository of "dApps", some of which don't even have their landing page up anymore, useless Ethereum smart contracts that for some reason use IPFS to store whatever the useless data their users produce.

Again, per se it isn't a problem that Ethereum people are using IPFS, but it is at least confusing, maybe misleading, that when you search for IPFS most of the use-cases are actually Ethereum useless-cases.

See also

• Bitcoin, the only non-shitcoin

Getting money from clients very easily, dispatching that money to "world class experts" (what a silly way to market things, but I guess it works) very easily are the job for Bitcoin and the Lightning Network.

EDIT 2020-09-04

My idea was that people would advertise themselves, so you would book an hour with people you know already, but it seems that clarify.fm has gone through the route of offering a "catalog of experts" to potential clients, all full of verification processes probably and marketing. So I guess this is not a thing I can do.

Actually I did https://s4a.etleneum.com/ (on Etleneum) that is somewhat similar, but of course doesn't have the glamour and network effect and marketing -- also it's just text, when in Clarity is fancy calls.

Thinking about it, this is just a simple and obvious idea: just copy things from the fiat world and make them on Lightning, but maybe it is still worth pointing these out as there are hundreds of developers out there trying to make yet another lottery game with Lightning.

It may also be a good idea to not just copy fiat-businesses models, but also change them experimenting with new paradigms, like idea: Patreon, but simple, and without subscription.

A static JS app that allowed you to authorize with your Trello account, fetch the board structure, find attachments, edit them in the browser then replace them in the cards.

Quite a nice thing. I believe it was done to help with Websites For Trello attached scripts and CSS files.

• https://github.com/fiatjaf/trello-attachments
• https://fiatjaf.github.io/trello-attachments/#/login

See also

• Temperos

If there's something all common people believe about gold is that it is useless¹. Austrian economists and libertarians in general that argue against central banks or defend a primitive gold standard are often charged with that accusation: that gold is useless, it has no use in the industry, it serves no purpose besides ornamental, so it is a silly commodity, a luxurious one, and that it would be almost immoral to have such a thing in a so central position in an economy such as the position of money.

I've seen libertarians in general argue such things as: "it is used in some dental operations", which means people make dental prosthesis of gold, something that fits in same category of jewelry, I would say.

There's also the argument of electronic connectors. That's something that appears to be true, but wouldn't suffice the anti-gold arguments. The fact remains that, besides its uses as money -- because gold is still considered to be a form money even now that it doesn't have that position formally in any country (otherwise it wouldn't be considered as an "investment" or "value store" everywhere) -- gold is used mainly for ornamental purposes².

All that is a hassle for libertarians in general. Even the Mises Regression Theory wouldn't solve that problem of people skeptical of gold due to its immoral nature. That problem is solved once you read what is written in the chapter 17 from Richard Cantillon's Essay on Economic Theory³ (page 103):

Gold and silver are capable of serving not only the same purpose as tin and copper, but also most of the purposes of lead and iron. They have this further advantage over other metals in that they are not consumed by fire and are so durable that they may be considered permanent. It is not surprising, therefore, that the men who found the other metals useful, valued gold and silver even before they were used in exchange.

So gold is indeed useful. Everybody should already know that. You can even do forks and spoons with gold. You can do furniture with gold, and many other useful stuff. As soon as you grasp this, gold is useful again. It is an useful commodity.

Answering the next question becomes easy: why isn't anyone making gold forks anywhere? The questioner already knows the answer: because it is too expensive for that.

And now the Regression Theory comes with its full force: why is it expensive? Because it has gained a lot of value in the process of becoming money. The value of gold as money is much greater than as a metal used in fork production.

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

Bitcoin is not money if not for the others.

Suponha que você queira escrever a palavra BANANA partindo de OOOOOO e usando só alterações aleatórias das letras. As alterações se dão por meio da multiplicação da palavra original em várias outras, cada uma com uma mudança diferente.

No primeiro período, surgem BOOOOO e OOOOZO. E então o ambiente decide que todas as palavras que não começam com um B estão eliminadas. Sobra apenas BOOOOO e o algoritmo continua.

É fácil explicar conceber a evolução das espécies acontecendo dessa maneira, se você controlar sempre a parte em que o ambiente decide quem vai sobrar.

Porém, há apenas duas opções:

1. Se o ambiente decidir as coisas de maneira aleatória, a chance de você chegar na palavra correta usando esse método é tão pequena que pode ser considerada nula.
2. Se o ambiente decidir as coisas de maneira pensada, caímos no //design inteligente//.

Acredito que isso seja uma enunciação decente do argumento "no free lunch" aplicado à crítica do darwinismo por William Dembski.

A resposta darwinista consiste em dizer que não existe essa BANANA como objetivo final. Que as palavras podem ir se alterando aleatoriamente, e o que sobrar sobrou, não podemos dizer que um objetivo foi atingido ou deixou de sê-lo. E aí os defensores do design inteligente dirão que o resultado ao qual chegamos não pode ter sido fruto de um processo aleatório. BANANA é qualitativamente diferente de AYZOSO, e aí há várias maneiras de "provar" que sim usando modelos matemáticos e tal.

Fico com a impressão, porém, de que essa coisa só pode ser resolvida como sim ou não mediante uma discussão das premissas, e chega um ponto em que não há mais provas matemáticas possíveis, apenas subjetividade.

Daí eu me lembro da minha humilde solução ao problema do cão que aperta as teclas aleatoriamente de um teclado e escreve as obras completas de Shakespeare: mesmo que ele o faça, nada daquilo terá sentido sem uma inteligência de tipo humano ali para lê-las e perceber que não se trata de uma bagunça, mas sim de um texto com sentido para ele. O milagre se dá não no momento em que o cão tropeça no teclado, mas no momento em que o homem olha para a tela.

Se o algoritmo da evolução chegou à palavra BANANA ou UXJHTR não faz diferença pra ela, mas faz diferença para nós, que temos uma inteligência humana, e estamos observando aquilo. O homem também pensaria que há //algo// por trás daquele evento do cão que digita as obras de Shakespeare, e como seria possível alguém em sã consciência pensar que não?

Quando for ouvir música de fundo, escolha músicas bem conhecidas. Para ouvir músicas novas, reserve um tempo e ouça-as com total atenção.

Uma coisa similar é dirigir por caminhos conhecidos versus dirigir em lugares novos. a primeira opção te permite fazer coisas enquanto dirige "de fundo", a segunda requer atenção total.

Com músicas, tenho errado constantemente em achar que posso conhecer músicas novas ao mesmo tempo em que me dedico a outras tarefas.

See also:

• Músicas que você já conhece

On Why I don't like NIP-26 as a solution for key management I talked about multiple techniques that could be used to tackle the problem of key management on Nostr.

Here are some ideas that work in tandem:

• NIP-41 (stateless key invalidation)
• NIP-46 (Nostr Connect)
• NIP-07 (signer browser extension)
• Connected hardware signing devices
• other things like musig or frostr keys used in conjunction with a semi-trusted server; or other kinds of trusted software, like a dedicated signer on a mobile device that can sign on behalf of other apps; or even a separate protocol that some people decide to use as the source of truth for their keys, and some clients might decide to use that automatically
• there are probably many other ideas

Some premises I have in my mind (that may be flawed) that base my thoughts on these matters (and cause me to not worry too much) are that

• For the vast majority of people, Nostr keys aren't a target as valuable as Bitcoin keys, so they will probably be ok even without any solution;
• Even when you lose everything, identity can be recovered -- slowly and painfully, but still --, unlike money;
• Nostr is not trying to replace all other forms of online communication (even though when I think about this I can't imagine one thing that wouldn't be nice to replace with Nostr) or of offline communication, so there will always be ways.
• For the vast majority of people, losing keys and starting fresh isn't a big deal. It is a big deal when you have followers and an online persona and your life depends on that, but how many people are like that? In the real world I see people deleting social media accounts all the time and creating new ones, people losing their phone numbers or other accounts associated with their phone numbers, and not caring very much -- they just find a way to notify friends and family and move on.

We can probably come up with some specs to ease the "manual" recovery process, like social attestation and explicit signaling -- i.e., Alice, Bob and Carol are friends; Alice loses her key; Bob sends a new Nostr event kind to the network saying what is Alice's new key; depending on how much Carol trusts Bob, she can automatically start following that and remove the old key -- or something like that.

One nice thing about some of these proposals, like NIP-41, or the social-recovery method, or the external-source-of-truth-method, is that they don't have to be implemented in any client, they can live in standalone single-purpose microapps that users open or visit only every now and then, and these can then automatically update their follow lists with the latest news from keys that have changed according to multiple methods.

filemap solves the problem of sending and receiving files to and from non-tech people when you don't have a text communication channel with them.

Imagine you want to send files to your grandfather, or you don't use Facebook and your younger cousin who only uses Facebook and doesn't know what is email wants to send you some pictures, it's pretty hard to get a file-sharing channel between people if they're not in the same network. If even the people have a way to upload the files to some hosting service and then share the link everything would still work, but you're not going to write somehostingservice.com/wHr4y7vFGh0 to your grandfather -- or expect your cousin to do that for you and send you an SMS with dozens of those links.

Solution: * Upload your files to https://filemap.xyz/ (you can either upload directly or share links to things already uploaded -- or even links to pages) and pin them to your grandfather's house address; then tell your grandfather to open https://filemap.xyz/ and look for his address. Done. * Tell your younger cousin to visit filemap.xyz and upload all the files to his address, later you open the site and look for his address. There are your files.

Initially this used ipfs-dropzone, but IPFS is broken, os I migrated to WebTorrent, but that required the file sender to be online hosting its own file and the entire idea of this service was to make something easy, so I migrated to Firebase Hosting, which is also terrible and has a broken API, but at least is capable of hosting files. Should have used something like S3.

• https://github.com/fiatjaf/filemap.xyz
• https://filemap.xyz/

Traditionally the Austrian Theory of Business Cycles has been explained and reworked in many ways, but the most widely accepted version (or the closest to the Mises or Hayek views) view is that banks (or the central bank) cause the general interest rate to decline by creation of new money and that prompts entrepreneurs to invest in projects of longer duration. This can be confusing because sometimes entrepreneurs embark in very short-time projects during one of these bubbles and still contribute to the overall cycle.

The solution is to think about the "longer term" problem is to think of the entire economy going long-term, not individual entrepreneurs. So if one entrepreneur makes an investiment in a thing that looks simple he may actually, knowingly or not, be inserting himself in a bigger machine that is actually involved in producing longer-term things. Incidentally this thinking also solves the biggest criticism of the Austrian Business Cycle Theory: that of the rational expectations people who say: "oh but can't the entrepreneurs know that the interest rate is artificially low and decide to not make long-term investiments?" ("and if they don't know they should lose money and be replaced like in a normal economy flow blablabla?"). Well, the answer is that they are not really relying on the interest rate, they are only looking for profit opportunities, and this is the key to another confusion that has always followed my thinkings about this topic.

If a guy opens a bar in an area of a town where many new buildings are being built during a "housing bubble" he may not know, but he is inserting himself right into the eye of that business cycle. He expects all these building projects to continue, and all the people involved in that to be getting paid more and be able to spend more at his bar and so on. That is a bet that may or may not end up paying.

Now what does that bar investiment has to do with the interest rate? Nothing. It is just a guy who saw a business opportunity in a place where hungry people with money had no bar to buy things in, so he opened a bar. Additionally the guy has made some calculations about all the ending, starting and future building projects in the area, and then the people that would live or work in that area afterwards (after all the buildings were being built with the expectation of being used) and so on, there is no interest rate calculations involved. And yet that may be a malinvestiment because some building projects will end up being canceled and the expected usage of the finished ones will turn out to be smaller than predicted.

This bubble may have been caused by a decline in interest rates that prompted some people to start buying houses that they wouldn't otherwise, but this is just a small detail. The bubble can only be kept going by a constant influx of new money into the economy, but the focus on the interest rate is wrong. If new money is printed and used by the government to buy ships then there will be a boom and a bubble in the ship market, and that involves all the parts of production process of ships and also bars that will be opened near areas of the town where ships are built and new people are being hired with higher salaries to do things that will eventually contribute to the production of ships that will then be sold to the government.

It's not interest rates or the length of the production process that matters, it's just printed money and malinvestiment.

Em 2005 a Cultura Inglesa me classificou como nível 2 em proficiência de inglês, numa escala de 1 a 14 ou coisa parecida. De modo que eu precisaria de 6 anos de aulas com eles pra ficar bom. 2 anos depois, sem fazer nenhuma aula ou ter qualquer tipo de treinamento intensivo eu era capaz de compreender textos técnicos em inglês sem nenhuma dificuldade. Mais 2 anos e eu era capaz de compreender qualquer coisa e me expressar com razoável qualidade.

Tudo isso pra documentar mais um exemplo, que poderia passar despercebido, de aprendizado de tipo escolar que se deu fora de uma escola.

If you have a closed system, a platform with users inside that login with name and password, it's not hard to introduce "social network" features into it. It was always the plan at ZEBEDEE to introduce such a thing, but much better than a closed social network just for ZBD users is if one such a thing can plug into the outer world of Nostr. Therefore ZBD Social is both an internal social network and a network that is open to the external world through Nostr.

The ZBD app already includes a custodial Bitcoin Lightning wallet and the target userbase doesn't want to care about keys and prefers email and password as the login mechanism to a trusted platform, therefore the ZBD Social is a custodial Nostr client. ZBD users also may be running their app on low-spec phones and low bandwidth, and since the key is already custodial it makes more sense to have all the Nostr logic for each ZBD user to be done on a ZEBEDEE server, instead of in the device itself, therefore the Social section on the ZBD app is just a thin client to an internal API.

Doing the correct thing given the constraints

In order for Nostr to scale, people must be able to host their notes in whatever relay they want and their followers must still be able to find these.

With that goal in mind, the ZBD Social server keeps track of all associations it can find -- in event hints, kind 3 and kind 10002 events, nprofile and nevent codes and the bare fact that a given event from someone was found in a given relay -- and uses that information to estimate the best possible set of relays to be used to fetch notes for each Nostr user, along with some variance to account for the fact that these sets are dynamic.

Whenever a ZBD user wants to read notes from any external Nostr user -- either because they've opened on that user's profile or because they follow that user and are browsing their classic "home feed" with notes from everybody they follow -- the ZBD Social backend will gather the best relays for that given user and open new subscriptions -- if there isn't already a subscription open -- for that user. If there are already other subscriptions open for other users in that same relay, the subscriptions will be merged in order to not spam external relays.

As they come in, notes from external users are cached in a way that they are automatically evicted as soon as memory is low and they haven't been accessed for a while. Browsing through old notes is done through paging these cached notes, indexed by author.

The wss://nostr.zbd.gg relay

The ZBD relay stores all events emitted by ZBD users. It runs strfry with a plugin that makes it interact with the rest of the backend. It is replicated accross multiple instances using strfry's native syncing capabilities and serves both as a normal relay interface to which external Nostr clients can talk normally and as a database that can be queried by the internal backend (turns out strfry is not only a Nostr relay, it is also a mechanism to turn LMDB into a cloud-native datastore).

This makes it easy to have a dedicated tab on the app with the feed of all the other ZBD users, which is effectively the same as browsing just wss://nostr.zbd.gg from any other Nostr client -- see, for example, Coracle, nostrrr, nostr.com or using the CLI: nak req -l 10 --stream wss://nostr.zbd.gg | jq.

It also contributes to the future world of Nostr in which niche relays can be browsed individually to enhance the experience of normal social interactions. For any given note, for example, you should be able to see "what are the ZBD users commenting about this" or "what are the gold enthusiasts saying" and so on.

Ideas for the future

Being a Nostr custodian in a platform that offers Lightning payment services and other third-party integrations for its existing userbase, it's easy to see how ZEBEDEE can start bridging Nostr into more things inside its domain.

For example, in the future ZEBEDEE could offer a way for game vendors to plug in a social networking layer into their games and that wouldn't be just an API to a proprietary platform, but a bridge to the real Nostr world that integrates seamlessly with the ZBD app for ZBD users, but works in Nostr-native mode for any Nostr user. Another use case could be powering social features for music and entertainment apps. Another very obvious use case is a NIP-58 badges system that games and other "gamified" services and apps can use.

In a not distant future, I imagine we'll see also integrations with the ZBD browser extension and NIP-07, Nostr features with the Telegram and Discord bots, and NIP-53 integration with ZBD Streamer (but I am not officially announcing anything).

The website history.com has a list of some of the most important "checks and balances" put in place by the United States Constitution. Here are some of them and how they are not real checks, they're flawed and easily bypassed by malicious peers that manage to enter the network.

The president (head of the executive branch) serves as commander in chief of the military forces, but Congress (legislative branch) appropriates funds for the military and votes to declare war.

As it has happened multiple times, the United States has engaged in many undeclared wars -- and many other military encounters that don't get enough media coverage and weren't even formally acknowledged by the Congress.

Congress has the power of the purse, as it controls the money used to fund any executive actions.

There's a separate power called Federal Reserve which is more-or-less under the influence of the executive branch that is controlled by a single man and has the power of creating unlimited money. It was softly abused by the executive branch since its creation, but since 2008 it has been increasingly having its scope expanded from just influencing the banking sector to also directly using its money to buy all sorts of things and influence all sorts of markets and other actors.

Veto power. Once Congress has passed a bill, the president has the power to veto that bill. In turn, Congress can override a regular presidential veto by a two-thirds vote of both houses.

If you imagine that both the executive and the legislative are 100% dedicated to go against each other the president could veto all bills, but then the legislative could enact them all anyway. Congress has the absolute power here (which can be justified by fact that the congress itself is split into multiple voters, but still this "veto" rule seems more like a gimmick to obscure the process than any actual check).

The Supreme Court and other federal courts (judicial branch) can declare laws or presidential actions unconstitutional, in a process known as judicial review.

This rule gives absolute power to the Supreme Court over any matter. It can use their own personal judgement to veto any bill, cancel any action by the executive, reinterpret any existing law in any manner. There's no check against bad interpretations or judgements, so any absurd thing must be accepted. This should be obvious, and yet the entire system which most people believe to be "checked" is actually dependent on the good will and sanity of the judicial branch.

In turn, the president checks the judiciary through the power of appointment, which can be used to change the direction of the federal courts

If the president and congress are being attacked by the judicial power, this isn't of much help as its effects are very long term. On the other hand, a president can single-handedly and arbitrarily use this rule to slowly poison the judicial system such that will turn malicious for the rest of the system after some time.

By passing amendments to the Constitution, Congress can effectively check the decisions of the Supreme Court.

What is written in the Constitution can be easily ignored or misread by the members of the Supreme Court without any way for these interpretations to be checked or reverted. Basically the Supreme Court has absolute power over all things if we consider this.

Congress (considered the branch of government closest to the people) can impeach both members of the executive and judicial branches.

Again (like in the presidential veto rule), this gives the congress unlimited power. There are no checks here -- except of course the fact that the congress is composed by multiple different voting heads of which a majority has to agree for the congress to do anything, which is the only thing preventing overabuse of this rule.

As shown above, most rules that compose the "checks and balances" system can be abused and if given enough time they will. They aren't real checks.

Ultimately, the stability and decency of a democracy relies on the majority rule (so congress votes are never concentrated in dictatorial measures) and the common sense of the powerful people (president and judges).

There probably hasn't been a single year in any democracy in which one of these powers didn't abused or violated one of the rules, but still in most cases the overall system stays in place because of the general culture, splitted views about most issues, overall common sense and fear of public shame.

The checks and balances system itself is an illusion. All the complex "democracy" construct depends on the goodwill of all the participants and have only worked so far (when it did) by miracle and by the power of human cooperation and love.

Names like "blablabla for trello" were the official recommendation from Trello for anyone doing services that integrated with it.

This one generated websites from cards and lists on a board.

The websites were generated from a fixed HTML template that were possible to be styled using the standard for CSS and JS plugins I've created, classless.

It was very complex, used RabbitMQ, a Python tasker that constantly rebuilt the sites on a Postgres database, Trello webhooks, a Go server that just sent the data to the client, I don't remember, but it was terrible design, although it was fun to think of the many branches and complexities of it, but also a huge amount of mostly wasted work.

It had some few paying users for a time.

• https://github.com/fiatjaf/websites-for-trello
• https://websitesfortrello.com/

See also

• Boardthreads

This is another attempt and conveying the same information that should be in Lightning and its fake HTLCs. It assumes you know everything about Lightning and will just highlight a point. This is also valid for PTLCs.

The protocol says HTLCs are trimmed (i.e., not actually added to the commitment transaction) when the cost of redeeming them in fees would be greater than their actual value.

Although this is often dismissed as a non-important fact (often people will say "it's trusted for small payments, no big deal"), but I think it is indeed very important for 3 reasons:

1. Lightning absolutely relies on HTLCs actually existing because the payment proof requires them. The entire security of each payment comes from the fact that the payer has a preimage that comes from the payee. Without that, the state of the payment becomes an unsolvable mystery. The inexistence of an HTLC breaks the atomicity between the payment going through and the payer receiving a proof.
2. Bitcoin fees are expected to grow with time (arguably the reason Lightning exists in the first place).
3. MPP makes payment sizes shrink, therefore more and more of Lightning payments are to be trimmed. As I write this, the mempool is clear and still payments smaller than about 5000sat are being trimmed. Two weeks ago the limit was at 18000sat, which is already below the minimum most MPP splitting algorithms will allow.

Therefore I think it is important that we come up with a different way of ensuring payment proofs are being passed around in the case HTLCs are trimmed.

Channel closures

Worse than not having HTLCs that can be redeemed is the fact that in the current Lightning implementations channels will be closed by the peer once an HTLC timeout is reached, either to fulfill an HTLC for which that peer has a preimage or to redeem back that expired HTLCs the other party hasn't fulfilled.

For the surprise of everybody, nodes will do this even when the HTLCs in question were trimmed and therefore cannot be redeemed at all. It's very important that nodes stop doing that, because it makes no economic sense at all.

However, that is not so simple, because once you decide you're not going to close the channel, what is the next step? Do you wait until the other peer tries to fulfill an expired HTLC and tell them you won't agree and that you must cancel that instead? That could work sometimes if they're honest (and they have no incentive to not be, in this case). What if they say they tried to fulfill it before but you were offline? Now you're confused, you don't know if you were offline or they were offline, or if they are trying to trick you. Then unsolvable issues start to emerge.

Arbiters

One simple idea is to use trusted arbiters for all trimmed HTLC issues.

This idea solves both the protocol issue of getting the preimage to the payer once it is released by the payee -- and what to do with the channels once a trimmed HTLC expires.

A simple design would be to have each node hardcode a set of trusted other nodes that can serve as arbiters. Once a channel is opened between two nodes they choose one node from both lists to serve as their mutual arbiter for that channel.

Then whenever one node tries to fulfill an HTLC but the other peer is unresponsive, they can send the preimage to the arbiter instead. The arbiter will then try to contact the unresponsive peer. If it succeeds, then done, the HTLC was fulfilled offchain. If it fails then it can keep trying until the HTLC timeout. And then if the other node comes back later they can eat the loss. The arbiter will ensure they know they are the ones who must eat the loss in this case. If they don't agree to eat the loss, the first peer may then close the channel and blacklist the other peer. If the other peer believes that both the first peer and the arbiter are dishonest they can remove that arbiter from their list of trusted arbiters.

The same happens in the opposite case: if a peer doesn't get a preimage they can notify the arbiter they hadn't received anything. The arbiter may try to ask the other peer for the preimage and, if that fails, settle the dispute for the side of that first peer, which can proceed to fail the HTLC is has with someone else on that route.

A Haskell app that uses Miso and hledger's Haskell libraries plus ghcjs to be compiled to a web page, and then adds optional remoteStorage so you can store your ledger data somewhere else.

This was my introduction to Haskell and also built at a time I thought remoteStorage was a good idea that solved many problems, and that it could use some help in the form of just yet another somewhat-useless-but-cool project using it that could be added to their wiki.

• https://hledger.alhur.es/
• https://github.com/fiatjaf/hledger-web

See also

• My stupid introduction to Haskell
• LessPass remoteStorage
• TiddlyWiki remoteStorage

This was an app that allowed people to create micro apps powered by forms. Actually just one form I believe. The idea was for the micro apps to be really micro.

For example, you want a list of people, but you can only have at most 10 people in the list. Your app could keep a state with list of people already added and reject any other submissions above the specified limit. This would be done with 3 lines of code and provide an automatic form for people to fill with expected data.

Another example, you wanted to create a list of people that would go to an event and each would have to bring one item from a list: you created an initial state of a list of the items that should be brought, then specified a form where people could write their names and select the item they would bring, then code that for each submitted form added the name of the person plus the item they would bring to the state while also removing the selected item from the available items. Also 3 or 4 lines of data.

Something like this can't be done anywhere else. But also of course it would be arcane and frighten normal people and so on (although I do believe some "normal" people would be able to use such a thing if they needed it, just like they learn to write complex Excel formulas and still don't call themselves programmers).

• https://github.com/fiatjaf/superform.xyz

See also

• Etleneum, as it is basically the same core idea of a mutable state that is affected by calls, but Etleneum introduces (and actually forces the usage of) money, both in the sense that it acts as an escrow for contract results and that it mandates the payment of a small amount with each call, so it ends up not serving the same purposes.

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

https://www.terra.com.br/noticias/brasil/cidades/manaus-comeca-a-enterrar-em-valas-coletivas,e7da8b2579e7f032629cf65fa27a11956wd2qblx.html

Todo o Estado do Amazonas tem 193 mortos por Coronavirus, mas essa foto de "valas coletivas" sendo abertas em Manaus tem aproximadamente 500 túmulos. As notícias de "calamidade total" já estão acontecendo pelo menos desde o dia 11 (https://www.oantagonista.com/brasil/manaus-sao-paulo-e-rio-de-janeiro-nao-podem-relaxar-com-as-medidas-de-distanciamento/).

O comércio está fechado por decreto desde o final de março (embora a matéria diga que as pessoas não estão respeitando).

Decentralized Identifiers are supposedly a standard that will allow anyone (or anything) to have an online identity. The DID is a URI like did:<method>:<data> in which <method> determines how to interpret the <data>. The data is generally a public key in some cryptographic system or shitcoin blockchain, or a naked key, or a DNS-backed web address.

Some of the DID proponents argue that this is for maximum interoperability, since any new system can be supported under the same standard, i.e. supposedly an application could "support DIDs" (as some would say) and that would allow anyone to just paste their DID string there and that would refer to something.

There are a gazillion of different DID "methods", most of them are probably barely used. What does it mean for an application to "support" DIDs, then? For the interoperability argument to make any sense that must mean that the application must understand all the "methods" -- which involves understanding all cryptographic protocols and reading and interpreting data from a gazillion different blockchains and also understanding the specifics of each method, since the data of each blockchain or website and so on must also be interpreted according to the rules of the method.

It must be clear from the paragraph above that the DID goal is is unimplementable and therefore will either fail horribly by lack of adoption; or it will have to be changed to something else (for example everybody will start accepting just did:key and ignore others and that will be the standard); or it will become a centralized thing with all supporting applications using a single set of libraries that have built-in support for all methods by calling centralized servers that return the final product of processing the DID data for each method.

See also:

• The problem with ION

An interactive REPL for jq with smart helpers (for example, it automatically assigns each line of input to a variable so you can reference it later, it also always referenced the previous line automatically).

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

See also

• jiq
• jq-web

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

Que grande bobagem.

Fractional-reserve banking isn't anything else besides transfer of money from the people at large to bankers.

It has been argued that fractional-reserve banking serves a purpose in making new funds available out of no one's pocket for lending and thus directing resources to productive borrowers. This financing method is preferrable to the more conservative way of borrowing funds directly from a saver and then using that to lend to others because it uses new money, money not tied to anyone else before, and thus it's cheaper and involves less friction.

Instead, what happens is that someone must at all times be the owner of each money. So when banks use their power of generating fractional-reserve funds, they are creating new money and they are the owners – at this point, a theft occurs from the public at large to them – and then they proceed to lend their own money. From this description it is clear that the fact that bank customers have previously deposited their own funds in the banks' vaults have no direct relation with the fact that banks created money afterwards, there's only a legal relation and the fact that banks may need cash deposited by its customers to redeem borrowers claims, but even that wouldn't be necessary if banks were allowed to print their own cash.

Many a time it has been brought up the fact that the NIPs repository is a central part of the otherwise fully decentralized Nostr protocol and some ideas have been proposed about how we should proceed to decentralize that part of it.

Two of the most reasonable approaches were (very simply) (1) for anyone to write their own version of the NIPs anywhere they wanted; and (2) to have a link from the NIPs repository to some "proprietary" specs defined elsewhere. Approach 1 has been more-or-less codified in the NUDs proposal (which wasn't really adopted) and approach 2 on the practice used a few times of "reserving kinds" in the NIPs repository README table.

Two frequent (and correct and good) arguments against "decentralizing" the repo were that (a) the current NIPs repo serves as a good discussion forum for new ideas and index of potential NIPs; and (b) some centralization is needed and good so developers are forced to cooperate and work on interoperability.

So here goes one idea that actually tries to satisfy 1, 2, a and b together while at the same time decentralizing the process as much as possible:

• We stop using the NIPs repository completely.
• We create a new repository, much less opinionated and contentious, only for reserving kind numbers and giving a short description to them.
• Anyone interested in any kind -- or group of kinds that work together -- writes a guide explaining how these kinds work and how they should be properly used.

With this simple approach we solve many problems:

• Most current NIPs are actually just schema descriptions of what tag is what and what is the shape of the events. It's kind of a waste of numbers and human memory to have to create a new NIP, get a number assigned and go through all the process (that has gone increasingly bureaucractic) just to define a new event kind with some small number of tags.
• NIPs that aren't like that, such as NIP-05, for example, would probably be better served by multiple attempts by different people at explaining the idea, each in its own way, such that the future implementor would have more options.
• Currently the text of the NIPs is often too short, it doesn't really inform developers about how exactly each event kind should be used in practice, the exact logic flow clients use, specially the part about choosing what relays to use at each step (which caused many developers to just focus on translating between event schemas as described in the NIP text and UI elements and disregarded the hard subtleties of relay choice, writing "clients" that only connected to a hardcoded set of relays). Because there may be difference in approaches the NIP text ends up not being a good place to write these things, but different personal articles written by people personally involved in one or more implementations could, and they would serve Nostr better.
• GitHub might have been a good platform for a while, but it's becoming increasingly worse in many aspects. And for the discussion forums it provides (the "pull request" and "issue" pages) we should be dogfooding Nostr-based groups or even kind:1 threads. We may keep the registry of kinds there for now, but since that is just a simple list it will be much easier to move elsewhere later.
• There are already many practices out there that aren't codified in the NIPs repository, and it feels wrong that some (including some that I personally disagree with) have this inevitable officialness aura that comes from the NIP number while others that are pretty good don't, just because they are only being used by one person.
• As the NIPs repo inevitably gets more ossified we'll still need a way to assign the remaining kind numbers to the hundreds of unexplored Nostr possibilities. This approach hopefully serves that.
• And, finally, this flexibler approach allows bad or abandoned NIPs to effectively die such that they don't continue to pollute the minds of every new programmer that first gets introduced to Nostr and inevitably starts reading the "list of NIPs".

One last irrelevant word, if you aren't tired of reading: when I first turned the LNURL spec from a single confusing blob of text into a modular numbered-documents approach that approach felt very correct. However the situation was different, that thing described a single main "flow" with strictly optional features on top, each document described one of these optional features and what dependencies they had. Then I just copied that approach to Nostr, I'm not sure if I thought Nostr was always going to be a single main flow (text notes) but it clearly isn't and hopefully it will grow to be even less like that. Nostr also clearly isn't like a single-implementation programming-language-spec with a dictator and his committee on evaluating random "improvement proposals". So we're forced to conclude that the numberered-documents approach isn't the best way to do coordinate the creation of Nostr-based sub-protocols.

Imagine you have an app that created one document for each day. The docs ids are easily "2015-02-05", "2015-02-06" and so on. Nothing could be more simple. Let's say each day you record "sales", "expenses" and "events", so this a document for a typical day for the retail management Couchapp for an orchid shop:

{
  "_id": "2015-02-04",
  "sales": [{
    "what": "A blue orchid",
    "price": 50000
  }, {
    "what": "A red orchid",
    "price": 3500
  }, {
    "what": "A yellow orchid",
    "price": 11500
  }],
  "expenses": [{
    "what": "A new bucket",
    "how much": 300
  },{
    "what": "The afternoon snack",
    "how much": "1200"
  }],
  "events": [
    "Bob opened the store",
    "Lisa arrived",
    "Bob went home",
    "Lisa closed the store"
  ]
}

Now when you want to know what happened in a specific day, you know where to look at.

But you don't want only that, you want profit reports, cash flows, day profitability, a complete log of the events et cetera. Then you create one view to turn this mess into something more useful:

function (doc) {
  var spldate = doc._id.split("-")
  var year = parseInt(spldate[0])
  var month = parseInt(spldate[1])
  var day = parseInt(spldate[2])

  doc.sales.forEach(function (sale, i) {
    emit(["sale", sale.what], sale.price)
    emit(["cashflow", year, month, day, i], sale.price)
  })
  doc.expenses.forEach(function (exp, i) {
    emit(["expense", exp.what], exp.price)
    emit(["cashflow", year, month, day, i], -exp.price)
  })
  doc.events.forEach(function (ev, i) {
    emit(["log", year, month, day, i], ev)
  })
}

Then you add a reduce function with the value of _sum and you get a bunch of useful query endpoints. For example, you can request

/_design/orchids/_view/main?startkey=["cashflow", "2014", "12"]&endkey=["cashflow", "2014", "12", {}]

A server that creates instant chat rooms with Server-Sent Events and normal HTTP POST requests (instead of WebSockets which are an overkill most of the times).

It defaults to a room named as your public IP, so if two machines in the same LAN connect they'll be in the same chat automatically -- but then you can also join someone else's LAN if you need.

This is supposed to be useful.

• https://github.com/fiatjaf/localchat
• https://localchat.bigsun.xyz/

See also

• Filemap

Content-addressing is unusable with an index or database that describes each piece of content. Since IPFS is fully content-addressable, nothing can be done with it unless you have a non-IPFS index or database, or an internal protocol for dynamic and updateable links.

The IPFS conceit made then go with the with the second option, which proved to be a failure. They even incentivized the creation of a database powered by IPFS, which couldn't be more misguided.

(A somewhat absurd example, but you'll get the idea)

Iimagine some client decides to add support for a variant of nip05 that checks for values at /.well-known/nostr.yaml besides /.well-known/nostr.json. "Why not?", they think, "I like YAML more than JSON, this can't hurt anyone".

Then some user makes a nip05 file in YAML and it will work on that client, they will think their file is good since it works on that client. When the user sees that other clients are not recognizing their YAML file, they will complain to the other client developers: "Hey, your client is broken, it is not supporting my YAML file!".

The developer of the other client, astonished, replies: "Oh, I am sorry, I didn't know that was part of the nip05 spec!"

The user, thinking it is doing a good thing, replies: "I don't know, but it works on this other client here, see?"

Now the other client adds support. The cycle repeats now with more users making YAML files, more and more clients adding YAML support, for fear of providing a client that is incomplete or provides bad user experience.

The end result of this is that now nip05 extra-officially requires support for both JSON and YAML files. Every client must now check for /.well-known/nostr.yaml too besides just /.well-known/nostr.json, because a user's key could be in either of these. A lot of work was wasted for nothing. And now, going forward, any new clients will require the double of work than before to implement.

NIP-26 was created out of the needs of the Nostr integration at https://minds.com/. They wanted Minds users to be able to associate their "custodial" Nostr key with an external self-owned key. NIP-26 looked like a nice fit for the job, because it would allow supporting clients to associate the two identities statelessly (i.e. by just seeing one event published by Minds but with a delegation tag on it the client would be able to associate that with the self-owned external key without anything else¹).

The big selling point of NIP-26 (to me) was that it was fully optional. Clients were free to not implement it and they would not suffer much. They would just see "bob@minds.com" published this, and "bob-self-owned" published that. They would probably know intuitively that these two were the same person, or not, but it wouldn't be an issue. Both would still be identified as Bob and have a picture, a history and so on. Moreover, this wasn't expected to happen a lot, it would be mostly for the small intersection of people that wanted to have their own keys and also happened to be using one of these "custodial Nostr" platforms like Minds.

At some point, though, NIP-26 started to be seen as the solution for key management on Nostr. The idea is that someone will generate a very safe key on a hardware device and guard it as their most precious treasure without it ever touching the internet, and use it just to sign delegation tags. Then use multiple of these delegation tags, one for each different Nostr app, and maybe rotate them every month or so, details are unclear.

This breaks the previous expectations I had for NIP-26 entirely, as now these keys become faceless entities that can't be associated with anything except their "master" key (the one that is in cold storage). So in a world in which most Nostr users are using NIP-26 for everything, clients that do not implement NIP-26 become completely useless, as all they will see is a constant stream of random keys. They won't be able to follow anyone or interact with anyone, as these keys will not identify any concrete person on their back, they will vanish all the time and new keys will show up and the world will be chaotic. So now every client must implement NIP-26 to become usable at all, it is not optional anymore.

You may argue that making NIP-26 a de facto mandatory NIP isn't a bad thing and is worth the cost, but I think it breaks a lot of the simplicity of the protocol. It would probably be worth the cost if we knew NIP-26 was an actual complete solution, but it definitely is not, it is partial, and not the most elegant thing in the world. I think key management can be solved in multiple different ways that can all work together or not, but most importantly they can all remain optional.

More thoughts on these multiple ways can be found at Thoughts on Nostr key management.

If I am wrong about all this and we really come to the conclusion that we need a de facto mandatory key delegation method for Nostr, so be it -- but in that case, considering that we will break backwards-compatibility anyway, I think there might be a better design than NIP-26, more optimized and easier to implement, I don't know how exactly. But I really think we shouldn't rush that.

Adam Smith says that there were first workers earning wages, but then came the capitalists and extracted profits from those wages.

But in fact if that primitive state ever existed there were no workers, but entrepreneursearning profit. And since they were not capitalists ("capitalist" defined as someone that buys with the intent of selling) they were earning an infinite rate of profit.

When capitalists came they were responsible for introducing costs (investment) reducing thus the rate of profit -- and the more capitalistic the society the smaller the rate of profits.

-- George Reisman in https://www.bobmurphyshow.com/139

I don't have much experience with that so maybe this is all a stupid nonsense, but I think routing in mesh networks (by which I mean all the software that exists out there for creating smallish mesh networks and the real-world projects that use them and effectively have a community of people that connect to each other in some geographical area or a virtual network that uses the underlying internet) is never scalable. It basically always requires all the nodes to keep a full view of the network in order to route packages -- and often there is no incentive for them to do that either. And then the thing is easily spammable but either that problem doesn't happen because the mesh never gets big enough or it has a central committee that decides who can join.

The biggest example is, of course, the big ICANN-controlled IP network, that gets all the negatives of being centrally controlled while weirdly getting also all the negatives of being a kinda-decentralized peer-to-peer ad-hoc network between indepent ISPs.

A good solution that makes kinda-decentralized (at least open and permissionless) routing possible and replaces node addresses with pubkeys could get make it possible for us to get rid of ICANN. Once that is done, ad-hoc peering would become more seamless and ISPs wouldn't have to be so big and clunky, they could slowly split, and non-comercial entities could join the party too by basically just plugging a cable or pointing an antenna to the correct place.

What is it?

One very dumb solution that came to my mind that has a chance of working is one in which each node as a keypair and to be reachable by others they announce their address -- for example, using some kind of DNS (on a [spacechain]?) or by directly communicating their address through some other means -- as their public key plus some "routing hints".

The routing hints are just pubkeys of other nodes known to be routers. Known to whom? Well, this would require some schelling points to naturally appear and the network would be ordered around them, but you are never forced to use them, you have to include as many routing hints as required to ensure that all the people you want to connect to you will eventually be able to, but nothing is ever 100% guaranteed.

Such network could probably work with a pure onion routing scheme with all its privacy benefits in some cases; degrading to a trampoline onion routing scheme otherwise, which means it will just be slightly less private the more trampolines you have to use. And every node has to keep track of just a set of routes from them to a bunch of known routers (or trampolines, which in my mind are mostly the same nodes, but are slightly different roles).

Example

Suppose A is trying to connect to B.

A is a home computer in the city of Évora, Portugal.

B is a home computer in the city of Udine, Italy.

There is a route (we, the narrator, know) between them that goes like this:

A--Ev--Li--Al--Ro--Sm--Ve--Ud--B, in which Ev means the node of an ISP in Évora which directly serves A, Li means a big node in Lisboa, Al a node in Algiers, Ro a node in Rome, Sm a node in San Marino, Ve a node in Venice and Ud a gateway node in the mesh of Udine to which B is connected.

There could be many other routes, but we'll ignore them for now.

B could have published his address as <pubkey-B>?hint=<pubkey-Ud>,<pubkey-Ve>,<pubkey-Sm>,<pubkey-Ro>, which would mean A would only have to know a route from Ev up to Ro.

If Ro is known to be a big router, A could easily have a route cached there, and could discover other routes by asking around every now and then too. It wouldn't take a lot of space to have routes cached to some thousands of different known big nodes like that. Then A can just wrap an onion with all the coordinates and the message inside and hand it to Ev and it would reach B. Inside the message she would also include the full route for a message to be sent back.

However, even if A doesn't have a route to Ro, it could still hope that Li would have, then she could make a special "trampoline" onion that goes Ev--Li and then when Li receives it it sees a request to forward the next packet to Ro, so Li has the freedom to choose a route from itself to Ro (as long as it knows Ro, of course) and from there A's message continues.

The same trampolining can exist on B's side, if B doesn't have a route from Ud to Ro, but knows Ro is likely to have one up to Ud -- or if B feels it's not worth including so many hints when most big nodes will have routes to Ud, for example, it can publish his address as <pubkey-B>?hint=<pubkey-Ud>*<pubkey-Ro> meaning that one should find a route up to Ro and from there ask Ro to trampoline it up to Ud.

Or, if B doesn't expect Ud to be very well-known, but Sm yes, then it could do <pubkey-B>?hint=<pubkey-Ud>,<pubkey-Sm>*<pubkey-Ro>. Again, this is just one hint, in practice it would have to have a lot (maybe 10, 20?) other hints, in a tree structure that this querystring syntax isn't very suited for encoding:

Ud
  Tr
    Pu
      Za
    Li

  Sm
    *
      Ro
      Ba
  Mi
    La
      Ge
    *
      Mo
    Tu

(Remember, we're using city name abbreviations here, but each of these would be a specific node, with a specific public key, supposed for the example to be in such a city, but nothing prevents them from being in different cities or that multiple nodes exist in the same city.)

Summary

Basically packets go from node to node, in a sequence established by the sender -- with optional trampolines in between -- until they get to the target. Target responds in the same route. Nodes can be anyone. Focal points form around big nodes, but they can be replaced easily, the receivers just have to stop using them in their hints, so the network is flexible and open.

ION is a DID method based on a thing called "Sidetree".

I can't say for sure what is the problem with ION, because I don't understand the design, even though I have read all I could and asked everybody I knew. All available information only touches on the high-level aspects of it (and of course its amazing wonders) and no one has ever bothered to explain the details. I've also asked the main designer of the protocol, Daniel Buchner, but he may have thought I was trolling him on Twitter and refused to answer, instead pointing me to an incomplete spec on the Decentralized Identity Foundation website that I had already read before. I even tried to join the DIF as a member so I could join their closed community calls and hear what they say, maybe eventually ask a question, so I could understand it, but my entrance was ignored, then after many months and a nudge from another member I was told I had to do a KYC process to be admitted, which I refused.

One thing I know is:

• ION is supposed to provide a way to rotate keys seamlessly and automatically without losing the main identity (and the ION proponents also claim there are no "master" keys because these can also be rotated).
• ION is also not a blockchain, i.e. it doesn't have a deterministic consensus mechanism and it is decentralized, i.e. anyone can publish data to it, doesn't have to be a single central server, there may be holes in the available data and the protocol doesn't treat that as a problem.
• From all we know about years of attempts to scale Bitcoins and develop offchain protocols it is clear that you can't solve the double-spend problem without a central authority or a kind of blockchain (i.e. a decentralized system with deterministic consensus).
• Rotating keys also suffer from the double-spend problem: whenever you rotate a key it is as if it was "spent", you aren't supposed to be able to use it again.

The logic conclusion of the 4 assumptions above is that ION is flawed: it can't provide the key rotation it says it can if it is not a blockchain.

See also

• Excerpt of discussion about DIDs and ION

I check my emails like once or twice a week, always when I am looking for something specific in there.

Then I go there and I see a bunch of other stuff I had no idea I was missing. Even many things I wish I had seen before actually. And sometimes people just expect and assume I would have checked emails instantly as they arrived.

It's so weird because I'm not making a point, I just don't remember to open the damn "gmail.com" URL.

I remember some people were making some a Nostr service a while ago that sent a DM to people with Nostr articles inside -- or some other forms of "subscription services on Nostr". It makes no sense at all.

Pulling in DMs from relays is exactly the same process (actually slightly more convoluted) than pulling normal public events, so why would a service assume that "sending a DM" was more likely to reach the target subscriber when the target had explicitly subscribed to that topic or writer?

Maybe due to how some specific clients work that is true, but fundamentally it is a very broken assumption that comes from some fantastic past era in which emails were 100% always seen and there was no way for anyone to subscribe to someone else's posts.

Building around such broken assumptions is the wrong approach. Instead we should be building new flows for subscribing to specific content from specific Nostr-native sources (creators directly or manual or automated curation providers, communities, relays etc), which is essentially what most clients are already doing anyway, but specifically Coracle's new custom feeds come to mind now.

This also reminds me of the interviewer asking the Farcaster creator if Farcaster made "email addresses available to content creators" completely ignoring all the cryptography and nature of the protocol (Farcaster is shit, but at least they tried, and in this example you could imagine the interviewer asking the same thing about Nostr).

I imagine that if the interviewer had asked these people who were working (or suggesting) the Nostr DM subscription flow they would have answered: "no, you don't get their email addresses, but you can send them uncensorable DMs!" -- and that, again, is getting everything backwards.

A violência é uma forma de comunicação: um serial killer, um pai que bate no filho, uma briga de torcidas, uma sessão de tortura, uma guerra, um assassinato passional, uma briga de bar. Em todos esses se pode enxergar uma mensagem que está tentando ser transmitida, que não foi compreendida pelo outro lado, que não pôde ser expressa, e, quando o transmissor da mensagem sentiu que não podia ser totalmente compreendido em palavras, usou essa outra forma de comunicação.

Quando uma ofensa em um bar descamba para uma briga, por exemplo, o que há é claramente uma tentativa de uma ofensa maior ainda pelo lado do que iniciou a primeira, a briga não teria acontecido se ele a tivesse conseguido expressar em palavras tão claras que toda a audiência de bêbados compreendesse, o que estaria além dos limites da linguagem, naquele caso, o soco com o mão direita foi mais eficiente. Poderia ser também a defesa argumentativa: "eu não sou um covarde como você está dizendo" -- mas o bar não acreditaria nessa frase solta, a comunicação não teria obtido o sucesso desejado.

A explicação para o fato da redução da violência à medida em que houve progresso da civilização está na melhora da eficiência da comunicação humana: a escrita, o refinamento da expressão lingüística, o aumento do alcance da palavra falada com rádio, a televisão e a internet.

Se essa eficiência diminuir, porque não há mais acordo quanto ao significado das palavras, porque as pessoas não estão nem aí para se o que escrevem é bom ou não, ou porque são incapazes de compreender qualquer coisa, deve aumentar proporcionalmente a violência.

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

While reading the following paragraphs, assume Drivechain itself will be a "smart contract platform", like Ethereum. And that it won't be used to launch an Ethereum blockchain copy, but instead each different Ethereum contract could be turned into a different sidechain under BIP300 rules.

A big Ethereum problem

Anyone can publish any "contract" to Ethereum. Often people will come up with somewhat interesting ideas and publish them. Since they want money they will add an unnecessary token and use that to bring revenue to themselves, gamify the usage of their contract somehow, and keep some control over the supposedly open protocol they've created by keeping a majority of the tokens. They will use the profits on marketing and branding, have a visual identity, a central website and a forum with support personnel and so on: their somewhat interesting idea have become a full-fledged company.

If they have success then another company will appear in the space and copy the idea, launch it using exactly the same strategy with a tweak, then try to capture the customers of the first company and new people. And then another, and another, and another. Very often these contracts require some network effect to work, i.e., they require people to be using it so others will use it. The fact that the market is now split into multiple companies offering roughly the same product hurts that, such that none of these protocols get ever enough usage to become really useful in the way they were first conceived. At this point it doesn't matter though, they get some usage, and they use that in their marketing material. It becomes a race to pump the value of the tokens and the current usage is just another point used for that purpose. The company will even start giving out money to attract new users and other weird moves that have no relationship with the initial somewhat intereting idea.

Once in a lifetime it happens that the first implementer of these things is not a company seeking profits, but some altruistic developer or company that believes in Ethereum and wants to see it grow -- or more likely someone financed by the Ethereum Foundation, which allegedly doesn't like these token schemes and would prefer everybody to use the token they issued first, the ETH --, but that's a fruitless enterprise because someone else will copy that idea anyway and turn it into a company as described above.

How Drivechain fixes it

In the Drivechain world, if someone had an idea, they would -- as it happens all the time with Bitcoin things -- publish it in a public forum. Other members of the community would evaluate that idea, add or remove things, all interested parties would contribute to make it the best possible incarnation of that idea. Once the design was settled, someone would volunteer to start writing the code to turn that idea into a sidechain. Maybe some company would fund those efforts and then more people would join. It's not a perfect process and one that often involves altruism, but Bitcoin inspires people to do these things.

Slowly, the thing would get built, tested, activated as a sidechain on testnet, tested more, and at this point luckily the entire community of interested Bitcoin users and miners would have grown to like that idea and see its benefits. It could then be proposed to be activated according to BIP300 rules.

Once it was activated, the entire pool of interested users would join it. And it would be impossible for someone else to create a copy of that because everybody would instantly notice it was a copy. There would be no token, no one profiting directly from the operations of that "smart contract". And everybody would be incentivized to join and tell others to join that same sidechain since the network effect was already the biggest there, they will know more network effect would only be good for everybody involved, and there would be no competing marketing and free token giveaways from competing entities.

See also

• Upgrading 'Smart Contracts' to 'Wise Contracts', by Paul Sztorc
• Drivechain
• Drivechain comparison with Ethereum
• Alternatives to Drivechain

Basically, there are basically (not exhaustively) 2 kinds of programs one can run in a computer nowadays:

1.1. A program that is installed, permanent, has direct access to the Operating System, can draw whatever it wants, modify files, interact with other programs and so on; 1.2. A program that is transient, fetched from someone else's server at run time, interpreted, rendered and executed by another program that bridges the access of that transient program to the OS and other things.

Meanwhile, web browsers have basically (not exhaustively) two use cases:

2.1. Display text, pictures, videos hosted on someone else's computer; 2.2. Execute incredibly complex programs that are fetched at run time, executed and so on -- you get it, it's the same 1.2.

These two use cases for browsers are at big odds with one another. While stretching itsel f to become more and more a platform for programs that can do basically anything (in the 1.1 sense) they are still restricted to being an 1.2 platform. At the same time, websites that were supposed to be on 2.1 sometimes get confused and start acting as if they were 2.2 -- and other confusing mixed up stuff.

I could go hours in philosophical inquiries on the nature of browsers, how rewriting everything in JavaScript is not healthy or where everything went wrong, but I think other people have done this already.

One thing that bothers me a lot, though, is that computers can do a lot of things, and with the internet and in the current state of the technology it's fairly easy to implement tools that would help in many aspects of human existence and provide high-quality, useful programs, with the help of a server to coordinate access, store data, authenticate users and so on many things are possible. However, due to the nature of UI in the browser, it's very hard to get any useful tool to users.

Writing a UI, even the most basic UI imaginable (some text input boxes and some buttons, or a table) can take a long time, always more than the time necessary to code the actual core features of whatever program is being developed -- and that is considering that the person capable of writing interesting programs that do the functionality in the backend are also capable of interacting with JavaScript and the giant amount of frameworks, transpilers, styling stuff, CSS, the fact that all this is built on top of HTML and so on.

This is not good.

The most simple, but still useful, command line app. Done just because I was bored someday.

From the GitHub README:

~> go get github.com/fiatjaf/howoldis
~> howoldis github.com
github.com is available at least since May 2008, 10 years ago.
~> howoldis github.com/fiatjaf
github.com/fiatjaf is available at least since Jun 2015, 3 years ago.

howoldis fetches data from the Wayback Machine to quickly tell you how old a website is.

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

The firm doesn't exist because, like Coase said, it is inefficient to operate in a fully open-market and production processes need some bubbles of central planning.

Instead, what happens is that a firm is created because an entrepreneur is doing a new thing (and here I imagine that doing an old thing in a new context also counts as doing a new thing, but I didn't read his book), and for that new thing there is no market, there are no specialized workers offering the services needed, nor other businesses offering the higher-order goods that entrepreneur wants, so he must do all by himself.

So the entrepreneur goes and hires workers and buys materials more generic than he wanted and commands these to build what he wants exactly. It is less efficient than if he could buy the precise services and goods he wanted and combine those to yield the product he envisaged, but it accomplishes the goal.

Later, when that specific market evolves, it's natural that specialized workers and producers of the specific factors begin to appear, and the market gets decentralized.

A service that grabs code samples from two chosen languages on RosettaCode and displays them side-by-side.

The code-fetching is done in real time and snippet-by-snippet (there is also a prefetch of which snippets are available in each language, so we only compare apples to apples).

This was my first Golang web application if I remember correctly.

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

Every person is either in the left or in the right. You can see it by the way they do they manage their lives and their families.

"Libertarianism" is not in that same category, because you can't manage your life or your family in a libertarian way. Libertarianism is a purely political idea, it only applies to what the State can do or if it should exist or not, nothing else.

People who are from the left or from the right can be libertarian. People from these two camps can also not be libertarian, and then their political goals and ideals would be just an extrapolation of their views on family management. They will see the State as the big father, an image inherit from the media and other people, and go with it: if the State is the father of our big family, it should behave in regards to his children, the citizens, just like I would behave in regards to my children.

Related

• https://www.bobmurphyshow.com/episodes/ep-159-gregory-gordon-on-left-vs-right-libertarianism/
• https://mises.org/wire/why-theres-left-right-divide-among-libertarians

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.

The precautionary principle that people, including Nassim Nicholas Taleb, love and treat as some form of wisdom, is actually just a justification for arbitrary acts.

In a given situation for which there's no sufficient knowledge, either A or B can be seen as risky or precautionary measures, there's no way to know except if you have sufficient knowledge.

Someone could reply saying, for example, that the known risk of A is tolerable to the unknown, probably magnitudes bigger, risk of B. Unless you know better or at least have a logical explanation for the risks of B (a thing "scientists" don't have because they notoriously dislike making logical claims), in which case you do know something and is not invoking the precautionary principle anymore, just relying on your logical reasoning – and that can be discussed and questioned by others, undermining your intended usage of the label "precautionary principle" as a magic cover for your actions.

Like Gravatar, but using profile images from websites tagged with "microformats-2" tags, like people from the indiewebcamp movement liked. It falled back to favicon, gravatar and procedural avatar generators.

No one really used this, despite people saying they liked it. Since I was desperate to getting some of my programs appreciated by someone I even bought a domain. It was sad, but an enriching experience.

• https://github.com/fiatjaf/webvatar.com
• http://webvatar.com

See also

• jekmentions
• questo.email

• No primeiro semestre da faculdade de Economia nós, os alunos, fomos guiados por um livro imbecil chamado "Introdução à Economia". O livro listava lá trocentas coisas que economistas supostamente faziam como parte da sua natureza de economistas. Uma delas era, lembro-me desta frase, "economistas pensam na margem".
• De início eu não entendi onde era essa margem, mas a professora passou quase uma aula inteira explicando (isto é, lendo o capítulo) que "pensar na margem" era considerar que pequenas mudanças nas condições de qualquer coisa causariam mudanças em pequenos grupos de pessoas: as pessoas que estavam na margem da mudança.
• Por exemplo, se um limão custa 5 reais e 100.000 pessoas compram limão todo dia, se aumentamos o preço para 5,05 pode ser que, sei lá, só 99.873 continuem comprando. Faz sentido, não faz? Isto era tão óbvio para mim no primeiro período de faculdade que não imaginei que alguém precisasse explicar, por isso não percebi qual era a da margem.
• Até hoje, porém, vejo pessoas o tempo todo afirmarem categoricamente que o "cinco centavos não vão fazer diferença nenhuma, as pessoas vão continuar comprando o limão como sempre compraram" e invocando em defesa desta tese argumentos perfeitamente lógicos como "até parece que você ia deixar de comprar seu limão por causa de 5 centavos", "eu nem olho o preço das coisas no supermercado" e "as pessoas precisam do limão, então elas vão ter que comprar, não importa o preço".
• Muitas destas pessoas entenderão a explicação sobre a margem, mas na próxima oportunidade que tiverem falharão em perceber a analogia ou em se lembrarem da margem e novamente evocarão os seus chavões. Para outras pessoas, porém, o pensamento na margem faz parte do bom senso habitual.
• Tirando fora a inútil conclusão de que a maior parte das pessoas é burra, sobra-nos um problema.
• Discussão
  • Estaria o autor do livro, contra sua própria vontade, enunciando uma verdade acerca dos tipos de pessoas que povoam a sociedade, "os economistas", que são economistas desde o berço, e que "pensam na margem" por natureza, contra "o resto", os não-economistas, que não pensam na margem, não importa o que se faça?
    • Esta é uma solução bem mixuruca. Nem é uma solução, na verdade, além disto ela deixa escapar um outro problema: por que diabos um sujeito que não consegue entender o problema do limão se candidata a um diploma de economista?
    • Bom, talvez aqui a hipótese da burrice generalizada explique bem as coisas: aparentemente a burrice que há nas universidades, no valor dos diplomas, na natureza da escola e em sua relação com as universidades faça com que jovens sejam despejados em qualquer curso sem terem noção nenhuma do que eles mesmos esperam que se dê lá. Ei-lo.
  • Há algum outro mistério aqui? O bom senso (enquanto um conhecimento apreendido dos meus vizinhos de sociedade) me ensinou a pensar na margem, ou não? Onde eu aprendi isso? Por que eu penso assim e o meu vizinho não?
    • Imagino que Bernard Lonergan responderia dizendo que os economistas são pessoas que tiveram esse insight e as outras pessoas não. Para as que tiveram o insight ele aparece já como uma obviedade, para os que não tiveram ele não é nem percebido como possibilidade (do contrário ele se efetuaria automaticamente como insight).
    • Neste caso, o que explica que pessoas entendam o caso do limão, caso se lhas explique com calma, mas falhem em aplicá-lo, minutos depois, a laranjas?
    • Há casos de economistas famosos e premiados que não conseguem conceber, por exemplo, que o aumento do salário mínimo possa fazer com que menos pessoas contratem funcionários -- na margem. Estes mesmos economistas passariam facilmente no teste do limão. Paul Krugman é um exemplo clássico de pessoa definitivamente "economista" (pelo critério do limão), mas que falha na aplicação do mesmo princípio a situações em que ele tem interesse político.
      • Aqui caímos num outro problema totalmente diferente, mas talvez a dissonância cognitiva explique.
    • Falha na aplicação de analogias não é um defeito, segundo me parece. Afinal de contas cada nova aplicação de uma analogia ou de relação previamente conhecida é, em si, um novo insight. O insight pode não ocorrer facilmente em certas condições. Mas, nestes casos, imagino que com algum auxílio (alguém que te lembre da analogia correta a ser aplicada ali, fazendo com que você a teste por si mesmo) o insight ocorra.
  • Também posso considerar que eu estou errado e que é ilógico pensar que cinco centavos farão com que menos pessoas comprem o limão. Há centenas de estudos "empíricos" que mostram como "pensar na margem" é correto, mas estes estudos são todos inconclusivos, ou afetados por dissonância cognitiva por parte dos autores, economistas, que já começaram a fazer o estudo sabendo da conclusão. Tudo isto parece razoável. Tenho para mim, no entando, que não é nada razoável, mas um absurdo louco.

I heard about this epistemological method conjecture and criticism in this video. Oddly, it was portrayed as something that goes against the Austrian method by Paul Sztorc, while the other guy, JW Weatherman, was championing the "praxeological" method of pure logical deduction from first principles as the basis of all economic knowledge.

It has always seemed to me that this pure logical reasoning was somewhat weird, specially in light of Carl Menger's empiricism (which is not the same empiricism from modern sciences).

Conjecture and criticism seems to fit better with Menger's method and whatever Austrians actually do. No one really reasons with pure logical deduction. What people do is spot something in the real world and try to come up with a reasonable explanation that is logically consistent. The entire logical impenetrability of every Austrian theory comes after the theory is conceived (conjected?) by a human mind, not -- like some praxeological claims would imply -- deducted as if by a computer.

• A Causa

Using the lnurl-allowance protocol, a website could instead of putting a paywall over the entire site, charge a reader for only the paragraphs they read. Of course this requires trust from the reader on the website, but this is normal. The website could just hide the rest of the article before an invoice from the paragraph just read was paid.

This idea came from Colin from the Unhashed Podcast.

Could also work with podcasts and videos.

• About CouchDB
• my personal approach on using let, const and var in javascript
• A crappy course on torrents
• Multi-service Graph Reputation protocol
• The monolithic approach to CouchDB views
• My stupid introduction to Haskell
• The unit test bubble
• There's a problem with using Git concepts for everything
• On the state of programs and browsers
• Rust's .into() is a strictly bad thing

um processo, é, essencialmente, imagino eu na minha ingenuidade leiga, um apelo que se faz ao juiz para que este reconheça certos fatos como probantes de um certo fenômeno tipificado por uma certa lei.

imagino então o seguinte:

uma petição não é mais um enorme documento escrito numa linguagem nojenta com referências a leis e a evidências factuais espalhadas segundo a (in) capacidade ensaística do advogado, mas apenas um esquema lógico - talvez até um diagrama desenhado (ou talvez quem sabe uma série de instruções compreensíveis por um computador?) - mostrando a ligação entre a lei e os fatos e os pedidos, por exemplo:

1. a lei tal diz que ninguém pode vender
2. fulano vendeu cigarros
3. é prova de que fulano vendeu cigarros ia foto tirada na rua tal no dia tal que mostra fulano vendendo cigarros
4. a mesma lei pede que fulano pague uma multa

este exemplo está ainda muito verborrágico, mas é só um exemplo simples. coisas mais complicadas precisariam de outras formas de expressão caso queiramos evitar as longas dissertações jurídicas em voga.

a idéia é que o esquema acima vale por si. um proto-juiz pode julgá-lo como válido ou inválido apenas pela sua lógica interna.

a outra parte do julgamento seria a ligação desse esquema com a realidade externa: anexados à petição viriam as evidências. no caso, anexada ao ponto 3 viria uma foto do fulano. ao ponto 1 também precisa ser anexado o texto da lei referida, mas isto pode ser feito automaticamente pelo número da lei.

uma vez que tenhamos um esquema lógico válido um outro proto-juiz, ou vários outros, pode julgar individualmente cada evidência: ver se o texto da lei confere com a interpretação feita no ponto 1, e se a foto anexada ao ponto 3 é mesmo a foto do réu vendendo cigarro e não a de um urso comendo laranjas.

cada um desses julgamentos pode ser feito sem que o proto-juiz tenha conhecimento do resto das coisas do processo: o primeiro proto-juiz não precisa ver a foto ou a lei, o segundo não precisa ver o esquema lógico ou a foto, o terceiro não precisa ver a lei nem o esquema lógico, e mesmo assim teríamos um julgamento de procedência ou não da petição ao final, o mais impessoal e provavelmente o mais justo possível.

a defesa consistiria em apontar erros no esquema lógico ou falhas no nexo entre a realidade é o esquema. por exemplo:

1. uma foto assim não é uma prova de que fulano vendeu, ele podia estar só passando lá perto.
   • ele estava de fato só passando lá perto. do que é prova este documento mostrando seu comparecimento a uma aula do curso de direito da UFMG no mesmo horário.

perdoem-me se estiver falando besteira, mas são 5h e estou ainda dormindo. obviamente há vários pontos problemáticos aí, e quero entendê-los, mas a forma geral me parece bem razoável.

o que descrevi acima é uma proposta, digamos, de sistema jurídico que não se diferencia em nada do nosso sistema jurídico atual, exceto na forma (não no sentido escolástico). é também uma tentativa de compreender sua essência.

as vantagens desse formato ao atual são muitas:

• menos papel, coisas pra ler, repetição infinita de citações legais e longuíssimas dissertações escritas por advogados analfabetos que destroem a língua e a inteligência de todos
• diminuição drástica do tempo gasto por cada juiz em cada processo
• diminuição do poder de cada juiz (se cada ato de julgamento humano necessário em cada processo pode ser feito por qualquer juiz, sem conhecimento dos outros aspectos do mesmo processo, tudo é muito mais rápido, e cada julgamento desses pode ser feito por vários juízes diferentes, escolhidos aleatoriamente)
• diminuição da pomposidade de casa juiz: com menos poder e obrigações maus simples, um juiz não precisa ser mais uma pessoa especial que ganha milhões, pode ser uma pessoa comum, um proto-juiz, ganhando menos (o que possibilitaria até ter mais desses e aumentar a confiabilidade de cada julgamento)
• os juízes podem trabalhar da casa deles e a qualquer momento
• passa a ter sentido a existência de um sistema digital de processos (porque é ridículo que o sistema digital atual seja só uma forma de passar documentos do Word de um lado para o outro)
• o fim das audiências de conciliação, que são uma monstruosidade criada apenas pela necessidade de diminuir a quantidade de processos em tramitação e acabam retirandobo sentido da justiça (as partes são levemente pressionadas a ignorar a validade ou não das suas posições e fazer um acordo, sob pena de o juiz ficar com raiva delas depois)

milhares de precauções devem ser tomadas caso um sistema desses vá ser implantado (ahahah), talvez manter uma forma de julgamento tradicional, de corpo presente e com um juiz ou júri que tem conhecimento de toda situação, mas apenas para processos que chegarem até certo ponto, e assim por diante.

Ver também

• P2P reputation thing para um fundamento de um sistema jurídico anárquico.

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.

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.

Basically instead of a subscription and becoming member of something, you just get a forum for your inner circle and people get lnurl-pay codes they can use to donate. Some amount of donations is required to remain in the group (like x per month), but if you donate more than that on the beginning you can stay until your credits expire.

Every time someone donates a notice is posted in the group page.

Perhaps that could be an @lntxbot feature.

Inspired by Bob Murphy's thesis against the "pure time preference theory" (see also this series of podcasts) -- or blatantly copying it -- here are some thoughts on Mises' most wrong take:

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

No service wants to keep users balances forever or "become a custodian", as that may have some complications dependending on who is doing it.

But the sad truth is that there is no way to do automatic payouts to users on the Lightning Network. So if you're running a marketplace or a game of some kind that takes sats from some users, does something, then sends sats out to other users, you must keep a table with balances for each user.

-- But I can ask for a Lightning Address!

No, you can't, because mobile users of noncustodial wallets do not have those things generally, and that's not the purpose of Lightning Addresses anyway. Well, of course you can, but what I'm trying to say is that you shouldn't, as that is an anti-practice that will cause people to not want to use your service or force them into custodial providers -- which may be ok for them, but may not be.

-- So if I ignore the concerns above I can do this with Lightning Addresses, right?

Not really, because payments can fail. The user might input an invalid Lightning Address, or the Lightning Address may stop working after a while. Or even if it is working and online your payout can still fail for many reason inherent to Lightning.

That means you need to keep a table of balances for your users anyway. It doesn't matter.

Since you are already keeping a table of balances, now it's your chance to bring back the mobile noncustodial wallet users into a greater standard that accomodates everybody: LUD-14.

Wallets can implement LUD-14 support and then be made to withdraw balances from your service automatically every time they're turned on or periodically or upon manual request from the user. That limits the amount of user balance you'll have to keep on your service (but you can also add more rules around that, for example, automatically confiscating balances that stay parked too long, or putting a hard limit on the balance size for each user).

-- But with Lightning Addresses I can do instant payouts!

Yes, you can, but that's why LUD-15 exists: for all custodial providers, noncustodial wallets that rely on some kind of friendly server or coordinator (like Breez, Blixt or Phoenix) or even noncustodial providers running some kind of homemade server, you can dispatch these requests that cause them to withdraw the money automatically, which makes the experience similar to instant payouts -- and better, since then the payment requests can be more meaningful and say they are withdrawals from your service instead of saying that you're donating money to them (which is what most Lightning Address payments really mean).

When someone created jiq claiming it had "jq queries" I went to inspect and realized it didn't, it just had a poor simple JSON query language that implemented 1% of all jq features, so I forked it and plugged jq directly into it, and renamed to jiq.

After some comments on issues in the original repository from people complaining about lack of jq compatibility it got a ton of unexpected users, was even packaged to ArchLinux.

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

The United States population (counting only people more than 25 years old) is 222098080 people, the United States GDP is 20807000000000 USD. The Federal government has received 5845968000000 in taxes in 2019.

The standard UBI plan (from Andrew Yang) is to give $1000 to each person every month, which means a total annual expenditure of 2665176960000 USD, or 12.81% of the GDP and 45.59% of all tax money received from the federal government.

Mandatory spending (which includes healthcare and social security) corresponds to $2.7 trillion, or 46.18% of annual receipts. Discretionary spending (which includes education and military stuff) corresponds to $1.3 trillion, or 22.23% of annual receipts.

Does it fit?

If you are capable of cutting more-or-less all spending in social security (17.10% of federal receipts), all military (11.56%), all education, transportation, housing, veterans benefits and most other things the federal government does (11.30%) and parts of Medicare and Medicaid (26.17%) then it will be possible to fit UBI.

Welcome to the leftist paradise, one in which the government budget has to be drastically cut in every possible (cruel?) way.

Data sources

• https://en.wikipedia.org/wiki/United_States
• https://en.wikipedia.org/wiki/Demographics_of_the_United_States#Structure
• https://en.wikipedia.org/wiki/Government_spending_in_the_United_States
• https://www.bea.gov/tools/
• https://www.pbs.org/newshour/politics/how-would-andrew-yang-give-americans-1000-per-month-with-this-tax

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

A website that allowed people to fill a form and get a standard Contrato de Locação.

Better than all the other "templates" that float around the internet, which are badly formatted .doc files.

It was fully programmable so other templates could be added later, but I never did. This website made maybe one dollar in Google Ads (and Google has probably stolen these like so many other dollars they did with their bizarre requirements).

• https://github.com/fiatjaf/contratos
• http://contratos.alhur.es

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¹ and the binary releases that will be downloaded by thousands;
2. Bitcoin Core is susceptible to social attacks;
3. "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

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

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.

As palavras que Thafne teve que soletrar: "ocioso", "hermético", "glossário", "argênteo", "morfossintaxe", "infra-hepático", "hagiológio". Enquanto isso Eder recebia: "intramuscular", "destilação", "inabitável", "subcutâneo", "homogeneidade", "predecessor", "displicência", "subconsciência", "psicroestesia" (isto segundo o site da folha, donde certamente faltam algumas palavras de Thafne). Sério, "argênteo"? Não é errado dizer que a Globo tentou promover o menino pobre da escola pública do sertão contra a riquinha de Curitiba.

O mais espetacular disto é que deu errado e o Brasil inteiro torceu pela Thafne, o que se verifica com uma simples busca no Google. Eis aqui alguns exemplos:

• O problema de Thafne traz comentários tentando incriminar o governo do Estado de Minas Gerais com a vitória forçada de Eder.
• este vídeo mostrando os erros do programa e a vitória triunfal, embora parcial, de Thafne, traz a brilhante descrição "globo de puleira quis complicar a vida da menina!!!!!!!!!!!!!!!!!!!!!!"
• este vídeo, com o mesmo conteúdo,, porém chamado "Thafne versus Luciano Huck, o confronto do século", tem, além disto, vários comentários de francos torcedores de Thafne:
  • "Nossa isso é burrice porq o doutor falou duas vezes como o luciano não prestou atenção logo thafine deu duas patadas no luciano... Proxima luciano presta atenção na pronuncia"
  • "ele nao pronunciou errado porque é burro, isso foi pra manipular o resultado"
  • "Gabriel o Bostador ficou pianinho. Babaca do krl"
  • "Pena que ela perdeu :("
  • "verdade... ela que ganhou, o outro só ficou com o título :S"
  • "A menina deu um banho nesse que além de idiota é BURRO."
  • e muitos, muitos outros.
• Globo Erra e Luciano Huck dá Vexame, um breve artigo descrevendo alguns dos pontos em que Eder foi favorecido.
• esta comunidade do Orkut, apenas a maior dentre várias que foram criadas.

O movimento de apoio a Thafne é um exemplo entre poucos de união total da nação em prol de uma causa.

"Templates as a service", or "temperaas", changed to "temperos" later because it was a nice pun in Portuguese.

The ideas was that it would take an URL with any file and some querystring parameters, then replace {{paramName}} with the parameters from the querystring and serve it, all stateless.

Created to make it easy for people to embed scripts on Websites For Trello (but of course it was too hard for most people).

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

Pensando sobre como o Google poderia implementar uma solução "pure software" para o problema dos programinhas de carona paga -- já que agora parece que o Waze vai virar tipo um Uber -- me vi pensando em que poderia haver punições bastante severas e para-legais para infratores dos regulamentos internos do serviço.

Digamos, por exemplo, que é proibido pelas regras do serviço que o motorista ou o passageiro agridam um ao outro de qualquer maneira. Para ser qualificado como um potencial usuário, tanto o motorista quanto o passageiro devem ser usuários de longa data dos serviços do Google, possuir um email no Gmail com trocentas mensagens sendo recebidas e enviadas todos os dias, um enorme arquivo, coisas guardadas no Google Drive e/ou outros serviços do Google sendo usados. Caso o sujeito agrida o motorista, roube-o ou faça qualquer outra coisa não-permitida, o Google pode, imediatamente, cancelar seu acesso a todos os serviços. Depois, com mais calma, pode-se tentar alguma coisa por meio da justiça estatal, mas essa punição seria tão imediata e tão incondicional (bom, poderia haver um julgamento interno dentro do Google para avaliar o que aconteceu mesmo, mas pronto, nada de milanos na justiça penal e depois uma punição fajuta qualquer.)

Esse tipo de punição imediata já desencorajaria a maioria dos infratores, imagino eu. É a própria idéia anarquista da punição por ostracismo. O cara fica excluído da sociedade até que a sociedade (neste caso, o Google) decida perdoá-lo por qualquer motivo. A partir daí é possível imaginar que os outros vários "silos" deste mundo -- Facebook, Vivo, Diamond Mall, SuperNosso -- possam também aderir, caso concordem com o julgamento do Google, e vice-versa, e também impedirem o infrator de usar os seus serviços.

Mas o grande tchans disto aqui é que esse processo pode começar com um único agente, desde que ele seja grande o suficiente para que a sua ostracização, sozinha, já seja uma punição quase suficiente para o infrator.

Instead of uploading the dropped files to an URL, this subclass of Dropzone.js publishes them to IPFS with js-ipfs (no running local nodes needed).

• https://github.com/fiatjaf/ipfs-dropzone

See also

• How IPFS is broken

A CLI tool for generating fulltext indexes and using them to query files later based on a library called whoosh¹.

I made this to help me search my git-annex files, but never really used it.

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

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

A idéia de ficar dentro duma dessas penitenciárias superlotadas é aterrorizante para qualquer cidadão de bem, logo, nenhum cidadão de bem comete crimes puníveis dessa maneira. Mas os cidadãos de bem já não os cometeriam de qualquer modo, é um outro tipo de gente, que não o cidadão de bem, que comete os piores crimes (não quero dizer que o "cidadão de bem" é melhor do que o outro absolutamente, estou só usando um conceito mais-ou-menos identificável).

O problema disso é que todos esses mesmos cidadãos de bem imaginam que a existência da cadeia e da punição-padrão movida pelo Estado afasta do crime milhões de pessoas que, sem isso, cometeriam crimes horríveis, mas que com isso vivem vidas normais.

A verdade, me parece, é que quem fica assim tão aterrorizado com a idéia da cadeia e da punição-padrão é a pessoa que já por natureza não cometeria esses crimes.

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.

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?

Content-addressability is cool and we all like it, but we all also know we can't live in a world without readable and memorizeable names. IPFS has proposed IPNS, the Interplanetary Name System (the names are very cool indeed), since its beggining (or maybe it was some months after the first IPFS idea, which would indicate this problem arrived as an afterthought).

It has been said IPNS would work in a manner similar to Git heads and branches (this was probably part of Juan Benet's marketing pitches that were immensely repeated in the first years, that IPFS was a mix between Torrents, Git and some other cool technology). This remains a distant promise, however. IPNS has been, for the last years, a very slow, unrecommended by their own developers and unusable way of addressing content that is basically just a pointer from a public key to an object hash.

Recommendations fall on using a domain and dnslink, the way to tell IPFS nodes you own a domain and that can be used to identify an object hash. That works, but it is not the wonder of decentralization that was promised, and still, it's just a pointer. Any key-value store, database of filesystem can do pointers.

Here I'm not saying, like tons of stupid people have on the internet, that IPFS should support dynamic links so we can build web apps on it. No, I would be pretty fine with just static links for static content, and continue to use the other internet protocols for things that needed to be dynamic.

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:

Não tenho acompanhado o futebol desde 2013 ou 2014, mas me parece que, como poderia ter sido previsto, o VAR tem favorecido os times pequenos ou marginais em detrimento dos demais.

É lógico: se os juízes favoreriam mais o Flamengo e o Corinthians, e depois os grandes de Rio e São Paulo, em detrimento dos demais, o VAR, por minimamente mais justo que seja, aparentará favorecer os outros.

• Viva o mata-mata

Since 2015 I have this idea of making one app that could be repurposed into a full-fledged app for all kinds of uses, like powering small businesses accounts and so on. Hackable and open as an Excel file, but more efficient, without the hassle of making tables and also using ids and indexes under the hood so different kinds of things can be related together in various ways.

It is not a concrete thing, just a generic idea that has taken multiple forms along the years and may take others in the future. I've made quite a few attempts at implementing it, but never finished any.

I used to refer to it as a "multidimensional spreadsheet".

Can also be related to DabbleDB.

If Drivechain doesn't get soft-forked into Bitcoin, the alternatives people are left with are:

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

Every time one person goes against Drivechain without proposing something else better, they're condemning bitcoiners to one or many of the above forever.

É razoável dizer que há três tipos de reações à menção do nome O que é Bitcoin? no Brasil:

1. A reação das pessoas velhas

Muito sabiamente, as pessoas velhas que já ouviram falar de Bitcoin o encaram ou como uma coisa muito distante e reservada ao conhecimento dos seus sobrinhos que entendem de computador ou como um golpe que se deve temer e do qual o afastamento é imperativo, e de qualquer modo isso não as deve afetar mesmo então para que perder o seu tempo. Essas pessoas estão erradas: nem o sobrinho que entende de computador sabe nada sobre Bitcoin, nem o Bitcoin é um golpe, e nem é o Bitcoin uma coisa totalmente irrelevante para elas.

É razoável ter cautela diante do desconhecido, no que as pessoas velhas fazem bem, mas creio eu que também muito do medo que essas pessoas têm vem da ignorância que foi criada e difundida durante os primeiros 10 anos de Bitcoin por jornalistas analfabetos e desinformados em torno do assunto.

1. A reação das pessoas pragmáticas

"Já tenho um banco e já posso enviar dinheiro, pra que Bitcoin? O quê, eu ainda tenho que pagar para transferir bitcoins? Isso não é vantagem nenhuma!"

Enquanto querem parecer muito pragmáticas e racionais, essas pessoas ignoram vários aspectos das suas próprias vidas, a começar pelo fato de que o uso dos bancos comuns não é gratuito, e depois que a existência desse sistema financeiro no qual elas se crêem muito incluídas e confortáveis é baseada num grande esquema chamado Banco Central, que tem como um dos seus fundamentos a possibilidade da inflação ilimitada da moeda, que torna todas as pessoas mais pobres, incluindo essas mesmas, tão pragmáticas e racionais.

Mais importante é notar que essas pessoas tão racionais foram também ludibriadas pela difusão da ignorância sobre Bitcoin como sendo um sistema de transferência de dinheiro. O Bitcoin não é e não pode ser um sistema de transferência de dinheiro porque ele só pode transferir-se a si mesmo, não pode transferir "dinheiro" no sentido comum dessa palavra (tenho em mente o dinheiro comum no Brasil, os reais). O fato de que haja hoje pessoas que conseguem "transferir dinheiro" usando o Bitcoin é uma coisa totalmente inesperada: a existência de pessoas que trocam bitcoins por reais (e outros dinheiros de outros lugares) e vice-versa. Não era necessário que fosse assim, não estava determinado em lugar nenhum, 10 anos atrás, que haveria demanda por um bem digital sem utilidade imediata nenhuma, foi assim por um milagre.

Porém, o milagre só estará completo quando esses bitcoins se tornarem eles mesmo o dinheiro comum. E aí assim será possível usar o sistema Bitcoin para transferir dinheiro de fato. Antes disso, chamar o Bitcoin de sistema de pagamentos ou qualquer coisa que o valha é perverter-lhe o sentido, é confundir um acidente com a essência da coisa.

1. A reação dos jovens analfabetos

Os jovens analfabetos são as pessoas que usam a expressão "criptos" e freqüentam sítios que dão notícias totalmente irrelevantes sobre "criptomoedas" o dia inteiro. Não sei muito bem como eles vivem porque não lhes suporto a presença, mas são pessoas que estão muito empolgadas com toda a "onda das criptomoedas" e acham tudo muito incrível, tão incrível que acabam se interessando e então comprando todos os tokens vagabundos que inventam. Usam a palavra "decentralizado", um anglicismo muito feio que deveria significar que não existe um centro controlador da moeda x ou y e que o seu protocolo continuaria funcionando mesmo que vários operadores saíssem do ar, mas como o aplicam aos tokens que são literalmente emitidos por um centro controlador com uma figura humana no centro que toma todas as decisões sobre tudo -- como o Ethereum e conseqüentemente todos os milhares de tokens ERC20 criados dentro do sistema Ethereum -- essa palavra não faz mais sentido.

Na sua empolgação e completo desconhecimento sobre como um ente nocivo poderia destruir cadauma das suas criptomoedas tão decentralizadas, ou como mesmo sem ninguém querer uma falha fundamental no protocolo e no sistema de incentivos poderia pôr tudo abaixo, sem imaginar que toda a valorização do token XYZ pode ter sido fabricada de caso pensado pelos seus próprios emissores ou só ser mesmo uma bolha, acabam esses jovens por igualar o token XYZ, ou ETH, BCH ou o que for, ao Bitcoin, ignorando todas as diferenças qualitativas e apenas mencionando de leve as quantitativas.

Misturada à sua empolgação, e como um bônus, surge a perspectiva de ficar rico. Se um desses por algum golpe de sorte surfou em alguma bolha como a de 2017 e conseguiu multiplicar um dinheiro por 10 comprando e vendendo EOS, já começa logo a usar como argumento para convencer os outros de que "criptomoedas são o futuro" o fato de que ele ficou rico. Não subestime a burrice humana.

Há jovens no grupo das pessoas velhas, velhas no grupo das pessoas jovens, pessoas que não estão em nenhum dos grupos e pessoas que estão em mais de um grupo, isso não importa.

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

A single, read/write open database for everything in the world.

• A hosted database that accepts anything you put on it and stores it in order.
• Anyone can update it by adding new stuff.
• To make sense of the data you can read only the records that interest you, in order, and reconstruct a local state.
• Each updater pays a fee (anonymously, in satoshis) to store their piece of data.
• It's a single store for everything in the world.

Cost and price estimates

Prices for guaranteed storage for 3 years: 20 satoshis = 1KB 20 000 000 = 1GB

https://www.elephantsql.com/ charges $10/mo for 1GB of data, 3 600 000 satoshis for 3 years

If 3 years is not enough, people can move their stuff to elsewhere when it's time, or pay to keep specific log entries for more time.

Other considerations

• People provide a unique id when adding a log so entries can be prefix-matched by it, like myapp.something.random
• When fetching, instead of just fetching raw data, add (paid?) option to fetch and apply a jq map-reduce transformation to the matched entries

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

It just makes the code unreadable for no gain.

Instead of defining methods with readable and meaningful names for transforming objects into other objects and calling those, the .into() bad practice just teaches everybody to write .into() everywhere, making the code impossible to read without a superpowered editor -- and sometimes even with it.

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

A programmable escrow for satoshis with self-contained stateful micro-apps defined with Lua anyone can create and call to deposit money while simultaneously changing their state.

Also known as "the centralized smart contract platform", in opposition to the supposedly "decentralized" Ethereum platform.

The "smart contracting" features of Etleneum are very similar to the ones on Ethereum.

• https://etleneum.com/
• https://www.coindesk.com/why-this-dev-built-a-centralized-ethereum-on-top-of-bitcoins-lightning-network

I always knew of at least two standardized ways browsers used to determine the charset of a given webpage document: the Content-Type header and the <meta charset> tag. These are widely understood, teached and documented specs that a lot of developers assume are being followed because they're "web standards".

Turns out there are a lot of pages on the internet that declare themselves as UTF-8 but are actually using other types of encoding (here's an example), and just by looking at the headers and meta tags you would think they are actually UTF-8, since they render correctly on Chromium and Firefox.

But the actual truth is that browsers actually ignore these headers completely and use their own internal heuristics to determine the actual charset. And they expose their internal result in the DOM property document.characterSet.

"Oh, that's great! Technology is awesome, they've fixed a problem!", you may think. But the actual result of that is:

1. developers never learn that they're wrongly declaring "UTF-8" when their content is actually "windows-1252" because they never see their page being rendered wrongly;
2. the actual spec is now that browsers should correctly guess a page encoding instead of just following what is written;
3. people are fooled and continue to teach, learn (and write) the falsehood of these useless HTTP headers and <meta> tags not knowing they are completely wrong.
4. new browsers coming to the space have to first learn that this is a thing, which is not obvious nor written anywhere, then they must implement it, because if they follow the spec people will think it is their fault that some broken pages are rendered with broken characters on this new browser;
5. barriers to entry are higher, the protocol continues to centralize more and more;
6. other people trying to read these HTML pages for whatever reason, from any software that isn't Google Chrome or Mozilla Firefox, will have the same problem and will have to learn everything and come up with their own charset detection mechanism, this again closes the content of webpages to being more and more restricted to the walled garden of existing browser vendors.

I think we can all agree these are not good outcomes.

In the end of things, this is just a very small example, but "the web" protocol has thousands of such small examples, and they add up.

Also, arguably the spec should have been "browsers must do their own charset detection" since the beginning, but that's irrelevant. The fact is that it wasn't (and still isn't, the specs weren't updated as far as I know), and here's again another undeniable example of how being flexible can bloat a protocol.

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.

In Keys are meaningless we hopefully made it clear that keys are not central to Nostr's idea, in fact keys are just an unnecessary burden that enables something much more important: relays.

The fact that one user, through their client, can reach out to a huge number of these servers hosted anywhere, and that each user can publish their stuff to any of them, from a modest server at his basement to a big cloud relay hosted by a big company, without anyone having to trust any of these: this is the core of the Nostr idea.

And the fact that Nostr relies on an open ecosystem of privately-owned relay servers is the only thing that ensures a proper incentive structure and gives it a chance of working: while other centralized platforms and protocols in the past -- even those that have tried to be very open and anti-censorship -- ended up struggling against what whom or what should be allowed to be published or not -- because after all they relied on a big common "global" pool of messages that had to be interpreted by apps.

That reliance kills the entire idea because at the very least someone has to host the content, and hosting that content has a cost, it has moral implications and also legal implications, so at some point someone, somewhere, has to make a decision to stop hosting some things, or restricting some users from publishing and so on, and there will never be a global agreement between all the peoples of the Earth about whom or what should be allowed and what should be disallowed. Even a rate-limit, IP blocking or other naïve measures that a server must necessarily take in order to survive on the internet, are a form of "censorship".

On Nostr none of that is a factor because each relay is independent of each other and there is no global pool of content, by definition. Because of that, and because it's the job of the readers to figure out from where to read, no relay has any obligations to please all the peoples of the Earth and is free to impose any limits or policies it wants.

Of course all of that breaks down if apps relinquish their obligation to figure out what relays to read from and decide to read from a static list of relays, but that should have gone without saying.

See also

• Constant's video explanation

Sei que o Atlético tem vários problemas. Sei que várias reclamações que vários atleticanos diferentes fazem têm fundamento e que os vários problemas do Atlético se misturam e fazem o time jogar mal, absurdamente mal, como jogou hoje contra o Internacional. Mas vou me dar o direito de ignorar todas os diversos tipos de falhas e problemas do Atlético e atribuir tudo de mau que nos aconteceu recentemente a um único elemento: Ricardinho. Breve história do campeonato atleticano O campeonato começou com o Atlético jogando bonito e vencendo com facilidade os inimigos, com um time leve, que passava a bola rápido, jogava no contra-ataque, um ataque rápido, toques rápidos ou enfiadas de bola dos volantes faziam com que Tardelli e Éder saíssem na cara do gol a todo instante e tudo era felicidade.

Mas aí vieram os problemas, aos poucos: o time não conseguia utilizar toda a sua rapidez contra adversários muito fechados. Dessa maneira veio o empate contra o Santo André, o empate com o Botafogo, o empate contra o Vitória, uma vitória suada contra o Fluminense (que jogou fechado no Mineirão), a derrota catastrófica para um Goiás que nem encostou na bola direito. E a derrota para o Flamengo no Maracanã.

Nessas, inventaram que o Atlético ia mal contra times fechados porque não sabia tocar a bola, tocar a bola de lado, "procurando um espaço", faltava ao Atlético, diziam, uma figura centralizadora, que parasse o jogo, parasse a correria, distribuisse com inteligência a bola, para que o Atlético furasse a defesa adversária com inteligência e paciência, e não com correria como vivia tentando. Inventaram isso, e começaram a acreditar - acho que todas as pessoas começaram a acreditar, inclusive o Celso Roth e eu mesmo.

E onde estava a solução: no camisa 10.

A paciência ricardiana

Jamais apreciei a idéia fixa que havia (e talvez, infelizmente, ainda haja) na cabeça da maioria dos torcedores do Atlético, de que um time só é bom quando tem um "camisa 10", cujas características são conhecidas por todos: tem o poder mágico de arrumar o meio-de-campo, dar criatividade ao time, lançar a bola e passá-la com plasticidade e leveza e resolver todos os problemas; mas cujos exemplos no futebol brasileiro e mundial são muito escassos. Essa fixação, creio eu, não é um fenômeno natural: é conseqüência direta do imbróglio Ziza-Gallardo do ano do centenário. Foi lá que inventaram esse negócio de camisa 10 e aí ficou nessa até recentemente (ou até agora). O próprio presidente do Atlético, Alexandre Kalil, disse em entrevista concedida antes de contratar Ricardinho que o único exemplo que era apontado quando se perguntava sobre quem poderia ser o tal camisa 10 que a torcida tanto queria era Ricardinho. Ricardinho, Ricardinho, Ricardinho. O nome se confunde com o número da camisa. Ricardinho, essa entidade mística, pirilâmpica e luminosa que transforma times rápidos e burros em times inteligentes.

E trouxeram o tal camisa 10. O único exemplar vivo e o único que a torcida aceitaria: Ricardinho. E ele foi saudado exatamente como a solução para o problema da correria. Ricardinho era a expressão da "paciência".

Segue a história

Se esqueceram, porém, que a inteligência de Ricardinho não era gratuita. Ela nos era dada em troca da velocidade, da leveza do time, dos passes rápidos, das enfiadas de bola, da correria que confundia o adversário, das jogadas que surgiam sem que os próprios jogadores soubessem como. As jogadas do Atlético pararam de surgir naturalmente. Agora teriam que partir todas elas da cabeça da mente pensante centralizada: Ricardinho.

Mas isso era secundário. Agora o problema principal estava resolvido: havia o camisa 10 e poderíamos "passar a bola" e "encontrar um espaço".

As vitórias vieram de novo. Contra Barueri e Santos, que foram times abertos, o Atlético jogou sem seu camisa 10 e foi muito bem. Contra São Paulo, jogou na retranca, e aí funcionou a paciência ricardiana. E contra Vitória o Atlético passou a bola, passou a bola, passou a bola o jogo inteiro e conseguiu fazer um mísero gol, contra um time atestadamente ruim, e justamente numa jogada de velocidade louca e não-pensada que não contou com a participação de Ricardinho.

E aí Ricardinho passou a ser o centro do time. E simultaneamente a coisa desandou. Fluminense, Flamengo, Coritiba e Internacional. Ricardinho, por melhor jogador que seja (perceba: eu jamais diria que se trata de um mal jogador, pelo contrário), não consegue, sozinho, pensar em tudo, arrumar espaços onde não se pode arrumar, com o time todo lento e parado. O time joga em função dele, e por isso está parado, sempre parado, morto. E não há espaço que apareça. É por isso que perdemos jogos em que dominamos completamente a bola: dominamo-la, mas não há mais o que fazer com a bola, porque as jogadas loucas da correria não saíam mais, porque não havia correria, porque tudo o que se deve fazer quando se tem um camisa 10 no time é tocar para o camisa 10. E passar a bola. Passar a bola, passar a bola.

Os times fechados

A coisa desandou com Ricardinho, é certo, porque o Atlético não consegue vencer times fechados. Os que discordarem de meu ponto vão lembrar que o time sem Ricardinho - que era outro time, era a correria e tal - também não conseguia vencer adversários fechados. É verdade. Mas deve-se levar em conta não só o resultado final, mas as chances, porque futebol não é exato, mas também não é aleatório, é probabilístico: em um duelo entre dois times, um bom e um ruim, não se pode afirmar que o bom vai vencer, mas se pode ter quase certeza de que, em se jogando 10 vezes, o time melhor vencerá mais de 5 partidas, só pra dar um exemplo.

Então a pergunta é: o time antigo do Atlético, aquele que perdeu para aquele Goiás retrancado até a alma no Mineirão, era ou não era melhor do que o atual, que perdeu, pelo mesmo placar para o incrivelmente retrancado Internacional no Mineirão? E a resposta é: Era. O time antigo, o time da correria e da burrice, o time sem camisa-10-pensante, era melhor. Eu sei disso, você sabe disso, toda a torcida sabe disso. Naquela ocasião [http://www.youtube.com/watch?v=SvY9G3975MA] a torcida não vaiou o time como o fez contra o Internacional, e isso é a indicação de que a torcida preferia aquele time, e de que aquele era um time melhor do que o atual e também melhor do que o Goiás, mesmo tendo perdido - o que não se pode dizer do time atual em relação ao Internacional. O total de chances criadas naquele jogo por aquele time, criadas quase que sem se saber por que, tudo no meio da correria, é a prova de que o time antigo era melhor. É a prova de que um time orientado para tocar a bola para o camisa 10 não funciona.

Soluções possíveis

Sei que não há mais tempo de salvar o ano, mas como mesmo que houvesse tempo de nada adiantaria eu escrever aqui qualquer sugestão, vou escrever mesmo assim e quem sabe fica aí pro próximo ano, ou quem sabe fica aí só pra eu e mais meia dúzia lermos e fim.

É certo que o Atlético não pode continuar jogando assim como está. A velocidade tem que voltar. Tem que voltar a correria e a loucura (não que Ricardinho deva ser mandado embora, apesar de eu achar essa uma boa idéia, mas ele precisa ser reposicionado no time). Então como fica o problema do furo da retranca adversária?

Perguntando a quem sabe mais de futebol do que eu, arranjei duas soluções possíveis:

(a) chutar de fora da área: ora, o Atlético tem vários pretensos chutadores de longa distância: o próprio Ricardinho, Evandro, Corrêa, Tardelli, Éder e até o Jonílson. Mas não chuta. Não entendo o porquê disso. Até vinha chutando em algumas partidas aí, mas parou, e a parada coincide mais ou menos com as partidas de nosso maior desgosto (essas últimas aí). O Flamengo só faz gol chutando de fora da área ou em jogada individual, não tem uma jogada coletiva (ou pelo menos não teve nos jogos que eu vi: contra Barueri, Atlético e Náutico).

(b) correr no fundo e cruzar pro meio da pequena área: essa é a melhor jogada do futebol, funciona quase sempre, é muito melhor do que os cruzamentos normais que se vê pedir pelas arquibancadas do Mineirão, é bela de se ver e, creio, fácil de se fazer. Mas é fácil só pra quem está acostumado a ela. Em várias oportunidades hoje mesmo contra o Internacional nossos jogadores poderiam tê-la feito, Corrêa, Márcio Araújo e Éder Luís poderiam tê-la feito, mas não sabem, sei lá, não querem fazer. O único jogador que faz esse tipo de jogada atualmente, mesmo assim só de vez em quando, é o Thiago Feltri (lembre-se dos dois pênaltis que ele sofreu recentemente), mas todo mundo vaia o sujeito.

Há, porém, um jogador que já passou pelo Atlético e que sabia fazer esse tipo de jogada com maestria. Não que ele seja a solução de tudo, mas acho que seria uma excelente peça no elenco: Danilinho. O problema de Danilinho é a estigma que pesa sobre ele, a de torcedores preconceituosos que o incluem entre um agrupamento místico e inerentemente ruim chamado "geração Série B", uma grande bobagem que inventaram aí.

Acabou-se o que eu tinha pra dizer.

Recently was suggested to me that https://p2panda.org/ was a great protocol and that maybe Nostr wouldn't be necessary if we could just use that. After making the blind remark that p2p doesn't work I was pointed to https://github.com/p2panda/aquadoggo which acts as a "node" in some ways similar to a "relay", and it all looks somewhat well, cool, maybe they're into something:

Then I realized that Aquadoggo isn't really a relay, it is more like an "app server". There are still no relays in the Nostr sense in p2panda, the base of communication is still p2p between "nodes", and, as Aquadoggo's readme say, it could be run both as a client and as a server. In other words, we could easily have an "Nostr Aquadoggo" that abstracts all communication with relays, relay selection, event and tag parsing and signatures then stores filtered, ordered, indexed data locally: it is just a Nostr client.

That you can put one of these in a server doesn't change that fact that it will be still a client -- and that underlings behind it consuming its API will be controlled, censored, mislead and tricked. This design that requires trust in one single server from a dumb client in exchange for massaged, sorted, filtered, ordered data is seen not only in p2panda, but it's also a fundamental part of the design in many of the supposed decentralized protocols out there, including Bluesky, Farcaster and Pubky. It has also found its way even into RSS, with feed aggregators, and into IRC with bouncers. It can also be seen being experimented with inside Nostr, with ZBD Social, Primal, Ditto, Satlantis and others I forgot, and even behind the ideas of some pseudo-relays like Bostr and filter.nostr.wine (although I'm not sure). Notably, though, this design is not a part of SSB or Mastodon and these two weren't ever corrupted by it as far as I know.

In any case, should we accept that such architecture will eventually find its way into Nostr and completely dominate it? If I believed the answer was "yes" I would immediately declare Nostr a failed experiment, but I don't. As the main author of one such experiment (ZBD Social), I still think this architecture isn't necessarily bad as long as it's limited and restricted to certain circumstances, but it does pose a risk of Nostr becoming almost as bad as Bluesky, so the path has to be threaded carefully.

Ultimately, though, what all these protocols are trying to achieve by injecting these dangerous super-peers into their architecture is the reliability that pure p2p cannot provide, along with filtering and discovery features. And Nostr's multi-relay architecture, as cumbersome and weird as it is, represents a very different approach to solving the same problems, one that none of these other protocols can even begin to consider emulating, and I believe we have to accept that, embrace it and lean on it more.

We can go there by having whitelisted relays as communities, relays that enforce group rules automatically, relays that provide fulltext search, relays that provide AI-based personalized custom feeds, relays that filter out reply spam or harassment (or enforce blocks at the server-side), relays that restrict reads to a certain selected group, relays that perform curation and make valuable content reemerge from the abyss of the ongoing stream; and of course clients that surface all these different types of relays and their features.

Why is this complex madness better than the super-peer architecture? Because, well, even though custom relays give us all these cool weird features, The basic Nostr feature of being able to follow anyone you want and not giving a super-peer the power to break that link between follower and followed, i.e. the outbox model, is still the most basic function of relays.

Most ideas come to me while I'm nowhere near a computer, so it's impossible to note them all down.

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

A browser extension that reads source code on GitHub and tries to find links to imported dependencies so you can click on them and navigate through either GitHub or package repositories or base language documentation. Works for many languages at different levels of completeness.

• https://github.com/fiatjaf/module-linker
• https://module-linker.alhur.es/
• https://addons.mozilla.org/firefox/addon/module-linker
• https://chrome.google.com/webstore/detail/dglofghjinifeolcpjfjmfdnnbaanggn

Está na moda ser contra a propaganda. "Se você não está pagando você é o produto", dizem os ativistas contrários aos sites que funcionam de graça, mas que ou te mostram propagandas ou vendem os seus dados para empresas terceirizadas que então te mostrarão propagandas. E aí advogam que todos devem usar bloqueadores de propagandas e procurar alternativas pagas aos mesmos serviços que funcionam de graça, porque os de graça, por sua participação nas redes de propaganda, acabam saindo mais caros para o usuário.

É claro que o Facebook e várias outras dessas grandes empresas da internet e "redes sociais" são horríveis, mas o pior de seus males é a propaganda que eles mostram. Os ativistas anti-propaganda se esquecem do maior bem que a propaganda -- e principalmente a propaganda direcionada e fracionada, estilo Google -- nos proporciona: a possibilidade de conhecer empresas novas com serviços que potencialmente nos interessam.

Se nos tempos da televisão a propaganda era uma coisa que só empresas já enormes conseguiam colocar no ar, hoje empresas minúsculas conseguem, e com essas propagandas conseguem atingir clientes que jamais sonhariam em conhecê-las. E empresas médias ou que estão tentando crescer conseguem atingir clientes que de outro modo acabariam comprando ou contratando as atuais líderes de mercado.

Se o primeiro caso é mais importante para mais pessoas e para a idéia mesma da liberdade de empresa e à cultura da microempresa individual, o segundo ponto soará melhor aos sociólogos e economistas normais: sem a possibilidade da propaganda, a tendência à manutenção do status quo é maior, sem a propaganda, é maior a probabilidade de um fulano qualquer escolher o seu fornecedor de bens e serviços pelo nome e pela fama, ou seja, as empresas que já são grandes e famosas têm uma probabilidade maior de continuarem grandes e famosas, mesmo que as menores que estão chegando agora ofereçam bens e serviços melhores e por menores preços -- ou mesmo bens e serviços ligeiramente diferentes, mais adeqüados à necessidade de fulano.

Essa conclusão é inegável, embora eu não possa dizer qual seja a magnitude do impacto que a propaganda tem.

Para vivermos num mundo sem propaganda e sem uma enorme tendência ao status quo, me parece que são necessários os seguintes desenvolvimentos (não precisa ser todos ao mesmo tempo, qualquer um deles pode funcionar separadamente):

• sistemas melhores de busca: quando fulano procura (no Google, uma empresa que vive de propaganda, será que alguém pagaria pra usar o Google? acho que sim) por um chicabon, o Google deveria mostrar-lhe não só o Chicabon da Kibon, mas outros chicabons possivelmente melhores, e talvez lhe dizer por que aqueles poderiam lhe agradar mais. Mas não só isso: talvez o fulano não esteja realmente querendo um chicabon, talvez ele esteja viciado em doces e no fundo esteja querendo se desviciar, talvez precise de um spa, uma dieta paleolítica, um cozinheiro melhor. Todas essas possibilidades deveriam lhe ser apresentadas, mas eu não faço idéia de como seria a interface do fulano com o computador para que isso fosse possível. Também não consigo imaginar isso funcionando sem um sistema computacional complexo e "inteligente" que opera com dados muito íntimos de fulano.
• melhor autoconhecimento e capacidade de expressão: as pessoas em geral não sabem o que querem, como disse, acho, o Steve Jobs, quando criou o iPhone. Se as pessoas soubessem o que querem, poderiam procurar exatamente pelo que querem. Se procurassem exatamente pelo que querem, talvez achassem coisas melhores do que acham quando procuram por termos genéricos ou nomes de marcas. Talvez a internet já tenha sido capaz de fazer melhorar muito as habilidades de buscar no Google das pessoas, mas continua havendo muito espaço para melhora. Os maiores problemas aqui são a auto-inspeção real (imagino que a maior parte das buscas sejam feitas hoje baseadas em coisas que as pessoas ouviram falar, e não no que elas querem intimamente de verdade) e, a parte mais difícil, a expressão dos resultados dessa auto-inspeção, para a qual é necessária também uma língüa decente (formal?), sólida e ao mesmo tempo flexível.
• bancos de dados de necessidades: se isso fosse inventado hoje, ninguém usaria, ou seriam repletos de desejos vazios, abstratos demais ou específicos demais para serem úteis, mas se o ponto anterior fosse realizado, a criação de bancos de dados de necessidades traria desenvolvimentos enormes no mundo (micro-)empresarial, com benefícios fáceis e grandes para todas as partes. Imagino eu, porém, que um esforço monstruosamente paciente de alguém que começasse a implementar a idéia dos bancos de dados de necessidades (perceba que a minha idéia aqui é expressa de forma abstrata e inútil) poderia, se tivesse algum sucesso, começar a educar as pessoas, assim como o Google as educou na técnica de "buscar", de modo que daqui a uns anos esses bancos de dados começassem já a terem utilidade e efeito.

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

o Princípios de Economia Política de Menger é o único livro que enfatiza a CAUSA o tempo todo. os cientistas todos parecem não saber, ou se esquecer sempre, que as coisas têm causa, e que o conhecimento verdadeiro é o conhecimento da causa das coisas.

a causa é uma categoria metafísica muito superior a qualquer correlação ou resultado de teste de hipótese, ela não pode ser descoberta por nenhum artifício econométrico ou reduzida à simples antecedência temporal estatística. a causa dos fenômenos não pode ser provada cientificamente, mas pode ser conhecida.

o livro de Menger conta para o leitor as causas de vários fenômenos econômicos e as interliga de forma que o mundo caótico da economia parece adquirir uma ordem no momento em que você lê. é uma sensação mágica e indescritível.

quando eu te o recomendei, queria é te imbuir com o espírito da busca pela causa das coisas. depois de ler aquilo, você está apto a perceber continuidade causal nos fenômenos mais complexos da economia atual, enxergar as causas entre toda a ação governamental e as suas várias consequências na vida humana. eu faço isso todos os dias e é a melhor sensação do mundo quando o caos das notícias do caderno de Economia do jornal -- que para o próprio jornalista que as escreveu não têm nenhum sentido (tanto é que ele escreve tudo errado) -- se incluem num sistema ordenado de causas e consequências.

provavelmente eu sempre erro em alguns ou vários pontos, mas ainda assim é maravilhoso. ou então é mais maravilhoso ainda quando eu descubro o erro e reinsiro o acerto naquela racionalização bela da ordem do mundo econômico que é a ordem de Deus.

em scrap para T.P.

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

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

Me lembrou do episódio do flautista n'O Vento dos Salgueiros.

Jofer era um jogador diferente. À primeira vista não, parecia igual, um volante combativo, perseguia os atacantes adversários implacavelmente, um bom jogador. Mas não era essa a característica que diferenciava Jofer. Jofer era, digamos, um chutador.

Começou numa semifinal de um torneio de juniores. O time de Jofer precisava do empate e estava sofrendo uma baita pressão do adversário, mas o jogo estava 1 a 1 e parecia que ia ficar assim mesmo, daquele jeito futebolístico que parece, parece mesmo. Só que aos 46 do segundo tempo tomaram um gol espírita, Ruizinho do outro time saiu correndo pela esquerda e, mesmo sendo canhoto, foi cortando para o meio, os zagueiros meio que achando que já tinha acabado mesmo, devia ter só mais aquele lance, o árbitro tinha dado dois minutos, Ruizinho chutou, marcou e o goleiro, que só pulou depois que já tinha visto que não ia ter jeito, ficou xingando.

A bola saiu do meio e tocaram para Jofer, ninguém nem veio marcá-lo, o outro time já estava comemorando, e com razão, o juiz estava de sacanagem em fazer o jogo continuar, já estava tudo acabado mesmo. Mas não, estava certo, mais um minuto de acréscimo, justo. Em um minuto dá pra fazer um gol. Mas como? Jofer pensou nas partidas da NBA em que com alguns centésimos de segundo faltando o armador jogava de qualquer jeito para a cesta e às vezes acertava. De trás do meio de campo, será? Não vou ter nem força pra fazer chegar no gol. Vou virar piada, melhor tocar pro Fumaça ali do lado e a gente perde sem essa humilhação no final. Mas, poxa, e daí? Vou tentar mesmo assim, qualquer coisa eu falo que foi um lançamento e daqui a uns dias todo mundo esquece. Olhou para o próprio pé, virou ele de ladinho, pra fora e depois pra dentro (bom, se eu pegar daqui, direitinho, quem sabe?), jogou a bola pro lado e bateu. A bola subiu escandalosamente, muito alta mesmo, deve ter subido uns 200 metros. Jofer não tinha como ter a menor noção. Depois foi descendo, o goleirão voltando correndo para debaixo da trave e olhando pra bola, foi chegando e pulando já só pra acompanhar, para ver, dependurado no travessão, a bola sair ainda bem alta, ela bateu na rede lateral interna antes de bater no chão, quicar violentamente e estufar a rede no alto do lado direito de quem olhava.

Mas isso tudo foi sonho do Jofer. Sonhou acordado, numa noite em que demorou pra dormir, deitado na sua cama. Ficou pensando se não seria fácil, se ele treinasse bastante, acertar o gol bem de longe, tipo no sonho, e se não dava pra fazer gol assim. No dia seguinte perguntou a Brunildinho, o treinador de goleiros. Era difícil defender essas bolas, ainda mais se elas subissem muito, o goleiro ficava sem perspectiva, o vento alterava a trajetória a cada instante, tinha efeito, ela cairia rápido, mas claro que não valia à pena treinar isso, a chance de acertar o gol era minúscula. Mas Jofer só ia tentar depois que treinasse bastante e comprovasse o que na sua imaginação parecia uma excelente idéia.

Começou a treinar todos os dias. Primeiro escondido, por vergonha dos colegas, chegava um pouco antes e ficava lá, chutando do círculo central. Ao menor sinal de gente se aproximando, parava e ia catar as bolas. Depois, quando começou a acertar, perdeu a vergonha. O pessoal do clube todo achava engraçado quando via Jofer treinando e depois ouvia a explicação da boca de alguém, ninguém levava muito a sério, mas também não achava de todo ridículo. O pessoal ria, mas no fundo torcia praquilo dar certo, mesmo.

Aconteceu que num jogo que não valia muita coisa, empatezinho feio, aos 40 do segundo tempo, a marcação dos adversários já não estava mais pressionando, todo mundo contente com o empate e com vontade de parar de jogar já, o Henrique, meia-esquerdo, humilde, mas ainda assim um pouco intimidante para Jofer (jogava demais), tocou pra ele. Vai lá, tenta sua loucura aí. Assumiu a responsabilidade do nosso volante introspectivo. Seria mais verossímil se Jofer tivesse errado, primeira vez que tentou, restava muito tempo ainda pra ele ter a chance de ser herói, ninguém acerta de primeira, mas ele acertou. Quase como no sonho, Lucas, o goleiro, não esperava, depois que viu o lance, riu-se, adiantou-se para pegar a bola que ele julgava que quicaria na área, mas ela foi mais pra frente, mais e mais, daí Lucas já estava correndo, só que começou a pensar que ela ia pra fora, e ele ia só se dependurar no travessão e fazer seu papel de estar na bola. Acabou que por conta daquele gol eles terminaram em segundo no grupo daquele torneiozinho, ao invés de terceiro, e não fez diferença nenhuma.

A response to https://gist.github.com/fernandonm/81cb21bdce0910055de32b98ee4119e1

This piece from Fernando Nieto claims that any asset that is expected to constantly appreciate in value -- as Bitcoin is expected to, as its supply is strictly fixed, the other option is for Bitcoin to die, but we're not considering that hypothesis -- will necessarily be very volatile.

It is not clear what "volatile" means, but we'll assume it means the market value of this asset will vary against the market value of all the other things strongly and annoyingly enough to make it useless as a unit of account. We can't just consider "the price of Bitcoin against the Dollar", it must be against "everything", otherwise we could just assume the volatily was happening on the Dollar side, not on the Bitcoin side.

The value of an asset can only grow due to uncertain future returns becoming increasingly certain as time passes. Any future value expectation is priced in from the very moment it becomes certain. Hence, the same uncertainty inherent to investiments expected to provide a return -- e.g. an increase in the value of each bitcoin -- makes them inherently volatile.

This is the claim, and also considered an explanation as it says "the article could end here", but the explanation is missing one piece, which is given many paragraphs below:

Even if sometimes you may appreciate a return exceeding the cost of volatily risk, returns are always offset at the margin by the costs of holding the asset. If any asset offered a risk adjusted return opportunity clearly more attractive than the rest, that would be immediately arbitraged away (...)

The essence of the argument is that there cannot be an asset that increases in value without risk, otherwise that value increase would be arbitraged away. In other words, if Bitcoin is to increase in value constantly and predictably accross the years, then its price should be arbitraged away in a manner ~~~

(This was never finished and I don't remember what I was going to say.)

o método científico não pode ser aplicado senão numa meia dúzia de casos, e no entanto ei-nos aqui, pensando nele para tudo.

"formule hipóteses e teste-as independentemente", "obtenha uma quantidade de dados estatisticamente significante", teste, colete dados, mensure.

não é que de repente todo mundo resolveu calcular desvios-padrão, mas sim que é comum, para as pessoas mais cultas, nível Freakonomics, acharem que têm que testar e coletar dados, e nunca jamais confiar na sua "intuição" ou, pior, num raciocínio que pode parecer certo, mas na verdade é enormemente enganador.

sim, é verdade que raciocínios com explicações aparentemente sensatas nos são apresentados todos os dias -- para um exemplo fácil é só imaginar um comentarista de jornal, ou até uma matéria inocente de jornal, aliás, melhor pensar num comentarista da GloboNews --, e sim, é verdade que a maioria dessas explicações é falsa.

o que está errado é achar que só o que vale é testar hipóteses. você não pode testar a explicação aparentemente sensata que o taxista te fornece sobre a crise brasileira, deve então anotá-la para testar depois? mantê-la para sempre no cabedal das teorias ainda por testar?

e a explicação das redinhas que economizam água quando instaladas na torneira? essa dá pra testar, então você vai comprar um relógio de água e deixar a torneira ligada lá 5 horas com a redinha, depois 5 horas sem a redinha? obviamente não vai funcionar se você abrir o mesmo tanto, você vai precisar de um critério melhor: a satisfação da pessoa que está lavando as mãos com o resultado final versus a quantidade de água gasta. daí você precisaria de muitas pessoas, mas satisfação é uma coisa imensurável, nem adianta tentar fazer entrevistas antes e depois com as pessoas. o certo então, é o quê? procurar um estudo científico publicado numa revista de qualidade (porque tem aquelas revistas que aceitam estudos gerados por computador, então é melhor tomar cuidado) que fala sobre redinhas? como saber se a redinha é a mesma que você comprou? e agora que você já comprou, o resultado do experimento importa? (claro: pode ser que a redinha faça gastar mais água, você nunca saberá até que faça o experimento).

por que não, ao invés de condenar todos os raciocínios como enganadores e mandar que as pessoas façam experimentos científicos, ensinar a fazer raciocínios certos?

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

Setting up Google Analytics for a bunch of very small projects was a big hassle for me, the bureaucracy involved in creating Google Analytics projects/pages/websites involved something like 4 or 5 forms, and then I always got confused when I went to browse the most simple stats (pageviews, sessions, referrers), and the page was slow to open, had more information than was needed or desirable and so on. And finally there was always a ton of referrer spam (people who used the referrer tracking function of Google Analytics to insert their own sites there somehow and get me to click them).

Then I tried to use the only alternative that existed at the time: gaug.es, but although it was better it wasn't as better as it could be. I wanted a very minimalistic thing. And it was too expensive (for my standards).

So I wrote my own, in React, specifically aimed to people who have a lot of small websites they wanted to track, using Bulma for the styles, react-dnd to make nice reorderable cards with the information and the most efficient scheme for storing the smallest amount of data possible in the database (first CouchDB, then migrated to Postgres later) while still providing session tracking and an optional way to assign points to each action a visitor may perform in a website.

At its height I personally used it with more than 20 projects. There were some other users, but the only one that actually used it besides me was https://eternum.io/ (although I didn't charge them).

I set up a very low pricing range and tried to market it in all the usual "hacker" sites, but never get any attention. At its last days I started pricing it in Bitcoin, but it made no difference.

Then all of a sudden about 5 different "minimalistic" website tracking and tools very similar to trackingco.de began to show up on Hacker News and they got a ton of interest and users. They weren't better than trackingco.de as far as I know. It was frustrating.

• https://github.com/fiatjaf/trackingco.de

See also

• microanalytics

This is the most barebones possible, it will just open a web browser at https://nostr.guru/ with the contents of the nostr: link.

Create this file at ~/.local/share/applications/nostr-opener.desktop:

[Desktop Entry]
Exec=/home/youruser/nostr-opener %u
Name=Nostr Browser
Type=Application
StartupNotify=false
MimeType=x-scheme-handler/nostr;

(Replace "youruser" with your username above.)

This will create a default handler for nostr: links. It will be called with the link as its first argument.

Now you can create the actual program at ~/nostr-opener. For example:

#!/usr/bin/env python

import sys
import webbrowser

nip19 = sys.argv[1][len('nostr:'):]
webbrowser.open(f'https://nostr.guru/{nip19}')

Remember to make it executable with chmod +x ~/nostr-opener.

A comparação entre uma database e a memória humana é trivial, todo mundo pensa. Os exemplos das letras de música e dos rostos humanos citados neste trabalhinho acadêmico boboca fazem muito sentido: de fato a analogia entre index keys e trechos de música ou rostos humanos parece explicar fenômenos que experimentamos.

O que me parece loucura é a simplificação, o reducionismo, que povoa a mente dos responsáveis por essas analogias. O fato de que uma database tem uma lista de keys enquanto a memória humana tem um mecanismo de busca vago, context-sensitive, que opera com dicas soltas e ora funciona ora não funciona -- não é argumento para afirmar que o computador é melhor do que a memória humana.

Claro, todos esses cientistas vão dizer que a memória humana tem uma eficiência enorme, porque ela armazena muito mais dados do que os computadores blablablá, mas em tese ela pode ser reimplementada usando os algoritmos de databases que nós já usamos.

A imagem simplificada da memória humana que se faz é a seguinte: quando vimos uma coisa qualquer, um menino pulando um muro, ela nos lembra de outras coisas relacionadas, uma certa vez em que nós mesmos pulamos um muro, o muro que estamos pensando em construir, umas brincadeiras parecidas com pular muro, os motivos que já levaram outras pessoas a pular muro, um filme que tinha cenas de meninos travessos, a muralha da China, uma imagem de assaltante que não está pulando nenhum muro, uma casa da mesma cor do muro. Simples: nosso cérebro pega os dados dos sentidos e com eles faz uma busca na memória.

A questão toda é: quais "dados dos sentidos"? Como é que o coitado do cérebro sabe que é pra procurar um muro, e não uma parede qualquer, ou os tijolos separados, ou o cimento, o barro de onde são feitos os tijolos? Isto sem contar a distinção, que é outro problema, que fazemos entre a mancha colorida a que chamamos muro e a outra mancha colorida a que chamamos menino, dentre infinitas outras, porque isto é outro problema. Mas a escolha dos dados que vão ser usados na busca que será feita na memória é crucial para o sucesso da operação, e nenhum computador saberia escolher.

Alguém vai argumentar que um mecanismo de computer vision poderia identificar um menino e um muro na cena e encontrar no banco de dados várias coisas relacionadas a meninos e várias coisas relacionadas a muros, mas temos que concordar que não é nada nem próximo disto que a mente humana faz. O assaltante, por exemplo, só seria encontrado se, no ato de indexá-lo, já colocássemos lá "atravessar obstáculos" e, putz, como tirar esta mesma frase de uma imagem de um menino perto de um muro? Mesmo que a computer vision seja ótima e consiga, como decidir entre a query "atravessar obstáculos" e "correr risco físico", "desafiar-se a si mesmo", "chegar mais alto", "invadir propriedade privada", "brincar", "tentar impressionar as meninas", "lutar para ser aceito entre seus pares", "mostrar que sabe", "chegar primeiro" e infinitos outros sentimentos, motivações, expectativas e processos que podem estar em curso naquela subida de muro?

Não é nada disso que a mente humana faz, eu dizia, porque a computer vision pode identificar o muro e o menino e o ato do menino de subir o muro, mas e quando a atenção humana foca no material que constitui o muro, a cor do muro ou a planta que está nascendo no meio do muro? Ou no reboque malfeito do muro, a casa que imagina haver atrás do muro? Cada foco destes, cuja causa também não vem ao caso aqui, deveria produzir queries bem diferentes.

Há vários outros pontos que poderiam ser levantados aqui contra o reducionismo e a simplificação da analogia entre a memória humana e uma database simples, e o erro que é igualá-las, mas me perdi, e acho que se você entendeu os pontos que levantei acima saberá encontrar vários outros exemplos nos quais o funcionamento da memória humana ultrapassa em complexidade qualquer algoritmo infinitamente -- e uso aqui "infinitamente" em sentido estritamente literal.

em meio ao caos, às trevas e à imundície da esquerda atroz, que a pó a nação reduz surge um guerreiro cavalgando as planícies pra libertar a Terra de Santa Cruz

tendo sua liberdade ameaçada o povo prostra-se em pia oração deus lhes envia com armadura prateada o herói Jair, dos justos o bastião

Bolsonaro mito Bolsonaro mito defende a liberdade neste conflito

à serpente vermelha quem resiste? são China e ONU seus braços de terror mas Bolsomito com sua espada em riste rasga o inimigo com a audácia de um condor

por sua honra não se acovarda ou falha imbuído está de intrepidez viril vá Bolsonaro, vença essa batalha! destrua o mal, salve o povo do Brasil

Bolsonaro mito Bolsonaro mito defende a liberdade neste conflito

Letra de Paulo Kogos, cantada por ele em https://www.youtube.com/watch?v=b1BBY9e-__s

If AI is so good why can't it:

• write good glue code that wraps a documented HTTP API?
• make good translations using available books and respective published translations?
• extract meaningful and relevant numbers from news articles?
• write mathematical models that fit perfectly to available data better than any human?
• play videogames without cheating (i.e. simulating human vision, attention and click speed)?
• turn pure HTML pages into pretty designs by generating CSS
• predict the weather
• calculate building foundations
• determine stock values of companies from publicly available numbers
• smartly and automatically test software to uncover bugs before releases
• predict sports matches from the ball and the players' movement on the screen
• continuously improve niche/local search indexes based on user input and and reaction to results
• control traffic lights
• predict sports matches from news articles, and teams and players' history

This was posted first on Twitter.

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.

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

Look at the following piece of Go code:

func NewQuery(query []rune) *Query {
	q := &Query{
		query:    &[]rune{},
		complete: &[]rune{},
	}
	_ = q.Set(query)
	return q
}
func NewQueryWithString(query string) *Query {
	return NewQuery([]rune(query))
}

It is taken from a GitHub project with over 2000 stars.

Now take a look at these unit tests for the same package:

func TestNewQuery(t *testing.T) {
	var assert = assert.New(t)

	v := []rune(".name")
	q := NewQuery(v)

	assert.Equal(*q.query, []rune(".name"))
	assert.Equal(*q.complete, []rune(""))
}

func TestNewQueryWithString(t *testing.T) {
	var assert = assert.New(t)

	q := NewQueryWithString(".name")

	assert.Equal(*q.query, []rune(".name"))
	assert.Equal(*q.complete, []rune(""))
}

Now be honest: what are these for? Is this part of an attack to eat all GitHub storage and head them to bankruptcy?

Also

• my personal approach on using let, const and var in javascript

há aqui um artigo, escrito por um sujeito provavelmente esquerdista, ateu e tal, que toca num ponto importante sobre o discurso dessas esquerdas defensoras de minorias.

ele introduz brevemente o conceito da motte-and-bailey doctrine, que é um nome bacana que deram para a estratégia que esses conhecidos e amigos seus de esquerda usam para dizer os maiores absurdos na internet e em grupos fechados esquerdistas, mas, quando confrontados por você, parecem ser mansos, inteligentes e gente boa, como você sempre esperou que fossem.

o sujeito é meio confuso, mas o fato mesmo de ele ser esquerdista valida mais ainda o argumento.

The HRF has awarded two bounties yesterday. The episode exposes some of the problems of the bounties and grants culture that exists on Bitcoin.

First, when the bounties were announced, almost an year ago, I felt they were very hard to achieve (and also very useless, but let's set that aside).

The first, "a wallet that integrates bolt12 so it can receive tips noncustodially", could be understood as a bounty for mobile wallets only, in which case the implementation would be hacky, hard and take a lot of time; or it could be understood as being valid for any wallet, in which case it was already implemented in CLN (at the time called "c-lightning"), so the bounty didn't make sense.

The second, a wallet with a noncustodial US dollar balance, is arguably impossible, since there is no way to achieve it without trusted oracles, therefore it is probably invalid. If one assumed that trust was fine, then it was already implemented by StandardSats at the time. It felt it was designed to use some weird construct like DLCs -- and Chris Steward did publish a guide on how to implement a wallet that would be eligible for the bounty using DLCs, therefore the path seemed to be set there, but this would be a very hard and time-intensive thing.

The third, a noncustodial wallet with optional custodial ecash functionality, seemed to be targeting Fedimint directly, which already existed at the time and was about to release exactly these features.

Time passed and apparently no one tried to claim any of these bounties. My explanation is that, at least for 1 and 2, it was so hard to get it done that no one would risk trying and getting rejected. It is better for a programmer to work on something that interests them directly if they're working for free.

For 3 I believe no one even tried anything because the bounty was already set to be given to Fedimint.

Fast-forward to today and bounties 1 and 3 were awarded to two projects that were created by the sole interest of the developers with no attempt to actually claim these bounties -- and indeed, the two winners strictly do not qualify according to the descriptions from last year.

What if someone was working for months on trying to actually fulfill the criteria? That person would be in a very bad shape now, having thrown away all the work. Considering this it was a very good choice for everyone involved to not try to claim any of the bounties.

The winners have merit only in having pursued their own interests and in creating useful programs as the result. I'm sure the bounties do not feel to them like a deserved payment for the specific work they did, but more like a token of recognition for having worked on Bitcoin-related stuff at all, and an incentive to continue to work.

What is better than bounties and grants?

A tool that migrates data from a c-lightning SQLite3 database into PostgreSQL so one can keep Lightning channels and everything but change the underlying database.

It's a mostly manual thing, and I keep following changes in the database schema on c-lightning's GitHub repo so I can update the migration specs whenever needed.

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

See also

• Sparko
• trustedcoin

The problem

1. Users inside centralized services need to know reputations of other users they're interacting with;
2. Building reputation with ratings imposes a big burden on the user and still accomplishes nothing, can be faked, no one cares about these ratings etc.

The ideal solution

Subjective reputation: reputation based on how you rated that person previously, and how other people you trust rated that person, and how other people trusted by people you trust rated that person and so on, in a web-of-trust that actually can give you some insight on the trustworthiness of someone you never met or interacted with.

The problem with the ideal solution

1. Most of the times the service that wants to implement this is not as big as Facebook, so it won't have enough people in it for such graphs of reputation to be constructed.
2. It is not trivial to build.

My proposed solution:

I've drafted a protocol for an open system based on services publishing their internal reputation records and indexers using these to build graphs, and then serving the graphs back to the services so they can show them to users when it is needed (as HTTP APIs that can be called directly from the user client app or browser).

Crucially, these indexers will gather data from multiple services and cross-link users from these services so the graph is better.

https://github.com/fiatjaf/multi-service-reputation-rfc

The first and single actionable and useful feedback I got, from @bootstrapbandit was that services shouldn't share email addresses in plain text (email addresses and other external relationships users of a service may have are necessary to establish links from users accross services), but I think it is ok if services publish hashes of these email addresses instead. At some point I will update the spec draft and that may have been before the time you're reading this.

Another issue is that services may lie about their reputation records and that will hurt other services and users in these other services that are relying on that data. Maybe indexers will have to do some investigative job here to assert service honesty. Or maybe this entire protocol is just failed and we will actually need a system in which users themselves will publish their own records.

See also

• P2P reputation thing
• idea: Graph subjective reputation as a service
• https://github.com/jangerritharms/reputation_systems

(The title is misleading.)

I don't see how you can successfully resist an invasion without a centralized entity to coordinate things on a high level.

This is the argument used every time the topic of war is raised in a conversation that involved talks of anarchism and ending the State, and it did not fail to show up again in a conversation about Russia's invasion of Ukraine now.

Turns out there is a simple answer: if there was no State there would be no invasion because if you assume Ukrainian people wouldn't be able to organize a defense then you much more have to assume that the Russian people won't organize an attack.

The answer is unsatisfactory because there may be a Russian state organizing the attack while there is no Ukrainian State to organize the defense (because somehow the Ukrainian libertarians succeeded in ending the State just inside the borders of Ukraine). In this case it may be that the Russian State will occupy Ukraine and now the Ukrainian people will have to pay taxes and submit to psychopath politicians again, and Ukrainian libertarians will have another State to fight against.

The nature of the State

This situation, if it ever happened, would showcase again the nature of the State, which is, as described by Franz Oppenheimer, the apparatus formed by a group that conquered the another group. In this case the Russian high politicians and military conquered the people of Ukraine -- just like they had conquered the Russian peoples (or taken the control of the Russian government from others that conquered these peoples before).

What has changed?

If you compare the situation of Ukrainian people before the Ukrainian State ended and after the Russia dominated, has it worsen significantly? No. Maybe it is a little worse because the Russian State is worse than the Ukrainian State, but it could have been better if Ukraine had been conquered by some other country (could also have been worse).

What is to be done?

There is no real conclusion, i.e. I don't know what to do about Russia vs Ukraine. In this specific case maybe it makes sense to join the Ukraine government to defend against Russia -- if you think the Ukrainian government is so much better than the Russian. But to what point? I have no idea. The fight against the State will have to continue in any case.

Not necessarily

For the purposes of the reasoning above we granted that the Russian State would successfully invade and conquer Stateless Ukraine, but that is not certain. Many people have imagined ways in which a stateless society could fight back an organized army, and these ideas are not more absurd than some of the things we see in the real State vs State war.

Imagine someone comes up with a solution for P2P content-addressed data-sharing that involves storing all the files' contents in all computers of the network. That wouldn't work, right? Too much data, if you think this can work then you're a BSV enthusiast.

Then someone comes up with the idea of not storing everything in all computers, but only some things on some computers, based on some algorithm to determine what data a node would store given its pubkey or something like that. Still wouldn't work, right? Still too much data no matter how much you spread it, but mostly incentives not aligned, would implode in the first day.

Now imagine someone says they will do the same thing, but instead of storing the full contents each node would only store a pointer to where each data is actually available. Does that make it better? Hardly so. Still, you're just moving the problem.

This is IPFS.

Now you have less data on each computer, but on a global scale that is still a lot of data.

No incentives.

And now you have the problem of finding the data. First if you have some data you want the world to access you have to broadcast information about that, flooding the network -- and everybody has to keep doing this continuously for every single file (or shard of file) that is available.

And then whenever someone wants some data they must find the people who know about that, which means they will flood the network with requests that get passed from peer to peer until they get to the correct peer.

The more you force each peer to store the worse it becomes to run a node and to store data on behalf of others -- but the less your force each peer to store the more flooding you'll have on the global network, and the slower will be for anyone to actually get any file.

But if everybody just saves everything to Infura or Cloudflare then it works, magic decentralized technology.

Related

• How IPFS is broken

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

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.

I started using this neuron thing to create an update this same zettelkasten, but the existing vim plugin had too many problems, so I forked it and ended up changing almost everything.

Since the upstream repository was somewhat abandoned, most users and people who were trying to contribute upstream migrate to my fork too.

• https://github.com/fiatjaf/neuron.vim

A replacement for Google Analytics that run inside a CouchDB, when CouchDB still was a potential platform for hosting of simple apps and easily distribution of apps with data.

It also had a CLI app for browsing the data with nice CLI charts.

• https://github.com/fiatjaf/microanalytics
• https://github.com/fiatjaf/microanalytics-cli

See also

• About CouchDB
• trackingco.de

A transaction is a piece of data that takes inputs and produces outputs. Forget about the blockchain thing, Bitcoin is actually just a big tree of transactions. The blockchain is just a way to keep transactions ordered.

Imagine you have 10 satoshis. That means you have them in an unspent transaction output (UTXO). You want to spend them, so you create a transaction. The transaction should reference unspent outputs as its inputs. Every transaction has an immutable id, so you use that id plus the index of the output (because transactions can have multiple outputs). Then you specify a script that unlocks that transaction and related signatures, then you specify outputs along with a script that locks these outputs.

As you can see, there's this lock/unlocking thing and there are inputs and outputs. Inputs must be unlocked by fulfilling the conditions specified by the person who created the transaction they're in. And outputs must be locked so anyone wanting to spend those outputs will need to unlock them.

For most of the cases locking and unlocking means specifying a public key whose controller (the person who has the corresponding private key) will be able to spend. Other fancy things are possible too, but we can ignore them for now.

Back to the 10 satoshis you want to spend. Since you've successfully referenced 10 satoshis and unlocked them, now you can specify the outputs (this is all done in a single step). You can specify one output of 10 satoshis, two of 5, one of 3 and one of 7, three of 3 and so on. The sum of outputs can't be more than 10. And if the sum of outputs is less than 10 the difference goes to fees. In the first days of Bitcoin you didn't need any fees, but now you do, otherwise your transaction won't be included in any block.

If you're still interested in transactions maybe you could take a look at this small chapter of that Andreas Antonopoulos book.

If you hate Andreas Antonopoulos because he is a communist shitcoiner or don't want to read more than half a page, go here: https://en.bitcoin.it/wiki/Coin_analogy

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

É simples: Você pode escolher entre votar em um candidato qualquer, como todos fazemos normalmente, ou tirar um voto de um político que não quer que seja eleito de jeito nenhum. A possibilidade de votarmos negativamente duas vezes é muito interessante também.

Outro motivo para implementar essa inovação na democracia: é muito mais divertido que o voto nulo.

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

Danilo acordou cedo e saiu para pegar o metrô, trajava aquelas vestes que seus amigos chamavam de "roupa de comunista", uma calça velha de brim, bege, uma blusa branca com uma logomarca vermelha - que não tinha nada a ver com comunismo - velha sob um paletó azul surrado e chinelo de dedo. Suas roupas eram todas parecidas entre si e, combinadas com sua barba malfeita castanha e seu olhar fundo típico de pessoas alcoolizadas, davam-lhe, realmente, um aspecto notório de comunista.

Quando o metrô parou na estação, Danilo entrou com sua mochila. Não havia assentos livres, mas ele já estava acostumado, aliás, até gostava de ficar em pé, para sentir melhor no rosto o vento que só vinha das janelas superiores do veículo. Colocou a mochila no chão e se segurou em uma das barras de ferro do veículo. Seus cabelos, apesar de curtos, balançavam em intrépidos estandartizados movimentos, como se dançassem o som de "One of These Days".

Fumaça verde me entrando pelas narinas e um coro desafinado fazia uma base melódica.

nos confins da galáxia havia um planetinha isolado. Era um planeta feliz.

O homem vestido de mago começava a aparecer por detrás da fumaça verde.

O planetinha recebeu três presentes, mas o seu habitante, o homem, estava num estado de confusão tão grande que ameaçava estragá-los. Os homens já havia escravizado o primeiro presente, a vida; lutavam contra o segundo presente, a morte; e havia alguns que achavam que deviam destruir totalmente o terceiro, o amor, e com isto levar a desordem total ao pobre planetinha perdido, que se chamava Terra.

O coro desafinado entrou antes do "Terra" cantando várias vezes, como se imitasse um eco, "terra-terra-terraaa". Depois de uma pausa dramática, o homem vestido de mago voltou a falar.

Terra, nossa nave mãe.

Neste momento eu me afastei. À frente do palco onde o mago e seu coral faziam apelos à multidão havia vários estandes cobertos com a tradicional armação de quatro pernas e lona branca. Em todos os cantos da praça havia gente, gente dos mais variados tipos. Visitantes curiosos que se aproximavam atraídos pela fumaça verde e as barraquinhas, gente que aproveitava o movimento para vender doces sem pagar imposto, casais que se abraçavam de pé para espantar o frio, os tradicionais corredores que faziam seu cooper, gente cheia de barba e vestida para imitar os hippies dos anos 60 e vender colares estendidos no chão, transeuntes novos e velhos, vestidos como baladeiros ou como ativistas do ônibus grátis, grupos de ciclistas entusiastas.

O mago fazia agora apelos para que nós, os homens, habitantes do isolado planetinha, passássemos a ver o planetinha, nossa nave mãe, como um todo, e adquiríssemos a consciência de que ele estava entrando em maus lençóis. A idéia, reforçada pela logomarca do evento, era que parássemos de olhar só para a nossa vida e pensássemos no planeta.

A logomarca do evento, um desenho estilizado do planeta Terra, nada tinha a ver com seu nome: "Festival Andando de Bem com a Vida", mas havia sido ali colocada estrategicamente pelos organizadores, de quem parecia justamente sair a mensagem dita pelo mago.

Aquela multidão de pessoas que, assim como eu, tinham suas próprias preocupações, não podiam ver o quadro caótico que formavam, cada uma com seus atos isolados, ali naquela praça isolada, naquele planeta isolado. Quando o hippie barbudo, quase um Osho, assustava um casal para tentar vender-lhes um colar, a quantidade de caos que isto acrescentava à cena era gigantesca. Por um segundo, pude ver, como se estivesse de longe e acima, com toda a pretensão que este estado imaginativo carrega, a cena completa do caos.

Uma nave-mãe, dessas de ficção científica, habitada por milhões de pessoas, seguia no espaço sem rumo, e sem saber que logo à frente um longo precipício espacial a esperava, para a desgraça completa sua e de seus habitantes.

Acostumados àquela nave tanto quanto outrora estiveram acostumados à sua terra natal, os homens viviam as próprias vidas sem nem se lembrar que estavam vagando pelo espaço. Ninguém sabia quem estava conduzindo a nave, e ninguém se importava.

No final do filme descobre-se que era a soma completa do caos que cada habitante produzia, com seus gestos egoístas e incapazes de levar em conta a totalidade, é que determinava a direção da nave-mãe. O efeito, no entanto, não era imediato, como nunca é. Havia gente de verdade encarregada de conduzir a nave, mas era uma gente bêbada, mau-caráter, que vivia brigando pelo controle da nave e o poder que isto lhes dava. Poder, status, dinheiro!

Essa gente bêbada era atraída até ali pela corrupção das instituições e da moral comum que, no fundo no fundo, era causada pelo egoísmo da população, através de um complexo -- mas que no filme aparece simplificado pela ação individual de um magnata do divertimento público -- processo social.

O homem vestido de mago era mais um agente causador de caos, com sua cena cheia de fumaça e sua roupa estroboscópica, ele achava que estava fazendo o bem ao alertar sua platéia, todos as sextas-feiras, de que havia algo que precisava ser feito, que cada um que estava ali ouvindo era responsável pelo planeta. A sua incapacidade, porém, de explicar o que precisava ser feito só aumentava a angústia geral; a culpa que ele jogava sobre seu público, e que era prontamente aceita e passada em frente, aos familiares e amigos de cada um, atormentava-os diariamente e os impedia de ter uma vida decente no trabalho e em casa. As famílias, estressadas, estavam constantemente brigando e os motivos mais insignificantes eram responsáveis pelas mais horrendas conseqüências.

O mago, que após o show tirava o chapéu entortado e ia tomar cerveja num boteco, era responsável por uma parcela considerável do caos que levava a nave na direção do seu desgraçado fim. No filme, porém, um dos transeuntes que de passagem ouviu um pedaço do discurso do mago despertou em si mesmo uma consiência transformadora e, com poderes sobre-humanos que lhe foram então concedidos por uma ordem iniciática do bem ou não, usando só os seus poderes humanos mesmo, o transeunte -- na primeira versão do filme um homem, na segunda uma mulher -- consegue consertar as instituições e retirar os bêbados da condução da máquina. A questão da moral pública é ignorada para abreviar a trama, já com duas horas e quarenta de duração, mas subentende-se que ela também fora resolvida.

No planeta Terra real, que não está indo em direção alguma, preso pela gravidade ao Sol, e onde as pessoas vivem a própria vida porque lhes é impossível viver a dos outros, não têm uma consciência global de nada porque só é possível mesmo ter a consciência delas mesmas, e onde a maioria, de uma maneira ou de outra, está tentando como pode, fazer as coisas direito, o filme é exibido.

Para a maioria dos espectadores, é um filme que evoca reflexões, um filme forte. Por um segundo elas têm o mesmo vislumbre do caos generalizado que eu tive ali naquela praça. Para uma pequena parcela dos espectadores -- entre eles alguns dos que estavam na platéia do mago, o próprio mago, o seguidor do Osho, o casal de duas mulheres e o vendedor de brigadeiros, mas aos quais se somam também críticos de televisão e jornal e gente que fala pelos cotovelos na internet -- o filme é um horror, o filme é uma vulgarização de um problema real e sério, o filme apela para a figura do herói salvador e passa uma mensagem totalmente errada, de que a maioria da população pode continuar vivendo as suas própria vidinhas miseráveis enquanto espera por um herói que vem do Olimpo e os salva da mixórdia que eles mesmos causaram, é um filme que presta um enorme desserviço à causa.

No dia seguinte ao lançamento, num bar meio caro ali perto da praça, numa mesa com oito pessoas, entre elas seis do primeiro grupo e oito do segundo, discute-se se o filme levará ou não o Oscar. Eu estou em casa dormindo e não escuto nada.

Today I saw this: https://github.com/stickfigure/blog/wiki/How-to-(and-how-not-to)-design-REST-APIs

And it reminded me why GraphQL is so much better.

It has also reminded me why HTTP is so confusing and awful as a protocol, especially as a protocol for structured data APIs, with all its status codes and headers and bodies and querystrings and content-types -- but let's not talk about that for now.

People complain about GraphQL being great for frontend developers and bad for backend developers, but I don't know who are these people that apparently love reading guides like the one above of how to properly construct ad-hoc path routers, decide how to properly build the JSON, what to include and in which circumstance, what status codes and headers to use, all without having any idea of what the frontend or the API consumer will want to do with their data.

It is a much less stressful environment that one in which we can just actually perform the task and fit the data in a preexistent schema with types and a structure that we don't have to decide again and again while anticipating with very incomplete knowledge the usage of an extraneous person -- i.e., an environment with GraphQL, or something like GraphQL.

By the way, I know there are some people that say that these HTTP JSON APIs are not the real REST, but that is irrelevant for now.

O sujeito que quer menos Estado, menos leis, menos complicação desnecessária, menos gastos jamais vai se interessar pela política do dia-a-dia de uma câmara de vereadores. Nada de bom jamais pode sair de uma pocilga dessas.

Já o sujeito que acha que o Estado tem que fazer coisas, dar coisas para a população, não liga para problemas orçamentários ou para a produção desnecessária de complexidade e de burocracias -- esse sujeito se interessa, acha que uma câmara dos deputados pode mandar construir coisas ou direcionar dinheiro para programas sociais, produzir várias leis que o agradem, que proíbem certas coisas e obrigam outras, criar departamentos.

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.

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

(Rome, a série.)

Just bad things.

• Drivechain comparison with Ethereum
• A crappy zk-rollups explanation attempt

A browser for public Lightning Network channels that updates daily, shows some unexpected charts and tries to use some chain analysis and other heuristics to determine who opened the channels, who closed, what was the state of the closure, what node software each entity is using and other things.

It consists of a Python script that fetches and does things with data before saving it to a Postgres database, a Postgrest server and a static site that gets data from Postgrest.

• https://raw.githubusercontent.com/fiatjaf/lnchannels/master/lnchannels-home.png

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

• https://ln.bigsun.xyz/

Based on sitio, this was supposed to be the successor of Websites For Trello.

From the old landing page:

sítios.xyz is a hosted static site generator based on sitio. It is capable of building websites by fetching content from other services and arranging them in pages. It can be used to build any sort of blog or site.

It supports fetching content from Trello, Dropbox, Evernote and arbitrary URLs. You can use just one of these providers, or mix them all in your site.

How it works

Basically, you just have to point to an URL of the site, like /posts, for example, and assign a provider to it. The trello:list provider, for example, will fetch all cards on a Trello list and create a page for each of them under /posts/:card-name and finish with an index, optionally paginated, on /posts itself.

You can repeat this process for other content from other sources, or even just point the root URL, / to some provider and be done with it.

Fast

The generated websites are super fast, as they're served as HTML files directly, no server-rendering involved. Also, due to sitio capabilities, they have instant navigation enabled by default, which uses JavaScript to fetch just the content of the pages, instead of performing a full reload.

Customization

Since the way pages are rendered -- their HTML structure -- is standardized by classless, custom theming and styling is simple to do using just CSS and JavaScript, and there are some themes available already for you to choose.

If you want custom HTML or a provider for which we don't have support yet, that's easy to add. Please let's us know using the chat below! No lock-in

The code that renders the sites is just a very minimal sitio script with the plugins you choose. These are all open-source and you can export your site and render it by yourself if you don't want to use sítios.xyz anymore.

• http://web.archive.org/web/20180416143134/https://sitios.xyz/
• https://github.com/fiatjaf/sitios.xyz

• clients can't programatically build new offers by changing a path or query params (services like zbd.gg or lnurl-pay.me won't work)
• impossible to use in a load-balanced custodian way -- since offers would have to be pregenerated and tied to a specific lightning node.
• the existence of fiat currency fields makes it so wallets have to fetch exchange rates from somewhere on the internet (or offer a bad user experience), using HTTP which hurts user privacy.
• the vendor field is misleading, can be phished very easily, not as safe as a domain name.
• onion messages are an improvement over fake HTLC-based payments as a way of transmitting data, for sure. but we must decide if they are (i) suitable for transmitting all kinds of data over the internet, a replacement for tor; or (ii) not something that will scale well or on which we can count on for the future. if there was proper incentivization for data transmission it could end up being (i), the holy grail of p2p communication over the internet, but that is a very hard problem to solve and not guaranteed to yield the desired scalability results. since not even hints of attempting to solve that are being made, it's safer to conclude it is (ii).

bolt12 limitations

• not flexible enough. there are some interesting fields defined in the spec, but who gets to add more fields later if necessary? very unclear.
• services can't return any actionable data to the users who paid for something. it's unclear how business can be conducted without an extra communication channel.

bolt12 illusions

• recurring payments is not really solved, it is just a spec that defines intervals. the actual implementation must still be done by each wallet and service. the recurring payment cannot be enforced, the wallet must still initiate the payment. even if the wallet is evil and is willing to initiate a payment without the user knowing it still needs to have funds, channels, be online, connected etc., so it's not as if the services could rely on the payments being delivered in time.
• people seem to think it will enable pushing payments to mobile wallets, which it does not and cannot.
• there is a confusion of contexts: it looks like offers are superior to lnurl-pay, for example, because they don't require domain names. domain names, though, are common and well-established among internet services and stores, because these services have websites, so this is not really an issue. it is an issue, though, for people that want to receive payments in their homes. for these, indeed, bolt12 offers a superior solution -- but at the same time bolt12 seems to be selling itself as a tool for merchants and service providers when it includes and highlights features as recurring payments and refunds.
• the privacy gains for the receiver that are promoted as being part of bolt12 in fact come from a separate proposal, blinded paths, which should work for all normal lightning payments and indeed are a very nice solution. they are (or at least were, and should be) independent from the bolt12 proposal. a separate proposal, which can be (and already is being) used right now, also improves privacy for the receiver very much anway, it's called trampoline routing.

Nostr is a description of a message format called "event" that is cryptographically signed and the description of public communication interface that can be offered by servers called "relays".

Armed with such two descriptions anyone can write programs called "clients" that run on people's computers and can send and receive "events" to and from the "relays".

Some people, once they learn this, start thinking of Nostr as a set of free servers that are readable and writable by everyone.

From that may come questions such as: "who will run these relays?"; or concerns like: "how can this be censorship-resistant if you can just take down the relays?".

Don't be one of these people.

Nostr is not any specific set of relays, and relays are not meant to be public or free. Remember from the first paragraph above: Nostr is just a description of an interface. What does that mean? It means that if you send a message to a relay saying hello mr relay please send me the messages you have it will not understand that message and will probably ignore you. But if you send a message like ["REQ", "z", {"limit":10}] then it will understand and will send you 10 events.

There are other types of messages relays will understand, but that is basically all that there is to it.

If a relay will be free or not that depends on what the program running on the relay server decides to do.

If a relay will store your event specifically that depends on what the program running on the relay server decides to do.

If a relay will delete your event after a while or store it in 32 redundant copies that depends on what the program running on the relay server decides to do.

If a relay will allow anyone to read any event they might have or if they will only allow some people to do that it will depend on... you get the idea.

A idéia central da “política da prudência¹” de Russell Kirk me parece muito correta, embora tenha sido melhor formulada pior no seu enorme livro do que em uma pequena frase do joanadarquista Lucas Souza: “o conservadorismo é importante, porque tem muita gente com idéia errada por aí, e nós podemos não saber distingüi-las”.

Porém, há alguns problemas que precisam ser esclarecidos, ou melhor explicados, e que me impedem de enxergar os seus argumentos como refutação final do meu já tão humilde (embora feroz) anarquismo. São eles:

I Percebo alguma coisa errada, não sei bem onde, entre a afirmação de que toda ideologia é ruim, ou “todas as ideologias causam confusão²”, e a proposta conservadora de “conservar o mundo da ordem que herdamos, ainda que em estado imperfeito, de nossos ancestrais³”. Ora, sem precisar cair em exemplos como o do partido conservador inglês -- que conservava a política inglesa sempre onde estava, e se alternava no governo com o partido trabalhista, que a levava cada vez mais um pouco à esquerda --, está embutida nessa frase, talvez, a idéia, que ao mesmo tempo é clara e ferrenhamente combatida pelos próprios conservadores, de que a história é da humanidade é uma história de progresso linear rumo a uma situação melhor.

Querer conservar o mundo da ordem que herdamos significa conservar também os vários erros que podem ter sido cometidos pelos nossos ancestrais mais recentes, e conservá-los mesmo assim, acusando toda e qualquer tentativa de propôr soluções a esses erros de ideologia? Ou será que conservar o mundo da ordem é escolher um período determinado que seja tido como o auge da história humana e tentar restaurá-lo em nosso próprio tempo? Não seria isto ideologia?

Ou, ainda, será que conservar o mundo da ordem é selecionar, entre vários períodos do passado, alguns pedaços que o conservador considerar ótimos em cada sociedade, fazer dali uma mistura de sociedade ideal baseada no passado e então tentar implementá-la? Quem saberia dizer quais são as partes certas?

II Sobre a questão do que mantém a sociedade civil coesa, Russell Kirk, opondo-a à posição libertária de que o nexo da sociedade é o autointeresse, declara que a posição conservadora é a de que “a sociedade é uma comunidade de almas, que une os mortos, os vivos e os ainda não nascidos, e que se harmoniza por aquilo que Aristóteles chamou de amizade e os cristãos chamam de caridade ou amor ao próximo”.

Esta é uma posição muito correta, mas me parece estar em contradição com a defesa do Estado que ele faz na mesma página e na seguinte. O que me parece errado é que a sociedade não pode ser, ao mesmo tempo, uma “comunidade baseada no amor ao próximo” e uma comunidade que “requer não somente que as paixões dos indivíduos sejam subjugadas, mas que, mesmo no povo e no corpo social, bem como nos indivíduos, as inclinações dos homens, amiúde, devam ser frustradas, a vontade controlada e as paixões subjugadas” e, pior, que “isso somente pode ser feito por um poder exterior”.

Disto aí podemos tirar que, da mesma forma que Kirk define a posição libertária como sendo a de que o autointeresse é que mantém a sociedade civil coesa, a posição conservadora seria então a de que essa coesão vem apenas do Estado, e não de qualquer ligação entre vivos e mortos, ou do amor ao próximo. Já que, sem o Estado, diz, ele, citando Thomas Hobbes, a condição do homem é “solitária, pobre, sórdida, embrutecida e curta”?

Todo guia infeliz sobre Bitcoin começa com esta pergunta manjada, e normalmente já vai respondendo que é uma "moeda virtual"¹, um conceito estúpido que não esclarece nada.

Esqueça esse papo. Bitcoin não é uma moeda. Bitcoin é um protocolo².

Por que então dizem que é uma moeda? Porque essas pessoas muito apressadinhas gostam de dizer que tudo que é facilmente divisível e transferível, e cujas várias unidades são idênticas umas às outras, é uma moeda. Então, nesse sentido, Bitcoin é uma moeda, mas ignore esse papo de moeda.

O protocolo Bitcoin diz que existem "créditos" (ou "pontos", ou "unidades") que podem ser transferidas entre os participantes, e vários computadores, cada um operando independentemente do outro, desde que sigam o protocolo (ou seja: que estejam todos rodando o mesmo programa, ou programas compatíveis), estarão sempre em acordo a respeito de quem gastou cada crédito e como gastou.

É basicamente essa a idéia: um monte de "pontos virtuais" que são transferidos de uns para outros, sem que exista uma entidade organizadora, "o dono do Bitcoin", "o chefe supremo do Bitcoin", que controle nada, coordene nada, ou tenha poder sobre essas transferências.

Como funciona

Imagine vários computadores rodando o mesmo programa (ou programas compatíveis). Agora imagine que esses programas se comunicam entre si através da internet: eles enviam mensagens uns para os outros e esperam respostas. De vez em quando a resposta não vem, ou vem num formato que o programa não entende, isso significa que o outro computador saiu do ar, ou está rodando uma versão incompatível do programa, e aí todos os outros vão ignorá-lo. Mas em geral a resposta vem certinha e todos conseguem falar com todos.

Agora que você imaginou isso, fica fácil imaginar, por exemplo, que cada um desses computadores mantém uma lista de todos os bitcoins existentes e quem tem cada um. Eles pegam a lista dos outros computadores na rede e depois a vão atualizando à medida que novas transações vão sendo feitas. Toda vez que alguém quer fazer alguma transação, ele deve fazê-la por meio de um desses computadores, a pessoa chega no computador que está rodando o programa e diz: "sou fulano, tenho x bitcoins, e quero enviá-los para tal lugar", o programa vai lá e envia essa mensagem para os outros computadores, que atualizam a sua lista. Fim.

Essa seria uma versão ingênua do protocolo, que funcionaria se todos os participantes fossem muito honestos e ninguém jamais tentasse gastar os bitcoins que não têm.

Pra uma coisa dessas funcionar no mundo real teve de entrar a grande invenção do Bitcoin, o insight genial do Satoshi Nakamoto, que é a tal cadeia de blocos, conhecida por aí como blockchain.

Funciona assim: ao invés de cada computador manter uma lista de onde está cada bitcoin, cada computador mantém a tal cadeia de blocos. Um "bloco" é só um nome bonitinho para um conjunto de dados. Cada bloco é composto por uma referência ao bloco anterior e uma lista de transações. Como eles contém uma referência ao anterior, existe uma seqüência, uma fila indiana, e o computador pode ficar tranqüilo sabendo a ordem das transações (as transações que aconteceram no terceiro bloco são posteriores às que aconteceram no segundo bloco, por exemplo) e saber que os mesmos bitcoins não foram gastos duas vezes seguidas pela mesma pessoa, o que seria inválido. Quando aparece um novo bloco, é só todos os computadores conferirem se não existe nenhuma transação inválida ali e, caso exista, rejeitarem aquele bloco por inteiro e esperarem que o próximo descarte aquela transação inválida e venha certinho.

Quem faz os blocos

Em tese, qualquer um dos computadores pode fazer o próximo bloco. A idéia é que cada pessoa que queira fazer uma transação vai lá e usa um computador da rede para enviar a sua proposta de transação ("quero transferir bitcoins para tal lugar e tal") para todos os demais, e que, quando alguém for fazer um bloco, pegue todas essas propostas de transação que forem válidas e as coloque no bloco que então será aceito por todos os outros computadores e incluído na cadeia global de blocos. Essa cadeia global tem que ser exatamente igual em todos os computadores.

Na prática, existe uma regra que faz com que nem todos consigam fazer blocos: é que o hash dos dados do bloco + um número mágico deve ser menor do que um valor muito pequeno x. O número mágico é um número qualquer que o computador que está tentando fazer o bloco pode ajustar, por tentativa e erro, para que o hash saia de um jeito que ele queira. O x pode ser maior ou menor de acordo com a freqüência dos últimos blocos produzidos. Quanto menor for x, mais estatisticamente difícil é encontrar um número mágico que, junto com os dados do bloco, tenha um hash menor do que x.

Ou seja: para fazer um bloco, muitos números mágicos diferentes devem ser tentados até que seja encontrado algum que satisfaça as condições.

O que é um hash? Um hash é uma função matemática que é fácil fazer para um lado e difícil de fazer para o outro. A multiplicação, por exemplo, é fácil de fazer e fácil de fazer, e sua operação contrária, a divisão, também (tanto é que qualquer um com papel e caneta consegue, tem aquela coisa de ir passando os números pra baixo e subtraindo e tal). Já uma operação de exponenciação -- um número elevado a 1000, por exemplo -- é fácil de fazer, mas pra desfazer só com tentativa e erro (e é por tentativa e erro que o computador ou a calculadora fazem).

No caso do Bitcoin, o computador que está tentando produzir um bloco tem que achar um número tal que (esse número mágico + fatores predeterminados do bloco) elevados a 50 resultem num valor menor do que fator de dificuldade, um outro fator predeterminado pelo estado geral da cadeia de blocos.

Suponha que um computador acha um número 1798465042647412146620280340569649349251249, por exemplo, e ele é menor do que o fator de dificuldade. Ele então diz para os outros: "aqui está meu bloco, o hash do meu bloco é 1798465042647412146620280340569649349251249, os fatores predeterminados do bloco são 4 (esses fatores todo mundo pode conferir), e meu número mágico é 3. (4 + 3) elevado a 50 é 1798465042647412146620280340569649349251249, como todos podem conferir, então meu bloco é válido". Então todos aceitam aquele bloco como válido e começam a tentar achar o número mágico para o próximo bloco (e desta vez os fatores do bloco são diferentes, já que um novo bloco foi adicionado à cadeia e fez com que tudo mudasse).

As regras para a definição de x fazem com que na média cada novo bloco fique pronto em 10 minutos. Logo, se há apenas um computador tentando produzir blocos, o protocolo dirá que x seja relativamente alto, de modo que esse computador conseguirá, em 10 minutos, na média, encontrar um número mágico. Se, porém, milhares de computadores superpotentes estiverem tentando produzir blocos, x será ajustado para um valor muito mais baixo, de modo que o esforço de todos esses computadores fazendo milhares de tentativas-e-erros por segundo só conseguirá encontrar um número mágico a cada 10 minutos.

Hoje existem computadores feitos especialmente para procurar números mágicos que conseguem calcular hashes muito mais rápido do que o seu computador caseiro, o que torna inviável que qualquer pessoa não especializada tente produzir blocos, veja este gráfico da evolução da quantidade de hashes que são tentados a cada segundo.

Por algum motivo convencionou-se chamar os computadores que se empenham em fazer novos blocos de "mineradores".

Se dois computadores da rede fizerem blocos ao mesmo tempo, qual dos dois vale?

Se você já sabe quem faz os blocos fica fácil imaginar que isso é um pouco improvável. Mas mesmo assim pode acontecer. Mesmo que os blocos não fiquem prontos exatamente no mesmo instante, problemas podem acontecer porque os outros computadores da rede receberão os dois novos blocos em ordens diferentes, e aí não vai dar pra determinar qual vale ou qual deixa de valer assim, pela ordem.

Os computadores então ficam num estado de indeterminação acerca das duas cadeias de blocos possíveis, A e B, digamos, ambas idênticas até o bloco de número 723, mas diferentes no que diz respeito ao bloco 724, para o qual há duas alternativas. O protocolo determina que a cadeia que tenha mais trabalho realizado é a que vale, mas durante algum tempo podemos ter um estado em que alguns computadores da rede só sabem da existência do bloco A, enquanto outros só sabem da existência do bloco B, o que é uma grande confusão que só pode ser resolvida pelo advento do próximo bloco, o 725.

Como cada bloco se refere a um bloco anterior, é necessário que um desses dois blocos 724 seja escolhido pelos mineradores para ser o "pai" do bloco 725 quando o número mágico for encontrado e ele for feito. Mesmo que cada minerador escolha um pai diferente, desse processo sairá provavelmente apenas um bloco 725, e quando ele for espalhado ele determinará, pela sua ascendência, qual foi o bloco 724 que ficou valendo. Caso dois ou mais blocos 725 sejam produzidos ao mesmo tempo, o sistema continua nesse estado de indecisão até o 726, e assim por diante.

Por este motivo não se deve confiar que uma transação está concretizada pra valer mesmo só porque ela foi incluída num bloco. Você não tem como saber se existe um outro bloco alternativo que será preferido ao seu até que pelo menos mais alguns blocos tenham sido adicionados.

Transações

Muitas pessoas acreditam que existem endereços e que esses endereços têm um dono e ele é o dono dos bitcoins. Esta crença errônea é resultado de uma analogia com bancos tradicionais e contas bancárias (as contas são endereços que têm um dono e guardam dinheiro).

Na verdade assim que as transações são incluídas num bloco elas não "ficam em um endereço", mas vagando num grande limbo de transações. Deste limbo elas podem ser retiradas por qualquer pessoa que cumpra as condições que foram previamente especificadas pelo criador da transação.

Uma analogia mais útil do que a analogia das contas bancárias é a analogia do dinheiro: imagine que você tem uma nota de 20 dinheiros e você quer usá-la pra pagar 10 dinheiros a outrem. Você precisa quebrar aquela nota de 20 em duas de 10 e aí uma fica com você e a outra com a outra pessoa, ou, se você tiver duas notas de 5, você pode juntar as duas e dar para a outra pessoa. Todas essas notas que você está gastando têm uma história prévia: elas vieram de algum lugar em algum momento para o seu controle.

Transações com Bitcoin também são assim: você precisa mencionar especificamente uma transação anterior.

Por exemplo,

1. Carlos paga 10 bitcoins a Dandara, Dandara agora tem uma transação no valor de 10
2. Elisa paga 17 bitcoins a Dandara, Dandara tem uma transação no valor de 10 e uma no valor de 17
3. Dandara paga 23 bitcoins a Felipe, ela junta suas duas transações e faz duas novas, uma no valor de 23, que vai para o controle de Felipe, e outra no valor de 4, que volta para o seu controle, Dandara agora tem uma transação no valor de 4, Felipe tem uma transação no valor de 23
4. Felipe paga 14 bitcoins a Geraldo, ele divide sua transação em duas, uma no valor de 14 e outra no valor de 9, e assim por diante

Uma diferença, porém, é que no Bitcoin ninguém sabe quem é o dono da nota, você apenas sabe que pode gastá-la, caso você realmente possa (se uma transação prévia especifica uma condição que você pode cumprir, você deve cumprir aquela condição no momento em que estiver mencionando a transação prévia). Por isso uma carteira Bitcoin pode dizer que você "tem" um número x de bitcoins: a carteira sabe quais chaves privadas você controla e quais transações, dentre todas as transações não-gastas de toda a blockchain, podem ser gastas usando aquela chave.

Uma forma comum de transação é que especifica a condição qualquer pessoa que tiver a chave privada capaz de assinar a chave pública cujo hash vai aqui dito pode gastar esta transação. Outras condições comuns são as que especificam n chaves, das quais m precisam assinar a transação para que ela seja gasta (por exemplo, entre Fulano, Beltrano e Ciclano, quaisquer dois deles precisam concordar, mas não um só), o famoso multisig.

Canal de pagamento

Um payment channel, ou via de pagamento, ou canal de pagamento é uma seqüência de promessas de pagamento feitas entre dois usuários de Bitcoin que não precisam ser publicados na blockchain e por isso são instantâneas e grátis.

Antes que você se pergunte o que acontece se alguém descumprir a promessa, devo dizer que "promessa" é um termo ruim, porque promessas de verdade podem ser quebradas, mas estas promessas são auto-cumpríveis, elas são transações assinadas que podem ser resgatadas a qualquer momento pelo destinatário bastando que ele as publique na blockchain.

A idéia é que na maioria das vezes você não vai precisar disso, e pode continuar fazendo transações novas que invalidam as antigas até que você decida publicar a última transação válida. Deste modo seu dinheiro está seguro numa via de pagamento

O grande problema é que caso a outra parte decida roubar e publicar uma transação antiga, você precisa aparecer num espaço de tempo razoável (isto depende do combinado entre os dois usuários, mas acho que o padrão é 24 horas) e publicar a última transação. Existem incentivos para impedir que alguém tente roubar (por exemplo, quem tentar roubar e for pego perde todo o dinheiro que estava naquela via) e outros mecanismos, como as atalaias que vigiam as vias de pagamentos dos outros pra ver se ninguém está roubando.

Exemplo:

1. Ângela e Bóris decidem criar uma via de pagamento, pois esperam realizar muitos pagamentos de pequeno valor entre eles, tanto de ida quanto de volta, ao longo de vários meses
2. Ângela cria uma transação para um endereço compartilhado entre ela e Bóris, no valor de 1000 satoshis, e desse endereço ela e Bóris criam uma transação devolvendo os 1000 para Ângela
3. Ao resolver pagar 200 satoshis para Bóris, eles criam uma nova transação que transfere 800 para Ângela e 200 para Bóris
4. Agora Bóris quer pagar 17 satoshis para Ângela, eles criam uma nova transação que transfere 817 para Ângela e 173 para Bóris
5. E assim por diante eles vão criando novas transações que invalidam as anteriores e vão alterando o "saldo" da via de pagamento. Quando qualquer um dos dois quiser sacar o dinheiro que tem no saldo é só publicar a última transação e pronto.

A rede Relâmpago é uma grande rede de canais de pagamento que permite que pessoas façam pagamentos para pessoas não diretamente ligadas a elas por canais diretos, mas através de uma rota que percorre vários canais de outrem e ajusta seus saldos.

Existem outras criptomoedas além do Bitcoin?

Pra começar, jamais use essa palavra de novo. "criptomoeda" é ainda pior do que "moeda virtual"¹.

Agora, respondendo: sim, de certo modo existem, são chamadas as "altcoins" ou "shitcoins" ("moedas de cocô", tradução amigável), porque elas são, de fato, grandes porcarias.

De outro modo, pode-se dizer que elas não são comparáveis ao Bitcoin, porque só pode haver uma moeda num livre mercado de moedas, e esse posto já é do Bitcoin, e também porque o Bitcoin é livre, sem donos, sem grandes poderes que o controlam, o que não se pode dizer de nenhuma altcoin.

Depois que o Bitcoin foi inventado e seu insight genial foi assimilado pela comunidade interessada, milhares de pessoas copiaram o protocolo, com pequenas modificações, para criar suas próprias moedas.

Assim surgiram Litecoin, Ethereum e muitas outras. No fundo são apenas cópias do Bitcoin que tentam melhorá-lo de algum modo ou adicionar outras funções.

Veja também:

• Aos poucos, e aí tudo de uma vez, Parker Lewis
• Não tem solução
• A podridão
• O Bitcoin como um sistema social humano
• Rede Relâmpago

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

Agora esqueci o nome do conto de Jorge Luis Borges em que a tal biblioteca é descrita, ou seus detalhes específicos. Eu tinha lido o conto e nunca havia percebido que ele matava a questão da aleatoriedade ser capaz de produzir coisas valiosas. Precisei mesmo da Wikipédia me dizer isso.

Alguns anos atrás levantei essa questão para um grupo de amigos sem saber que era uma questão tão batida e baixa. No meu exemplo era um cachorro andando sobre letras desenhadas e não um macaco numa máquina de escrever. A minha conclusão da discussão foi que não importa o que o cachorro escrevesse, sem uma inteligência capaz de compreender aquilo nada passaria de letras aleatórias.

Borges resolve tudo imaginando uma biblioteca que contém tudo o que o cachorro havia escrito durante todo o infinito em que fez o experimento, e portanto contém todo o conhecimento sobre tudo e todas as obras literárias possíveis -- mas entre cada página ou frase muito boa ou pelo menos legívei há toneladas de livros completamente aleatórios e uma pessoa pode passar a vida dentro dessa biblioteca que contém tanto conhecimento importante e mesmo assim não aprender nada porque nunca vai achar os livros certos.

Everything would be in its blind volumes. Everything: the detailed history of the future, Aeschylus' The Egyptians, the exact number of times that the waters of the Ganges have reflected the flight of a falcon, the secret and true nature of Rome, the encyclopedia Novalis would have constructed, my dreams and half-dreams at dawn on August 14, 1934, the proof of Pierre Fermat's theorem, the unwritten chapters of Edwin Drood, those same chapters translated into the language spoken by the Garamantes, the paradoxes Berkeley invented concerning Time but didn't publish, Urizen's books of iron, the premature epiphanies of Stephen Dedalus, which would be meaningless before a cycle of a thousand years, the Gnostic Gospel of Basilides, the song the sirens sang, the complete catalog of the Library, the proof of the inaccuracy of that catalog. Everything: but for every sensible line or accurate fact there would be millions of meaningless cacophonies, verbal farragoes, and babblings. Everything: but all the generations of mankind could pass before the dizzying shelves – shelves that obliterate the day and on which chaos lies – ever reward them with a tolerable page.

Tenho a impressão de que a publicação gigantesca de artigos, posts, livros e tudo o mais está transformando o mundo nessa biblioteca. Há tanta coisa pra ler que é difícil achar o que presta. As pessoas precisam parar de escrever.

Made with jq-web, a tool to explore JSON using jq that works like jiq.

• https://jq.alhur.es/jiq/
• https://github.com/fiatjaf/jiq-web

See also

• jq-finder

Drivechain is, in essence, just a way to give Bitcoin users the option to deposit their coins in a hashrate escrow. If Bitcoin is about coin ownership, in theory there should be no objection from anyone on users having the option to do that: my keys, my coins etc. In other words: even if you think hashrate escrows are a terrible idea and miners will steal all coins from that, you shouldn't care about what other people do with their own money.

There are only two reasonable objections that could be raised by normal Bitcoin users against Drivechain:

1. Drivechain adds code complexity to bitcoind
2. Drivechain perverts miner incentives of the Bitcoin chain

If these two objections can be reasonably answered there remains no reason for not activating the Drivechain soft-fork.

1

To address 1 we can just take a look at the code once it's done (which I haven't) but from my understanding the extra validation steps needed for ensuring hashrate escrows work are very minimal and self-contained, they shouldn't affect anything else and the risks of introducing some catastrophic bug are roughly zero (or the same as the risks of any of the dozens of refactors that happen every week on Bitcoin Core).

For the BMM/BIP-301 part, again the surface is very small, but we arguably do not need that at all, since anyprevout (once that is merged) enables blind merge-mining in way that is probably better than BIP-301, and that soft-fork is also very simple, plus already loved and accepted by most of the Bitcoin community, implemented and reviewed on Bitcoin Inquisition and is live on the official Bitcoin Core signet.

2

To address 2 we must only point that BMM ensures that Bitcoin miners don't have to do any extra work to earn basically all the fees that would come from the sidechain, as competition for mining sidechain blocks would bid the fee paid to Bitcoin miners up to the maximum economical amount. It is irrelevant if there is MEV on the sidechain or not, everything that reaches the Bitcoin chain does that in form of fees paid in a single high-fee transaction paid to any Bitcoin miner, regardless of them knowing about the sidechain or not. Therefore, there are no centralization pressure or pervert mining incentives that can affect Bitcoin land.

Sometimes it's argued that Drivechain may facilitate the ocurrence of a transaction paying a fee so high it would create incentives for reorging the Bitcoin chain. There is no reason to believe Drivechain would make this more likely than an actual attack than anyone can already do today or, as has happened, some rich person typing numbers wrong on his wallet. In fact, if a drivechain is consistently paying high fees on its BMM transactions that is an incentive for Bitcoin miners to keep mining those transactions one after the other and not harm the users of sidechain by reorging Bitcoin.

Moreover, there are many factors that exist today that can be seen as centralization vectors for Bitcoin mining: arguably one of them is non-blind merge mining, of which we have a (very convoluted) example on the Stacks shitcoin, and introducing the possibility of blind merge-mining on Bitcoin would basically remove any reasonable argument for having such schemes, therefore reducing the centralizing factor of them.

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

Bluesky advertises itself as an open network, they say people won't lose followers or their identity, they advertise themselves as a protocol ("atproto") and because of that they are tricking a lot of people into using them. These three claims are false.

protocolness

Bluesky is a company. "atproto" is the protocol. Supposedly they are two different things, right? Bluesky just releases software that implements the protocol, but others can also do that, it's open!

And yet, the protocol has an official webpage with a waitlist and a private beta? Why is the protocol advertised as a company product? Because it is. The "protocol" is just a description of whatever the Bluesky app and servers do, it can and does change anytime the Bluesky developers decide they want to change it, and it will keep changing for as long as Bluesky apps and servers control the biggest part of the network.

Oh, so there is the possibility of other players stepping in and then it becomes an actual interoperable open protocol? Yes, but what is the likelihood of that happening? It is very low. No serious competitor is likely to step in and build serious apps using a protocol that is directly controlled by Bluesky. All we will ever see are small "community" apps made by users and small satellite small businesses -- not unlike the people and companies that write plugins, addons and alternative clients for popular third-party centralized platforms.

And last, even if it happens that someone makes an app so good that it displaces the canonical official Bluesky app, then that company may overtake the protocol itself -- not because they're evil, but because there is no way it cannot be like this.

identity

According to their own documentation, the Bluesky people were looking for an identity system that provided global ids, key rotation and human-readable names.

They must have realized that such properties are not possible in an open and decentralized system, but instead of accepting a tradeoff they decided they wanted all their desired features and threw away the "decentralized" part, quite literally and explicitly (although they make sure to hide that piece in the middle of a bunch of code and text that very few will read).

The "DID Placeholder" method they decided to use for their global identities is nothing more than a normal old boring trusted server controlled by Bluesky that keeps track of who is who and can, at all times, decide to ban a person and deprive them from their identity (they dismissively call a "denial of service attack").

They decided to adopt this method as a placeholder until someone else doesn't invent the impossible alternative that would provide all their desired properties in a decentralized manner -- which is nothing more than a very good excuse: "yes, it's not great now, but it will improve!".

openness

Months after launching their product with an aura of decentralization and openness and getting a bunch of people inside that believed, falsely, they were joining an actually open network, Bluesky has decided to publish a part of their idea of how other people will be able to join their open network.

When I first saw their app and how they were very prominently things like follower counts, like counts and other things that are typical of centralized networks and can't be reliable or exact on truly open networks (like Nostr), I asked myself how were they going to do that once they became and open "federated" network as they were expected to be.

Turns out their decentralization plan is to just allow you, as a writer, to host your own posts on "personal data stores", but not really have any control over the distribution of the posts. All posts go through the Bluesky central server, called BGS, and they decide what to do with it. And you, as a reader, doesn't have any control of what you're reading from either, all you can do is connect to the BGS and ask for posts. If the BGS decides to ban, shadow ban, reorder, miscount, hide, deprioritize, trick or maybe even to serve ads, then you are out of luck.

Oh, but anyone can run their own BGS!, they will say. Even in their own blog post announcing the architecture they assert that "it’s a fairly resource-demanding service" and "there may be a few large full-network providers". But I fail to see why even more than one network provider will exist, if Bluesky is already doing that job, and considering the fact there are very little incentives for anyone to switch providers -- because the app does not seem to be at all made to talk to multiple providers, one would have to stop using the reliable, fast and beefy official BGS and start using some half-baked alternative and risk losing access to things.

When asked about the possibility of switching, one of Bluesky overlords said: "it would look something like this: bluesky has gone evil. there's a new alternative called freesky that people are rushing to. I'm switching to freesky".

The quote is very naïve and sounds like something that could be said about Twitter itself: "if Twitter is evil you can just run your own social network". Both are fallacies because they ignore the network-effect and the fact that people will never fully agree that something is "evil". In fact these two are the fundamental reasons why -- for social networks specifically (and not for other things like commerce) -- we need truly open protocols with no owners and no committees.

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
}

In 8 points¹:

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

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.

Nostr doesn't subscribe to any ideals of "free speech" as these belong to the realm of politics and assume a big powerful government that enforces a common ruleupon everybody else.

Nostr instead is much simpler, it simply says that servers are private property and establishes a generalized framework for people to connect to all these servers, creating a true free market in the process. In other words, Nostr is the public road that each market participant can use to build their own store or visit others and use their services.

(Of course a road is never truly public, in normal cases it's ran by the government, in this case it relies upon the previous existence of the internet with all its quirks and chaos plus a hand of government control, but none of that matters for this explanation).

More concretely speaking, Nostr is just a set of definitions of the formats of the data that can be passed between participants and their expected order, i.e. messages between clients (i.e. the program that runs on a user computer) and relays (i.e. the program that runs on a publicly accessible computer, a "server", generally with a domain-name associated) over a type of TCP connection (WebSocket) with cryptographic signatures. This is what is called a "protocol" in this context, and upon that simple base multiple kinds of sub-protocols can be added, like a protocol for "public-square style microblogging", "semi-closed group chat" or, I don't know, "recipe sharing and feedback".

Ao descer de seu ônibus na rodoviária de Belo Horizonte às 4 e pouco da manhã, darás de frente para um caubói que toma cerveja em seus trajes típicos em um bar no setor mesmo de desembarque. Suba a escada à direita que dá no estacionamento da rodoviária. Vire à esquerda e caminhe por mais ou menos 400 metros, atravessando uma área onde pessoas suspeitas -- mas provavelmente dormindo em pé -- lhe observam, e então uma pracinha ocupada por um clã de mendigos. Ao avistar um enorme obelisco no meio de um cruzamento de duas avenidas, vire à esquerda e caminhe por mais 400 metros. Você verá uma enorme, antiga e bela estação com uma praça em frente, com belas fontes aqüáticas. Corra dali e dirija-se a um pedaço de rua à direita dessa praça. Um velho palco de antigos carnavais estará colocado mais ou menos no meio da simpática ruazinha de parelepípedos: é onde você pegará seu próximo ônibus.

Para entrar na estação é necessário ter um cartão com créditos recarregáveis. Um viajante prudente deixa sempre um pouco de créditos em seu cartão a fim de evitar filas e outros problemas de indisponibilidade quando chega cansado de viagem, com pressa ou em horários incomuns. Esse tipo de pessoa perceberá que foi totalmente ludibriado ao perceber que que os créditos do seu cartão, abastecido quando de sua última vinda a Belo Horizonte, há três meses, pereceram de prazo de validade e foram absorvidos pelos cofre públicos. Terá, portanto, que comprar mais créditos. O guichê onde os cartões são abastecidos abre às 5h, mas não se espante caso ele não tenha sido aberto ainda quando o primeiro ônibus chegar, às 5h10.

Com alguma sorte, um jovem de moletom, autorizado por dois ou três fiscais do sistema de ônibus que conversam alegremente, será o operador da catraca. Ele deixa entrar sem pagar os bêbados, os malandros, os pivetes. Bastante empático e perceptivo do desespero dos outros, esse bom rapaz provavelmente também lhe deixará entrar sem pagar.

Uma vez dentro do ônibus, não se intimide com os gritalhões e valentões que, ofendidíssimos com o motorista por ele ter parado nas estações, depois dos ônibus anteriores terem ignorado esses excelsos passageiros que nelas aguardavam, vão aos berros tirar satisfação.

O ponto final do ônibus, 40 minutos depois, é o terminal Morro Alto. Lá você verá, se procurar bem entre vários ônibus e pessoas que despertam a sua mais honesta suspeita, um veículo escuro, apagado, numerado 5882 e que abrigará em seu interior um motorista e um cobrador que descansam o sono dos justos.

Aguarde na porta por mais uns vinte minutos até que, repentinamente desperto, o motorista ligue o ônibus, abra as portas e já comece, de leve, a arrancar. Entre correndo, mas espere mais um tempo, enquanto as pessoas que têm o cartão carregado passem e peguem os melhores lugares, até que o cobrador acorde e resolva te cobrar a passagem nesse velho meio de pagamento, outrora o mais líqüído, o dinheiro.

Este último ônibus deverá levar-lhe, enfim, a Lagoa Santa.

Currently (and probably it has always been the case) in the Bitcoin community there is some push towards donations as some sort of business model, or in general just a general love for the idea of donations, and I think that is very misguided.

Two examples of the push for the primacy of donations

For example, there is a general wantness of people to have some sort of "static QR code" or "static Lightning invoice" that people can put on their Twitter profiles to receive donations (sometimes they say "payments" instead of "donations" but to me there is no such a thing as a payment without a good or service being given in exchange, so I'm saying "donations") and that is a hard problem to solve considering the fact that most Lightning wallets are running on phones.

Another example is the "Podcasting 2.0" initiative that tries to integrate podcast players with Lightning wallets so they can send donations to podcast hosts that are running Lightning nodes. Their proponents call it "value for value" (or "value4value", "v4v") and if you ask they will say value4value is a "model" in which the listener gives out in satoshis to the podcast host the same amount of "value" he is getting from listening to that content.

The value4value concept makes it almost explicit the problems I see with this big emphasis on donations the Bitcoin community is making in general. In essence, the idea that the listener is capable of measuring the value it gets from the podcast then converting it into a monetary amount and then donating that is completely wrong and even nonsensical.

Why value4value is not sound

Basic (Austrian) economics teaches us that all value is ordinal, not cardinal -- i.e., it can't be measured or assigned a number to. One can only know that at some instant they prefer x over y, they cannot say x has a value of 10 and y has a value of 9. Because of that, it's a nonsense quest to try determine how much value one is getting from a podcast.

Basic (Austrian) economics also teaches us that exchanges happen when there are differences in the subjective valuations of goods, i.e., Alice can give x to Bob in exchange for y if Alice prefers y over x and Bob prefers x over y at that point. Because of that (and disregarding the previous paragraph), it's futile to expect that the podcast listener will donate exactly the amount he is getting from the podcast in "value".

Because of the two points above, it should also be clear that it is impossible to convert "value" in podcast content form into "value" in satoshis form, but I won't try to explain why that is because this is not an economics textbook.

What actually happens is that whether it's in the value4value context or not, donations are always a somewhat random and subjective amount, if they happen. If I like some content that someone is publishing for free, my decision on if and how much I will donate is never dictated by some nonsense calculation, but by calculation that is governed almost entirely by feeling and animal spirits (but one that also considers how much money I can spare, how much I like that person and how much I perceive they need).

When I go to a normal shop to buy a bottle of milk I look at the bottle of milk and I read its price, and there is one simple decision I have to make: is this bottle of milk worth more than the amount of money that's specified in the price tag? It's a single decision with only two answers: yes or no.

While when I see a free form on some free "creator" page asking me to type how much I will donate I have to decide if I will donate, when I will donate, how much I will donate, if I want this donation to be done every month or how will that work going forward? Will I keep consuming the content produced by this person? Will they keep producing? Maybe I'll just listen for free now and do this later as I'm busy, but then will I forget? Maybe I have just donated a lot to someone else and do not have much more money to spare, but now I feel guilty that the other person got all my donation money and this one didn't get anything but I can't go back and ask the other to return the money I just donated -- and so on and so forth.

Conclusions

Although the paragraphs above are confusing and do not follow a very logical presentation pattern, I hope you got from them why I think donations are much more complicated than purchases, and that repeating the "value for value" mantra doesn't help at all.

Considering that, what I wanted to say is that bitcoiners should give more attention to the other model, in which people produce goods and services and sell them. And that model can be applied successfully to "content creators", podcasters etc in many ways that are probably (I don't have any data backing my claims) better than the donation model.

Other possible monetization possibilities

For example, I've noticed that many blogs and podcasts with interesting content start to release exclusive episodes as they get big enough. These exclusive episodes are available only for "supporters". This is effectively selling access to the episodes. There is also the "crowdwall" model in which multiple people pay so that some content gets released for free.

We can count even the model in which a donation is not just a blank donation, but gives the donor the right to write something on the screen or something like that -- these are actually not just donations, but purchases of these rights.

Professional videogame streamers have come up with some other interesting ideas. For example, they crowdfund the creation of special content ("if enough people pay I will dress like a rabbit") or they sell the right to participate in the stream somehow (for example, by playing a game with the streamer in some special day).

In these models, the static QR code with which so many people dream doesn't make much sense (if you're selling a specific episode or if a payment is specific to one identifiable person, you need different QR codes or more metadata to be attached to each payment by the payer).

Addendum

I think people like the donation model very much because they only see the big and super famous people that receive donations. A very small set of people have so many followers that they can live with just donations, even though donations are very inefficient and they could earn more and even deliver better content if they were using some other model.

I imagine that a creator with a high number of followers will get a lot of people that do not donate anything, a lot that will donate a little -- probably less than they would if they were paying -- and eventually a little number of people that will donate way more than they would if they were buying. This last group is probably what makes it worthwhile to work on this donations model for these creators.

The takeaway is that the donations model is not a panacea and is not very good either.

Related:

• Donations on the internet

enquanto vinha se conduzindo pela plataforma superior daquela arena que se pensava totalmente preenchida por adeptos da famosa equipe do Grêmio de Porto Alegre, viu-se, como por obra de algum nigromante - dos muitos que existem e estão a todo momento a fazer más obras e a colocar-se no caminhos dos que procuram, se não fazer o bem acima de todas as coisas, a pelo menos não fazer o mal no curso da realização dos seus interesses -, o discretíssimo jornalista a ser xingado e moído em palavras por uma horda de malandrinos a cinco ou seis passos dele surgida que cantavam e moviam seus braços em movimentos que não se pode classificar senão como bárbaros, e assim cantavam:

Grêmio TV pior que o SBT !

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

In this talk from 2009, Michael Miller highlights some of the core features of CouchDB, those that would make it appeal to the developer public:

• Bi-directional incremental replication
• Custom views built with Javascript functions and saved to disk
• Filtered replication, so users can get part of the data
• Couchapps: lightweight web apps served directly from the database

What is the state of these awesome features today, 2016?

The replication protocol, which supports multi-master, has changed little, and has received criticism, but, as it is, it is the only open replication protocol out there, the only one that stands the fight, and the only one people were able to implement in the browser. PouchDB is probably the main reason people adopt CouchDB today. There are other things that talk that same replication protocol, so that's a thing.

Continuous replication, however, is too heavy, uses too much memory, and I don't think the idea of keeping two or more CouchDB databases in continuous replication today is good as it sounded back then.

Custom views always seemed to me as a gift from heavens, the solution to the dilemma between normalization and data duplication, they should be fast and flexible and support any use-case. That's how it sounds in that Miller presentation. However, today most CouchDB seem to be approaching views as just a confusing complicated hard way to do simple queries, like getting a list of items by the name of the category they're in, and other boring queries you can imagine.

This whole problem gave rise to the Cloudant Query Language and pouchdb-find. The second advertises itself as "inspired by MongoDB, it provides a simple API with operators like $gt (greater-than) and $eq (equals), so you can write less code to achieve the same performance as the map/reduce API". In other words: everybody seem to be looking at CouchDB as just a very poor and limited MongoDB.

To be fair, that is in fact the only sane way to approach CouchDB views, as other approaches, like the monolithic, cannot be used with a lot of data, and you must be sure your blocks of data will not get too big if you're willing to put them in massive documents.

Filtered replication was implemented, but it is slow to the point that no one recommends that you use them. I imagine the original idea was to mix filtered replication with Couchapps to make full-featured applications that the users would run on their own CouchDB instances, syncing back and forth from centralized CouchDB instances.

This idea would have been even more powerful if done with PouchDB on the user side -- since, I guess, no one has ever succeeded in distributing a CouchDB application to end users that ran their own CouchDB --, however the inefficiency of filtered replication made all these dreams come apart.

From the ruins of filtered replication emerged the db-per-user idea, which is the same filtered replication, but in such a way that a user owns the entire database and controls a PouchDB instance that replicates to and from that centralized database. The server may do things with the data stored in the CouchDB under its control, but the user at the same time has a copy of the entire data and it supposedly can work with it offline. This is a great idea, but if we look closely, it is much more limited than the original vision.

About Couchapps, the special database features that powered them in the first place were left aside as offline-first database-per-user PouchDB apps started to gain hearts and minds, and on the other side apps that would rely on a single server started to require features, like sophisticated authorization and per-document access control, that could only be provided by putting a normal server in front of CouchDB.

Like what happened to views, this is a sad thing. By trying to do things in the "regular" way, CouchDB users ignored CouchDB innovative ideas and made it look like a limited weird piece of software that lacks so many features that you must write a ton of middleware (that, of course, cannot be run inside CouchDB, what a limited server it is) to make it do simple stuff.

I must say, before it is too late, that I'm not in the big enterprise game, so I don't know how (if any) enormous software companies are using CouchDB and how it is working for them, this is just my impression from the low end of things.

LessPass is a nice idea: a password manager without any state. Just remember one master password and you can generate a different one for every site using the power of hashes.

But it has a very bad issue: some sites require just numbers, others have a minimum or maximum character limits, some require non-letter characters, uppercase characters, others forbid these and so on.

The solution: to allow you to specify parameters when generating the password so you can fit a generated password on every service.

The problem with the solution: it creates state. Now you must remember what parameters you used when generating a password for each site.

This was a way to store these settings on a remoteStorage bucket. Since it isn't confidential information in any way, that wasn't a problem, and I thought it was a good fit for remoteStorage.

Some time later I realized it maybe would be better to have a centralized repository hosting all weird requirements for passwords each domain forced on its users, and let LessPass use data from that central place when generating a password. Still stateful, not ideal, not very far from a centralized password manager, but still requiring less trust and less cryptographic assumptions.

• https://github.com/fiatjaf/lesspass-remotestorage
• https://addons.mozilla.org/firefox/addon/lesspass-remotestorage/
• https://chrome.google.com/webstore/detail/lesspass-remotestorage/aogdpopejodechblppdkpiimchbmdcmc
• https://lesspass.alhur.es/

See also

• hledger-web
• TiddlyWiki remoteStorage

A lightningd plugin that replaces a bitcoind node with trusted public explorers. Great so one can run a c-lightning node on a VPS without having to bother with an expensive bitcoind.

It uses multiple explorers and alternates between them, parses blocks and compares them with block hashes taken from other explorers so if someone is trying to trick you at least your node will crash instead of assuming all is fine.

It is used on @lntxbot and Etleneum.

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

See also

• Sparko

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

O que define uma ciência é o recorte de uma realidade a partir de um paradigma que todos os que entram no campo daquela ciência aceitam como verdade. Pronto.

O "método científico" não é nem necessário nem suficiente (apesar de que ele mesmo precisa pressupor uma série de axiomas para funcionar, do contrário a pessoa ficaria tendo que testar cada sílaba dos seus experimentos e cada um desses testes seria impossível de realizar pois eles necessariamente precisariam de outros conhecimentos prévios etc.).

Por isso - a física teórica pode ser uma ciência embora não faça experimentos; - e a economia pode ser uma ciência embora não faça experimentos (tá bom, existem pessoas que insistem em fazer "experimentos" em economia, mas que na verdade são só uma enorme perda de tempo baseada em estatísticas, mas isso não importa, até essas coisas podem ter algum valor desde que não se as entenda como sendo parte de um método científico); - e a história pode ser uma ciência, por mais estranho que isso pareça, bastando apenas que o historiador junte fatos de antigamente tendo como pressuposto um paradigma, por exemplo, de que existe um sentido da história, ou sei lá (não acho que exista essa ciência da história hoje em dia, me parece que cada historiador está fazendo uma coisa diferente, sem muitos paradigmas além do bom senso); - e a biologia pode ser uma ciência mesmo consistindo unicamente num longo esforço de classificação, e de fato é hoje, já que vê cada espécie e suas partes como frutos de um processo evolutivo cujas bases constituem um paradigma, e nega outras visões, como a teleologia.

• Método científico
• A estrutura paradigmática da ciência
• Um algoritmo imbecil da evolução

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

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.

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.

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.

A collection of notes related to Bitcoin.

• Bitcoin, not you
• Drivechain
• My personal experience (as a complete ignorant) of the blocksize debate in 2017
• Bitcoin transactions explained
• Eltoo
• On "zk-rollups" applied to Bitcoin
• bitcoind decentralization

Nostr is a protocol designed to work with fully independent clients. Each client is meant to talk to multiple standalone servers and act, like a web browser, as a true "user agent", requesting content that the user wants to read and signing content that the user wants to publish. A fundamental assumption of Nostr is that servers are free to be as evil as they want as long as clients are working to serve the interests of users.

This works relatively well with native clients assuming the user knows what it is installing and running and client has a name and a reputation (even in the world of mobile "app stores", as bad as it is, the assumptions still hold somewhat as updates are optional, relatively rare and discernible, and they're the same for everybody). Once a user installs an app it is in a way "theirs", it is running in their computer and doesn't depend on anyone else to keep running.

The same can't be said about "web" clients as they necessarily rely on a DNS domain name and a server owned by someone else, so a web client can't ever be trusted as an installed client can. They can't be fully user agents as they'll always remain (at least a little bit) agents of their true owner, the person who has the domain name.

An example

Everything is fine with, say, https://jumble.social/, until nostr:npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl decides to shut it down and its users lose access to their client; or maybe he is threatened to include some malicious code in there, most Jumble users are going to fall for that and Nostr will feel broken; finally even a small harmless change in the way it does some specific thing can be bad as it's impossible to opt out of.

Subjective apps

Maybe the correct way to approach this would be to treat "Jumble" as a subjective concept of an app. Not "whatever is on the jumble.social domain", but "this version of Jumble I use (represented by this hash), this is what Jumble is to me".

Any real Nostr web client must be capable of running entirely on the client side, as a "static" webpage made of just HTML, JS and CSS, so it should be possible to have these files hosted on Blossom and referenced by the hash of the "index.html" or something like that.

The hard part is how to get users to use not https://jumble.social/ directly, but their chosen version of Jumble, which they may update voluntarily whenever nostr:npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl decides to publishes a new release (while also being able to opt out of the update), but which they also may decide to represent some other version (hash) branch of Jumble, published or maintained by someone else.

It gets more interesting when subjective changes to the concept of "Jumble" (i.e. ignoring the original author and assigning that name to a contentious fork, for example) get propagated through the friends and friends of friends of the people making the switch, such that others can learn that there is a new Jumble in the town and opt to switch too, or maybe use both, give them different names and so on.

A lazier solution

To me the idea described above sounds very good, but I'm not super hopeful it can be accomplished soon given how weird it is. There is another, perhaps easier, but also less elegant solution, that may end up being adopted: that is for users to learn that Nostr clients, even web clients, aren't a single thing, they are many, and the same user may learn that they're able to use different clients simultaneously, and easily switch their habits from one to another.

If users have this conscience it may be that they won't find it hard to switch from jumble.social to fevela.me when they learn that the first is doing something they disagree with. They may also be using yakihonne.com or coracle.social as secondary clients in parallel, so even if jumble.social shuts down entirely they won't be left hanging and will be able to use these secondary clients to learn of all the Jumble forks that may have appeared in the meantime that they can try.

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.

A Go library that abstracts all the burdensome ActivityPub things and provides just the right amount of helpers necessary to integrate an existing website into the "fediverse" (what an odious name). Made for the gravity integration.

• https://godoc.org/github.com/fiatjaf/litepub

See also

-

I don't remember exactly when I did this, but I think a friend wanted to do software that would give him money over the internet without having to work. He didn't know how to program. He mentioned this idea he had which was some kind of football championship manager solution, but I heard it like this: a website that generated a round-robin championship table for people to print.

It is actually not obvious to anyone how to do it, it requires an algorithm that people will not reach casually while thinking, and there was no website doing it in Portuguese at the time, so I made this and it worked and it had a couple hundred daily visitors, and it even generated money from Google Ads (not much)!

First it was a Python web app running on Heroku, then Heroku started charging or limiting the amount of free time I could have on their platform, so I migrated it to a static site that ran everything on the client. Since I didn't want to waste my Python code that actually generated the tables I used Brython to run Python on JavaScript, which was an interesting experience.

In hindsight I could have just taken one of the many round-robin JavaScript libraries that exist on NPM, so eventually after a couple of more years I did that.

I also removed Google Ads when Google decided it had so many requirements to send me the money it was impossible, and then the money started to vanished.

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

Or: how to activate Drivechain.

Imagine a world in which there are 10 different bitcoind flavors, as described in bitcoind decentralization.

Now how do you enable a soft-fork?

Flavor 1 enables it. Seeing that nothing bad happened, flavor 2 enables it. Then flavor 3 enables it.

And so on.

When what is perceived by miners to be a big chunk of support for the proposal, a miner can try to mine a block that contains the new feature.

No need for a flag day or a centralized decision making process that depends on one or two courageous leaders to enable a timer.

This probably sounds silly, and maybe is.

I thought a community of people sharing feedback on mutual interests would be a good thing, so as always I broadened and generalized the idea and mixed with my old criticue-inspired idea-feedback project and turned it into a "token". You give feedback on other people's things, they give you a "point". You can then use that point to request feedback from others.

This could be made as an Etleneum contract so these points were exchanged for satoshis using the shitswap contract (yet to be written).

In this case all the Bitcoin/Lightning side of the website must be hidden until the user has properly gone through the usage flow and earned points.

If it was to be built on Etleneum then it needs to emphasize the login/password login method instead of the lnurl-auth method. And then maybe it could be used to push lnurl-auth to normal people, but with a different name.

São poucos os exemplos de sistemas legais claramente anárquicos que nós temos, e são sempre de tempos muito remoto, da idade média ou por aí. Me vêm à cabeça agora o sistema islandês, o somaliano, o irlandês e as cortes dos mercadores da Europa continental.

Esses exemplos, embora sempre pareçam aos olhos de um libertário convicto a prova cabal de que a sociedade sem o Estado é capaz de fazer funcionar sistemas legais eficientes, complexos e muito melhores e mais baratos do que os estatais, a qualquer observador não entusiasmado vão parecer meio anacrônicos: são sempre coisas que envolvem família, clãs, chefes de família, comunidades pequenas -- fatores quase sempre ausentes na sociedade hoje --, o que dá espaço para que a pessoa pense (e eu confesso que isso também sempre me incomodou) que nada disso funcionaria hoje, são bonitos, mas sistemas que só funcionariam nos tempos de antigamente, o Estado com seu sistema judiciário é a evolução natural e necessária de tudo isso e assim por diante.

Vale lembrar, porém, que os exemplos que nós temos provavelmente não surgiram espontamente, eles mesmos foram o resultado de uma evolução lenta mas constante do sistema legal das suas respectivas comunidades. Se não tivessem sido interrompidos pela intervenção de algum Estado, esses sistemas teriam continuado evoluindo e hoje, quem sabe, seriam redes complexas altamente eficientes, que, por que não, juntariam tecnologias similares à internet com segurança de dados, algoritmos maravilhosos de reputação e voto, tudo decentralizado, feito por meio de protocolos concorrentes mas padronizados -- talvez, se tivessem tido um pouquinho mais de tempo, cada um desses sistemas legais anárquicos teria desenvolvido meios de evitar a conquista ou a concorrência desleal de um Estado, ou pelo menos do Estado como nós o conhecemos hoje.

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.

Nos esportes e jogos em geral, existe uma constante preocupação em balancear os incentivos e atributos do jogo, as regras do esporte em si e as regras das competições para que o melhor vença, ou, em outras palavras, para que sejam minimizados os outros fatores exceto a habilidade mais pura quanto possível no jogo em questão.

O mundo fora dos jogos, porém, nem sempre pode ter suas regras mudadas por um ente que as controla e está imbuído da vontade e dos meios para escolher as melhores regras possíveis para a obtenção dos resultados acima. Aliás, é muitas vezes essa possibilidade é até impensável. Mesmo quando ela é pensável e levada em conta os fatores que operam no mundo real não são facilmente identificáveis, eles são muitos, e mudam o tempo todo.

Mais do que isso, ao contrário de um jogo em que o objetivo é praticamente o mesmo para todo mundo, os objetivos de cada agente no mundo real são diferentes e incontáveis, e as "competições" que cada um está disputando são diferentes e muitas, cada minúsculo ato de suas vidas compreendendo várias delas simultaneamente.

Da mesma forma, é impossível conceber até mesmo o conceito de "melhor" para que se deseje que ele vença.

Mesmo assim é comum encontrarmos em várias situações gente que parte do princípio de que se Fulano está num certo lugar (por exemplo, um emprego muito bom) e Beltrano não isso se deve ao fato de Fulano ter sido melhor que Beltrano.

Está aí uma crítica à idéia da meritocracia (eu tinha me esquecido que essa palavra existia).

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

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

While I was writing my first small program on Haskell (really simple, but functional webapp) in December 2017 I only knew vaguely what was the style of things, some basic notions about functions, pure functions and so on (I've read about a third of LYAH).

An enourmous amount of questions began to appear in my head while I read tutorials and documentation. Here I present some of the questions and the insights I got that solved them. Technically, they may be wrong, but they helped me advance in the matter, so I'm writing them down while I still can -- If I keep working with Haskell I'll probably get to know more and so my new insights will replace the previous ones, and the new ones won't be useful for total begginers anymore.

Here we go:

• Why do modules have odd names?
  • modules are the things you import, like Data.Time.Clock or Web.Scotty.
  • packages are the things you install, like 'time' or 'scotty'
  • packages can contain any number of modules they like
  • a module is just a collection of functions
  • a package is just a collection of modules
  • a package is just name you choose to associate your collection of modules with when you're publishing it to Hackage or whatever
  • the module names you choose when you're writing a package can be anything, and these are the names people will have to import when they want to use you functions
    • if you're from Javascript, Python or anything similar, you'll expect to be importing/writing the name of the package directly in your code, but in Haskell you'll actually be writing the name of the module, which may have nothing to do with the name of the package
    • people choose things that make sense, like for aeson instead of import Aeson you'll be doing import Data.Aeson, import Data.Aeson.Types etc. why the Data? because they thought it would be nice. dealing with JSON is a form of dealing with data, so be it.
      • you just have to check the package documentation to see which modules it exposes.
• What is data User = User { name :: Text }?
  • a data type definition. means you'll have a function User that will take a Text parameter and output a User record or something like that.
  • you can also have Animal = Giraffe { color :: Text } | Human { name :: Text }, so you'll have two functions, Giraffe and Human, each can take a different set of parameters, but they will both yield an Animal.
    • then, in the functions that take an Animal parameter you must typematch to see if the animal is a giraffe or a human.
• What is a monad?
  • a monad is a context, an environment.
    • when you're in the context of a monad you can write imperative code.
      • you do that when you use the keyword do.
    • in the context of a monad, all values are prefixed by the monad type,
      • thus, in the IO monad all Text is IO Text and so on.
    • some monads have a relationship with others, so values from that monad can be turned into values from another monad and passed between context easily.
      • for exampĺe, scotty's ActionM and IO. ActionM is just a subtype of IO or something like that.
    • when you write imperative code inside a monad you can do assignments like varname <- func x y
      • in these situations some transformation is done by the <-, I believe it is that the pure value returned by func is being transformed into a monad value. so if func returns Text, now varname is of type IO Text (if we're in the IO monad).
      • so it will not work (and it can be confusing) if you try to concatenate functions like varname <- transform $ func x y, but you can somehow do
        • varname <- func x y
        • othervarname <- transform varname
      • or you can do other fancy things you'll get familiar with later, like varname <- fmap transform $ func x y
        • why? I don't know.
• How do I deal with Maybe, Either or other crazy stuff? "ok, I understand what is a Maybe: it is a value that could be something or nothing. but how do I use that in my program?"
  • you don't! you turn it into other thing. for example, you use fromMaybe, a function that takes a default value and that's it. if your Maybe is Just x you get x, if it is Nothing you get the default value.
    • using only that function you can already do whatever there is to be done with Maybes.
    • you can also manipulate the values inside the Maybe, for example:
      • if you have a Maybe Person and Person has a name which is Text, you can apply a function that turns Maybe Person into Maybe Text AND ONLY THEN you apply the default value (which would be something like the "unnamed") and take the name from inside the Maybe.
  • basically these things (Maybe, Either, IO also!) are just tags. they tag the value, and you can do things with the values inside them, or you can remove the values.
    • besides the example above with Maybes and the fromMaybe function, you can also remove the values by using case -- for example:
      • case x of
      • Left error -> error
      • Right success -> success
      • case y of
      • Nothing -> "nothing!"
      • Just value -> value
    • (in some cases I believe you can't remove the values, but in these cases you'll also don't need to)
      • for example, for values tagged with the IO, you can't remove the IO and turn these values into pure values, but you don't need that, you can just take the value from the outside world, so it's a IO Text, apply functions that modify that value inside IO, then output the result to the user -- this is enough to make a complete program, any complete program.
• JSON and interfaces (or instances?)
  • using Aeson is easy, you just have to implement the ToJSON and FromJSON interfaces.
  • "interface" is not the correct name, but I don't care.
  • ToJSON, for example, requires a function named toJSON, so you do
    • instance ToJSON YourType where
      • toJSON (YourType your type values) = object [] ... etc.
  • I believe lots of things require interface implementation like this and it can be confusing, but once you know the mystery of implementing functions for interfaces everything is solved.
  • FromJSON is a little less intuitive at the beggining, and I don't know if I did it correctly, but it is working here. Anyway, if you're trying to do that, I can only tell you to follow the types, copy examples from other places on the internet and don't care about the meaning of symbols.

See also

• Haskell Monoids

I once fell for this talk about "content-addressing". It sounds very nice. You know a certain file exists, you know there are probably people who have it, but you don't know where or if it is hosted on a domain somewhere. With content-addressing you can just say "start" and the download will start. You don't have to care.

Other magic properties that address common frustrations: webpages don't go offline, links don't break, valuable content always finds its way, other people will distribute your website for you, any content can be transmitted easily to people near you without anyone having to rely on third-party centralized servers.

But you know what? Saying a thing is good doesn't automatically make it possible and working. For example: saying stuff is addressed by their content doesn't change the fact that the internet is "location-addressed" and you still have to know where peers that have the data you want are and connect to them.

And what is the solution for that? A DHT!

DHT?

Turns out DHTs have terrible incentive structure (as you would expect, no one wants to hold and serve data they don't care about to others for free) and the IPFS experience proves it doesn't work even in a small network like the IPFS of today.

If you have run an IPFS client you'll notice how much it clogs your computer. Or maybe you don't, if you are very rich and have a really powerful computer, but still, it's not something suitable to be run on the entire world, and on web pages, and servers, and mobile devices. I imagine there may be a lot of unoptimized code and technical debt responsible for these and other problems, but the DHT is certainly the biggest part of it. IPFS can open up to 1000 connections by default and suck up all your bandwidth -- and that's just for exchanging keys with other DHT peers.

Even if you're in the "client" mode and limit your connections you'll still get overwhelmed by connections that do stuff I don't understand -- and it makes no sense to run an IPFS node as a client, that defeats the entire purpose of making every person host files they have and content-addressability in general, centralizes the network and brings back the dichotomy client/server that IPFS was created to replace.

Connections?

So, DHTs are a fatal flaw for a network that plans to be big and interplanetary. But that's not the only problem.

Finding content on IPFS is the most slow experience ever and for some reason I don't understand downloading is even slower. Even if you are in the same LAN of another machine that has the content you need it will still take hours to download some small file you would do in seconds with scp -- that's considering that IPFS managed to find the other machine, otherwise your command will just be stuck for days.

Now even if you ignore that IPFS objects should be content-addressable and not location-addressable and, knowing which peer has the content you want, you go there and explicitly tell IPFS to connect to the peer directly, maybe you can get some seconds of (slow) download, but then IPFS will drop the connection and the download will stop. Sometimes -- but not always -- it helps to add the peer address to your bootstrap nodes list (but notice this isn't something you should be doing at all).

IPFS Apps?

Now consider the kind of marketing IPFS does: it tells people to build "apps" on IPFS. It sponsors "databases" on top of IPFS. It basically advertises itself as a place where developers can just connect their apps to and all users will automatically be connected to each other, data will be saved somewhere between them all and immediately available, everything will work in a peer-to-peer manner.

Except it doesn't work that way at all. "libp2p", the IPFS library for connecting people, is broken and is rewritten every 6 months, but they keep their beautiful landing pages that say everything works magically and you can just plug it in. I'm not saying they should have everything perfect, but at least they should be honest about what they truly have in place.

It's impossible to connect to other people, after years there's no js-ipfs and go-ipfs interoperability (and yet they advertise there will be python-ipfs, haskell-ipfs, whoknowswhat-ipfs), connections get dropped and many other problems.

So basically all IPFS "apps" out there are just apps that want to connect two peers but can't do it manually because browsers and the IPv4/NAT network don't provide easy ways to do it and WebRTC is hard and requires servers. They have nothing to do with "content-addressing" anything, they are not trying to build "a forest of merkle trees" nor to distribute or archive content so it can be accessed by all. I don't understand why IPFS has changed its core message to this "full-stack p2p network" thing instead of the basic content-addressable idea.

IPNS?

And what about the database stuff? How can you "content-address" a database with values that are supposed to change? Their approach is to just save all values, past and present, and then use new DHT entries to communicate what are the newest value. This is the IPNS thing.

Apparently just after coming up with the idea of content-addressability IPFS folks realized this would never be able to replace the normal internet as no one would even know what kinds of content existed or when some content was updated -- and they didn't want to coexist with the normal internet, they wanted to replace it all because this message is more bold and gets more funding, maybe?

So they invented IPNS, the name system that introduces location-addressability back into the system that was supposed to be only content-addressable.

And how do they manage to do it? Again, DHTs. And does it work? Not really. It's limited, slow, much slower than normal content-addressing fetches, most of the times it doesn't even work after hours. But still although developers will tell it is not working yet the IPFS marketing will talk about it as if it was a thing.

Archiving content?

The main use case I had for IPFS was to store content that I personally cared about and that other people might care too, like old articles from dead websites, and videos, sometimes entire websites before they're taken down.

So I did that. Over many months I've archived stuff on IPFS. The IPFS API and CLI don't make it easy to track where stuff are. The pin command doesn't help as it just throws your pinned hash in a sea of hashes and subhashes and you're never able to find again what you have pinned.

The IPFS daemon has a fake filesystem that is half-baked in functionality but allows you to locally address things by names in a tree structure. Very hard to update or add new things to it, but still doable. It allows you to give names to hashes, basically. I even began to write a wrapper for it, but suddenly after many weeks of careful content curation and distribution all my entries in the fake filesystem were gone.

Despite not having lost any of the files I did lose everything, as I couldn't find them in the sea of hashes I had in my own computer. After some digging and help from IPFS developers I managed to recover a part of it, but it involved hacks. My things vanished because of a bug at the fake filesystem. The bug was fixed, but soon after I experienced a similar (new) bug. After that I even tried to build a service for hash archival and discovery, but as all the problems listed above began to pile up I eventually gave up. There were also problems of content canonicalization, the code the IPFS daemon use to serve default HTML content over HTTP, problems with the IPFS browser extension and others.

Future-proof?

One of the core advertised features of IPFS was that it made content future-proof. I'm not sure they used this expression, but basically you have content, you hash that, you get an address that never expires for that content, now everybody can refer to the same thing by the same name. Actually, it's better: content is split and hashed in a merkle-tree, so there's fine-grained deduplication, people can store only chunks of files and when a file is to be downloaded lots of people can serve it at the same time, like torrents.

But then come the protocol upgrades. IPFS has used different kinds of hashing algorithms, different ways to format the hashes, and will change the default algorithm for building the merkle-trees, so basically the same content now has a gigantic number of possible names/addresses, which defeats the entire purpose, and yes, files hashed using different strategies aren't automagically compatible.

Actually, the merkle algorithm could have been changed by each person on a file-by-file basis since the beginning (you could for example split a book file by chapter or page instead of by chunks of bytes) -- although probably no one ever did that. I know it's not easy to come up with the perfect hashing strategy in the first go, but the way these matters are being approached make me wonder that IPFS promoters aren't really worried about future-proof, or maybe we're just in Beta phase forever.

Ethereum?

This is also a big problem. IPFS is built by Ethereum enthusiasts. I can't read the mind of people behind IPFS, but I would imagine they have a poor understanding of incentives like the Ethereum people, and they tend towards scammer-like behavior like getting a ton of funds for investors in exchange for promises they don't know they can fulfill (like Filecoin and IPFS itself) based on half-truths, changing stuff in the middle of the road because some top-managers decided they wanted to change (move fast and break things) and squatting fancy names like "distributed web".

The way they market IPFS (which is not the main thing IPFS was initially designed to do) as a "peer-to-peer cloud" is very seductive for Ethereum developers just like Ethereum itself is: as a place somewhere that will run your code for you so you don't have to host a server or have any responsibility, and then Infura will serve the content to everybody. In the same vein, Infura is also hosting and serving IPFS content for Ethereum developers these days for free. Ironically, just like the Ethereum hoax peer-to-peer money, IPFS peer-to-peer network may begin to work better for end users as things get more and more centralized.

More about IPFS problems:

• IPFS problems: Too much immutability
• IPFS problems: General confusion
• IPFS problems: Shitcoinery
• IPFS problems: Community
• IPFS problems: Pinning
• IPFS problems: Conceit
• IPFS problems: Inefficiency
• IPFS problems: Dynamic links

See also

• A crappy course on torrents, on the protocol that has done most things right
• The Tragedy of IPFS in a series of links, an ongoing Twitter thread.