BIP: Block signal enforcement via tx fees

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

Good morning Luke,

Minor editorial nitpick, this paragraph is repeated, maybe one of these should be Testnet?

For Bitcoin '''mainnet''', the BIP8 '''starttime''' will be TBD (Epoch timestamp TBD) and BIP8 '''timeout''' will be TBD (Epoch timestamp TBD).

For Bitcoin '''mainnet''', the BIP8 '''starttime''' will be TBD (Epoch timestamp TBD) and BIP8 '''timeout''' will be TBD (Epoch timestamp TBD).

Regards, ZmnSCPxj

On Fri, May 12, 2017 at 07:22:56PM +0000, Luke Dashjr via bitcoin-dev 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

I strongly disagree with this proposal.

nVersion signaling is already technically unenforceable, in the sense that we don't have good ways of ensuring miners actually adopt the rules they're claiming to signal. Equally, it's users who ultimately adopt rules, not miners, and attempting to pay miners to signal certain bits will further confuse this point.

Quite likely the outcome of users trying to anonymously pay anonymous miners to signal certain bits will be the complete breakdown of the honesty of the nVersion signalling system, currently enforced only by "gentlemans agreement".

A more productive direction would be a direct coin-owner signalling process, with users taking action based on what provable coin-ownership has signalled.

Also, as an aside, this "specification" again shows the inadequacy and unreadability of English language specifications. I'd strongly suggest you delete it and instead mark the "reference implementation" as the specification.

On Friday 12 May 2017 10:22:14 PM Peter Todd wrote:

> nVersion signaling is already technically unenforceable, in the sense that
> we don't have good ways of ensuring miners actually adopt the rules
> they're claiming to signal. Equally, it's users who ultimately adopt
> rules, not miners, and attempting to pay miners to signal certain bits
> will further confuse this point.

This BIP doesn't change that. Enforcement remains primarily by users.

> Quite likely the outcome of users trying to anonymously pay anonymous
> miners to signal certain bits will be the complete breakdown of the
> honesty of the nVersion signalling system, currently enforced only by
> "gentlemans agreement".

You assume users will pay for signalling of softforks prematurely. So long as it waits until deployment of the softfork is widespread, this risk is minimal. At worst, it creates risks similar to a UASF. So long as UASF is the alternative, this way seems strictly better.

> Also, as an aside, this "specification" again shows the inadequacy and
> unreadability of English language specifications. I'd strongly suggest you
> delete it and instead mark the "reference implementation" as the
> specification.

How so?

On Friday 12 May 2017 10:17:30 PM ZmnSCPxj wrote:

> Minor editorial nitpick, this paragraph is repeated, maybe one of these
> should be Testnet?
>
> For Bitcoin '''mainnet''', the BIP8 '''starttime''' will be TBD (Epoch
> timestamp TBD) and BIP8 '''timeout''' will be TBD (Epoch timestamp TBD).
>
> For Bitcoin '''mainnet''', the BIP8 '''starttime''' will be TBD (Epoch
> timestamp TBD) and BIP8 '''timeout''' will be TBD (Epoch timestamp TBD).

Fixed, thanks.

Luke

If people want to influence the decisions of miners, all they need to do is mine.

I do not see why any person would want to pay, and then trust, another to mine accordingly. Each person can mine and attain their level of influence. This not only avoids the side payment, but earns the person money.

There is nothing inherently wrong with paying people to run nodes or signal "readiness", but there is no reason whatsoever to consider these ideas beneficial from a personal/economic or security/decentralization standpoint.

If you are not running a node you are not part of the economic consensus. If you are not mining you have no say in transaction ordering. The "solution" is both obvious and necessary to secure Bitcoin .

If a person does not want to bother then he/she clearly does not have a strong opinion. As developers we should be focused on reducing the complexities of mining and of validation, not finding ways for people to avoid participating in these necessarily distributed roles.

e

On 05/12/2017 05:49 PM, Luke Dashjr via bitcoin-dev wrote:

> On Friday 12 May 2017 10:22:14 PM Peter Todd wrote:
>> nVersion signaling is already technically unenforceable, in the
>> sense that we don't have good ways of ensuring miners actually
>> adopt the rules they're claiming to signal. Equally, it's users
>> who ultimately adopt rules, not miners, and attempting to pay
>> miners to signal certain bits will further confuse this point.
>
> This BIP doesn't change that. Enforcement remains primarily by
> users.
>
>> Quite likely the outcome of users trying to anonymously pay
>> anonymous miners to signal certain bits will be the complete
>> breakdown of the honesty of the nVersion signalling system,
>> currently enforced only by "gentlemans agreement".
>
> You assume users will pay for signalling of softforks prematurely.
>  So long as it waits until deployment of the softfork is
> widespread, this risk is minimal. At worst, it creates risks
> similar to a UASF. So long as UASF is the alternative, this way
> seems strictly better.
>
>> Also, as an aside, this "specification" again shows the
>> inadequacy and unreadability of English language specifications.
>>  I'd strongly suggest you delete it and instead mark the
>> "reference implementation" as the specification.
>
> How so?
>
> On Friday 12 May 2017 10:17:30 PM ZmnSCPxj wrote:
>> Minor editorial nitpick, this paragraph is repeated, maybe one of
>> these should be Testnet?
>>
>> For Bitcoin '''mainnet''', the BIP8 '''starttime''' will be TBD
>> (Epoch timestamp TBD) and BIP8 '''timeout''' will be TBD (Epoch
>> timestamp TBD).
>>
>> For Bitcoin '''mainnet''', the BIP8 '''starttime''' will be TBD
>> (Epoch timestamp TBD) and BIP8 '''timeout''' will be TBD (Epoch
>> timestamp TBD).
>
> Fixed, thanks.
>
> Luke _______________________________________________ bitcoin-dev
> mailing list bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

Good morning,

>I do not see why any person would want to pay, and then trust, another
>to mine accordingly. Each person can mine and attain their level of
>influence. This not only avoids the side payment, but earns the person
>money.

The problem, is that, the rate of conversion of Bitcoin-> hashrate is different for different people.

For some, it's very cheap to convert Bitcoin -> hashrate. For others, it's very expensive. The reason, is the large difference in electricity rates depending on country.

It's all very well for those who can get electricity cheaply. But, for some, it is not.

Thus, paying someone with better Bitcoin->hashrate conversion via fees such as these is more economically logical, than to suffer a lower Bitcoin->hashrate conversion.

>If a person does not want to bother then he/she clearly does not have
>a strong opinion. As developers we should be focused on reducing the
>complexities of mining and of validation, not finding ways for people
>to avoid participating in these necessarily distributed roles.

It is also, very obviously, clear that you are operating under very strange assumptions, that all people are already equal somehow, or that someone who is paid x10 more is strictly superior, even though skill-wise and ability-wise, they are the same, and the one paid less is simply suffering due to the country where he or she is born in, through no fault of their own.

Regards, ZmnSCPxj

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
>

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

On 05/12/2017 08:54 PM, ZmnSCPxj wrote:

> Good morning,
>
>> I do not see why any person would want to pay, and then trust,
>> another to mine accordingly. Each person can mine and attain
>> their level of influence. This not only avoids the side payment,
>> but earns the person money.
>
> The problem, is that, the rate of conversion of Bitcoin-> hashrate
> is different for different people.
>
> For some, it's very cheap to convert Bitcoin -> hashrate.  For
> others, it's very expensive.  The reason, is the large difference
> in electricity rates depending on country.
>
> It's all very well for those who can get electricity cheaply.  But,
> for some, it is not.
>
> Thus, paying someone with better Bitcoin->hashrate conversion via
> fees such as these is more economically logical, than to suffer a
> lower Bitcoin->hashrate conversion.

Despite the tedious explanation of absolute advantage, this is simply an argument for all people to pay one person to mine, as there is presumably always one person who will be able to mine more efficiently than all others.

The argument fails to recognize that mining for one's self may (or may not) result in a net loss, but donating to a miner in the hope of some action is comparatively a total loss. One is an expense in exchange for the intended social outcome, and the other is payment for representative government.

And in this form of representative government that you propose, if we assume that miners are somehow bound to honor the payments (votes), how are the votes distributed? Is this supposed to be democratic in the sense of one person one vote? Your argument below is clearly based on that idea. However the result would be very different. The wealthier would of course exert the greater influence. So the idea fails by its own standard.

>> If a person does not want to bother then he/she clearly does not
>> have a strong opinion. As developers we should be focused on
>> reducing the complexities of mining and of validation, not
>> finding ways for people to avoid participating in these
>> necessarily distributed roles.
>
> It is also, very obviously, clear that you are operating under
> very strange assumptions, that all people are already equal
> somehow, or that someone who is paid x10 more is strictly superior,
> even though skill-wise and ability-wise, they are the same, and the
> one paid less is simply suffering due to the country where he or
> she is born in, through no fault of their own.

You are making a political argument wrapped in appeal to emotion. Both are pointless in this context.

e

On Saturday 13 May 2017 3:26:08 AM Eric Voskuil wrote:

> If people want to influence the decisions of miners, all they need to
> do is mine.

Most people cannot mine except at a huge expense (profit is limited to few people via monopoly and electric costs). But more importantly, the profits from every miner you buy will go to pay for Bitmain growing their arsenal more than enough to offset your influence.

Mining is simply broken at this point.

> There is nothing inherently wrong with paying people to run nodes or
> signal "readiness", but there is no reason whatsoever to consider
> these ideas beneficial from a personal/economic or
> security/decentralization standpoint.

Running a node and mining are two very different things.

> The argument fails to recognize that mining for one's self may (or may
> not) result in a net loss, but donating to a miner in the hope of some
> action is comparatively a total loss. One is an expense in exchange
> for the intended social outcome, and the other is payment for
> representative government.
>
> And in this form of representative government that you propose, if we
> assume that miners are somehow bound to honor the payments (votes), ...

First of all, this isn't donating to miners, but forbidding them from mining your transaction (and thereby collecting your transaction fee) unless they signal for the softfork.

Secondly, your argument here assumes miners are a government or control Bitcoin in some way. This is not correct. Miners are entrusted with enforcement of softforks *for old nodes only*, and therefore given the ability to trigger activation of the new rules via signalling. But entrusting them with this is NOT done by the system itself, but by the users, whose updated nodes are the primary mechanism for enforcing softforks. So miners are in fact already bound to honour the wishes of the greater economy, and their refusal to do so is an attack on the network.

Luke

On 05/12/2017 10:45 PM, Luke Dashjr wrote:

> On Saturday 13 May 2017 3:26:08 AM Eric Voskuil wrote:
>> If people want to influence the decisions of miners, all they
>> need to do is mine.
>
> Most people cannot mine except at a huge expense (profit is limited
> to few people via monopoly and electric costs). But more
> importantly, the profits from every miner you buy will go to pay
> for Bitmain growing their arsenal more than enough to offset your
> influence.

You seem to be suggesting that in order to decentralize mining nobody should mine. I'm having a hard time making sense out of that.

> Mining is simply broken at this point.

So maybe you are just saying that nobody should mine because it's a zero sum game that one miner will always win and therefore we should not push up the hash rate by trying to compete because the same miner just makes more money on the hardware. Apparently it is economically impossible for anyone else to compete in hardware as well.

I agree that there is a serious problem of mining centralization (and economic/validation centralization). If these problems are not solved Bitcoin will fail. It will rise again, with people a little wiser, but the disruption will be unfortunate for many.

I don't want to see that, so I tend to not advocate for solutions that run counter to the security model. Many people must mine, there is no way around it. And if people want a say with respect to mining, they should mine. As a developer I would rather work toward fixing that problem than putting a band-aid over it that basically tells people that the way they get their say is by donating to the big mining personality of their choice.

>> There is nothing inherently wrong with paying people to run nodes
>> or signal "readiness", but there is no reason whatsoever to
>> consider these ideas beneficial from a personal/economic or
>> security/decentralization standpoint.
>
> Running a node and mining are two very different things.

No, really?

If it wasn't clear, I was relating two sets of proposals. One aims to find ways to fund node operation and the other aims to fund miner signaling. The former fails to understand the economics and security model of full node operation and the latter fails to understand that distributed mining is as essential to Bitcoin survival as distributed validation.

>> The argument fails to recognize that mining for one's self may
>> (or may not) result in a net loss, but donating to a miner in the
>> hope of some action is comparatively a total loss. One is an
>> expense in exchange for the intended social outcome, and the
>> other is payment for representative government.
>>
>> And in this form of representative government that you propose,
>> if we assume that miners are somehow bound to honor the payments
>> (votes), ...
>
> First of all, this isn't donating to miners, but forbidding them
> from mining your transaction (and thereby collecting your
> transaction fee) unless they signal for the softfork.

I assumed that people understand how markets work. Miners compete for fees. By eliminating a subset of potential sellers (currently by ~70%) the buyer raises his own price. Presumably the price is raised even further by increasing the size of the transaction. This is either a donation to the cause or a purchase of the signal, depending on how you want to describe it (all donations are purchases of a sort).

So there is a cost increase that could alternatively be incurred by mining (i.e. assuming a lossy operation). If one is going to spend money on influencing mining one might as well not do it in a way that contributes to centralization while training people to rely on it.

> Secondly, your argument here assumes miners are a government or
> control Bitcoin in some way. This is not correct.

Miners absolutely "control Bitcoin in some way" - that is their purpose. They control the ordering of transactions, and with sufficient hash power can double-spend and therefore make the network unusable. Why would you bother to make me type this?

> So miners are in fact already bound to honour the wishes of the
> greater economy, and their refusal to do so is an attack on the
> network.

