Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2015-11-19 📝 Original message: Its still a huge code ...
📅 Original date posted:2015-11-19
📝 Original message:
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
>
📝 Original message:
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
>