path: root/ec/a4d2a18ab02d81d1d9ec9662183643c2e35baa

Return-Path: <jgarzik@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 4876CEC5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Dec 2015 14:54:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com
	[209.85.213.180])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2B0BCEC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Dec 2015 14:53:59 +0000 (UTC)
Received: by mail-ig0-f180.google.com with SMTP id to4so67593537igc.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Dec 2015 06:53:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=FNw+wQ7B5ztY3w9lknjzBgPemtkP8XuTLr+bGjR5vz8=;
	b=YIu4Z+SLP0ag5eW+ktJpn2WDA2RzkNHep8PcN6JxN0pzNB12DE0DkUSMky6HIlIZX1
	JbrhOeaRwxBMMKVTzTx8NzvoO73m3/RhkWPoZ9+/Brc2UUl7tcl+EzodUZdQdts4LvPR
	zpBlqNzFqpAjpSHUzqSEa8tNKMzX5DYcfwyRo3EGCfyf48IP+f851dxx3/vca8TDnNfh
	85Fs68k4laRldn/LM1b65oc47DR3x9Y+sN2LfIpeyA4/ZPCupQba+1KCdBB3XDQL3kT9
	AzQRIvv5ykkvlDF0MRlu90DutkYQetlevtp4tWjIKPYUuKs915P8ImmwzIyuMyjl2Bk8
	WSgg==
MIME-Version: 1.0
X-Received: by 10.50.111.193 with SMTP id ik1mr9911551igb.23.1450277638543;
	Wed, 16 Dec 2015 06:53:58 -0800 (PST)
Received: by 10.79.8.198 with HTTP; Wed, 16 Dec 2015 06:53:58 -0800 (PST)
Date: Wed, 16 Dec 2015 09:53:58 -0500
Message-ID: <CADm_WcasDuBsop55ZWcTb2FvccaoREg8K032rUjgQUQhQ3g=XA@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=047d7b3a9c1478a1440527051382
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: [bitcoin-dev] Block size: It's economics & user preparation & moral
	hazard
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Dec 2015 14:54:01 -0000

--047d7b3a9c1478a1440527051382
Content-Type: text/plain; charset=UTF-8

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.

--047d7b3a9c1478a1440527051382
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><span style=3D"font-size:13px">All,</span><div style=3D"fo=
nt-size:13px"><br></div><div style=3D"font-size:13px">Following the guiding=
 WP principle of Assume Good Faith, I&#39;ve been trying to boil down the e=
ssence of the message following Scaling Bitcoin.=C2=A0 There are key bitcoi=
n issues that remain outstanding and pressing, that are<i> orthogonal to LN=
 &amp; SW</i>.</div><div style=3D"font-size:13px"><br></div><div style=3D"f=
ont-size:13px">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.=C2=A0 Why do I do what I do -- Why not try to r=
eboot... just list those problems?</div><div style=3D"font-size:13px"><br><=
/div><div style=3D"font-size:13px">Definitions:</div><div style=3D"font-siz=
e:13px"><br></div><blockquote style=3D"font-size:13px;margin:0px 0px 0px 40=
px;border:none;padding:0px">FE - &quot;Fee Event&quot;, the condition where=
 main chain MSG_BLOCK is 95+% to hard limit for 7 or more days in row, &quo=
t;blocks generally full&quot; =C2=A0 This can also be induced by a miner sq=
ueeze (collective soft limit reduction).</blockquote><br style=3D"font-size=
:13px"><blockquote style=3D"font-size:13px;margin:0px 0px 0px 40px;border:n=
one;padding:0px"><div>Service - a view of bitcoin as a decentralized, facel=
ess, multi-celled, amorphous automaton cloud, that provides services in exc=
hange for payment</div><div><br></div></blockquote><blockquote style=3D"fon=
t-size:13px;margin:0px 0px 0px 40px;border:none;padding:0px"><div>Users - t=
otal [current | future] set of economic actors that pay money to the Servic=
e, and receive value (figuratively or literally) in return</div><div><br></=
div></blockquote><blockquote style=3D"font-size:13px;margin:0px 0px 0px 40p=
x;border:none;padding:0px">Block Size - This is short hand for MAX_BLOCK_SI=
ZE, the hard limit that requires, today, a hard fork to increase (excl. ext=
ension blocks etc.)</blockquote><br style=3D"font-size:13px"><div style=3D"=
font-size:13px">Guiding Principle:</div><div style=3D"font-size:13px"><br><=
/div><blockquote style=3D"font-size:13px;margin:0px 0px 0px 40px;border:non=
e;padding:0px">Keep the Service alive, secure, decentralized, and censorshi=
p resistant for as many Users as possible.</blockquote><br style=3D"font-si=
ze:13px"><div style=3D"font-size:13px">Observations on block size (shorthan=
d for MAX_BLOCK_SIZE as noted above):</div><div style=3D"font-size:13px"><b=
r></div><blockquote style=3D"font-size:13px;margin:0px 0px 0px 40px;border:=
none;padding:0px">This is economically modeled as a supply limited resource=
 over time.=C2=A0 On average, 1M capacity is available every 10 minutes, wi=
