[Lightning-dev] Lightning, the death of BIP62, and Segregated Witness

Matt Corallo lf-lists at mattcorallo.com
Thu Nov 19 19:38:46 UTC 2015


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 <mark at friedenbach.org
> <mailto:mark at friedenbach.org>> 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 <gsanders87 at gmail.com
>     <mailto:gsanders87 at gmail.com>> 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
>         <glenn at tarbox.org <mailto:glenn at tarbox.org>> wrote:
>
>
>             On Thu, Nov 19, 2015 at 4:33 AM, sickpig at gmail.com
>             <mailto:sickpig at gmail.com> <sickpig at gmail.com
>             <mailto: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
>             <mailto:Lightning-dev at lists.linuxfoundation.org>
>             https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
>
>         _______________________________________________
>         Lightning-dev mailing list
>         Lightning-dev at lists.linuxfoundation.org
>         <mailto:Lightning-dev at lists.linuxfoundation.org>
>         https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
>
>     _______________________________________________
>     Lightning-dev mailing list
>     Lightning-dev at lists.linuxfoundation.org
>     <mailto: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
>


More information about the Lightning-dev mailing list