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
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
|
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 <adrian@coinbase.com>) id 1Z5xJL-0007YC-W4
for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 14:30:28 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of coinbase.com
designates 209.85.212.175 as permitted sender)
client-ip=209.85.212.175; envelope-from=adrian@coinbase.com;
helo=mail-wi0-f175.google.com;
Received: from mail-wi0-f175.google.com ([209.85.212.175])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z5xJH-0004W1-6n
for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 14:30:27 +0000
Received: by wicnd19 with SMTP id nd19so20841532wic.1
for <bitcoin-development@lists.sourceforge.net>;
Fri, 19 Jun 2015 07:30:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=eod5m2fmsZW6/mTMuPeVhAWXC33YRRo2oO62Ilx6kzc=;
b=BfddzwuziRuJ9FiA4Rcvdn193ls9RXgAeiJ+pFH7UmMbdZ8vlyIVy2eTY4aVu+fhsq
/9k78nkL0yVyowgdvSeLLdEt1CVll8SY3SrPvjC3+jBqwnnbbcodxCSR/FStm/8v4j/w
3CaZz9RTutuhMqt2ZmOj5DmaUXuBb2MGwNi2AiPbLuw/dZyP0JRFsIYj24fCcjOlsxDN
HnxemfXfrysayNDFojT73ETeZHQKkQ9jEzUs3LPR8H5btIUixPr9Xhw154I+0o/d68Rq
nPIj5662ypZsyOqR0Fg/juH8i/i1ObxsM4LC66BowJcmzDSc34Jg8jxnFfctkNjsAIzg
scww==
X-Gm-Message-State: ALoCoQnhQRXVVdivi2NlmMBcN4pEBqYVJnRIWA9Hg6/PCOx8YP4HUhGx/HPzICkeOA1Et4oS2LLI
MIME-Version: 1.0
X-Received: by 10.180.37.230 with SMTP id b6mr7320040wik.14.1434724217179;
Fri, 19 Jun 2015 07:30:17 -0700 (PDT)
Received: by 10.27.177.99 with HTTP; Fri, 19 Jun 2015 07:30:17 -0700 (PDT)
In-Reply-To: <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>
<20150619140815.GA32470@savin.petertodd.org>
Date: Fri, 19 Jun 2015 07:30:17 -0700
Message-ID: <CAMK47c9NhX2gzCioTycEPXqyYeKRM9XgXuW9MGyj=OdGsKVbFg@mail.gmail.com>
From: Adrian Macneil <adrian@coinbase.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=e89a8f64701d50f0620518dfc3be
X-Spam-Score: -0.6 (/)
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
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Z5xJH-0004W1-6n
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:30:28 -0000
--e89a8f64701d50f0620518dfc3be
Content-Type: text/plain; charset=UTF-8
>
> > We have no contracts in place or plans to do this that I am aware of.
> >
> > 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?
>
We take it as it comes.
Currently, it's perfectly possible to accept zeroconf transactions with
only a very small chance of double spend. As long as it's only possible to
double spend a small fraction of the time, it's an acceptable cost to us in
exchange for being able to provide a fast checkout experience to customers
and merchants.
If the status quo changes, then we will need to investigate alternatives
(which realistically would include mining contracts, or only accepting
instant payments from other trusted hosted wallets, which would be a net
loss for decentralization).
Long term we would prefer to see an open, decentralized solution, such as
payment channels / green addresses / lightening networks. However, I think
as a community we are a long way away from choosing a standard here and
implementing it across all popular wallet software and merchant processors.
Adrian
--e89a8f64701d50f0620518dfc3be
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><span class=3D"">> We have no contracts in pl=
ace or plans to do this that I am aware of.<br>
><br>
> However, we do rely pretty heavily on zeroconf transactions for mercha=
nt<br>
> processing, so if any significant portion of the mining pools started<=
br>
> running your unsafe RBF patch, then we would probably need to look int=
o<br>
> this as a way to prevent fraud.<br>
<br>
</span>What happens if the mining pools who are mining double-spends aren&#=
39;t<br>
doing it delibrately? Sybil attacking pools appears to have been done<br>
before to get double-spends though, equally there are many other changes<br=
>
the reduce the reliability of transaction confirmations. For instance<br>
the higher demands on bandwidth of a higher blocksize will inevitably<br>
reduce the syncronicity of mempools, resulting in double-spend<br>
opportunities. Similarly many proposals to limit mempool size allow<br>
zeroconf double-spends.<br>
<br>
In that case would you enter into such contracts?<br></blockquote><div><br>=
</div><div>We take it as it comes.</div><div><br></div><div>Currently, it&#=
39;s perfectly possible to accept zeroconf transactions with only a very sm=
all chance of double spend. As long as it's only possible to double spe=
nd a small fraction of the time, it's an acceptable cost to us in excha=
nge for being able to provide a fast checkout experience to customers and m=
erchants.</div><div><br></div><div>If the status quo changes, then we will =
need to investigate alternatives (which realistically would include mining =
contracts, or only accepting instant payments from other trusted hosted wal=
lets, which would be a net loss for decentralization).</div><div><br></div>=
<div>Long term we would prefer to see an open, decentralized solution, such=
as payment channels / green addresses / lightening networks. However, I th=
ink as a community we are a long way away from choosing a standard here and=
implementing it across all popular wallet software and merchant processors=
.</div><div><br></div><div>Adrian</div></div></div></div>
--e89a8f64701d50f0620518dfc3be--
|