Absolute nonsense, a miner incurs no obligation to the "greater economy". He is offering a service in voluntary trade. He is likely to do what it takes to spend his coinbase, assuming he wants to. This gives the economy strong economic control over his behavior. But nothing whatsoever obligates him to signal soft forks (or not optimize his operations).

Double spending is an attack, on the person who has been robbed. The state enforcing a patent is an attack, on the person against whom it is enforced. These are called attacks **because they are actually theft**. You are conflating normal operation (despite disagreement with some unmeasurable "wishes") with robbery.

e

On Sat, May 13, 2017 at 12:49:33AM +0000, Luke Dashjr wrote:

> On Friday 12 May 2017 10:22:14 PM Peter Todd wrote:
> > nVersion signaling is already technically unenforceable, in the sense that
> > we don't have good ways of ensuring miners actually adopt the rules
> > they're claiming to signal. Equally, it's users who ultimately adopt
> > rules, not miners, and attempting to pay miners to signal certain bits
> > will further confuse this point.
>
> This BIP doesn't change that. Enforcement remains primarily by users.

I'm not arguing that it changes that; I'm arguing that it further confuses the situation.

> > Quite likely the outcome of users trying to anonymously pay anonymous
> > miners to signal certain bits will be the complete breakdown of the
> > honesty of the nVersion signalling system, currently enforced only by
> > "gentlemans agreement".
>
> You assume users will pay for signalling of softforks prematurely. So long as
> it waits until deployment of the softfork is widespread, this risk is minimal.
> At worst, it creates risks similar to a UASF. So long as UASF is the
> alternative, this way seems strictly better.

I think you're assuming that the users paying for soft-fork signalling will represent an economic majority; that's not necessarily the case.

For example, if miners decide there's no downside to false signalling, they may take the extra fees provided by 1% of the users paying to signal a fork, while the other 99% don't participate, resulting in a situation where we have blocks violating the nVersion protocol, and an unknown % of that 99% rejecting those blocks. At best that'd be no worse than a UASF, and at wost you're wrecked the validity of the nVersion "gentlemans agreement"

> > Also, as an aside, this "specification" again shows the inadequacy and
> > unreadability of English language specifications. I'd strongly suggest you
> > delete it and instead mark the "reference implementation" as the
> > specification.
>
> How so?

Just read it: you have ten separate lines of dense English text describing something that could have been specified instead by ten lines of much more formally defined C++. In particular, note how many of those lines of English text refer to C++ code anyway, like the sentence "minimal-length 40-bit CScriptNum"

I don't want to have to learn another language - formally defined English that still fails to be formally defined - just to read Bitcoin's specification.

On Saturday 13 May 2017 12:48:48 PM Peter Todd wrote:

> > You assume users will pay for signalling of softforks prematurely. So
> > long as it waits until deployment of the softfork is widespread, this
> > risk is minimal. At worst, it creates risks similar to a UASF. So long
> > as UASF is the alternative, this way seems strictly better.
>
> I think you're assuming that the users paying for soft-fork signalling will
> represent an economic majority; that's not necessarily the case.

I'm assuming that if the economic majority hasn't consented to the softfork, at least as many users will make their transactions conditional on non- signalling.

On Sat, May 13, 2017 at 1:26 AM, Luke Dashjr <luke@dashjr•org> wrote:

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

To add a timeout a user can optionally bundle a pair of similar transactions. One with the transaction version bits set and a second with a locktime set. The effect is the same.

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

