📅 Original date posted:2015-09-16
📝 Original message:On Wed, Sep 16, 2015 at 9:19 PM, Rusty Russell <rusty at rustcorp.com.au>
wrote:
> I couldn't see a use for it, since partial enforcement of a soft fork is
> pretty useless.
>
It isn't useful for actually using the feature, but some miners might set
the bit but not actually create blocks that comply with the new rule.
This would cause their blocks to be orphaned until they fixed it.
OK, *that* variant makes perfect sense, and is no more complex, AFAICT.
>
> So, there's two weeks to detect bad implementations, then you everyone
> stops setting the bit, for later reuse by another BIP.
>
It could be more than two weeks if the support stays between 80% and 90%
for a while.
75%+ checks that blocks with the bit set follow the rule.
95%+ enters lock-in and has the same rules as 75%+, but is irreversible at
that point.
> You need a timeout: an ancient (non-mining, thus undetectable) node
> should never fork itself off the network because someone reused a failed
> BIP bit.
>
I meant if the 2nd bit was part of the BIP. One of the 2 bits is "FOR" and
the other is "AGAINST". If against hits 25%, then it is deemed a failure.
The 2nd bit wouldn't be used normally. This means that proposals can be
killed quickly if they are obviously going to fail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150916/c60f2225/attachment.html>;
Tier Nolan [ARCHIVE] /
npub1g6…sl5wd
2023-06-07 17:40:09
in reply to nevent1q…tzrz
Author Public Key
npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wdPublished at
2023-06-07 17:40:09Event JSON
{
"id": "6e361b8de8a7a6950a33018db2f56dd2240d1d47cf8441d52320e1dae4e8bafc",
"pubkey": "46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e",
"created_at": 1686159609,
"kind": 1,
"tags": [
[
"e",
"97970fd647e1ad99b763fefc14ff6c3da92992c59a8d85f2e5fe9ba87f5c9fb9",
"",
"root"
],
[
"e",
"d2dcd6e3bff592b5f6b3eb21bfd0d24e4eec62b134a33605e56e55e257b7c7e0",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2015-09-16\n📝 Original message:On Wed, Sep 16, 2015 at 9:19 PM, Rusty Russell \u003crusty at rustcorp.com.au\u003e\nwrote:\n\n\u003e I couldn't see a use for it, since partial enforcement of a soft fork is\n\u003e pretty useless.\n\u003e\n\nIt isn't useful for actually using the feature, but some miners might set\nthe bit but not actually create blocks that comply with the new rule.\n\nThis would cause their blocks to be orphaned until they fixed it.\n\nOK, *that* variant makes perfect sense, and is no more complex, AFAICT.\n\u003e\n\u003e So, there's two weeks to detect bad implementations, then you everyone\n\u003e stops setting the bit, for later reuse by another BIP.\n\u003e\n\nIt could be more than two weeks if the support stays between 80% and 90%\nfor a while.\n\n75%+ checks that blocks with the bit set follow the rule.\n\n95%+ enters lock-in and has the same rules as 75%+, but is irreversible at\nthat point.\n\n\n\u003e You need a timeout: an ancient (non-mining, thus undetectable) node\n\u003e should never fork itself off the network because someone reused a failed\n\u003e BIP bit.\n\u003e\n\nI meant if the 2nd bit was part of the BIP. One of the 2 bits is \"FOR\" and\nthe other is \"AGAINST\". If against hits 25%, then it is deemed a failure.\n\nThe 2nd bit wouldn't be used normally. This means that proposals can be\nkilled quickly if they are obviously going to fail.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150916/c60f2225/attachment.html\u003e",
"sig": "ae16e2339bf5b54030e32ebc12401569948b614f10a0f7160d7cecee262c56b7bb168b484aa9467f1b17597bff7211f2476bf216f95c88f48a67642bbc8ebe42"
}