Discussion:
[bitcoin-dev] BIP: Block signal enforcement via tx fees
Luke Dashjr via bitcoin-dev
2017-05-12 19:22:56 UTC
Permalink
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
Peter Todd via bitcoin-dev
2017-05-12 22:22:14 UTC
Permalink
Post by Luke Dashjr via bitcoin-dev
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.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
Luke Dashjr via bitcoin-dev
2017-05-13 00:49:33 UTC
Permalink
Post by Peter Todd via bitcoin-dev
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.
Post by Peter Todd via bitcoin-dev
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.
Post by Peter Todd via bitcoin-dev
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?
Post by Peter Todd via bitcoin-dev
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
Eric Voskuil via bitcoin-dev
2017-05-13 03:26:08 UTC
Permalink
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
Post by Luke Dashjr via bitcoin-dev
Post by Peter Todd via bitcoin-dev
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.
Post by Peter Todd via bitcoin-dev
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.
Post by Peter Todd via bitcoin-dev
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?
Post by Peter Todd via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Luke Dashjr via bitcoin-dev
2017-05-13 05:45:24 UTC
Permalink
Post by Eric Voskuil via bitcoin-dev
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.
Post by Eric Voskuil via bitcoin-dev
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.
Post by Eric Voskuil via bitcoin-dev
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
Eric Voskuil via bitcoin-dev
2017-05-13 06:43:59 UTC
Permalink
Post by Luke Dashjr via bitcoin-dev
Post by Eric Voskuil via bitcoin-dev
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.
Post by Luke Dashjr via bitcoin-dev
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.
Post by Luke Dashjr via bitcoin-dev
Post by Eric Voskuil via bitcoin-dev
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.
Post by Luke Dashjr via bitcoin-dev
Post by Eric Voskuil via bitcoin-dev
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.
Post by Luke Dashjr via bitcoin-dev
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?
Post by Luke Dashjr via bitcoin-dev
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
ZmnSCPxj via bitcoin-dev
2017-05-13 03:54:50 UTC
Permalink
Good morning,
Post by Eric Voskuil via bitcoin-dev
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.
Post by Eric Voskuil via bitcoin-dev
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
Eric Voskuil via bitcoin-dev
2017-05-13 05:36:43 UTC
Permalink
Post by ZmnSCPxj via bitcoin-dev
Good morning,
Post by Eric Voskuil via bitcoin-dev
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.
Post by ZmnSCPxj via bitcoin-dev
Post by Eric Voskuil via bitcoin-dev
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
Peter Todd via bitcoin-dev
2017-05-13 12:48:48 UTC
Permalink
Post by Luke Dashjr via bitcoin-dev
Post by Peter Todd via bitcoin-dev
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.
Post by Luke Dashjr via bitcoin-dev
Post by Peter Todd via bitcoin-dev
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"
Post by Luke Dashjr via bitcoin-dev
Post by Peter Todd via bitcoin-dev
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.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
Luke Dashjr via bitcoin-dev
2017-05-13 16:42:44 UTC
Permalink
Post by Peter Todd via bitcoin-dev
Post by Luke Dashjr via bitcoin-dev
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.
ZmnSCPxj via bitcoin-dev
2017-05-12 22:17:30 UTC
Permalink
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
Russell O'Connor via bitcoin-dev
2017-05-13 04:23:41 UTC
Permalink
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 <
Post by Luke Dashjr via bitcoin-dev
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.
https://github.com/luke-jr/bitcoin/compare/cbah...luke-
jr:checkblockversion
Luke
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Luke Dashjr via bitcoin-dev
2017-05-13 05:26:58 UTC
Permalink
Post by Russell O'Connor via bitcoin-dev
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.
Post by Russell O'Connor via bitcoin-dev
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...
Post by Russell O'Connor via bitcoin-dev
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
Russell O'Connor via bitcoin-dev
2017-05-13 17:11:27 UTC
Permalink
Post by Luke Dashjr via bitcoin-dev
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
Post by Luke Dashjr via bitcoin-dev
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.
Rusty Russell via bitcoin-dev
2017-05-15 01:14:13 UTC
Permalink
Post by Russell O'Connor via bitcoin-dev
Post by Luke Dashjr via bitcoin-dev
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).
Post by Russell O'Connor via bitcoin-dev
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.
Anthony Towns via bitcoin-dev
2017-05-20 05:05:43 UTC
Permalink
Post by Luke Dashjr via bitcoin-dev
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

ZmnSCPxj via bitcoin-dev
2017-05-14 12:18:18 UTC
Permalink
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.

--

Also, this invites an inverse logic:

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

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

I think, your proposal allows an economic actor to pay fees if the miner is explicitly not signaling. This is supposed to allow a vote against a particular softfork.

Thus, it should also be possible to allow to vote against a softfork.

But in any case, I think, it's better to pay on activation or failure to activate, rather than mere signalling, as signalling is not the goal. Activation, or rejection of activation, is the goal.

Regards,
ZmnSCPxj
Loading...