summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorPeter Todd <pete@petertodd.org>2015-06-19 11:40:54 -0400
committerbitcoindev <bitcoindev@gnusha.org>2015-06-19 15:41:12 +0000
commit7afec4fea3e8a6c9163a242a9be9f5b3eaade52f (patch)
treed75bd6bfc5eeddc4c4e89d1ebb7d2e0a1a797f89
parent88efd6ed9dbce5d0a82711ff08aa3132f4ffd407 (diff)
downloadpi-bitcoindev-7afec4fea3e8a6c9163a242a9be9f5b3eaade52f.tar.gz
pi-bitcoindev-7afec4fea3e8a6c9163a242a9be9f5b3eaade52f.zip
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
-rw-r--r--e2/cd87a5c54da811fec0e87ce726a962cec9d522188
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--
+
+