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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <kalle@rosenbaum.se>) id 1YmiG6-0000Yc-6p
for bitcoin-development@lists.sourceforge.net;
Mon, 27 Apr 2015 12:35:34 +0000
X-ACL-Warn:
Received: from mail-qc0-f173.google.com ([209.85.216.173])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YmiG4-0005b7-T3
for bitcoin-development@lists.sourceforge.net;
Mon, 27 Apr 2015 12:35:34 +0000
Received: by qcbii10 with SMTP id ii10so54052401qcb.2
for <bitcoin-development@lists.sourceforge.net>;
Mon, 27 Apr 2015 05:35:27 -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=fgawZ10MzjEfeuWVp6TU1xYlPNCOzkxIbITKbOX3nZw=;
b=m+24Eem7e34kZEEYHeMRzU8WuTB6TvkuJVwo+L52sYRLT7lANo9D3N8edr8xSiohEh
FRypDAWxl9dcWvBkwqsqVjP/6+T8Dl4CJzAGGnDskpR2ZXVkyDmO5+VWltBHHyPtquRj
B8cymokj6wXdP0JUqrt/7fcjf/rPnj2Kjf6Zyjx15gMOi01bqODajwSQE1gbXaEfxI+K
btCxX5uuovnnZt2F/V63jJhOcGIBpm64x5FdGm3+dXNL4USoHAFM5OOPHQqmP5UyGESo
yzTNpI3CerUzTEsm0j6HuxNOnffLh/kPkwiX8dVvhcxBaaeXpCbXA1uTv9ajW/TDx85j
0H0A==
X-Gm-Message-State: ALoCoQlGawi8mvBgG1e++Ojh6xmi3OJNoryMDBtkxRs7r9XmCcyR76KD6tsDEzbyah2f+U47BYU0
MIME-Version: 1.0
X-Received: by 10.55.20.207 with SMTP id 76mr11997682qku.46.1430138127291;
Mon, 27 Apr 2015 05:35:27 -0700 (PDT)
Received: by 10.96.145.9 with HTTP; Mon, 27 Apr 2015 05:35:27 -0700 (PDT)
Received: by 10.96.145.9 with HTTP; Mon, 27 Apr 2015 05:35:27 -0700 (PDT)
In-Reply-To: <553D87CE.5000005@thinlink.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>
Date: Mon, 27 Apr 2015 14:35:27 +0200
Message-ID: <CAPswA9xUfr1D6New3hm+1Z1OqSfkAZ8L+VnbFZayG+uJecgaeA@mail.gmail.com>
From: Kalle Rosenbaum <kalle@rosenbaum.se>
To: Tom Harding <tomh@thinlink.com>
Content-Type: multipart/alternative; boundary=001a114005320eaa4a0514b3fbcf
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: 1YmiG4-0005b7-T3
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: Mon, 27 Apr 2015 12:35:34 -0000
--001a114005320eaa4a0514b3fbcf
Content-Type: text/plain; charset=UTF-8
>
> 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
--001a114005320eaa4a0514b3fbcf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">><br>
> Some more use cases might be:<br>
> Waiting in comfort:<br>
> =C2=A0- Send a payment ahead of time, then wander over and collect the=
goods<br>
> after X confirmations.<br>
><br>
> Authorized pickup :<br>
> =C2=A0- Hot wallet software used by related people could facilitate th=
e use<br>
> of 1 of N multisig funds.=C2=A0 Any one of the N wallets could collect=
goods<br>
> and services purchased by any of the others.</p>
<p dir=3D"ltr">I like this one, because it shows the power of reusing the t=
ransaction data structure.</p>
<p dir=3D"ltr">><br>
> Non-monetary gifts:<br>
> =C2=A0- Sender exports spent keys to a beneficiary, enabling PoP to wo=
rk as a<br>
> gift claim<br>
><br>
> Contingent services:<br>
> =C2=A0- Without Bob's permission, a 3rd party conditions action on=
a payment<br>
> made from Alice to Bob.=C2=A0 For example, if you donated at least .02=
BTC to<br>
> Dorian, you (or combining scenarios, any of your N authorized family<b=
r>
> members), can come to my dinner party.</p>
<p dir=3D"ltr">This is an interesting one.</p>
<p dir=3D"ltr">><br>
> I tried out your demo wallet and service and it worked as advertised.<=
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 payments, yo=
u could<br>
> call it something like proof of payment potential.</p>
<p dir=3D"ltr">I guess it's possible, but we'd have to remove the t=
xid from the output, since there is none. This is a way of saying "I&#=
39;m in control of these addresses". The other party/parties can then =
verify the funds on the blockchain and watch those addresses for changes. M=
aybe there are some interesting use cases here. Ideas?</p>
<p dir=3D"ltr">><br>
> Why not make these proofs permanently INVALID transactions, to remove<=
br>
> any possibility of their being mined and spending everything to fees<b=
r>
> when used in this way, and also in cases involving reorganizations?</p=
>
<p dir=3D"ltr">Yes. Initially I thought it would be enough that the funds a=
re already spent, but I think you're right here. Reorgs could be a prob=
lem. Worse, you also might want to prove 0-confirmation transactions, in wh=
ich 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 modifi=
cations. Could we possibly change the version number on the PoP to somethin=
g other than 1? Maybe 2^4-1? Or a really high lock_time, but it would not m=
ake it invalid, just delayed. Any suggestions here? </p>
<p dir=3D"ltr">><br>
> I agree that PoP seems complementary to BIP70.<br>
><br>
></p>
<p dir=3D"ltr">Thank you very much for your comments!</p>
<p dir=3D"ltr">/Kalle </p>
--001a114005320eaa4a0514b3fbcf--
|
