[Bitcoin-development] Proof of Payment BIP-able?

[Kalle Rosenbaum <kalle@rosenbaum.se>]

[-- Attachment #1: Type: text/plain, Size: 2247 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2734 bytes --]