From lf-lists at mattcorallo.com Thu Nov 19 19:48:04 2015 From: lf-lists at mattcorallo.com (Matt Corallo) Date: Thu, 19 Nov 2015 19:48:04 +0000 Subject: [Lightning-dev] Lightning, the death of BIP62, and Segregated Witness In-Reply-To: References: <87si42n1ir.fsf@rustcorp.com.au> <1447920788.2353.12.camel@ultimatestunts.nl> <564E2546.3060908@mattcorallo.com> Message-ID: <564E2774.7090205@mattcorallo.com> Its still a huge code change that hasnt been significantly discussed publicly, so I think opinions on what to do have yet to solidify, but (at the risk of putting words in other people's mouths) I think a part of retracting BIP62 is because Pieter wants to push this forward. On 11/19/15 19:40, Tadge Dryja wrote: > Cool, I had not seen that, I'll take a look. I'm all for anything that > allows reliable spends from unconfirmed txs. If SW can get in easier, > sounds good. > > -Tadge > > On Thu, Nov 19, 2015 at 11:38 AM, Matt Corallo > wrote: > > Nope, Luke came up with a way to do it in a soft-fork. > > On 11/19/15 19:12, Tadge Dryja wrote: > > I've joked that BIP62 is the "whack-a-mole" BIP in that it addresses > many vectors for txid malleability, but maybe there are more. > And more > importantly, it addresses 3rd party malleability. It's not > helpful in > the context of lightning channel creation because ECDSA sigs are > inherently malleable. You can always re-sign the same message > with a > different k-value and get a different signature. > > The functionality that's needed is to be able to reliably spend from > unconfirmed transactions. Segregated witness can accomplish > that, but > it quite a large hard-fork change. sighash_noinput can also > accomplish > that: as input txids are not signed, if they change, the spending > transaction can be modified while leaving counterparty > signatures intact. > > I'm hoping to start a new "testnet-L" similar to testnet3, with this > sighash type so that we can test malleability mitigation out. > > (Oh also, hi mailing list, sorry I have not posted till now! > But I will > start posting!) > > -Tadge > > On Thu, Nov 19, 2015 at 9:56 AM, Mark Friedenbach > > >> wrote: > > The basic idea of the soft-fork plan is very simple --- > have the > scriptPubKey be just the 20-byte hash of the redeem script. The > scriptSig of the spending input is empty. The actual > scriptSig, with > the redeem script and signatures, is contained in a > separate Merkle > tree committed to elsewhere in the block (e.g. in the last > output of > the coinbase, or the last output of the last transaction). > > On Thu, Nov 19, 2015 at 7:31 AM, Greg Sanders > > >> wrote: > > The hardfork variant is quite simple, if I understood it > correctly. You just stick the signatures in another > parallel > merkle tree. So if you don't want to validate > signatures, just > don't download them, and validate everything else. > TXIDs don't > use the signature at all. Nothing to malleate, AFAIK. > Not sure > what the softfork plan is, but it will be a talk at Scaling > Bitcoin HK. > > On Thu, Nov 19, 2015 at 10:28 AM, Glenn Tarbox, PhD > > >> wrote: > > > On Thu, Nov 19, 2015 at 4:33 AM, sickpig at gmail.com > > > > >> wrote: > > Hi Pierre > > you could start here > > https://github.com/ElementsProject/elementsproject.github.io#segregated-witness > https://people.xiph.org/~greg/blockstream.gmaxwell.elements.talk.060815.pdf > https://github.com/ElementsProject/elements > > > There was a brief blip on Reddit: > > https://www.reddit.com/r/Bitcoin/comments/3ngtx5/could_the_segregated_witness_part_of_the/cwnthlh > > Its weird how little information there is on Segregated > Witness. I'm guessing its a simple concept and those > working on it (sipa / gmaxwell) haven't felt the > need to > write it up. > > That it "apparently" can be done with a soft fork > similar to > P2SH is good news... I guess... > > > -- > Glenn H. Tarbox, PhD > =]|[= > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >