From: Gregory Maxwell <gmaxwell@gmail•com>
To: Alan Reiner <etotheipi@gmail•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Cut-through propagation of blocks
Date: Sat, 24 May 2014 17:14:59 -0700 [thread overview]
Message-ID: <CAAS2fgRSvbUdB80vQOvSBfCckzPASkw6wNzqZUk-h2pWiY8srg@mail.gmail.com> (raw)
In-Reply-To: <53813391.7040503@gmail.com>
On Sat, May 24, 2014 at 5:04 PM, Alan Reiner <etotheipi@gmail•com> wrote:
> I think the most important change is modifying the way Bitcoin Core
> prioritizes blocks. Right now it uses the first full block verified.
> Instead, it should consider the first valid header received as highest
> priority, but only mine on it once it has done full verification of the
This directly opens an attack where as soon as you find a block you
announce the header to the world and then you delay announcing the
block content. You can continue to mine on the block but no one else
can (or alternatively they break their rule and risk extending an
invalid block— bad news for SPV wallets)— then when you find a
successor block or someone else finds a competing block you
immediately announce the content.
It basically means that you can always delay announcing a block and be
sure that doing so doesn't deprive you of your winning position.
> If miners are concerned about that 1-3 second gap, they
> should perhaps focus on making sure the tx they are mining are
> well-propagated already, so that most of the network has most of the
> transactions already in their memory pool by the time their block is mined.
With an alternative transport protocol, assuming the content has
already been relayed a block could be sent in a couple back to back
UDP packets. (e.g. a few bytes per transaction to disambiguate the
transaction order out of the already sent transactions). So I think
very similar latency could be achieved without doing any thing which
might increase the motivations for miners to misbehave.
next prev parent reply other threads:[~2014-05-25 0:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-24 3:57 Ashley Holman
2014-05-24 5:11 ` Ashley Holman
2014-05-24 22:59 ` Bernd Jendrissek
2014-05-24 23:16 ` Gregory Maxwell
2014-05-24 23:41 ` Ashley Holman
2014-05-25 0:04 ` Alan Reiner
2014-05-25 0:14 ` Gregory Maxwell [this message]
2014-05-25 0:38 ` Alan Reiner
2014-05-25 9:36 ` Mike Hearn
2014-05-25 9:51 ` Gregory Maxwell
2014-05-26 15:08 ` Mike Hearn
[not found] <mailman.177181.1400974908.2207.bitcoin-development@lists.sourceforge.net>
2014-05-24 23:57 ` Jonathan Levin
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=CAAS2fgRSvbUdB80vQOvSBfCckzPASkw6wNzqZUk-h2pWiY8srg@mail.gmail.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=etotheipi@gmail$(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