Eric, that would be, I think, my sequencenumbers2 branch in which nSequence
is an explicit relative lock-time field (unless the most significant bit is
set). That has absolutely clear semantics. You should comment on #6312
where this is being discussed.
On Wed, Sep 16, 2015 at 7:23 PM, Eric Lombro
I'd rather replace the whole nSequence thing with an explicit relative locktime
with clear semantics...but I'm not going to fight this one too much.
On September 16, 2015 6:40:06 PM EDT, Btc Drak via bitcoin-dev
wrote:
>Where do we stand now on which sequencenumbers variation to use? We
>really
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
Where do we stand now on which sequencenumbers variation to use? We really
should make a decision now.
On Fri, Aug 28, 2015 at 12:32 AM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> So I've created 2 new repositories with changed rules regarding
> sequencenum
On Tue, Sep 15, 2015 at 12:10:37AM -0400, Jeff Garzik via bitcoin-dev wrote:
> Refactors however have a very real negative impact.
> bitcoin/bitcoin.git is not only the source tree in the universe.
> Software engineers at home, at startups, and at major companies are
> maintaining branches of their
I only have one "correction", included inline.
On 09/16/15 21:32, Jeff Garzik via bitcoin-dev wrote:
>
> During Scaling Bitcoin, Bitcoin Core committers and notable contributors
> got together and chatted about where a "greatest common denominator"
> type consensus might be. The following is a w
During Scaling Bitcoin, Bitcoin Core committers and notable contributors
got together and chatted about where a "greatest common denominator" type
consensus might be. The following is a without-attribution (Chatham House)
summary. This is my own personal summary of the chat; any errors are my
own
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
Jason Livesay via bitcoin-dev wrote:
> In order to keep the existing brand momentum, network, and business
> investment,
These are precisely the issues that the Bitcoin Development team SHOULD
NOT concern themselves with as they are not technical in nature.
> I believe the smoothest path forward i
19 matches
Mail list logo
