Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

On 9/29/2015 7:05 PM, Rusty Russell wrote: Tom Harding via bitcoin-dev writes: With a simple delay, you can have the embarrassing situation where support falls off during the delay period and there is far below threshold support just moments prior to

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

Tom Harding via bitcoin-dev writes: > On 9/13/2015 11:56 AM, Rusty Russell via bitcoin-dev wrote: >> '''Success: Activation Delay''' >> The consensus rules related to ''locked-in'' soft fork will be enforced in >> the second retarget period; ie. there is a

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

On 9/13/2015 11:56 AM, Rusty Russell via bitcoin-dev wrote: '''Success: Activation Delay''' The consensus rules related to ''locked-in'' soft fork will be enforced in the second retarget period; ie. there is a one retarget period in which the remaining 5% can upgrade. At the that activation

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

I say keep it simple. If the 75% threshold is hit, then support suddenly drops off below 50%, "meh" -- there will be a big ruckus, everybody will freak out, and miners will refuse to build big blocks because they'll worry that they'll get orphaned. Adding more complexity for a case that ain't

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

Jorge Timón writes: > I disagree with the importance of this concern and old soft/hardforks will > replace this activation mechanism with height, so that's an argument in > favor of using the height from the start. This is "being discussed" in a > thread branched from bip99's

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

I disagree with the importance of this concern and old soft/hardforks will replace this activation mechanism with height, so that's an argument in favor of using the height from the start. This is "being discussed" in a thread branched from bip99's discussion. Anyway, is this proposing to use the

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

Tier Nolan via bitcoin-dev writes: > The advantage of enforcing the rule when 75% is reached (but only for > blocks with the bit set) is that miners get early notification that they > have implemented the rule incorrectly.They might produce blocks that >

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

On Wed, Sep 16, 2015 at 11:52 PM, Eric Lombrozo wrote: > The exact numbers (95% vs. 75% etc) don't need to be completely specified > to start working on an implementation. What really matters for now is > defining the states and trigger mechanisms. I'd rather we not argue

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

On Thu, Sep 17, 2015 at 12:38 PM, Tier Nolan via bitcoin-dev wrote: > The advantage of enforcing the rule when 75% is reached (but only for blocks > with the bit set) is that miners get early notification that they have > implemented the rule incorrectly.

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

Rusty, I think you've covered all the issues discussed now. +1 for submitting to BIPs repo to get an official number. Are you planning to write the implementation? On Sun, Sep 13, 2015 at 7:56 PM, Rusty Russell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi all, > >

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

On Sun, Sep 13, 2015 at 7:56 PM, Rusty Russell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > '''States''' > With every softfork proposal we associate a state BState, which begins > at ''defined'', and can be ''locked-in'', ''activated'', > or ''failed''. Transitions are

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

On Wed, Sep 16, 2015 at 9:19 PM, Rusty Russell wrote: > I couldn't see a use for it, since partial enforcement of a soft fork is > pretty useless. > It isn't useful for actually using the feature, but some miners might set the bit but not actually create blocks that

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

No, 95% is safer and will produce less orphaned blocks. 0%is fine to do it in your own blocks. I agree on using height vs time. Rusty, what do you mean by being easier for bip writers? How is writing "block x" any harder than writing "date y". On Sep 16, 2015 4:32 PM, "Tier Nolan via bitcoin-dev"

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

On Wed, Sep 16, 2015 at 9:38 PM, Jorge Timón wrote: > No, 95% is safer and will produce less orphaned blocks. > The point of the 75% is just as a test run. Enforcement wouldn't happen until 95%. At 75%, if someone sets the bit, then they should be creating valid blocks (under

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

Tier Nolan via bitcoin-dev writes: > On Sun, Sep 13, 2015 at 7:56 PM, Rusty Russell via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> '''States''' >> With every softfork proposal we associate a state BState, which begins >> at

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

On Wed, Sep 16, 2015 at 9:54 PM, Jorge Timón wrote: > > On Sep 16, 2015 4:49 PM, "Tier Nolan via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > At 75%, if someone sets the bit, then they should be creating valid > blocks (under the rule). > > You shouldn't

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

On Sep 16, 2015 4:49 PM, "Tier Nolan via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > On Wed, Sep 16, 2015 at 9:38 PM, Jorge Timón wrote: >> >> No, 95% is safer and will produce less orphaned blocks. > > The point of the 75% is just as a test run.

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

The exact numbers (95% vs. 75% etc) don't need to be completely specified to start working on an implementation. What really matters for now is defining the states and trigger mechanisms. I'd rather we not argue over the optimal values for supermajority requirement at this point. On September

[bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

Hi all, Those who've seen the original versionbits bip, this adds: 1) Percentage checking only on retarget period boundaries. 2) 1 retarget period between 95% and activation. 3) A stronger suggestion for timeout value selection. https://gist.github.com/rustyrussell/47eb08093373f71f87de