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 17:01:27 -0700 [thread overview]
Message-ID: <20150822000127.GA5679@muck> (raw)
In-Reply-To: <55D7B157.904@thinlink.com>
[-- Attachment #1: Type: text/plain, Size: 1456 bytes --]
On Fri, Aug 21, 2015 at 04:16:39PM -0700, Tom Harding wrote:
> On 8/21/2015 3:21 PM, Peter Todd wrote:
> > 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.
>
> No. If we must play the analogy game, it was found that the car crashes
> when the brakes are bad (minority hash power partitioned) the radio is
> on (partitioned miners had small individual hashrate).
>
> I checked the scenario where only the radio is on, and found the car
> does not crash.
Incidentally, what's your acceptable revenue difference between a small
(1% hashing power) and large (%30 hashing power) miner, all else being
equal? (remember that we shouldn't preclude variance reduction
techniques such as p2pool and pooled-solo mode)
Equally, what kind of attacks on miners do you think we need to be able to
resist? E.g. DoS attacks, hacking, etc.
That would let me know if you're definition of "the brakes are bad"
corresponds to normal usage, or something that's not reasonable to
design for.
--
'peter'[:-1]@petertodd.org
00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 646 bytes --]
next prev parent reply other threads:[~2015-08-22 0:01 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-18 12:13 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
2015-08-21 23:16 ` Tom Harding
2015-08-22 0:01 ` Peter Todd [this message]
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=20150822000127.GA5679@muck \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=tomh@thinlink$(echo .)com \
/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