From: Mark Friedenbach <mark@monetize•io>
To: Paul Lyon <pmlyon@hotmail•ca>, 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 09:38:17 -0700 [thread overview]
Message-ID: <53554979.9020206@monetize.io> (raw)
In-Reply-To: <BLU170-W757A725FD907FDC49BF9F2A55E0@phx.gbl>
Yes, it certainly can be improved in this way. You can even extend the
idea to distribute partial proofs of work (block headers + Merkle lists
which represent significant but not sufficient work), and 'prime' your
memory pools with the transactions contained within.
This is, btw, basically what p2pool does, which is why last time I
calculated you get roughly 1% better return from p2pool than a zero-fee
mining pool would get you, specifically because of the lower stale rate.
On 04/21/2014 09:22 AM, Paul Lyon wrote:
> 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.
>
next prev parent reply other threads:[~2014-04-21 16:38 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
2014-04-21 16:38 ` Mark Friedenbach [this message]
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=53554979.9020206@monetize.io \
--to=mark@monetize$(echo .)io \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jonathan.levin@sant$(echo .)ox.ac.uk \
--cc=pete@petertodd$(echo .)org \
--cc=pmlyon@hotmail$(echo .)ca \
/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