path: root/70/027730786b7d2eaf864c003747f1a6d917451c

Return-Path: <jaredr26@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id EFA71B5A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Mar 2017 16:44:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f43.google.com (mail-vk0-f43.google.com
	[209.85.213.43])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CA085180
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Mar 2017 16:44:23 +0000 (UTC)
Received: by mail-vk0-f43.google.com with SMTP id r69so61471867vke.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Mar 2017 09:44:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=u59fsGYKTMKVxKYC6PpudhGAofJDRInKa6HddVEoXjA=;
	b=g/NZq/9cyDG9qVNywkMPh5xV2DvTVw5S7VbaryKjDX+DtYrYY+/JA2t2Jdd0hEkeLP
	dEB3nsJ1RqgOwT5+TZ0+OoCk7FHjLtKsdZnPOtoeY4EFY0zJwC2gh/Xl0KuZosMJJ4js
	ctls9soXHhSDAVqbqgHVE2G0Wif1ELizzDRGtFtwWLGZA/gzwVUivomnscHlYAFryi8J
	MKHvhD5kxFmnUNhqS2BEIhcKpUrqt1SoevjlX7asqpEvDlyi2gmszFuhfJBRKEzM8kMs
	LntEos97wVjuoHRR2KIUjMWbGJc9IErZ1vaOoUEp7grXl1F1j/Bv+1aaP3L28LpMAAIk
	mwfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=u59fsGYKTMKVxKYC6PpudhGAofJDRInKa6HddVEoXjA=;
	b=FGeGvAUrHdnBhHG21wqShUetOqnvAOHErlwWW3lENo9vZ2sHyj6eHWcuc0LCaioMCB
	LYCxVbhsrwX/2iEhNEFObUHa0W562gIICacWXMPR55rE1nVHFFDSqWcPSMIxur0Agblk
	ppBnYucNgM2WWFELOeO7Ykc/c3VHLfmvgn5AzgrDch6+tsPIfkXYYsJL6uheZx9W0oYx
	R5YD9lt4vNndxXD5vO5Hc8STY3g9O0uk/5uqpO0/onDMeEy80WxxnujjAH5dQpB3EEUz
	lj5cmCvdCQ/t4S1vUx36dc2uYlB/IodfeT+etOVFc5a2QtnyocveH6V+iR6uaz6NUKeB
	/zNw==
X-Gm-Message-State: AFeK/H2KqcbnT1VPgFuf+TaLPH3+VP+X0Qzqpx1hbuXSJ3dCS5ozC8KKHsrw7xaMkWP5HydpUm3qoMbzx/kIbw==
X-Received: by 10.31.92.69 with SMTP id q66mr296545vkb.119.1490892262762; Thu,
	30 Mar 2017 09:44:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.157.143 with HTTP; Thu, 30 Mar 2017 09:44:21 -0700 (PDT)
In-Reply-To: <1715389.dpD6Bbpm7b@strawberry>
References: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com>
	<2349f523-942c-ffb9-7af2-5cc81264888f@gmail.com>
	<127281C1AA02374F8AAD9EE04FAE878A0218E8B825@STUDMail1.muad.local>
	<1715389.dpD6Bbpm7b@strawberry>
From: Jared Lee Richardson <jaredr26@gmail.com>
Date: Thu, 30 Mar 2017 09:44:21 -0700
Message-ID: <CAD1TkXuCFHL7zvCth+huHH2zhGZY=8gpzFoRk5OzXs-EzpH4Lg@mail.gmail.com>
To: Tom Zander <tomz@freedommail.ch>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a114f6e0cb872e2054bf567a7
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 30 Mar 2017 16:46:28 +0000
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Thu, 30 Mar 2017 16:44:25 -0000

--001a114f6e0cb872e2054bf567a7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> The block size itself should be set based on the amount of fees being
paid to miners to make a block.

