📅 Original date posted:2015-11-19
📝 Original message:
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
>
Matt Corallo [ARCHIVE] /
npub1e4…jxmcu
2023-06-09 12:45:09
in reply to nevent1q…ar37
Author Public Key
npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuPublished at
2023-06-09 12:45:09Event JSON
{
"id": "b11412a1d4fc731a5293c2ab3c245f8ee2007f4040e8e80cf191daec88f3ff2f",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686314709,
"kind": 1,
"tags": [
[
"e",
"1af72c6403b0bf6c208cd96111979b74febacb268ea0e46444fb1495c20b46af",
"",
"root"
],
[
"e",
"2458934c3ec7853b562af068ebbf7d150bd05839d5027b430b440ac8bae2402d",
"",
"reply"
],
[
"p",
"650f4d21ea171bfb75c6bd78ba5b1aeace2a658bf7bee367bde3736055bf4e2d"
]
],
"content": "📅 Original date posted:2015-11-19\n📝 Original message:\nNope, Luke came up with a way to do it in a soft-fork.\n\nOn 11/19/15 19:12, Tadge Dryja wrote:\n\u003e I've joked that BIP62 is the \"whack-a-mole\" BIP in that it addresses\n\u003e many vectors for txid malleability, but maybe there are more. And more\n\u003e importantly, it addresses 3rd party malleability. It's not helpful in\n\u003e the context of lightning channel creation because ECDSA sigs are\n\u003e inherently malleable. You can always re-sign the same message with a\n\u003e different k-value and get a different signature.\n\u003e\n\u003e The functionality that's needed is to be able to reliably spend from\n\u003e unconfirmed transactions. Segregated witness can accomplish that, but\n\u003e it quite a large hard-fork change. sighash_noinput can also accomplish\n\u003e that: as input txids are not signed, if they change, the spending\n\u003e transaction can be modified while leaving counterparty signatures intact.\n\u003e\n\u003e I'm hoping to start a new \"testnet-L\" similar to testnet3, with this\n\u003e sighash type so that we can test malleability mitigation out.\n\u003e\n\u003e (Oh also, hi mailing list, sorry I have not posted till now! But I will\n\u003e start posting!)\n\u003e\n\u003e -Tadge\n\u003e\n\u003e On Thu, Nov 19, 2015 at 9:56 AM, Mark Friedenbach \u003cmark at friedenbach.org\n\u003e \u003cmailto:mark at friedenbach.org\u003e\u003e wrote:\n\u003e\n\u003e The basic idea of the soft-fork plan is very simple --- have the\n\u003e scriptPubKey be just the 20-byte hash of the redeem script. The\n\u003e scriptSig of the spending input is empty. The actual scriptSig, with\n\u003e the redeem script and signatures, is contained in a separate Merkle\n\u003e tree committed to elsewhere in the block (e.g. in the last output of\n\u003e the coinbase, or the last output of the last transaction).\n\u003e\n\u003e On Thu, Nov 19, 2015 at 7:31 AM, Greg Sanders \u003cgsanders87 at gmail.com\n\u003e \u003cmailto:gsanders87 at gmail.com\u003e\u003e wrote:\n\u003e\n\u003e The hardfork variant is quite simple, if I understood it\n\u003e correctly. You just stick the signatures in another parallel\n\u003e merkle tree. So if you don't want to validate signatures, just\n\u003e don't download them, and validate everything else. TXIDs don't\n\u003e use the signature at all. Nothing to malleate, AFAIK. Not sure\n\u003e what the softfork plan is, but it will be a talk at Scaling\n\u003e Bitcoin HK.\n\u003e\n\u003e On Thu, Nov 19, 2015 at 10:28 AM, Glenn Tarbox, PhD\n\u003e \u003cglenn at tarbox.org \u003cmailto:glenn at tarbox.org\u003e\u003e wrote:\n\u003e\n\u003e\n\u003e On Thu, Nov 19, 2015 at 4:33 AM, sickpig at gmail.com\n\u003e \u003cmailto:sickpig at gmail.com\u003e \u003csickpig at gmail.com\n\u003e \u003cmailto:sickpig at gmail.com\u003e\u003e wrote:\n\u003e\n\u003e Hi Pierre\n\u003e\n\u003e you could start here\n\u003e\n\u003e https://github.com/ElementsProject/elementsproject.github.io#segregated-witness\n\u003e https://people.xiph.org/~greg/blockstream.gmaxwell.elements.talk.060815.pdf\n\u003e https://github.com/ElementsProject/elements\n\u003e\n\u003e\n\u003e There was a brief blip on Reddit:\n\u003e\n\u003e https://www.reddit.com/r/Bitcoin/comments/3ngtx5/could_the_segregated_witness_part_of_the/cwnthlh\n\u003e\n\u003e Its weird how little information there is on Segregated\n\u003e Witness. I'm guessing its a simple concept and those\n\u003e working on it (sipa / gmaxwell) haven't felt the need to\n\u003e write it up.\n\u003e\n\u003e That it \"apparently\" can be done with a soft fork similar to\n\u003e P2SH is good news... I guess...\n\u003e\n\u003e\n\u003e --\n\u003e Glenn H. Tarbox, PhD\n\u003e =]|[=\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:Lightning-dev at lists.linuxfoundation.org\u003e\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:Lightning-dev at lists.linuxfoundation.org\u003e\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:Lightning-dev at lists.linuxfoundation.org\u003e\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e",
"sig": "b68a4fd73498fd354f76dfd142db6c917b2a92690204a3b6756235d74b7bb06dd528fafdc1ee4a1287315d041430b058ec276ced2bfde03f29cf5da224f5238a"
}