Block size: It's economics & user preparation & moral hazard

All,

Following the guiding WP principle of Assume Good Faith, I've been trying to boil down the essence of the message following Scaling Bitcoin. There are key bitcoin issues that remain outstanding and pressing, that are* orthogonal to LN & SW*.

I create multiple proposals and try multiple angles because of a few, notable systemic economic and analysis issues - multiple tries at solving the same problems. Why do I do what I do -- Why not try to reboot... just list those problems?

Definitions:

FE - "Fee Event", the condition where main chain MSG_BLOCK is 95+% to hard limit for 7 or more days in row, "blocks generally full" This can also be induced by a miner squeeze (collective soft limit reduction).

Service - a view of bitcoin as a decentralized, faceless, multi-celled, amorphous automaton cloud, that provides services in exchange for payment

Users - total [current | future] set of economic actors that pay money to the Service, and receive value (figuratively or literally) in return

Block Size - This is short hand for MAX_BLOCK_SIZE, the hard limit that requires, today, a hard fork to increase (excl. extension blocks etc.)

Guiding Principle:

Keep the Service alive, secure, decentralized, and censorship resistant for as many Users as possible.

Observations on block size (shorthand for MAX_BLOCK_SIZE as noted above):

This is economically modeled as a supply limited resource over time. On average, 1M capacity is available every 10 minutes, with variance.

Observations on Users, block size and modern bidding process:

A supermajority of hashpower currently evaluates for block inclusion based, first-pass, on tx-fee/KB. Good.

The Service is therefore responsive to the free market and some classes of DoS. Good.

Recent mempool changes float relay fee, making the Service more responsive to fast moving markets and DoS's. Good progress.

Service provided to Users can be modeled at the bandwidth resource level as bidding for position in a virtual priority queue, where up-to-1M bursts are cleared every 10 min (on avg etc.). Not a perfectly fixed supply, definitionally, but constrained within a fixed range.

Observations on the state of today's fee market:

On average, blocks are not full. Economically, this means that fees trend towards zero, due to theoretically unlimited supply at <1M levels.

Of course, fees are not zero. The network relay anti-flood limits serve as an average lower limit for most transactions (excl direct-to-miner). Wallet software also introduces fee variance in interesting ways. All this fee activity is range-bound on the low end.

Let the current set of Users + transaction fee market behavior be TFM (today's fee market). Let the post-Fee-Event set of Users + transaction fee market behavior be FFM (future fee market).

*Key observation: A Bitcoin Fee Event (see def. at top) is an Economic Change Event.*

An Economic Change Event is a period of market chaos, where large changes to prices and sets of economic actors occurs over a short time period.

A Fee Event is a notable Economic Change Event, where a realistic projection forsees higher fee/KB on average, pricing some economic actors (bitcoin projects and businesses) out of the system.

*It is a major change to how current Users experience and pay for the Service*, state change from TFM to FFM.

The game theory bidding behavior is different for a mostly-empty resource versus a usually-full resource. Prices are different. Profitable business models are different. Users (the set of economic actors on the network) are different.

Observation: Contentious hard fork is an Economic Change Event.

Similarly, a fork that partitions economic actors for an extended period or permanently is also an Economic Change Event, shuffling prices and economic actors as the Service dynamically readjusts on both sides of the partition, and Users-A and Users-B populations change their behavior.

Short-Term Problem #1: No-action on block size increase leads to an Economic Change Event.

Failure to increase block size is not obviously-conservative, it is a conscious choice, electing for one economic state and set of actors and prices over another. Choosing FFM over TFM.

*It is rational to reason that maintaining TFM is more conservative* than enduring an Economic Change Event from TFM to FFM.

*It is rational to reason that maintaining similar prices and economic actors is less disruptive.*

Failure to increase block size will lead to a Fee Event sooner rather than later.

Failure to plan ahead for a Fee Event will lead to greater market chaos and User pain.

Short-Term Problem #2: Some Developers wish to accelerate the Fee Event, and a veto can accomplish that.

In the current developer dynamics, 1-2 key developers can and very likely would veto any block size increase.

Thus a veto (e.g. no-action) can lead to a Fee Event, which leads to pricing actors out of the system.

A block size veto wields outsize economic power, because it can accelerate ECE.

*This is an extreme moral hazard: A few Bitcoin Core committers can veto increase and thereby reshape bitcoin economics, price some businesses out of the system. It is less of a moral hazard to keep the current economics [by raising block size] and not exercise such power.*

Short-Term Problem #3: User communication and preparation

The current trajectory of no-block-size-increase can lead to short time market chaos, actor chaos, businesses no longer viable.

In a $6.6B economy, it is criminal to let the Service undergo an ECE without warning users loudly, months in advance: "Dear users, ECE has accelerated potential due to developers preferring a transition from TFM to FFM."

As stated, *it is a conscious choice to change bitcoin economics and User experience* if block size is not advanced with a healthy buffer above actual average traffic levels.

*Raising block size today, at TFM, produces a smaller fee market delta.*

Further, wallet software User experience is very, very poor in a hyper-competitive fee market. (This can and will be improved; that's just the state of things today)

Short-Term Problem #4: User/Dev disconnect: Large mass of users wishes to push Fee Event into future

Almost all bitcoin businesses, exchanges and miners have stated they want a block size increase. See the many media articles, BIP 101 letter, and wiki e.g. https://en.bitcoin.it/wiki/Block_size_limit_controversy#Entities_positions

The current apparent-veto on block size increase runs contra to the desires of many Users. (note language: "many", not claiming "all")

*It is a valid and rational economic choice to subsidize the system with lower fees in the beginning*. Many miners, for example, openly state they prefer long term system growth over maximizing tiny amounts of current day income.

Vetoing a block size increase has the effect of eliminating that economic choice as an option.

It is difficult to measure Users; projecting beyond "businesses and miners" is near impossible.

Without exaggeration, I have never seen this much disconnect between user wishes and dev outcomes in 20+ years of open source.

Short-Term Problem #5: Higher Service prices can negatively impact system security

Bitcoin depends on a virtuous cycle of users boosting and maintaining bitcoin's network effect, incentivizing miners, increasing security.

Higher prices that reduce bitcoin's user count and network effect can have the opposite impact.

(Obviously this is a dynamic system, users and miners react to higher prices... including actions that then reduce the price)

Short-Term Problem #6: Post-Fee-Event market reboot problem + general lack of planning

Game it out: Blocks are now full (FFM). Block size kept at 1M.

How full is too full - who and what dictates when 1M should be increased?

The same question remains, yet now economic governance issues are compounded: In FFM, the fees are very tightly bound to the upper bound of the block size. In TFM, fees are much less sensitive to the upper bound of block size.

Changing block size, when blocks are full, has a more dramatic effect on the market - suddenly new supply is magically brought online, and a minor Economic Change Event occurs.

More generally, the post-Fee-Event next step has not been agreed upon. Is it flexcap? This key "step #2" is just barely at whiteboard stage.

Short-Term Problem #7: Fee Event timing is unpredictable.

As block size free space gets tighter - that is the trend - and block size remains at 1M, Users are ever more likely to hit an Economic Change Event. It could happen in the next 2-6 months.

Today, Users and wallets are not prepared.

It is also understandably a very touchy subject to say "your business or use case might get priced out of bitcoin"

But it is even worse to let worse let Users run into a Fee Event without informing the market that the block size will remain at 1M.

Markets function best with maximum knowledge - when they are informed well in advance of market shifting news and events, giving economic actors time to prepare.

Short-Term Problem #8: Very little testing, data, effort put into blocks-mostly-full economics

*We only know for certain that blocks-mostly-not-full works.* We do not know that changing to blocks-mostly-full works.

Changing to a new economic system includes boatloads of risk.

Very little data has been forthcoming from any party on what FFM might look like, following a Fee Event.

Observation: In the long run, it is assumed we need a "healthy fee market"

Yes, absolutely. In the long run, bitcoin was intended to be supported by transaction fees and not the minting of new supply, and the design of the system is to slowly wean Users off new supply and onto transaction fees for supporting the Service.

While agreeing with the goal, it must be acknowledge that this is a vague and untested goal with many open economic questions -- more of a hope, really.

It is more conservative to preserve current economics than to change to a new system with new economics and no notion of what-comes-next (flexcap?) in terms of system security, healthy sustainable market levels, and impact of changes during and following an ECE.

Core recommendations:

1) "Short term bump" Block size increase to maintain buffer. I've no special BIP preference.

This avoids moral hazard and avoids a major Economic Change Event, as well many other risks.

2) If block size stays at 1M, the Bitcoin Core developer team should sign a collective note stating their desire to transition to a new economic policy, that of "healthy fee market" and strongly urge users to examine their fee policies, wallet software, transaction volumes and other possible User impacting outcomes.

