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 ) 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 ; 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:

<55384AC9.80501@datamagi.no> Date: Thu, 23 Apr 2015 16:39:15 +0200 Message-ID: From: Kalle Rosenbaum To: Martin Lie , Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" : > > 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 "? > 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:// 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

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 request= ing/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 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>"?
>

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.

> 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?
>
> 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.
>
> 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&#= 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. ;)
>

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?

> 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 enou= gh 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 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.)
>

For now I think I'll stick to "txid is mandatory&qu= ot;.

>
> 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. https://github.com /bitcoin /bitcoin /pull/= 5286
>

Yes, I deliberately limited the data to 40 bytes for that re= ason. With versioning, this may change in the future.

> :)
>
>
> Vennlig hilsen
> Martin Lie

--001a1137610c74a2810514653e53--