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

Matt Corallo lf-lists at mattcorallo.com
Thu Nov 19 19:48:04 UTC 2015


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 <lf-lists at mattcorallo.com
> <mailto:lf-lists at mattcorallo.com>> 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
>         <mark at friedenbach.org <mailto:mark at friedenbach.org>
>         <mailto: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>
>              <mailto: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>
>         <mailto: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>
>                      <mailto:sickpig at gmail.com
>         <mailto:sickpig at gmail.com>> <sickpig at gmail.com
>         <mailto:sickpig at gmail.com>
>                      <mailto: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>
>                      <mailto: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>
>                  <mailto: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>
>              <mailto: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