3) Even if can is kicked down the road, Fee Event will come eventually. Direct research, testing and simulations into the economics and user impact side of the equation. Research and experiment with pay-for-burst (pay to future miner), flexcap and other solutions ASAP.

The worst possible outcome is letting the ecosystem randomly drift into the first Fee Event without openly stating the new economic policy choices and consequences.

The simple fact is *inaction* on this supply-limited resource, block size, will change bitcoin to a new economic shape and with different economic actors, selecting some and not others.

It is better to kick the can and gather crucial field data, because next-step (FFM) is very much not fleshed out.

On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:

> 2) If block size stays at 1M, the Bitcoin Core developer team should sign a
> collective note stating their desire to transition to a new economic policy,
> that of "healthy fee market" and strongly urge users to examine their fee
> policies, wallet software, transaction volumes and other possible User
> impacting outcomes.

You present this as if the Bitcoin Core development team is in charge of deciding the network consensus rules, and is responsible for making changes to it in order to satisfy economic demand. If that is the case, Bitcoin has failed, in my opinion.

What the Bitcoin Core team should do, in my opinion, is merge any consensus change that is uncontroversial. We can certainly - individually or not - propose solutions, and express opinions, but as far as maintainers of the software goes our responsibility is keeping the system running, and risking either a fork or establishing ourselves as the de-facto central bank that can make any change to the system would greatly undermine the system's value.

Hard forking changes require that ultimately every participant in the system adopts the new rules. I find it immoral and dangerous to merge such a change without extremely widespread agreement. I am personally fine with a short-term small block size bump to kick the can down the road if that is what the ecosystem desires, but I can only agree with merging it in Core if I'm convinced that there is no strong opposition to it from others.

Soft forks on the other hand only require a majority of miners to accept them, and everyone else can upgrade at their leisure or not at all. Yes, old full nodes after a soft fork are not able to fully validate the rules new miners enforce anymore, but they do still verify the rules that their operators opted to enforce. Furthermore, they can't be prevented. For that reason, I've proposed, and am working hard, on an approach that includes Segregated Witness as a first step. It shows the ecosystem that something is being done, it kicks the can down the road, it solves/issues half a dozen other issues at the same time, and it does not require the degree of certainty needed for a hardfork.

I would also like to summarize my observation and thoughts after the Hong Kong workshop.

1. I'm so glad that I had this opportunity to meet so many smart developers who are dedicated to make Bitcoin better. Regular conference like this is very important for a young project, and it is particularly important for Bitcoin, with consensus as the core value. I hope such a conference could be conducted at least once in 2 years in Hong Kong, which is visa-friendly for most people in both East and West.

2. I think some consensus has emerged at/after the conference. There is no doubt that segregated witness will be implemented. For block size, I believe 2MB as the first step is accepted by the super majority of miners, and is generally acceptable / tolerable for devs.

3. Chinese miners are requesting consensus among devs nicely, instead of using their majority hashing power to threaten the community. However, if I were allowed to speak for them, I think 2MB is what they really want, and they believe it is for the best interest of themselves and the whole community

4. In the miners round table on the second day, one of the devs mentioned that he didn't want to be seen as the decision maker of Bitcoin. On the other hand, Chinese miners repeatedly mentioned that they want several concrete proposals from devs which they could choose. I see no contradiction between these 2 viewpoints.

Below are some of my personal views:

5. Are we going to have a "Fee Event" / "Economic Change Event" in 2-6 months as Jeff mentioned? Frankly speaking I don't know. As the fee starts to increase, spammers will first get squeezed --- which could be a good thing. However, I have no idea how many txs on the blockchain are spam. We also need to consider the effect of halving in July, which may lead to speculation bubble and huge legitimate tx volume.

6. I believe we should avoid a radical "Economic Change Event" at least in the next halving cycle, as Bitcoin was designed to bootstrap the adoption by high mining reward in the beginning. For this reason, I support an early and conservative increase, such as BIP102 or 2-4-8. 2MB is accepted by most people and it's better than nothing for BIP101 proponents. By "early" I mean to be effective by May, at least 2 months before the halving.

7. Segregated witness must be done. However, it can't replace a short-term block size hardfork for the following reasons: (a) SW softfork does not allow higher volume if users are not upgrading. In order to bootstrap the new tx type, we may need the help of altruistic miners to provide a fee discount for SW tx. (b) In terms of block space saving, SW softfork is most efficient for multisig tx, which is still very uncommon (c) My most optimistic guess is SW will be ready in 6 months, which will be very close to halving and potential tx volume burst. And it may not be done in 2016, as it does not only involve consensus code, but also change in the p2p protocol and wallet design

8. Duplex payment channel / Lightning Network may be viable solutions. However, they won't be fully functional until SW is done so they are irrelevant in this discussion

9. No matter what is going to be done / not done, I believe we should now have a clear road map and schedule for the community: a short-term hardfork or not? The timeline of SW? It is bad to leave everything uncertain and people can't well prepared for any potential radical changes

10. Finally, I hope this discussion remains educated and evidence-based, and no circling

On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille <pieter.wuille@gmail•com> wrote:

> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation•org> wrote:
> > 2) If block size stays at 1M, the Bitcoin Core developer team should
> sign a
> > collective note stating their desire to transition to a new economic
> policy,
> > that of "healthy fee market" and strongly urge users to examine their fee
> > policies, wallet software, transaction volumes and other possible User
> > impacting outcomes.
>
> You present this as if the Bitcoin Core development team is in charge
> of deciding the network consensus rules, and is responsible for making
> changes to it in order to satisfy economic demand. If that is the
> case, Bitcoin has failed, in my opinion.
>

This circles back to Problem #1: Avoidance of a choice is a still a choice - failing to ACK a MAX_BLOCK_SIZE increase still creates very real Economic Change Event risk.

And #3: If the likely predicted course is that Bitcoin Core will not accept a protocol change changing MAX_BLOCK_SIZE via hard fork in the short term, the core dev team should communicate that position clearly to users and media.

Hitting a Fee Event is market changing, potentially reshuffling economic actors to a notable degree. Maintaining a short term economic policy of fixed 1M supply in the face of rising transaction volume carries risks that should be analyzed and communicated.

On Wed, Dec 16, 2015 at 10:08 PM, Jeff Garzik <jgarzik@gmail•com> wrote:

>> You present this as if the Bitcoin Core development team is in charge
>> of deciding the network consensus rules, and is responsible for making
>> changes to it in order to satisfy economic demand. If that is the
>> case, Bitcoin has failed, in my opinion.
>
>
> This circles back to Problem #1:   Avoidance of a choice is a still a choice
> - failing to ACK a MAX_BLOCK_SIZE increase still creates very real Economic
> Change Event risk.

We are not avoiding a choice. We don't have the authority to make a choice.

> And #3:  If the likely predicted course is that Bitcoin Core will not accept
> a protocol change changing MAX_BLOCK_SIZE via hard fork in the short term,
> the core dev team should communicate that position clearly to users and
> media.

I indeed think we can communicate much better that deciding consensus rules is not within our power.

On Dec 16, 2015 10:08 PM, "Jeff Garzik via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation•org> wrote:

>
> On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille <pieter.wuille@gmail•com>

wrote:

>>
>> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
>> <bitcoin-dev@lists•linuxfoundation•org> wrote:
>> > 2) If block size stays at 1M, the Bitcoin Core developer team should

sign a

>> > collective note stating their desire to transition to a new economic

policy,

>> > that of "healthy fee market" and strongly urge users to examine their

fee

>> > policies, wallet software, transaction volumes and other possible User
>> > impacting outcomes.
>>
>> You present this as if the Bitcoin Core development team is in charge
>> of deciding the network consensus rules, and is responsible for making
>> changes to it in order to satisfy economic demand. If that is the
>> case, Bitcoin has failed, in my opinion.
>
>
> This circles back to Problem #1:   Avoidance of a choice is a still a

choice - failing to ACK a MAX_BLOCK_SIZE increase still creates very real Economic Change Event risk.

Unless the community is going to always avoid this "economic change event" forever (effectively eliminating MAX_BLOCK_SIZE), this is going to happen at some point. I assume those concerned with the "economic change" are only scared about it because "nitcoin is still very young" of something like that. Since you advocate for delaying this event from happening, can you be clearer about when do you think it would be ok to let the event happen? What other event makes this event ok?

> Hitting a Fee Event is market changing, potentially reshuffling economic

actors to a notable degree. Maintaining a short term economic policy of fixed 1M supply in the face of rising transaction volume carries risks that should be analyzed and communicated.

Assuming we adopt bip102, eventually you will be able to say exactly the same about 2 MB. When does this "let's not change the economics" finishes (if ever)?

On Wed, Dec 16, 2015 at 4:24 PM, Jorge Timón <jtimon@jtimon•cc> wrote:

> Assuming we adopt bip102, eventually you will be able to say exactly the
> same about 2 MB. When does this "let's not change the economics" finishes
> (if ever)?
>

The question is answered in the original email.

In the short term, the risk of a Fee Event and lack of solid post-Fee-Event economic plan implies "short term bump" reduces those risks.

It is also true - as noted in [1], a bump does create the danger of long term moral hazard.

This is why a bump should be accompanied with at least a weak public commitment to flexcap or a similar long term proposal, as the original email recommended. Communicate clearly the conditions for future change, then iterate as needs and feedback indicate.

[1] http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf

On Wed, Dec 16, 2015 at 1:36 PM, jl2012 <jl2012@xbt•hk> wrote:

> 4. In the miners round table on the second day, one of the devs mentioned
> that he didn't want to be seen as the decision maker of Bitcoin. On the
> other hand, Chinese miners repeatedly mentioned that they want several
> concrete proposals from devs which they could choose. I see no
> contradiction between these 2 viewpoints.
>

This was a very interesting dynamic, and seems fair (menu).

> 6. I believe we should avoid a radical "Economic Change Event" at least in
> the next halving cycle, as Bitcoin was designed to bootstrap the adoption
> by high mining reward in the beginning. For this reason, I support an early
> and conservative increase, such as BIP102 or 2-4-8. 2MB is accepted by most
> people and it's better than nothing for BIP101 proponents. By "early" I
> mean to be effective by May, at least 2 months before the halving.
>

That was precisely my logic for picking May 5 as the hard fork date. Some buffer before halving, enough for caution and iteration in the meantime.

>
> (c) My most optimistic guess is SW will be ready in 6 months, which will
> be very close to halving and potential tx volume burst. And it may not be
> done in 2016, as it does not only involve consensus code, but also change
> in the p2p protocol and wallet design
>

Not just wallet design -- you have to game through the standard steps of: update dev lib (bitcoin-core.js/bitcoinj) + release cycle, update app + release cycle, for most actors in the ecosystem, on top of the Bitcoin Core roll out.

On Wed, Dec 16, 2015 at 1:11 PM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:

> On Wed, Dec 16, 2015 at 10:08 PM, Jeff Garzik <jgarzik@gmail•com> wrote:
> >> You present this as if the Bitcoin Core development team is in charge
> >> of deciding the network consensus rules, and is responsible for making
> >> changes to it in order to satisfy economic demand. If that is the
> >> case, Bitcoin has failed, in my opinion.
> >
> >
> > This circles back to Problem #1:   Avoidance of a choice is a still a
> choice
> > - failing to ACK a MAX_BLOCK_SIZE increase still creates very real
> Economic
> > Change Event risk.
>
> We are not avoiding a choice. We don't have the authority to make a choice.
>
> > And #3:  If the likely predicted course is that Bitcoin Core will not
> accept
> > a protocol change changing MAX_BLOCK_SIZE via hard fork in the short
> term,
> > the core dev team should communicate that position clearly to users and
> > media.
>
> I indeed think we can communicate much better that deciding consensus
> rules is not within our power.
>

Indeed, because I sometimes find these statements to be confusing as well - I can completely understand what you mean if you're speaking from a moral standpoint. If you're saying that it's unacceptable for the Bitcoin Core developers to force consensus changes upon the system, I agree. But thankfully the design of the system does not allow the developers to do so. Developers can commit amazing code or terrible code, but it must be voluntarily adopted by the rest of the ecosystem. Core developers can't decide these changes, they merely propose them to the ecosystem by writing and releasing code.

I agree that Core developers have no authority to make these decisions on behalf of all of the network participants. However, they are in a position of authority when it comes to proposing changes. One of my takeaways from Hong Kong was that most miners have little interest in taking responsibility for consensus changes - they trust the Core developers to use their expertise to propose changes that will result in the continued operation of the network and not endanger their business operations.

A non-trivial portion of the ecosystem is requesting that the Core developers make a proposal so that the network participants can make a choice. Jeff noted that we can expect for the economic conditions of the network to change significantly in 2016, barring higher throughput capacity. If the year+ deployment timeframe for hard forks proposed by Matt on another thread is what we can expect for any proposed consensus change, then it should be non-contentious to announce that there will be no hard fork in 2016. This will give clarity to the rest of the ecosystem as to how they should prepare.

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

On Wed, Dec 16, 2015 at 1:11 PM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:

> I indeed think we can communicate much better that deciding consensus
> rules is not within our power.

I'm not a core dev, so maybe I have the power to change the consensus rules. No one has that power, actually, at least not legitimately. All we can do is build it and hope enough people find it acceptable to adopt. Who doesn't want to hard fork to 2MB blocks on May 5th and why not?

I have a bitcoin to be split up among all those who suffer from a May 5, 2016 hardfork to 2MB blocks if they can prove it to me, or prove it to enough engineers that I succumb to peer pressure. I would have to respect the engineers though.

There!

Now that we've agreed to have a hard fork on May 5th, 2016, we might decide to implement some other methods of avoiding the FFM, like braiding the blockchain or flexcap, or just let anyone mining on top of a block make one that is a five or ten Kb larger.

notplato

On Wed, Dec 16, 2015 at 2:27 PM, Jeff Garzik via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:

> On Wed, Dec 16, 2015 at 1:36 PM, jl2012 <jl2012@xbt•hk> wrote:
>
>> 4. In the miners round table on the second day, one of the devs mentioned
>> that he didn't want to be seen as the decision maker of Bitcoin. On the
>> other hand, Chinese miners repeatedly mentioned that they want several
>> concrete proposals from devs which they could choose. I see no
>> contradiction between these 2 viewpoints.
>>
>
> This was a very interesting dynamic, and seems fair (menu).
>
>
>
>> 6. I believe we should avoid a radical "Economic Change Event" at least
>> in the next halving cycle, as Bitcoin was designed to bootstrap the
>> adoption by high mining reward in the beginning. For this reason, I support
>> an early and conservative increase, such as BIP102 or 2-4-8. 2MB is
>> accepted by most people and it's better than nothing for BIP101 proponents.
>> By "early" I mean to be effective by May, at least 2 months before the
>> halving.
>>
>
> That was precisely my logic for picking May 5 as the hard fork date.  Some
> buffer before halving, enough for caution and iteration in the meantime.
>
>
>
>
>
>
>>
>> (c) My most optimistic guess is SW will be ready in 6 months, which will
>> be very close to halving and potential tx volume burst. And it may not be
>> done in 2016, as it does not only involve consensus code, but also change
>> in the p2p protocol and wallet design
>>
>
> Not just wallet design -- you have to game through the standard steps of:
>  update dev lib (bitcoin-core.js/bitcoinj) + release cycle, update app +
> release cycle, for most actors in the ecosystem, on top of the Bitcoin Core
> roll out.
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

On Wed, Dec 16, 2015 at 9:11 PM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:

> We are not avoiding a choice. We don't have the authority to make a choice.
>

This is really the most important question.

Bitcoin is kind of like a republic where there is separation of powers between various groups.

The power blocs in the process include

- Core Devs
- Miners
- Exchanges
- Merchants
- Customers

Complete agreement is not required for a change. If merchants and their customers were to switch to different software, then there is little any of the other groups could do.

Consensus is nice, certainly, and it is a good social norm to seek widespread agreement before committing to a decision above objection. Committing to no block increase is also committing to a decision against objections.

Having said that, each of the groups are not equal in power and organisation.

Merchants and their customers have potentially a large amount of power, but they are disorganised. There is little way for them to formally express a view, much less put their power behind making a change. Their potential power is crippled by public action problems.

On the other extreme is the core devs. Their power is based on legitimacy due to having a line of succession starting with Satoshi and respect gained due to technical and political competence. Being a small group, they are organised and they are also more directly involved.

The miners are less centralised, but statements supported by the majority of the hashing power are regularly made. The miners' position is that they want dev consensus. This means that they have delegated their decision making to the core devs.

The means that the two most powerful groups in Bitcoin have given the core devs the authority to make the decision. They don't have carte blanche from the miners.

If the core devs made the 2MB hard-fork with a 75% miner threshold, it is highly likely that the other groups would accept it.

That is the only authority that exists in Bitcoin. The check is that if the authority is abused, the other groups can simply leave (or use checkpointing)

On Thu, Dec 17, 2015 at 04:58:02PM +0000, Tier Nolan via bitcoin-dev wrote:

> This is really the most important question.
>
> Bitcoin is kind of like a republic where there is separation of powers
> between various groups.
>
> The power blocs in the process include
>
> - Core Devs
> - Miners
> - Exchanges
> - Merchants
> - Customers
>
> Complete agreement is not required for a change.  If merchants and their
> customers were to switch to different software, then there is little any of
> the other groups could do.

If Bitcoin remains decentralized, miners have veto power over any blocksize increases. You can always soft-fork in a blocksize reduction in a decentralized blockchain that actually works.

On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille <pieter.wuille@gmail•com> wrote:

> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation•org> wrote:
> > 2) If block size stays at 1M, the Bitcoin Core developer team should
> sign a
> > collective note stating their desire to transition to a new economic
> policy,
> > that of "healthy fee market" and strongly urge users to examine their fee
> > policies, wallet software, transaction volumes and other possible User
> > impacting outcomes.
>
> You present this as if the Bitcoin Core development team is in charge
> of deciding the network consensus rules, and is responsible for making
> changes to it in order to satisfy economic demand. If that is the
> case, Bitcoin has failed, in my opinion.
>

Diverging from the satoshi block size change plan[1] and current economics would seem to require a high level of months-ahead communication to users.

> all. Yes, old full nodes after a soft fork are not able to fully
> validate the rules new miners enforce anymore, but they do still
> verify the rules that their operators opted to enforce. Furthermore,
> they can't be prevented. For that reason, I've proposed, and am
> working hard, on an approach that includes Segregated Witness as a
> first step. It shows the ecosystem that something is being done, it
> kicks the can down the road, it solves/issues half a dozen other
> issues at the same time, and it does not require the degree of
> certainty needed for a hardfork.
>

Segregated Witness does not kick the can, it solves none of the problems #1, #3 - #8 explicitly defined and listed in email #1.

1) A plan of "SW + no hard fork" is gambling with ECE risk, gambling there will be no Fee Event, because the core block size is still heavily contended -- 100% contended at time out SW rollout.

2) We are only 100% certain that bitcoin works in the blocks-not-full-on-avg state, where there is a healthy buffer between the hard limit and the average block size.

There is remains major ECE risk due to the core block size freeze, possibly pushing the system into a new, untried economic state and causing major market and actor disruption. Users of the Service can still drift randomly and unpredictably into a Fee Event.

SW mitigates this - only after several months - only assuming robust adoption rates by up-layer ecosystem software, and - only assuming transaction volume growth is flat or sub-linear

Those conditions *must* go as planned to fulfill "SW kicked the can" -- a lot of if's.

As stated, SW is orthogonal to the drift-into-uncharted-waters problem outlined in email #1, which a short term bump does address.

On Thu, Dec 17, 2015 at 8:44 PM, Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:

> If Bitcoin remains decentralized, miners have veto power over any
> blocksize increases. You can always soft-fork in a blocksize reduction
> in a decentralized blockchain that actually works.

You can always schism hardfork miners out...

On Fri, Dec 18, 2015 at 6:11 AM, Jeff Garzik <jgarzik@gmail•com> wrote:

>> You present this as if the Bitcoin Core development team is in charge
>> of deciding the network consensus rules, and is responsible for making
>> changes to it in order to satisfy economic demand. If that is the
>> case, Bitcoin has failed, in my opinion.
>
> Diverging from the satoshi block size change plan[1] and current economics
> would seem to require a high level of months-ahead communication to users.

I don't see any plan, but will you say the same thing when the subsidy dwindles, and mining income seems to become uncertain? It will equally be an economic change, which equally well will have been predictable, and it will equally well be treatable with a hardfork to increase the subsidy.

Yes, I'm aware the argument above is a straw man, because there was clear expectation that the subsidy would go down asymptotically, and much less an expectation that the blocksize would remain fixed forever.

But I am not against a block size increase hard fork. My talk on segregated witness even included proposed pursuing a hard fork at a slightly later stage.

But what you're arguing for is that - despite being completely expected - blocks grew fuller, and people didn't adapt to block size pressure and a fee market, so the Core committee now needs to kick the can down the road, because we can't accept the risk of economic change. That sounds very much like a bailout to me.

Again. I am not against growth, but increasing in response to fear of economic change is the wrong approach. Economic change is inevitable.

> Segregated Witness does not kick the can, it solves none of the problems #1,
> #3 - #8 explicitly defined and listed in email #1.
>
> 1)  A plan of "SW + no hard fork" is gambling with ECE risk, gambling there
> will be no Fee Event, because the core block size is still heavily contended
> -- 100% contended at time out SW rollout.

That is an assumption. I expect demand for transactions at a given feerate to stop growing at a certain contention level (and we've reached some level of contention already, with mempools not being cleared for significant amounts of time already).

> SW mitigates this
> - only after several months

That is assuming a hard fork consensus forming, deployment, activation, ... goes faster than a softfork.

> - only assuming robust adoption rates by up-layer ecosystem software, and

That's not required. Everyone who individually switches to new transactions gets to do 1.75x more transactions for the same price (and at the same time gets safer contracts, better script upgradability, and more security models at their disposal), completely independent of whether anyone else in the ecosystem does the same.

> - only assuming transaction volume growth is flat or sub-linear

The only question is how many transactions for what price. Contention always happens at a specific feerate level anyway.

> Those conditions must go as planned to fulfill "SW kicked the can" -- a lot
> of if's.
>
> As stated, SW is orthogonal to the drift-into-uncharted-waters problem
> outlined in email #1, which a short term bump does address.

Both SW and a short bump (which is apparently not what BIP102 does anymore?) increase capacity available per price, and yes, they are completely orthogonal.

My only disagreement is the motivation (avoiding economic change, as opposed to aiming for safe growth) and the claim that a capacity increase hardfork is easier and safe(r) to roll out quickly than sortfork SW.

Apart from that, we clearly need to do both at some point.

On Thu, Dec 17, 2015 at 7:44 PM, Peter Todd <pete@petertodd•org> wrote:

> If Bitcoin remains decentralized, miners have veto power over any
> blocksize increases. You can always soft-fork in a blocksize reduction
> in a decentralized blockchain that actually works.
>

The actual users of the system have significant power, if they (could) choose to use it. There are "chicken" effects though. They can impose costs on the other participants but using those options harms themselves. If the cost of inaction is greater than the costs of action, then the chicken effects go away.

In the extreme, they could move away from decentralisation and the concept of miners and have a centralised checkpointing system. This would be a bankrupting cost to miners but at the cost to the users of the decentralised nature of the system.

At a lower extreme, they could change the mining hash function. This would devalue all of the miner's investments. A whole new program of ASIC investments would have to happen and the new miners would be significantly different. It would also establish that merchants and users are not to be ignored. On the other hand, bankrupting miners would make it harder to convince new miners to make the actual investments in ASICs required to establish security.

As a gesture, if merchants and exchanges wanted to get their "seat" at the table, they could create a representative group that insists on a trivial soft fork. For example, they could say that they will not accept any block from block N to block N + 5000 that doesn't have a specific bit set in the version.

Miners have an advantage where they can say that they have the majority of the hashing power. As part of the public action problem that merchants face, there is no equivalent metric.

On Fri, Dec 18, 2015 at 8:56 AM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:

>
> > - only assuming robust adoption rates by up-layer ecosystem software, and
>
> That's not required. Everyone who individually switches to new
> transactions gets to do 1.75x more transactions for the same price
> (and at the same time gets safer contracts, better script
> upgradability, and more security models at their disposal), completely
> independent of whether anyone else in the ecosystem does the same.
>
>

So hypothetically if wallets/payments processors/full nodes adoption will take 6 month to get to 50% after the segwit soft-fork activation, this means that actual network capacity will be increased by:

1.75 x 0.5 + 1 x 0.5 = 1.375

after six month.

An hard-fork on the others side would bring 1.75 since the activation, am I right?

On Fri, Dec 18, 2015 at 2:56 AM, Pieter Wuille <pieter.wuille@gmail•com> wrote:

> On Fri, Dec 18, 2015 at 6:11 AM, Jeff Garzik <jgarzik@gmail•com> wrote:
> >> You present this as if the Bitcoin Core development team is in charge
> >> of deciding the network consensus rules, and is responsible for making
> >> changes to it in order to satisfy economic demand. If that is the
> >> case, Bitcoin has failed, in my opinion.
> >
> > Diverging from the satoshi block size change plan[1] and current
> economics
> > would seem to require a high level of months-ahead communication to
> users.
>
> I don't see any plan, but will you say the same thing when the subsidy
>

Yes, I forgot the link:

[1] https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366

> dwindles, and mining income seems to become uncertain? It will equally
> be an economic change, which equally well will have been predictable,
> and it will equally well be treatable with a hardfork to increase the
> subsidy.
>

That is a red herring. Nobody I know has proposed this, and I am opposed to changing that fundamental.

It is well known that the 1M limit was never intended to stay, unlike 21M coin limit etc.

1M was set high in the beginning because it is a DoS engineering limit, not an [accidental] economic policy tool.

> But I am not against a block size increase hard fork. My talk on
> segregated witness even included proposed pursuing a hard fork at a
> slightly later stage.
>

Great!

> But what you're arguing for is that - despite being completely
> expected - blocks grew fuller, and people didn't adapt to block size
> pressure and a fee market, so the Core committee now needs to kick the
> can down the road, because we can't accept the risk of economic
> change. That sounds very much like a bailout to me.
>

I am arguing for continuing what we know works. We are 100% certain blocks-not-full-on-avg works, where a "buffer" of space exists between avg block size and hard limit.

Any other avenue is by definition speculation and risk. You _think_ you know what a healthy fee market _should_ be. Massive damage occurs to bitcoin if you are wrong - and I listed several

vis expectation, there is clear consensus and expectation that block size would increase, from 2010 onward. It was always a question of _when_ not if.

Sticking with 1M presents clear risk of (a) economic fracture and (b) community fracture. It quite clearly risks massive change to an unknown system at an unknown, unpredictable date in the future.

BIP 102 presents an expected upgrade at a predictable date in the future.

On Dec 18, 2015 2:13 AM, "sickpig@gmail•com" <sickpig@gmail•com> wrote:

> 1.75 x 0.5 + 1 x 0.5 = 1.375
>
> after six month.
>
> An hard-fork on the others side would bring 1.75 since the activation, am

I right?

Yes.

However, SW immediately gives a 1.75 capacity increase for anyone who adopts it, after the softfork, instantly. They don't need to wait for anyone else.

A hard fork is an orthogonal improvement, which is also needed if we don't want to be stuck with a constant maximum ultimately.

Hardforks can however only be deployed at a time when all full node software can reasonably have agreed to upgrade, while a softfork can be deployed much earlier.

They are independent improvements, and we need both. I am however of the opinion that hard forks need a much clearer consensus and much longer rollout timeframes to be safe (see my thread on the security of softforks).

I've already publicly declared that I offer one bitcoin to "those who suffer from a May 5, 2016 hardfork to 2MB blocks" but that's probably way too sloppy. Here's a better idea that transmits the economic power of merchants and customers (well, anyone with bitcoin) to the miners on whom they must rely for confirmations:

The bitcoin I offer is part of a fund that, when it reaches 25 BTC, will be pledged to a miner. Here is how that miner earns the reward:

   1. Wait until a core dev signs a release of bitcoin core in which the
   limit is double it's current level.
   2. Use the new release to mine, but use a soft limit on the blocksize to
   produce only blocks that are valid according to the old software.
   3. Wait until May 5th, 2016.
   4. Remove the soft limit on blocksize.
   5. Create a block that breaks the old limit and is valid according to
   the new signed release.
   6. Wait for the new large block to be orphaned.

Hopefully, the reward will be greater than 25 bitcoins and therefore cover the transaction fees. Of course, if they wait until after the halving in step 3, then they will get twice the (new, 12.5 btc) reward if they can arrange for the orphaning of their own block.

Any core dev could do this but I guess it would be playing with fire. So maybe Satoshi will do it. He played with fire (right?) and look how that worked out. Come on, someone, be a hero. Mike and Gavin tried, but I think they went a little overboard.

Another way to do this is to identify the position in each binary where the hard limit is stored, and write a little script that will (check the date first, and then) alter the data at that position so that currently running bitcoin software can be hot-patched on May 5th without the help of any core devs (if that would work). Obviously, the little script should be signed by a competent programmer whom the user trusts, a slightly less stringent requirement than being an actual core dev.

notplato

On Fri, Dec 18, 2015 at 7:48 AM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:

>
> On Dec 18, 2015 2:13 AM, "sickpig@gmail•com" <sickpig@gmail•com> wrote:
> > 1.75 x 0.5 + 1 x 0.5 = 1.375
> >
> > after six month.
> >
> > An hard-fork on the others side would bring 1.75 since the activation,
> am I right?
>
> Yes.
>
> However, SW immediately gives a 1.75 capacity increase for anyone who
> adopts it, after the softfork, instantly. They don't need to wait for
> anyone else.
>
> A hard fork is an orthogonal improvement, which is also needed if we don't
> want to be stuck with a constant maximum ultimately.
>
> Hardforks can however only be deployed at a time when all full node
> software can reasonably have agreed to upgrade, while a softfork can be
> deployed much earlier.
>
> They are independent improvements, and we need both. I am however of the
> opinion that hard forks need a much clearer consensus and much longer
> rollout timeframes to be safe (see my thread on the security of softforks).
>
> --
> Pieter
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

> You present this as if the Bitcoin Core development team is in charge
> of deciding the network consensus rules, and is responsible for
> making changes to it in order to satisfy economic demand. If that is
> the case, Bitcoin has failed, in my opinion.

Pieter, what's actually happening is that the bitcoin-core release has become a Schelling point in the consensus game:

https://en.wikipedia.org/wiki/Schelling_point

Due to the strong incentives for consensus, everyone is looking for an obvious reference point that they think everyone else will also pick, even though the point itself isn't critical, only that everyone agree on whatever point is picked. Like it or not, the bitcoin-core release, and by extension it's committers have a great degree of influence over what the community as a whole decides to do. If core screws things up badly enough, yes, the community will settle on some other focal point for consensus, but the cost and risk of doing so is high, so there is indeed unavoidable moral hazard for whoever has control over any such focus point.

Aaron Voisine co-founder and CEO breadwallet <http://breadwallet.com>

On Wed, Dec 16, 2015 at 10:34 AM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:

> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation•org> wrote:
> > 2) If block size stays at 1M, the Bitcoin Core developer team should
> sign a
> > collective note stating their desire to transition to a new economic
> policy,
> > that of "healthy fee market" and strongly urge users to examine their fee
> > policies, wallet software, transaction volumes and other possible User
> > impacting outcomes.
>
> You present this as if the Bitcoin Core development team is in charge
> of deciding the network consensus rules, and is responsible for making
> changes to it in order to satisfy economic demand. If that is the
> case, Bitcoin has failed, in my opinion.
>
> What the Bitcoin Core team should do, in my opinion, is merge any
> consensus change that is uncontroversial. We can certainly -
> individually or not - propose solutions, and express opinions, but as
> far as maintainers of the software goes our responsibility is keeping
> the system running, and risking either a fork or establishing
> ourselves as the de-facto central bank that can make any change to the
> system would greatly undermine the system's value.
>
> Hard forking changes require that ultimately every participant in the
> system adopts the new rules. I find it immoral and dangerous to merge
> such a change without extremely widespread agreement. I am personally
> fine with a short-term small block size bump to kick the can down the
> road if that is what the ecosystem desires, but I can only agree with
> merging it in Core if I'm convinced that there is no strong opposition
> to it from others.
>
> Soft forks on the other hand only require a majority of miners to
> accept them, and everyone else can upgrade at their leisure or not at
> all. Yes, old full nodes after a soft fork are not able to fully
> validate the rules new miners enforce anymore, but they do still
> verify the rules that their operators opted to enforce. Furthermore,
> they can't be prevented. For that reason, I've proposed, and am
> working hard, on an approach that includes Segregated Witness as a
> first step. It shows the ecosystem that something is being done, it
> kicks the can down the road, it solves/issues half a dozen other
> issues at the same time, and it does not require the degree of
> certainty needed for a hardfork.
>
> --
> Pieter
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

