From: "Russell O'Connor" <roconnor@blockstream•io>
To: Luke Dashjr <luke@dashjr•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees
Date: Sat, 13 May 2017 00:23:41 -0400 [thread overview]
Message-ID: <CAMZUoKnzV9faJ+mBTTzTre05Ejwnx3tC4ozbiPoPUfS+7GLMTQ@mail.gmail.com> (raw)
In-Reply-To: <201705121922.57445.luke@dashjr.org>
[-- Attachment #1: Type: text/plain, Size: 2223 bytes --]
I recall chatting about this idea recently and my conclusion was the same
as Peter Todd's conclusion: this will just encourage miners to false signal
readiness with undermines both BIP 9 and BIP 8.
I felt that rather than using script system for this construction, it would
be better to use the transaction version number instead by soft-forking in
a rule that says when the most significant bits of a transaction version
are 001 then the transaction can only be included in blocks whose lower 29
version bits are set at the same position as the lower 29 version bits set
in the transaction version.
That is to say, if we have block version blkVersion and transaction version
txVersion, we soft fork in a rule that requires that
(txVersion & 0xe0000000 != 0x020000000) || ((blkVersion & 0xe0000000 =
0x020000000) && (blkVersion & txVersion = txVersion))
While I think that making use of the transaction version number is superior
to adding an opcode, because it doesn't interfere with caching of script
validity and because it doesn't use any more transaction space by making
use of the otherwise useless transaction version number, I still think it
is a bad proposal.
On Fri, May 12, 2017 at 3:22 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> I've written a new BIP draft for OP_CHECKBLOCKVERSION to allow the
> community
> to put economic pressure on miners to deploy softforks without the extreme
> of
> a UASF.
>
> https://github.com/luke-jr/bips/blob/bip-cbv/bip-cbv.mediawiki
>
> Due to the potential for miners to maliciously block this softfork, it is
> suggested that we deploy it using BIP 8 to ensure it eventually activates
> even
> if encountering hostility.
>
> This is intended to be an alternative to BIP 8 in the long term.
> It is NOT intended to make BIP 148 obsolete, given the timeframes involved.
>
> An implementation is available (based on top of BIP 115's implementation):
>
> https://github.com/luke-jr/bitcoin/compare/cbah...luke-
> jr:checkblockversion
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 3153 bytes --]
next prev parent reply other threads:[~2017-05-13 4:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-12 19:22 Luke Dashjr
2017-05-12 22:17 ` ZmnSCPxj
2017-05-12 22:22 ` Peter Todd
2017-05-13 0:49 ` Luke Dashjr
2017-05-13 3:26 ` Eric Voskuil
2017-05-13 3:54 ` ZmnSCPxj
2017-05-13 5:36 ` Eric Voskuil
2017-05-13 5:45 ` Luke Dashjr
2017-05-13 6:43 ` Eric Voskuil
2017-05-13 12:48 ` Peter Todd
2017-05-13 16:42 ` Luke Dashjr
2017-05-13 4:23 ` Russell O'Connor [this message]
2017-05-13 5:26 ` Luke Dashjr
2017-05-13 17:11 ` Russell O'Connor
2017-05-15 1:14 ` Rusty Russell
2017-05-20 5:05 ` Anthony Towns
2017-05-14 12:18 ` ZmnSCPxj
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=CAMZUoKnzV9faJ+mBTTzTre05Ejwnx3tC4ozbiPoPUfS+7GLMTQ@mail.gmail.com \
--to=roconnor@blockstream$(echo .)io \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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