[bitcoin-dev] BIP: Block signal enforcement via tx fees

[bitcoin-dev] BIP: Block signal enforcement via tx fees

[Luke Dashjr]

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

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

[ZmnSCPxj]

[-- Attachment #1: Type: text/plain, Size: 419 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 518 bytes --]

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1378 bytes --]

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.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

[Luke Dashjr]

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

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

[Eric Voskuil]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCAAGBQJZFnzNAAoJEDzYwH8LXOFOlMsH/2Li7lDTr57EC2mSt4BuCf3Q
Q1sx21CBumm6OQKMxd207wgXTaxVJVmrGPXfJ6ZW8Bf+2tMKgc/LsZfzXdEo5+Fx
iTkdgJeW8QbKiEGzOFKMxWXH9jyCnd0WcDnKw/v7WqUhYfy2c9wz9RzCMY5iJqph
xd2+DeiEIjXIvE+l2TXGwjnB8Wp41QeY0I98kG3HHwNvNREbbGS/BjtLj5+eBygU
m+6dxkJoEttms31F47WFoZRzN7u5pe3BY5kDfZdVkbG7MOomSYwlhMvR3PtA1wrz
FeAUcHpp9MPj+qgHGwAGMfJiG/5WsVSrl/dJTm68zPOdwH60fMNNT/Srfbj1Ty8=
=9Xik
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

[ZmnSCPxj]

[-- Attachment #1: Type: text/plain, Size: 1435 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1834 bytes --]

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

[Russell O'Connor]

[-- 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 --]

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

[Luke Dashjr]

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

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

[Eric Voskuil]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCAAGBQJZFptnAAoJEDzYwH8LXOFOs34IAIciCyrn7FMq7leiQ6jAvr3g
sW9YRQ403IJd9BiBj3lI6xpsxtJ4zezkU2AFZUTf9X6AoIX/UJtPb8clb4RIpicf
ACK+iec4YM+15kgPcLyLij3aALvNNCNQ+XuXeHT1bHqfukP+bc/DBAnm48qGvW9o
ugRIFFWqtt8FB9MAh/VM6SsfaQc3D8hk6Dh3SyEVzohkrgWpRVQKNGD/FYY8odCA
8KPo/R3jrgO6JNR0EGxR3SatuKLYUgMcl3n63fanAOh8ESHGHHiP0SEpYoG3wOCt
eAyEcPI4SezJHBjJWcsPe0hhLg0HkvFaLwQe8tGHXrCzsZ18QTNBA0h9npWqqi4=
=LKcb
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

[Luke Dashjr]

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

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

[Eric Voskuil]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCAAGBQJZFqstAAoJEDzYwH8LXOFOsvsH/2aWlsfi5hB1IrnX1UBsMJl8
+R6BZE+d5C5uNkk6/yENHqwwgTv8yhOKav2Y7xYx/DedhVftX90h9CtdeKGgCS2H
cYNtoNauAvF2nlEMGGGcinLkYbS0dyQm07zwOI8gwuzbkslFGxLFClngFlFgMF4S
4/YCWvtRJ0O5dkrAZuKwG/7JQ1JNopbDTxssirA/OzwTGjq7BUv7INyR8nBbOp6I
xcrjq2bXja6Kxo08pr3+UrWc+0LO8fvX9z3rkm6USyin7TueS85gEUsk30h1Xng3
Al1QccJ9KKJ+iQKdGozeHD2OlTFC1zW2kZaWbhgxOewDlmf7cNwZXEUwfr4C4Hs=
=j5eo
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2565 bytes --]

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.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

[Luke Dashjr]

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.

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1793 bytes --]

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

[ZmnSCPxj]

[-- Attachment #1: Type: text/plain, Size: 2118 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2824 bytes --]

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

[Rusty Russell]

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.

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

[Anthony Towns]

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