There's a formula to this as well, though going from that to a blocksize
number will be very difficult.  Miner fees need to be sufficient to
maintain economic protection against attackers.  There is no reason that
miner fees need to be any higher than "sufficient."  I believe that
"sufficient" value can be estimated by considering a potential attacker
seeking to profit from short-selling Bitcoin after causing a panic crash.
If they can earn more profit from shorting Bitcoin than it costs to buy,
build/deploy, and perform a 51% attack to shut down the network, then we
are clearly vulnerable.  The equation for the profit side of the equation
can be worked out as:

(bitcoin_price * num_coins_shortable * panic_price_drop_percentage)

The equation for the cost side of the equation depends on the total amount
of miner hardware that the network is sustainably paying to operate,
factoring in all costs of the entire bitcoin mining lifecycle(HW cost,
deployment cost, maintenance cost, electricity, amortized facilities cost,
business overheads, orphan losses, etc) except chip design, which the
attacker may be able to take advantage of for free.  For convenience I'm
simplifying that complicated cost down to a single number I'm calling
"hardware_lifespan" although the concept is slightly more involved than
that.

(total_miner_payouts * bitcoin_price * hardware_lifespan)

Bitcoin_price is on boths ides of the equation and so can be divided out,
giving:

Unsafe point =3D (num_coins_shortable * panic_price_drop_percentage) <
(total_miner_payouts
* hardware_lifespan)

Estimating the total number of shortable coins an attacker of nearly
unlimited funds is tricky, especially when things like high leverage levels
or naked short selling may be offered by exchanges.  The percent of damage
the resulting panic would cause is also tricky to estimate, but on both
numbers we can make some rough guesses and see how they play out.  With
more conservative numbers like say, 2 year hardware lifespan, 10% short,
70% panic drop you get: 1,300k coins profit, 1800 BTC/day in fees minimum
needed to make the attack cost more than it profits.

Using various inputs and erring on the side of caution, I get a minimum
BTC/day fee range of 500-2000.  Unfortunately if the blocksize isn't
increased, a relatively small number of transactions/users have to bear the
full cost of the minimum fees, over time increasing the minimum "safe"
average fee paid to 0.008 BTC, 30x the fees people are complaining about
today, and increasing in real-world terms as price increases.  All that
said, I believe the costs for node operation are the number that gets hit
first as blocksizes are increased, at least past 2020.  I don't think
blocksizes could be increased to such a size that the insufficient-fee
vulnerability would be a bigger concern than high node operational costs.
The main thing I don't have a good grasp on at the moment is any math to
estimate how many nodes we need to protect against the attacks that can
come from having few nodes, or even a clear understanding of what those
attacks are.

> A block so big that 100% of the transactions will always be mined in the
> next block will just cause a large section of people to no longer feel th=
e
> need to pay fees.

This is also totally true.  A system that tried to eliminate the fee
markets would be flawed, and fortunately miners have significant reasons to
oppose such a system.

The reverse is also a problem - If miners as a large group sought to lower
blocksizes to force fee markets higher, that could be a problem.  I don't
have solutions for the issue at this time, but something I've turned over
in my mind.

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

> On Thursday, 30 March 2017 07:23:31 CEST Ryan J Martin via bitcoin-dev
> wrote:
> >      The original post and the assorted limit proposals---lead me to
> > something I think is worth reiterating: assuming Bitcoin adoption
> > continues to grow at similar or accelerating rates, then eventually the
> > mempool is going to be filled with thousands of txs at all times whethe=
r
> > block limits are 1MB or 16MB
>
> This is hopefully true. :)
>
> There is an unbounded amount of demand for block space, and as such it
> doesn=E2=80=99t benefit anyone if the amount of free transactions get out=
 of hand.
> Because freeloaders would definitely be able to completely suffocate
> Bitcoin.
>
> In the mail posted by OP he makes clear that this is a proposal for a har=
d
> fork to change the block size *limit*. The actual block size would not be
> changed at the same time, it will continue being set based on market valu=
es
> or whatever we decide between now and then.
>
> The block size itself should be set based on the amount of fees being pai=
d
> to miners to make a block.
>
> What we want is a true fee-market where the miner can decide to make a
> block
> smaller to get people to pay more fees, because if we were to go to 16MB
> blocks in one go, the cost of the miner would go up, but his reward based
> on
> fees will go down!
> A block so big that 100% of the transactions will always be mined in the
> next block will just cause a large section of people to no longer feel th=
e
> need to pay fees.
>
> As such I don=E2=80=99t fear the situation where the block size limit goe=
s up a lot
> in one go, because it is not in anyone=E2=80=99s interest to make the act=
ual block
> size follow.
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">&gt;=C2=A0<span style=3D"font-size:12.8px">The block size =
itself should be set based on the amount of fees being paid=C2=A0to miners =
to make a block.</span><br><br><span style=3D"font-size:12.8px">There&#39;s=
 a formula to this as well, though going from that to a blocksize number wi=
ll be very difficult.=C2=A0 Miner fees need to be sufficient to maintain ec=
onomic protection against attackers.=C2=A0 There is no reason that miner fe=
es need to be any higher than &quot;sufficient.&quot; =C2=A0I believe that =
&quot;sufficient&quot; value can be estimated by considering a potential at=
tacker seeking to profit from short-selling Bitcoin after causing a panic c=
rash.=C2=A0 If they can earn more profit from shorting Bitcoin than it cost=
s to buy, build/deploy, and perform a 51% attack to shut down the network, =
then we are clearly vulnerable.=C2=A0 The equation for the profit side of t=
he equation can be worked out as:=C2=A0</span><br><br><span style=3D"font-s=
ize:12.8px">(bitcoin_price * num_coins_shortable * panic_price_drop_percent=
age)<br></span><br>The equation for the cost side of the equation depends o=
n the total amount of miner hardware that the network is sustainably paying=
 to operate, factoring in all costs of the entire bitcoin mining lifecycle(=
HW cost, deployment cost, maintenance cost, electricity, amortized faciliti=
es cost, business overheads, orphan losses, etc) except chip design, which =
the attacker may be able to take advantage of for free.=C2=A0 For convenien=
ce I&#39;m simplifying that complicated cost down to a single number I&#39;=
m calling &quot;hardware_lifespan&quot; although the concept is slightly mo=
re involved than that.<br><br>(total_miner_payouts * bitcoin_price * hardwa=
re_lifespan)<br><br>Bitcoin_price is on boths ides of the equation and so c=
an be divided out, giving:<br><br>Unsafe point =3D=C2=A0<span style=3D"font=
-size:12.8px">(num_coins_shortable * panic_price_drop_percentage) &lt;=C2=
=A0</span>(total_miner_payouts * hardware_lifespan)<br><br>Estimating the t=
otal number of shortable coins an attacker of nearly unlimited funds is tri=
cky, especially when things like high leverage levels or naked short sellin=
g may be offered by exchanges.=C2=A0 The percent of damage the resulting pa=
nic would cause is also tricky to estimate, but on both numbers we can make=
 some rough guesses and see how they play out.=C2=A0 With more conservative=
 numbers like say,=C2=A02 year hardware lifespan, 10% short, 70% panic drop=
 you get: 1,300k coins profit, 1800 BTC/day in fees minimum needed to make =
the attack cost more than it profits.<br><br>Using various inputs and errin=
g on the side of caution, I get a minimum BTC/day fee range of 500-2000.=C2=
=A0 Unfortunately if the blocksize isn&#39;t increased, a relatively small =
number of transactions/users have to bear the full cost of the minimum fees=
, over time increasing the minimum &quot;safe&quot; average fee paid to 0.0=
08 BTC, 30x the fees people are complaining about today, and increasing in =
real-world terms as price increases.=C2=A0 All that said, I believe the cos=
ts for node operation are the number that gets hit first as blocksizes are =
increased, at least past 2020.=C2=A0 I don&#39;t think blocksizes could be =
increased to such a size that the insufficient-fee vulnerability would be a=
 bigger concern than high node operational costs.=C2=A0 The main thing I do=
