public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Luke Dashjr <luke@dashjr.org>
To: "Russell O'Connor" <roconnor@blockstream.io>
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 05:26:58 +0000	[thread overview]
Message-ID: <201705130526.59467.luke@dashjr.org> (raw)
In-Reply-To: <CAMZUoKnzV9faJ+mBTTzTre05Ejwnx3tC4ozbiPoPUfS+7GLMTQ@mail.gmail.com>

On Saturday 13 May 2017 4:23:41 AM Russell O'Connor wrote:
> 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 already explained why this isn't the case: If we're comparing MASF to 
MASF+CBV, then I agree. But MASF is not necessarily always on the table, so 
the comparison where this becomes relevant is MASF+CBV vs UASF.

> 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.

Versionbits change/lose their meaning after the deployment timeout. For this 
reason, the timeout must be specified so the check is skipped when that 
occurs.

Also, doing it the way you describe would fail to enforce that BIP9 is 
actually in use for the block version; you could simply add that as an 
additional condition, but it seems pretty hacky since you wouldn't be able to 
upgrade versionbits anymore...

> 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

Script validity can still be cached with this: you would always allow the 
opcode to succeed at evaluation-time, and simply store the criteria checked 
separately. Then it would behave effectively the same as using the transaction 
version number.

Luke


  reply	other threads:[~2017-05-13  5:27 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-12 19:22 [bitcoin-dev] BIP: Block signal enforcement via tx fees 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
2017-05-13  5:26   ` Luke Dashjr [this message]
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=201705130526.59467.luke@dashjr.org \
    --to=luke@dashjr.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=roconnor@blockstream.io \
    /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