The amount of activity in #LDK is HUGE!

Technically I've become an #LDK contributor 😎

I'm reluctant to call it X, as during the period I've used it, it was Twitter.

[LDK Splicing] 🎉🎉🎉 Managed to create first real spliced channel with LDK!! This is with my simplified prototype; I spent the last 1-2 days debugging, and fixed transaction creation.

[LDK Splicing] In splicing, creation of the new funding tx is similar to the creation of the funding tx in the case of channel open. But there is an important difference: in splicing, the new funding tx has the old funding tx as an input. Which means signing of the funding tx has to be done by both ends (as the prev funding tx is a 2-of-2 multisig). It's not easy to accomplish this without the full tx negotiation messages.

[LDK Splicing] I've decided to start hacking Splicing support into LDK! My first goal is a super stripped-down end-to-end working prototype (happy path only, no quiscence, no tx negotiation). I'm almost ready (almost = not)

Always look for hidden motives when a government says or does something.

#Splicing Does channel ID change during splicing process? During channel open, channel ID is derived from the funding TX, which does change during the splicing process, so I can imagine both ways.

Extensive collection of practical resources on the topic of PRIVACY:

Awesome Privacy

Home | Awesome Privacy

Privacy is a fundamental human right; without it, we

🤩 after you spend the evening in a beer garden discussing bitcoin, after unexpectedly getting to a local meetup Stack sats and build local communities

The right to privacy is as fundamental as the right to private property.

I'm looking for an LN Splicing message sequence diagram. Anyone? (Dusty seems to have a nostr account, but not used @Dusty Daemon)

Scam spam has reached my notes as well...

#grownostr poppies

What's the difference between NIP-46 Nostr Signer and NIP-26 Delegation, and how can they be combined? Both solutions deal with the scenario when you want to use a Nostr app without entering your secret key, and a 'keystore' app which only deals with your keys. In the Signer solution, every single time the app needs a signature (posting a note, a like, a follow, etc.), it reaches out to the Signer for a signature. Communication happens over Nostr events. In the Delegation solution, on the other hand, you first create a delegation, which allows the app to post on the behalf of the user without the secret key. Typically a delegation is restricted for some period (e.g. one month). Signing the delegation requires the key, and the delegation has to get to the app. The two approaches can be combined: the app can request the Signer to sign a delegation, and it can use the delegation right away to post on behalf of the user, without needing to further contact the Signer. I hope to see more apps supporting both NIP-46 and NIP-26 in the future.

View quoted note → I was wondering if the lightning channel construct could be generalized to 3 (or more) parties; I've found the/an answer in this bitcoin.stackexchange.com question.