Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EFA71B5A for ; 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 ; Thu, 30 Mar 2017 16:44:23 +0000 (UTC) Received: by mail-vk0-f43.google.com with SMTP id r69so61471867vke.2 for ; 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: <2349f523-942c-ffb9-7af2-5cc81264888f@gmail.com> <127281C1AA02374F8AAD9EE04FAE878A0218E8B825@STUDMail1.muad.local> <1715389.dpD6Bbpm7b@strawberry> From: Jared Lee Richardson Date: Thu, 30 Mar 2017 09:44:21 -0700 Message-ID: To: Tom Zander , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
>=C2=A0The block size = itself should be set based on the amount of fees being paid=C2=A0to miners = to make a block.

There'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 "sufficient." =C2=A0I believe that = "sufficient" 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

(bitcoin_price * num_coins_shortable * panic_price_drop_percent= age)

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'm simplifying that complicated cost down to a single number I'= m calling "hardware_lifespan" although the concept is slightly mo= re involved than that.

(total_miner_payouts * bitcoin_price * hardwa= re_lifespan)

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

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

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.

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

>= ;=C2=A0A block so big that 100% of the tra= nsactions will always be mined in the
= > next block will just cause a large se= ction of people to no longer feel the
= > need to pay fees.

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.

=
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'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 bi= tcoin-dev
wrote:
>=C2=A0 =C2=A0 =C2=A0 The original post and the assorte= d limit proposals---lead me to
> something I think is worth reiterating: assuming Bitcoin adoption
> continues to grow at similar or accelerating rates, then eventually th= e
> mempool is going to be filled with thousands of txs at all times wheth= er
> 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 o= f hand.
Because freeloaders would definitely be able to completely suffocate Bitcoi= n.

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 changed at the same time, it will continue being set based on market values=
or whatever we decide between now and then.

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

What we want is a true fee-market where the miner can decide to make a bloc= k
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 o= n
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 the<= br> need to pay fees.

As such I don=E2=80=99t fear the situation where the block size limit goes = up a lot
in one go, because it is not in anyone=E2=80=99s interest to make the actua= l block
size follow.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel<= /a>
____________________________= ___________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

--001a114f6e0cb872e2054bf567a7--