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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <kalle@rosenbaum.se>) id 1YwdDS-0006Gx-SI
for bitcoin-development@lists.sourceforge.net;
Sun, 24 May 2015 21:13:50 +0000
X-ACL-Warn:
Received: from mail-qg0-f52.google.com ([209.85.192.52])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YwdDP-0003hV-5e
for bitcoin-development@lists.sourceforge.net;
Sun, 24 May 2015 21:13:50 +0000
Received: by qgew3 with SMTP id w3so36060783qge.2
for <bitcoin-development@lists.sourceforge.net>;
Sun, 24 May 2015 14:13:41 -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=4b2jmC7GbyRwBKqz7P5eZNDrM3pAj0oJ5t4ImJIl9d8=;
b=XnNN5bSCdZ2JFYfVUsm27xvinu/VZtGincL611zpvq0gZq7PSY+x9FlJbSVWmcqrjV
Ql5jn0ehtGw+n2sbT0P/FXy4fcWtjHw+j1me/DhmbuZDUX4jH3nIkem2jD5QcaJXdMbE
8zfNCQRrZ+8TZ+/ScLT31rizb4jM/blrnysEXXIzFYIMYPLLq2uLALfqYBjrUWXYf3dd
rPqBfvTFh/ZvdVNAX8Ze6rqvd+HkPFH4zTFF0Kf531th/Ceymk2FNpoShkYq3fTmOYrW
HpT/6UpJ2s+Bn4lBwsPeAUqK7RaTbMyBwlNugDTIrJTW+4AoOiE0rqirBWoIzJv2aXfn
elCQ==
X-Gm-Message-State: ALoCoQmVLWyJzRjW2vYzoSSbRLpmGEf+hO/EWBw52Cplnh1fxMA4HR96/JoGyfn6l8T8GO5URWA3
MIME-Version: 1.0
X-Received: by 10.55.16.33 with SMTP id a33mr39025922qkh.51.1432500316808;
Sun, 24 May 2015 13:45:16 -0700 (PDT)
Received: by 10.96.145.9 with HTTP; Sun, 24 May 2015 13:45:16 -0700 (PDT)
Date: Sun, 24 May 2015 22:45:16 +0200
Message-ID: <CAPswA9x8YNCUb_W30LMDbUQ34W=1OUnrghaSx_PGOwt=VnBVTg@mail.gmail.com>
From: Kalle Rosenbaum <kalle@rosenbaum.se>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a113acf008648110516d9f866
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: 1YwdDP-0003hV-5e
Subject: [Bitcoin-development] Proof of Payment BIP-able?
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: Sun, 24 May 2015 21:13:50 -0000
--001a113acf008648110516d9f866
Content-Type: text/plain; charset=UTF-8
Hi all!
As indicated in my first email regarding Proof of Payment (Mars 13, subject
"Proof of Payment"), I would like to BIP it. I have two proposals:
* PoP datastructure and process:
https://github.com/kallerosenbaum/poppoc/wiki/Proof-of-Payment
* btcpop: URI scheme:
https://github.com/kallerosenbaum/poppoc/wiki/btcpop-scheme
Basically, my question to the community is: Do you agree that these are
BIP-able?
The proposals are not yet BIP formatted, but pretty complete. An
implementation is avaliable at https://github.com/kallerosenbaum/poppoc.
Specifically, the PoP validating code is in PopValidator.java
<https://github.com/kallerosenbaum/poppoc/blob/master/src/main/java/se/rosenbaum/poppoc/core/validate/PopValidator.java>
.
As far as I can tell from the previous thread, no major objection against
the idea was raised. PoP, if standardized, would bring a lot of utility to
bitcoin: Paysite login, concert tickets, left luggage lockers, lotteries,
video rental, etc.
Further on, I'd like to extend BIP70 to support PoP, but that will have to
wait until we have consensus around the two basic proposals above.
I have received some great feedback from the community and included most of
it in the updated version of the specification. The essential changes are:
* If a PoP for some reason appears in the bitcoin p2p network, we must make
sure that IF it is included in a block it should have minimal impact. The
solution I chose was to include all outputs of the original paymet in the
PoP. That way, if the PoP is included it will not alter the payees. (Thanks
to Tom Harding for pointing out the problem and Magnus Andersson for the
initial solution).
* The check if the transaction is actually a tx that you want proof for is
moved to later in the validation process. Otherwise, one could get
information on what transactions pays for which services by simply sending
erroneously signed PoPs with a transaction id we're interested in.
* A version field of 2 bytes is included. Currently the only valid version
is 0x00 0x01. (Thanks Martin Lie)
* The "PoP" literal is removed. It provides little value as the receiver of
a PoP expects a PoP. (Again, thanks Martin Lie for making me think about
this.)
Regards,
Kalle Rosenbaum
--001a113acf008648110516d9f866
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>Hi all!<br><br>As indicated in my first email re=
garding Proof of Payment (Mars 13, subject "Proof of Payment"), I=
would like to BIP it. I have two proposals:<br><br>* PoP datastructure and=
process: <a href=3D"https://github.com/kallerosenbaum/poppoc/wiki/Proof-of=
-Payment">https://github.com/kallerosenbaum/poppoc/wiki/Proof-of-Payment</a=
><br>* btcpop: URI scheme: <a href=3D"https://github.com/kallerosenbaum/pop=
poc/wiki/btcpop-scheme">https://github.com/kallerosenbaum/poppoc/wiki/btcpo=
p-scheme</a><br><br></div><div>Basically, my question to the community is: =
Do you agree that these are BIP-able?<br></div><div><br>The proposals are n=
ot yet BIP formatted, but pretty complete. An implementation is avaliable a=
t <a href=3D"https://github.com/kallerosenbaum/poppoc">https://github.com/k=
allerosenbaum/poppoc</a>. Specifically, the PoP validating code is in<span =
class=3D""> <a href=3D"https://github.com/kallerosenbaum/poppoc/blob/master=
/src/main/java/se/rosenbaum/poppoc/core/validate/PopValidator.java">PopVali=
dator.java</a></span>.<br><br></div><div>As far as I can tell from the prev=
ious thread, no=20
major objection against the idea was raised. PoP, if standardized,=20
would bring a lot of utility to bitcoin: Paysite login,=20
concert tickets, left luggage lockers, lotteries, video rental, etc.<br><br=
>Further on, I'd like to extend BIP70 to support PoP, but that will hav=
e to wait until we have consensus around the two basic proposals above.<br>=
</div><br></div><div><div><div>I have received some great feedback from the=
community and included most of it in the updated version of the specificat=
ion. The essential changes are:<br><br>* If a PoP for some reason appears i=
n the bitcoin p2p network, we must make sure that IF it is included in a bl=
ock it should have minimal impact. The solution I chose was to include all =
outputs of the original paymet in the PoP. That way, if the PoP is included=
it will not alter the payees. (Thanks to Tom Harding for pointing out the =
problem and Magnus Andersson for the initial solution).<br><br>* The check =
if the transaction is actually a tx that you want proof for is moved to lat=
er in the validation process. Otherwise, one could get information on what =
transactions pays for which services by simply sending erroneously signed P=
oPs with a transaction id we're interested in.<br><br>* A version field=
of 2 bytes is included. Currently the only valid version is 0x00 0x01. (Th=
anks Martin Lie)<br><br>* The "PoP" literal is removed. It provid=
es little value as the receiver of a PoP expects a PoP. (Again, thanks Mart=
in Lie for making me think about this.)<br><br></div><div>Regards,<br></div=
><div>Kalle Rosenbaum<br></div></div></div></div>
--001a113acf008648110516d9f866--
|
