📅 Original date posted:2017-04-06
📝 Original message:The 95% miner signaling is important to prevent two Bitcoin forks, such as
what happened with Ethereum HF and Ethereum Classic.
Bitcoin has a very slow difficulty re-targeting algorithm. A fork that has
just 95% miner support will initially (for 2016 blocks) be 5% slower (an
average block every 10 minutes and 30 seconds). The transaction capacity of
the new Bitcoin protocol is reduced only 5%.
However the chain with 5% if the hashing power not only has a 20x capacity
reduction, but confirms transactions in 20x more time. So the mempool will
grow 400 times. It must be noted that fees increased 10x from the moment
blocks were half full, to the moment blocks became saturated. I'm sure no
Bitcoin (pre-fork) user will be willing to pay 100x times the transaction
fees to use such a slow and insecure network.
So a 6-block confirmation will take 20 hours in the original chain and the
original chain will be in this almost useless slow state for an average of
2016 blocks, or 280 days.
If the original blockchain hard-forks to re-adjust the difficulty, then it
will just represent an alt-coin having 5% of Bitcoin community, and it
can't affect Bitcoin (the segwit2mb fork).
On Mon, Apr 3, 2017 at 11:40 AM, Btc Drak <btcdrak at gmail.com> wrote:
> On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> The hard-fork is conditional to 95% of the hashing power has approved the
>> segwit2mb soft-fork and the segwit soft-fork has been activated (which
>> should occur 2016 blocks after its lock-in time)
>>
>
> Miners signalling they have upgraded by flipping a bit in the nVersion
> field has little relevance in a hard fork. If 100% of the hash power
> indicates they are running this proposal, but the nodes don't upgrade, what
> will happen?
>
> For the record, I actually talk a lot about hard forks with various
> developers and am very interested in the research that Johnson in
> particular is pioneering. However, I have failed to understand your point
> about 95% miner signalling in relation to a hard fork, so I am eagerly
> awaiting your explanation.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170406/a91923df/attachment.html>;
Sergio Demian Lerner [ARCHIVE] /
npub1fv…3vq7f
2023-06-07 17:58:52
in reply to nevent1q…stxs
Author Public Key
npub1fvuxqdqg7klqqgy3yy8gdxjv4phu92sll5y8zqm2qe5qdrhxymhqf3vq7fPublished at
2023-06-07 17:58:52Event JSON
{
"id": "8e2fd3699080181658269c0430c523e35807c58765961d60e738065310c2ae0c",
"pubkey": "4b38603408f5be002091210e869a4ca86fc2aa1ffd0871036a0668068ee626ee",
"created_at": 1686160732,
"kind": 1,
"tags": [
[
"e",
"7011ea91d13433b27ca999be38e11becd970479a19a12ca22f4ebc2ec0d1700f",
"",
"root"
],
[
"e",
"4e53ef8b2db0f8bbcd19ff7528af31b909b03c375d1ddf1b5c53556beddfbde1",
"",
"reply"
],
[
"p",
"4b38603408f5be002091210e869a4ca86fc2aa1ffd0871036a0668068ee626ee"
]
],
"content": "📅 Original date posted:2017-04-06\n📝 Original message:The 95% miner signaling is important to prevent two Bitcoin forks, such as\nwhat happened with Ethereum HF and Ethereum Classic.\n\nBitcoin has a very slow difficulty re-targeting algorithm. A fork that has\njust 95% miner support will initially (for 2016 blocks) be 5% slower (an\naverage block every 10 minutes and 30 seconds). The transaction capacity of\nthe new Bitcoin protocol is reduced only 5%.\nHowever the chain with 5% if the hashing power not only has a 20x capacity\nreduction, but confirms transactions in 20x more time. So the mempool will\ngrow 400 times. It must be noted that fees increased 10x from the moment\nblocks were half full, to the moment blocks became saturated. I'm sure no\nBitcoin (pre-fork) user will be willing to pay 100x times the transaction\nfees to use such a slow and insecure network.\n\nSo a 6-block confirmation will take 20 hours in the original chain and the\noriginal chain will be in this almost useless slow state for an average of\n2016 blocks, or 280 days.\nIf the original blockchain hard-forks to re-adjust the difficulty, then it\nwill just represent an alt-coin having 5% of Bitcoin community, and it\ncan't affect Bitcoin (the segwit2mb fork).\n\n\nOn Mon, Apr 3, 2017 at 11:40 AM, Btc Drak \u003cbtcdrak at gmail.com\u003e wrote:\n\n\u003e On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e The hard-fork is conditional to 95% of the hashing power has approved the\n\u003e\u003e segwit2mb soft-fork and the segwit soft-fork has been activated (which\n\u003e\u003e should occur 2016 blocks after its lock-in time)\n\u003e\u003e\n\u003e\n\u003e Miners signalling they have upgraded by flipping a bit in the nVersion\n\u003e field has little relevance in a hard fork. If 100% of the hash power\n\u003e indicates they are running this proposal, but the nodes don't upgrade, what\n\u003e will happen?\n\u003e\n\u003e For the record, I actually talk a lot about hard forks with various\n\u003e developers and am very interested in the research that Johnson in\n\u003e particular is pioneering. However, I have failed to understand your point\n\u003e about 95% miner signalling in relation to a hard fork, so I am eagerly\n\u003e awaiting your explanation.\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170406/a91923df/attachment.html\u003e",
"sig": "83786bf50428d17973c8057718e237b3025bbd1dc1b101e71ddbeeb3788d4ccf955d5356db0a6c5aa70957883f7e8d0c86abce86378a00bb4b14947271264196"
}