📅 Original date posted:2015-05-14
📝 Original message:Sorry about that, sometimes I hate keyboard shortcuts :-)
Ok, I think I got the OP_CHECKAWESOMESIG proposal, transactions keep
referencing using hashes of complete transactions (including signatures),
while the OP_CHECKAWESOMESIG looks up the previous transaction (which we
already need to do anyway in order to insert the prevOut pubkeyScript),
normalizes the prevout and calculates its normalized transaction ID. It
then inserts the normalized transaction IDs in the OutPoint before
calculating its own hash which is then signed. Is that correct so far?
Let me try to summarize the discussion so far:
I think we have consensus that transaction malleability needs to be
addressed, and normalized transaction IDs seem to be the way to go forward.
The discussion now is how to use normalized transaction IDs and we have two
approaches to implement them:
- OP_CHECKAWESOMESIG which continues to use the current hashes to
reference a specific signed instance of a class of semantically identical
transactions. Internally only the semantic class is enforced. Transactions
can be fixed to reference the correct signed instance if the transaction
has been changed along the way.
- The second proposal advocates using the normalized transaction IDs
directly in the transactions, requiring no further intervention to fix an
eventually malleated transaction.
Both approaches have their own advantages and problems:
OP_CHECKAWESOMESIG is a soft-fork which makes it somewhat less problematic
to roll-out and does not break existing software. The normalized
transaction ID can be computed on the fly (possibly increasing lookup
times) or stored alongside the UTXO (increasing storage needs). If the
normalized transaction IDs really need to be recomputed down to the
coinbase then the increased storage is the only option, and would add 32
byte to every transaction metadata in the UTXO.
My proposal is harder to migrate to, as it requires a hardfork, and will
require more storage (64 byte raw data for a normalized to legacy
transaction ID) for every transaction in the UTXO set. At 6 million
distinct transactions which unspent outputs this boils down to 384 MB
(though this may change in future by introducing an aggregation strategy or
fragment further). Some of that space may be reclaimed. There is absolutely
no interaction required to fix up transactions if a dependency has been
malleated, since we address a semantic class, not the specific instance. We
limit the use of normalized transaction IDs to the OutPoint in
transactions, since there we want to reference the semantic class not the
actual signed instance. At protocol message level (inv, getdata) and blocks
we continue to use the legacy ID. This is not as nice as having one ID for
every transaction that is used everywhere.
Both solutions solve malleability, just with different tradeoffs.
I don't see them as mutually exclusive, if we adopt the OP_CHECKAWESOMESIG
as short term fix, that can be rolled out and applied, then my proposal can
be seen as long-term goal that is semantically cleaner and easier to
implement.
Personally I think hard-forks shouldn't be the dreaded boogeyman everybody
makes them out to be, we have never really tested rolling out a hardfork
and they might just turn out to be possible. I don't thing we loose
anything by attempting this, except maybe reduce the urgency to apply some
perfect future thing.
Regards,
Christian
On Thu, May 14, 2015 at 1:01 PM, Christian Decker <
decker.christian at gmail.com> wrote:
> Ok, I think I got the OP_CHECKAWESOMESIG proposal, transactions keep
> referencing using hashes of complete transactions (including signatures),
> while the OP_CHECKAWESOMESIG looks up the previous transaction (which we
> already need to do anyway in order to insert the prevOut pubkeyScript),
> normalizes the prevout and calculates its normalized transaction ID. It
> then inserts the normalized transaction IDs in the OutPoint before
> calculating its own hash which is then signed. Is that correct so far?
>
> Let me try to summarize the discussion so far:
>
> I think we have consensus that transaction malleability needs to be
> addressed, and normalized transaction IDs seem to be the way to go forward.
>
> The discussion now is how to use normalized transaction IDs and we have
> two approaches to implement them:
>
> - OP_CHECKAWESOMESIG which continues to use the current hashes to
> reference a specific signed instance of a class of semantically identical
> transactions. Internally only the semantic class is enforced. Transactions
> can be fixed to reference the correct signed instance if the transaction
> has been changed along the way.is a softfork using the "if I don't
> know this opcode the TX is automatically valid" trick
>
>
> On Thu, May 14, 2015 at 2:40 AM Pieter Wuille <pieter.wuille at gmail.com>
> wrote:
>
>> On Wed, May 13, 2015 at 1:32 PM, Tier Nolan <tier.nolan at gmail.com> wrote:
>>
>>>
>>> On Wed, May 13, 2015 at 9:31 PM, Pieter Wuille <pieter.wuille at gmail.com>
>>> wrote:
>>>
>>>>
>>>> This was what I was suggesting all along, sorry if I wasn't clear.
>>>>
>>>> That's great. So, basically the multi-level refund problem is solved
>>> by this?
>>>
>>
>> Yes. So to be clear, I think there are 2 desirable end-goal proposals
>> (ignoring difficulty of changing things for a minute):
>>
>> * Transactions and blocks keep referring to other transactions by full
>> txid, but signature hashes are computed off normalized txids (which are
>> recursively defined to use normalized txids all the way back to coinbases).
>> Is this what you are suggesting now as well?
>>
>> * Blocks commit to full transaction data, but transactions and signature
>> hashes use normalized txids.
>>
>> The benefit of the latter solution is that it doesn't need "fixing up"
>> transactions whose inputs have been malleated, but comes at the cost of
>> doing a very invasive hard fork.
>>
>> --
>> Pieter
>>
>>
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150514/acae1f4f/attachment.html>;
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-07 15:35:13
in reply to nevent1q…v5ym
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-07 15:35:13Event JSON
{
"id": "6e3d3b869dcc4e4726d81b8132a0471c49cd5c2c3ca7b9a192e4d472fbd5e3e6",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686152113,
"kind": 1,
"tags": [
[
"e",
"d4296383f49c1a9f727ee325cad107826210d0f0a44bfb48a025773c99b7560e",
"",
"root"
],
[
"e",
"6596e59d6c4271f7bc314134211fa00db1ca583404b14f298661910d3b1d69aa",
"",
"reply"
],
[
"p",
"72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057"
]
],
"content": "📅 Original date posted:2015-05-14\n📝 Original message:Sorry about that, sometimes I hate keyboard shortcuts :-)\n\n\nOk, I think I got the OP_CHECKAWESOMESIG proposal, transactions keep\nreferencing using hashes of complete transactions (including signatures),\nwhile the OP_CHECKAWESOMESIG looks up the previous transaction (which we\nalready need to do anyway in order to insert the prevOut pubkeyScript),\nnormalizes the prevout and calculates its normalized transaction ID. It\nthen inserts the normalized transaction IDs in the OutPoint before\ncalculating its own hash which is then signed. Is that correct so far?\n\nLet me try to summarize the discussion so far:\n\nI think we have consensus that transaction malleability needs to be\naddressed, and normalized transaction IDs seem to be the way to go forward.\n\nThe discussion now is how to use normalized transaction IDs and we have two\napproaches to implement them:\n\n\n - OP_CHECKAWESOMESIG which continues to use the current hashes to\n reference a specific signed instance of a class of semantically identical\n transactions. Internally only the semantic class is enforced. Transactions\n can be fixed to reference the correct signed instance if the transaction\n has been changed along the way.\n - The second proposal advocates using the normalized transaction IDs\n directly in the transactions, requiring no further intervention to fix an\n eventually malleated transaction.\n\nBoth approaches have their own advantages and problems:\n\nOP_CHECKAWESOMESIG is a soft-fork which makes it somewhat less problematic\nto roll-out and does not break existing software. The normalized\ntransaction ID can be computed on the fly (possibly increasing lookup\ntimes) or stored alongside the UTXO (increasing storage needs). If the\nnormalized transaction IDs really need to be recomputed down to the\ncoinbase then the increased storage is the only option, and would add 32\nbyte to every transaction metadata in the UTXO.\n\nMy proposal is harder to migrate to, as it requires a hardfork, and will\nrequire more storage (64 byte raw data for a normalized to legacy\ntransaction ID) for every transaction in the UTXO set. At 6 million\ndistinct transactions which unspent outputs this boils down to 384 MB\n(though this may change in future by introducing an aggregation strategy or\nfragment further). Some of that space may be reclaimed. There is absolutely\nno interaction required to fix up transactions if a dependency has been\nmalleated, since we address a semantic class, not the specific instance. We\nlimit the use of normalized transaction IDs to the OutPoint in\ntransactions, since there we want to reference the semantic class not the\nactual signed instance. At protocol message level (inv, getdata) and blocks\nwe continue to use the legacy ID. This is not as nice as having one ID for\nevery transaction that is used everywhere.\n\nBoth solutions solve malleability, just with different tradeoffs.\n\nI don't see them as mutually exclusive, if we adopt the OP_CHECKAWESOMESIG\nas short term fix, that can be rolled out and applied, then my proposal can\nbe seen as long-term goal that is semantically cleaner and easier to\nimplement.\n\nPersonally I think hard-forks shouldn't be the dreaded boogeyman everybody\nmakes them out to be, we have never really tested rolling out a hardfork\nand they might just turn out to be possible. I don't thing we loose\nanything by attempting this, except maybe reduce the urgency to apply some\nperfect future thing.\n\nRegards,\nChristian\n\nOn Thu, May 14, 2015 at 1:01 PM, Christian Decker \u003c\ndecker.christian at gmail.com\u003e wrote:\n\n\u003e Ok, I think I got the OP_CHECKAWESOMESIG proposal, transactions keep\n\u003e referencing using hashes of complete transactions (including signatures),\n\u003e while the OP_CHECKAWESOMESIG looks up the previous transaction (which we\n\u003e already need to do anyway in order to insert the prevOut pubkeyScript),\n\u003e normalizes the prevout and calculates its normalized transaction ID. It\n\u003e then inserts the normalized transaction IDs in the OutPoint before\n\u003e calculating its own hash which is then signed. Is that correct so far?\n\u003e\n\u003e Let me try to summarize the discussion so far:\n\u003e\n\u003e I think we have consensus that transaction malleability needs to be\n\u003e addressed, and normalized transaction IDs seem to be the way to go forward.\n\u003e\n\u003e The discussion now is how to use normalized transaction IDs and we have\n\u003e two approaches to implement them:\n\u003e\n\u003e - OP_CHECKAWESOMESIG which continues to use the current hashes to\n\u003e reference a specific signed instance of a class of semantically identical\n\u003e transactions. Internally only the semantic class is enforced. Transactions\n\u003e can be fixed to reference the correct signed instance if the transaction\n\u003e has been changed along the way.is a softfork using the \"if I don't\n\u003e know this opcode the TX is automatically valid\" trick\n\u003e\n\u003e\n\u003e On Thu, May 14, 2015 at 2:40 AM Pieter Wuille \u003cpieter.wuille at gmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e On Wed, May 13, 2015 at 1:32 PM, Tier Nolan \u003ctier.nolan at gmail.com\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e On Wed, May 13, 2015 at 9:31 PM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003e\n\u003e\u003e\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e This was what I was suggesting all along, sorry if I wasn't clear.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e That's great. So, basically the multi-level refund problem is solved\n\u003e\u003e\u003e by this?\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e Yes. So to be clear, I think there are 2 desirable end-goal proposals\n\u003e\u003e (ignoring difficulty of changing things for a minute):\n\u003e\u003e\n\u003e\u003e * Transactions and blocks keep referring to other transactions by full\n\u003e\u003e txid, but signature hashes are computed off normalized txids (which are\n\u003e\u003e recursively defined to use normalized txids all the way back to coinbases).\n\u003e\u003e Is this what you are suggesting now as well?\n\u003e\u003e\n\u003e\u003e * Blocks commit to full transaction data, but transactions and signature\n\u003e\u003e hashes use normalized txids.\n\u003e\u003e\n\u003e\u003e The benefit of the latter solution is that it doesn't need \"fixing up\"\n\u003e\u003e transactions whose inputs have been malleated, but comes at the cost of\n\u003e\u003e doing a very invasive hard fork.\n\u003e\u003e\n\u003e\u003e --\n\u003e\u003e Pieter\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e One dashboard for servers and applications across Physical-Virtual-Cloud\n\u003e\u003e Widest out-of-the-box monitoring support with 50+ applications\n\u003e\u003e Performance metrics, stats and reports that give you Actionable Insights\n\u003e\u003e Deep dive visibility with transaction tracing using APM Insight.\n\u003e\u003e http://ad.doubleclick.net/ddm/clk/290420510;117567292;y\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150514/acae1f4f/attachment.html\u003e",
"sig": "bc83b51e6fe08c53970fbe506f96e47a422aa967200ff5a8e260f33b98899c2c47f31f5ee6feb27a3f7771724f1229bfa16eb1aaef1f5f70a01fb8dc932b042b"
}