diff options
| author | Peter Todd <pete@petertodd.org> | 2013-06-17 13:39:42 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-06-17 17:39:58 +0000 |
| commit | 9415f27845cfdad7eda3895c6a5e280b8cfaa551 (patch) | |
| tree | 405680d2de74ebe7b72747b540798a3ab58f5110 | |
| parent | 62da4d7de96930b7e779abc1723b02db718fb3c5 (diff) | |
| download | pi-bitcoindev-9415f27845cfdad7eda3895c6a5e280b8cfaa551.tar.gz pi-bitcoindev-9415f27845cfdad7eda3895c6a5e280b8cfaa551.zip | |
Re: [Bitcoin-development] Decentralizing mining
| -rw-r--r-- | 9c/a75c0981a495d1bc7327cde7c7eb112deaa443 | 156 |
1 files changed, 156 insertions, 0 deletions
diff --git a/9c/a75c0981a495d1bc7327cde7c7eb112deaa443 b/9c/a75c0981a495d1bc7327cde7c7eb112deaa443 new file mode 100644 index 000000000..929babe39 --- /dev/null +++ b/9c/a75c0981a495d1bc7327cde7c7eb112deaa443 @@ -0,0 +1,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-- + + |