From: Tom Zander <tomz@freedommail•ch>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP - 'Block75' - New algorithm
Date: Mon, 02 Jan 2017 23:33:16 +0100 [thread overview]
Message-ID: <2491464.ujv6hLnuF3@cherry> (raw)
In-Reply-To: <CAGCNRJpBMEha+cqXbgL6z9Fk5aoDOJF8tHu+XhYmMtgmdY2osw@mail.gmail.com>
On Monday, 2 January 2017 16:05:58 CET t. khan wrote:
> On Mon, Jan 2, 2017 at 3:35 PM, Tom Zander <tomz@freedommail•ch> wrote:
> > If the input of your math is completely free and human created, how does
> > it follow that it was math that created it ?
> > Why do you want it math created anyway?
>
> The beauty of math is that everyone on the planet agrees how it works.
> Everything in Bitcoin is math, with the exception of the blocksize limit
> (1MB) which was a stop-gap solution at the time.
In actual fact the block size *is* set by miners, not math. And always has
been.
In your proposal the max blocksize continues to be set by miners as a
secondary effect of them choosing the block size.
Saying the max is actually math is painting an illusion that is rather thin
and easy to see through because every single usecase for your suggestion
starts with the choice of blocksize that a human makes. There is not really
any other input except some rather simple algorithm.
> > A maximum is needed, yes. But does it have to be part of the protocol?
> > A simple policy which is set by node operators (reject block if greater
> > than
> > X bytes) will solve this just fine, no?
>
> No. That would be an epic disaster. There's no such thing as a "simple
> policy" when humans are involved.
This is ignoring history where miners have successfully set policy on block
size for years now.
> Obviously no one would agree on what X
> bytes would be and you'd have some nodes rejecting blocks that others
> already accepted.
Not sure about your "obviously". I don't agree. In fact, there is plenty of
reason to think it does work.
Miners have always been the ones to decide on the block size, and they have
always done this in a coordinated fashion. This is a natural consequence of
the rather elegant (economic) design of Bitcoin.
* Miners earn more fee-based income when they produce bigger blocks.
* Miners take more risk of their blocks being orphaned with bigger blocks.
* Miners want to avoid emptying the memory pool every block as that removes
a total need for users to pay fees.
* Miners want to make sure the mempool does not become backlogged because
users that do not see their transactions confirmed will get disappointed and
find other means to do payments. Which hurts the price and in effect hurts
the miners income.
This behaviour in block size means blocks will not get huge and they will
not stay small either, because there are reasons for both. And so the size
will be something in the middle.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
next prev parent reply other threads:[~2017-01-02 22:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-02 18:04 t. khan
2017-01-02 19:01 ` Tom Zander
2017-01-02 19:32 ` t. khan
2017-01-02 20:35 ` Tom Zander
2017-01-02 21:05 ` t. khan
2017-01-02 22:33 ` Tom Zander [this message]
2017-01-02 21:19 ` Luke Dashjr
2017-01-02 22:01 ` Tom Zander
2017-01-03 14:28 ` t. khan
2017-02-13 11:21 ` Hampus Sjöberg
2017-01-02 20:04 ` Luke Dashjr
2017-01-02 20:41 ` t. khan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2491464.ujv6hLnuF3@cherry \
--to=tomz@freedommail$(echo .)ch \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox