đź“… Original date posted:2015-08-18
đź“ť Original message:Again, I'm not suggesting further testing in sterile environments. I'm
suggesting testing on the public global testnet network, so that real-world
hazards such as network lag, bandwidth constraints, traffic bottlenecks,
etc can wreak what havoc they can on the proposed implementation. Also, a
test deployment would give more people an opportunity to see how the
proposed implementation works and "kick the tires", which might help to
reduce some degree of angst about the proposals.
Your point appears to be that the biggest challenge facing Bitcoin is not
technical, but political. Sadly, you may be right.
On Tue, Aug 18, 2015 at 2:17 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> People have already been testing big blocks on testnets.
>
> The biggest problem here isn’t whether we can test the code in a fairly
> sterile environment. The biggest problem is convincing enough people to
> switch without:
>
> 1) Pissing off the other side enough to the point where regardless of who
> wins the other side refuses to cooperate
> 2) Screwing up the incentive model, allowing people to sabotage the
> process somehow
> 3) Setting a precedent enabling hostile entities to destroy the network
> from within in the future
> etc…
>
> These kinds of things seem very hard to test on a testnet.
>
> On Aug 18, 2015, at 2:06 PM, Danny Thorpe <danny.thorpe at gmail.com> wrote:
>
> Ya, so? All that means is that the experiment might reach the hard fork
> tipping point faster than mainnet would. Verifying that the network can
> handle such transitions, and how larger blocks affect the network, is the
> point of testing.
>
> And when I refer to testnet, I mean the public global testnet blockchain,
> not in-house isolated networks like testnet-in-a-box.
>
> On Tue, Aug 18, 2015 at 1:51 PM, Eric Lombrozo <elombrozo at gmail.com>
> wrote:
>
>> Problem is if you know most of the people running the testnet personally
>> (as is pretty much the case with many current testnets) then the deployment
>> amounts to “hey guys, let’s install the new version”
>>
>> On Aug 18, 2015, at 1:48 PM, Danny Thorpe via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Deploying experimental code onto the "live" bitcoin blockchain seems
>> unnecessarily risky. Why not deploy a blocksize limit experiment for long
>> term trials using testnet instead?
>>
>> On Tue, Aug 18, 2015 at 2:54 AM, jl2012 via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> As I understand, there is already a consensus among core dev that block
>>> size should/could be raised. The remaining questions are how, when, how
>>> much, and how fast. These are the questions for the coming Bitcoin
>>> Scalability Workshops but immediate consensus in these issues are not
>>> guaranteed.
>>>
>>> Could we just stop the debate for a moment, and agree to a scheduled
>>> experimental hardfork?
>>>
>>> Objectives (by order of importance):
>>>
>>> 1. The most important objective is to show the world that reaching
>>> consensus for a Bitcoin hardfork is possible. If we could have a successful
>>> one, we would have more in the future
>>>
>>> 2. With a slight increase in block size, to collect data for future
>>> hardforks
>>>
>>> 3. To slightly relieve the pressure of full block, without minimal
>>> adverse effects on network performance
>>>
>>> With the objectives 1 and 2 in mind, this is to NOT intended to be a
>>> kick-the-can-down-the-road solution. The third objective is more like a
>>> side effect of this experiment.
>>>
>>>
>>> Proposal (parameters in ** are my recommendations but negotiable):
>>>
>>> 1. Today, we all agree that some kind of block size hardfork will happen
>>> on t1=*1 June 2016*
>>>
>>> 2. If no other consensus could be reached before t2=*1 Feb 2016*, we
>>> will adopt the backup plan
>>>
>>> 3. The backup plan is: t3=*30 days* after m=*80%* of miner approval, but
>>> not before t1=*1 June 2016*, the block size is increased to s=*1.5MB*
>>>
>>> 4. If the backup plan is adopted, we all agree that a better solution
>>> should be found before t4=*31 Dec 2017*.
>>>
>>> Rationale:
>>>
>>> t1 = 1 June 2016 is chosen to make sure everyone have enough time to
>>> prepare for a hardfork. Although we do not know what actually will happen
>>> but we know something must happen around that moment.
>>>
>>> t2 = 1 Feb 2016 is chosen to allow 5 more months of negotiations (and 2
>>> months after the workshops). If it is successful, we don't need to activate
>>> the backup plan
>>>
>>> t3 = 30 days is chosen to make sure every full nodes have enough time to
>>> upgrade after the actual hardfork date is confirmed
>>>
>>> t4 = 31 Dec 2017 is chosen, with 1.5 year of data and further debate,
>>> hopefully we would find a better solution. It is important to acknowledge
>>> that the backup plan is not a final solution
>>>
>>> m = 80%: We don't want a very small portion of miners to have the power
>>> to veto a hardfork, while it is important to make sure the new fork is
>>> secured by enough mining power. 80% is just a compromise.
>>>
>>> s = 1.5MB. As the 1MB cap was set 5 years ago, there is no doubt that
>>> all types of technology has since improved by >50%. I don't mind making it
>>> a bit smaller but in that case not much valuable data could be gathered and
>>> the second objective of this experiment may not be archived.
>>>
>>> --------------------
>>>
>>> If the community as a whole could agree with this experimental hardfork,
>>> we could announce the plan on bitcoin.org and start coding of the patch
>>> immediately. At the same time, exploration for a better solution continues.
>>> If no further consensus could be reached, a new version of Bitcoin Core
>>> with the patch will be released on or before 1 Feb 2016 and everyone will
>>> be asked to upgrade immediately.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150818/6ce5aad3/attachment.html>;
Danny Thorpe [ARCHIVE] /
npub1q5…3ps87
2023-06-07 17:36:41
in reply to nevent1q…30vy
Author Public Key
npub1q5sgcakfxhw3ya93tvnpqeacvf32p6lw70hke53rkjnf9lhw9w8s43ps87Published at
2023-06-07 17:36:41Event JSON
{
"id": "a19615194c4a97e8579e7b584694d4310915d8ebd43af06684c33bbb185da8cb",
"pubkey": "05208c76c935dd1274b15b261067b86262a0ebeef3ef6cd223b4a692feee2b8f",
"created_at": 1686159401,
"kind": 1,
"tags": [
[
"e",
"015c5ac0a5b1780b314fc0de46b00e614fb9247d46dfb61637d3d94fa76f544c",
"",
"root"
],
[
"e",
"b6369bc789aaa8d70102a834e7e31648c9fc65dc6bd2dba5df150f763bae01fb",
"",
"reply"
],
[
"p",
"e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f"
]
],
"content": "📅 Original date posted:2015-08-18\n📝 Original message:Again, I'm not suggesting further testing in sterile environments. I'm\nsuggesting testing on the public global testnet network, so that real-world\nhazards such as network lag, bandwidth constraints, traffic bottlenecks,\netc can wreak what havoc they can on the proposed implementation. Also, a\ntest deployment would give more people an opportunity to see how the\nproposed implementation works and \"kick the tires\", which might help to\nreduce some degree of angst about the proposals.\n\nYour point appears to be that the biggest challenge facing Bitcoin is not\ntechnical, but political. Sadly, you may be right.\n\nOn Tue, Aug 18, 2015 at 2:17 PM, Eric Lombrozo \u003celombrozo at gmail.com\u003e wrote:\n\n\u003e People have already been testing big blocks on testnets.\n\u003e\n\u003e The biggest problem here isn’t whether we can test the code in a fairly\n\u003e sterile environment. The biggest problem is convincing enough people to\n\u003e switch without:\n\u003e\n\u003e 1) Pissing off the other side enough to the point where regardless of who\n\u003e wins the other side refuses to cooperate\n\u003e 2) Screwing up the incentive model, allowing people to sabotage the\n\u003e process somehow\n\u003e 3) Setting a precedent enabling hostile entities to destroy the network\n\u003e from within in the future\n\u003e etc…\n\u003e\n\u003e These kinds of things seem very hard to test on a testnet.\n\u003e\n\u003e On Aug 18, 2015, at 2:06 PM, Danny Thorpe \u003cdanny.thorpe at gmail.com\u003e wrote:\n\u003e\n\u003e Ya, so? All that means is that the experiment might reach the hard fork\n\u003e tipping point faster than mainnet would. Verifying that the network can\n\u003e handle such transitions, and how larger blocks affect the network, is the\n\u003e point of testing.\n\u003e\n\u003e And when I refer to testnet, I mean the public global testnet blockchain,\n\u003e not in-house isolated networks like testnet-in-a-box.\n\u003e\n\u003e On Tue, Aug 18, 2015 at 1:51 PM, Eric Lombrozo \u003celombrozo at gmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e Problem is if you know most of the people running the testnet personally\n\u003e\u003e (as is pretty much the case with many current testnets) then the deployment\n\u003e\u003e amounts to “hey guys, let’s install the new version”\n\u003e\u003e\n\u003e\u003e On Aug 18, 2015, at 1:48 PM, Danny Thorpe via bitcoin-dev \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e Deploying experimental code onto the \"live\" bitcoin blockchain seems\n\u003e\u003e unnecessarily risky. Why not deploy a blocksize limit experiment for long\n\u003e\u003e term trials using testnet instead?\n\u003e\u003e\n\u003e\u003e On Tue, Aug 18, 2015 at 2:54 AM, jl2012 via bitcoin-dev \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e As I understand, there is already a consensus among core dev that block\n\u003e\u003e\u003e size should/could be raised. The remaining questions are how, when, how\n\u003e\u003e\u003e much, and how fast. These are the questions for the coming Bitcoin\n\u003e\u003e\u003e Scalability Workshops but immediate consensus in these issues are not\n\u003e\u003e\u003e guaranteed.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Could we just stop the debate for a moment, and agree to a scheduled\n\u003e\u003e\u003e experimental hardfork?\n\u003e\u003e\u003e\n\u003e\u003e\u003e Objectives (by order of importance):\n\u003e\u003e\u003e\n\u003e\u003e\u003e 1. The most important objective is to show the world that reaching\n\u003e\u003e\u003e consensus for a Bitcoin hardfork is possible. If we could have a successful\n\u003e\u003e\u003e one, we would have more in the future\n\u003e\u003e\u003e\n\u003e\u003e\u003e 2. With a slight increase in block size, to collect data for future\n\u003e\u003e\u003e hardforks\n\u003e\u003e\u003e\n\u003e\u003e\u003e 3. To slightly relieve the pressure of full block, without minimal\n\u003e\u003e\u003e adverse effects on network performance\n\u003e\u003e\u003e\n\u003e\u003e\u003e With the objectives 1 and 2 in mind, this is to NOT intended to be a\n\u003e\u003e\u003e kick-the-can-down-the-road solution. The third objective is more like a\n\u003e\u003e\u003e side effect of this experiment.\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e Proposal (parameters in ** are my recommendations but negotiable):\n\u003e\u003e\u003e\n\u003e\u003e\u003e 1. Today, we all agree that some kind of block size hardfork will happen\n\u003e\u003e\u003e on t1=*1 June 2016*\n\u003e\u003e\u003e\n\u003e\u003e\u003e 2. If no other consensus could be reached before t2=*1 Feb 2016*, we\n\u003e\u003e\u003e will adopt the backup plan\n\u003e\u003e\u003e\n\u003e\u003e\u003e 3. The backup plan is: t3=*30 days* after m=*80%* of miner approval, but\n\u003e\u003e\u003e not before t1=*1 June 2016*, the block size is increased to s=*1.5MB*\n\u003e\u003e\u003e\n\u003e\u003e\u003e 4. If the backup plan is adopted, we all agree that a better solution\n\u003e\u003e\u003e should be found before t4=*31 Dec 2017*.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Rationale:\n\u003e\u003e\u003e\n\u003e\u003e\u003e t1 = 1 June 2016 is chosen to make sure everyone have enough time to\n\u003e\u003e\u003e prepare for a hardfork. Although we do not know what actually will happen\n\u003e\u003e\u003e but we know something must happen around that moment.\n\u003e\u003e\u003e\n\u003e\u003e\u003e t2 = 1 Feb 2016 is chosen to allow 5 more months of negotiations (and 2\n\u003e\u003e\u003e months after the workshops). If it is successful, we don't need to activate\n\u003e\u003e\u003e the backup plan\n\u003e\u003e\u003e\n\u003e\u003e\u003e t3 = 30 days is chosen to make sure every full nodes have enough time to\n\u003e\u003e\u003e upgrade after the actual hardfork date is confirmed\n\u003e\u003e\u003e\n\u003e\u003e\u003e t4 = 31 Dec 2017 is chosen, with 1.5 year of data and further debate,\n\u003e\u003e\u003e hopefully we would find a better solution. It is important to acknowledge\n\u003e\u003e\u003e that the backup plan is not a final solution\n\u003e\u003e\u003e\n\u003e\u003e\u003e m = 80%: We don't want a very small portion of miners to have the power\n\u003e\u003e\u003e to veto a hardfork, while it is important to make sure the new fork is\n\u003e\u003e\u003e secured by enough mining power. 80% is just a compromise.\n\u003e\u003e\u003e\n\u003e\u003e\u003e s = 1.5MB. As the 1MB cap was set 5 years ago, there is no doubt that\n\u003e\u003e\u003e all types of technology has since improved by \u003e50%. I don't mind making it\n\u003e\u003e\u003e a bit smaller but in that case not much valuable data could be gathered and\n\u003e\u003e\u003e the second objective of this experiment may not be archived.\n\u003e\u003e\u003e\n\u003e\u003e\u003e --------------------\n\u003e\u003e\u003e\n\u003e\u003e\u003e If the community as a whole could agree with this experimental hardfork,\n\u003e\u003e\u003e we could announce the plan on bitcoin.org and start coding of the patch\n\u003e\u003e\u003e immediately. At the same time, exploration for a better solution continues.\n\u003e\u003e\u003e If no further consensus could be reached, a new version of Bitcoin Core\n\u003e\u003e\u003e with the patch will be released on or before 1 Feb 2016 and everyone will\n\u003e\u003e\u003e be asked to upgrade immediately.\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 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\u003e\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150818/6ce5aad3/attachment.html\u003e",
"sig": "a57271d493ef14d222c1ff453875d207c3fb261391be30e9152be7cbf707d834859818a37f39080f1e34567451d1aca72f178cc6c4693507388943e64faba64a"
}