📅 Original date posted:2016-08-16
📝 Original message:On Tue, Aug 16, 2016 at 10:52 PM, Russell O'Connor via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I see.
>
> But is it really necessary to soft fork over this issue? Why not just make
> it a relay rule? Miners are already incentivized to modify transactions to
> drop excess witness data and/or prioritize (versions of) transactions based
> on their cost. If a miner wants to mine a block with excess witness data,
> it is mostly their own loss.
Relay rules are quite fragile-- people build programs or protocols not
expecting them to be violated, without proper error handling in those
cases... and then eventually some miner rips them out because they
simply don't care about them: not enforcing them won't make their
blocks invalid.
It's my general view that we should avoid blocking things with relay
rules unless we think that someday they could be made invalid... not
necessarily that they will, but that it's plausible. Then the
elimination at the relay level is just the first exploratory step in
that direction.
One should also consider adversarial behavior by miners. For example,
I can mine blocks with mutated witnesses with a keyed mac that chooses
the mutation. The key is shared by conspirators or customers, and now
collectively we have a propagation advantage (since we know the
mutated version before it shows up). Not the _biggest_ concern, since
parties doing this could just create their own new transactions to
selectively propagate; but doing that would require leaving behind fee
paying public transactions, while using malleability wouldn't.
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 17:52:57
in reply to nevent1q…jrmg
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetPublished at
2023-06-07 17:52:57Event JSON
{
"id": "8332c7172d37bf07ca5be41722529a6988d1c17b57d0b41e34953474e9d17107",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686160377,
"kind": 1,
"tags": [
[
"e",
"9284d48ee3ec0986e743af41281b218e681b340835d80de299ea9e9d68940884",
"",
"root"
],
[
"e",
"b08254d600d4ef17a859534e0cf7cd76f5dc2173ec47cea9666e6ddbe0870491",
"",
"reply"
],
[
"p",
"6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d"
]
],
"content": "📅 Original date posted:2016-08-16\n📝 Original message:On Tue, Aug 16, 2016 at 10:52 PM, Russell O'Connor via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e I see.\n\u003e\n\u003e But is it really necessary to soft fork over this issue? Why not just make\n\u003e it a relay rule? Miners are already incentivized to modify transactions to\n\u003e drop excess witness data and/or prioritize (versions of) transactions based\n\u003e on their cost. If a miner wants to mine a block with excess witness data,\n\u003e it is mostly their own loss.\n\nRelay rules are quite fragile-- people build programs or protocols not\nexpecting them to be violated, without proper error handling in those\ncases... and then eventually some miner rips them out because they\nsimply don't care about them: not enforcing them won't make their\nblocks invalid.\n\nIt's my general view that we should avoid blocking things with relay\nrules unless we think that someday they could be made invalid... not\nnecessarily that they will, but that it's plausible. Then the\nelimination at the relay level is just the first exploratory step in\nthat direction.\n\nOne should also consider adversarial behavior by miners. For example,\nI can mine blocks with mutated witnesses with a keyed mac that chooses\nthe mutation. The key is shared by conspirators or customers, and now\ncollectively we have a propagation advantage (since we know the\nmutated version before it shows up). Not the _biggest_ concern, since\nparties doing this could just create their own new transactions to\nselectively propagate; but doing that would require leaving behind fee\npaying public transactions, while using malleability wouldn't.",
"sig": "5a62dc26803cfd5f30c24c8ae7764f52fec8e45abcf4d23dbe4a3c0c422a5c51aa69e3fbd43270998dc017851f2d22b1b3963c58e361a2d857bf9b06128a2b5d"
}