th variance.</blockquote><br style=3D"font-size:13px"><div style=3D"font-si=
ze:13px">Observations on Users, block size and modern bidding process:</div=
><div style=3D"font-size:13px"><br></div><blockquote style=3D"font-size:13p=
x;margin:0px 0px 0px 40px;border:none;padding:0px"><div>A supermajority of =
hashpower currently evaluates for block inclusion based, first-pass, on tx-=
fee/KB.=C2=A0 Good.</div><div><br></div></blockquote><blockquote style=3D"f=
ont-size:13px;margin:0px 0px 0px 40px;border:none;padding:0px"><div>The Ser=
vice is therefore responsive to the free market and some classes of DoS.=C2=
=A0 Good.</div><div><br></div></blockquote><blockquote style=3D"font-size:1=
3px;margin:0px 0px 0px 40px;border:none;padding:0px">Recent mempool changes=
 float relay fee, making the Service more responsive to fast moving markets=
 and DoS&#39;s.=C2=A0 Good progress.</blockquote><br style=3D"font-size:13p=
x"><blockquote style=3D"font-size:13px;margin:0px 0px 0px 40px;border:none;=
padding:0px">Service provided to Users can be modeled at the bandwidth reso=
urce level as bidding for position in a virtual priority queue, where up-to=
-1M bursts are cleared every 10 min (on avg etc.).=C2=A0 Not a perfectly fi=
xed supply, definitionally, but constrained within a fixed range.<br></bloc=
kquote><div style=3D"font-size:13px"><br></div><span style=3D"font-size:13p=
x">Observations on the state of today&#39;s fee market:</span><div style=3D=
"font-size:13px"><br></div><blockquote style=3D"font-size:13px;margin:0px 0=
px 0px 40px;border:none;padding:0px">On average, blocks are not full.=C2=A0=
 Economically, this means that fees trend towards zero, due to theoreticall=
y unlimited supply at &lt;1M levels.<br><br>Of course, fees are not zero.=
=C2=A0 The network relay anti-flood limits serve as an average lower limit =
for most transactions (excl direct-to-miner).=C2=A0 Wallet software also in=
troduces fee variance in interesting ways.=C2=A0 All this fee activity is r=
ange-bound on the low end.<br><br>Let the current set of Users + transactio=
n fee market behavior be TFM (today&#39;s fee market).<br>Let the post-Fee-=
Event set of Users + transaction fee market behavior be FFM (future fee mar=
ket).<br><br></blockquote><div style=3D"font-size:13px"><b>Key observation:=
 =C2=A0 A Bitcoin Fee Event (see def. at top) is an Economic Change Event.<=
/b></div><div style=3D"font-size:13px"><br></div><blockquote style=3D"font-=
size:13px;margin:0px 0px 0px 40px;border:none;padding:0px"><div>An Economic=
 Change Event is a period of market chaos, where large changes to prices an=
d sets of economic actors occurs over a short time period.</div><div><br></=
div></blockquote><blockquote style=3D"font-size:13px;margin:0px 0px 0px 40p=
x;border:none;padding:0px">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.<br><b=
r><b>It is a major change to how current Users experience and pay for the S=
ervice</b>, state change from TFM to FFM.<br><br>The game theory bidding be=
havior is different for a mostly-empty resource versus a usually-full resou=
rce.=C2=A0 Prices are different.=C2=A0 Profitable business models are diffe=
rent.=C2=A0 Users (the set of economic actors on the network) are different=
.<br></blockquote><div style=3D"font-size:13px"><br></div><span style=3D"fo=
nt-size:13px">Observation: =C2=A0Contentious hard fork is an Economic Chang=
e Event.</span><div style=3D"font-size:13px"><br></div><blockquote style=3D=
"font-size:13px;margin:0px 0px 0px 40px;border:none;padding:0px">Similarly,=
 a fork that partitions economic actors for an extended period or permanent=
ly is also an Economic Change Event, shuffling prices and economic actors a=
s the Service dynamically readjusts on both sides of the partition, and Use=
rs-A and Users-B populations change their behavior.</blockquote><div style=
=3D"font-size:13px"><br></div><div style=3D"font-size:13px"><br></div><span=
 style=3D"font-size:13px">Short-Term Problem #1: =C2=A0No-action on block s=
ize increase leads to an Economic Change Event.</span><br style=3D"font-siz=
e:13px"><div style=3D"font-size:13px"><blockquote style=3D"margin:0px 0px 0=
px 40px;border:none;padding:0px"><br>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.=C2=A0 Choosing FFM over T=
FM.<br><b><br>It is rational to reason that maintaining TFM is more conserv=
ative</b>=C2=A0than enduring an Economic Change Event from TFM to FFM.<br><=
b><br>It is rational to reason that maintaining similar prices and economic=
 actors is less disruptive.</b><br><br>Failure to increase block size will =
lead to a Fee Event sooner rather than later.<br><br>Failure to plan ahead =
for a Fee Event will lead to greater market chaos and User pain.<br></block=
quote><div><br></div>Short-Term=C2=A0Problem #2: =C2=A0Some Developers wish=
 to accelerate the Fee Event, and a veto can accomplish that.</div><div sty=
le=3D"font-size:13px"><br></div><blockquote style=3D"font-size:13px;margin:=
0px 0px 0px 40px;border:none;padding:0px"><div>In the current developer dyn=
amics, 1-2 key developers can and very likely would veto any block size inc=
rease.</div><div><br></div></blockquote><blockquote style=3D"font-size:13px=
;margin:0px 0px 0px 40px;border:none;padding:0px"><div>Thus a veto (e.g. no=
-action) can lead to a Fee Event, which leads to pricing actors out of the =
system.</div><div><br></div><div>A block size veto wields outsize economic =
power, because it can accelerate ECE.</div><div><b><br></b></div></blockquo=
te><blockquote style=3D"font-size:13px;margin:0px 0px 0px 40px;border:none;=
padding:0px"><div><b>This is an extreme moral hazard: =C2=A0A few Bitcoin C=
ore committers can veto increase and thereby reshape bitcoin economics, pri=
ce some businesses out of the system.=C2=A0 It is less of a moral hazard to=
 keep the current economics [by raising block size] and not exercise such p=
