Re: [bitcoin-dev] Moving towards user activated soft fork activation

Re: [bitcoin-dev] Moving towards user activated soft fork activation

[Chris Belcher]

I think UASF is a great idea for the reasons mentioned before that it
more closely matches the balance of powers in bitcoin, and that its much
more opt-in.

Many people are comparing an UASF fork with a hard fork. I disagree with
this view and I think there is a difference between the two kinds of
forks. The situation between hard and soft forks is reversed.

In a fork between segwit-invalid and segwit-valid after a UASF, if the
segwit-valid chain ever ends up with more work then the segwit-invalid
chain will be annihilated in a big re-organization as
non-segwit-enforcing nodes move to the segwit-valid chain. The less-work
chain will simply cease to exist.

Only a miner that recodes their software can initiate such a fork,
because segwit transactions are non-standard and won't be relayed by
default.

A closer situation is the accidental fork created soon after the BIP66
soft fork. The fork lasted a few blocks and did not mine any
transactions except the coinbase. It was annihilated with a monetary
loss to any miner that took part.


Here is an argument for why chain fork is unlikely to last long or be
created by a rational self-interested miner, assuming the bitcoin
economic majority even slightly enforces the UASF.

Because the segwit-invalid coins can be annihilated in this way and
segwit-valid coins cannot, segwit-invalid coins are more risky to hold
as an asset, all else equal.

A more risky asset has a lower price, all else equal. Because investors
demand higher risk premiums for holding it and also short sellers may
sell down the price in the hopes of making a profit if it's value goes
to zero.

In cryptocurrencies like bitcoin, hashpower follows price. This is very
clear from historical trends and the underlying economic forces.

A lower-hashrate chain will eventually be overtaken in work by a
higher-hashrate chain.

Therefore, the segwit-invalid chain will be annihilated sooner or later
if the price of its coin is higher.

Of course as the old saying goes markets can stay irrational longer than
we can stay solvent, which is why I think UASF should only go ahead if
we're sure that a big part of the economic majority will enforce it.
This will make the value and liquidity of the segwit-invalid chain very
low and make the annihilating re-organization happen faster.
User-activated means it _must_ be done by the users of bitcoin.

Re: [bitcoin-dev] Moving towards user activated soft fork activation

[David Vorick]

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

I also think that the UASF is a good idea. Hashrate follows coin price. If
the UASF has the higher coin price, the other chain will be annihilated. If
the UASF has a lower coin price, the user activated chain can still exist
(though their coins can be trivially stolen on the majority chain).

The success of the UASF depends entirely on the price. And actually, the
price is easy to manipulate. If you, as an economically active full node,
refuse to acknowledge the old chain and demand that incoming coins arrive
over the UASF chain. In doing so, you drive down the utility of the old
chain and drive up the utility of the new chain. This ultimately impacts
the price.

I think it would be pretty easy to get high confidence of the success of a
UASF. Basically you need all the major economic hubs to agree to upgrade
and then exclusively accept UASF coins. I don't have a comprehensive list,
but if we could sign on 75% of the major exchanges and payment processors,
and get 75% of the wallets to upgrade, then the UASF would be very likely
to successfully obliterate the old rules, as miners would be unable to sell
their coins or pay their bills by stubbornly sticking to the old chain.
It's less risky than a hard fork by far, because there is zero risk of coin
split if the UASF has majority hashrate, which will follow majority
economic value.

A serious proposal I think would get all the code ready and merged, but
without setting a flag day. Then we would get signatures from the major
institutions promising to use the software and saying that they are ready
for a flag day. After that, you release a patch with a flag day 12 months
in the future. People can upgrade immediately, and have a full year to
transition.

That gives tons of time for people to upgrade, and tons of confidence that
the UASF will end up as the majority chain.

If we cannot get enough major exchanges, payment processors, and other
economic hubs to upgrade,  the flag day should remain upset, as the risk of
coin split will be non-zero.

I would suggest that a carefully executed UASF is much riskier than a soft
fork, but far, far less risky than a hard fork.

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

Re: [bitcoin-dev] Moving towards user activated soft fork activation

[Eric Voskuil]

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

There are two aspects of system security in Bitcoin, mining (hash power) and payment validation (economy). The security of each is a function of its level of decentralization. Another way to think of it is that a system with less decentralization has a smaller community (consensus). A large consensus is more secure in that it is more resistant to change (forks) than a system with a small consensus.

The fact that mining is highly centralized makes it relatively easy to enforce a fork via miner collaboration, and hard to do so without it.

So clearly the other option, as being discussed here, is to enforce a fork via the economy. Given the highly centralized nature of the economy, described below as "economic hubs", it is also relatively easy as well.

Independent of one's opinion on the merits of one fork or another, the state of centralization in Bitcoin is an area of great concern. If "we" can sit down with 75% of the economy and/or 90% of the hash power (which of course has been done) and negotiate a change to any rule, Bitcoin is a purely political money.

If "we" can do this, so can "they".

e

> On Mar 5, 2017, at 10:10 AM, David Vorick via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> I also think that the UASF is a good idea. Hashrate follows coin price. If the UASF has the higher coin price, the other chain will be annihilated. If the UASF has a lower coin price, the user activated chain can still exist (though their coins can be trivially stolen on the majority chain).
> 
> The success of the UASF depends entirely on the price. And actually, the price is easy to manipulate. If you, as an economically active full node, refuse to acknowledge the old chain and demand that incoming coins arrive over the UASF chain. In doing so, you drive down the utility of the old chain and drive up the utility of the new chain. This ultimately impacts the price.
> 
> I think it would be pretty easy to get high confidence of the success of a UASF. Basically you need all the major economic hubs to agree to upgrade and then exclusively accept UASF coins. I don't have a comprehensive list, but if we could sign on 75% of the major exchanges and payment processors, and get 75% of the wallets to upgrade, then the UASF would be very likely to successfully obliterate the old rules, as miners would be unable to sell their coins or pay their bills by stubbornly sticking to the old chain. It's less risky than a hard fork by far, because there is zero risk of coin split if the UASF has majority hashrate, which will follow majority economic value.
> 
> A serious proposal I think would get all the code ready and merged, but without setting a flag day. Then we would get signatures from the major institutions promising to use the software and saying that they are ready for a flag day. After that, you release a patch with a flag day 12 months in the future. People can upgrade immediately, and have a full year to transition.
> 
> That gives tons of time for people to upgrade, and tons of confidence that the UASF will end up as the majority chain.
> 
> If we cannot get enough major exchanges, payment processors, and other economic hubs to upgrade,  the flag day should remain upset, as the risk of coin split will be non-zero.
> 
> I would suggest that a carefully executed UASF is much riskier than a soft fork, but far, far less risky than a hard fork.
> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

Re: [bitcoin-dev] Moving towards user activated soft fork activation

[Nick ODell]

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

>I also think that the UASF is a good idea. Hashrate follows coin price. If
the UASF has the higher coin price, the other chain will be annihilated. If
the UASF has a lower coin price, the user activated chain can still exist
(though their coins can be trivially stolen on the majority chain).

I don't think that's true. Say there are two forks of Blahcoin. Alice
thinks there's a 55% chance that Fork A will succeed. Bob thinks there's a
55% chance that Fork B will succeed. Alice trades all of her Fork B coins
for all of Bob's Fork A coins. Now, Bob and Alice both have a stake in one
fork or the other succeeding. Alice starts spending more time around Fork A
users; Bob starts spending his time with Fork B users.

A year passes, and Alice and Bob meet again. Bob tells Alice that Fork B
has been doing much better than Fork A, and is trading at ten times the
price. Alice replies that it doesn't matter, since Fork B will soon split
into B1 and B2. After all, if Fork B surrendered its principles once, it
can do so again. Bob replies that Fork B represents the true spirit of
Blahcoin. Alice replies that all of the people whose opinion she respects
believe that Fork B violates principles set down by the Founder (peace be
upon him.)

Bob disagrees, and cites an annotated collection of the Founder's writings,
which clearly show that if a situation like what provoked the Great Fork
happens, Fork B is in the right. All of the people Bob knows (except Alice)
agree that this shows Fork A is invalid. Alice replies that Bob is
committing the bandwagon fallacy; even if a thousand people believe that
red is green, that does not make it true. Also, the collection takes
several of the Founder's comments out of context. If one looks at comments
made prior to the release of Blahcoin, they lay out a framework that
envisions Fork A. Bob replies that Alice can't use statements made prior to
the release of Blahcoin to establish original intent; the system hadn't
been designed yet.

Bob points out that Fork B has a higher total chainwork. Alice scoffs. She
posits a Fork C, which is exactly like Fork A, except that chainwork is
defined to be the previous definition plus a quadrillion. Bob finds that
ridiculous. Fork C would transgress upon intrinsic principles of Blahcoin.
No more than Fork B does, Alice replies.

----

Each sentence above is true from some point of view. Each person sincerely
believes in the rightness of their position. Is there some objective
measure, that both Alice and Bob can agree on, that resolves this? I don't
think there is. Bob and Alice will sneer at each other for being idiots
forever. The schism will never resolve.

Satoshi Bless,
--Nick

On Sun, Mar 5, 2017 at 11:10 AM, David Vorick via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I also think that the UASF is a good idea. Hashrate follows coin price. If
> the UASF has the higher coin price, the other chain will be annihilated. If
> the UASF has a lower coin price, the user activated chain can still exist
> (though their coins can be trivially stolen on the majority chain).
>
> The success of the UASF depends entirely on the price. And actually, the
> price is easy to manipulate. If you, as an economically active full node,
> refuse to acknowledge the old chain and demand that incoming coins arrive
> over the UASF chain. In doing so, you drive down the utility of the old
> chain and drive up the utility of the new chain. This ultimately impacts
> the price.
>
> I think it would be pretty easy to get high confidence of the success of a
> UASF. Basically you need all the major economic hubs to agree to upgrade
> and then exclusively accept UASF coins. I don't have a comprehensive list,
> but if we could sign on 75% of the major exchanges and payment processors,
> and get 75% of the wallets to upgrade, then the UASF would be very likely
> to successfully obliterate the old rules, as miners would be unable to sell
> their coins or pay their bills by stubbornly sticking to the old chain.
> It's less risky than a hard fork by far, because there is zero risk of coin
> split if the UASF has majority hashrate, which will follow majority
> economic value.
>
> A serious proposal I think would get all the code ready and merged, but
> without setting a flag day. Then we would get signatures from the major
> institutions promising to use the software and saying that they are ready
> for a flag day. After that, you release a patch with a flag day 12 months
> in the future. People can upgrade immediately, and have a full year to
> transition.
>
> That gives tons of time for people to upgrade, and tons of confidence that
> the UASF will end up as the majority chain.
>
> If we cannot get enough major exchanges, payment processors, and other
> economic hubs to upgrade,  the flag day should remain upset, as the risk of
> coin split will be non-zero.
>
> I would suggest that a carefully executed UASF is much riskier than a soft
> fork, but far, far less risky than a hard fork.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

Re: [bitcoin-dev] Moving towards user activated soft fork activation

[David Vorick]

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

On Mar 5, 2017 6:48 PM, "Eric Voskuil" <eric@voskuil.org> wrote:


Independent of one's opinion on the merits of one fork or another, the
state of centralization in Bitcoin is an area of great concern. If "we" can
sit down with 75% of the economy and/or 90% of the hash power (which of
course has been done) and negotiate a change to any rule, Bitcoin is a
purely political money.

If "we" can do this, so can "they".

e


There is no doubt that politics play a big role in all of this. Also no
doubt that broader decentralization would be superior. But miner activated
soft forks and user activated soft forks do not need discussions with
centralized parties to move forward. It is merely two different methods for
pushing a soft fork through the network.

The key is that it's a soft fork. Old nodes continue to work as always,
whether the soft fork deploys or not.

User activated soft forks, or perhaps more accurately called 'economically
forced soft forks' are a tool to use if the miners are in clear opposition
to the broader economy. They only work if the broader economy actually
fully supports the soft fork, which is much more difficult to measure than
miner support. And miners with deeper pockets may be able to resist for
some time, effectively performing a rewardless 51% attack and maintaining a
split network for some time. The miners would lose lots of money, but old
nodes would feel all the burn of a hard fork, followed by a sudden deep
reorg when the network finally 'heals'.

I guess in some sense you'd be playing chicken with the miners. If the
split is not instantly successful there would be a lot of damage to old
nodes, even if the majority of new nodes had upgraded. (but there would
also be a lot of damage to the miners).

On Mar 5, 2017 9:31 PM, "Nick ODell" <nickodell@gmail.com> wrote:

>I also think that the UASF is a good idea. Hashrate follows coin price. If
the UASF has the higher coin price, the other chain will be annihilated. If
the UASF has a lower coin price, the user activated chain can still exist
(though their coins can be trivially stolen on the majority chain).

I don't think that's true. Say there are two forks of Blahcoin. Alice
thinks there's a 55% chance that Fork A will succeed. Bob thinks there's a
55% chance that Fork B will succeed. Alice trades all of her Fork B coins
for all of Bob's Fork A coins. Now, Bob and Alice both have a stake in one
fork or the other succeeding. Alice starts spending more time around Fork A
users; Bob starts spending his time with Fork B users.


This is not relevant to a UASF. The existing nodes on the network have a
single formal definition for longest chain. If the UASF is successful, the
old nodes will follow the new soft fork and there will be only one chain.
Spirit of Bitcoin or not, the UASF is successful and there is no coin split
or network fork.

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

Re: [bitcoin-dev] Moving towards user activated soft fork activation

[Edmund Edgar]

On 6 March 2017 at 18:18, David Vorick via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> User activated soft forks, or perhaps more accurately called 'economically
> forced soft forks' are a tool to use if the miners are in clear opposition
> to the broader economy.

I don't think they work for that, at least not for new features,
because miners will presumably just head the whole thing off by
orphaning the whole class of non-standard transactions that are the
subject of the fork. In the SegWit case, they'd just orphan anything
that looks like a SegWit transaction, valid or not. That way they
don't need to worry about ending up on the wrong side of the upgrade,
because no transaction affected by the proposed rule change will ever
get into the longest chain. Rational node operators (particularly
exchanges) will likely also adopt their stricter rule change, since
they know any chain that breaks it will end up being orphaned, so you
don't want to act on a payment that you see confirmed in it. So then
you're back where you started, except that your soft-fork is now a
de-facto hard-fork, because you have to undo the new, stricter rule
that the miners introduced to head off your shenannigans.

Where they're interesting is where you can do something meaningful by
forcing some transactions through on a once-off basis. For example, if
the Chinese government identified an address belonging to Uighur
separatists and leaned on Chinese miners to prevent anything from that
address confirming, it might be interesting for users to say, "If
these utxos are not spent by block X, your block is invalid".

They might also be interesting for feature upgrades in a world where
mining is radically decentralized and upgrades are fighting against
inertia rather than opposition, but sadly that's not the world we
currently live in.

-- 
-- 
Edmund Edgar
Founder, Social Minds Inc (KK)
Twitter: @edmundedgar
Linked In: edmundedgar
Skype: edmundedgar
http://www.socialminds.jp

Reality Keys
@realitykeys
support@realitykeys.com
https://www.realitykeys.com

Re: [bitcoin-dev] Moving towards user activated soft fork activation

[Gareth Williams]

What you're describing is a hashpower activated soft fork to censor transactions, in response to a user activated soft fork that the majority of hashpower disagrees with.

It is always possible for a majority of hashpower to censor transactions they disagree with. Users may view that as an attack, and can always respond with a POW hard fork. 

Bitcoin only works if the majority of hashpower is not hostile to the users.


On 6 March 2017 9:29:35 PM AEDT, Edmund Edgar via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>On 6 March 2017 at 18:18, David Vorick via bitcoin-dev
><bitcoin-dev@lists.linuxfoundation.org> wrote:
>> User activated soft forks, or perhaps more accurately called
>'economically
>> forced soft forks' are a tool to use if the miners are in clear
>opposition
>> to the broader economy.
>
>I don't think they work for that, at least not for new features,
>because miners will presumably just head the whole thing off by
>orphaning the whole class of non-standard transactions that are the
>subject of the fork. In the SegWit case, they'd just orphan anything
>that looks like a SegWit transaction, valid or not. That way they
>don't need to worry about ending up on the wrong side of the upgrade,
>because no transaction affected by the proposed rule change will ever
>get into the longest chain. Rational node operators (particularly
>exchanges) will likely also adopt their stricter rule change, since
>they know any chain that breaks it will end up being orphaned, so you
>don't want to act on a payment that you see confirmed in it. So then
>you're back where you started, except that your soft-fork is now a
>de-facto hard-fork, because you have to undo the new, stricter rule
>that the miners introduced to head off your shenannigans.
>
>Where they're interesting is where you can do something meaningful by
>forcing some transactions through on a once-off basis. For example, if
>the Chinese government identified an address belonging to Uighur
>separatists and leaned on Chinese miners to prevent anything from that
>address confirming, it might be interesting for users to say, "If
>these utxos are not spent by block X, your block is invalid".
>
>They might also be interesting for feature upgrades in a world where
>mining is radically decentralized and upgrades are fighting against
>inertia rather than opposition, but sadly that's not the world we
>currently live in.

Re: [bitcoin-dev] Moving towards user activated soft fork activation

[Edmund Edgar]

On 7 March 2017 at 08:23, Gareth Williams <gjw@posteo.net> wrote:
> What you're describing is a hashpower activated soft fork to censor transactions, in response to a user activated soft fork that the majority of hashpower disagrees with.

Well, they'd be censoring transactions to prevent the thing from
activating in the first place. (As opposed to censoring a subset of
those transactions to enforce the new rule, which is the behaviour
that the people promoting the change want.) There would be no point at
which people reasonably expected that something useful would happen if
they sent funds to an address protected by the new scripting rule.

> Bitcoin only works if the majority of hashpower is not hostile to the users.

This is true. But what we're talking about here is hostility to *a
particular proposal to change the network rules* which is (in this
hypothetical case) supported by the economic majority of users. This
doesn't, in itself, break Bitcoin, although the economic majority are
of course always free to hard-fork to something new if they're
unhappy.

Edmund

-- 
-- 
Edmund Edgar
Founder, Social Minds Inc (KK)
Twitter: @edmundedgar
Linked In: edmundedgar
Skype: edmundedgar
http://www.socialminds.jp

Reality Keys
@realitykeys
ed@realitykeys.com
https://www.realitykeys.com

Re: [bitcoin-dev] Moving towards user activated soft fork activation

[Tom Zander]

On Tuesday, 7 March 2017 00:23:47 CET Gareth Williams via bitcoin-dev wrote:
> What you're describing is a hashpower activated soft fork to censor
> transactions, in response to a user activated soft fork that the majority
> of hashpower disagrees with.

It is incorrect to say that censoring of transactions is what Edmund 
suggested. It's purely about the form they take, you can re-send the 
transaction in a different form with the same content and they go through. 
Hence, not transaction censoring.

I do believe the point that Edmund brought up is a very good one, the idea 
that a set of users can force the miners to do something is rather silly and 
the setup that a minority miner fraction can force the majority to do 
something is equally silly. This is because the majority mining hashpower 
can fight back against this attack upon them.

Don’t be mistaken; a hash-minority attacking the hash-majority is in actual 
fact an attack upon Bitcoin as a whole.
If this were possible then next year we’d see governments try to push 
through changes in the same UASF way. I’m very happy that UASFs can’t work 
because that would be the end of Bitcoin's freedom and decentralized nature.

> It is always possible for a majority of hashpower to censor transactions
> they disagree with. Users may view that as an attack, and can always
> respond with a POW hard fork.

I definitely welcome that approach.

The result would be that you have two chains, but also you ensure that the 
chain that the miners didn’t like will no longer be something they can mine. 
Not even the minority set of miners that like the softfork can mine on it. 
This is a win-win and then the market will decide which one will "win".
 
> Bitcoin only works if the majority of hashpower is not hostile to the
> users.

This goes both ways, miners both generate value (in the form of security) 
and they take value (in the form of inflation).
If the majority of the users are hostile and reject blocks that the miners 
create, or change the POW, then what the miners bring to the table is also 
removed.
Bitcoin would lose the security and in the short term even the ability to 
mine blocks every 10 minutes.

So, lets correct your statement a little;
«Bitcoin only works when the majority of the hashpower and the (economic)
  majority of the users are balanced in power and have their goals aligned.»

-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

Re: [bitcoin-dev] Moving towards user activated soft fork activation

[Eric Voskuil]

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

On 03/06/2017 05:07 PM, Edmund Edgar via bitcoin-dev wrote:
> On 7 March 2017 at 08:23, Gareth Williams <gjw@posteo.net> wrote:
>> What you're describing is a hashpower activated soft fork to censor
transactions, in response to a user activated soft fork that the
majority of hashpower disagrees with.

This definition of censorship would apply to all validation.

A miner is free to select whatever transactions he wants, for whatever
reasons he wants. Bitcoin's defense against censorship (and disruption)
is in the broad distribution of over 50% (anecdotally) of the hash power
among a large number of people.

> Well, they'd be censoring transactions to prevent the thing from
> activating in the first place. (As opposed to censoring a subset of
> those transactions to enforce the new rule, which is the behaviour
> that the people promoting the change want.)

Exactly, a soft fork expects that people start rejecting a previously
valid style of transaction, or that they ignore it. It's perfectly
reasonable to conclude that some miners may continue to accept the
soft-fork-invalidated transactions and instead reject the new style of
transactions as invalid. Reliance on their acceptance of the soft fork
is based on the weak assumption that they won't change their software or
that they live in fear of a retaliatory POW change.

>> Bitcoin only works if the majority of hashpower is not hostile to the
users.

Honesty in this context refers to double spending. Selecting a different
rule set effectively moves one to another coin, which is not dishonest
(hostile to anyone).  Miners have zero technical or ethical obligation
to follow any particular set of rules. Bitcoin has one golden rule, run
whatever code you want. Security is based on decentralization, not
well-behaved people (or well-behaved software).

> This is true. But what we're talking about here is hostility to *a
> particular proposal to change the network rules* which is (in this
> hypothetical case) supported by the economic majority of users. This
> doesn't, in itself, break Bitcoin, although the economic majority are
> of course always free to hard-fork to something new if they're
> unhappy.

Again spot on. Users of the money purchase security from miners. Miners
are under no obligation to provide that service nor are users under any
obligation to purchase it.

One thing to consider is how different the landscape would look if every
person on the planet was a miner, and the economy was similarly
distributed. Would it be easier to get 51% hash power on board with a
soft fork, or some much higher percentage on board with a hard fork? It
seems likely that any proposed material change would fail. Regardless of
how one feels about that, it is the nature of a sound money that it
doesn't change.

e


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [bitcoin-dev] Moving towards user activated soft fork activation

[Eric Voskuil]

> Bitcoin would lose the security and in the short term even the ability to 
mine blocks every 10 minutes.

Presumably a POW hard fork would be accompanied by a difficulty reset, so that the deployment didn't have *both* of these problems from the outset.  There's really little difference between 10 minutes at little/no security and zero conf. See testnet. But people might feel better about still seeing blocks.

But in any case it's not clear to me why you assume a loss of security in the "short term" is something that can be overcome. The short term can presumably prevent the long term from ever becoming.

e

> On Mar 7, 2017, at 1:17 AM, Tom Zander via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
>> On Tuesday, 7 March 2017 00:23:47 CET Gareth Williams via bitcoin-dev wrote:
>> What you're describing is a hashpower activated soft fork to censor
>> transactions, in response to a user activated soft fork that the majority
>> of hashpower disagrees with.
> 
> It is incorrect to say that censoring of transactions is what Edmund 
> suggested. It's purely about the form they take, you can re-send the 
> transaction in a different form with the same content and they go through. 
> Hence, not transaction censoring.
> 
> I do believe the point that Edmund brought up is a very good one, the idea 
> that a set of users can force the miners to do something is rather silly and 
> the setup that a minority miner fraction can force the majority to do 
> something is equally silly. This is because the majority mining hashpower 
> can fight back against this attack upon them.
> 
> Don’t be mistaken; a hash-minority attacking the hash-majority is in actual 
> fact an attack upon Bitcoin as a whole.
> If this were possible then next year we’d see governments try to push 
> through changes in the same UASF way. I’m very happy that UASFs can’t work 
> because that would be the end of Bitcoin's freedom and decentralized nature.
> 
>> It is always possible for a majority of hashpower to censor transactions
>> they disagree with. Users may view that as an attack, and can always
>> respond with a POW hard fork.
> 
> I definitely welcome that approach.
> 
> The result would be that you have two chains, but also you ensure that the 
> chain that the miners didn’t like will no longer be something they can mine. 
> Not even the minority set of miners that like the softfork can mine on it. 
> This is a win-win and then the market will decide which one will "win".
> 
>> Bitcoin only works if the majority of hashpower is not hostile to the
>> users.
> 
> This goes both ways, miners both generate value (in the form of security) 
> and they take value (in the form of inflation).
> If the majority of the users are hostile and reject blocks that the miners 
> create, or change the POW, then what the miners bring to the table is also 
> removed.
> Bitcoin would lose the security and in the short term even the ability to 
> mine blocks every 10 minutes.
> 
> So, lets correct your statement a little;
> «Bitcoin only works when the majority of the hashpower and the (economic)
>  majority of the users are balanced in power and have their goals aligned.»
> 
> -- 
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Moving towards user activated soft fork activation

[Alphonse Pace]

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

I fail to see how any non-mining user can attack a miner.  The worst they
can do is refuse to buy their coinbase transaction.  Do you believe that
users are obligated to buy coins from miners?  If not, then all miners are
voluntarily choosing a set of rules to enforce and a set of policy to mine.

>Don’t be mistaken; a hash-minority attacking the hash-majority is in actual
fact an attack upon Bitcoin as a whole.

Can you outline how a minority of hash rate can attack a majority? Users
are free to follow tighter rules than before, or they may reject it.  The
majority of hash rate can continue the old rules or not.  Where is the
attack?  I see a disagreement being resolved peacefully through unilateral
separation.

>If this were possible then next year we’d see governments try to push
through changes in the same UASF way. I’m very happy that UASFs can’t work
because that would be the end of Bitcoin's freedom and decentralized nature.

Governments would be much more equipped to simply go directly to the miners
to enforce this for them - why even bother with millions of distributed
miners when you can knock on a few doors and get your policy?

>If the majority of the users are hostile and reject blocks that the miners
create, or change the POW, then what the miners bring to the table is also
removed.

I don't understand how users can be hostile to Bitcoin.  Users are
Bitcoin.  Everyone else serves the users.  All participants are voluntary
and can choose to participate or not.  Where is the attack or hostility?

-Alphonse

On Tue, Mar 7, 2017 at 3:17 AM, Tom Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tuesday, 7 March 2017 00:23:47 CET Gareth Williams via bitcoin-dev
> wrote:
> > What you're describing is a hashpower activated soft fork to censor
> > transactions, in response to a user activated soft fork that the majority
> > of hashpower disagrees with.
>
> It is incorrect to say that censoring of transactions is what Edmund
> suggested. It's purely about the form they take, you can re-send the
> transaction in a different form with the same content and they go through.
> Hence, not transaction censoring.
>
> I do believe the point that Edmund brought up is a very good one, the idea
> that a set of users can force the miners to do something is rather silly
> and
> the setup that a minority miner fraction can force the majority to do
> something is equally silly. This is because the majority mining hashpower
> can fight back against this attack upon them.
>
> Don’t be mistaken; a hash-minority attacking the hash-majority is in actual
> fact an attack upon Bitcoin as a whole.
> If this were possible then next year we’d see governments try to push
> through changes in the same UASF way. I’m very happy that UASFs can’t work
> because that would be the end of Bitcoin's freedom and decentralized
> nature.
>
> > It is always possible for a majority of hashpower to censor transactions
> > they disagree with. Users may view that as an attack, and can always
> > respond with a POW hard fork.
>
> I definitely welcome that approach.
>
> The result would be that you have two chains, but also you ensure that the
> chain that the miners didn’t like will no longer be something they can
> mine.
> Not even the minority set of miners that like the softfork can mine on it.
> This is a win-win and then the market will decide which one will "win".
>
> > Bitcoin only works if the majority of hashpower is not hostile to the
> > users.
>
> This goes both ways, miners both generate value (in the form of security)
> and they take value (in the form of inflation).
> If the majority of the users are hostile and reject blocks that the miners
> create, or change the POW, then what the miners bring to the table is also
> removed.
> Bitcoin would lose the security and in the short term even the ability to
> mine blocks every 10 minutes.
>
> So, lets correct your statement a little;
> «Bitcoin only works when the majority of the hashpower and the (economic)
>   majority of the users are balanced in power and have their goals
> aligned.»
>
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] Moving towards user activated soft fork activation

[shaolinfry]

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

Thank you all for the insightful feedback, on list, in private and on various social media platforms. I have extended the generalized proposal which extends BIP9. This basically introduces an extra workflow state if activationtime > starttime and < timeout - 1 month. It allows extra business logic to be added, such as requiring mandatory signalling.

Please find the draft here:

https://gist.github.com/shaolinfry/70d0582db7de958b7d5b6422cfef4e22

<pre> BIP: bip-uaversionbits-strong Title: Version bits extension with mandatory activation Author: Shaolin Fry <shaolinfry@protonmail.ch> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-???? Status: Draft Type: Informational Created: 2017-03-09 License: BSD-3-Clause CC0-1.0 </pre> ==Abstract== This document specifies an extension to BIP9 that introduces an additional activation parameter to deploy backward-compatible changes (further called "soft forks") to be activated by a deadline. ==Motivation== BIP9 introduced a mechanism for doing parallel soft forking deployments based on repurposing the block nVersion field. Activation is dependent on near unanimous hashrate signalling which may be impractical and is also subject to veto by a small minority of non-signalling hashrate. This specification provides an way for full nodes to coordinate syncronized activation based on a median past time using the BIP9 state machine. Hashrate may optionally trigger activation before the user defined activation sequence triggers. ==Specification== This specification adds a new per-chain deployment parameter to the existing BIP9 specification as follows: # The '''activationtime''' specifies a minimum median time past of a block at which the deployment should transition to the locked-in state. This specification adds a new workflow state, '''PRE_LOCK_IN''' to the BIP9 state machine if the deployment '''activationtime''' is greater than zero when the workflow will be '''DEFINED''' -> '''STARTED''' -> '''PRE_LOCK_IN''' -> '''LOCKED_IN''' -> '''ACTIVE'''. The '''PRE_LOCK_IN''' phase allows optional per deployment processing, e.g. mandatory signalling. ===Selection guidelines=== The following guidelines are suggested for selecting these parameters for a soft fork: # '''activationtime''' should be set to some date in the future and must be less than the BIP9 '''timeout'''. It is recommended to have an activation time of 1 year minus 30 days (28944000 seconds). The '''activationtime''' cannot be less than 30 days before the '''timeout'''. ===State transitions=== The state transition workflow is exactly the same as in BIP9 except when '''activationtime''' is greater than zero. Then the workflow will be '''DEFINED''' -> '''STARTED''' -> '''PRE_LOCK_IN''' -> '''LOCKED_IN''' -> '''ACTIVE'''. When in the STARTED state if the median time past is greater than or equal to the '''activationtime''' then the state will transition to PRE_LOCK_IN on the next retarget after '''activationtime'''. case STARTED: // Transition to THRESHOLD_PRE_LOCK_IN if mandatory activation is set if ((nActivationTime != 0) && pindexPrev->GetMedianTimePast() >= nActivationTime) { stateNext = THRESHOLD_PRE_LOCK_IN; break; } // BIP9 specification follows if (GetMedianTimePast(block.parent) >= timeout) { return FAILED; } int count = 0; walk = block; for (i = 0; i < 2016; i++) { walk = walk.parent; if (walk.nVersion & 0xE0000000 == 0x20000000 && (walk.nVersion >> bit) & 1 == 1) { count++; } } if (count >= threshold) { return LOCKED_IN; } return STARTED; === Reference implementation === https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip-uaversionbits-strong ==== Optional mandatory signalling ==== <pre> /** * Return true if nVersion BIP9 deployment is signalling during * mandatory periods. */ bool IsMandatorySignalling(int32_t nVersion, Consensus::DeploymentPos pos, const CBlockIndex* pindexPrev, const Consensus::Params& params) { // Check the deployment is in the correct state for this check to apply. if (!((VersionBitsState(pindexPrev, params, pos, versionbitscache) == THRESHOLD_PRE_LOCK_IN) || (VersionBitsState(pindexPrev, params, pos, versionbitscache) == THRESHOLD_LOCKED_IN))) return true; // return signalling state return (((nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS) && (nVersion & VersionBitsMask(params, pos)) != 0); } // segwit signalling is mandatory during PRE_LOCK_IN and LOCKED_IN phase if (!IsMandatorySignalling(block.nVersion, Consensus::DEPLOYMENT_EXAMPLE, pindexPrev, consensusParams)) return state.Invalid(false, REJECT_OBSOLETE, strprintf("bad-version(0x%08x)", block.nVersion), strprintf("rejected nVersion=0x%08x block, must upgrade", block.nVersion)); </pre> ==Deployments== A living list of deployment proposals can be found [[bip-0009/assignments.mediawiki|here]]. ==Copyright== This document is placed in the public domain.

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

Re: [bitcoin-dev] Moving towards user activated soft fork activation

[Luke Dashjr]

Without at least a majority hashrate validating blocks, it is possible just a 
single invalid block could split the chain such that the majority continue 
building a most-work on that invalid block.

This failure to validate a softfork is similar in some respects to a hardfork, 
but with one critical difference: the default behaviour of old nodes will be 
to follow the chain with the most-work that was valid under the pre-softfork 
rules. This actually *inverts* the benefit of the softfork over a hardfork, 
and makes a softfork deployed in such a manner de facto behave as if it had 
been a hardfork, IF someone ever mines a single malicious block.

For this reason, I think a minority-hashrate softfork requires a much higher 
degree of social support than merely the widespread agreement typical of 
softforks. It might perhaps require less than the full ~100% consensus 
hardforks require, but it likely comes somewhat close.

Once it gets over 50% hashrate enforcement, however, the situation improves a 
lot more: a malicious block may split obsolete miners off the valid chain, but 
it will eventually resolve on its own given enough time. Due to natural 
fluctuations in block finding, however, automatic measurement may need to look 
for >75%.

So I would suggest that instead of a simple flag day activation, this proposal 
would be improved by changing the flag day to merely reduce the hashrate 
requirement from 95% to 75%.

(In addition to the above concerns, if >50% of miners are hostile to the 
network, we likely have other problems.)

Luke

Re: [bitcoin-dev] Moving towards user activated soft fork activation

[Eric Voskuil]

On Feb 27, 2017, at 8:02 AM, shaolinfry via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

>> 3) In terms of complexity for mining pool operators, how well does this model scale if there are N soft forks and the pool doesn't want to opt-in to any of them? Couldn't this result in those pool operators having to run not just one border node, but a multitude of "chained" border nodes if the soft forks are spread across different software implementations?
> 
> While BIP9 allows for 29 parallel deployments I think it is unrealistic to expect there would be such a high number of active parallel deployments at any one time: History shows soft forks take a minimum of 6 months design, consensus building, coding and testing before deployment. With such a high bar, I do not envisage more than a couple of parallel deployments at any given time. I also do not envisage "conflicting" soft forks, as that would not meet consensus from the technical community on the basis of safety and sanity. In any case, the deployment strategy of each soft fork should be considered on a case by case basis.

The relationship between a codebase and chain fork implementations is similar to vendor lock-in, and is being used in a similar manner.

There is nothing preventing a single codebase from implementing all forks and exposing the option to apply any non-conflicting combination of them.

While this has not been the norm libbitcoin now utilizes this approach. Currently the options to apply any activated Bitcoin forks are exposed via config. I personally am not working to implement non-activated forks at this point, but that's just prioritization.

Recently I objected to BIP90. This hard fork is presented as a code simplification and a performance optimization. I showed in the discussion that it was neither. Nevertheless we implemented this additional code and give the user the option to apply it or not. It's application produces no performance benefit, but it ensures that the choice of forks remains in the hands of the user.

e

Re: [bitcoin-dev] Moving towards user activated soft fork activation

[shaolinfry]

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

Dear Jameson,

Thank you for your questions. Answers inline below:

Jameson Lopp via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:


You've made many salient points, Shaolin, though I have a few questions:

1) How well does this model work under adversarial conditions? Fair point about signaling not being reliable, though it seems more vague in terms of safety given that you can't actually know what percentage of hashrate that is /not/ signaling for the soft fork has taken the necessary precautions to avoid mining an invalid block and potentially causing a hard fork. It's probably safe to say that if a flag-day soft fork is activated, there will be at least a few parties who will attempt to trigger a chain fork by crafting transactions that are valid via non-fork rules but invalid via the soft fork rules.

In a well designed soft fork, transactions under the old rules are non-standard by default and will not propagate or be mined. A miner would have to deliberately include the invalid transaction in a block and mine it. The invalid block would be rejected by the network costing the miner block reward and fees.

If >51% of the hashrate does not upgrade or does not take steps to protect themselves from invalid blocks, they will fork if someone produces an invalid block. Game theory suggests the incentive for those who do not wish to participate, would be to do so safely. There is no incentive to allow an attacker to cause you to split off from the network and it is trivial to prevent it.

There is a valid concern about "spy" mining and I cited a previous incident with BIP66 activation and we should be working towards solutions that remove the incentive to spy mine. "Weak blocks", where miners propagate their proposed blocks before solving the PoW may provide better incentives against spy mining, while delivering more (~no propagation delay and full validation, and thus more security).



2) If the flag day soft fork is activated with only a minority of hashrate support + safely opted-out hashrate, isn't it possible for the rest of miners to coordinate orphaning any soft fork compatible blocks to kill the soft fork chain? This would be a major difference from a miner-activated soft fork, correct? Unless perhaps many miners colluded to signal soft fork support while not actually supporting it...

The basic assumption in the Bitcoin system is that miners will remain honest because it is in their economic interest to do so. Of course 51% of the hashrate can censor the minority hash by orphaning blacklisted transactions or blocks. I am fairly certain it would be considered an attack by as well as being very conspicuous. A 51% attack would likely cause a dramatic loss in confidence in the Bitcoin system and adversely affect price. It is reasonable to assume miners would not do that because mining has to remain profitable. Additionally, such a scenario would draw much ire from users who may escalate demands for a PoW change.

It is assuming good-faith and that miners would not want to deny people the ability to opt into something they wanted. All that is required of miners is to upgrade their border node. Miners should update their software anyway for security reasons.



3) In terms of complexity for mining pool operators, how well does this model scale if there are N soft forks and the pool doesn't want to opt-in to any of them? Couldn't this result in those pool operators having to run not just one border node, but a multitude of "chained" border nodes if the soft forks are spread across different software implementations?

While BIP9 allows for 29 parallel deployments I think it is unrealistic to expect there would be such a high number of active parallel deployments at any one time: History shows soft forks take a minimum of 6 months design, consensus building, coding and testing before deployment. With such a high bar, I do not envisage more than a couple of parallel deployments at any given time. I also do not envisage "conflicting" soft forks, as that would not meet consensus from the technical community on the basis of safety and sanity. In any case, the deployment strategy of each soft fork should be considered on a case by case basis.



It seems to me that this type of user-driven approach would preferably be coupled with assurances from major Bitcoin wallets / exchanges / payment processors that they will not honor coins from a chain fork that results from invalid spends of outputs encumbered by soft fork rules. Though on the other hand, I don't see such an assurance being possible given that exchanges have an incentive to take the first mover advantage in listing a new coin.

Soft fork consensus proposals should be sane, uncontroversial and have a reasonably high bar in terms of technical consensus as we have seen with other soft forks to date. There is an implicit assumption in my text, that the decision to deploy a soft fork (regardless of the activation method) is based on a reasonable expectation that users will make use of the new feature. Hashrate signalling is not a vote, but a coordination trigger. Soft forks are backwards compatible and opt-in; so long as they are well written and bug free, users should at worst, be agnostic towards them because they have a choice whether to safely use the new feature or not, without preventing others' enjoyment of the feature. A controversial or unreasonable soft fork would not gain traction and I believe it would be fairly self evident.

In short, I do expect wide ecosystem collaboration as part of any deployment strategy, both hashrate or flag day based.

Many thanks for taking the time to read over and consider my thoughts and proposal. I would be happy to discuss more if you have any further questions or suggestions.



- Jameson



On Sat, Feb 25, 2017 at 6:55 PM, shaolinfry via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

Some thoughts about the activation mechanism for soft forks. In the past we used IsSuperMajority and currently use BIP9 as soft fork activation methods, where a supermajority of hashrate triggers nodes to begin enforcing new rules. Hashrate based activation is convenient because it is the simplest and most straightforward process. While convenient there are a number limitations with this method.

Firstly, it requires trusting the hash power will validate after activation. The BIP66 soft fork was a case where 95% of the hashrate was signaling readiness but in reality about half was not actually validating the upgraded rules and mined upon an invalid block by mistake[1].

Secondly, miner signalling has a natural veto which allows a small percentage of hashrate to veto node activation of the upgrade for everyone. To date, soft forks have taken advantage of the relatively centralised mining landscape where there are relatively few mining pools building valid blocks; as we move towards more hashrate decentralization, it's likely that we will suffer more and more from "upgrade inertia" which will veto most upgrades.

Upgrade inertia in inevitable for widely deployed software and can be seen for example, with Microsoft Windows. At the time of writing 5.72% of all Microsoft Windows installations are still running Windows XP, despite mainstream support ending in 2009 and being superseded by 4 software generations, Vista, 7, 8 and 10.

Thirdly, the signaling methodology is widely misinterpreted to mean the hash power is voting on a proposal and it seems difficult to correct this misunderstanding in the wider community. The hash powers' role is to select valid transactions, and to extend the blockchain with valid blocks. Fully validating economic nodes ensure that blocks are valid. Nodes therefore define validity according to the software they run, but miners decide what already valid transactions gets included in the block chain.

As such, soft forks rules are actually always enforced by the nodes, not the miners. Miners of course can opt-out by simply not including transactions that use the new soft fork feature, but they cannot produce blocks that are invalid to the soft fork. The P2SH soft fork is a good example of this, where non-upgraded miners would see P2SH as spendable without a signature and consider them valid. If such an transaction were to be included in a block, the block would be invalid and the miner would lose the block reward and fees.

So-called "censorship" soft forks do not require nodes to opt in, because >51% of the hash power already have the ability to orphan blocks that contain transactions they have blacklisted. Since this is not a change in validity, nodes will accept the censored block chain automatically.

The fourth problem with supermajority hash power signaling is it draws unnecessary attention to miners which can become unnecessarily political. Already misunderstood as a vote, miners may feel pressure to "make a decision" on behalf of the community: who is and isn't signalling becomes a huge public focus and may put pressures onto miners they are unprepared for. Some miners may not be in a position to upgrade, or may prefer not to participate in the soft fork which is their right. However, that miner may now become a lone reason that vetoes activation for everyone, where the soft fork is an opt-in feature! This situation seems to be against the voluntary nature of the Bitcoin system where participation at all levels is voluntary and kept honest by well balanced incentives.

Since miners already have the protocol level right to select whatever transaction they prefer (and not mine those they don't), it would be better if a miner could chose to not participate in triggering activation of something they won't use, but, without being a veto to the process (and all the ire they may have to experience as a consequence).

The alternative discussed here is "flag day activation" where nodes begin enforcement at a predetermined time in the future. This method needs a longer lead time than a hash power based activation trigger, but offers a number of advantages and perhaps provides a better tradeoff.

Soft forks are still entirely optional to use post activation. For example, with P2SH, many participants in the Bitcoin ecosystem still do not use P2SH. Only 11% of bitcoins[2] are stored in P2SH addresses at the time of writing. Miners are free to not mine P2SH transactions, however, the incentives are such that miners should still validate transactions so they don't accidentally include invalid transactions and cause their block to be rejected. As an additional safety measure for well designed soft forks, relay policy rules prevent non-standard and invalid transactions from being relayed and mined by default; a miner would have to purposefully mine an invalid transaction, which is against their own economic interest.

Since the incentives of the Bitcoin system rely on self validation, economic nodes (miners and users) should always remain safe by ensuring their nodes either validate the current rules, or, they can place their network behind a full node that will filter out invalid transactions and blocks at the edge of their network (so called firewall or border nodes).

A user activated soft fork is permissive. Miners do not have to produce new version blocks and non-upgraded miners' blocks will not be orphaned as was the case with IsSuperMajority soft forks (e.g. BIP34, BIP66, BIP65-CLTV) which made it a compulsory upgrade for miners.

BIP9 "versionbits" soft fork activation method is also permissive in so far as non-upgraded miners are not forced to upgrade after activation because their blocks wont be orphaned. A recent case was the "CSV" soft fork that activated BIP68, BIP112 and BIP113. As such, the CSV soft fork allows non-upgraded miners to continue mining so long as they didn't produce invalid blocks.

Miners always retain discretion on which transactions to mine. However, regardless of whether they actively include transactions using the new soft fork feature, or not, the incentive for hash power to upgrade in order to validate is strong: if they do not, they could be vulnerable to a rogue miner willing to waste 12.5BTC to create an invalid block, which may cause non-validating miners to build on an invalid chain similar to the BIP66 incident. Validation has always had a strong requirement.

A user activated soft fork is win-win because it adds an option that some people want that does not detract from other peoples' enjoyment. Even if only 10% of users ever wanted a feature, so long as the benefit outweighed the technical risks, it would not be rational to deny others the ability to opt-in.

My suggestion is to have the best of both worlds. Since a user activated soft fork needs a relatively long lead time before activation, we can combine with BIP9 to give the option of a faster hash power coordinated activation or activation by flag day, whichever is the sooner. In both cases, we can leverage the warning systems in BIP9. The change is relatively simple, adding an activation-time parameter which will transition the BIP9 state to LOCKED_IN before the end of the BIP9 deployment timeout.

You can find the proposal here https://gist.github.com/shaolinfry/0f7d1fd22743bb966da0c0b1682ea2ab

References:

[1]: https://bitcoin.org/en/alert/2015-07-04-spv-mining
[2]: http://p2sh.info/dashboard/db/p2sh-statistics?from=1472043312917&to=1488030912918

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

Re: [bitcoin-dev] Moving towards user activated soft fork activation

[Jameson Lopp]

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

You've made many salient points, Shaolin, though I have a few questions:

1) How well does this model work under adversarial conditions? Fair point
about signaling not being reliable, though it seems more vague in terms of
safety given that you can't actually know what percentage of hashrate that
is /not/ signaling for the soft fork has taken the necessary precautions to
avoid mining an invalid block and potentially causing a hard fork. It's
probably safe to say that if a flag-day soft fork is activated, there will
be at least a few parties who will attempt to trigger a chain fork by
crafting transactions that are valid via non-fork rules but invalid via the
soft fork rules.

