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

--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 &quot;Proof of Payment&quot;), 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&#39;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&#39;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 &quot;PoP&quot; 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--