I'm disappointed that @Peter McCormack never got an answer to his question about what Bitcoin looks like to those who can't afford a UTXO. This is an important question, maybe *the* important question. But it also underscores how much he diverged from his "pleb everyman" origins: this is very much not a newcomer question! Guess I won't be on WBD to answer it, either!* *Spoiler: I don't know the answer, but I can describe the possibilities and issues people can (and are!) exploring...

I am sometimes haunted by the phrase I heard log ago from Eben Moglen: It's wrong to be right too soon.

Just got a "call" from "Ledger Live Support". MtGox bringing them all out, I guess. Be careful!

People keep talking about stable channels. But few people need worry about -10% BTC prices, they worry about -70% prices, which is when they fail. I don't see anyone discussing their service limits here. They're a great business opportunity: if bitcoin goes up, you profit, if it goes down you declare bankrupcy and start again!

Bitcoin Magazine

Reflections On Bitcoin Culture

Bitcoin is for anyone who needs it, not just people who conform to preconceived notions of what is the acceptable culture.

BUT BITCOIN WAS SUPPOSED TO DEFEND MY IMPLIED PRONOUNS!!!!

As I've aged, I have come to terms with people not asking my permission or seeking my approval. Surprisingly often, my disapproval was just glass shards I was feeding myself. So I stopped.

Most of my friends are non-Bitcoiners. A significant fraction are non-binary, an even larger number are neurodiverse, and many are half my age: a great variety of fascinatingly different humans! It's OK to be weird, and it makes our world more interesting. If that makes me outside someone's "ethos of Bitcoin" I think they misunderstand what Bitcoin is for.

#cln #dev Finally catching up with the latest BOLT12 spec, and damn, Phoenix just announced BIP 353 support. Gotta code faster!

#cln #dev Wrapping up the great blinded path catchup, I hit a snag. Paying an invoice where we ourselves are nominated as the head of the blinded path. I solved this case elegantly for onion messages, but actual payments are not so easy. In an ideal world, our code would have been written so we could have either the RPC or an incoming HTLC trigger this code. But unwrapping and forwarding are only written for incoming HTLCs, and reworking all that is a major task. I may revisit this one day, as such code would transparently allow self-payment which currently has a special path. So instead we are going to have another special path for this case :( I thought about simply unwrapping the onion inside the pay plugin for this, but it requires ECDH using the node key which we don't expose through RPC (and I'm reluctant to expose). Hoping to finish soon as this is a large part of getting offers to production ready (vs the current experimental config option).

There's a thing I saw often in the early Linux days and still see in Bitcoin communities. People discover Bitcoin and try to wedge it into their existing special interest and extol the crossover as a discovery (rather than a construction). I call this "Bitcoin fan-fiction". It's weird, awkward and very very human. It's also usually very easy to spot in others, never in ourselves 💛

#dev #CLN I've spent the last few workdays completely reworking our onion message code. This was scattered in various places and I wanted to unify it, and also written several years ago and I'd forgotten how the protocol actually works! onion messages are *double* encrypted; this is the main source of confusion! At the high layer, they're a series of nested encrypted calls ("onionmsg_tlv" in the BOLT 4 spec), so each recipient decrypts and hands it on: this is exactly the same as we use for payment information. But inside that is *another* encrypted blob (onionmsg_tlv.encrypted_recipient_data), which requires a tweak which was handed to you alongside the onion, for you to decrypt (into an "encrypted_data_tlv"). Inside that is all the information about where to send next, any restrictions, and allows you to calculate the *next* tweak to hand on (it can also override the next tweak). The double encryption is necessary because there are *three* actors here: Alice wants Bob to send her a message, without revealing her identity. So she gives Bob a "blinded path" which goes via Charlie: this path contains Charlie's pubkey (where to start the path), a blinding tweak, and two encrypted blobs for Alice to put into each layer of the onion message. The first an encrypted blob which Charlie can read, which contains her pubkey so he knows where to send it next. The second is her own, and contains a secret specific to the purpose of this message, so Bob can't play games trying to use this blinded path for anything else ("hey, are you the same node as this previous payment?") or use a different blinded path for this purpose. She can also add dummy hops (we don't yet), which she will simply absorb, to obscure the path length from Bob. You can add padding to make the hops indistinguishable (we don't yet). Bob puts the actual stuff he wants to send Alice into the final onion call (often including his own blinded reply path!), along with the encrypted blob. Importantly, even if Bob were sending a message *not through a blinded path* he would use the same double-encrypted format: that's so Charlie can't tell whether a blinded path is being used or not, even though it's slightly less efficient. Crypto is cheap these days, too. Now, if Alice gives Bob a blinded path to Charlie and Charlie is Bob's peer, he can simply send the onion and the first blinding tweak to Charlie. But if Alice needs to send the message via Dave to Charlie, she needs to prepend a step. That's not quite possible, naively, because blinding tweaks are generated *forwards*, and she needs Charlie to get the right blinding tweak from Dave, and Alice has no way of making that happen. So inside Dave's encrypted blob, she uses next_blinding_override to tell Dave to hand that blinding override to Charlie instead of the normal one. I just implemented this for Core Lightning (previously we would simply connect to the first node, which is privacy-compromising and should only be done as a last resort). These blinded paths have some nice properties: you can't use part of them (you don't know the blinding factor except for the first one, so you can't start in the middle, and you can't replace any data), you need to use all of them. They can contain timelimits to avoid easy probing, too: a classic measure would be to see if the path fails when a given node is down, but that takes time. The spec insists all errors within the blinded path are the same, and originate from the entry: this loses some analytical power on failure, but makes probing harder. The entry point is supposed to add a random delay (we don't yet!). There may still be implementation differences, but they're hard for Bob to probe (and Alice doesn't need to, as she set up the path).

#Bitcoin #dev #GSR At

bitcoin++

bitcoin++ · Technical Bitcoin Conferences

bitcoin++ hosts technical conferences, workshops, and hackathons for bitcoin developers and builders around the world.

in Austin I presented my work on restoring Bitcoin Script. Script had an emergency amputation in 2010 as there were no limits on resource consumption; restoring it means solving this problem. My proposal is a runtime limit, similar to Taproot's runtime sigops limit, called "varops". How much you get depends on your transaction size (ie how much you paid), similar to sigops. But how much should operations cost? I had a cost model based on "worst-case bytes touched" for each operation. I've spent the last few weeks doing increasingly precise micro-benchmarks on my laptop, my build machine, and various Raspberry Pi. There's bad news, and good news....

Yes, I understand this feeling. Not quite how I would have expressed it, but there are genuine insights in here:

I Will Fucking Piledrive You If You Mention AI Again — Ludicity