From: Peter Todd <pete@petertodd•org>
To: Mike Hearn <mike@plan99•net>
Cc: Ittay Eyal <ittay.eyal@cornell•edu>,
Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Auto-generated miner backbone
Date: Mon, 4 Nov 2013 12:36:44 -0500 [thread overview]
Message-ID: <20131104173644.GA3447@petertodd.org> (raw)
In-Reply-To: <CANEZrP0pUvyP62NKu2hdzFYxaMdD7iPPmkL699-gZksZa=HHzg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]
On Mon, Nov 04, 2013 at 04:27:58PM +0100, Mike Hearn wrote:
> > The correct, and rational, approach for a miner is to always mine to
> > extend the block that the majority of hashing power is trying to extend.
> >
>
> There's no stable way to know that. The whole purpose of the block chain to
> establish the majority. I think your near-miss headers solution is
> circular/unstable for that reason, it's essentially a recursive solution.
>
>
> > Mining strategy is now to mine to extend the first block you see, on the
> > assumption that the earlier one probably propagated to a large portion
> > of the total hashing power. But as you receive "near-blocks" that are
> > under the PoW target, use them to estimate the hashing power on each
> > fork, and if it looks like you are not on the majority side, switch.
> >
>
> But you can't reliably estimate that. You can't even reliably estimate the
> speed of the overall network especially not on a short term basis like a
> block interval.
Re-read my proposal - the whole point of it is to give a way to quickly
come to consensus about which side of the fork has the majority of
hashing power. It doesn't, and doesn't need to, reliable determine what
the hashing power actually is on either side. Rather it's a feedback
mechanism that creates a clear majority consensus in a short amount of
time with the use of only a small amount of bandwidth. (~5KB/10minutes)
--
'peter'[:-1]@petertodd.org
00000000000000079c8a642234cb452cbe261fcdb5885af604471c458c257956
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2013-11-04 17:37 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-04 11:26 Mike Hearn
2013-11-04 11:53 ` Peter Todd
2013-11-04 12:00 ` Mike Hearn
2013-11-04 18:16 ` [Bitcoin-development] Committing to extra block data/a better merge-mine standard Peter Todd
2013-11-04 18:32 ` Peter Todd
2013-11-04 19:11 ` Mark Friedenbach
2013-11-15 22:06 ` Peter Todd
2013-11-04 19:38 ` Mike Hearn
2013-11-04 19:53 ` Mark Friedenbach
2013-11-04 20:10 ` Mike Hearn
2013-11-04 11:58 ` [Bitcoin-development] Auto-generated miner backbone Michael Gronager
2013-11-04 12:03 ` Mike Hearn
2013-11-04 12:20 ` Peter Todd
2013-11-04 12:40 ` Michael Gronager
2013-11-04 15:58 ` Gregory Maxwell
2013-11-04 14:26 ` Peter Todd
2013-11-04 14:34 ` Pieter Wuille
2013-11-04 14:46 ` Peter Todd
[not found] ` <CABT1wWm1NzKSS9H=Qh3Z6pFmNHbOFKC12WaE=b3kE0mNsRgfmw@mail.gmail.com>
2013-11-04 15:04 ` Peter Todd
[not found] ` <CABT1wWmONUeOWRg-=FKr88bgBQf0un4bvjYW2h8d-10ys-VKtA@mail.gmail.com>
2013-11-04 15:46 ` Peter Todd
[not found] ` <CABT1wWmM466jWWdWAo5GmzP58xJFT70Vcr74ta+2QF2fWT+1SA@mail.gmail.com>
2013-11-04 16:07 ` Peter Todd
[not found] ` <CABT1wWm5BDZf7U40pOqZvTqdOKeTWUTekjUNckq5McMV=LDu_g@mail.gmail.com>
2013-11-04 16:51 ` Peter Todd
[not found] ` <CABT1wWmwb17b4ACHMmDKqd94tUSKsvwAPx344mZ0VS+47myeWg@mail.gmail.com>
2013-11-04 21:04 ` Peter Todd
2013-11-04 21:45 ` Alan Reiner
2013-11-04 22:03 ` Peter Todd
2013-11-04 15:27 ` Mike Hearn
2013-11-04 17:36 ` Peter Todd [this message]
2013-11-04 15:51 ` Gregory Maxwell
2013-11-05 4:14 Gustaw Wieczorek
2013-11-05 4:39 ` Peter Todd
2013-11-05 6:37 ` Gregory Maxwell
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=20131104173644.GA3447@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=ittay.eyal@cornell$(echo .)edu \
--cc=mike@plan99$(echo .)net \
/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