From laolu32 at gmail.com  Mon May  7 23:58:54 2018
From: laolu32 at gmail.com (Olaoluwa Osuntokun)
Date: Mon, 07 May 2018 23:58:54 +0000
Subject: [Lightning-dev] Scriptless Scripts with ECDSA
In-Reply-To: <WqRM7vHWZJ2xs45_ejEq4WjkojYSgc9q7NoBRZyGmAagPm3QBcyry3kWtm1YW31dqV4OyVLZCHoa1zRlKf2grpWc7ILzqfmBo4x_3gFELXk=@protonmail.com>
References: <39f93652-666d-8864-5b3e-0141f3e45085@purdue.edu>
	<WqRM7vHWZJ2xs45_ejEq4WjkojYSgc9q7NoBRZyGmAagPm3QBcyry3kWtm1YW31dqV4OyVLZCHoa1zRlKf2grpWc7ILzqfmBo4x_3gFELXk=@protonmail.com>
Message-ID: <CAO3Pvs9vD1aQ5_pWVPL2uxd6T4Ca=XSFOh6E_TWFVw8FJOL=Gw@mail.gmail.com>

> 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180507/58d3211e/attachment.html>