[Lightning-dev] We don't need R-Value, how OP_CODESEPARATOR saves the day

[Nicolas Dorier]

Yes they do,

But I did not thought you had a way not to store one R value per
commitment.
If you store one R Value per commitment, then the solution with
OP_CODESEPARATOR is strictly better as it saves space on
blockchain.

So indeed if old commit tx are published, they need to fetch the
signatures.

Nicolas,

On Tue, Mar 8, 2016 at 4:09 AM, Fabrice Drouin <fabrice.drouin at acinq.fr>
wrote:

> Hi,
> I may have misunderstood something, but with this scheme instead of R
> + shachain/elkrem, then how do nodes react when old commit tx are
> published ? It seems that they would have to store lots of signatures
> ?
>
>
> On 7 March 2016 at 08:28, Nicolas Dorier <nicolas.dorier at gmail.com> wrote:
> > I managed to adapt the payment channel script to use less space.
> >
> > This version is winning around 32 bytes in the scriptpubkey (for the R
> > value) as well as 70 bytes in the signature when Alice close the channel.
> >
> > Alice closing the channel:
> >
> http://n.bitcoin.ninja/checkscript?savedScript=51225750-f245-45b5-a86c-6ca1e87dcafb
> >
> > Bob using revocation:
> >
> http://n.bitcoin.ninja/checkscript?savedScript=c4d7ebaa-5a79-4c03-ab55-c499854f1e94
> >
> > This amount to 100 bytes saved between the anchor transaction +
> commitment
> > broadcasted.
> >
> > _______________________________________________
> > 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/20160308/f7b0831e/attachment-0001.html>