public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  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 ` [Bitcoin-development] Economics of information propagation 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.ca \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=jonathan.levin@sant.ox.ac.uk \
    --cc=mark@monetize.io \
    --cc=pete@petertodd.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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