Hi Antoine,
> "I also think resizing channels can be done fairly effectively
>off-chain
>with hierarchical channels [1] (and even better with hierarchical channels
>within timeout-trees)".
>Yes, transactional scaling of Lightning (i.e how many transfers can be
>performed off-chain per on-chain
Hi ZmnSCPxj,
> Good morning John,
> On the other hand, if the consensus rules are changed to allow even
> simple covenants, this scaling bottleneck is eliminated.
> The key observation is that with covenants, a casual user can
> co-own an off-chain Lightning channel without having to sign
Hi John,
Thanks for the additional insightful comments. See new questions at the end.
> "My main point is that there's a huge pool of potential users that just
want payments to work, and they don't want to devote time or hardware
resources to making them work (if they can away with that)"
Sure,
Good morning Erik,
> > replacing CTV usage with Musig2
>
>
> this changes the trust model to a federated one vs trustless and also
> increases the on-chain footprint of failure, correct?
As I understand it, no.
MuSig and MuSig2 are n-of-n signing algorithms.
The implied usage is that all
>
> replacing CTV usage with Musig2
>
>
this changes the trust model to a federated one vs trustless and also
increases the on-chain footprint of failure, correct?
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
Good morning John,
> On the other hand, if the consensus rules are changed to allow even simple
> covenants, this scaling bottleneck is eliminated.
> The key observation is that with covenants, a casual user can co-own an
> off-chain Lightning channel without having to sign all (or any) of the
Hi Rusty,
> I've read the start of the paper on my vacation, and am still
> digesting it. But even so far, it presents some delightful
> possibilities.
Great!
> As with some other proposals, it's worth noting that the cost of
> enforcement is dramatically increased. It's no longer one
Hi Antoine,
Thanks for your note. Responses are in-line below:
> Hi John,
> Thanks for the proposal, few feedback after a first look.
> If Bitcoin and Lightning are to become widely-used, they will have to
> be adopted by casual users who want to send and receive bitcoin, but who
> do not
Hi John,
Thanks for the proposal, few feedback after a first look.
> If Bitcoin and Lightning are to become widely-used, they will have to be
> adopted by casual users who want to send and receive bitcoin, but > who do
> not want to go to any effort in order to provide the infrastructure for
Hi!
I've read the start of the paper on my vacation, and am still
digesting it. But even so far, it presents some delightful
possibilities.
As with some other proposals, it's worth noting that the cost of
enforcement is dramatically increased. It's no longer one or two txs,
it's 10+.
TL;DR
=
* The key challenge in scaling Lightning in a trust-free manner is the creation
of Lightning channels for casual users.
- It appears that signature-based factories are inherently limited to
creating at most tens or hundreds of Lightning channels per UTXO.
- In contrast, simple
11 matches
Mail list logo