2) If the flag day soft fork is activated with only a minority of hashrate
support + safely opted-out hashrate, isn't it possible for the rest of
miners to coordinate orphaning any soft fork compatible blocks to kill the
soft fork chain? This would be a major difference from a miner-activated
soft fork, correct? Unless perhaps many miners colluded to signal soft fork
support while not actually supporting it...

3) In terms of complexity for mining pool operators, how well does this
model scale if there are N soft forks and the pool doesn't want to opt-in
to any of them? Couldn't this result in those pool operators having to run
not just one border node, but a multitude of "chained" border nodes if the
soft forks are spread across different software implementations?

It seems to me that this type of user-driven approach would preferably be
coupled with assurances from major Bitcoin wallets / exchanges / payment
processors that they will not honor coins from a chain fork that results
from invalid spends of outputs encumbered by soft fork rules. Though on the
other hand, I don't see such an assurance being possible given that
exchanges have an incentive to take the first mover advantage in listing a
new coin.

- Jameson

On Sat, Feb 25, 2017 at 6:55 PM, shaolinfry via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Some thoughts about the activation mechanism for soft forks. In the past
> we used IsSuperMajority and currently use BIP9 as soft fork activation
> methods, where a supermajority of hashrate triggers nodes to begin
> enforcing new rules. Hashrate based activation is convenient because it is
> the simplest and most straightforward process. While convenient there are a
> number limitations with this method.
>
> Firstly, it requires trusting the hash power will validate after
> activation. The BIP66 soft fork was a case where 95% of the hashrate was
> signaling readiness but in reality about half was not actually validating
> the upgraded rules and mined upon an invalid block by mistake[1].
>
> Secondly, miner signalling has a natural veto which allows a small
> percentage of hashrate to veto node activation of the upgrade for everyone.
> To date, soft forks have taken advantage of the relatively centralised
> mining landscape where there are relatively few mining pools building valid
> blocks; as we move towards more hashrate decentralization, it's likely that
> we will suffer more and more from "upgrade inertia" which will veto most
> upgrades.
>
> Upgrade inertia in inevitable for widely deployed software and can be seen
> for example, with Microsoft Windows. At the time of writing 5.72% of all
> Microsoft Windows installations are still running Windows XP, despite
> mainstream support ending in 2009 and being superseded by 4 software
> generations, Vista, 7, 8 and 10.
>
> Thirdly, the signaling methodology is widely misinterpreted to mean the
> hash power is voting on a proposal and it seems difficult to correct this
> misunderstanding in the wider community. The hash powers' role is to select
> valid transactions, and to extend the blockchain with valid blocks. Fully
> validating economic nodes ensure that blocks are valid. Nodes therefore
> define validity according to the software they run, but miners decide what
> already valid transactions gets included in the block chain.
>
> As such, soft forks rules are actually always enforced by the nodes, not
> the miners. Miners of course can opt-out by simply not including
> transactions that use the new soft fork feature, but they cannot produce
> blocks that are invalid to the soft fork. The P2SH soft fork is a good
> example of this, where non-upgraded miners would see P2SH as spendable
> without a signature and consider them valid. If such an transaction were to
> be included in a block, the block would be invalid and the miner would lose
> the block reward and fees.
>
> So-called "censorship" soft forks do not require nodes to opt in, because
> >51% of the hash power already have the ability to orphan blocks that
> contain transactions they have blacklisted. Since this is not a change in
> validity, nodes will accept the censored block chain automatically.
>
> The fourth problem with supermajority hash power signaling is it draws
> unnecessary attention to miners which can become unnecessarily political.
> Already misunderstood as a vote, miners may feel pressure to "make a
> decision" on behalf of the community: who is and isn't signalling becomes a
> huge public focus and may put pressures onto miners they are unprepared
> for. Some miners may not be in a position to upgrade, or may prefer not to
> participate in the soft fork which is their right. However, that miner may
> now become a lone reason that vetoes activation for everyone, where the
> soft fork is an opt-in feature! This situation seems to be against the
> voluntary nature of the Bitcoin system where participation at all levels is
> voluntary and kept honest by well balanced incentives.
>
> Since miners already have the protocol level right to select whatever
> transaction they prefer (and not mine those they don't), it would be better
> if a miner could chose to not participate in triggering activation of
> something they won't use, but, without being a veto to the process (and all
> the ire they may have to experience as a consequence).
>
> The alternative discussed here is "flag day activation" where nodes begin
> enforcement at a predetermined time in the future. This method needs a
> longer lead time than a hash power based activation trigger, but offers a
> number of advantages and perhaps provides a better tradeoff.
>
> Soft forks are still entirely optional to use post activation. For
> example, with P2SH, many participants in the Bitcoin ecosystem still do not
> use P2SH. Only 11% of bitcoins[2] are stored in P2SH addresses at the time
> of writing. Miners are free to not mine P2SH transactions, however, the
> incentives are such that miners should still validate transactions so they
> don't accidentally include invalid transactions and cause their block to be
> rejected. As an additional safety measure for well designed soft forks,
> relay policy rules prevent non-standard and invalid transactions from being
> relayed and mined by default; a miner would have to purposefully mine an
> invalid transaction, which is against their own economic interest.
>
> Since the incentives of the Bitcoin system rely on self validation,
> economic nodes (miners and users) should always remain safe by ensuring
> their nodes either validate the current rules, or, they can place their
> network behind a full node that will filter out invalid transactions and
> blocks at the edge of their network (so called firewall or border nodes).
>
> A user activated soft fork is permissive. Miners do not have to produce
> new version blocks and non-upgraded miners' blocks will not be orphaned as
> was the case with IsSuperMajority soft forks (e.g. BIP34, BIP66,
> BIP65-CLTV) which made it a compulsory upgrade for miners.
>
> BIP9 "versionbits" soft fork activation method is also permissive in so
> far as non-upgraded miners are not forced to upgrade after activation
> because their blocks wont be orphaned. A recent case was the "CSV" soft
> fork that activated BIP68, BIP112 and BIP113. As such, the CSV soft fork
> allows non-upgraded miners to continue mining so long as they didn't
> produce invalid blocks.
>
> Miners always retain discretion on which transactions to mine. However,
> regardless of whether they actively include transactions using the new soft
> fork feature, or not, the incentive for hash power to upgrade in order to
> validate is strong: if they do not, they could be vulnerable to a rogue
> miner willing to waste 12.5BTC to create an invalid block, which may cause
> non-validating miners to build on an invalid chain similar to the BIP66
> incident. Validation has always had a strong requirement.
>
> A user activated soft fork is win-win because it adds an option that some
> people want that does not detract from other peoples' enjoyment. Even if
> only 10% of users ever wanted a feature, so long as the benefit outweighed
> the technical risks, it would not be rational to deny others the ability to
> opt-in.
>
> My suggestion is to have the best of both worlds. Since a user activated
> soft fork needs a relatively long lead time before activation, we can
> combine with BIP9 to give the option of a faster hash power coordinated
> activation or activation by flag day, whichever is the sooner. In both
> cases, we can leverage the warning systems in BIP9. The change is
> relatively simple, adding an activation-time parameter which will
> transition the BIP9 state to LOCKED_IN before the end of the BIP9
> deployment timeout.
>
> You can find the proposal here https://gist.github.com/shaolinfry/
> 0f7d1fd22743bb966da0c0b1682ea2ab
>
> References:
>
> [1]: https://bitcoin.org/en/alert/2015-07-04-spv-mining
> [2]: http://p2sh.info/dashboard/db/p2sh-statistics?from=
> 1472043312917&to=1488030912918
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

