hey nostr

any non US folks open to chatting with me and some of the strike team in a user research study we’re doing?

we are looking to launch our global on-ramps soon and we wanna learn more about how strike can be the best bitcoin experience and learn more about the financial needs of different parts of the world

I spoke at a big bitcoin-adjacent company this week and one of the best questions was from someone who asked what the downsides of bitcoin adoption might be.

I always do appreciate these steelman questions, the skeptical questions, the ones where we challenge ourselves. Only when we can answer those types of questions do we understand the concept that we are promoting.

So the classic example is that in modern economic literature, "deflation is bad". This, however, is only the case in a highly indebted system. Normally, deflation is good. Money appreciates, technology improves, and goods and services get cheaper over time as they should. Price of Tomorrow covers this well. My book touches on this too, etc. The "deflation is bad" meme is still alive in modern economic discourse and thus is worth countering, but I think in the bitcoin spectrum of communities, people get that deflation is fine and good.

My answer to the question was in two parts.

The first part was technological determinism. In other words, if we were to re-run humanity multiple times, there are certain rare accidents that might not replicate, and other commonalities that probably would. Much like steam engines, internal combustion engines, electricity, and nuclear power, I think a decentralized network of money is something we would eventually come across. In our case, Bitcoin came into existence as soon as the bandwidth and encryption tech allowed it to. In other universes or simulations it might look a bit different (e.g. might not be 21 million or ten minute block times exactly), but I think decentralized real-time settlement would become apparent as readily as electricity does, for any civilization that reaches this point. So ethics aside, it just is what it is. It exists, and thus we must deal with it.

The second part was that in my view, transparency and individual empowerment is rarely a bad thing. Half of the world is autocratic. And half of the world (not quite the same half) deals with massive structural inflation. A decentralized spreadsheet that allows individuals to store and send value can't possibly be a bad thing, unless humanity itself is totally corrupted. I then went into more detail with examples about historical war financing, and all sorts of tangible stuff. In other words, a whole chapter full of stuff. I've addressed this in some articles to.

In your view, if you had to steelman the argument as best as you could, what are the scenarios where bitcoin is *BAD* for humanity rather than good for it, on net?

I’m still #onlyzaps

have any of you ditched mobile phone for laptop only?

Just read the comment you're responding to.

Calgary, Alberta in 🇨🇦

#ProofofWalk #Sunnydays

I have fewer followers on Threads but more engagement than Nostr.

Where are you, plebs?

🤔

I want to clean up NIP-01 a little more, remove the things no one uses, like kind2, and merge in NIPs 12, 16 and 20. Is that a bad idea?

Just imagine for a moment a world where prices of everything consistently fell as the productivity gains of a free market flowed to society.

Now, try to imagine a group of people advancing an idea that there needed to be theft in money society to function, and that they would be the major beneficiaries of that theft.

Seems crazy!

#Bitcoin

Instead of using a database I'm storing events in a file. Memory mapping lets you access a file as if it was entirely in memory, and the OS pages it in and out for you automatically doing the reads and writes and stuff.

Each event just gets appended, which requires a write lock (one writer at a time) but readers can keep reading while writes are happening so it is less contentious than a traditional RWLock which blocks readers while writes happen.

The indexes are functionally similar to key-value btrees which map certain query tuples like (pubkeyhex, createdat, idhex) to an offset into the event file (the length of the event is encoded in the serialization so we just need the offset). The serialization is very minimal, just enough to have a length and to be linear. Each key in each index must be unique (or else we would lose events) which is why they end in the "idhex". We can scan a time slice (before/since) as they are grouped together on the btree, so I can iterate from (pubkey, before) to (pubkey, since+1) to get all that person's events within that time range. I'm intersecting multiple index results by hashing results and checking that map each time I run through the next index, discarding matches that come up missing (from the previous index). That should cover all possible queries, not in an ideal way, but in a simple and relatively fast way. strfry has more indices (all the common ones) and falls back to scanning a flatbuffer event sequence for matches. It also uses LMDB for the events rather than trying to memory map directly. I'm using sled for the indexing. I don't know if my indexing merging scheme is going to be faster or not. Probably slower in most cases, but faster then when strfry doesn't have a suitable index. That's my guess anyhow. My code is at least easy to reason about. I came up with mine before talking to Doug.

Does anyone have a chart of the dates of Bitcoin futures expiry vs. the price chart over the time period from when the first futures appeared?

I have a theory. Needing data.