[bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jeff Garzik]

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

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.

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Pieter Wuille]

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[jl2012]

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jeff Garzik]

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

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.

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Pieter Wuille]

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.

-- 
Pieter

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jorge Timón]

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

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)?

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jeff Garzik]

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

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

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jeff Garzik]

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

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.

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jameson Lopp]

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

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
>

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Dave Scotese]

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

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


-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Tier Nolan]

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

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)

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Peter Todd]

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

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.

-- 
'peter'[:-1]@petertodd.org
000000000000000001bd68962863e6fa34e9776df361d4926912f52fc5f4b618

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jeff Garzik]

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

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.

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jorge Timón]

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Pieter Wuille]

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.

-- 
Pieter

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Tier Nolan]

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

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.

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[sickpig]

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

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?

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jeff Garzik]

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

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.

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Pieter Wuille]

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

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

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Dave Scotese]

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

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


-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Aaron Voisine]

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

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

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Pieter Wuille]

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

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).

-- 
Pieter
On Dec 26, 2015 17:25, "digitsu" <jerry.d.chan@bittoku.co.jp> wrote:

> So it seems that everyone is in agreement then, since a hard fork to 2M is
> orthogonal to SW, and also that core should not be involved in dictating
> what the consensus rules should be, then why not put BIP102 into play with
> a 75% mining majority activation and let the market decide.
>
> As it’s activation only involves the miners, and its implementation
> doesn’t affect users or exchanges, then it poses no complication to SW
> which can do done in parallel.
>
>
>
>

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jorge Timón]

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

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).

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jonathan Toomim]

[-- Attachment #1.1: Type: text/plain, Size: 585 bytes --]

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.

[-- Attachment #1.2: Type: text/html, Size: 940 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Pieter Wuille]

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

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.

-- 
Pieter

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jonathan Toomim]

[-- Attachment #1.1: Type: text/plain, Size: 999 bytes --]

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.

[-- Attachment #1.2: Type: text/html, Size: 1417 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Justus Ranvier]

[-- Attachment #1.1: Type: text/plain, Size: 775 bytes --]

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.



[-- Attachment #1.2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 23699 bytes --]

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Pieter Wuille]

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

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,

-- 
Pieter

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jonathan Toomim]

[-- Attachment #1.1: Type: text/plain, Size: 1834 bytes --]

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?

[-- Attachment #1.2: Type: text/html, Size: 2336 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Bryan Bishop]

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

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

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Justus Ranvier]

[-- Attachment #1.1: Type: text/plain, Size: 2100 bytes --]

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.



[-- Attachment #1.2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 23699 bytes --]

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