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
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1UodPK-0007NM-So
for bitcoin-development@lists.sourceforge.net;
Mon, 17 Jun 2013 17:39:58 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.112 as permitted sender)
client-ip=62.13.149.112; envelope-from=pete@petertodd.org;
helo=outmail149112.authsmtp.co.uk;
Received: from outmail149112.authsmtp.co.uk ([62.13.149.112])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1UodPJ-0006Ju-LP for bitcoin-development@lists.sourceforge.net;
Mon, 17 Jun 2013 17:39:58 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt12.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
r5HHdmBu084262; Mon, 17 Jun 2013 18:39:48 +0100 (BST)
Received: from petertodd.org (petertodd.org [174.129.28.249])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r5HHdhcO055828
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Mon, 17 Jun 2013 18:39:45 +0100 (BST)
Date: Mon, 17 Jun 2013 13:39:42 -0400
From: Peter Todd <pete@petertodd.org>
To: Jeff Garzik <jgarzik@bitpay.com>
Message-ID: <20130617173942.GA26623@petertodd.org>
References: <20130527111149.GB8955@tilt> <20130531165758.GA29135@petertodd.org>
<20130610210913.GA17242@petertodd.org>
<201306102123.15732.luke@dashjr.org>
<20130614200654.GB11509@petertodd.org>
<CAJHLa0P7gndRqubREeQqbVNy_nJgyu7CUdgK9no14RCahxx7Cg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW"
Content-Disposition: inline
In-Reply-To: <CAJHLa0P7gndRqubREeQqbVNy_nJgyu7CUdgK9no14RCahxx7Cg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: e692fbcc-d774-11e2-b5c5-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdwUUEkAaAgsB AmUbWlxeU1R7XWY7 ag1VcwRfa1RMVxto
VEFWR1pVCwQmQxl5 fkpGAWZycgBOenY+ ZE9hXHQVCUJzdxAv
ER1JQWoBYXphaTUd TRJdJAZJcANIexZF O1F6ACIKLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDMjM3 ShYeBzwrHF8EQSp7 Kh0gK1gTdAAI
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 174.129.28.249/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
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
X-Headers-End: 1UodPJ-0006Ju-LP
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Decentralizing mining
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: Mon, 17 Jun 2013 17:39:59 -0000
--ew6BAiZeqk4r7MaW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Jun 17, 2013 at 11:16:01AM -0400, Jeff Garzik wrote:
> > Part of the broader issue that when we send peers INV advertisements we
> > should be telling them what the fee/kb is so our peers can prioritize
> > properly. That'd also help for the case where you want to broadcast two
> > transactions in a row, but the pair is only profitable because the
> > second is paying the fee for the first.
>=20
> Interesting proposals, particularly this last. The net result impact
> is, however, that which was criticized in at least one forum thread:
> replace-with-higher-fee.
Actually the two are orthogonal: a low-priority no-fee tx might result
because it was from a customer paying a merchant via the payment
protocol. The merchant can then respend that tx with a fee to cover
both, but with the current mempool arrangement if the no-fee tx load is
high actually getting that first tx to propagate so the second can will
be difficult.
A nice way to do this would be to accept tx's into your mempool
indiscriminately but delay broadcasting INV messages until you find
child tx's that make the low-profit ones worth mining. When you do find
a child with a sufficiently high fee, send an INVGROUP message to notify
your peers of the new opportunity. Different nodes will have different
ideas of what priority TX deserves to be broadcast, but here provided
the group meets the threshold a peer will always find out.
> > Speaking of, the way we tell peers about new blocks is really
> > suboptimal: we tell every peer, in no particular order, about a new
> > block via a block INV message, and then we give them the new block in
> > parallel. I was looking through comp-sci papers on optimal
> > flood-fill/gossip algorithms for random graph networks and it appears
> > that optimal is to spend all your bandwidth to send the message to your
> > fastest peer first, followed by your next fastest and so on. This works
> > best because you get the exponential growth scaling faster by
> > propagating the message as "deep" as possible in the network, and it
> > then can flood outwards from there. Just sorting the peer list by
> > #inv-recevied/time when doing INV pushes and when attending to incoming
> > messages would probably be a big improvement.
>=20
> In terms of packet size, I would like to look into the network-wide
> costs of simply broadcasting block header + coinbase TX + TX list. I
> bet miners would love to opt into that.
Whether or not that is a improvement is a really complex question, even
without taking failure into account. If you agressively prioritize peers
that are the most connected and keep your # of peers reasonably low you
can afford the memory to keep track of what tx's your peers already know
about so to save on round trips for TX hash's they don't have. On the
other hand if you have a large number of peers and can't do that, or
need to cut down on bandwidth used up by the INV floods and have a
probabalistic scheme, you are risking more round-trip latency.
Not to mention the nasty problem of how *relying* on TX hashes to keep
your bandwidth down means that anything disrupting that system suddenly
has a big impact on the network. I don't think we really understand all
the nuances of that - look at how few people realize that you need
multiples of average bandwidth to have sufficient emergency bandwidth
available to catch up in the event of a chain fork.
--=20
'peter'[:-1]@petertodd.org
00000000000000a1c290ce20953d864a4b9c603abc8a9c77a04429c89c5e9fac
--ew6BAiZeqk4r7MaW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAlG/Sd4ACgkQpEFN739thoxeHwCfUKLHJgncQnLGDeXi2bOG/aPy
oUsAnjVu+4LOZVPTvl81/62/6ty43pzs
=kuMO
-----END PGP SIGNATURE-----
--ew6BAiZeqk4r7MaW--
|
