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 

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 (?).

Lightning-dev mailing list

Reply via email to