📅 Original date posted:2015-09-28
📝 Original message:>
> Can you explain exactly how you think wallets will "know" how to ignore
> the invalid chain?
>
I'm confused - I already said this. For a fork to work, hard or soft, there
must be support from a majority of the hash power.
Therefore, the usual SPV technique of following the highest work chain
results in ignoring the minority chain produced by the hard fork.
BIP 101 is SPV friendly because the wallets would simply follow the 75%
chain and never even be aware anything has changed. It's backwards
compatible with them in this respect: they already know how to ignore the
no-bigger-blocks fork that'd be created if some miners didn't upgrade
during the grace period.
My point about IsStandard is that miners can and do bypass it, without
expecting that to carry financial consequences or lower the security of
other users. By making it so a block which includes non-standard
transactions can end up being seen as invalid, you are increasing the risk
of accidents that carry financial consequences.
That's incorrect: Miners bypassing IsStandard() risk creating invalid
> blocks in the event of a soft-fork. Equally, we design soft-forks to
> take advantage of this.
>
Gah. You repeated what I just said. Yes, I know miners face that risk, my
point is that they do NOT face such a risk when there's no soft fork in
action and have historically NOT faced that risk at all, hence the
widespread practice of bypassing or modifying this function.
All this approach does is make changing IsStandard() the same as changing
AcceptBlock(), except without the advantage of telling anyone about it.
> > So I'll repeat the question that I posed before - given that there are
> > clear, explicit downsides, what is the purpose of doing things this way?
> > Where is the gain for ordinary Bitcoin users?
>
> We seem to be in strong disagreement about which option has "clear,
> explicit downsides"
Obviously. So please enlighten me.
How do ordinary Bitcoin users benefit from this rollout strategy? Put
simply, what is the point of this whole complex soft fork endeavour?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/37024596/attachment.html>;
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 17:41:35
in reply to nevent1q…spdn
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydPublished at
2023-06-07 17:41:35Event JSON
{
"id": "6f1ffc93e5e37e2a41520b85293bd9a9ff30bf900a7c7dc910036533ca0e15bc",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686159695,
"kind": 1,
"tags": [
[
"e",
"f5bb1bf208994917ac3ec4154383520df2a8573df815c54d28bae4e41ef024c8",
"",
"root"
],
[
"e",
"01c311c3fb14e7c20edb75f4fe97c1448171397bb006568a421c18047ed3fb8e",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2015-09-28\n📝 Original message:\u003e\n\u003e Can you explain exactly how you think wallets will \"know\" how to ignore\n\u003e the invalid chain?\n\u003e\n\nI'm confused - I already said this. For a fork to work, hard or soft, there\nmust be support from a majority of the hash power.\n\nTherefore, the usual SPV technique of following the highest work chain\nresults in ignoring the minority chain produced by the hard fork.\n\nBIP 101 is SPV friendly because the wallets would simply follow the 75%\nchain and never even be aware anything has changed. It's backwards\ncompatible with them in this respect: they already know how to ignore the\nno-bigger-blocks fork that'd be created if some miners didn't upgrade\nduring the grace period.\n\nMy point about IsStandard is that miners can and do bypass it, without\nexpecting that to carry financial consequences or lower the security of\nother users. By making it so a block which includes non-standard\ntransactions can end up being seen as invalid, you are increasing the risk\nof accidents that carry financial consequences.\n\nThat's incorrect: Miners bypassing IsStandard() risk creating invalid\n\u003e blocks in the event of a soft-fork. Equally, we design soft-forks to\n\u003e take advantage of this.\n\u003e\n\nGah. You repeated what I just said. Yes, I know miners face that risk, my\npoint is that they do NOT face such a risk when there's no soft fork in\naction and have historically NOT faced that risk at all, hence the\nwidespread practice of bypassing or modifying this function.\n\nAll this approach does is make changing IsStandard() the same as changing\nAcceptBlock(), except without the advantage of telling anyone about it.\n\n\n\u003e \u003e So I'll repeat the question that I posed before - given that there are\n\u003e \u003e clear, explicit downsides, what is the purpose of doing things this way?\n\u003e \u003e Where is the gain for ordinary Bitcoin users?\n\u003e\n\u003e We seem to be in strong disagreement about which option has \"clear,\n\u003e explicit downsides\"\n\n\nObviously. So please enlighten me.\n\nHow do ordinary Bitcoin users benefit from this rollout strategy? Put\nsimply, what is the point of this whole complex soft fork endeavour?\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/37024596/attachment.html\u003e",
"sig": "ae49e7105d48d78154034ea2e43fefb54df081c6f34a3d1120ee87dcb23f91372994a2ed8e024d746f067a212be0a7fa09b6cc7a3c9d54265b1346f2cc292038"
}