n&#39;t have a good grasp on at the moment is any math to estimate how many=
 nodes we need to protect against the attacks that can come from having few=
 nodes, or even a clear understanding of what those attacks are.<br><br>&gt=
;=C2=A0<span style=3D"font-size:12.8px">A block so big that 100% of the tra=
nsactions will always be mined in the</span><br style=3D"font-size:12.8px">=
<span style=3D"font-size:12.8px">&gt; next block will just cause a large se=
ction of people to no longer feel the</span><br style=3D"font-size:12.8px">=
<span style=3D"font-size:12.8px">&gt; need to pay fees.<br><br>This is also=
 totally true.=C2=A0 A system that tried to eliminate the fee markets would=
 be flawed, and fortunately miners have significant reasons to oppose such =
a system.<br></span><div><span style=3D"font-size:12.8px"><br></span></div>=
<div><span style=3D"font-size:12.8px">The reverse is also a problem - If mi=
ners as a large group sought to lower blocksizes to force fee markets highe=
r, that could be a problem.=C2=A0 I don&#39;t have solutions for the issue =
at this time, but something I&#39;ve turned over in my mind.</span></div><d=
iv><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Mar 30=
, 2017 at 3:30 AM, Tom Zander via bitcoin-dev <span dir=3D"ltr">&lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">On Thursday, 30 March 2017 07:23:31 CEST Ryan J Martin via bi=
tcoin-dev<br>
wrote:<br>
<span class=3D"">&gt;=C2=A0 =C2=A0 =C2=A0 The original post and the assorte=
d limit proposals---lead me to<br>
&gt; something I think is worth reiterating: assuming Bitcoin adoption<br>
&gt; continues to grow at similar or accelerating rates, then eventually th=
e<br>
&gt; mempool is going to be filled with thousands of txs at all times wheth=
er<br>
&gt; block limits are 1MB or 16MB<br>
<br>
</span>This is hopefully true. :)<br>
<br>
There is an unbounded amount of demand for block space, and as such it<br>
doesn=E2=80=99t benefit anyone if the amount of free transactions get out o=
f hand.<br>
Because freeloaders would definitely be able to completely suffocate Bitcoi=
n.<br>
<br>
In the mail posted by OP he makes clear that this is a proposal for a hard<=
br>
fork to change the block size *limit*. The actual block size would not be<b=
r>
changed at the same time, it will continue being set based on market values=
<br>
or whatever we decide between now and then.<br>
<br>
The block size itself should be set based on the amount of fees being paid<=
br>
to miners to make a block.<br>
<br>
What we want is a true fee-market where the miner can decide to make a bloc=
k<br>
smaller to get people to pay more fees, because if we were to go to 16MB<br=
>
blocks in one go, the cost of the miner would go up, but his reward based o=
n<br>
fees will go down!<br>
A block so big that 100% of the transactions will always be mined in the<br=
>
next block will just cause a large section of people to no longer feel the<=
br>
need to pay fees.<br>
<br>
As such I don=E2=80=99t fear the situation where the block size limit goes =
up a lot<br>
in one go, because it is not in anyone=E2=80=99s interest to make the actua=
l block<br>
size follow.<br>
<span class=3D"im HOEnZb">--<br>
Tom Zander<br>
Blog: <a href=3D"https://zander.github.io" rel=3D"noreferrer" target=3D"_bl=
ank">https://zander.github.io</a><br>
Vlog: <a href=3D"https://vimeo.com/channels/tomscryptochannel" rel=3D"noref=
errer" target=3D"_blank">https://vimeo.com/channels/<wbr>tomscryptochannel<=
/a><br>
</span><div class=3D"HOEnZb"><div class=3D"h5">____________________________=
__<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div></div></div>

--001a114f6e0cb872e2054bf567a7--