summaryrefslogtreecommitdiff
path: root/a9/382332a0f442e229befd6d3b9c31141287280a
blob: 685f028a85232667163cf6446db10f0f5867dfb9 (plain)
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
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pete@petertodd.org>) id 1Z5wy9-00068N-88
	for bitcoin-development@lists.sourceforge.net;
	Fri, 19 Jun 2015 14:08:33 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.75 as permitted sender)
	client-ip=62.13.149.75; envelope-from=pete@petertodd.org;
	helo=outmail149075.authsmtp.net; 
Received: from outmail149075.authsmtp.net ([62.13.149.75])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1Z5wy8-0003uD-12 for bitcoin-development@lists.sourceforge.net;
	Fri, 19 Jun 2015 14:08:33 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
	by punt16.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5JE8M6j050294;
	Fri, 19 Jun 2015 15:08:22 +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 t5JE8FOg044884
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Fri, 19 Jun 2015 15:08:18 +0100 (BST)
Date: Fri, 19 Jun 2015 10:08:15 -0400
From: Peter Todd <pete@petertodd.org>
To: Adrian Macneil <adrian@coinbase.com>
Message-ID: <20150619140815.GA32470@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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6"
Content-Disposition: inline
In-Reply-To: <CAMK47c_kCgb6hEUf_JePAC_tBK8aCF1W4f1guiAah-Gj_cFfSw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: a2bfd31e-168c-11e5-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aQdMdwsUEkAaAgsB AmMbWlFeUFV7WGs7 bA9PbARUfEhLXhtr
	VklWR1pVCwQmRRl7 cxZoLU5ycwFOcHo+ ZENgXnAVDUYoIxJ+
	QxtJFGsONnphaTUa TRJbfgVJcANIexZF O1F6ACIKLwdSbGoL
	NQ4vNDcwO3BTJTpY RgYVKF8UXXNDMGQE QBcGVTUmBgUIQSw5
	KxEqYlABGEJZKEgq NVIqVBcSIlocBwA2 
X-Authentic-SMTP: 61633532353630.1023: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: 1Z5wy8-0003uD-12
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 14:08:33 -0000


--IJpNTDwzlM2Ie8A6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 19, 2015 at 07:00:56AM -0700, Adrian Macneil wrote:
> >
> > For instance, if Coinbase had
> > contracts with 80% of the Bitcoin hashing power to guarantee their
> > transactions would get mined, but 20% of the hashing power didn't sign
> > up, then the only way to guarantee their transactions could be for the
> > 80% to not build on blocks containing doublespends by the 20%.
> >
>=20
> This seems to be more of a problem with centralized mining than zeroconf
> transactions.

You're mistaking cause and effect: the contracts will drive
centralization of mining, as only the larger, non-anonymous, players
have the ability to enter into such contracts.

> Speaking of, could we get a confirmation that Coinbase is, or is not,
> > one of the merchant service providers trying to get hashing power
> > contracts with mining pools for guaranteed transaction acceptance? IIRC
> > you are still an advisor to them. This is a serious concern for the
> > reasons I outlined in my post.
> >
>=20
> We have no contracts in place or plans to do this that I am aware of.
>=20
> However, we do rely pretty heavily on zeroconf transactions for merchant
> processing, so if any significant portion of the mining pools started
> running your unsafe RBF patch, then we would probably need to look into
> this as a way to prevent fraud.

What happens if the mining pools who are mining double-spends aren't
doing it delibrately? Sybil attacking pools appears to have been done
before to get double-spends though, equally there are many other changes
the reduce the reliability of transaction confirmations. For instance
the higher demands on bandwidth of a higher blocksize will inevitably
reduce the syncronicity of mempools, resulting in double-spend
opportunities. Similarly many proposals to limit mempool size allow
zeroconf double-spends.

In that case would you enter into such contracts?

--=20
'peter'[:-1]@petertodd.org
000000000000000005a4c76d0bf088ef3e059914d6fc0335683a92b5be01b7dc

--IJpNTDwzlM2Ie8A6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJVhCJKXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxMjFlMjg1MGM4NmE5OWM4NjcyYzkzOTZhZGViYjBhMDc1
OWU4NWE1ZmJiODkyMmMvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfv6rwgAjIzRTRljEa55+DCJ2tDNcj8H
2jAr9zLlm4g0QhFlwI4ZYp5ryqiB+CJWiXs2LEgDSwbGnPcWRPM2RDCPyr9J0G4x
NAdpGgrN22lR/BFThnNqOrVktMW0FTYba3bhDEiMpGX5+aAoKnqZHsojR5uuLzgl
c4+OS/DVsPjrJ/oXxKPeaGnMqVbrRJUftFGmXTObF9LmZIRP7l38Yc5FbwQ9bMMQ
XcmL0hWOmWwcEJ/RQX1gIkaPQh24UxFc/ryJX0BPl5NW5+qLuw+rCTf3H/CrNsLL
+Pma+jDJlQNLUa9SBvj1DlEzi7mqpmTkk5JDSvdRitAV0AH5A4U/PJQi8WgRAg==
=+bMm
-----END PGP SIGNATURE-----

--IJpNTDwzlM2Ie8A6--