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
118
119
|
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 <jgarzik@bitpay.com>) id 1X89kJ-0002eB-QA
for bitcoin-development@lists.sourceforge.net;
Fri, 18 Jul 2014 15:06:51 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bitpay.com
designates 74.125.82.177 as permitted sender)
client-ip=74.125.82.177; envelope-from=jgarzik@bitpay.com;
helo=mail-we0-f177.google.com;
Received: from mail-we0-f177.google.com ([74.125.82.177])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1X89kI-00056x-1G
for bitcoin-development@lists.sourceforge.net;
Fri, 18 Jul 2014 15:06:51 +0000
Received: by mail-we0-f177.google.com with SMTP id w62so4660550wes.8
for <bitcoin-development@lists.sourceforge.net>;
Fri, 18 Jul 2014 08:06:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-type;
bh=gkoy2TIA4hHQqfqT+speDNa/TSgnNP+Vhac+Iy/eJ/4=;
b=jFmeN8QMyOwLVeYt6goqh6j5nhR4dV8UXl90JY7C10RdjzKP1UZC8ZBrzK9MI4NbBh
SL9JQVG4XqqNpTNiBbAMdH4o/NRbv35AKt1EVPBPT0kNEf9yrhIv2URTx/dKcLhzfsYV
2TwBUxhv71i5lKy0NXyyHLyOGfFv7tHRbvpXoLn8QyFIF5zLZhy8CWhFRfjz7HDCIcCp
yYnEUOabzxu4jaRZhKneOtP0rpmkabDX5QNtJpaq7CZbwmUs3UAuipxqEZabA6jtEOOd
+6FdR5jvNTC2eVhCfIfbwu8dG5/ozl7Fo47XXE95ZFHvkb0uWX8QxzpccLzEv7MRV9G8
6QVg==
X-Gm-Message-State: ALoCoQldGrOUaaBUx51/Oe/byM0lG9R1FtucXAupdSSAsf0mO4KijM/wJ6t+RkCDa0Q8QFZjcoc3
X-Received: by 10.194.172.167 with SMTP id bd7mr7844536wjc.74.1405696003647;
Fri, 18 Jul 2014 08:06:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.5.67 with HTTP; Fri, 18 Jul 2014 08:06:23 -0700 (PDT)
In-Reply-To: <CABsx9T2BDBNqvinVNk3FmBRWU7R8jf6Vm6NaH74te0FRCh1O-w@mail.gmail.com>
References: <CA+iPb=EaX=bvOjNtZ+LnYTMRLQQ9nFcrefAkBdv8eActoX_b8A@mail.gmail.com>
<CABsx9T0ag_o_mu=5Q7Ju7s2hO3jz-o5g9FihE9h4B6+ednd2Pg@mail.gmail.com>
<CAJHLa0NZRF+1QjSwtwjaTE07NWJ_U-O-DE24=P5eSAutMqTupg@mail.gmail.com>
<CABsx9T2BDBNqvinVNk3FmBRWU7R8jf6Vm6NaH74te0FRCh1O-w@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Fri, 18 Jul 2014 11:06:23 -0400
Message-ID: <CAJHLa0O=eCoyvV19dWgTnYd9Di0wLLZtWmCPidc-dWqPNQv_oQ@mail.gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.6 (-)
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 SPF_PASS SPF: sender matches SPF record
-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: 1X89kI-00056x-1G
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Squashing redundant tx data in blocks on
the wire
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: Fri, 18 Jul 2014 15:06:52 -0000
On Fri, Jul 18, 2014 at 10:53 AM, Gavin Andresen
<gavinandresen@gmail.com> wrote:
> But if there was some agreed-upon canonical ordering, then it should
> theoretically be possible to take shortcuts in the "what order".
>
> You'd start with setof(transactions I think everybody knows about)
> Select some subset, based on miner's policy
> Sort that subset with the canonical ordering algorithm
> Very efficiently broadcast, taking all sorts of shortcuts assuming most of
> your peers already know the set you started with and expect the same
> canonical ordering (see gmaxwell's thoughts on block encoding).
Related implementation detail: Having pursued this train of thought,
I noted that you don't want to include too-young transactions that you
received in the past few seconds, because those are likely still
propagating around the network.
> Second half-baked thought:
> I wonder if broadcasting your transaction selection policy ("11KB of free
> transactions, sorted by priority, then 111K of fee-paying transactions,
> sorted by fee") might make it possible to save even more bandwidth by
> letting your peers create a very good approximation of your block with just
> that information....
Absolutely. One path I would like to see pursued is multiple
p2pool-esque chains. Each with their own policy, perhaps with their
own administrative team. ie. you could have a fully decentralized
p2pool-like chain, or multiple such chains, each with a stated
policy/reward pattern. Or, GHash/BTCGuild/Eligius could run a
semi-centrally managed chain ultimately guaranteed not only by
protocol but by administrators' digital signatures.
In each case, advertising technical attributes about your pool [chain]
policy would give nodes the better ability to predict what is in an
upcoming block.
And the flip side of that, such predictions are never perfect. Need
to make sure the fallback case, while undoubtedly more costly than the
Fast Path, is not overly painful.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
|
