📅 Original date posted:2015-10-21
📝 Original message:A signer modifying the order of inputs or changing outputs when
"re-signing" a transaction (which already has dependent child transactions
spending its outputs) seems like quite a different hazard than a malicious
third party modifying a transaction in the mempool by twiddling opcodes in
the signature scripts. The former seems like more a matter of keeping your
own house in order (an internal affair) while the latter is an external
threat beyond the transaction writer's control.
While I agree that having a canonical ordering for inputs and outputs might
be useful in some cases, there are also use cases where the relative
positions of inputs and outputs are significant, where reordering would
change the semantics of the transaction. SIGHASH_SINGLE, for example,
makes an association between an input index and an output index. Open Asset
colored coins are identified by the order of inputs and outputs.
Let's keep canonical ordering separate from the normalized transaction ID
proposal. Baby steps. Normalized transaction IDs provide an immediate
benefit against the hazard of third party manipulation of transactions in
the mempool, even without canonical ordering.
-Danny
On Wed, Oct 21, 2015 at 1:46 AM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wednesday, October 21, 2015 8:44:53 AM Christian Decker wrote:
> > Hm, that is true as long as the signer is the only signer of the
> > transaction, otherwise he'd be invalidating the signatures of the other
> > signers.
>
> Or he can just have the other signers re-sign with the modified version.
> Even if it only worked with a single signer, it's still a form of
> malleability
> that your BIP does not presently solve, but would be desirable to solve...
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151021/3ab09100/attachment.html>;
Danny Thorpe [ARCHIVE] /
npub1q5…3ps87
2023-06-07 17:43:44
in reply to nevent1q…rshr
Author Public Key
npub1q5sgcakfxhw3ya93tvnpqeacvf32p6lw70hke53rkjnf9lhw9w8s43ps87Seen on
wss://relay.nostr.bandPublished at
2023-06-07 17:43:44Event JSON
{
"id": "41332d9d5f9ca0b8516c9eb0f1d873eed20b195f8e3199572ea7f3961160bdc5",
"pubkey": "05208c76c935dd1274b15b261067b86262a0ebeef3ef6cd223b4a692feee2b8f",
"created_at": 1686159824,
"kind": 1,
"tags": [
[
"e",
"e71cb83b97f22f5353a76bf12fac79eec2c215f6e13d11b1eb608f076bcfae47",
"",
"root"
],
[
"e",
"79037e6438c1b1473f135a24275533b55c32bf67af6e43e4d6866691afc130e0",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2015-10-21\n📝 Original message:A signer modifying the order of inputs or changing outputs when\n\"re-signing\" a transaction (which already has dependent child transactions\nspending its outputs) seems like quite a different hazard than a malicious\nthird party modifying a transaction in the mempool by twiddling opcodes in\nthe signature scripts. The former seems like more a matter of keeping your\nown house in order (an internal affair) while the latter is an external\nthreat beyond the transaction writer's control.\n\nWhile I agree that having a canonical ordering for inputs and outputs might\nbe useful in some cases, there are also use cases where the relative\npositions of inputs and outputs are significant, where reordering would\nchange the semantics of the transaction. SIGHASH_SINGLE, for example,\nmakes an association between an input index and an output index. Open Asset\ncolored coins are identified by the order of inputs and outputs.\n\nLet's keep canonical ordering separate from the normalized transaction ID\nproposal. Baby steps. Normalized transaction IDs provide an immediate\nbenefit against the hazard of third party manipulation of transactions in\nthe mempool, even without canonical ordering.\n\n-Danny\n\n\n\n\n\nOn Wed, Oct 21, 2015 at 1:46 AM, Luke Dashjr via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Wednesday, October 21, 2015 8:44:53 AM Christian Decker wrote:\n\u003e \u003e Hm, that is true as long as the signer is the only signer of the\n\u003e \u003e transaction, otherwise he'd be invalidating the signatures of the other\n\u003e \u003e signers.\n\u003e\n\u003e Or he can just have the other signers re-sign with the modified version.\n\u003e Even if it only worked with a single signer, it's still a form of\n\u003e malleability\n\u003e that your BIP does not presently solve, but would be desirable to solve...\n\u003e\n\u003e Luke\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151021/3ab09100/attachment.html\u003e",
"sig": "789eac89757a33eeaac2aeca07ce4aef262acb28a42ced329dd5c075cb0d20d4f55bbcfc0151c80e5931cd36d52ff60a949239d664a5cb6deeb54eadfbb5915c"
}