{"type":"rich","version":"1.0","author_name":"npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn","author_url":"https://nostr.ae/npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-10-19\n📝 Original message:After spending some more time on the normalized transaction ID proposal and\nreworking it to be a soft-fork (thanks sipa for helping me figuring out\nhow), I'd like to propose the BIP again.\n\nAs with the previous version, which was using a hard-fork, the normalized\ntransaction ID is computed only considering the non-malleable parts of a\ntransaction, i.e., stripping the signatures before computing the hash of\nthe transaction. This ensures that if a transaction is modified, either by\na third party fishing transactions from the network and re-injecting\nmodified versions or by one of the signers re-signing it, any transaction\nthat builds on top of it still remains valid. Furthermore it allows the use\nof template transactions, unsigned transactions upon which further\ntransaction can be built before signing the template transaction and\nlocking the contract.\n\nUnlike the previous proposal, this is a softfork proposal that redefines\nOP_NOP4 with an extensible and parameterized version of the signature\nchecking opcodes, called OP_CHECKSIGEX. Among other things the parameters\nallow to specify that an output with an OP_CHECKSIGEX is to be referenced\nby the normalized transaction ID that created it, instead of the instance\ntransaction ID containing malleable signatures. This BIP uses the\nnormalized transaction IDs exclusively while signing or checking\nsignatures, they are not used in any network level message as the previous\nversion would have done, hence there is no change at network level and old\nclients should be able to exchange transactions as before and blocks still\nreference the transaction instances.\n\nThe proposal is implemented (see below), by computing the normalized\ntransaction ID when adding them to the UTXO and storing them along with the\ncoin state. OP_CHECKSIGEX mostly duplicates OP_CHECKSIG and\nOP_CHECKMULTISIG, but I'm hoping somebody can give me some pointers into\nhow to best refactor the common functionality into reusable blocks. And the\nannotating incoming transactions with their normalized inputs is a bit\ncumbersome, maye somebody has some pointers here as well?\n\nBIP Pull request: https://github.com/bitcoin/bips/pull/224\nImplementation: https://github.com/cdecker/bitcoin/commits/normtx\n\nI think in the discussion of my previous proposal, most of you welcomed the\nintroduction of normalized transaction IDs, were it not for the hardfork. I\nhope this proposal adresses the previous concerns and that we can move\nforward in adding the normalized transaction IDs to the bitcoin protocol.\nThat being said, I'm always open to suggestions :-)\n\nRegards,\nChristian\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151019/2ed7395d/attachment-0001.html\u003e"}