From nicolas.dorier at gmail.com Tue Mar 8 04:25:53 2016 From: nicolas.dorier at gmail.com (Nicolas Dorier) Date: Tue, 8 Mar 2016 13:25:53 +0900 Subject: [Lightning-dev] We don't need R-Value, how OP_CODESEPARATOR saves the day In-Reply-To: References: Message-ID: 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 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 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: