diff options
author | Peter Todd <pete@petertodd.org> | 2015-06-19 11:40:54 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-06-19 15:41:12 +0000 |
commit | 7afec4fea3e8a6c9163a242a9be9f5b3eaade52f (patch) | |
tree | d75bd6bfc5eeddc4c4e89d1ebb7d2e0a1a797f89 | |
parent | 88efd6ed9dbce5d0a82711ff08aa3132f4ffd407 (diff) | |
download | pi-bitcoindev-7afec4fea3e8a6c9163a242a9be9f5b3eaade52f.tar.gz pi-bitcoindev-7afec4fea3e8a6c9163a242a9be9f5b3eaade52f.zip |
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
-rw-r--r-- | e2/cd87a5c54da811fec0e87ce726a962cec9d522 | 188 |
1 files changed, 188 insertions, 0 deletions
diff --git a/e2/cd87a5c54da811fec0e87ce726a962cec9d522 b/e2/cd87a5c54da811fec0e87ce726a962cec9d522 new file mode 100644 index 000000000..61649d8fa --- /dev/null +++ b/e2/cd87a5c54da811fec0e87ce726a962cec9d522 @@ -0,0 +1,188 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <pete@petertodd.org>) id 1Z5yPo-0002ji-IC + for bitcoin-development@lists.sourceforge.net; + Fri, 19 Jun 2015 15:41:12 +0000 +Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org + designates 62.13.148.114 as permitted sender) + client-ip=62.13.148.114; envelope-from=pete@petertodd.org; + helo=outmail148114.authsmtp.net; +Received: from outmail148114.authsmtp.net ([62.13.148.114]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) + id 1Z5yPm-0005cB-G5 for bitcoin-development@lists.sourceforge.net; + Fri, 19 Jun 2015 15:41:12 +0000 +Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) + by punt16.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5JFf0RC080567; + Fri, 19 Jun 2015 16:41:00 +0100 (BST) +Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com + [75.119.251.161]) (authenticated bits=128) + by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5JFetID050527 + (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); + Fri, 19 Jun 2015 16:40:57 +0100 (BST) +Date: Fri, 19 Jun 2015 11:40:54 -0400 +From: Peter Todd <pete@petertodd.org> +To: Adrian Macneil <adrian@coinbase.com> +Message-ID: <20150619154054.GA13498@savin.petertodd.org> +References: <20150619103959.GA32315@savin.petertodd.org> + <CABsx9T1pnT=Tty3+tg+EUphLwQrWXf9EEwUOGuyNcdu=4wAqTg@mail.gmail.com> + <20150619135245.GB28875@savin.petertodd.org> + <CAMK47c_kCgb6hEUf_JePAC_tBK8aCF1W4f1guiAah-Gj_cFfSw@mail.gmail.com> + <20150619140815.GA32470@savin.petertodd.org> + <CAMK47c9NhX2gzCioTycEPXqyYeKRM9XgXuW9MGyj=OdGsKVbFg@mail.gmail.com> + <20150619145940.GB5695@savin.petertodd.org> + <CAMK47c8Mc8v2C4aG=7GdAQ7ZCR2qXhfq-dktNS7bDa00RdKThw@mail.gmail.com> +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha256; + protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ" +Content-Disposition: inline +In-Reply-To: <CAMK47c8Mc8v2C4aG=7GdAQ7ZCR2qXhfq-dktNS7bDa00RdKThw@mail.gmail.com> +User-Agent: Mutt/1.5.21 (2010-09-15) +X-Server-Quench: 947f5631-1699-11e5-9f74-002590a135d3 +X-AuthReport-Spam: If SPAM / abuse - report it at: + http://www.authsmtp.com/abuse +X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR + aQdMdwsUEkAaAgsB AmMbWlJeVF17XGs7 bA9PbARUfEhLXhtr + VklWR1pVCwQmRRl7 cEtaK21ycgVDenk+ Z0VlXHgVVUB9I0N7 + QU9JFGsPbHphaTUa TUkOcAdJcANIexZF O1F8UScOLwdSbGoL + NQ4vNDcwO3BTJTpY RgYVKF8UXXNDMGQE QBcGVTUmBgUIQSw5 + KxEqYlABGEJZKEgq NVIqVBcSIlocBwA2 +X-Authentic-SMTP: 61633532353630.1024:706 +X-AuthFastPath: 0 (Was 255) +X-AuthSMTP-Origin: 75.119.251.161/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: 1Z5yPm-0005cB-G5 +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee +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, 19 Jun 2015 15:41:12 -0000 + + +--mP3DRpeJDSE+ciuQ +Content-Type: text/plain; charset=iso-8859-1 +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +On Fri, Jun 19, 2015 at 08:20:52AM -0700, Adrian Macneil wrote: +> > +> > Unless you're sybil attacking the network and miners, consuming valuable +> > resources and creating systemic risks of failure like we saw with +> > Chainalysis, I don't see how you're getting "very small" double-spend +> > probabilities. +> > +>=20 +> So connecting to many nodes just because we can and it's not technically +> prevented is bad for the network and creating systemic risks of failure, + +Well it is actually; that's why myself, Wladimir van der Laan, and +Gregory Maxwell all specifically=B9 called Chainalysis's actions a sybil +attack. + +The Bitcoin P2P network is resilliant to failure when the chance of any +one node going down is uncorrelated with others. For instance if you +accidentally introduced a bug in your nodes that failed to relay +transactions/blocks properly, you'd simultaneously be disrupting a large +portion of the network all at once. + +How many nodes is Coinbase connecting too? What software are they +running? What subnets are they using? In particular, are they all on one +subnet or multiple? + +> but relaying harmful double spend transactions just because you can and +> it's not technically prevented, is good for everyone? + +You realise that Hearn/Andresen/Harding's double-spend-relaying patch, +included in Bitcoin XT, relays double-spend transactions right? Do you +consider that harmful? + +> > You know, you're creating an interesting bit of game theory here: if I'm +> > a miner who doesn't already have a mining contract, why not implement +> > full-RBF to force Coinbase to offer me one? One reason might be because +> > other miners with such a contract - a majority - are going to be asked +> > by Coinbase to reorg you out of the blockchain, but then we have a +> > situation where a single entity has control of the blockchain. +> > +>=20 +> If someone did enter into contracts with miners to mine certain +> transactions, and had a guarantee that the miners would not build on +> previous blocks which included double spends, then they would only need +> contracts with 51% of the network anyway. So it wouldn't really matter if +> you were a small time miner and wanted to run full-RBF. + +But of course, you'd never 51% the network right? After all it's not +possible to guarantee that your miner won't mine double-spends, as there +is no single consensus definition of which transaction came first, nor +can there be. + +Or do you see things differently? If I'm a small miner should I be +worried my blocks might be rejected by the majority with hashing power +contracts because I'm unable to predict which transactions Coinbase +believes should go in the blockchain? + +> > For the good of Bitcoin, and your own company, you'd do well to firmly +> > state that under no condition will Coinbase ever enter into mining +> > contracts. +> > +>=20 +> I don't personally see what good this does for bitcoin. Now you are +> suggesting that we should prevent a 51% attack by using policy and +> promises, rather than a technical solution. How is this any better than us +> relying on existing double spend rules which are based on policy and +> promises? + +Well, I think I've shown how dangerous mining contracts can be to the +overall health of the Bitcoin ecosystem; I'm simply asking you to +promise not to make use of this dangerous option regardless of what +happens. Like I said, if for whatever reason the first-seen mempool +behavior proves to be insufficient at preventing double-spends from your +perspective, you did suggest you might use mining contracts to ensure +txs you want mined get mined, over others. + + +1) "Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network", + March 14th 2015, Grace Caffyn, Coindesk, + http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on= +-bitcoin-network/ + +--=20 +'peter'[:-1]@petertodd.org +00000000000000000e806870e7e9cf4d507af6b78fc709e6839a8d34b52ea334 + +--mP3DRpeJDSE+ciuQ +Content-Type: application/pgp-signature; name="signature.asc" +Content-Description: Digital signature + +-----BEGIN PGP SIGNATURE----- + +iQGrBAEBCACVBQJVhDgCXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw +MDAwMDAwMDAwMDAwMDAwZTgwNjg3MGU3ZTljZjRkNTA3YWY2Yjc4ZmM3MDllNjgz +OWE4ZDM0YjUyZWEzMzQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 +ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfvKpgf/R/1zLQTrnuULURDdeISm2KMd +aHXLl7J5SZQSgjbYCQsuv/q4cap9k6hQgpwdUS2L0vG2t+O3/3udlxGpeSQkd5bi +mp/1G56SKTyXdYaFRBzHvda06RYF6fs2SHPqvMW+Cytj2lHQ6M1APlTmGWplatHm +MBkSf8rDHxwkK3Cj0ckILmHF0E6/hDgj6g8ZT4BNP3OLVksbEEzVA3L6fm73lTFV +K+1XAofdIyHv23/sDKrbN+z6ycBEchzOENXdA4AdOiLHtLzoB9995sAUkoenRg98 +Dh7u6bQB4vmx76ur9QQB7mNNmpFMU5BovjlaXCTOY/LCZm7V839vTdAvowZ5Nw== +=hLqt +-----END PGP SIGNATURE----- + +--mP3DRpeJDSE+ciuQ-- + + |