From: Paul Lyon <pmlyon@hotmail•ca>
To: Mark Friedenbach <mark@monetize•io>,
Peter Todd <pete@petertodd•org>,
Jonathan Levin <jonathan.levin@sant•ox.ac.uk>
Cc: "bitcoin-development@lists•sourceforge.net"
<bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Economics of information propagation
Date: Mon, 21 Apr 2014 13:22:48 -0300 [thread overview]
Message-ID: <BLU170-W757A725FD907FDC49BF9F2A55E0@phx.gbl> (raw)
In-Reply-To: <53554089.1010503@monetize.io>
[-- Attachment #1: Type: text/plain, Size: 3808 bytes --]
I haven't done the math on this, so it may be a terrible idea. :)
I've been wondering if block propagation times could also be improved by allowing peers to request the list of transaction hashes that make up a block, and then making a follow-up request to only download any transactions not currently known. I'm not sure what percentage of transactions a node will usually already have when it receives a new block, but if it's high I figure this could be beneficial.
> Date: Mon, 21 Apr 2014 09:00:09 -0700
> From: mark@monetize•io
> To: pete@petertodd•org; jonathan.levin@sant•ox.ac.uk
> CC: bitcoin-development@lists•sourceforge.net
> Subject: Re: [Bitcoin-development] Economics of information propagation
>
> That wasn't what I was saying. Right now the primacy of a block is
> determined by the time at which the `block` message is received, which
> is delays due to both the time it takes to transmit the block data and
> the time it takes to validate. Headers-first, on the other hand, has the
> option of basing primacy on the time the block header is received, which
> is O(1) time to transmit and to SPV-validate. Mining on that block
> doesn't actually commence until the full block is received and validated.
>
> To see how this works, take an example: two blocks with a common parent
> are found relatively close to each other, block A and block B. A is
> found first but is a large block with the maximum block size and many
> slow scripts. B is found a few seconds later and is an empty block. In
> the current regime it is entirely possible that block B, the later but
> smaller block, would get received and processed first by more mining
> peers than the larger block A, exactly as described in Jonathan Levin's
> email.
>
> With headers-first, however, the cost of propagation of the block header
> is the same and we should expect block A to win out over block B nearly
> every time. Miners will continue working on the old, known valid parent
> block until the contents of block A are received and processed. So the
> smaller block B is still found, and since it's data moves across the
> network faster, miners even briefly mine on block B. But as soon as they
> receive and process the contents of block A, they switch to that.
>
> The earlier, larger block A will only become stale if *two* blocks are
> found in the extra time it takes for block A to propagate the network.
> That is a substantially different risk, and probably a negligible
> concern to most miners.
>
> On 04/20/2014 09:06 PM, Peter Todd 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.
> >
> > Of course, in reality smaller miners can just mine on top of block
> > headers and include no transactions and do no validation, but that is
> > extremely harmful to the security of Bitcoin.
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[-- Attachment #2: Type: text/html, Size: 4384 bytes --]
next prev parent reply other threads:[~2014-04-21 16:22 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
2014-04-21 15:58 ` Alan Reiner
2014-04-21 16:00 ` Mark Friedenbach
2014-04-21 16:22 ` Paul Lyon [this message]
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=BLU170-W757A725FD907FDC49BF9F2A55E0@phx.gbl \
--to=pmlyon@hotmail$(echo .)ca \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jonathan.levin@sant$(echo .)ox.ac.uk \
--cc=mark@monetize$(echo .)io \
--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