> It is also not clear to me how well B-N signature aggregation can work for > Lightning use-cases; certainly onchain claims of unilateral closes can be > made smaller with signature aggregation, but for mutual closes, there is > only one input, unless we support close aggregation somehow
>From the PoV, the two-stage HTLCs, depending on how cross-input sigagg was implemented, this would allow us (using sighash_single+anyone_can_pay) to coalesce all the second-layer HTLCs for a particularly state+party into a single transaction with a single signature spending all HTLCs to the second layer/stage. -- Laolu On Sun, Apr 29, 2018 at 9:23 PM ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good morning Pedro, > > This is certainly of great interest to me; unfortunately I am not a > mathematician and probably cannot review if the math is correct or not. In > particular it seems to me, naively, to be able to implement my AMP idea > which supports both path decorrelation and proof-of-payment, which is based > on SS and HD. > > The Lightning BOLT 1.0 spec is mostly frozen and we have good > inter-implementation working of HTLCs. Supporting SS, whether on top of > ECDSA or Bellare-Neven, will be a large effort, and it is not clear to me > if it is easy to switch between ECDSA and Bellare-Neven dynamically (i.e. > if one hop supports ECDSA SS and the next hop supports Bellare-Neven SS). > > It is also not clear to me how well B-N signature aggregation can work for > Lightning use-cases; certainly onchain claims of unilateral closes can be > made smaller with signature aggregation, but for mutual closes, there is > only one input, unless we support close aggregation somehow (involving more > than two parties, so much more effort). A 2-of-2 with a single signature > (which I believe is the basis of your SS work?) would let the mutual close > and commitment transactions be smaller by one signature and one pubkey, > though. > > At the Lightning BOLT spec level: > > 1. We need a new global feature bit, `option_support_scriptless`, which > would support routing of scriptless-script conditional payments. Paying > via SS can only be done if the entire route supports this option, which may > hamper adoption and complicate routing implementations (cannot route an SS > payment through nodes that do not support SS). > > 2. Depending on how easy it would be to translate between ECDSA and > Bellare-Neven SS, maybe only a local-level feature bit for > `option_support_scriptless_ecdsa` and `option_support_scriptless_bn`? > > 3. Also affects BOLT11 as we would have to support both `SHA256(secret)` > and `secret * G` in invoices, with the latter being used for SS payments. > > 4. We may want intra-path decorrelation (indeed, aside from AMP, this is > the other use of SS on Lightning). This requires passing a blinding secret > to each layer of the onion in the onion routes, I think (?). > > > Regards, > ZmnSCPxj > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