My formal condition does include a check for the block version (I've corrected the constants below):

(txVersion & 0xe0000000 != 0x200000000) || (*(blkVersion & 0xe0000000 =
0x200000000)* && (blkVersion & txVersion = txVersion))

Nothing here prevents upgrading versionbits AFAICT. Any txVersion that does not begin with 0b001 is unconditionally acceptable and available for further soft-forking.

Good morning Luke,

Considering the proposal as a whole, I think, it's a little imperfect.

The main problem, is that the end goal is activation, but what the opcode rewards is signalling.

Consider a miner who signals only if the number of non-signalling blocks in this retargeting time > 5% of 2016. Such a miner would still effectively block a softfork activation, while still has a chance (albeit reduced) of winning the transaction fees of the block-signalling-opcode, in proportion to the number of miners not signaling for a softfork or using a similar algorithm.

What we should reward should be activation.

How about an opcode which requires this stack (stack top at right)

<signature> <publickeyhash> <versionbit>

1. If the <versionbit> given is in state FAILED, then it checks if the given <signature> matches the given <publickeyhash>.

2. If the <versionbit> given is in state LOCKED_IN or ACTIVE, it checks if the given <signature> matches the block's coinbase transaction signature.

This creates an output which is refundable to the owner, if the softfork fails to activate, but which may be claimed by miners, if the softfork activates.

I don't know enough yet about Bitcoin's codebase to know if the above spec is actually workable.

But basically, I think we should create an assurance contract for activation of a softfork.

Russell O'Connor via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> writes:

> On Sat, May 13, 2017 at 1:26 AM, Luke Dashjr <luke@dashjr•org> wrote:
>
>> 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.
>>
>
> To add a timeout a user can optionally bundle a pair of similar
> transactions.  One with the transaction version bits set and a second with
> a locktime set.  The effect is the same.

I have a similar proposal to Russell; use tx nVersion. However, my subset is simpler, and uses fewer precious nVersion bits:

1. Top version 26 bits must be 1 (say)
2. Next bit indicates positive (must have bit set) or negative (must NOT
   have bit set).
3. Bottom 5 bits refer to which BIP8/9 bit we're talking about.

This only allows specifying a single bit, and only support BIP8/9-style signalling.

I believe we can skip the timeout: miners don't signal 100% either way anyway. If a BIP is in LOCKIN, wallets shouldn't set positive on that bit (this gives them two weeks). Similarly, if a BIP is close to FAILED, don't set positive on your tx. Wallets shouldn't signal until any bit until see some minimal chance it's accepted (eg. 1 in 20 blocks).

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

This is gentler on miners than a UASF flag day, and does offer some harder-to-game signalling from bitcoin users.

False signalling miners still have the 2 week LOCKIN period to upgrade, otherwise they can already lose money. You could argue they're *more* likely to upgrade with a signal that significant parts of the economy have done so.

Cheers, Rusty.

On Sat, May 13, 2017 at 01:11:27PM -0400, Russell O'Connor via bitcoin-dev wrote:

> On Sat, May 13, 2017 at 1:26 AM, Luke Dashjr <luke@dashjr•org> wrote:
> > 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.
> To add a timeout a user can optionally bundle a pair of similar transactions.
> One with the transaction version bits set and a second with a locktime set.
> The effect is the same.

Another approach to ensuring the timeout might be to simply use input height. ie:

  * if there is a BIP-9 soft-fork using bit N currently STARTED or
    LOCKED_IN phase. since the soft-fork is started, set the height of
    the first block after starttime as "S".

  * then a transaction is invalid in a block if:
     * the soft-fork has not timed out or activated
     * the block does not signal bit N
     * the transaction nversion does signal bit N (by whatever formula)
     * at least one input to the transaction has a height >= S

That's compatible with bit reuse: if a transaction designed to encourage soft-fork foo with bit 1 does not get mined by the time foo finishes (by timeout or success), then when soft-fork bar reaches STARTED phase while reusing bit 1, the old transaction can be mined by either signalling or non-signalling miners -- because all of the transaction inputs are prior to bar's block S, the invalidation rule doesn't apply for bar, and because foo has timed out or activated, it doesn't apply for foo either.

It means you can't directly use a bunch of old coins on their own to incentivise miner signalling -- you need to include a coin from after starttime. That doesn't seem terribly onerous though; and should be easily solvable by just providing a coinjoin API anyway. I think it's compatible with using bitcoin days destroyed as a weighting measure too, since only one of the coins needs to be relatively recent.

The above is a "fail-open" timeout rather than "fail-closed" -- if you signal for foo, but your transaction doesn't get mined because too few miners are signalling foo, and then foo fails to activate and times out, your transaction can then be mined by the miners that didn't signal. If this isn't what you want, double-spending should be fine: provide a double spend at market rates that doesn't require signalling directly to miners and their choice becomes "mine this thing now and get the fee directly" versus "hope no one else mines it now, and that I get the chance to mine the original higher fee transaction after activation, before anyone else does", so at least the economically-rational choice should be to mine the lower-fee double spend immediately. So it should be reasonable to offer a higher fee for signalling, without risking that non-signalling miners will be able to claim that high fee eventually.

I'm not sure the incentives about tying user-signalling for a soft-fork to miner signalling for a soft-fork are entirely sound; but if they are then just using nversion seems a lot more user-friendly than requiring script changes to me. In particular, it doesn't require any setup or teardown costs -- you don't have to get an input with a particular script encoded that you can then spend to signal, and you don't have to remember variations on output address when you want to spend a transaction that was signalling; likewise changes to wallets are pretty simple and don't have "you lost all your money" results if there's a bug. Well, the above timeout procedure requires getting a recent coin as "setup", but that's pretty trivial, at least.

Cheers, aj