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
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
|
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 <drice@greenmangosystems.com>) id 1WwT0h-0001F7-O5
for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jun 2014 09:15:27 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of
greenmangosystems.com designates 209.85.220.175 as permitted
sender) client-ip=209.85.220.175;
envelope-from=drice@greenmangosystems.com;
helo=mail-vc0-f175.google.com;
Received: from mail-vc0-f175.google.com ([209.85.220.175])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WwT0f-0000it-Mu
for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jun 2014 09:15:27 +0000
Received: by mail-vc0-f175.google.com with SMTP id hy4so4616464vcb.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 16 Jun 2014 02:15:19 -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:date:message-id:subject:from:to
:content-type;
bh=mdd9pUVpenVe5ipg2bYfMtIqanOzwlhtQWX3c3YX/6Q=;
b=gVEmBTWVq5tsuCwVb1diCfZk3w7aQtxpZjvtW0YUf890Y/61aZDQ+PwcaxDh8irlFP
inrP+O22p5YWOrdBctikYHFl+8KcT3yLxqNavhZUqtX7+ariEsrm4us9Hsql7eREnAZf
B7uXnp4mH4HdE5XyhGKU5MserMvRkycMo8iHYlRS1vuBke1oPEM6kCzr8kZ/oNpazWOQ
P0XDSK5Cwr2mT8EgJ0oEdpeBU+pXO9LyMpdfuCrHeDgDBu9pbN5g9uNyCEl2wnznR+Ju
a1yhJOzXE17owMaB4wsJAQqqg/MDy0Ux1N0EdfovvZq3yvaobqEeiTCaCohrMFqoclj5
TlHA==
X-Gm-Message-State: ALoCoQkaZK7GimDxRgf6ARuF4CWWgIFaiSt1dG5FW5IVgeAfd2k1HCR4J5G8hDkbmib/tr6USzYh
MIME-Version: 1.0
X-Received: by 10.58.211.229 with SMTP id nf5mr10374533vec.19.1402908818839;
Mon, 16 Jun 2014 01:53:38 -0700 (PDT)
Received: by 10.58.123.35 with HTTP; Mon, 16 Jun 2014 01:53:38 -0700 (PDT)
Date: Mon, 16 Jun 2014 01:53:38 -0700
Message-ID: <CAFDyEXgbKtE4xrqMt3Ai9grD4otycVOEh95TtmvGCiQPv52-bg@mail.gmail.com>
From: Daniel Rice <drice@greenmangosystems.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=047d7bdc1824ccc74804fbf029bf
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: 1WwT0f-0000it-Mu
Subject: Re: [Bitcoin-development] instant confirmation via payment protocol
backwards compatible proto buffer extension
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, 16 Jun 2014 09:15:27 -0000
--047d7bdc1824ccc74804fbf029bf
Content-Type: text/plain; charset=UTF-8
Jumping in on this conversation because I've been doing research in this
area. Using a list of trusted providers in the payment details will be very
limiting and not scalable. I understand the reason for wanting the
supports_instant field, but I think that's a bad idea because the list
could literally be a million providers. Secondly, some merchants already
support instant transactions without any trust signature, so they should
also be able to advertise that as well.
I also don't believe that trusted or not trusted is a valid on and off
switch. For example, I might trust an instant provider for a 1 btc
transaction, but not 1,000,000 btc. Trust is all about the risk involved.
We can definitely learn from the current financial system in this realm.
I 100% agree with the In Payment Message portion of the BIP extension.
Here's how I think this will practically shake out in an automated way:
Anyone can become an instant provider, but nobody will trust them at first.
As that particular instant provider processes more and more transactions
without any double spends, they essentially build up trust. Based on the
past history of a particular instant provider a risk factor could be
calculated for a given transaction. This would also factor in the size of
the transaction. It would be very similar to a credit file showing the past
history of that particular instant provider based on all the transactions
they signed.
Andreas Schildbach <andreas <at> schildbach.de> writes:
> Just a quick comment:
>
> The supports_instant field seems redundant to me. First, as per your
> spec, you can derive it from trusted_instant_providers. And second, why
> do you need it at all? Protobuf is designed so it will simply ignore
> fields you don't know. So you can just send the instant_* fields in the
> Payment message without harm.
Agreed, supports_instant is redundant and can/should/will go.
trusted_instant_providers on the other hand I think is needed.
Sometimes the providers will charge fees for instant.
While the software can ignore the fields,
users may not want to pay for instant when the merchant may not accept it or
care (even if it would not break the protocol it would still be a waste of
fees)
Does it make sense?
Not all transactions from GreenAddress provide double spend protection, there
are additional checks on prevout that are normally not done when spending
normally, etc
--047d7bdc1824ccc74804fbf029bf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Jumping in on this conversation because I've been doin=
g research in this area.=C2=A0Using a list of trusted providers in the paym=
ent details will be very limiting and not scalable.=C2=A0I=C2=A0understand =
the reason for wanting the supports_instant field, but I think that's a=
bad idea because the list could literally be a million providers. Secondly=
, some merchants already support instant transactions without any trust sig=
nature, so they should also be able to advertise that as well.<div>
<br></div><div>I also don't believe that trusted or not trusted is a va=
lid on and off switch. For example, I might trust an instant provider for a=
1 btc transaction, but not 1,000,000 btc. Trust is all about the risk invo=
lved. We can definitely learn from the current financial system in this rea=
lm.</div>
<div><br></div><div>I 100% agree with the In Payment Message portion of the=
BIP extension. Here's how I think this will practically shake out in a=
n automated way: Anyone can become an instant provider, but nobody will tru=
st them at first. As that particular instant provider processes more and mo=
re transactions without any double spends, they essentially build up trust.=
Based on the past history of a particular instant provider a risk factor c=
ould be calculated for a given transaction. This would also factor in the s=
ize of the transaction. It would be very similar to a credit file showing t=
he past history of that particular instant provider based on all the transa=
ctions they signed.</div>
<div><div><br></div><div><pre style=3D"margin-top:0px;margin-bottom:0px;pad=
ding:15px;border-width:0px 0px 0px 1px;border-left-style:solid;border-left-=
color:rgb(229,229,229);outline:0px;font-size:13px;vertical-align:baseline;f=
ont-family:monospace,sans-serif;white-space:pre-wrap;word-wrap:break-word;o=
verflow:auto;color:rgb(85,85,85);line-height:18px;background-image:initial;=
background-repeat:initial">
Andreas Schildbach <andreas <at> <a href=3D"http://schildbach.de">=
schildbach.de</a>> writes:
=20
> Just a quick comment:
>=20
> The supports_instant field seems redundant to me. First, as per your
> spec, you can derive it from trusted_instant_providers. And second, wh=
y
> do you need it at all? Protobuf is designed so it will simply ignore
> fields you don't know. So you can just send the instant_* fields i=
n the
> Payment message without harm.
Agreed, supports_instant is redundant and can/should/will go.
trusted_instant_providers on the other hand I think is needed.
Sometimes the providers will charge fees for instant.
While the software can ignore the fields,=20
users may not want to pay for instant when the merchant may not accept it o=
r=20
care (even if it would not break the protocol it would still be a waste of=
=20
fees)
Does it make sense?=20
Not all transactions from GreenAddress provide double spend protection, the=
re=20
are additional checks on prevout that are normally not done when spending=
=20
normally, etc</pre></div></div></div>
--047d7bdc1824ccc74804fbf029bf--
|
