From: Ashley Holman <dscvlt@gmail•com>
To: Peter Todd <pete@petertodd•org>
Cc: bitcoin-development@lists•sourceforge.net,
Jonathan Levin <jonathan.levin@sant•ox.ac.uk>
Subject: Re: [Bitcoin-development] Economics of information propagation
Date: Tue, 22 Apr 2014 01:10:48 +0930 [thread overview]
Message-ID: <CAOXABZrB0p3KzKhGaYQsgQ2TGMvg_A0cuOhQ956QPRBPrO_=qg@mail.gmail.com> (raw)
In-Reply-To: <a9a262a9-c70f-470d-81e0-ca32c41d8dc5@email.android.com>
[-- Attachment #1: Type: text/plain, Size: 1133 bytes --]
On Mon, Apr 21, 2014 at 1:36 PM, Peter Todd <pete@petertodd•org> wrote:
>
> That is mistaken: you can't mine on top of just a block header, leaving
> small miners disadvantaged as they are earning no profit while they wait
> for the information to validate the block and update their UTXO sets. This
> results in the same problem as before, as the large pools who mine most
> blocks can validate either instantly - the self-mine case - or more quickly
> than the smaller miners.
>
>
Under the headers first scenario, wouldn't the full block still reach
everyone in the same time as it would under the current rules? So the
small miner loses nothing in terms of updating their UTXO set, but gains an
early "heads up" alert that a new block is coming. This allows them spend
the propagation time working more productively on an empty block in the new
chain rather than wasting time on an orphan. It's true that it doesn't
solve the problem of larger pools vs smaller pools, but if it doesn't make
it any worse then headers-first propagation would be a net benefit to the
network since it removes the incentive to make small blocks.
[-- Attachment #2: Type: text/html, Size: 1476 bytes --]
next prev parent reply other threads:[~2014-04-21 15:40 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.122233.1398039406.2207.bitcoin-development@lists.sourceforge.net>
2014-04-21 1:30 ` Jonathan Levin
2014-04-21 3:58 ` Mark Friedenbach
2014-04-21 4:06 ` Peter Todd
2014-04-21 4:44 ` Daniel Lidstrom
2014-04-21 5:46 ` Daniel Lidstrom
2014-04-21 11:34 ` Tier Nolan
2014-04-21 13:04 ` Jorge Timón
2014-04-21 15:40 ` Ashley Holman [this message]
2014-04-21 15:58 ` Alan Reiner
2014-04-21 16:00 ` Mark Friedenbach
2014-04-21 16:22 ` Paul Lyon
2014-04-21 16:38 ` Mark Friedenbach
2014-04-21 16:39 ` Mike Hearn
2014-04-21 16:45 ` Jonathan Levin
2014-04-23 2:54 ` Tom Harding
2014-04-23 15:05 ` Peter Todd
[not found] ` <CAOe4Ui=OaVLvh0vUnNv-1j41YB4B2x896DQ5b6xt4oUJ5oLPFg@mail.gmail.com>
2014-05-02 11:48 ` [Bitcoin-development] Block collision resolution using the DECOR protocol and Bonneau's Kickbacks problem Sergio Lerner
2014-05-02 12:00 ` Sergio Lerner
[not found] ` <CAOe4UimBEe4t1Z41du3r8pQUOmzd_1V_aESizuiH2U6uvN9nFA@mail.gmail.com>
2014-05-05 19:45 ` Sergio Lerner
2014-05-05 20:27 ` Ittay
2014-05-07 4:31 ` [Bitcoin-development] DECOR+ Better block selection rule Sergio Lerner
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='CAOXABZrB0p3KzKhGaYQsgQ2TGMvg_A0cuOhQ956QPRBPrO_=qg@mail.gmail.com' \
--to=dscvlt@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jonathan.levin@sant$(echo .)ox.ac.uk \
--cc=pete@petertodd$(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