[Lightning-dev] AMP via HD, BN+SS, and TR

ZmnSCPxj ZmnSCPxj at protonmail.com
Tue Mar 20 02:32:16 UTC 2018


Good morning Andrew,

> Hi ZmnSCPxj,
> 
> Yep, I'm pretty sure this works the way you describe -- essentially replace
> 
> the hash challenges with adaptor signatures which are reblinded at each layer.


Thank you very much your confirmation.

> For example, with adaptor signatures + Graftroot \[1\], one party can make their
> 
> commit-tx signature atomic with a delegation to a timelock script; the other
> 
> party does the same but for a different timelock script. Then maybe both parties
> 
> can share the same commit tx rather than doing the symmetric thing, which would
> 
> save space and simplify the protocol a bit.

Possibly not?  On each pair of symmetric commitments, an output that is timelocked on one commitment transaction is not timelocked on the other commitment transaction, and that output is signable by the same party.  E.g. in the simple case with a single output controlled by a single party A, A has a commitment transaction whose output is timelocked and unlockable by A, B has a commitment transaction whose output is only unlockable by A (and in particular not timelocked).  Each side still needs its own commitment transaction I think.

(unless Graftroot is even more magical than how I understand it: my skills already strain trying to understand Scriptless Script and Taproot, so possibly I just do not understand Graftroot well enough)

Symmetry in commitment transactions is not particularly space-heavy.  Well-behaved nodes will never bother storing old commitments and can delete those from disk, and you only need to store your own commitment --- the other commitment is the responsibility of the counterparty to store.

> And more generally, this "output
> 
> has different spend conditions depending on who publishes to the chain" primitive
> 
> seems like a really powerful thing, and AFAIK nobody has noticed this feature of
> 
> Graftroot until very recently.

Ah, this is indeed very interesting!

Regards,
ZmnSCPxj


More information about the Lightning-dev mailing list