📅 Original date posted:2015-12-30
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 30 December 2015 12:22:43 GMT-08:00, "Emin Gün Sirer" <el33th4x0r at gmail.com> wrote:
>On Wed, Dec 30, 2015 at 3:16 PM, Peter Todd <pete at petertodd.org> wrote:
>
>> Note how transaction malleability can quickly sabotage naive notions
>of
>> this idea.
>>
>
>Bitcoin-United relies on a notion of transaction equivalence that
>doesn't
>involve the transaction hash at all, so it should be immune to
>malleability
>issues and compatible with segwit.
>
>From the post, two transactions are equal if they "consume the same
>inputs
>and result in the same outputs, not counting the miner fee. Simple
>pay-to-pubkey-hash and pay-to-script-hash transactions are
>straightforward.
>Multikey transactions are evaluated for equivalency by their inputs and
>outputs, so it is allowable for a 2-out-of-3 payment to be signed by
>one
>set of two keys on Dum and another set of two keys on Dee, as long as
>the
>transaction consumes the same coins and produces the same outputs. Not
>that
>we'll ever encounter such a case, but making this point helps
>pedagogically
>with getting across the notion of transaction equivalence. What counts
>are
>the consumed inputs and the destination and amounts of the outputs."
You seem to not be familiar with how multisig transactions on Bitcoin work - 99.9% of the time theyre hidden behind p2sh and there is no way to know what keys are involved. Equally, multisig is just one of many complex scripts possible.
Look into what a segwit transaction hashes - that's a better notion of non-malleable transaction. But even then lots of transactions are malleable, and its easy to trigger those cases intentionally by third parties.
Most likely any Bitcoin United scheme would quickly diverge and fail; much simpler and more predictable to achieve convincing consensus, e.g. via proof of stake voting, or Adam Bank's extension blocks suggestions. (or of course, not trying to force controversial forks in the first place)
-----BEGIN PGP SIGNATURE-----
iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJWhD9N
AAoJEMCF8hzn9Lncz4MH/0JPGVc2JLtD5q0I2w0vqmBqsoSzSueCtnKa2K1Ea10g
w9I4uhK7+cgfCLbofJznVHMChXu0uCxtWwqSj++uJx238TEupcu951gUhFfuPOeH
Egye8jmDkDFiB1P40kUSVk9N64Zt3kWLk4xSsfjawVHz/WWpM24Fn8k/bmI7JiLl
nmVwoBdRsTKffM/1dr8ix4U8YPSmJ7W+jAByNHUpSgc1R73YylqNT95pF8QD35df
dQwSK9DIc+2N4CKnp22xLvYeCivFjeS2Fm4kbcKQwMjcqlJ1mWghP/c8q/lzhaGN
Ac15/pgeHp8dPP8c81zkN9ps14rrnXoHnrzjiY+TwKY=
=FfK1
-----END PGP SIGNATURE-----
Peter Todd [ARCHIVE] /
npub1m2…a2np2
2023-06-07 17:47:29
in reply to nevent1q…nxtv
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 17:47:29Event JSON
{
"id": "ae9f8c84a522c59708adae6945b3228f81c0cbd6ebd80f66a143e01537900e81",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686160049,
"kind": 1,
"tags": [
[
"e",
"952f2c3963bbc4e3bc8c1ee62942da7fea09db4c863ca025d9e089b9448e51cb",
"",
"root"
],
[
"e",
"bc394190ef1c05b71df64054db1389afcdd1ac93a7336c0fec1dbae2270cf8a3",
"",
"reply"
],
[
"p",
"b68afd106d166cdb4d51d8e16c275c09e0a49020fb6f311509c56b6743b37a84"
]
],
"content": "📅 Original date posted:2015-12-30\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA512\n\n\n\nOn 30 December 2015 12:22:43 GMT-08:00, \"Emin Gün Sirer\" \u003cel33th4x0r at gmail.com\u003e wrote:\n\u003eOn Wed, Dec 30, 2015 at 3:16 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e\n\u003e\u003e Note how transaction malleability can quickly sabotage naive notions\n\u003eof\n\u003e\u003e this idea.\n\u003e\u003e\n\u003e\n\u003eBitcoin-United relies on a notion of transaction equivalence that\n\u003edoesn't\n\u003einvolve the transaction hash at all, so it should be immune to\n\u003emalleability\n\u003eissues and compatible with segwit.\n\u003e\n\u003eFrom the post, two transactions are equal if they \"consume the same\n\u003einputs\n\u003eand result in the same outputs, not counting the miner fee. Simple\n\u003epay-to-pubkey-hash and pay-to-script-hash transactions are\n\u003estraightforward.\n\u003eMultikey transactions are evaluated for equivalency by their inputs and\n\u003eoutputs, so it is allowable for a 2-out-of-3 payment to be signed by\n\u003eone\n\u003eset of two keys on Dum and another set of two keys on Dee, as long as\n\u003ethe\n\u003etransaction consumes the same coins and produces the same outputs. Not\n\u003ethat\n\u003ewe'll ever encounter such a case, but making this point helps\n\u003epedagogically\n\u003ewith getting across the notion of transaction equivalence. What counts\n\u003eare\n\u003ethe consumed inputs and the destination and amounts of the outputs.\"\n\nYou seem to not be familiar with how multisig transactions on Bitcoin work - 99.9% of the time theyre hidden behind p2sh and there is no way to know what keys are involved. Equally, multisig is just one of many complex scripts possible.\n\nLook into what a segwit transaction hashes - that's a better notion of non-malleable transaction. But even then lots of transactions are malleable, and its easy to trigger those cases intentionally by third parties.\n\nMost likely any Bitcoin United scheme would quickly diverge and fail; much simpler and more predictable to achieve convincing consensus, e.g. via proof of stake voting, or Adam Bank's extension blocks suggestions. (or of course, not trying to force controversial forks in the first place)\n\n-----BEGIN PGP SIGNATURE-----\n\niQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJWhD9N\nAAoJEMCF8hzn9Lncz4MH/0JPGVc2JLtD5q0I2w0vqmBqsoSzSueCtnKa2K1Ea10g\nw9I4uhK7+cgfCLbofJznVHMChXu0uCxtWwqSj++uJx238TEupcu951gUhFfuPOeH\nEgye8jmDkDFiB1P40kUSVk9N64Zt3kWLk4xSsfjawVHz/WWpM24Fn8k/bmI7JiLl\nnmVwoBdRsTKffM/1dr8ix4U8YPSmJ7W+jAByNHUpSgc1R73YylqNT95pF8QD35df\ndQwSK9DIc+2N4CKnp22xLvYeCivFjeS2Fm4kbcKQwMjcqlJ1mWghP/c8q/lzhaGN\nAc15/pgeHp8dPP8c81zkN9ps14rrnXoHnrzjiY+TwKY=\n=FfK1\n-----END PGP SIGNATURE-----",
"sig": "8823fd51958afa4233b80fd999cb6a39ce81af949a07632d27a123f3902ddd20d732b9047da0b9473197407dd8012d3c24f0a2704ded930ed5f0fd34593ca5dc"
}