Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 15A7EA88 for ; Thu, 30 Mar 2017 20:51:48 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f45.google.com (mail-vk0-f45.google.com [209.85.213.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2406C281 for ; Thu, 30 Mar 2017 20:51:47 +0000 (UTC) Received: by mail-vk0-f45.google.com with SMTP id r69so69471215vke.2 for ; Thu, 30 Mar 2017 13:51:47 -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=vlDwJIMBKsbtp9dPqzTMUN3/jaM5JNvkWTWl2xwDNoY=; b=A8NAR/dEoNTMgpMC8GV01+je9Nn9NaI/xnZX2g4GF36ulXJPlVZgnpaEyvFzMskg9S /ppprwQ3RahgPN8PVUlqML0qF9YtceKpb9q896oeKf/pNh+lNHzsp1TfU4ysfY7Y0Jw+ mlLO2MTjl7E3cgv+SrCuP8KUg04oHW/HjgJH6VdiCtW3IuXxbzHoKgYXC+RVJb9eEzYT rIF7POoJia7O5PprNtrlSlAPgdVsyHTH0BaPCyx2dRunjgfr1LRy91QoJGwNTj2w6Vjf cCU3+FxPoZVLYdOrtnMSOh3ioeb2lNz9/k1hs6rXrHNd8CkRDbjrXzAVpw4KMJDhaeXT xz6w== 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=vlDwJIMBKsbtp9dPqzTMUN3/jaM5JNvkWTWl2xwDNoY=; b=nEAX+hMFNC4Ffa+dOoNiymjiWDzfJjxmqcEX03ubQoNMM4We1rwcIfjhZALLK/caAz f3Q0Bquv1Pv33xno4s2RZis448Fh4K53wKrwoXugj9mPBHq601caWcptkNIxxap8BjPw IERcRz2rTgVYFCj8EPetzaEYd/qPF3KprHYJ5h+DFx4vYvzHzp8DCL3sP8hi7ugUHA62 NLLBwhHiA9ujlzDvArpu2g57smKPzWGSLngbjEgHN/VkUwwn8XbPFut80CyBzmdpZcU2 R2cAfqw/zE8OKV0Vpg4kIR/8iAb0hnB6vVtLJSmXtP1+cvACDq4nghnQ8VyvQJg8I3t9 JCHg== X-Gm-Message-State: AFeK/H0VU93GcxSDre53twte9QItUvOP+mSihErMFHDr21rm/XdJmZ8fsKaXSK2IvaC0aNMZqXupevi4rQJTIg== X-Received: by 10.31.164.198 with SMTP id n189mr929231vke.62.1490907106161; Thu, 30 Mar 2017 13:51:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.157.143 with HTTP; Thu, 30 Mar 2017 13:51:45 -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 13:51:45 -0700 Message-ID: To: Tom Zander , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a114158f074b9fd054bf8dc8f X-Spam-Status: No, score=-1.2 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, RCVD_IN_SORBS_SPAM 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 21:03:21 +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 20:51:48 -0000 --001a114158f074b9fd054bf8dc8f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > 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! I agree in concept with everything you've said here, but I think there's a frequent misconception that there's a certain level of miner payouts that miners "deserve" and/or the opposite, that miners "deserve" as little as possible. The 51% attacks that PoW's shields us from are relatively well defined, which can be used to estimate the minimum amount of sustainable fees for shielding. Beyond that minimum amount of fees, the best amount of fees for every non-miner is the lowest. Unfortunately miners could arbitrarily decide to limit blocksizes, and there's little except relay restrictions that everyone else could do about it. Fortunately miners so far have pushed for blocksize increases at least as much as anyone else, though the future when Bitcoin adoption stabilizes would be an unknown. > 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. FYI, I don't see this happening again ever, barring brief exceptions, unless there was a sudden blocksize change, which ideally we'd avoid ever happening. The stable average value of the transaction fee determines what kind of business use-cases can be built using Bitcoin. An average fee of $0.001 usd enables a lot more use cases than $0.10 average fees, and $50.00 average fees still have far more possible use cases than a $1000 average fee. If fees stabilize low, use cases will spring up to fill the blockspace, unless miners arbitraily seek to keep the fees above some level= . 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 > --001a114158f074b9fd054bf8dc8f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0What we want is= a true fee-market where the miner can decide to make a block
> smaller to ge= t people to pay more fees, because if we were to go to 16MB
> blocks in one g= o, the cost of the miner would go up, but his reward based on
> fees will go = down!

I agree in concept with everything you've said here, but I think t= here's a frequent misconception that there's a certain level of min= er payouts that miners "deserve" and/or the opposite, that miners= "deserve" as little as possible.=C2=A0 The 51% attacks that PoW&= #39;s shields us from are relatively well defined, which can be used to est= imate the minimum amount of sustainable fees for shielding.=C2=A0 Beyond th= at minimum amount of fees, the best amount of fees for every non-miner is t= he lowest.

Unfortunately miners could arbitrarily decide to limit bl= ocksizes, and there's little except relay restrictions that everyone el= se could do about it.=C2=A0 Fortunately miners so far have pushed for block= size increases at least as much as anyone else, though the future when Bitc= oin adoption stabilizes would be an unknown.

> A block so big tha= t 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
> need to pay fees.
FYI, I don't see this happening again ever, barring brief exceptio= ns, unless there was a sudden blocksize change, which ideally we'd avoi= d ever happening.=C2=A0 The stable=C2=A0average=C2=A0value of the tran= saction fee determines what kind of business use-cases can be built using B= itcoin.=C2=A0 An average fee of $0.001 usd enables a lot more use cases tha= n $0.10 average fees, and $50.00 average fees still have far more possible = use cases than a $1000 average fee.=C2=A0 If fees stabilize low, use cases = will spring up to fill the blockspace, unless miners arbitraily seek to kee= p the fees above some level.

On Thu, Mar 30, 2017 at 3:30 AM, Tom Zander via bit= coin-dev <bitcoin-dev@lists.linuxfoundation.org>= ; wrote:
On Thursday, 30 March 201= 7 07:23:31 CEST Ryan J Martin via bitcoin-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

--001a114158f074b9fd054bf8dc8f--