From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YwdDS-0006Gx-SI for bitcoin-development@lists.sourceforge.net; Sun, 24 May 2015 21:13:50 +0000 X-ACL-Warn: Received: from mail-qg0-f52.google.com ([209.85.192.52]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YwdDP-0003hV-5e for bitcoin-development@lists.sourceforge.net; Sun, 24 May 2015 21:13:50 +0000 Received: by qgew3 with SMTP id w3so36060783qge.2 for ; Sun, 24 May 2015 14:13:41 -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:date:message-id:subject:from:to :content-type; bh=4b2jmC7GbyRwBKqz7P5eZNDrM3pAj0oJ5t4ImJIl9d8=; b=XnNN5bSCdZ2JFYfVUsm27xvinu/VZtGincL611zpvq0gZq7PSY+x9FlJbSVWmcqrjV Ql5jn0ehtGw+n2sbT0P/FXy4fcWtjHw+j1me/DhmbuZDUX4jH3nIkem2jD5QcaJXdMbE 8zfNCQRrZ+8TZ+/ScLT31rizb4jM/blrnysEXXIzFYIMYPLLq2uLALfqYBjrUWXYf3dd rPqBfvTFh/ZvdVNAX8Ze6rqvd+HkPFH4zTFF0Kf531th/Ceymk2FNpoShkYq3fTmOYrW HpT/6UpJ2s+Bn4lBwsPeAUqK7RaTbMyBwlNugDTIrJTW+4AoOiE0rqirBWoIzJv2aXfn elCQ== X-Gm-Message-State: ALoCoQmVLWyJzRjW2vYzoSSbRLpmGEf+hO/EWBw52Cplnh1fxMA4HR96/JoGyfn6l8T8GO5URWA3 MIME-Version: 1.0 X-Received: by 10.55.16.33 with SMTP id a33mr39025922qkh.51.1432500316808; Sun, 24 May 2015 13:45:16 -0700 (PDT) Received: by 10.96.145.9 with HTTP; Sun, 24 May 2015 13:45:16 -0700 (PDT) Date: Sun, 24 May 2015 22:45:16 +0200 Message-ID: From: Kalle Rosenbaum To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a113acf008648110516d9f866 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: 1YwdDP-0003hV-5e Subject: [Bitcoin-development] Proof of Payment BIP-able? 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: Sun, 24 May 2015 21:13:50 -0000 --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 . 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
Hi all!

As indicated in my first email re= garding 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/btcpo= p-scheme

Basically, my question to the community is: = Do you agree that these are BIP-able?

The proposals are n= ot yet BIP formatted, but pretty complete. An implementation is avaliable a= t https://github.com/k= allerosenbaum/poppoc. Specifically, the PoP validating code is in PopVali= dator.java.

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.
Further on, I'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.
=

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:

* 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).

* 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're interested in.

* A version field= of 2 bytes is included. Currently the only valid version is 0x00 0x01. (Th= anks Martin Lie)

* The "PoP" 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.)

Regards,
Kalle Rosenbaum
--001a113acf008648110516d9f866--