Re: [bitcoin-dev] Hard fork proposal from last week's meeting

[Jared Lee Richardson <jaredr26@gmail.com>]

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

> 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 the
> 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 whether
> > 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’t 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 hard
> 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
> 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 the
> need to pay fees.
>
> As such I don’t fear the situation where the block size limit goes up a lot
> in one go, because it is not in anyone’s interest to make the actual 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
>

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