Tadge Dryja [ARCHIVE] on Nostr: 📅 Original date posted:2015-11-19 📝 Original message: Cool, I had not seen ...
📅 Original date posted:2015-11-19
📝 Original message:
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>
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>> 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151119/c3686d88/attachment.html>;
📝 Original message:
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>
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>> 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151119/c3686d88/attachment.html>;