From: Peter Todd <pete@petertodd•org>
To: Kyle Jerviss <kjj@jerviss•org>
Cc: Bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] we can all relax now
Date: Wed, 6 Nov 2013 23:33:10 -0500 [thread overview]
Message-ID: <20131107043310.GA30788@savin> (raw)
In-Reply-To: <527B13EC.7020708@jerviss.org>
[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]
On Wed, Nov 06, 2013 at 10:15:40PM -0600, Kyle Jerviss wrote:
> You are ignoring the gambler's ruin. We do not operate on an
> infinite timeline. If you find a big pool willing to try this,
> please give me enough advance warning to get my popcorn ready.
Gamblers ruin has nothing to do with it.
At every point you want to evaluate the chance the other side will get
ahead, vs. cashing in by just publishing the blocks you have. (or some
of them) I didn't mention it in the analysis, but obviously you want to
keep track of how much the blocks you haven't published are worth to
you, and consider publishing some or all of your lead to the rest of the
network if you stand to lose more than you gain.
Right now it's a mostly theoretical attack because the inflation subsidy
is enormous and fees don't matter, but once fees do start to matter
things get a lot more complex. An extreme example is announce/commit
sacrifices to mining fees: if I'm at block n+1, the rest of the network
is at block n, and there's a 100BTC sacrifice at block n+2, I could
easily be in a situation where I have zero incentive to publish my block
to keep everyone else behind me, and just hope I find block n+2. If I
do, great! I'll immediately publish to lock-in my winnings and start
working on block n+3
Anyway, my covert suggestion that pools contact me was more to hopefully
strike fear into the people mining at a large pool and get them to
switch to a small one. :) If everyone mined solo or on p2pool none of
this stuff would matter much... but we can't force them too yet.
--
'peter'[:-1]@petertodd.org
0000000000000005713cac303bd2d529ebeffa82fff60be5307010a83933698d
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
next prev parent reply other threads:[~2013-11-07 4:33 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-06 5:33 kjj
2013-11-06 9:26 ` Frank F
2013-11-06 11:35 ` Jeff Garzik
2013-11-06 18:06 ` Christophe Biocca
2013-11-07 3:44 ` Peter Todd
2013-11-07 4:15 ` Kyle Jerviss
2013-11-07 4:33 ` Peter Todd [this message]
2013-11-07 4:59 ` Kyle Jerviss
2013-11-07 13:09 ` Peter Todd
2013-11-07 4:56 ` Gavin Andresen
2013-11-07 13:24 ` Peter Todd
2013-11-07 16:14 ` Mike Hearn
2013-11-07 18:28 ` Daniel Lidstrom
2013-11-08 19:49 ` Andreas M. Antonopoulos
2013-11-08 20:33 ` Gregory Maxwell
2013-11-15 10:58 ` Peter Todd
2013-11-07 8:07 ` Jannes Faber
2013-11-07 5:24 ` Kyle Jerviss
2013-11-06 18:17 ` Melvin Carvalho
2013-11-06 22:19 ` Jouke Hofman
2014-05-10 11:05 ` E willbefull
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=20131107043310.GA30788@savin \
--to=pete@petertodd$(echo .)org \
--cc=Bitcoin-development@lists$(echo .)sourceforge.net \
--cc=kjj@jerviss$(echo .)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