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

[shaolinfry via bitcoin-dev]

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

 BIP: bip-uaversionbits-strong Title: Version bits extension with 
mandatory activation Author: Shaolin Fry  
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  
==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 & 0xE000 == 0x2000 && (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   /** * 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));  ==Deployments== 
A living list of deployment proposals can be found 
[[bip-0009/assignments.mediawiki|here]]. ==Copyright== This document is placed 
in the public domain.___
bitcoin-dev mailing 

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

[Alphonse Pace via bitcoin-dev]

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

[Eric Voskuil via bitcoin-dev]

On 03/06/2017 05:07 PM, Edmund Edgar via bitcoin-dev wrote:
> On 7 March 2017 at 08:23, Gareth Williams  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



signature.asc
Description: OpenPGP digital signature
___
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

[Edmund Edgar via bitcoin-dev]

On 7 March 2017 at 08:23, Gareth Williams  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
e...@realitykeys.com
https://www.realitykeys.com
___
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

[Gareth Williams via bitcoin-dev]

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 
 wrote:
>On 6 March 2017 at 18:18, David Vorick via bitcoin-dev
> 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.

___
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

[Edmund Edgar via bitcoin-dev]

On 6 March 2017 at 18:18, David Vorick via bitcoin-dev
 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
supp...@realitykeys.com
https://www.realitykeys.com
___
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

[David Vorick via bitcoin-dev]

On Mar 5, 2017 6:48 PM, "Eric Voskuil"  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"  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.
___
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

[Eric Voskuil via bitcoin-dev]

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

[Chris Belcher via bitcoin-dev]

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.

___
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

[Luke Dashjr via bitcoin-dev]

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

[Eric Voskuil via bitcoin-dev]

On Feb 27, 2017, at 8:02 AM, shaolinfry via bitcoin-dev 
 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
___
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

[shaolinfry via bitcoin-dev]

Dear Jameson,

Thank you for your questions. Answers inline below:

Jameson Lopp via bitcoin-dev  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 

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

[Jameson Lopp via bitcoin-dev]

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 

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

[shaolinfry via bitcoin-dev]

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