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
120
121
122
123
124
125
126
127
128
129
130
131
132
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1X89X3-00013N-8d
for bitcoin-development@lists.sourceforge.net;
Fri, 18 Jul 2014 14:53:09 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.172 as permitted sender)
client-ip=209.85.160.172; envelope-from=gavinandresen@gmail.com;
helo=mail-yk0-f172.google.com;
Received: from mail-yk0-f172.google.com ([209.85.160.172])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1X89X1-0005dC-DM
for bitcoin-development@lists.sourceforge.net;
Fri, 18 Jul 2014 14:53:09 +0000
Received: by mail-yk0-f172.google.com with SMTP id 10so2219749ykt.17
for <bitcoin-development@lists.sourceforge.net>;
Fri, 18 Jul 2014 07:53:01 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.61.6 with SMTP id v6mr7903850yhc.151.1405695181876; Fri,
18 Jul 2014 07:53:01 -0700 (PDT)
Received: by 10.170.144.213 with HTTP; Fri, 18 Jul 2014 07:53:01 -0700 (PDT)
In-Reply-To: <CAJHLa0NZRF+1QjSwtwjaTE07NWJ_U-O-DE24=P5eSAutMqTupg@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>
Date: Fri, 18 Jul 2014 10:53:01 -0400
Message-ID: <CABsx9T2BDBNqvinVNk3FmBRWU7R8jf6Vm6NaH74te0FRCh1O-w@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Jeff Garzik <jgarzik@bitpay.com>
Content-Type: multipart/alternative; boundary=089e0160a63efa739604fe78e9aa
X-Spam-Score: -0.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gavinandresen[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1X89X1-0005dC-DM
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 14:53:09 -0000
--089e0160a63efa739604fe78e9aa
Content-Type: text/plain; charset=ISO-8859-1
Two more half-baked thoughts:
We should be able to assume that the majority of transaction data (except
for coinbase) has already been propagated. As Jeff said, incentivizing
nodes to propagate transactions is a very good thing (the signature cache
already gives a small incentive to miners to propagate and not 'hoard'
transactions).
So the only information that theoretically needs to be propagated is which
transactions a miner is including in their block, and in what order they
are included.
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).
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....
--
--
Gavin Andresen
--089e0160a63efa739604fe78e9aa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Two more half-baked thoughts:<div><br></div><div>We should=
be able to assume that the majority of transaction data (except for coinba=
se) has already been propagated. As Jeff said, incentivizing nodes to propa=
gate transactions is a very good thing (the signature cache already gives a=
small incentive to miners to propagate and not 'hoard' transaction=
s).</div>
<div><br></div><div>So the only information that theoretically needs to be =
propagated is which transactions a miner is including in their block, and i=
n what order they are included.</div><div><br></div><div>But if there was s=
ome agreed-upon canonical ordering, then it should theoretically be possibl=
e to take shortcuts in the "what order".</div>
<div><br></div><div>You'd start with setof(transactions I think everybo=
dy knows about)</div><div>Select some subset, based on miner's policy</=
div><div>Sort that subset with the canonical ordering algorithm</div><div>
Very efficiently broadcast, taking all sorts of shortcuts assuming most of =
your peers already know the set you started with and expect the same canoni=
cal ordering (see gmaxwell's thoughts on block encoding).</div><div>
<br></div><div>Second half-baked thought:</div><div>I wonder if broadcastin=
g your transaction selection policy ("11KB of free transactions, sorte=
d by priority, then 111K of fee-paying transactions, sorted by fee") m=
ight make it possible to save even more bandwidth by letting your peers cre=
ate a very good approximation of your block with just that information....<=
/div>
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><br></div>-- <br>--<b=
r>Gavin Andresen<br>
</div><div class=3D"gmail_extra"><br></div></div>
--089e0160a63efa739604fe78e9aa--
|
