MIME-Version: 1.0
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
Subject: Re: [Bitcoin-development] Proof of Payment
Precedence: list

--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 &quot;Martin Lie&quot; &lt;<a hr=
ef=3D"mailto:martin@datamagi.no">martin@datamagi.no</a>&gt;:<br>
&gt;<br>
&gt; Hej, Kalle.<br>
&gt;<br>
&gt; I love the idea of standardised PoPs, including a protocol for request=
ing/sending them as an extension of BIP-70.<br>
&gt;</p>
<p dir=3D"ltr">Me too! </p>
<p dir=3D"ltr">&gt;<br>
&gt; A couple of comments:<br>
&gt;<br>
&gt; 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&#39;re proposing, e.g. &quot;OP_RETURN POP_LITERAL &lt;nonce&g=
t; &lt;txid&gt;&quot;?<br>
&gt;</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&#3=
9;s more intuitive to put txid last if it&#39;s not mandatory in a future v=
ersion. It makes sense to swap order. I&#39;ll put that on my todo list. </=
p>
<p dir=3D"ltr">&gt; 2. Building on #1, perhaps there could be other identif=
ying information than a txid? Perhaps a txid field shouldn&#39;t be &quot;h=
ardcoded&quot; into the standard at all?<br>
&gt;<br>
&gt; 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 &quot;type&quot; (or &quot;purpose&quot; or &quot;version&quot; or what=
ever you&#39;d like to call it) field. This would allow for different purpo=
ses/versions of a PoP, including as of now unforeseen ones.<br>
&gt;<br>
&gt; The new structure would then be:<br>
&gt; OP_RETURN POP_PREFIX POP_TYPE POP_NONCE POP_PAYLOAD<br>
&gt;<br>
&gt; POP_PREFIX (? bytes): I&#39;ll leave it up to you to specify the exact=
 bits (and length) of the POP_PREFIX, but if your literal is used, it&#39;d=
 be 3 bytes: 0x506f50.<br>
&gt;<br>
&gt; Literals in Bitcoin protocols generally seem to be of the &quot;binary=
&quot; sort as opposed to human-readable text, so perhaps the devs wouldn&#=
39;t ACK something as &quot;wasteful&quot; 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&#39;re mostly stuck with what you have. ;)<br>
&gt;</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&#39;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">&gt; POP_TYPE: (1 byte): 0x01 for your &quot;standard&quot; =
version, which would mean that the payload contains a txid.<br>
&gt;</p>
<p dir=3D"ltr">This is a good idea. Todo! </p>
<p dir=3D"ltr">&gt; POP_NONCE: (4 bytes): &quot;2^32 re-uses should be enou=
gh for everyone&quot;, no? ;)<br>
&gt;</p>
<p dir=3D"ltr">Euhm, well, I don&#39;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">&gt; 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&#39;ve sent.)<br>
&gt;</p>
<p dir=3D"ltr">For now I think I&#39;ll stick to &quot;txid is mandatory&qu=
ot;.</p>
<p dir=3D"ltr">&gt;<br>
&gt; 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&#39;s &quot;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>
&gt;</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">&gt; :)<br>
&gt;<br>
&gt;<br>
&gt; Vennlig hilsen<br>
&gt; Martin Lie<br>
</p>

--001a1137610c74a2810514653e53--