From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 To: Jeff Garzik 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline In-Reply-To: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--