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 22:38:20 +0200 [thread overview]
Message-ID: <CABm2gDppFsTbh3JtdJkAkV_GzKFYAOLiEmtQPCgS9O6b7eWFuw@mail.gmail.com> (raw)
In-Reply-To: <CAE-z3OXATJ6HGKqU=vxc8k-yCMAMwXiWQJxvO3D_O256_ZODtw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]
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" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> On Wed, Sep 16, 2015 at 9:27 PM, Jorge Timón <jtimon@jtimon.cc> 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%, you have a pretty solid super-majority.
>
> You can safely reject blocks that have the bit set but are invalid
> according to the new rule (as long as everyone who sets the bit does it
> too).
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 1850 bytes --]
next prev parent reply other threads:[~2015-09-16 20:38 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 [this message]
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
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=CABm2gDppFsTbh3JtdJkAkV_GzKFYAOLiEmtQPCgS9O6b7eWFuw@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