Avatar
nerd2ninja; ©️📺
834c0b53c8b33e0ad50fc4524e11f0506ac64fed2be7629e69512c9d2da74369
Nerd, ruby dev, systems theory adversarial thinker/arm chair general, Bitcoin enthusiast, toki pona 🗣👍 and other language barrier breaking methods advocate relays = [ relayable.org, nostr.wine, nostr.milou.lol, paid.spore.ws, nostr.uselessshit.co, nostr-pub.wellorder.net ]

How CTV (BIP 119) Could Create Channel Factories for Casual Users (John Law)

"The key challenge in scaling Lightning in a trust-free manner is the creation of Lightning channels for casual users. Signature-based factories (AKA other ideas for channel factories before this paper) appear to be inherently limited to creating at most tens or hundreds of Lightning channels per unspent transaction output (UTXO). In contrast, simple covenants (including those enabled by CheckTemplateVerify (CTV) or AnyPrevOut (APO)) would allow a single UTXO to create Lightning channels for millions of casual users.

The resulting covenant-based protocols also:

1. support resizing channels off-chain,

2. use the same capital to simultaneously provide in-bound liquidity to casual users and route unrelated payments for other users

3. charge casual users tunable penalties for attempting to put an old state on-chain, and

4. allow casual users to monitor the blockchain for just a few minutes every few months without employing a watchtower service.

As a result, adding CTV and/or APO to Bitcoin's consensus rules would go a long way toward making Lightning a widely-used means of payment

...

The remainder of this paper is organized as follows.

Section 2 demonstrates that the key challenge in scaling Lightning is providing Lightning channels to casual users while meeting their usability requirements.

Section 3 then shows why no protocol that uses Bitcoin's current consensus rules is likely to meet this challenge.

Covenant-based protocols for creating Lightning channels are presented in Section 4,

and they are analyzed in Section 5. The remaining sections look at related work and give conclusions."

This has been my reformatted for readability but otherwise mostly copy and paste of the introduction of "Scaling Lightning With Simple Covenants" paper written by John Law. I hope this introduction gets you as interested in reading the paper as it has gotten me.

The full paper can be read here: https://github.com/JohnLaw2/ln-scaling-covenants/blob/main/scalingcovenants_v1.0.pdf

"Timeout Trees"

?o=1

#[2] River out here doing graphics on covenants

Don't forget about self care after your shaming kink session is over XD

My first reaction was "What are you talking about?" And then I was like was this a mass shooting or natural disaster or something more personal.

So thanks for the reminder about what today's date is XD

Wallet of Satoshi is just a bank or a Bitcoin vaulting custodian and payment service if you prefer.

Real solutions are like Phoenix, Breez, Blixt, running your own stack etc

At a certain point we figured out Muun isn't a lightning wallet and its actually an on-chain wallet that does on-chain to ln swaps

Then they just take 0 confirmations as a spend to make it look fast.

I heard that because of increasing on-chain fees and full rbf being a thing, they were going to become a real lightning wallet, but no idea what the progress is on that.

Like wallet of satoshi. Mutiny has an LSP which serves as a channel partner not a custodian

Protocol development takes time using existing technology takes compromises. Zaps rely on DNS to then forward to an always online server to grab a bolt 11 address and return it to the person requesting it. Governments "turn off the internet" by turning off DNS. (Hint hint, use IPs were you can and self host your own DNS server).

If Phoenix and Breez had like a desktop client so you could easily be always online, they would still control the DNS server.

As you know, Bolt 12 (reusable invoices) is being developed.

No its not. Look at what lightning implementations wallets with LSPs use. Look at what lightning implementations are used between those LSP routes. Its not LND or nothing. The more LND neglects what users who make payments actually want, the more irrelevant it will become over time.

There's no markings on the chip, but we do know its a 14 pin chip. If you send a current on one pin at a time and read the other pins with an ohms reader, you can at least map out the internal connections. I'll have to think of how to look up chips by internal connections from there.

What might be easier, if you could tell us where you got this board from, we could probably look up the board on the internet and figure it out that way