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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <kalle@rosenbaum.se>) id 1YlIHi-00081S-S1
for bitcoin-development@lists.sourceforge.net;
Thu, 23 Apr 2015 14:39:22 +0000
X-ACL-Warn:
Received: from mail-qc0-f175.google.com ([209.85.216.175])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YlIHh-0007Mb-7k
for bitcoin-development@lists.sourceforge.net;
Thu, 23 Apr 2015 14:39:22 +0000
Received: by qcrf4 with SMTP id f4so10142228qcr.0
for <bitcoin-development@lists.sourceforge.net>;
Thu, 23 Apr 2015 07:39:15 -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:content-type;
bh=BQNyiypxXH3mWfKlk+63x0FXWtODyJ2TymJ9O5Js0q4=;
b=blbqrbxeUGr/HAK0Q9HT/RToLkRcKQC3UTGVISRScpta1YIamUfWcrfXf4NnI+ihHQ
XZs/PC/NPGod7kjwJkKpam0oeEq1D+jLf9wrAXYSKzceJ8yPxkjjlc9Wo6elEw7qxuIa
M+HuTDcxY7wDFeAb6jV6VO/1zT0tXFt7T9jiGuu7i0ZFk+RGf7kbuVNaROnBlcjZPEMj
WZPjoyAyRpBhx6FSGzopymvkQn93wLdkuS4tWyO7VNSy+WM/PsBeooi+7F48FVq+O25q
73XtcC70MJwRRMnVP8Po+26DDHoCjq+pvfXxb1eXEl1girsZslctGWKR8NSFabGYUF3T
8lKQ==
X-Gm-Message-State: ALoCoQmk4nddF8MWjSGnYdNiXan22oYIkOUjSUf/b9zPMBhj6wi6ENSzt+A8V5CA6gEa9JIHYFUb
MIME-Version: 1.0
X-Received: by 10.140.145.88 with SMTP id 85mr3693638qhr.39.1429799955630;
Thu, 23 Apr 2015 07:39:15 -0700 (PDT)
Received: by 10.96.145.9 with HTTP; Thu, 23 Apr 2015 07:39:15 -0700 (PDT)
Received: by 10.96.145.9 with HTTP; Thu, 23 Apr 2015 07:39:15 -0700 (PDT)
In-Reply-To: <55384AC9.80501@datamagi.no>
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>
<55384AC9.80501@datamagi.no>
Date: Thu, 23 Apr 2015 16:39:15 +0200
Message-ID: <CAPswA9x7LGFjWce35+4=m1t-DCOA==R+6=1tdimgV7TsAkZ1MQ@mail.gmail.com>
From: Kalle Rosenbaum <kalle@rosenbaum.se>
To: Martin Lie <martin@datamagi.no>,
Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a1137610c74a2810514653e53
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: 1YlIHh-0007Mb-7k
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: Thu, 23 Apr 2015 14:39:22 -0000
--001a1137610c74a2810514653e53
Content-Type: text/plain; charset=UTF-8
Hi Martin,
Thank you very much for your comments. See my answers inline:
Den 23 apr 2015 03:28 skrev "Martin Lie" <martin@datamagi.no>:
>
> Hej, Kalle.
>
> I love the idea of standardised PoPs, including a protocol for
requesting/sending them as an extension of BIP-70.
>
Me too!
>
> A couple of comments:
>
> 1. You admit that the txid is just a convenience and not strictly
necessary. Perhaps this should be reflected in the sequence of bits/bytes
in the record you're proposing, e.g. "OP_RETURN POP_LITERAL <nonce> <txid>"?
>
I was thinking that txid should be mandatory just as the nonce so the order
was arbitrarily chosen. I think you may be right that it's more intuitive
to put txid last if it's not mandatory in a future version. It makes sense
to swap order. I'll put that on my todo list.
> 2. Building on #1, perhaps there could be other identifying information
than a txid? Perhaps a txid field shouldn't be "hardcoded" into the
standard at all?
>
> How about taking the same approach as BIP-43 (and others) and use a
prefix that determines how the rest of the records should be interpreted,
i.e. a "type" (or "purpose" or "version" or whatever you'd like to call it)
field. This would allow for different purposes/versions of a PoP, including
as of now unforeseen ones.
>
> The new structure would then be:
> OP_RETURN POP_PREFIX POP_TYPE POP_NONCE POP_PAYLOAD
>
> POP_PREFIX (? bytes): I'll leave it up to you to specify the exact bits
(and length) of the POP_PREFIX, but if your literal is used, it'd be 3
bytes: 0x506f50.
>
> Literals in Bitcoin protocols generally seem to be of the "binary" sort
as opposed to human-readable text, so perhaps the devs wouldn't ACK
something as "wasteful" as using 3 bytes just to identify it as a PoP
record? Obviously, this is a small detail that can be changed at short
notice, but as with all standards - once people start using it, you're
mostly stuck with what you have. ;)
>
Yes, maybe we could drop POP_PREFIX altogether. The server is expecting a
pop and can therefore just assume it's a pop. No need to explicitly write
that inside the pop. Can you think of a scenario where it is actually
needed. Keeping the POP_PREFIX makes sense only if other transaction-like
data structures with OP_RETURN appears in the same contexts as pops. What
do you think?
> POP_TYPE: (1 byte): 0x01 for your "standard" version, which would mean
that the payload contains a txid.
>
This is a good idea. Todo!
> POP_NONCE: (4 bytes): "2^32 re-uses should be enough for everyone", no? ;)
>
Euhm, well, I don't know... The bigger the better. If we drop POP_PREFIX we
could allow for 2 bytes version and 6 bytes nonce. Or 1 byte version and 7
bytes nonce.
> POP_PAYLOAD (32+ bytes): The contents of which is determined by POP_TYPE,
e.g. a txid or possibly extra nonce data. Or perhaps some text that makes
the purpose or context of this PoP human-readable? (This could then be
stored by wallets in order to show a list of what kind of proofs you've
sent.)
>
For now I think I'll stick to "txid is mandatory".
>
> 3. I noticed that your post-OP_RETURN structure included exactly 40
bytes. Is that due to the 40-byte limitation on OP_RETURN's "data"? Are you
aware that it will be increased to 80 bytes? Cf. https://
<https://github.com/bitcoin/bitcoin/pull/5286>github.com
<https://github.com/bitcoin/bitcoin/pull/5286>/
<https://github.com/bitcoin/bitcoin/pull/5286>bitcoin
<https://github.com/bitcoin/bitcoin/pull/5286>/
<https://github.com/bitcoin/bitcoin/pull/5286>bitcoin
<https://github.com/bitcoin/bitcoin/pull/5286>/pull/5286
<https://github.com/bitcoin/bitcoin/pull/5286>
>
Yes, I deliberately limited the data to 40 bytes for that reason. With
versioning, this may change in the future.
> :)
>
>
> Vennlig hilsen
> Martin Lie
--001a1137610c74a2810514653e53
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Hi Martin,</p>
<p dir=3D"ltr">Thank you very much for your comments. See my answers inline=
:</p>
<p dir=3D"ltr">Den 23 apr 2015 03:28 skrev "Martin Lie" <<a hr=
ef=3D"mailto:martin@datamagi.no">martin@datamagi.no</a>>:<br>
><br>
> Hej, Kalle.<br>
><br>
> I love the idea of standardised PoPs, including a protocol for request=
ing/sending them as an extension of BIP-70.<br>
></p>
<p dir=3D"ltr">Me too! </p>
<p dir=3D"ltr">><br>
> A couple of comments:<br>
><br>
> 1. You admit that the txid is just a convenience and not strictly nece=
ssary. Perhaps this should be reflected in the sequence of bits/bytes in th=
e record you're proposing, e.g. "OP_RETURN POP_LITERAL <nonce&g=
t; <txid>"?<br>
></p>
<p dir=3D"ltr">I was thinking that txid should be mandatory just as the non=
ce so the order was arbitrarily chosen. I think you may be right that it=
9;s more intuitive to put txid last if it's not mandatory in a future v=
ersion. It makes sense to swap order. I'll put that on my todo list. </=
p>
<p dir=3D"ltr">> 2. Building on #1, perhaps there could be other identif=
ying information than a txid? Perhaps a txid field shouldn't be "h=
ardcoded" into the standard at all?<br>
><br>
> How about taking the same approach as BIP-43 (and others) and use a pr=
efix that determines how the rest of the records should be interpreted, i.e=
. a "type" (or "purpose" or "version" or what=
ever you'd like to call it) field. This would allow for different purpo=
ses/versions of a PoP, including as of now unforeseen ones.<br>
><br>
> The new structure would then be:<br>
> OP_RETURN POP_PREFIX POP_TYPE POP_NONCE POP_PAYLOAD<br>
><br>
> POP_PREFIX (? bytes): I'll leave it up to you to specify the exact=
bits (and length) of the POP_PREFIX, but if your literal is used, it'd=
be 3 bytes: 0x506f50.<br>
><br>
> Literals in Bitcoin protocols generally seem to be of the "binary=
" sort as opposed to human-readable text, so perhaps the devs wouldn&#=
39;t ACK something as "wasteful" as using 3 bytes just to identif=
y it as a PoP record? Obviously, this is a small detail that can be changed=
at short notice, but as with all standards - once people start using it, y=
ou're mostly stuck with what you have. ;)<br>
></p>
<p dir=3D"ltr">Yes, maybe we could drop POP_PREFIX altogether. The server i=
s expecting a pop and can therefore just assume it's a pop. No need to =
explicitly write that inside the pop. Can you think of a scenario where it =
is actually needed. Keeping the POP_PREFIX makes sense only if other transa=
ction-like data structures with OP_RETURN appears in the same contexts as p=
ops. What do you think? </p>
<p dir=3D"ltr">> POP_TYPE: (1 byte): 0x01 for your "standard" =
version, which would mean that the payload contains a txid.<br>
></p>
<p dir=3D"ltr">This is a good idea. Todo! </p>
<p dir=3D"ltr">> POP_NONCE: (4 bytes): "2^32 re-uses should be enou=
gh for everyone", no? ;)<br>
></p>
<p dir=3D"ltr">Euhm, well, I don't know... The bigger the better. If we=
drop POP_PREFIX we could allow for 2 bytes version and 6 bytes nonce. Or 1=
byte version and 7 bytes nonce. </p>
<p dir=3D"ltr">> POP_PAYLOAD (32+ bytes): The contents of which is deter=
mined by POP_TYPE, e.g. a txid or possibly extra nonce data. Or perhaps som=
e text that makes the purpose or context of this PoP human-readable? (This =
could then be stored by wallets in order to show a list of what kind of pro=
ofs you've sent.)<br>
></p>
<p dir=3D"ltr">For now I think I'll stick to "txid is mandatory&qu=
ot;.</p>
<p dir=3D"ltr">><br>
> 3. I noticed that your post-OP_RETURN structure included exactly 40 by=
tes. Is that due to the 40-byte limitation on OP_RETURN's "data&qu=
ot;? Are you aware that it will be increased to 80 bytes? Cf.<a href=3D"htt=
ps://github.com/bitcoin/bitcoin/pull/5286"> https://</a><a href=3D"https://=
github.com/bitcoin/bitcoin/pull/5286">github.com</a><a href=3D"https://gith=
ub.com/bitcoin/bitcoin/pull/5286">/</a><a href=3D"https://github.com/bitcoi=
n/bitcoin/pull/5286">bitcoin</a><a href=3D"https://github.com/bitcoin/bitco=
in/pull/5286">/</a><a href=3D"https://github.com/bitcoin/bitcoin/pull/5286"=
>bitcoin</a><a href=3D"https://github.com/bitcoin/bitcoin/pull/5286">/pull/=
5286</a><br>
></p>
<p dir=3D"ltr">Yes, I deliberately limited the data to 40 bytes for that re=
ason. With versioning, this may change in the future. </p>
<p dir=3D"ltr">> :)<br>
><br>
><br>
> Vennlig hilsen<br>
> Martin Lie<br>
</p>
--001a1137610c74a2810514653e53--
|