ower.</b></div></blockquote><div style=3D"font-size:13px"><br>Short-Term=C2=
=A0Problem #3: =C2=A0User communication and preparation</div><div style=3D"=
font-size:13px"><br></div><div style=3D"font-size:13px"><blockquote style=
=3D"margin:0px 0px 0px 40px;border:none;padding:0px">The current trajectory=
 of no-block-size-increase can lead to short time market chaos, actor chaos=
, businesses no longer viable.<br><br>In a $6.6B economy, it is criminal to=
 let the Service undergo an ECE without warning users loudly, months in adv=
ance: =C2=A0&quot;Dear users, ECE has accelerated potential due to develope=
rs preferring a transition from TFM to FFM.&quot;<br><br>As stated,=C2=A0<b=
>it is a conscious choice to change bitcoin economics and User experience</=
b>=C2=A0if block size is not advanced with a healthy buffer above actual av=
erage traffic levels.<br><br><b>Raising block size today, at TFM, produces =
a smaller fee market delta.</b><br><br>Further, wallet software User experi=
ence is very, very poor in a hyper-competitive fee market. =C2=A0 (This can=
 and will be improved; that&#39;s just the state of things today)</blockquo=
te><br><div>Short-Term Problem #4: =C2=A0User/Dev disconnect: =C2=A0 Large =
mass of users wishes to push Fee Event into future</div></div><div style=3D=
"font-size:13px"><br></div><blockquote style=3D"font-size:13px;margin:0px 0=
px 0px 40px;border:none;padding:0px"><div>Almost all bitcoin businesses, ex=
changes and miners have stated they want a block size increase.=C2=A0 See t=
he many media articles, BIP 101 letter, and wiki e.g.=C2=A0<a href=3D"https=
://en.bitcoin.it/wiki/Block_size_limit_controversy#Entities_positions" targ=
et=3D"_blank">https://en.bitcoin.it/wiki/Block_size_limit_controversy#Entit=
ies_positions</a></div><div><br></div></blockquote><blockquote style=3D"fon=
t-size:13px;margin:0px 0px 0px 40px;border:none;padding:0px"><div>The curre=
nt apparent-veto on block size increase runs contra to the desires of many =
Users. =C2=A0(note language: &quot;many&quot;, not claiming &quot;all&quot;=
)</div><div><br></div></blockquote><blockquote style=3D"font-size:13px;marg=
in:0px 0px 0px 40px;border:none;padding:0px"><b>It is a valid and rational =
economic choice to subsidize the system with lower fees in the beginning</b=
>.=C2=A0 Many miners, for example, openly state they prefer long term syste=
m growth over maximizing tiny amounts of current day income.<br><br>Vetoing=
 a block size increase has the effect of eliminating that economic choice a=
s an option.</blockquote><blockquote style=3D"font-size:13px;margin:0px 0px=
 0px 40px;border:none;padding:0px"><br></blockquote><blockquote style=3D"fo=
nt-size:13px;margin:0px 0px 0px 40px;border:none;padding:0px"><div>It is di=
fficult to measure Users; projecting beyond &quot;businesses and miners&quo=
t; is near impossible.</div><div><br></div></blockquote><blockquote style=
=3D"font-size:13px;margin:0px 0px 0px 40px;border:none;padding:0px">Without=
 exaggeration, I have never seen this much disconnect between user wishes a=
nd dev outcomes in 20+ years of open source.</blockquote><blockquote style=
=3D"font-size:13px;margin:0px 0px 0px 40px;border:none;padding:0px"><br></b=
lockquote><div style=3D"font-size:13px">Short-Term Problem #5: =C2=A0Higher=
 Service prices can negatively impact system security</div><div style=3D"fo=
nt-size:13px"><br></div><blockquote style=3D"font-size:13px;margin:0px 0px =
0px 40px;border:none;padding:0px"><div>Bitcoin depends on a virtuous cycle =
of users boosting and maintaining bitcoin&#39;s network effect, incentivizi=
ng miners, increasing security.</div><div><br></div></blockquote><blockquot=
e style=3D"font-size:13px;margin:0px 0px 0px 40px;border:none;padding:0px">=
<div>Higher prices that reduce bitcoin&#39;s user count and network effect =
can have the opposite impact.</div><div><br></div></blockquote><blockquote =
style=3D"font-size:13px;margin:0px 0px 0px 40px;border:none;padding:0px">(O=
bviously this is a dynamic system, users and miners react to higher prices.=
.. including actions that then reduce the price)<br><br></blockquote><span =
style=3D"font-size:13px">Short-Term Problem #6: =C2=A0Post-Fee-Event market=
 reboot problem + general lack of planning</span><div style=3D"font-size:13=
px"><br></div><blockquote style=3D"font-size:13px;margin:0px 0px 0px 40px;b=
order:none;padding:0px"><div>Game it out: =C2=A0 Blocks are now full (FFM).=
=C2=A0 Block size kept at 1M.</div><div><br></div></blockquote><blockquote =
style=3D"font-size:13px;margin:0px 0px 0px 40px;border:none;padding:0px"><d=
iv>How full is too full - who and what dictates when 1M should be increased=
?</div><div><br></div></blockquote><blockquote style=3D"font-size:13px;marg=
in:0px 0px 0px 40px;border:none;padding:0px">The same question remains, yet=
 now economic governance issues are compounded: =C2=A0In FFM, the fees are =
very tightly bound to the upper bound of the block size.=C2=A0 In TFM, fees=
 are much less sensitive to the upper bound of block size.</blockquote><div=
 style=3D"font-size:13px"><br></div><blockquote style=3D"font-size:13px;mar=
gin:0px 0px 0px 40px;border:none;padding:0px">Changing block size, when blo=
cks are full, has a more dramatic effect on the market - suddenly new suppl=
y is magically brought online, and a minor Economic Change Event occurs.<br=
><br>More generally, the post-Fee-Event next step has not been agreed upon.=
=C2=A0 Is it flexcap?=C2=A0 This key &quot;step #2&quot; is just barely at =
whiteboard stage.<br></blockquote><br style=3D"font-size:13px"><span style=
=3D"font-size:13px">Short-Term Problem #7: =C2=A0 Fee Event timing is unpre=
dictable.</span><div style=3D"font-size:13px"><br></div><blockquote style=
=3D"font-size:13px;margin:0px 0px 0px 40px;border:none;padding:0px"><div>As=
 block size free space gets tighter - that is the trend - and block size re=
mains at 1M, Users are ever more likely to hit an Economic Change Event.=C2=
=A0 It could happen in the next 2-6 months.</div><div><br></div></blockquot=
e><blockquote style=3D"font-size:13px;margin:0px 0px 0px 40px;border:none;p=
adding:0px"><div>Today, Users and wallets are not prepared.</div><div><br><=
/div></blockquote><blockquote style=3D"font-size:13px;margin:0px 0px 0px 40=
px;border:none;padding:0px">It is also understandably a very touchy subject=
 to say &quot;your business or use case might get priced out of bitcoin&quo=
t;</blockquote><div style=3D"font-size:13px"><br><blockquote style=3D"margi=
n:0px 0px 0px 40px;border:none;padding:0px"><div>But it is even worse to le=
t worse let Users run into a Fee Event without informing the market that th=
e block size will remain at 1M.</div><div><br></div></blockquote><blockquot=
e style=3D"margin:0px 0px 0px 40px;border:none;padding:0px">Markets functio=
n best with maximum knowledge - when they are informed well in advance of m=
arket shifting news and events, giving economic actors time to prepare.=C2=
=A0</blockquote><div><br></div><div>Short-Term Problem #8: =C2=A0 Very litt=
le testing, data, effort put into blocks-mostly-full economics</div><div><b=
><br></b></div></div><blockquote style=3D"font-size:13px;margin:0px 0px 0px=
 40px;border:none;padding:0px"><b>We only know for certain that blocks-most=
ly-not-full works.</b>=C2=A0 We do not know that changing to blocks-mostly-=
full works.<br><br>Changing to a new economic system includes boatloads of =
risk.<br><br>Very little data has been forthcoming from any party on what F=
FM might look like, following a Fee Event.</blockquote><div style=3D"font-s=
ize:13px"><br><div>Observation: =C2=A0 In the long run, it is assumed we ne=
ed a &quot;healthy fee market&quot;</div><div><br></div></div><blockquote s=
tyle=3D"font-size:13px;margin:0px 0px 0px 40px;border:none;padding:0px"><di=
v>Yes, absolutely.=C2=A0 In the long run, bitcoin was intended to be suppor=
ted by transaction fees and not the minting of new supply, and the design o=
f the system is to slowly wean Users off new supply and onto transaction fe=
es for supporting the Service.</div><div><br></div></blockquote><blockquote=
 style=3D"font-size:13px;margin:0px 0px 0px 40px;border:none;padding:0px"><=
div>While agreeing with the goal, it must be acknowledge that this is a vag=
ue and untested goal with many open economic questions -- more of a hope, r=
eally.</div><div><br></div></blockquote><blockquote style=3D"font-size:13px=
;margin:0px 0px 0px 40px;border:none;padding:0px">It is more conservative t=
o preserve current economics than to change to a new system with new econom=
ics and no notion of what-comes-next (flexcap?) in terms of system security=
, healthy sustainable market levels, and impact of changes during and follo=
wing an ECE.</blockquote><div><br></div><br style=3D"font-size:13px"><span =
style=3D"font-size:13px">Core recommendations:</span><div style=3D"font-siz=
e:13px"><br></div><div style=3D"font-size:13px"><div>1) &quot;Short term bu=
mp&quot; =C2=A0Block size increase to maintain buffer.=C2=A0 I&#39;ve no sp=
ecial BIP preference.</div><div><br></div><div>This avoids moral hazard and=
 avoids a major Economic Change Event, as well many other risks.</div><div>=
<br></div></div><div style=3D"font-size:13px"><br></div><div style=3D"font-=
size:13px">2) If block size stays at 1M, the Bitcoin Core developer team sh=
ould sign a collective note stating their desire to transition to a new eco=
nomic policy, that of &quot;healthy fee market&quot; and strongly urge user=
s to examine their fee policies, wallet software, transaction volumes and o=
ther possible User impacting outcomes.</div><div style=3D"font-size:13px"><=
br></div><div style=3D"font-size:13px"><br></div><div style=3D"font-size:13=
px">3) Even if can is kicked down the road, Fee Event will come eventually.=
 =C2=A0 Direct research, testing and simulations into the economics and use=
r impact side of the equation.=C2=A0 Research and experiment with pay-for-b=
urst (pay to future miner), flexcap and other solutions ASAP.</div><div sty=
le=3D"font-size:13px"><br></div><div style=3D"font-size:13px"><br></div><di=
v style=3D"font-size:13px">The worst possible outcome is letting the ecosys=
tem randomly drift into the first Fee Event without openly stating the new =
economic policy choices and consequences.</div><div style=3D"font-size:13px=
"><br></div><div style=3D"font-size:13px">The simple fact is=C2=A0<i>inacti=
on</i>=C2=A0on this supply-limited resource, block size, will change bitcoi=
n to a new economic shape and with different economic actors, selecting som=
e and not others.</div><div style=3D"font-size:13px"><br></div><div style=
=3D"font-size:13px">It is better to kick the can and gather crucial field d=
ata, because next-step (FFM) is very much not fleshed out.</div><div style=
=3D"font-size:13px"><br></div><div style=3D"font-size:13px"><br></div></div=
>

--047d7b3a9c1478a1440527051382--