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
