summaryrefslogtreecommitdiff
path: root/86/b0eab48a660962f3655a690cd14085f862dca2
blob: 5b96b472d5fcf5adcce1e51ed6b909cd76f4a150 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <john.dillon892@googlemail.com>) id 1V3VvP-0006pa-Bd
	for bitcoin-development@lists.sourceforge.net;
	Sun, 28 Jul 2013 18:42:35 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of googlemail.com
	designates 209.85.215.193 as permitted sender)
	client-ip=209.85.215.193;
	envelope-from=john.dillon892@googlemail.com;
	helo=mail-ea0-f193.google.com; 
Received: from mail-ea0-f193.google.com ([209.85.215.193])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1V3VvN-0003OA-93
	for bitcoin-development@lists.sourceforge.net;
	Sun, 28 Jul 2013 18:42:35 +0000
Received: by mail-ea0-f193.google.com with SMTP id z7so79909eaf.8
	for <bitcoin-development@lists.sourceforge.net>;
	Sun, 28 Jul 2013 11:42:27 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.14.1.70 with SMTP id 46mr56432184eec.82.1375036946946; Sun,
	28 Jul 2013 11:42:26 -0700 (PDT)
Received: by 10.223.12.131 with HTTP; Sun, 28 Jul 2013 11:42:26 -0700 (PDT)
In-Reply-To: <CAE-z3OWBoMz6jC36Bp+dGqj6jHiWj1d1zGtH+iBbLcCt_6kNJw@mail.gmail.com>
References: <CAE-z3OX+Uzw_diW97yKWGzVMBFZHq2t+w15jNSdGMGqwyJ65yQ@mail.gmail.com>
	<20130724094255.GB12568@savin>
	<CAE-z3OWBoMz6jC36Bp+dGqj6jHiWj1d1zGtH+iBbLcCt_6kNJw@mail.gmail.com>
Date: Sun, 28 Jul 2013 18:42:26 +0000
Message-ID: <CAPaL=UVc0CGvvam0tdxw+4Y8XwSw0Awz8ifv64HYgORJ7zLztg@mail.gmail.com>
From: John Dillon <john.dillon892@googlemail.com>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.4 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(john.dillon892[at]googlemail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
	digit (john.dillon892[at]googlemail.com)
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1V3VvN-0003OA-93
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Distributing low POW headers
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 28 Jul 2013 18:42:35 -0000

-----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-----