📅 Original date posted:2016-02-07
📝 Original message:I agree that it seems like a safe assumption that adoption would be faster,
whether it is "very safe" and "significantly faster", whether it will be 6
times faster, all of those assumptions seems significantly less safe and
robust to me.
The nature of the bitcoin protocol, that it is a decentralized census based
protocol involving currency, suggests to me that roll out schedules ought
to be conservative with a minimum of assumptions. In light of the most
recent protocol upgrade, 6 months for this hard fork seems to me to be the
most conservative time frame with the fewest assumptions.
As for why it needs to be so fast, ie what are the dangers of it being as
slow as 6 months?
Gavin writes:
"I strongly disagree with the statement that there is no cost to a longer
grace period. There is broad agreement that a capacity increase is needed
NOW."
~~
"Broad agreement", that really seems to be another assumption, the fact
that the debate has been as long and acrimonious as it has been suggests
that there isn't broad agreement. Also, resorting to "SHOUTING" doesn't win
any favors when it comes to engaging in reasonable discussion om the
technical merits of a proposal.
On Sun, Feb 7, 2016 at 5:04 PM, Corey Haddad <corey3 at gmail.com> wrote:
> We don't have any evidence of how fast nodes will upgrade when faced with
> an impending hard fork, but it seems like a very safe assumption that the
> upgrade pace will be significantly faster. The hard fork case it is:
> "upgrade or be kicked off the network". In the previous cases it has been,
> "here's the latest and greatest, give it a go!". Also, there will be
> alerts sent out warning people of the situation, prompting them to take
> action.
>
> It is unclear if this will translate into more or less than 6x the
> adoption speed of previous instances, but the idea that it would be faster
> is solid. 28 days is aggressive, but again, it is only 28 days from when
> the fork triggers. Compatible software is already available for anyone who
> wants to prepare.
>
> It is also of significance that this proposed fork, and this debate, has
> been going on for many, many months. If someone proposed a forking concept
> today, wrote the BIP tomorrow, deployed it next week, miners adopted it
> instantly, and 28 days later it was the flag day, those 28 days would be in
> a different context. There is no surprise here.
>
> On Sun, Feb 7, 2016 at 1:33 PM, Steven Pine via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Is it me or did Gavin ignore Yifu's direct questions? In case you missed
>> it Gavin --
>>
>> ~
>> "We can look at the adoption of the last major Bitcoin core release to
>> guess how long it might take people to upgrade. 0.11.0 was released on 12
>> July, 2015. Twenty eight days later, about 38% of full nodes were
>> running that release. Three months later, about 50% of the network was
>> running that release, and six months later about 66% of the network was
>> running some flavor of 0.11."
>>
>> On what grounds do you think it is reasonable to assume that this update
>> will roll out 6x faster than previous data suggested, as oppose to your own
>> observation of 66% adoption in 6 month. or do you believe 38% node
>> upgrade-coverage (in 28 days ) on the network for a hard fork is good
>> enough?
>>
>> There are no harm in choosing a longer grace period but picking one short
>> as 28 days you risk on alienating the nodes who do not upgrade with the
>> aggressive upgrade timeline you proposed.
>> ~~
>>
>> When Gavin writes "Responding to "28 days is not long enough" :
>>
>> I keep seeing this claim made with no evidence to back it up. As I said,
>> I surveyed several of the biggest infrastructure providers and the btcd
>> lead developer and they all agree "28 days is plenty of time."
>>
>> For individuals... why would it take somebody longer than 28 days to
>> either download and restart their bitcoind, or to patch and then re-run
>> (the patch can be a one-line change MAX_BLOCK_SIZE from 1000000 to
>> 2000000)?"
>>
>> ~~
>>
>> Isn't Yifu's comment, evidence, the very best sort of evidence, it isn't
>> propositional a priori logic, but empirical evidence that. As for why
>> people take longer, who knows, we simply know from passed experience that
>> it in fact does take longer.
>>
>> It's extremely frustrating to read Gavin's comments, it's hard to believe
>> he is engaging in earnest discussion.
>>
>> On Sun, Feb 7, 2016 at 4:01 PM, Luke Dashjr via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> On Sunday, February 07, 2016 2:16:02 PM Gavin Andresen wrote:
>>> > On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
>>> > bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> > > On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev
>>> wrote:
>>> > > > If you have a node that is "old" your node will stop getting new
>>> > > > blocks. The node will essentially just say "x-hours behind" with
>>> "x"
>>> > > > getting larger every hour. Funds don't get confirmed. etc.
>>> > >
>>> > > Until someone decides to attack you. Then you'll get 6, 10, maybe
>>> more
>>> > > blocks confirming a large 10000 BTC payment. If you're just a normal
>>> end
>>> > > user (or perhaps an automated system), you'll figure that payment is
>>> good
>>> > > and irreversibly hand over the title to the house.
>>> >
>>> > There will be approximately zero percentage of hash power left on the
>>> > weaker branch of the fork, based on past soft-fork adoption by miners
>>> (they
>>> > upgrade VERY quickly from 75% to over 95%).
>>>
>>> I'm assuming there are literally ZERO miners left on the weaker branch.
>>> The attacker in this scenario simply rents hashing for a few days in
>>> advance
>>> to build his fake chain, then broadcasts the blocks to the unsuspecting
>>> merchant at ~10 block intervals so it looks like everything is working
>>> normal
>>> again. There are lots of mining rental services out there, and miners
>>> quite
>>> often do not care to avoid selling hashrate to the highest bidder
>>> regardless
>>> of what they're mining. 10 blocks worth costs a little more than 250 BTC
>>> -
>>> soon, that will be 125 BTC.
>>>
>>> Luke
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>>
>> --
>> Steven Pine
>> (510) 517-7075
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
--
Steven Pine
(510) 517-7075
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160207/4f03a475/attachment-0001.html>;
Steven Pine [ARCHIVE] /
npub17t…kadm9
2023-06-07 17:48:49
in reply to nevent1q…nzrt
Author Public Key
npub17t0q8zqty0mzjuk6t6jul40zvszs0jwds0kkxy3d8x5xef60073sckadm9Published at
2023-06-07 17:48:49Event JSON
{
"id": "73ba6f88c5e08cdd15158ce8ecafa497725257c812533e60a16231c80a81a8a4",
"pubkey": "f2de03880b23f62972da5ea5cfd5e2640507c9cd83ed63122d39a86ca74f7fa3",
"created_at": 1686160129,
"kind": 1,
"tags": [
[
"e",
"299dc342b2928a854d3cdebebdfa1b5d7d113553560926ba6670328be5b1c1ce",
"",
"root"
],
[
"e",
"820c9c264c9b7cba0b38f86ddf45d353f21f7b19873bb2f0520e5a640a2f2e70",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "📅 Original date posted:2016-02-07\n📝 Original message:I agree that it seems like a safe assumption that adoption would be faster,\nwhether it is \"very safe\" and \"significantly faster\", whether it will be 6\ntimes faster, all of those assumptions seems significantly less safe and\nrobust to me.\n\nThe nature of the bitcoin protocol, that it is a decentralized census based\nprotocol involving currency, suggests to me that roll out schedules ought\nto be conservative with a minimum of assumptions. In light of the most\nrecent protocol upgrade, 6 months for this hard fork seems to me to be the\nmost conservative time frame with the fewest assumptions.\n\nAs for why it needs to be so fast, ie what are the dangers of it being as\nslow as 6 months?\n\nGavin writes:\n\n\"I strongly disagree with the statement that there is no cost to a longer\ngrace period. There is broad agreement that a capacity increase is needed\nNOW.\"\n\n~~\n\"Broad agreement\", that really seems to be another assumption, the fact\nthat the debate has been as long and acrimonious as it has been suggests\nthat there isn't broad agreement. Also, resorting to \"SHOUTING\" doesn't win\nany favors when it comes to engaging in reasonable discussion om the\ntechnical merits of a proposal.\n\n\n\nOn Sun, Feb 7, 2016 at 5:04 PM, Corey Haddad \u003ccorey3 at gmail.com\u003e wrote:\n\n\u003e We don't have any evidence of how fast nodes will upgrade when faced with\n\u003e an impending hard fork, but it seems like a very safe assumption that the\n\u003e upgrade pace will be significantly faster. The hard fork case it is:\n\u003e \"upgrade or be kicked off the network\". In the previous cases it has been,\n\u003e \"here's the latest and greatest, give it a go!\". Also, there will be\n\u003e alerts sent out warning people of the situation, prompting them to take\n\u003e action.\n\u003e\n\u003e It is unclear if this will translate into more or less than 6x the\n\u003e adoption speed of previous instances, but the idea that it would be faster\n\u003e is solid. 28 days is aggressive, but again, it is only 28 days from when\n\u003e the fork triggers. Compatible software is already available for anyone who\n\u003e wants to prepare.\n\u003e\n\u003e It is also of significance that this proposed fork, and this debate, has\n\u003e been going on for many, many months. If someone proposed a forking concept\n\u003e today, wrote the BIP tomorrow, deployed it next week, miners adopted it\n\u003e instantly, and 28 days later it was the flag day, those 28 days would be in\n\u003e a different context. There is no surprise here.\n\u003e\n\u003e On Sun, Feb 7, 2016 at 1:33 PM, Steven Pine via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Is it me or did Gavin ignore Yifu's direct questions? In case you missed\n\u003e\u003e it Gavin --\n\u003e\u003e\n\u003e\u003e ~\n\u003e\u003e \"We can look at the adoption of the last major Bitcoin core release to\n\u003e\u003e guess how long it might take people to upgrade. 0.11.0 was released on 12\n\u003e\u003e July, 2015. Twenty eight days later, about 38% of full nodes were\n\u003e\u003e running that release. Three months later, about 50% of the network was\n\u003e\u003e running that release, and six months later about 66% of the network was\n\u003e\u003e running some flavor of 0.11.\"\n\u003e\u003e\n\u003e\u003e On what grounds do you think it is reasonable to assume that this update\n\u003e\u003e will roll out 6x faster than previous data suggested, as oppose to your own\n\u003e\u003e observation of 66% adoption in 6 month. or do you believe 38% node\n\u003e\u003e upgrade-coverage (in 28 days ) on the network for a hard fork is good\n\u003e\u003e enough?\n\u003e\u003e\n\u003e\u003e There are no harm in choosing a longer grace period but picking one short\n\u003e\u003e as 28 days you risk on alienating the nodes who do not upgrade with the\n\u003e\u003e aggressive upgrade timeline you proposed.\n\u003e\u003e ~~\n\u003e\u003e\n\u003e\u003e When Gavin writes \"Responding to \"28 days is not long enough\" :\n\u003e\u003e\n\u003e\u003e I keep seeing this claim made with no evidence to back it up. As I said,\n\u003e\u003e I surveyed several of the biggest infrastructure providers and the btcd\n\u003e\u003e lead developer and they all agree \"28 days is plenty of time.\"\n\u003e\u003e\n\u003e\u003e For individuals... why would it take somebody longer than 28 days to\n\u003e\u003e either download and restart their bitcoind, or to patch and then re-run\n\u003e\u003e (the patch can be a one-line change MAX_BLOCK_SIZE from 1000000 to\n\u003e\u003e 2000000)?\"\n\u003e\u003e\n\u003e\u003e ~~\n\u003e\u003e\n\u003e\u003e Isn't Yifu's comment, evidence, the very best sort of evidence, it isn't\n\u003e\u003e propositional a priori logic, but empirical evidence that. As for why\n\u003e\u003e people take longer, who knows, we simply know from passed experience that\n\u003e\u003e it in fact does take longer.\n\u003e\u003e\n\u003e\u003e It's extremely frustrating to read Gavin's comments, it's hard to believe\n\u003e\u003e he is engaging in earnest discussion.\n\u003e\u003e\n\u003e\u003e On Sun, Feb 7, 2016 at 4:01 PM, Luke Dashjr via bitcoin-dev \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e On Sunday, February 07, 2016 2:16:02 PM Gavin Andresen wrote:\n\u003e\u003e\u003e \u003e On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev \u003c\n\u003e\u003e\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e \u003e \u003e On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev\n\u003e\u003e\u003e wrote:\n\u003e\u003e\u003e \u003e \u003e \u003e If you have a node that is \"old\" your node will stop getting new\n\u003e\u003e\u003e \u003e \u003e \u003e blocks. The node will essentially just say \"x-hours behind\" with\n\u003e\u003e\u003e \"x\"\n\u003e\u003e\u003e \u003e \u003e \u003e getting larger every hour. Funds don't get confirmed. etc.\n\u003e\u003e\u003e \u003e \u003e\n\u003e\u003e\u003e \u003e \u003e Until someone decides to attack you. Then you'll get 6, 10, maybe\n\u003e\u003e\u003e more\n\u003e\u003e\u003e \u003e \u003e blocks confirming a large 10000 BTC payment. If you're just a normal\n\u003e\u003e\u003e end\n\u003e\u003e\u003e \u003e \u003e user (or perhaps an automated system), you'll figure that payment is\n\u003e\u003e\u003e good\n\u003e\u003e\u003e \u003e \u003e and irreversibly hand over the title to the house.\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e There will be approximately zero percentage of hash power left on the\n\u003e\u003e\u003e \u003e weaker branch of the fork, based on past soft-fork adoption by miners\n\u003e\u003e\u003e (they\n\u003e\u003e\u003e \u003e upgrade VERY quickly from 75% to over 95%).\n\u003e\u003e\u003e\n\u003e\u003e\u003e I'm assuming there are literally ZERO miners left on the weaker branch.\n\u003e\u003e\u003e The attacker in this scenario simply rents hashing for a few days in\n\u003e\u003e\u003e advance\n\u003e\u003e\u003e to build his fake chain, then broadcasts the blocks to the unsuspecting\n\u003e\u003e\u003e merchant at ~10 block intervals so it looks like everything is working\n\u003e\u003e\u003e normal\n\u003e\u003e\u003e again. There are lots of mining rental services out there, and miners\n\u003e\u003e\u003e quite\n\u003e\u003e\u003e often do not care to avoid selling hashrate to the highest bidder\n\u003e\u003e\u003e regardless\n\u003e\u003e\u003e of what they're mining. 10 blocks worth costs a little more than 250 BTC\n\u003e\u003e\u003e -\n\u003e\u003e\u003e soon, that will be 125 BTC.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Luke\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e --\n\u003e\u003e Steven Pine\n\u003e\u003e (510) 517-7075\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n\u003e\n\n\n-- \nSteven Pine\n(510) 517-7075\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160207/4f03a475/attachment-0001.html\u003e",
"sig": "7051ea102923ca4ae76fad096b71322ec0d068851b06bb5c917e9f9a321163a3cd4c69efe628dc081d7b29d7754b7c8b6606a2d7eb50258f801db56f8f81d313"
}