📅 Original date posted:2015-12-30
📝 Original message:Emin,
I have two technical criticisms of your proposal, and one economic criticism.
>Unified miners would make sure that they mine transactions on Dum first, then on Dee. Recall that Dee miners can always just take Dum transactions and stick them in their blocks.
This seems to contradict a later section that says that users can use
Dee natively, without paying fees necessary to get a transaction into
Dum. You can't have this both ways - either you can get a transaction
into Dee without getting it into Dum first, or you can't.
>Such an attack would be quite visible, and it would leave Dum vulnerable. Unified clients could counter this launching a 51% counterattack on Dum.
What if some other group that wants to hurt both Dum and Dee were to
make a false-flag attack against Dee? Mutually assured destruction
doesn't work if you can't accurately attribute attacks.
>This would create some gentle pressure to explicitly unify the two chains (by merging Dee and Dum at some compromise and doing away with Unified)
I don't think a compromise would be reachable at that point - suppose
one had a market cap of 1.2 billion, and the other had a market cap of
0.8 billion. How would the coins on the unified chain be distributed?
You could give each chain an equal number of coins, but that's not
fair to the people holding the more valuable coins. You could give
each chain a number of coins proportional to the market cap, but that
invites price manipulation. In any case, if you had a way of reaching
compromise, why not use it instead of creating two chains?
Overall, I think this proposal is a bad idea.
>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.
That doesn't end up mattering, though, as I understand his proposal.
The unified client would just see that both validly spend an output
with a scriptPubKey of OP_HASH160 0xabcdef... OP_EQUAL.
On Wed, Dec 30, 2015 at 1:32 PM, Peter Todd via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> -----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-----
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Nick ODell [ARCHIVE] /
npub192…qwur0
2023-06-07 17:47:30
in reply to nevent1q…8alf
Author Public Key
npub192dh6dprqsvsrdeche436s9xunwnlyzpu7jl5j3d83nz62tgznrsnqwur0Published at
2023-06-07 17:47:30Event JSON
{
"id": "270090c6d7a06c5efeb5a755f8bd89ac2c7fe7b0366027f7f3a0e1487fb18c3d",
"pubkey": "2a9b7d3423041901b738be6b1d40a6e4dd3f9041e7a5fa4a2d3c662d296814c7",
"created_at": 1686160050,
"kind": 1,
"tags": [
[
"e",
"952f2c3963bbc4e3bc8c1ee62942da7fea09db4c863ca025d9e089b9448e51cb",
"",
"root"
],
[
"e",
"ae9f8c84a522c59708adae6945b3228f81c0cbd6ebd80f66a143e01537900e81",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2015-12-30\n📝 Original message:Emin,\n\nI have two technical criticisms of your proposal, and one economic criticism.\n\n\u003eUnified miners would make sure that they mine transactions on Dum first, then on Dee. Recall that Dee miners can always just take Dum transactions and stick them in their blocks.\nThis seems to contradict a later section that says that users can use\nDee natively, without paying fees necessary to get a transaction into\nDum. You can't have this both ways - either you can get a transaction\ninto Dee without getting it into Dum first, or you can't.\n\n\u003eSuch an attack would be quite visible, and it would leave Dum vulnerable. Unified clients could counter this launching a 51% counterattack on Dum.\nWhat if some other group that wants to hurt both Dum and Dee were to\nmake a false-flag attack against Dee? Mutually assured destruction\ndoesn't work if you can't accurately attribute attacks.\n\n\u003eThis would create some gentle pressure to explicitly unify the two chains (by merging Dee and Dum at some compromise and doing away with Unified)\nI don't think a compromise would be reachable at that point - suppose\none had a market cap of 1.2 billion, and the other had a market cap of\n0.8 billion. How would the coins on the unified chain be distributed?\nYou could give each chain an equal number of coins, but that's not\nfair to the people holding the more valuable coins. You could give\neach chain a number of coins proportional to the market cap, but that\ninvites price manipulation. In any case, if you had a way of reaching\ncompromise, why not use it instead of creating two chains?\n\n\nOverall, I think this proposal is a bad idea.\n\n\n\u003eYou 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.\nThat doesn't end up mattering, though, as I understand his proposal.\nThe unified client would just see that both validly spend an output\nwith a scriptPubKey of OP_HASH160 0xabcdef... OP_EQUAL.\n\nOn Wed, Dec 30, 2015 at 1:32 PM, Peter Todd via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e -----BEGIN PGP SIGNED MESSAGE-----\n\u003e Hash: SHA512\n\u003e\n\u003e\n\u003e\n\u003e On 30 December 2015 12:22:43 GMT-08:00, \"Emin Gün Sirer\" \u003cel33th4x0r at gmail.com\u003e wrote:\n\u003e\u003eOn Wed, Dec 30, 2015 at 3:16 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e Note how transaction malleability can quickly sabotage naive notions\n\u003e\u003eof\n\u003e\u003e\u003e this idea.\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003eBitcoin-United relies on a notion of transaction equivalence that\n\u003e\u003edoesn't\n\u003e\u003einvolve the transaction hash at all, so it should be immune to\n\u003e\u003emalleability\n\u003e\u003eissues and compatible with segwit.\n\u003e\u003e\n\u003e \u003eFrom the post, two transactions are equal if they \"consume the same\n\u003e\u003einputs\n\u003e\u003eand result in the same outputs, not counting the miner fee. Simple\n\u003e\u003epay-to-pubkey-hash and pay-to-script-hash transactions are\n\u003e\u003estraightforward.\n\u003e\u003eMultikey transactions are evaluated for equivalency by their inputs and\n\u003e\u003eoutputs, so it is allowable for a 2-out-of-3 payment to be signed by\n\u003e\u003eone\n\u003e\u003eset of two keys on Dum and another set of two keys on Dee, as long as\n\u003e\u003ethe\n\u003e\u003etransaction consumes the same coins and produces the same outputs. Not\n\u003e\u003ethat\n\u003e\u003ewe'll ever encounter such a case, but making this point helps\n\u003e\u003epedagogically\n\u003e\u003ewith getting across the notion of transaction equivalence. What counts\n\u003e\u003eare\n\u003e\u003ethe consumed inputs and the destination and amounts of the outputs.\"\n\u003e\n\u003e 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.\n\u003e\n\u003e 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.\n\u003e\n\u003e 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)\n\u003e\n\u003e -----BEGIN PGP SIGNATURE-----\n\u003e\n\u003e iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJWhD9N\n\u003e AAoJEMCF8hzn9Lncz4MH/0JPGVc2JLtD5q0I2w0vqmBqsoSzSueCtnKa2K1Ea10g\n\u003e w9I4uhK7+cgfCLbofJznVHMChXu0uCxtWwqSj++uJx238TEupcu951gUhFfuPOeH\n\u003e Egye8jmDkDFiB1P40kUSVk9N64Zt3kWLk4xSsfjawVHz/WWpM24Fn8k/bmI7JiLl\n\u003e nmVwoBdRsTKffM/1dr8ix4U8YPSmJ7W+jAByNHUpSgc1R73YylqNT95pF8QD35df\n\u003e dQwSK9DIc+2N4CKnp22xLvYeCivFjeS2Fm4kbcKQwMjcqlJ1mWghP/c8q/lzhaGN\n\u003e Ac15/pgeHp8dPP8c81zkN9ps14rrnXoHnrzjiY+TwKY=\n\u003e =FfK1\n\u003e -----END PGP SIGNATURE-----\n\u003e\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",
"sig": "79e8856a88488a9c16307e96f6332731cc1bffe697f0dd8a50ad82894f7384963b529a179b562d573da18da6eaf1825cbe7ea879f7a8ddf4505555cbe4e6bd2c"
}