📅 Original date posted:2016-08-16
📝 Original message:Okay.
I'm not really opposed to this BIP, but I am worried that fighting script
malleability is a battle that can never be won; even leaving one avenue of
malleability open is probably just as bad as having many avenues of
malleability, so it just doesn't seem worthwhile to me.
On Tue, Aug 16, 2016 at 8:18 PM, Gregory Maxwell <greg at xiph.org> wrote:
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160816/891f91a7/attachment.html>;
Russell O'Connor [ARCHIVE] /
npub1dw…8plrw
2023-06-07 17:52:57
in reply to nevent1q…yrdv
Author Public Key
npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrwPublished at
2023-06-07 17:52:57Event JSON
{
"id": "9cef1b3356af35e28c18dbe7a0963702765ff917dd36cfb4d19c82986c2e48a3",
"pubkey": "6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d",
"created_at": 1686160377,
"kind": 1,
"tags": [
[
"e",
"9284d48ee3ec0986e743af41281b218e681b340835d80de299ea9e9d68940884",
"",
"root"
],
[
"e",
"8332c7172d37bf07ca5be41722529a6988d1c17b57d0b41e34953474e9d17107",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2016-08-16\n📝 Original message:Okay.\n\nI'm not really opposed to this BIP, but I am worried that fighting script\nmalleability is a battle that can never be won; even leaving one avenue of\nmalleability open is probably just as bad as having many avenues of\nmalleability, so it just doesn't seem worthwhile to me.\n\nOn Tue, Aug 16, 2016 at 8:18 PM, Gregory Maxwell \u003cgreg at xiph.org\u003e wrote:\n\n\u003e On Tue, Aug 16, 2016 at 10:52 PM, Russell O'Connor via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e I see.\n\u003e \u003e\n\u003e \u003e But is it really necessary to soft fork over this issue? Why not just\n\u003e make\n\u003e \u003e it a relay rule? Miners are already incentivized to modify transactions\n\u003e to\n\u003e \u003e drop excess witness data and/or prioritize (versions of) transactions\n\u003e based\n\u003e \u003e on their cost. If a miner wants to mine a block with excess witness\n\u003e data,\n\u003e \u003e it is mostly their own loss.\n\u003e\n\u003e Relay rules are quite fragile-- people build programs or protocols not\n\u003e expecting them to be violated, without proper error handling in those\n\u003e cases... and then eventually some miner rips them out because they\n\u003e simply don't care about them: not enforcing them won't make their\n\u003e blocks invalid.\n\u003e\n\u003e It's my general view that we should avoid blocking things with relay\n\u003e rules unless we think that someday they could be made invalid... not\n\u003e necessarily that they will, but that it's plausible. Then the\n\u003e elimination at the relay level is just the first exploratory step in\n\u003e that direction.\n\u003e\n\u003e One should also consider adversarial behavior by miners. For example,\n\u003e I can mine blocks with mutated witnesses with a keyed mac that chooses\n\u003e the mutation. The key is shared by conspirators or customers, and now\n\u003e collectively we have a propagation advantage (since we know the\n\u003e mutated version before it shows up). Not the _biggest_ concern, since\n\u003e parties doing this could just create their own new transactions to\n\u003e selectively propagate; but doing that would require leaving behind fee\n\u003e paying public transactions, while using malleability wouldn't.\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160816/891f91a7/attachment.html\u003e",
"sig": "db97ebb858007db68b394152721b9451f8539d86116a6b40e4dc001719e401ecb68ecb4b0cc9ccadaec00b440af7bbe31483d40bc0a1dc1e427d29ba61429027"
}