📅 Original date posted:2015-05-13
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150513/2131ae26/attachment.html>;
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-07 15:35:06
in reply to nevent1q…hmfy
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-07 15:35:06Event JSON
{
"id": "411b96c235634e7792bba53a2539dfea8da38495fad6b70141a756c664388e99",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686152106,
"kind": 1,
"tags": [
[
"e",
"d4296383f49c1a9f727ee325cad107826210d0f0a44bfb48a025773c99b7560e",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2015-05-13\n📝 Original message:Hi All,\n\nI'd like to propose a BIP to normalize transaction IDs in order to address\ntransaction malleability and facilitate higher level protocols.\n\nThe normalized transaction ID is an alias used in parallel to the current\n(legacy) transaction IDs to address outputs in transactions. It is\ncalculated by removing (zeroing) the scriptSig before computing the hash,\nwhich ensures that only data whose integrity is also guaranteed by the\nsignatures influences the hash. Thus if anything causes the normalized ID\nto change it automatically invalidates the signature. When validating a\nclient supporting this BIP would use both the normalized tx ID as well as\nthe legacy tx ID when validating transactions.\n\nThe detailed writeup can be found here:\nhttps://github.com/cdecker/bips/blob/normalized-txid/bip-00nn.mediawiki.\n\n@gmaxwell: I'd like to request a BIP number, unless there is something\nreally wrong with the proposal.\n\nIn addition to being a simple alternative that solves transaction\nmalleability it also hugely simplifies higher level protocols. We can now\nuse template transactions upon which sequences of transactions can be built\nbefore signing them.\n\nI hesitated quite a while to propose it since it does require a hardfork\n(old clients would not find the prevTx identified by the normalized\ntransaction ID and deem the spending transaction invalid), but it seems\nthat hardforks are no longer the dreaded boogeyman nobody talks about.\nI left out the details of how the hardfork is to be done, as it does not\nreally matter and we may have a good mechanism to apply a bunch of\nhardforks concurrently in the future.\n\nI'm sure it'll take time to implement and upgrade, but I think it would be\na nice addition to the functionality and would solve a long standing\nproblem :-)\n\nPlease let me know what you think, the proposal is definitely not set in\nstone at this point and I'm sure we can improve it further.\n\nRegards,\nChristian\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150513/2131ae26/attachment.html\u003e",
"sig": "2839d8d9afbae144074e7a72ac01a28fd517260d4989a5381f7ab13888520c29e2cc181a856848ab0754cf5ad43e5948482601684e399246496b8eee5c17f469"
}