📅 Original date posted:2015-05-16
📝 Original message:We should make sure to consider how BIP34 affects normalized transaction ids, since the height of the block is included in the scriptSig ensuring that the txid will be different. We wouldn't want to enable replay attacks in the form of spending coinbase outputs in the same way they were spent from a previous block.
So maybe normalized txids should strip the scriptSigs of all transactions except for coinbase transactions? This seems to make sense, since coinbase transactions are inherently not malleable anyway.
Also, s7r linked to my 'Build your own nHashType' proposal (although V2 is here: https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal_v2.md). I just wanted to add that I think even with normalized ids, it could still be useful to be able to apply these flags to choose which parts of the transaction become signed. I've also seen vague references to some kind of a merklized abstract syntax tree, but am not fully sure how that would work. Maybe someone on here could explain it?
Best,
Stephen
> On May 15, 2015, at 5:54 AM, s7r <s7r at sky-ip.org> wrote:
>
> Hello,
>
> How will this exactly be safe against:
> a) the malleability of the parent tx (2nd level malleability)
> b) replays
>
> If you strip just the scriptSig of the input(s), the txid(s) can still
> be mutated (with higher probability before it gets confirmed).
>
> If you strip both the scriptSig of the parent and the txid, nothing can
> any longer be mutated but this is not safe against replays. This could
> work if we were using only one scriptPubKey per tx. But this is not
> enforced, and I don't think it's the proper way to do it.
>
> Something similar can be achieved if you would use a combination of
> flags from here:
>
> https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md
>
> But this has some issues too.
>
> I've read your draft but didn't understand how exactly will this prevent
> normal malleability as we know it, second level malleability and replays
> as well as how will we do the transition into mapping the txes in the
> blockchain to normalized txids. Looking forward to read more on this
> topic. Thanks for the brainstorming ;)
>
>
>> On 5/13/2015 3:48 PM, Christian Decker wrote:
>> Hi All,
>>
>> I'd like to propose a BIP to normalize transaction IDs in order to
>> address transaction malleability and facilitate higher level protocols.
>>
>> The normalized transaction ID is an alias used in parallel to the
>> current (legacy) transaction IDs to address outputs in transactions. It
>> is calculated by removing (zeroing) the scriptSig before computing the
>> hash, which ensures that only data whose integrity is also guaranteed by
>> the signatures influences the hash. Thus if anything causes the
>> normalized ID to change it automatically invalidates the signature. When
>> validating a client supporting this BIP would use both the normalized tx
>> ID as well as the legacy tx ID when validating transactions.
>>
>> The detailed writeup can be found
>> here: https://github.com/cdecker/bips/blob/normalized-txid/bip-00nn.mediawiki.
>>
>> @gmaxwell: I'd like to request a BIP number, unless there is something
>> really wrong with the proposal.
>>
>> In addition to being a simple alternative that solves transaction
>> malleability it also hugely simplifies higher level protocols. We can
>> now use template transactions upon which sequences of transactions can
>> be built before signing them.
>>
>> I hesitated quite a while to propose it since it does require a hardfork
>> (old clients would not find the prevTx identified by the normalized
>> transaction ID and deem the spending transaction invalid), but it seems
>> that hardforks are no longer the dreaded boogeyman nobody talks about.
>> I left out the details of how the hardfork is to be done, as it does not
>> really matter and we may have a good mechanism to apply a bunch of
>> hardforks concurrently in the future.
>>
>> I'm sure it'll take time to implement and upgrade, but I think it would
>> be a nice addition to the functionality and would solve a long standing
>> problem :-)
>>
>> Please let me know what you think, the proposal is definitely not set in
>> stone at this point and I'm sure we can improve it further.
>>
>> Regards,
>> Christian
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>
> ------------------------------------------------------------------------------
> 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
Stephen [ARCHIVE] /
npub1zq…53esn
2023-06-07 15:35:14
in reply to nevent1q…hvul
Author Public Key
npub1zq3c5mgvdpyvrt9evdtn48d47du4s03fxdjrvx7cv3mtf93hqjgqj53esnPublished at
2023-06-07 15:35:14Event JSON
{
"id": "f5017ee20f3bae309141622cc101311e4b1a947b8a1f604d5f0b03795370542f",
"pubkey": "10238a6d0c6848c1acb963573a9db5f379583e293364361bd86476b496370490",
"created_at": 1686152114,
"kind": 1,
"tags": [
[
"e",
"d4296383f49c1a9f727ee325cad107826210d0f0a44bfb48a025773c99b7560e",
"",
"root"
],
[
"e",
"7952d8f4b7d9f7ea57c8afe2cd05101e0e9de44b1835d3137f77f5cb675b470a",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2015-05-16\n📝 Original message:We should make sure to consider how BIP34 affects normalized transaction ids, since the height of the block is included in the scriptSig ensuring that the txid will be different. We wouldn't want to enable replay attacks in the form of spending coinbase outputs in the same way they were spent from a previous block. \n\nSo maybe normalized txids should strip the scriptSigs of all transactions except for coinbase transactions? This seems to make sense, since coinbase transactions are inherently not malleable anyway. \n\nAlso, s7r linked to my 'Build your own nHashType' proposal (although V2 is here: https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal_v2.md). I just wanted to add that I think even with normalized ids, it could still be useful to be able to apply these flags to choose which parts of the transaction become signed. I've also seen vague references to some kind of a merklized abstract syntax tree, but am not fully sure how that would work. Maybe someone on here could explain it? \n\nBest,\nStephen\n\n\n\n\u003e On May 15, 2015, at 5:54 AM, s7r \u003cs7r at sky-ip.org\u003e wrote:\n\u003e \n\u003e Hello,\n\u003e \n\u003e How will this exactly be safe against:\n\u003e a) the malleability of the parent tx (2nd level malleability)\n\u003e b) replays\n\u003e \n\u003e If you strip just the scriptSig of the input(s), the txid(s) can still\n\u003e be mutated (with higher probability before it gets confirmed).\n\u003e \n\u003e If you strip both the scriptSig of the parent and the txid, nothing can\n\u003e any longer be mutated but this is not safe against replays. This could\n\u003e work if we were using only one scriptPubKey per tx. But this is not\n\u003e enforced, and I don't think it's the proper way to do it.\n\u003e \n\u003e Something similar can be achieved if you would use a combination of\n\u003e flags from here:\n\u003e \n\u003e https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md\n\u003e \n\u003e But this has some issues too.\n\u003e \n\u003e I've read your draft but didn't understand how exactly will this prevent\n\u003e normal malleability as we know it, second level malleability and replays\n\u003e as well as how will we do the transition into mapping the txes in the\n\u003e blockchain to normalized txids. Looking forward to read more on this\n\u003e topic. Thanks for the brainstorming ;)\n\u003e \n\u003e \n\u003e\u003e On 5/13/2015 3:48 PM, Christian Decker wrote:\n\u003e\u003e Hi All,\n\u003e\u003e \n\u003e\u003e I'd like to propose a BIP to normalize transaction IDs in order to\n\u003e\u003e address transaction malleability and facilitate higher level protocols.\n\u003e\u003e \n\u003e\u003e The normalized transaction ID is an alias used in parallel to the\n\u003e\u003e current (legacy) transaction IDs to address outputs in transactions. It\n\u003e\u003e is calculated by removing (zeroing) the scriptSig before computing the\n\u003e\u003e hash, which ensures that only data whose integrity is also guaranteed by\n\u003e\u003e the signatures influences the hash. Thus if anything causes the\n\u003e\u003e normalized ID to change it automatically invalidates the signature. When\n\u003e\u003e validating a client supporting this BIP would use both the normalized tx\n\u003e\u003e ID as well as the legacy tx ID when validating transactions.\n\u003e\u003e \n\u003e\u003e The detailed writeup can be found\n\u003e\u003e here: https://github.com/cdecker/bips/blob/normalized-txid/bip-00nn.mediawiki.\n\u003e\u003e \n\u003e\u003e @gmaxwell: I'd like to request a BIP number, unless there is something\n\u003e\u003e really wrong with the proposal.\n\u003e\u003e \n\u003e\u003e In addition to being a simple alternative that solves transaction\n\u003e\u003e malleability it also hugely simplifies higher level protocols. We can\n\u003e\u003e now use template transactions upon which sequences of transactions can\n\u003e\u003e be built before signing them.\n\u003e\u003e \n\u003e\u003e I hesitated quite a while to propose it since it does require a hardfork\n\u003e\u003e (old clients would not find the prevTx identified by the normalized\n\u003e\u003e transaction ID and deem the spending transaction invalid), but it seems\n\u003e\u003e that hardforks are no longer the dreaded boogeyman nobody talks about.\n\u003e\u003e I left out the details of how the hardfork is to be done, as it does not\n\u003e\u003e really matter and we may have a good mechanism to apply a bunch of\n\u003e\u003e hardforks concurrently in the future.\n\u003e\u003e \n\u003e\u003e I'm sure it'll take time to implement and upgrade, but I think it would\n\u003e\u003e be a nice addition to the functionality and would solve a long standing\n\u003e\u003e problem :-)\n\u003e\u003e \n\u003e\u003e Please let me know what you think, the proposal is definitely not set in\n\u003e\u003e stone at this point and I'm sure we can improve it further.\n\u003e\u003e \n\u003e\u003e Regards,\n\u003e\u003e Christian\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 \n\u003e\u003e \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 \n\u003e ------------------------------------------------------------------------------\n\u003e One dashboard for servers and applications across Physical-Virtual-Cloud \n\u003e Widest out-of-the-box monitoring support with 50+ applications\n\u003e Performance metrics, stats and reports that give you Actionable Insights\n\u003e Deep dive visibility with transaction tracing using APM Insight.\n\u003e http://ad.doubleclick.net/ddm/clk/290420510;117567292;y\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development",
"sig": "1afdd21318de3008c56e7ec3949d7eb2e3ffb91d8b58cada8d003cc6a00037d2a6e47b9e48e8cc5cdd59f3717ace51965a5b386591c8d030a985229130f2234d"
}