From: Peter Todd <pete@petertodd.org>
To: Tom Harding <tomh@thinlink.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
Date: Fri, 21 Aug 2015 15:21:53 -0700 [thread overview]
Message-ID: <20150821222153.GD7450@muck> (raw)
In-Reply-To: <55D7575B.6030505@thinlink.com>
[-- Attachment #1: Type: text/plain, Size: 2149 bytes --]
On Fri, Aug 21, 2015 at 09:52:43AM -0700, Tom Harding wrote:
> On 8/20/2015 5:37 PM, Peter Todd wrote:
> > On Thu, Aug 20, 2015 at 05:25:59PM -0700, Tom Harding via bitcoin-dev wrote: >> I found that small miners were not at all disadvantaged by large
> blocks. >> > > You used 20% as the size of the large miner, with all the
> small miners > having good connectivity with each other. > > That is
> *not* the scenario we're worried about. The math behind the > issue is
> that the a miner needs to get their blocks to at least 33% of > hashing
> power, but more than that is unnecessary and only helps their >
> competition; you simulated 20%, which is under that threshold. Equally,
> > why are you assuming the small miner group is well connected to each >
> other? > > You probably didn't get any replies because your experiment
> is obviously > wrong and misguided, and we're all busy. >
>
> I gave the small miners collectively the same hashrate as the large
> miners in the original test. I made them well-connected because
> everyone was well-connected intra-partition in the original test.
>
> I just varied one thing: the size of the miners. This is a principle of
> experiment design, in science.
>
> Next you'll probably claim that second-order and cross-term effects
> dominate. Maybe you can find the time to prove it.
This is a security issue: if you can find a likely scenario where the
system fails, that's a problem and we need to fix it.
You've taken the scenario where the system fails, and changed the
conditions to create a scenario where it works. That's not particularly
interesting or noteworthy.
To use a car analogy, Pieter Wuille has shown that the brake cylinders
have a fatigue problem, and if used in stop-and-go traffic regularly
they'll fail during heavy braking, potentially killing someone. You've
countered with a study of highway driving, showing that if the car is
only used on the highway the brakes have no issues, claiming that the
car design is perfectly safe.
--
'peter'[:-1]@petertodd.org
00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-08-21 22:21 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-18 12:13 [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap Upal Chakraborty
2015-08-18 17:26 ` Chris Wardell
2015-08-20 7:31 ` Jorge Timón
2015-08-20 10:23 ` Milly Bitcoin
2015-08-21 0:25 ` Tom Harding
2015-08-21 0:37 ` Peter Todd
2015-08-21 16:52 ` Tom Harding
2015-08-21 22:21 ` Peter Todd [this message]
2015-08-21 23:16 ` Tom Harding
2015-08-22 0:01 ` Peter Todd
2015-08-22 3:21 ` Jorge Timón
2015-08-22 6:26 ` Peter Todd
2015-08-23 23:41 ` Tom Harding
2015-08-24 2:27 ` Jorge Timón
2015-08-21 0:45 ` Milly Bitcoin
2015-08-21 0:58 ` Peter Todd
2015-08-21 1:30 ` Milly Bitcoin
2015-08-21 20:28 ` Jorge Timón
2015-08-21 12:13 ` Sriram Karra
2015-08-21 20:09 ` Jorge Timón
2015-08-18 19:44 ` cedric perronnet
2015-08-18 20:58 ` Danny Thorpe
2015-08-18 21:17 ` Chris Wardell
2015-08-19 17:21 ` Upal Chakraborty
-- strict thread matches above, loose matches on Subject: below --
2015-08-21 21:45 Upal Chakraborty
2015-08-20 15:02 Upal Chakraborty
2015-08-17 11:57 Rodney Morris
2015-08-17 12:38 ` Angel Leon
2015-08-17 12:43 ` Tier Nolan
2015-08-17 9:44 Upal Chakraborty
2015-08-17 9:54 ` Levin Keller
2015-08-17 9:59 ` Patrick Strateman
2015-08-17 10:51 ` Btc Drak
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=20150821222153.GD7450@muck \
--to=pete@petertodd.org \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=tomh@thinlink.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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