From: John Dillon <john.dillon892@googlemail•com>
To: Tier Nolan <tier.nolan@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Distributing low POW headers
Date: Sun, 28 Jul 2013 18:42:26 +0000 [thread overview]
Message-ID: <CAPaL=UVc0CGvvam0tdxw+4Y8XwSw0Awz8ifv64HYgORJ7zLztg@mail.gmail.com> (raw)
In-Reply-To: <CAE-z3OWBoMz6jC36Bp+dGqj6jHiWj1d1zGtH+iBbLcCt_6kNJw@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Wed, Jul 24, 2013 at 11:55 AM, Tier Nolan <tier.nolan@gmail•com> wrote:
> Distributing headers with 1/64 of the standard POW means that a header would
> be broadcast approximately once every 9 seconds (assuming a 10 minute block
> time). This was picked because sending 80 byte headers every 9 seconds
> shouldn't represent much load on the network.
As Peter said, "much" should be quantified.
Remember that there is a statistical distribution here, what is the probability
of how many seconds per headers?
> This creates an incentive for miners to take headers into account. If all
> the headers were worth less than a full block, then a fork which was losing
> would suddenly be winning if a block is found. A fork will only become the
> main chain due to a new block, if it is within 16 mini-confirms.
Sounds like you are changing economics and requiring miners to have even better
network connections. This is not a thing to do lightly and it probably a bad
idea.
> Second, if a header builds on a header that is in the header tree, then it
> is broadcast, even if it doesn't meet full POW (only 1/64 required). This
> gives information on which fork is getting the most power.
>
> It gives information about potential "consensus loss" forks, where a
> significant number of miners are following an alternative chain.
>
> In fact, this is probably worth doing as an initial step.
I understand Pieter Wuille is working on letting Bitcoin propagate and make use
of pure block headers, a step towards SPV and partial UTXO mode.
Orphan measurement would be very useful for a lot of reasons, how about you
think about that first? It wouldn't have the potential data rate issues either
and should be a very simple change. Just set some threshold relative to the
height of the best block where you will not further propagate and orphan
block(header) and prior to that limit do so freely. I believe the change would
be 100% compatible with the P2P protocol as it is based on inventories.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJR9WXdAAoJEEWCsU4mNhiPBUYIALgg3ylA5mkciT3W/kb+qXCp
spYlPwAU/HVUrd/p6Ra6xAOOa224BE018FHRx7cJ31AQdVPsKhC1XiQCeYMv14Cj
5LstO2VTzxLovfs1lTVnekt+xVo6EHP47Qhmhdfo1AQWHS2njIp2lT9gAlNgMYoI
Twu0FLfJFwg14HlueLhTNvGo3TeVpGhTV3HYTbjWGBuPeroaaPCKKQOy/jmA9mnZ
1x4MjQZ+AkGA3+vrinyRZ1FQsp1pOUZMZx5UFYDOOPS3TysxttiHF/Vkdmy9dNVf
5zbXrEDImlariRnyxCf6sn4Fpu9H9bt6yttCez6NHqAoZCwciXyo+UrZjFawSVg=
=8gci
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2013-07-28 18:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-23 11:27 Tier Nolan
2013-07-24 9:42 ` Peter Todd
2013-07-24 11:55 ` Tier Nolan
2013-07-28 18:42 ` John Dillon [this message]
2013-07-28 20:07 ` Tier Nolan
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='CAPaL=UVc0CGvvam0tdxw+4Y8XwSw0Awz8ifv64HYgORJ7zLztg@mail.gmail.com' \
--to=john.dillon892@googlemail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=tier.nolan@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