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
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <kalle@rosenbaum.se>) id 1Yn4pg-0005Ff-8k
for bitcoin-development@lists.sourceforge.net;
Tue, 28 Apr 2015 12:41:48 +0000
X-ACL-Warn:
Received: from mail-qg0-f43.google.com ([209.85.192.43])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yn4pe-0002xH-4B
for bitcoin-development@lists.sourceforge.net;
Tue, 28 Apr 2015 12:41:48 +0000
Received: by qgfi89 with SMTP id i89so62284052qgf.1
for <bitcoin-development@lists.sourceforge.net>;
Tue, 28 Apr 2015 05:41:40 -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=x7sZdaKuOYXweMZl753WFXuK+1YSiXDtcFFNJSMMwZA=;
b=aVduk8Hzub2sPkU5pnBLnOD1sLQ97DxyN2yhStsLm022NqaJa+ZQ4HjdbECONCbAud
cQvf7UbKxUUN5GDZXj2fFi27A9gQg7yjgXWcy77/LkTILEhIZxVUUxWT0W0r3Mg5jqUQ
4G2b12yVjgRjHwLDTLoP40l+rCIt/6oKbopCTGZhBDkwf4idmotvuxrn56Sb6g5mjSLu
wbK0xLB5Bt5WmuA3e86O8N4Ntiz9wMyFxb1qMjECB3IG8ft95TPe+QlQxmxB/c3XDXpj
F8BHUOva7ZZ0zsMhqQ26SqKZSB0pzI1cQmuR0+5ykLa9FAfFDFtOgR5G+zLkpGaH1iXE
darQ==
X-Gm-Message-State: ALoCoQm6oz1D4/d+U9F+O3VKa7gww8cW5iqlMkL8JxhlrAXGUVZVX2X4uRQy98UlYt5IrZzkxhDL
MIME-Version: 1.0
X-Received: by 10.140.28.163 with SMTP id 32mr11689722qgz.5.1430224900577;
Tue, 28 Apr 2015 05:41:40 -0700 (PDT)
Received: by 10.96.145.9 with HTTP; Tue, 28 Apr 2015 05:41:40 -0700 (PDT)
Received: by 10.96.145.9 with HTTP; Tue, 28 Apr 2015 05:41:40 -0700 (PDT)
In-Reply-To: <CABm2gDrumXjfo7=YmTSkRO0QPtPtUj4PF9yb1m80L60O-HZe6A@mail.gmail.com>
References: <CAPswA9zzVDxW8_WXg5833r2Z4pxZOppYtNLHMQ=Nw-H72cMz7w@mail.gmail.com>
<A2849710-1069-45A1-89C0-9D8E40C4A8D6@newcastle.ac.uk>
<CAPswA9wNS2J=4YhpqWN8SmzJuUF8mek8XLUYTE+twLX9vM4Jhg@mail.gmail.com>
<CAPswA9wZk_8EjbN8J-VbMGQ6nrZ7SthopJ=HYMtpxhSCsm_neA@mail.gmail.com>
<553D87CE.5000005@thinlink.com>
<CAPswA9xUfr1D6New3hm+1Z1OqSfkAZ8L+VnbFZayG+uJecgaeA@mail.gmail.com>
<CAPswA9w=DMDokS8BrDPTtWa_qpdORbK+V4aNS4DoAKE_F1iVoA@mail.gmail.com>
<CABm2gDrumXjfo7=YmTSkRO0QPtPtUj4PF9yb1m80L60O-HZe6A@mail.gmail.com>
Date: Tue, 28 Apr 2015 14:41:40 +0200
Message-ID: <CAPswA9z9K2w-uEHMOrAvAENs5L1iS8PYu2xMOFidDUJvU04O5w@mail.gmail.com>
From: Kalle Rosenbaum <kalle@rosenbaum.se>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=001a1139b1b225f4ce0514c82f21
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1Yn4pe-0002xH-4B
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proof of Payment
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: Tue, 28 Apr 2015 12:41:48 -0000
--001a1139b1b225f4ce0514c82f21
Content-Type: text/plain; charset=UTF-8
Hi Jorge,
I don't think I understand the question. Proof of Payment is used to prove
that you have the credentials needed for a certain transaction. It does not
care where in the blockchain the transaction is. Or if it's in the
blockchain at all.
/Kalle
So at the low level, how does a "proof of payment" differ from just proving
that a given transaction is in a given block (what SPV nodes take as proof
of payment today)?
On Apr 27, 2015 2:42 PM, "Kalle Rosenbaum" <kalle@rosenbaum.se> wrote:
> "Or a really high lock_time, but it would not make it invalid, just
> delayed."
>
> Ok, this was a bad idea, since nodes would have to keep it in memory.
> Please disregard that idea...
>
> Kalle
>
> Den 27 apr 2015 14:35 skrev "Kalle Rosenbaum" <kalle@rosenbaum.se>:
> >
> > >
> > > Some more use cases might be:
> > > Waiting in comfort:
> > > - Send a payment ahead of time, then wander over and collect the goods
> > > after X confirmations.
> > >
> > > Authorized pickup :
> > > - Hot wallet software used by related people could facilitate the use
> > > of 1 of N multisig funds. Any one of the N wallets could collect goods
> > > and services purchased by any of the others.
> >
> > I like this one, because it shows the power of reusing the transaction
> data structure.
> >
> > >
> > > Non-monetary gifts:
> > > - Sender exports spent keys to a beneficiary, enabling PoP to work as
> a
> > > gift claim
> > >
> > > Contingent services:
> > > - Without Bob's permission, a 3rd party conditions action on a payment
> > > made from Alice to Bob. For example, if you donated at least .02 BTC
> to
> > > Dorian, you (or combining scenarios, any of your N authorized family
> > > members), can come to my dinner party.
> >
> > This is an interesting one.
> >
> > >
> > > I tried out your demo wallet and service and it worked as advertised.
> > >
> > > Could the same standard also be used to prove that a transaction COULD
> > > BE created? To generalize the concept beyond actual payments, you
> could
> > > call it something like proof of payment potential.
> >
> > I guess it's possible, but we'd have to remove the txid from the output,
> since there is none. This is a way of saying "I'm in control of these
> addresses". The other party/parties can then verify the funds on the
> blockchain and watch those addresses for changes. Maybe there are some
> interesting use cases here. Ideas?
> >
> > >
> > > Why not make these proofs permanently INVALID transactions, to remove
> > > any possibility of their being mined and spending everything to fees
> > > when used in this way, and also in cases involving reorganizations?
> >
> > Yes. Initially I thought it would be enough that the funds are already
> spent, but I think you're right here. Reorgs could be a problem. Worse, you
> also might want to prove 0-confirmation transactions, in which case it's a
> huge security problem. Someone might intercept the PoP and publish it on
> the bitcoin network, spending all the funds. But I still would like wallets
> to be able to build/verify PoPs with little or no modifications. Could we
> possibly change the version number on the PoP to something other than 1?
> Maybe 2^4-1? Or a really high lock_time, but it would not make it invalid,
> just delayed. Any suggestions here?
> >
> > >
> > > I agree that PoP seems complementary to BIP70.
> > >
> > >
> >
> > Thank you very much for your comments!
> >
> > /Kalle
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--001a1139b1b225f4ce0514c82f21
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Hi Jorge,</p>
<p dir=3D"ltr">I don't think I understand the question. Proof of Paymen=
t is used to prove that you have the credentials needed for a certain trans=
action. It does not care where in the blockchain the transaction is. Or if =
it's in the blockchain at all. </p>
<p dir=3D"ltr">/Kalle</p>
<div class=3D"gmail_quot<blockquote class=3D" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">So at the low =
level, how does a "proof of payment" differ from just proving tha=
t a given transaction is in a given block (what SPV nodes take as proof of =
payment today)?</p>
<div class=3D"gmail_quote">On Apr 27, 2015 2:42 PM, "Kalle Rosenbaum&q=
uot; <<a href=3D"mailto:kalle@rosenbaum.se" target=3D"_blank">kalle@rose=
nbaum.se</a>> wrote:<br type=3D"attribution"><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><p dir=3D"ltr">"Or a really high lock_time, but it would not make =
it invalid, just delayed." </p>
<p dir=3D"ltr">Ok, this was a bad idea, since nodes would have to keep it i=
n memory. Please disregard that idea... </p>
<p dir=3D"ltr">Kalle </p>
<p dir=3D"ltr">Den 27 apr 2015 14:35 skrev "Kalle Rosenbaum" <=
<a href=3D"mailto:kalle@rosenbaum.se" target=3D"_blank">kalle@rosenbaum.se<=
/a>>:<br>
><br>
> ><br>
> > Some more use cases might be:<br>
> > Waiting in comfort:<br>
> > =C2=A0- Send a payment ahead of time, then wander over and collec=
t the goods<br>
> > after X confirmations.<br>
> ><br>
> > Authorized pickup :<br>
> > =C2=A0- Hot wallet software used by related people could facilita=
te the use<br>
> > of 1 of N multisig funds.=C2=A0 Any one of the N wallets could co=
llect goods<br>
> > and services purchased by any of the others.<br>
><br>
> I like this one, because it shows the power of reusing the transaction=
data structure.<br>
><br>
> ><br>
> > Non-monetary gifts:<br>
> > =C2=A0- Sender exports spent keys to a beneficiary, enabling PoP =
to work as a<br>
> > gift claim<br>
> ><br>
> > Contingent services:<br>
> > =C2=A0- Without Bob's permission, a 3rd party conditions acti=
on on a payment<br>
> > made from Alice to Bob.=C2=A0 For example, if you donated at leas=
t .02 BTC to<br>
> > Dorian, you (or combining scenarios, any of your N authorized fam=
ily<br>
> > members), can come to my dinner party.<br>
><br>
> This is an interesting one.<br>
><br>
> ><br>
> > I tried out your demo wallet and service and it worked as adverti=
sed.<br>
> ><br>
> > Could the same standard also be used to prove that a transaction =
COULD<br>
> > BE created?=C2=A0 To generalize the concept beyond actual payment=
s, you could<br>
> > call it something like proof of payment potential.<br>
><br>
> I guess it's possible, but we'd have to remove the txid from t=
he output, since there is none. This is a way of saying "I'm in co=
ntrol of these addresses". The other party/parties can then verify the=
funds on the blockchain and watch those addresses for changes. Maybe there=
are some interesting use cases here. Ideas?<br>
><br>
> ><br>
> > Why not make these proofs permanently INVALID transactions, to re=
move<br>
> > any possibility of their being mined and spending everything to f=
ees<br>
> > when used in this way, and also in cases involving reorganization=
s?<br>
><br>
> Yes. Initially I thought it would be enough that the funds are already=
spent, but I think you're right here. Reorgs could be a problem. Worse=
, you also might want to prove 0-confirmation transactions, in which case i=
t's a huge security problem. Someone might intercept the PoP and publis=
h it on the bitcoin network, spending all the funds. But I still would like=
wallets to be able to build/verify PoPs with little or no modifications. C=
ould we possibly change the version number on the PoP to something other th=
an 1? Maybe 2^4-1? Or a really high lock_time, but it would not make it inv=
alid, just delayed. Any suggestions here?<br>
><br>
> ><br>
> > I agree that PoP seems complementary to BIP70.<br>
> ><br>
> ><br>
><br>
> Thank you very much for your comments!<br>
><br>
> /Kalle</p>
<br>-----------------------------------------------------------------------=
-------<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br=
>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br=
>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>=
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div>
</div>
--001a1139b1b225f4ce0514c82f21--
|
