From: Tom Harding <tomh@thinlink•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Managing block size the same way we do difficulty (aka Block75)
Date: Sun, 18 Dec 2016 17:42:38 -0800 [thread overview]
Message-ID: <8e329517-4fdf-925a-4a23-98cdaf844b7c@thinlink.com> (raw)
In-Reply-To: <CAH+Axy7H547kSh8y7OHzGRh0a=o0FDZ7N0eG3f5oAMTUGKJ-Fw@mail.gmail.com>
James,
I share your conviction that miners are the natural gatekeepers of the
maximum block size.
The trouble I see with Block75 is that linear growth won't work forever.
Also, by reading actual and not miners' preferred max blocksize, this
proposal is sensitive to randomness in block timing and tx rate, and so
incentivizes miners to manipulate their block content unnaturally in
either the up or down direction to influence the calculation.
The EB/AD scheme of Bitcoin Unlimited recognizes implementation of the
max blocksize by miners, who publish their preferred max blocksize. But
it expects forks of unpredictable (probably short) length as network
behavior evolves.
BIP100, which also recognizes miner implementation of the max blocksize,
but has a change support threshold, and like Block75 defines the timing
of max blocksize increases, looks superior to me.
On 12/18/2016 1:53 PM, James MacWhyte via bitcoin-dev wrote:
> Hi All,
>
> I'm coming late to the party. I like the Block75 proposal.
>
> Multiple people have said miners would/could stuff blocks with
> insincere transactions to increase the block size, but it was never
> adequately explained what they would gain from this. If there aren't
> enough legitimate transactions to fill up the block, where do you plan
> to earn extra income once the block is bigger?
>
> Miners would be incentivized to include as many legitimate
> transactions as possible, but if propagation time is as big an issue
> as some of you have said it is, miners would also be incentivized to
> keep their blocks small enough to propagate. So why not give them the
> choice? Once the block size gets too big to propagate effectively,
> miners would be naturally incentivized to limit how much data they put
> in each block, finding the perfect balance.
>
> In my opinion, none of the downsides presented so far have been a good
> argument. Risk of a 51% attack is not unique to this proposal, saying
> "we could also do that with hardcoded limits" doesn't actually point
> out any problem with this proposal, and miners already have the
> ability to add or withhold transactions from their blocks.
>
> We trust our miners to serve us by acting in their own best interests,
> and this proposal simply gives them more options for doing that. If
> anyone can make a strong argument against that would earn top marks in
> a high school debate class, I'd love to hear it!
>
> James
>
next prev parent reply other threads:[~2016-12-19 1:42 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-05 15:27 t. khan
2016-12-10 10:44 ` s7r
2016-12-10 12:05 ` Hampus Sjöberg
2016-12-11 0:26 ` t. khan
2016-12-11 0:40 ` James Hilliard
2016-12-11 1:07 ` Bram Cohen
2016-12-11 17:11 ` s7r
2016-12-11 19:55 ` t. khan
2016-12-11 20:31 ` James Hilliard
2016-12-11 21:40 ` t. khan
2016-12-11 21:53 ` Bram Cohen
2016-12-11 21:55 ` James Hilliard
2016-12-11 22:30 ` t. khan
2016-12-11 20:38 ` Andrew Johnson
2016-12-11 23:22 ` s7r
2016-12-18 21:53 ` James MacWhyte
2016-12-19 1:42 ` Tom Harding [this message]
2016-12-10 23:12 ` Bram Cohen
2016-12-11 0:52 ` t. khan
[not found] <CAEgR2PEMPo3veqJat7OAps1DzTSNFJmJiRbkFgYKvYfxqdbUiw@mail.gmail.com>
[not found] ` <CAEgR2PELB1_s+o0Bj4Kj9vS27eoqP7gV_VS_6QHQtTUAOnMORg@mail.gmail.com>
[not found] ` <CAEgR2PFpGWxngq=fKGi7CC_d+=5YWzWwbEEsQNEifCuHAAPAHw@mail.gmail.com>
[not found] ` <CAEgR2PHnrsdaBiDgywvE9amK8_yPE_hBo0yYOYwUk4T8n7wnAQ@mail.gmail.com>
[not found] ` <CAEgR2PEgPkRe76hW0Jj7_Z1EdmmNTpTAOKGm_of2dG=XXUOtnA@mail.gmail.com>
[not found] ` <CAEgR2PHew+fcJWnAt+t8umcwKu4TkshH=AFJ-8MeYysud2MkBQ@mail.gmail.com>
[not found] ` <CAEgR2PEVwt_shiqwGjK6dPscRUTHayis0PaQO5Dj_fVEGGgaCQ@mail.gmail.com>
2016-12-10 12:23 ` Daniele Pinna
2016-12-10 17:39 ` Pieter Wuille
2016-12-11 3:17 ` Daniele Pinna
2016-12-11 5:29 ` Eric Voskuil
2016-12-11 9:21 ` Adam Back
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=8e329517-4fdf-925a-4a23-98cdaf844b7c@thinlink.com \
--to=tomh@thinlink$(echo .)com \
--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