That's exactly the point: a hard fork does not just affect miners, and cannot just get decided by miners. All full nodes must have accepted the new rules, or they will be forked off when the hashrate percentage triggers.

Furthermore, 75% is pretty terrible as a switchover point, as it guarantees that old nodes will still see a 25% forked off chain temporarily.

My opinion is that the role of Bitcoin Core maintainers is judging whether consensus for a hard fork exists, and is technically necessary and safe. We don't need a hashpower vote to decide whether a hardfork is accepted or not, we need to be sure that full noded will accept it, and adopt it in time. A hashpower vote can still be used to be sure that miners _also_ agree.

Currently, a large amount of developers and others believe that the treshhold for a hardfork is not reached, especially given the fact that we scale in the short term, as well as make many changes that long-term benefit scalability, with just a softfork (which does not require forking off nodes that don't adopt the new rules, for whatever reason).

On Dec 26, 2015 5:45 PM, "Pieter Wuille via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation•org> wrote:

> My opinion is that the role of Bitcoin Core maintainers is judging

whether consensus for a hard fork exists, and is technically necessary and safe. We don't need a hashpower vote to decide whether a hardfork is accepted or not, we need to be sure that full noded will accept it, and adopt it in time. A hashpower vote can still be used to be sure that miners _also_ agree.

To clarify, that's the role of Bitcoin Core maintainers because they decide what goes into Bitcoin Core, not because they decide the consensus rules of Bitcoin. Other full node implementations (say, libbitcoin) will have to decide on their own and Bitcoin Core mainteiners don't have any authority over libbitcoin (or other alternative implementations). Nobody has such authority (not even the creator of the system if he was still maintaining Bitcoin Core).

On Dec 26, 2015, at 8:44 AM, Pieter Wuille via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:

> Furthermore, 75% is pretty terrible as a switchover point, as it guarantees that old nodes will still see a 25% forked off chain temporarily.
>

Yes, 75% plus a grace period is better. I prefer a grace period of about 4000 to 8000 blocks (1 to 2 months).

From my discussions with miners, I think we will be able to create a hardfork proposal that reaches about 90% support among miners, or possibly higher. I'll post a summary of those discussions in the next 24 hours.

On Dec 26, 2015 23:55, "Jonathan Toomim" <j@toom•im> wrote:

>
> On Dec 26, 2015, at 8:44 AM, Pieter Wuille via bitcoin-dev <

bitcoin-dev@lists•linuxfoundation•org> wrote:

>>
>> Furthermore, 75% is pretty terrible as a switchover point, as it

guarantees that old nodes will still see a 25% forked off chain temporarily.

>
> Yes, 75% plus a grace period is better. I prefer a grace period of about

4000 to 8000 blocks (1 to 2 months).

I think that's extremely short, even assuming there is no controversy about changing the rules at all. Things like BIP65 and BIP66 already took significantly longer than that, were uncontroversial, and only need miner adoption. Full node adoption is even slower.

I think the shortest reasonable timeframe for an uncontroversial hardfork is somewhere in the range between 6 and 12 months.

For a controversial one, not at all.

On Dec 26, 2015, at 3:01 PM, Pieter Wuille <pieter.wuille@gmail•com> wrote:

> I think that's extremely short, even assuming there is no controversy about changing the rules at all. Things like BIP65 and BIP66 already took significantly longer than that, were uncontroversial, and only need miner adoption. Full node adoption is even slower.
>

BIP65 and BIP66 were uncontroversial, but also generally uninteresting. Most people don't care about OP_CLTV right now, and they won't for quite a while longer. They neglect to upgrade their full nodes because there has been no reason to.

Given that a supermajority of users and miners have been asking for a hard fork to increase the blocksize for years, I do not think that mobilizing people to upgrade their nodes is going to be hard.

When we do the hard fork, we will need to encourage people to upgrade their full nodes. We may want to request that miners not trigger the fork until some percentage of visible full nodes have upgraded.

On 12/26/2015 05:01 PM, Pieter Wuille via bitcoin-dev wrote:

> I think the shortest reasonable timeframe for an uncontroversial
> hardfork is somewhere in the range between 6 and 12 months.

This argument would hold more weight if it didn't looks like a stalling tactic in context.

6 months ago, there was a concerted effort to being the process then, for exactly this reason.

After 6 months of denial, stonewalling, and generally unproductive fighting, the need for proactivity is being acknowledged with no reference to the delay.

If the network ever ends up making a hasty forced upgrade to solve a capacity emergency the responsibility for that difficulty will not fall on those who did their best to prevent emergency upgrades by planning ahead.

On Dec 27, 2015 00:06, "Jonathan Toomim" <j@toom•im> wrote:

> Given that a supermajority of users and miners have been asking for a

hard fork to increase the blocksize for years, I do not think that mobilizing people to upgrade their nodes is going to be hard.

>
> When we do the hard fork, we will need to encourage people to upgrade

their full nodes. We may want to request that miners not trigger the fork until some percentage of visible full nodes have upgraded.

I am generally not interested in a system where we rely on miners to make that judgement call to fork off nodes that don't pay attention and/or disagree with the change. This is not because I don't trust them, but because I believe one of the principle values of the system is that its consensus system should be hard to change.

I can't tell you what code to run of course, but I can decide what system I find interesting to build. And it seems many people have signed off on working towards a plan that does not include a hard fork being scheduled right now: https://bitcoin.org/en/bitcoin-core/capacity-increases

Cheers,

On Dec 26, 2015, at 3:16 PM, Pieter Wuille <pieter.wuille@gmail•com> wrote:

> I am generally not interested in a system where we rely on miners to make that judgement call to fork off nodes that don't pay attention and/or disagree with the change. This is not because I don't trust them, but because I believe one of the principle values of the system is that its consensus system should be hard to change.
>

I'm not proposing that we rely on miners' assessments of full node counts. I'm simply proposing that they serve as an extra layer of safety.

For the users that don't pay attention, I don't think the miners should be the sole parties to make that judgment call. That's why I suggested the grace period. I think that 1 or 2 months more than enough time for a business or active bitcoin user to download a new version of the software. I think that 1 or 2 months after a majority of nodes and miners have upgraded is more than more than enough time. For non-active businesses and users, there is no risk from the hard fork. If you're not transacting, you can't be defrauded.

Nodes that disagree with the change are welcome to continue to run the old version and watch the small fork if they so choose. Their numbers should be small if indeed this is an uncontroversial hardfork, but they won't be zero, and that's fine. The software supports this (except for peer discovery, which can get a little bit tricky in hardfork scenarios for the minority fork). Miners have no ethical obligation to protect individuals who choose not to follow consensus.

I think that use of the Alert System https://en.bitcoin.it/wiki/Alert_system would be justified in the weeks preceding the hard fork. Maybe we can create an "Upgrade now!" message that the new version would ignore, and set it to broadcast forever to all old nodes?

On Sat, Dec 26, 2015 at 5:15 PM, Justus Ranvier via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:

> On 12/26/2015 05:01 PM, Pieter Wuille via bitcoin-dev wrote:
> > I think the shortest reasonable timeframe for an uncontroversial
> > hardfork is somewhere in the range between 6 and 12 months.
>
> This argument would hold more weight if it didn't looks like a stalling
> tactic in context.
>

I think you'll find that there hasn't been stalling regarding an uncontroversial hard-fork deployment. You might be confusing an uncontroversial hard-fork decision instead with how developers have brought up many issues about various (hard-forking) block size proposals.... I suspect this is what you're intending to mention instead, given your mention of "capacity emergencies" and also the subject line.

> 6 months ago, there was a concerted effort to being the process then,
> for exactly this reason.
>

The uncontroversial hard-fork proposals from 6 months ago were mostly along the lines of jtimon's proposals, which were not about capacity. (Although, I should say "almost entirely uncontroversial"-- obviously has been some minor (and in my opinion, entirely solvable) disagreement regarding prioritization of deploying a jtimon's uncontroversial hard-fork idea I guess, seeing as how it has not yet happened.)

> After 6 months of denial, stonewalling, and generally unproductive
> fighting, the need for proactivity is being acknowledged with no
> reference to the delay.
>

There wasn't 6 months of "stonewalling" or "denial" about an uncontroversial hard-fork proposal. There has been extensive discussion regarding the controversial (flawed?) properties of other (block size) proposals. But that's something else. Much of this has been rehashed ad nauseum on this mailing list already... thankfully I think your future emails could be improved and made more useful if you were to read the mailing list archives, try to employ more careful reasoning, etc. Thanks.

> If the network ever ends up making a hasty forced upgrade to solve a
> capacity emergency the responsibility for that difficulty will not fall
> on those who did their best to prevent emergency upgrades by planning
> ahead.
>

("Capacity emergency" is too ambiguous in this context because of the competing concerns and tradeoffs regarding transaction rate capacity exhaustion vs. p2p low-bandwidth node bandwidth exhaustion.)

- Bryan http://heybryan.org/ 1 512 203 0507

On 12/26/2015 06:13 PM, Bryan Bishop wrote:

> I think you'll find that there hasn't been stalling regarding an
> uncontroversial hard-fork deployment. You might be confusing an
> uncontroversial hard-fork decision instead with how developers have
> brought up many issues about various (hard-forking) block size
> proposals.... I suspect this is what you're intending to mention
> instead, given your mention of "capacity emergencies" and also the
> subject line.

I think you'll find that writing in that tone makes one come across as a complete and utter douchebag.

I suspect what you're intending to do is to use faux-polite condescension to bait me into responding in a way to will justify my subsequent banning from this mailing list so that the people who aren't interested in answering certain uncomfortable questions will have a plausible excuse for preventing them from being asked here.

> There wasn't 6 months of "stonewalling" or "denial" about an
> uncontroversial hard-fork proposal. There has been extensive discussion
> regarding the controversial (flawed?) properties of other (block size)
> proposals. But that's something else. Much of this has been rehashed ad
> nauseum on this mailing list already...  thankfully I think your future
> emails could be improved and made more useful if you were to read the
> mailing list archives, try to employ more careful reasoning, etc. Thanks.

Actually there's been 3+ years of stonewalling, deception, conflicts of interest, and outright crimes, which have been generally ignored by those who are desperately attempting to assume good faith.

The purpose of my email was to remind everyone that nobody is going to get away with avoiding ownership of the consequences of their actions.

If the network experiences a painful upgrade because six months of time that could have been used to prepare a smooth upgrade was lost, the individuals who squandered that time own the result. They can't get around it by demanding six additional months, as if they had nothing to do with the six lost months.