The Covid-19 sin bin:

I'm deeply sorry that I didn't wholeheartedly support the small minority who were brave enough to protest the authorities' handling of Covid-19.

I let the rebels down.

I'm particularly ashamed, because as a lawyer, when I got my diploma, like all other Norwegian lawyers, I solemny had to promise I would go out and promote justice and prevent injustice.

I failed this duty miserably.

When we today see the very serious consequences of the authorities' abuse of power, with disproportionate and arbitrary lockdowns and distance regulations, in many cases mandatory vaccinations and various other harmful interventions in our freedom of movement and privacy, I just want to say that I now understand how much I'm to blame because I didn't protest openly and loudly.

Many of those who objected against the policies are bruised and battered and still have challenges in their lives due to the lack of support from their peers and the way they were treated by the rest of society.

I'll do everything to ensure that I don't make the same mistake in the future.

I'm writing this because today's postmodern society is affected by a virus that is very dangerous indeed - the fear of losing face and looking weak if one admits mistakes.

If we're to move forward in this process and succeed in forcing the authorities to put all the cards on the table, I think we must start with ourselves and acknowledge our own mistakes.

Therefore, feel free to write your own apology in the comments below, like and share, and then perhaps we can hope that many others do the same.

Thank you for your contribution.

🙏

New major release! Phoenix Android/iOS/Server now supports BOLT12:

- reusable, non-expiring payment requests

- contact list (Android for now, iOS soon)

- attach messages to payments

You can now receive payments to a static bolt-12 offer via Phoenix and keep a list of offers in your contact list!

See also bolt12.org

Are people not zapping anymore? Not seeing that many Zaps happening 🤔

laws do not stop people from doing "wrong" things

laws just provide a framework for punishing people who do things that society does not like

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

Summertime sunset at 23:00.. another beautiful day in the mountain comes to an end. GN

running obscura vpn #masque

Sure?

Isn’t Ocean censoring transactions??

Isn’t Ocean censoring transactions??

They can only sell once

Yes, it's coordinated.

They get to do this one time.

Watching multiple governments sell off their future existence is hard to watch but ultimately rewarding.

#HFSP

nostr:note1pfprvsm28v5wahq3v6kp4f34876pj3qw274xzmkyfvcrfe3y4mwq5hmaqc

Two things that we're building:

- There are going to be Cashu mints that will only be reachable via Nostr. They won't have IP addresses but npubs.

- There are going to be Cashu wallets that synchronize state across devices via nostr. No cloud.

Not everyone will like this but it doesn't matter because it can't be stopped.