From: "Jorge Timón" <jtimon@jtimon.cc>
To: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.
Date: Wed, 16 Sep 2015 23:03:43 +0200 [thread overview]
Message-ID: <CABm2gDphLRQ6huhxvcx1YvbsmaBHA_sk6MEZF+hgdxoC472P+w@mail.gmail.com> (raw)
In-Reply-To: <CAE-z3OUyNpmG5uhSCExf39zmmB-b9xDrn+gkp3UFeg7M3G8E5g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]
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 advantages of yours?
On Sep 16, 2015 4:57 PM, "Tier Nolan via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> On Wed, Sep 16, 2015 at 9:54 PM, Jorge Timón <jtimon@jtimon.cc> 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 may start applying the restrictions in
>> their own blocks at 0% and others only at 90%. Until it becomes a consensus
>> rule it is just part of the standard policy (and we shouldn't rely on nodes
>> following the standard policy).
>>
>
> It would be a consensus rule. If >75% of the blocks in the last 2016
> window have the bit set, then reject all blocks that have the bit set and
> fail to meet the rule.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 2271 bytes --]
next prev parent reply other threads:[~2015-09-16 21:03 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-13 18:56 [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay Rusty Russell
2015-09-16 15:53 ` Btc Drak
2015-09-16 17:53 ` Tier Nolan
2015-09-16 20:19 ` Rusty Russell
2015-09-16 20:27 ` Jorge Timón
2015-09-16 20:32 ` Tier Nolan
2015-09-16 20:38 ` Jorge Timón
2015-09-16 20:48 ` Tier Nolan
2015-09-16 20:54 ` Jorge Timón
2015-09-16 20:57 ` Tier Nolan
2015-09-16 21:03 ` Jorge Timón [this message]
2015-09-16 22:52 ` Eric Lombrozo
2015-09-17 10:38 ` Tier Nolan
2015-09-17 13:59 ` Jorge Timón
2015-09-17 21:57 ` Rusty Russell
2015-09-17 22:00 ` Rusty Russell
2015-09-19 5:04 ` Jorge Timón
2015-09-20 3:56 ` Rusty Russell
2015-09-21 8:24 ` Jorge Timón
2015-09-21 10:34 ` Rusty Russell
2015-09-16 20:30 ` Tier Nolan
2015-09-18 1:19 ` Rusty Russell
2015-09-23 18:33 ` Tom Harding
2015-09-23 19:01 ` Gavin Andresen
2015-09-30 2:05 ` Rusty Russell
2015-09-30 23:41 ` Tom Harding
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABm2gDphLRQ6huhxvcx1YvbsmaBHA_sk6MEZF+hgdxoC472P+w@mail.gmail.com \
--to=jtimon@jtimon.cc \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=tier.nolan@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox