[bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[jl2012]

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.

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[Micha Bailey]

[-- Attachment #1: Type: text/plain, Size: 671 bytes --]

A smaller block size would make this a soft fork, as unupgraded nodes would
consider the new blocks valid. It would only make things that were allowed
forbidden, which is the definition of a soft fork. For a hard fork, you
need to allow something that was previously invalid.

On Tuesday, August 18, 2015, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 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.
>

[-- Attachment #2: Type: text/html, Size: 859 bytes --]

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[Eric Lombrozo]

[-- Attachment #1: Type: text/plain, Size: 4199 bytes --]

I’m 100% in favor of attempting a hard fork using a far less controversial, far less risky consensus rule change. We should stop wasting our energy arguing over stuff we don’t really know and understand and can’t predict very well - and we should especially avoid using a highly contentious change as our first hard fork deployment.

I’m also in favor of trying a small block increase before attempting any major jumps. I don’t think we should be focusing so much on long-term block size adjustment rules right now - much more critical is to develop a hard fork mechanism and to make sure we can deploy it. So something along these lines is probably a step in the right direction.


> On Aug 18, 2015, at 2:54 AM, jl2012 via bitcoin-dev <bitcoin-dev@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[Danny Thorpe]

[-- Attachment #1: Type: text/plain, Size: 3677 bytes --]

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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 4358 bytes --]

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[Eric Lombrozo]

[-- Attachment #1.1: Type: text/plain, Size: 4381 bytes --]

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@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@lists.linuxfoundation.org <mailto:bitcoin-dev@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 <http://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@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[-- Attachment #1.2: Type: text/html, Size: 5902 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[Danny Thorpe]

[-- Attachment #1: Type: text/plain, Size: 4841 bytes --]

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@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@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@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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>

[-- Attachment #2: Type: text/html, Size: 6285 bytes --]

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[Eric Lombrozo]

[-- Attachment #1.1: Type: text/plain, Size: 5777 bytes --]

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@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@gmail.com <mailto:elombrozo@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@lists.linuxfoundation.org <mailto:bitcoin-dev@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@lists.linuxfoundation.org <mailto:bitcoin-dev@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 <http://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@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>> 
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> 
> 


[-- Attachment #1.2: Type: text/html, Size: 8326 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[Danny Thorpe]

[-- Attachment #1: Type: text/plain, Size: 6381 bytes --]

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@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@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@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@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@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@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>
>

[-- Attachment #2: Type: text/html, Size: 8207 bytes --]

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[Jorge Timón]

On Tue, Aug 18, 2015 at 11:06 PM, Danny Thorpe via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> 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.

I would expect any uncontroversial hardfork to be deployed in testnet3
before it is deployed in bitcoin's main chain.

In any case, you can already do these tests using
https://github.com/bitcoin/bitcoin/pull/6382
Note that even if the new testchains are regtest-like (ie cheap proof
of work) you don't need to test them "in-a-box": you can run them from
many different places.
Rusty's test ( http://rusty.ozlabs.org/?p=509 ) could have been
perfectly made using #6382, it just didn't existed at the time.

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[odinn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Firstly, XT is controversial, not uncontroversial;
Second, this issue has been beat to death quite a while ago
https://github.com/bitcoin-dot-org/bitcoin.org/pull/899#issuecomment-117
815987
Third, it poses major risks as a non-peer reviewed alt with a number
of problematic features (with the privacy problems recently mentioned
on this list being just one of them)
Fourth, it has not followed any semblance of process in terms of the
development funnel or BIPS process, with XT developers instead
choosing instead a dangerous path of hard forking bitcoin while being
well aware of miner voting on viable solutions which have followed
process.

The following proposals
http://bipsxdevs.azurewebsites.net/
regardless of what you think of any one of them, are deserving of
attention (BIP 100 / BIP 101) and are being voted on as you read this
by miners. (BIP sipa is not yet numbered, and BIP 102 is a backup
/fallback option.)  BIP 100 is probably the best of these (note, in
part, it schedules a hardfork on testnet in September).

Contentious hard forks are bad for Bitcoin.
https://bitcoin.org/en/posts/hard-fork-policy
You may want to read this again if you haven't recently.

There is no basis for further promoting XT by suggesting that it
should even be tested.

#GAVEL

On 08/19/2015 02:29 AM, Jorge Timón via bitcoin-dev wrote:
> On Tue, Aug 18, 2015 at 11:06 PM, Danny Thorpe via bitcoin-dev 
> <bitcoin-dev@lists.linuxfoundation.org> 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.
> 
> I would expect any uncontroversial hardfork to be deployed in
> testnet3 before it is deployed in bitcoin's main chain.
> 
> In any case, you can already do these tests using 
> https://github.com/bitcoin/bitcoin/pull/6382 Note that even if the
> new testchains are regtest-like (ie cheap proof of work) you don't
> need to test them "in-a-box": you can run them from many different
> places. Rusty's test ( http://rusty.ozlabs.org/?p=509 ) could have
> been perfectly made using #6382, it just didn't existed at the
> time. _______________________________________________ bitcoin-dev
> mailing list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJV1FcVAAoJEGxwq/inSG8CAd8H/R9khvHJJaNKrq7tjzksyc6V
jNN8ApaYUOE/i+goKd7XaeW0LM0aUC5vdqOCud632zb9XGo6awlk0fML4FV+wsE0
e5EfVDKZJxQ7zbaNCXXKTUfC+XRpJlhJgfF9jDgTsKv2l8fALbz+U6tn65Ke8F4+
9A4jJCe8yjttjBkX+8wLsSeDkDsPxo7f29rPfI6YMtN4MYbdxGiLjrTuRWrVje8q
l+3IFxrqGwKQl3LygRQHmLosvcW8UZzGYIM7hCleE9NUpc9TdpyTXPB3+9O9h4ty
5vY9jZ6t2Ww9CeljzD8S+1Nycz7sHqeoBCie+WexY7aT/QV2WQxFp4qnpO7PMSs=
=UNYA
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[Jorge Timón]

On Wed, Aug 19, 2015 at 12:14 PM, odinn <odinn.cyberguerrilla@riseup.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Firstly, XT is controversial, not uncontroversial;

XT it's just a software fork.
BIP101 (as currently implemented in Bitcoin XT) is a Schism hardfork
(or an altcoin), but BIP101 could be modified to be deployed like an
uncontroversial hardfork (in current bip99's draft, a given height
plus 95% mining upgrade confirmation after that).

> Third, it poses major risks as a non-peer reviewed alt with a number
> of problematic features (with the privacy problems recently mentioned
> on this list being just one of them)
>
> Fourth, it has not followed any semblance of process in terms of the
> development funnel or BIPS process, with XT developers instead
> choosing instead a dangerous path of hard forking bitcoin while being
> well aware of miner voting on viable solutions which have followed
> process.

I'm not defending the Schism hardfork being proposed. I am very
worried about it and I have publicly said so several times.
If Bitcoin XT didn't contained the Schism bip101 hardfork I wouldn't
be so worried: users are free to use software that is less reviewed at
their own risk.

> The following proposals
> http://bipsxdevs.azurewebsites.net/
> regardless of what you think of any one of them, are deserving of
> attention (BIP 100 / BIP 101) and are being voted on as you read this
> by miners. (BIP sipa is not yet numbered, and BIP 102 is a backup
> /fallback option.)  BIP 100 is probably the best of these (note, in
> part, it schedules a hardfork on testnet in September).

It's users and not miners who decide the consensus rules.

> Contentious hard forks are bad for Bitcoin.
> https://bitcoin.org/en/posts/hard-fork-policy
> You may want to read this again if you haven't recently.

You may want to read BIP99 to understand that I know this, but still
think that Schism hardforks may be necessary in some situations (I
don't think this one is reasonable though).

> There is no basis for further promoting XT by suggesting that it
> should even be tested.

All I'm saying is that Bitcoin XT the software fork is totally fine
(like other alternative Bitcoin implementations). The big problem is
BIP101 being deployed as a Schism hardfork.

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[odinn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 08/19/2015 04:06 AM, Jorge Timón wrote:
> On Wed, Aug 19, 2015 at 12:14 PM, odinn
> <odinn.cyberguerrilla@riseup.net> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> Firstly, XT is controversial, not uncontroversial;
> 
> XT it's just a software fork.


You must be really tired.

Please read the whole pull request discussing this loathsome subject her
e:

https://github.com/bitcoin-dot-org/bitcoin.org/pull/899

It was fairly detailed and conclusive. I'm not being a dumdum when I
say that it is controversial.

> BIP101 (as currently implemented in Bitcoin XT) is a Schism
> hardfork (or an altcoin), but BIP101 could be modified to be
> deployed like an uncontroversial hardfork (in current bip99's
> draft, a given height plus 95% mining upgrade confirmation after
> that).

Everybody here is well aware of what this sad proposal is.  See
detailed reply to the moaning and groaning of Hearn on this subject,
where he claimed that "the difference between hard and soft forks is
actually quite small, has got smaller with time and is thus hardly the
policy-founding chasm you seem to think it is."  He was wrong, of
course.  Thus, my reply to that, which I won't bother to quote in
detail but which you can read here:
https://github.com/bitcoin-dot-org/bitcoin.org/pull/899#issuecomment-117
815987

> 
>> Third, it poses major risks as a non-peer reviewed alt with a
>> number of problematic features (with the privacy problems
>> recently mentioned on this list being just one of them)
>> 
>> Fourth, it has not followed any semblance of process in terms of
>> the development funnel or BIPS process, with XT developers
>> instead choosing instead a dangerous path of hard forking bitcoin
>> while being well aware of miner voting on viable solutions which
>> have followed process.
> 
> I'm not defending the Schism hardfork being proposed. I am very 
> worried about it and I have publicly said so several times. If
> Bitcoin XT didn't contained the Schism bip101 hardfork I wouldn't 
> be so worried: users are free to use software that is less reviewed
> at their own risk.
> 
>> The following proposals http://bipsxdevs.azurewebsites.net/ 
>> regardless of what you think of any one of them, are deserving
>> of attention (BIP 100 / BIP 101) and are being voted on as you
>> read this by miners. (BIP sipa is not yet numbered, and BIP 102
>> is a backup /fallback option.)  BIP 100 is probably the best of
>> these (note, in part, it schedules a hardfork on testnet in
>> September).
> 
> It's users and not miners who decide the consensus rules.
> 
>> Contentious hard forks are bad for Bitcoin. 
>> https://bitcoin.org/en/posts/hard-fork-policy You may want to
>> read this again if you haven't recently.
> 
> You may want to read BIP99 to understand that I know this, but
> still think that Schism hardforks may be necessary in some
> situations (I don't think this one is reasonable though).


Given the state in which bitcoin is in now, one could say that things
are fairly horrible, but by no means necessitating, as you put it, a
schism hardfork.  It is clear and evidenced by my previous posts and
others that Hearn's efforts are an attack on the bitcoin network.

> 
>> There is no basis for further promoting XT by suggesting that it 
>> should even be tested.
> 
> All I'm saying is that Bitcoin XT the software fork is totally
> fine (like other alternative Bitcoin implementations).

It's not totally fine at all.  It shouldn't even exist.  People are
doing other unsuspecting users a disservice by even suggesting that it
should be downloaded.

 The big problem is
> BIP101 being deployed as a Schism hardfork.

This is certainly a problem.

> 

#GAVEL

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJV1GevAAoJEGxwq/inSG8CJXwH/3XX7Osr48MmcJ9mrPyOJ4Zn
WxRmdJ99mbO5KhrjD8+eRtFjURQNsQYAJ6ftnQEGaksuprSYCPQQR6WsV9mqRKZ2
/zdSz/5RjdADsjB2FDN6gWpwpyg7tzUpB6D4rCjuL1fcRmieCxwNUxnnFTbedxpE
MdT2oj9uSB7tTvU4AYs2VzJq0QeRn/c0pTJkBDwU0c4PN1tv/IQnOzmS+LnQDQJJ
eaunhpbmphRzqC9Mh8N7pD40ZyVoM5ysxVv86OaqmsOQL4W01CahQKADB4T/pBla
AOPh3LLxp7aamC9aYnBfxIaWXj28BZCwVasDkJdQ/Qg/rV5/Kze7TjJs9G2sowc=
=OvDj
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[jl2012]

odinn via bitcoin-dev 於 2015-08-19 07:25 寫到:

>  The big problem is
>> BIP101 being deployed as a Schism hardfork.
> 
> This is certainly a problem.
> 


No, BitcoinXT won't become a Schism hardfork, or may be just for a few 
days, at most.

There is one, and only one scenario that BitcoinXT will win: it is 
supported by major exchanges, merchants, and investors, and they request 
miners to support it. When BIP101 is activated, these exchanges will 
refuse to accept or exchange tokens from the old chain. Miners in the 
old chain can't sell their newly generated coins and can't pay the 
electricity bill. They will soon realize that they are mining fool's 
gold and will be forced to switch to the new chain or sell their ASIC. 
The old chain will be abandoned and has no hope to revive without a 
hardfork to decrease the difficulty. The dust will settle in days if not 
hours.

Will the adoption of BitcoinXT lead by miners? No, it won't. Actually, 
Chinese miners who control 60% of the network has already said that they 
would not adopt XT. So they must not be the leader in this revolution. 
Again, miners need to make sure they could sell their bitcoin in a good 
price, and that's not possible without support of exchanges and 
investors.

What about that Not-Bitcoin-XT? The creator of the spoof client may stay 
anonymous, but the miners cannot. 95% of the blocks come from known 
entities and they have to be responsible to their actions. And again, 
they have real money in stake. If bitcoin is destroyed, their ASIC 
serves at best as very inefficient heaters.

So Bitcoin-XT is basically in a win-all-or-lose-all position. It all 
relies on one condition: the support of major exchanges, merchants, and 
investors. Their consensus is what really matters. With their consensus, 
that could not be a Schism hardfork. Without their consensus, nothing 
will happen.

-------

Or let me analyse in a different angle. BitcoinXT is in no way similar 
to your examples of Schism hardforks. All of your examples, "ASIC-reset 
hardfork", "Anti-Block-creator hardfork", and "Anti-cabal hardfork", are 
hostile to the current biggest miners and will destroy their investment. 
These miners have no choice but stick to the original protocol so 2 
chains MUST coexist. However, BIP101 has no such effect at all and 
miners may freely switch between the forks. They will always choose the 
most valuable fork, so only one fork will survive.

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 1835 bytes --]

On Wed, Aug 19, 2015 at 4:22 PM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Will the adoption of BitcoinXT lead by miners? No, it won't. Actually,
> Chinese miners who control 60% of the network has already said that they
> would not adopt XT. So they must not be the leader in this revolution.
> Again, miners need to make sure they could sell their bitcoin in a good
> price, and that's not possible without support of exchanges and investors.
>

So, the exchanges get together to "encourage" the miners to start running
bitcoin-XT.  What would they do?

One scheme would be to create a taint system.  All non-XT coinbases outputs
are marked as tainted.  All outputs are tainted if any of the inputs into a
transaction are tainted.  Tainted coins can only be un-tainted by sending
0.5% of their value to the public address of one of the participating
exchanges (or to OP_RETURN).  They could slowly ratchet up the surcharge.

Exchanges in the cartel agree not to exchange tainted coins.  Even if some
still do, the tainted coins are still inherently less valuable, since fewer
exchanges accept them.

Schemes like that are the main way for non-miners to flex their muscles,
even if they seem unsavory.

Taint tracking would allow merchants to participate.  They could give less
credit for tainted bitcoins, even if the exchanges are trying to remain
neutral.  If that happens, the exchanges could run 2 prices, BTC and
BTC-tainted.

On the other hand, implementing taint machinery is a bad thing for
fungibility.

It can also be accomplished with checkpointing.  They need to create 1 big
block and then agree to checkpoint it.

A less strict rule rule could be that blocks after the first big block
count as double POW.  That means that the big block chain only needs 34% of
the hashing power to win.

[-- Attachment #2: Type: text/html, Size: 2330 bytes --]

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[Jorge Timón]

On Wed, Aug 19, 2015 at 1:25 PM, odinn <odinn.cyberguerrilla@riseup.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> On 08/19/2015 04:06 AM, Jorge Timón wrote:
>> On Wed, Aug 19, 2015 at 12:14 PM, odinn
>> <odinn.cyberguerrilla@riseup.net> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>
>>> Firstly, XT is controversial, not uncontroversial;
>>
>> XT it's just a software fork.
>
> Please read the whole pull request discussing this loathsome subject her
> e:
>
> https://github.com/bitcoin-dot-org/bitcoin.org/pull/899
>
> It was fairly detailed and conclusive. I'm not being a dumdum when I
> say that it is controversial.

And I'm not trying to be a dumdum (whatever that is) when saying that
Bitcoin XT the softfork and BIP101 implemented as a schism hardfork in
Bitcoin XT are different things. One existed before the other. And if
there wasn't a schism hardfork in the making there wouldn't be any
warning about Bitcoin XT in bitcoin.org because Bitcoin XT implemented
the same consensus rules (and I think was largely ignored).
When we say "Bitcoin XT is bad" some users read "Bitcoin Core devs
think any code fork to Bitcoin Core is back because they lose control
over it".
The second is not the case: nobody complained or cared about Bitcoin
XT when it implemented the same consensus rules.

>> BIP101 (as currently implemented in Bitcoin XT) is a Schism
>> hardfork (or an altcoin), but BIP101 could be modified to be
>> deployed like an uncontroversial hardfork (in current bip99's
>> draft, a given height plus 95% mining upgrade confirmation after
>> that).
>
> Everybody here is well aware of what this sad proposal is.  See
> detailed reply to the moaning and groaning of Hearn on this subject,
> where he claimed that "the difference between hard and soft forks is
> actually quite small, has got smaller with time and is thus hardly the
> policy-founding chasm you seem to think it is."  He was wrong, of
> course.  Thus, my reply to that, which I won't bother to quote in
> detail but which you can read here:
> https://github.com/bitcoin-dot-org/bitcoin.org/pull/899#issuecomment-117
> 815987

I'm not sure I will learn anything by reading this link (I didn't
reading the previous link).
Have you read BIP99 already? Can you tell me where you disagree with
what's in BIP99 in one of its 2 threads?

https://github.com/bitcoin/bips/pull/181

> Given the state in which bitcoin is in now, one could say that things
> are fairly horrible, but by no means necessitating, as you put it, a
> schism hardfork.  It is clear and evidenced by my previous posts and
> others that Hearn's efforts are an attack on the bitcoin network.

Again, I'm against this Schism hardfork but maybe I'm in favor of an
Schism hardfork in the future, I don't know.
We're both against the Schism hardfork but somehow you think I'm in
favor and are trying to change my mind.
What are we even discussing about?

>>> There is no basis for further promoting XT by suggesting that it
>>> should even be tested.
>>
>> All I'm saying is that Bitcoin XT the software fork is totally
>> fine (like other alternative Bitcoin implementations).
>
> It's not totally fine at all.  It shouldn't even exist.  People are
> doing other unsuspecting users a disservice by even suggesting that it
> should be downloaded.

Right now it shouldn't be downloaded because it contains this quite
irrational Schism hardfork.
When it was only a not-up-to-date-bitcoin/master + the commits
(non-consensus changes) Hearn would like to see in Bitcoin Core nobody
was specially worried about it.

>  The big problem is
>> BIP101 being deployed as a Schism hardfork.
>
> This is certainly a problem.

So what are we discussing about?

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[Danny Thorpe]

[-- Attachment #1: Type: text/plain, Size: 2092 bytes --]

>>
I would expect any uncontroversial hardfork to be deployed in testnet3
before it is deployed in bitcoin's main chain.
<<

Ok, glad to hear that.

>>
In any case, you can already do these tests using
https://github.com/bitcoin/bitcoin/pull/6382
<<

I saw your post about that awhile ago, thanks for doing the work!  My
fiddling with that end of the food chain is gated by my needing to block
out a weekend to set up a bitcoind build environment.

How do "big-block" testnet nodes running this 6382 rev recognize each other
on the peer network? If I set up a 2MB block limit testnet node and
-addnode another 2MB block testnet node (say, JornC's node) to it, and my
node mines a block stuffed with 1.3MB of test txs, the other "big-block"
node should accept my mined block, but it will be rejected / immediately
orphaned by the rest of the testnet network because it exceeds their notion
of block size limit, correct?

Thanks,
-Danny

On Wed, Aug 19, 2015 at 2:29 AM, Jorge Timón <jtimon@jtimon.cc> wrote:

> On Tue, Aug 18, 2015 at 11:06 PM, Danny Thorpe via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> 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.
>
> I would expect any uncontroversial hardfork to be deployed in testnet3
> before it is deployed in bitcoin's main chain.
>
> In any case, you can already do these tests using
> https://github.com/bitcoin/bitcoin/pull/6382
> Note that even if the new testchains are regtest-like (ie cheap proof
> of work) you don't need to test them "in-a-box": you can run them from
> many different places.
> Rusty's test ( http://rusty.ozlabs.org/?p=509 ) could have been
> perfectly made using #6382, it just didn't existed at the time.
>

[-- Attachment #2: Type: text/html, Size: 3411 bytes --]

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[Jorge Timón]

On Wed, Aug 19, 2015 at 7:30 PM, Danny Thorpe <danny.thorpe@gmail.com> wrote:
> How do "big-block" testnet nodes running this 6382 rev recognize each other
> on the peer network? If I set up a 2MB block limit testnet node and -addnode
> another 2MB block testnet node (say, JornC's node) to it, and my node mines
> a block stuffed with 1.3MB of test txs, the other "big-block" node should
> accept my mined block, but it will be rejected / immediately orphaned by the
> rest of the testnet network because it exceeds their notion of block size
> limit, correct?

I have (hopefully) answered your questions in the other thread.
Review/testing of #6235 would be also appreciated (to hopefully
eventually merge the full #6382 branch into bitcoin/master).

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[Ahmed Zsales]

[-- Attachment #1: Type: text/plain, Size: 1159 bytes --]

-> You need to take into account the reward halving, likely to be in
3Q2016. Forks and reward halving at the same time would possibly be a bad
combination.

-> The original proposed date for the fork was December 2015. It was pushed
back to January as December is a busy period for a lot of people and
businesses. Likewise, June is a busy period for people. July / August is a
good period as it is quiet because people go on holiday. A window of 2
months during holiday periods is better than starting in June. January 2016
is better, mainly because of the excessive reward halving chatter likely to
be going on..

..
> 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*.
> ..

[-- Attachment #2: Type: text/html, Size: 1429 bytes --]

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[Eric Lombrozo]

[-- Attachment #1.1: Type: text/plain, Size: 1592 bytes --]

As an aside, combining reward halving with block size limit doubling would have probably been a good idea :)

> On Aug 18, 2015, at 3:51 PM, Ahmed Zsales via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> -> You need to take into account the reward halving, likely to be in 3Q2016. Forks and reward halving at the same time would possibly be a bad combination.
> 
> -> The original proposed date for the fork was December 2015. It was pushed back to January as December is a busy period for a lot of people and businesses. Likewise, June is a busy period for people. July / August is a good period as it is quiet because people go on holiday. A window of 2 months during holiday periods is better than starting in June. January 2016 is better, mainly because of the excessive reward halving chatter likely to be going on..
> 
> ..
> 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*.
> ..
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[-- Attachment #1.2: Type: text/html, Size: 2547 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[Jorge Timón]

On Tue, Aug 18, 2015 at 11:54 AM, jl2012 via bitcoin-dev
<bitcoin-dev@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

Apart from classifying all potential consensus rule changes and
recommend a deployment path for each case, deploying an
uncontroversial hardfork is one of the main goals of bip99:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009837.html

> 2. With a slight increase in block size, to collect data for future
> hardforks

The uncontroversial hardfork doesn't need to change the maximum block
size: there's plenty of hardfork proposals out there, some of them
very well tested (like the proposed hardfork in bip99).

> 1. Today, we all agree that some kind of block size hardfork will happen on
> t1=*1 June 2016*

I disagree with this. I think it should be schedule at least a year
after it is deployed in the newest versions.
Maybe there's something special about June 2016 that I'm missing.

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[jl2012]

Jorge Timón 於 2015-08-19 05:24 寫到:
> On Tue, Aug 18, 2015 at 11:54 AM, jl2012 via bitcoin-dev
> <bitcoin-dev@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
> 
> Apart from classifying all potential consensus rule changes and
> recommend a deployment path for each case, deploying an
> uncontroversial hardfork is one of the main goals of bip99:
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009837.html
> 
>> 2. With a slight increase in block size, to collect data for future
>> hardforks
> 
> The uncontroversial hardfork doesn't need to change the maximum block
> size: there's plenty of hardfork proposals out there, some of them
> very well tested (like the proposed hardfork in bip99).

You misunderstand my intention. The experiment is not about a random 
hardfork. It's about a block size increase hardfork. The data will help 
us to design further hardfork on block size.

To make it less controversial, the size must not be too big.

To allow a meaningful experiment, the size must not be too small. 
Technically we could make it 1.01MB but that defeats all objectives I 
listed and there is no point to do it.

That's why I suggest 1.5MB.

>> 1. Today, we all agree that some kind of block size hardfork will 
>> happen on
>> t1=*1 June 2016*
> 
> I disagree with this. I think it should be schedule at least a year
> after it is deployed in the newest versions.
> Maybe there's something special about June 2016 that I'm missing.

I hope the fork could be done before the halving, which (hopefully) we 
may have a new bitcoin rush

There was only 2 months for the BIP50 hardfork. You may argue that's a 
"bug fix" but practically there is no difference: people not fixing the 
bug in 2 months was forked off. Four months of grace period (Feb to June 
2016) is already a double of that.

Also, if we could have zero grace period for softfork, why must we have 
a ultra-long period for hardfork? (Unless you also agree to have an 
1-year grace period for softfork. I don't buy the "softfork is safer 
than hardfork" theory. The recent BIP66 fork has clearly shown why it is 
wrong: non-upgrading full nodes are not full nodes)

The problem is many people won't update until they must do so. So 4 
months or 1 year make little difference

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[Jorge Timón]

On Wed, Aug 19, 2015 at 12:34 PM,  <jl2012@xbt.hk> wrote:
> You misunderstand my intention. The experiment is not about a random
> hardfork. It's about a block size increase hardfork.

One of your goals is "show the world that reaching consensus for a
Bitcoin hardfork is possible", right?
BIP99 can achieve that goal without touching the block size (thus
probably less controversial).

> The data will help us
> to design further hardfork on block size.

The data can be collected using testchains. See #6382

> To make it less controversial, the size must not be too big.

That makes the data less interesting, doesn't it?

> To allow a meaningful experiment, the size must not be too small.
> Technically we could make it 1.01MB but that defeats all objectives I listed
> and there is no point to do it.

It wouldn't defeat the "show the world that reaching consensus for a
Bitcoin hardfork is possible" objective though. But again, we don't
need to touch the block size to achieve that goal.

> That's why I suggest 1.5MB.

But that wouldn't be uncontroversial (unless it was accompanied with
data that somehow quantifies the risks, in which case maybe another
bigger size is acceptable).

>>> 1. Today, we all agree that some kind of block size hardfork will happen
>>> on
>>> t1=*1 June 2016*
>>
>>
>> I disagree with this. I think it should be schedule at least a year
>> after it is deployed in the newest versions.
>> Maybe there's something special about June 2016 that I'm missing.
>
>
> I hope the fork could be done before the halving, which (hopefully) we may
> have a new bitcoin rush
>
> There was only 2 months for the BIP50 hardfork. You may argue that's a "bug
> fix" but practically there is no difference: people not fixing the bug in 2
> months was forked off. Four months of grace period (Feb to June 2016) is
> already a double of that.

Yes, emergency hardforks are a different case as explained in BIP99's draft.
In any case, " we all agree that some kind of block size hardfork will
happen on June 2016" it's clearly false since I can find many
counter-examples besides myself.

> Also, if we could have zero grace period for softfork, why must we have a
> ultra-long period for hardfork? (Unless you also agree to have an 1-year
> grace period for softfork. I don't buy the "softfork is safer than hardfork"
> theory. The recent BIP66 fork has clearly shown why it is wrong:
> non-upgrading full nodes are not full nodes)

I don't think giving 1 year for "everybody in the world" to upgrade is
an "ultra-long" period.
I'm proposing 5 years for the hardfork proposed in bip99.
I do think softforks are safer than hardforks, that doesn't mean
softforks don't have serious risks as well.

> The problem is many people won't update until they must do so. So 4 months
> or 1 year make little difference

I disagree with this conclusion as well (it doesn't follow from the
first sentence, non sequitur).