[bitcoin-dev] Moving towards user activated soft fork activation

[shaolinfry]

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

Some thoughts about the activation mechanism for soft forks. In the past we used IsSuperMajority and currently use BIP9 as soft fork activation methods, where a supermajority of hashrate triggers nodes to begin enforcing new rules. Hashrate based activation is convenient because it is the simplest and most straightforward process. While convenient there are a number limitations with this method.

Firstly, it requires trusting the hash power will validate after activation. The BIP66 soft fork was a case where 95% of the hashrate was signaling readiness but in reality about half was not actually validating the upgraded rules and mined upon an invalid block by mistake[1].

Secondly, miner signalling has a natural veto which allows a small percentage of hashrate to veto node activation of the upgrade for everyone. To date, soft forks have taken advantage of the relatively centralised mining landscape where there are relatively few mining pools building valid blocks; as we move towards more hashrate decentralization, it's likely that we will suffer more and more from "upgrade inertia" which will veto most upgrades.

Upgrade inertia in inevitable for widely deployed software and can be seen for example, with Microsoft Windows. At the time of writing 5.72% of all Microsoft Windows installations are still running Windows XP, despite mainstream support ending in 2009 and being superseded by 4 software generations, Vista, 7, 8 and 10.

Thirdly, the signaling methodology is widely misinterpreted to mean the hash power is voting on a proposal and it seems difficult to correct this misunderstanding in the wider community. The hash powers' role is to select valid transactions, and to extend the blockchain with valid blocks. Fully validating economic nodes ensure that blocks are valid. Nodes therefore define validity according to the software they run, but miners decide what already valid transactions gets included in the block chain.

As such, soft forks rules are actually always enforced by the nodes, not the miners. Miners of course can opt-out by simply not including transactions that use the new soft fork feature, but they cannot produce blocks that are invalid to the soft fork. The P2SH soft fork is a good example of this, where non-upgraded miners would see P2SH as spendable without a signature and consider them valid. If such an transaction were to be included in a block, the block would be invalid and the miner would lose the block reward and fees.

So-called "censorship" soft forks do not require nodes to opt in, because >51% of the hash power already have the ability to orphan blocks that contain transactions they have blacklisted. Since this is not a change in validity, nodes will accept the censored block chain automatically.

The fourth problem with supermajority hash power signaling is it draws unnecessary attention to miners which can become unnecessarily political. Already misunderstood as a vote, miners may feel pressure to "make a decision" on behalf of the community: who is and isn't signalling becomes a huge public focus and may put pressures onto miners they are unprepared for. Some miners may not be in a position to upgrade, or may prefer not to participate in the soft fork which is their right. However, that miner may now become a lone reason that vetoes activation for everyone, where the soft fork is an opt-in feature! This situation seems to be against the voluntary nature of the Bitcoin system where participation at all levels is voluntary and kept honest by well balanced incentives.

Since miners already have the protocol level right to select whatever transaction they prefer (and not mine those they don't), it would be better if a miner could chose to not participate in triggering activation of something they won't use, but, without being a veto to the process (and all the ire they may have to experience as a consequence).

The alternative discussed here is "flag day activation" where nodes begin enforcement at a predetermined time in the future. This method needs a longer lead time than a hash power based activation trigger, but offers a number of advantages and perhaps provides a better tradeoff.

Soft forks are still entirely optional to use post activation. For example, with P2SH, many participants in the Bitcoin ecosystem still do not use P2SH. Only 11% of bitcoins[2] are stored in P2SH addresses at the time of writing. Miners are free to not mine P2SH transactions, however, the incentives are such that miners should still validate transactions so they don't accidentally include invalid transactions and cause their block to be rejected. As an additional safety measure for well designed soft forks, relay policy rules prevent non-standard and invalid transactions from being relayed and mined by default; a miner would have to purposefully mine an invalid transaction, which is against their own economic interest.

Since the incentives of the Bitcoin system rely on self validation, economic nodes (miners and users) should always remain safe by ensuring their nodes either validate the current rules, or, they can place their network behind a full node that will filter out invalid transactions and blocks at the edge of their network (so called firewall or border nodes).

A user activated soft fork is permissive. Miners do not have to produce new version blocks and non-upgraded miners' blocks will not be orphaned as was the case with IsSuperMajority soft forks (e.g. BIP34, BIP66, BIP65-CLTV) which made it a compulsory upgrade for miners.

BIP9 "versionbits" soft fork activation method is also permissive in so far as non-upgraded miners are not forced to upgrade after activation because their blocks wont be orphaned. A recent case was the "CSV" soft fork that activated BIP68, BIP112 and BIP113. As such, the CSV soft fork allows non-upgraded miners to continue mining so long as they didn't produce invalid blocks.

Miners always retain discretion on which transactions to mine. However, regardless of whether they actively include transactions using the new soft fork feature, or not, the incentive for hash power to upgrade in order to validate is strong: if they do not, they could be vulnerable to a rogue miner willing to waste 12.5BTC to create an invalid block, which may cause non-validating miners to build on an invalid chain similar to the BIP66 incident. Validation has always had a strong requirement.

A user activated soft fork is win-win because it adds an option that some people want that does not detract from other peoples' enjoyment. Even if only 10% of users ever wanted a feature, so long as the benefit outweighed the technical risks, it would not be rational to deny others the ability to opt-in.

My suggestion is to have the best of both worlds. Since a user activated soft fork needs a relatively long lead time before activation, we can combine with BIP9 to give the option of a faster hash power coordinated activation or activation by flag day, whichever is the sooner. In both cases, we can leverage the warning systems in BIP9. The change is relatively simple, adding an activation-time parameter which will transition the BIP9 state to LOCKED_IN before the end of the BIP9 deployment timeout.

You can find the proposal here https://gist.github.com/shaolinfry/0f7d1fd22743bb966da0c0b1682ea2ab

References:

[1]: https://bitcoin.org/en/alert/2015-07-04-spv-mining
[2]: http://p2sh.info/dashboard/db/p2sh-statistics?from=1472043312917&to=1488030912918

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