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 enforcement, but enforcement
happens anyway.
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 one retarget period in
>> which the remai
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 gon
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 bloc
Jorge Timón writes:
> On Sep 20, 2015 10:58 PM, "Rusty Russell" wrote:
>>
>> 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
On Sep 20, 2015 10:58 PM, "Rusty Russell" wrote:
>
> 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 discusse
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 discussion.
Thanks,
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 b
Tier Nolan via bitcoin-dev writes:
> On Wed, Sep 16, 2015 at 9:19 PM, Rusty Russell
> wrote:
>> You need a timeout: an ancient (non-mining, thus undetectable) node
>> should never fork itself off the network because someone reused a failed
>> BIP bit.
>>
>
> I meant if the 2nd bit was part of the
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
> they think are fine, but which aren't.
Jorge Timón via bitcoin-dev writes:
> 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".
Three years from drafting is reasonable. How many blocks is that? Hmm,
better make it 6 years of blocks ju
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.They might produce blocks that they
> t
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 over
> the optimal value
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 1
I understand your proposal, but I don't see what it accomplishes compared
to applying the new rule from the start (in your own blocks) and wait for
95% for consensus activation (which is my preference and it's much simpler
to implement).
What are the disadvantages of my approach? What are the advan
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 rely on that, some m
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. Enforcement wouldn't happ
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 the rule).
___
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"
On Wed, Sep 16, 2015 at 9:27 PM, Jorge Timón wrote:
> For enforcing new restrictions on your own blocks (thus at the policy
> level, not consensus) you don't need to wait for 75%. You can do it from
> the start (this way all miners setting the bit will enforce the new
> restrictions.
>
At 75%, yo
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 comply with the new rule.
Th
For enforcing new restrictions on your own blocks (thus at the policy
level, not consensus) you don't need to wait for 75%. You can do it from
the start (this way all miners setting the bit will enforce the new
restrictions.
On Sep 16, 2015 4:20 PM, "Rusty Russell via bitcoin-dev" <
bitcoin-dev@lis
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 ''defined'', and can be ''locked-in'', ''activated
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 consid
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,
>
> Thos
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
26 matches
Mail list logo
