Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z4pjg-00087H-EE for bitcoin-development@lists.sourceforge.net; Tue, 16 Jun 2015 12:13:00 +0000 X-ACL-Warn: Received: from mail-qk0-f176.google.com ([209.85.220.176]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z4pjb-0002IU-BD for bitcoin-development@lists.sourceforge.net; Tue, 16 Jun 2015 12:13:00 +0000 Received: by qkdm188 with SMTP id m188so7458122qkd.1 for ; Tue, 16 Jun 2015 05:12:49 -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:cc:content-type :content-transfer-encoding; bh=UAgXxfMQoLZbOxsLxtTlWltV9gKs9U+u+xNulljakA8=; b=Iyi12xqYS2V+46S1hYutQSJG52fy4+hQbsEp/pTq+Lbz/pW8VvK5cyL7YUwKeJl20g KqztUbkRENILgr6RT9shcfNaalvGkTLtMfLmWRm9rn7kjUkyEyB7s0ZU3uMK/9RYkesR 1bkb8jHkvDrkFsGPI0pNmz9Uf9H+oKBJh4Vo636Vazj9QPt//5bItC5fIHH9x8VK54Mw 6ojHx7URi0QWtbIY5BBYILhBwTIsWCc7Qyfda/9QK2v3qg75YCoyQVmiDXkppZnruaXI R6Hb9Bhv/1hx33ciR/hWvzZJu3RvCvfrphdNUhD8crJrHk/5Xnl4a9PX+SCIUbPh9O0b xNKg== X-Gm-Message-State: ALoCoQmMzohWij1M/MFrBajROsO79CYUPiQt10vNHXU6f2uUbnLeQ0T6FZFcv/A5F2UYi/jMRMRT MIME-Version: 1.0 X-Received: by 10.55.18.155 with SMTP id 27mr201041qks.36.1434456769704; Tue, 16 Jun 2015 05:12:49 -0700 (PDT) Received: by 10.96.145.9 with HTTP; Tue, 16 Jun 2015 05:12:49 -0700 (PDT) In-Reply-To: <557FB36B.1030902@thinlink.com> References: <557FB36B.1030902@thinlink.com> Date: Tue, 16 Jun 2015 14:12:49 +0200 Message-ID: From: Kalle Rosenbaum To: Tom Harding Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 T_FILL_THIS_FORM_SHORT Fill in a short form with personal information X-Headers-End: 1Z4pjb-0002IU-BD Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] BIP for 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: Tue, 16 Jun 2015 12:13:00 -0000 2015-06-16 7:26 GMT+02:00 Tom Harding : > > Kalle goes to some trouble to describe how merchants need to ensure that > they only accept a PoP provided as a response to their challenge. > Do you mean that it will be hard to explain to merchants that they must check the nonce in the PoP so that it matches the nonce in the pop request? I think not, this is a commonly used pattern that anyone should be able to grasp. Anyway, merchants will probably use a library (though yet non-existing) for PoP, that will hide the gory details. I also think that payment providers may want to add PoP to their offering to customers (merchants). Regards, /Kalle > > > On 6/15/2015 3:00 AM, Pieter Wuille wrote: > > I did misunderstand that. That changes things significantly. > > However, having paid is not the same as having had access to the input > coins. What about shared wallets or coinjoin? > > Also, if I understand correctly, there is no commitment to anything you'r= e > trying to say about the sender? So once I obtain a proof-of-payment from = you > about something you paid, I can go claim that it's mine? > > Why does anyone care who paid? This is like walking into a coffeshop, > noticing I don't have money with me, let me friend pay for me, and then h= ave > the shop insist that I can't drink it because I'm not the buyer. > > Track payments, don't try to assign identities to payers. > > On Jun 15, 2015 11:35 AM, "Kalle Rosenbaum" wrote: >> >> Hi Pieter! >> >> It is intended to be a proof that you *have paid* for something. Not >> that you have the intent to pay for something. You cannot use PoP >> without a transaction to prove. >> >> So, yes, it's just a proof of access to certain coins that you no longer >> have. >> >> Maybe I don't understand you correctly? >> >> /Kalle >> >> 2015-06-15 11:27 GMT+02:00 Pieter Wuille : >> > Now that you have removed the outputs, I don't think it's even a inten= t >> > of >> > payment, but just a proof of access to certain coins. >> > >> > On Jun 15, 2015 11:24 AM, "Kalle Rosenbaum" wrote= : >> >> >> >> Hi all! >> >> >> >> I have made the discussed changes and updated my implementation >> >> (https://github.com/kallerosenbaum/poppoc) accordingly. These are the >> >> changes: >> >> >> >> * There is now only one output, the "pop output", of value 0. >> >> * The sequence number of all inputs of the PoP must be set to 0. I >> >> chose to set it to 0 for all inputs for simplicity. >> >> * The lock_time of the PoP must be set to 499999999 (max block height >> >> lock >> >> time). >> >> >> >> The comments so far has been mainly positive or neutral. Are there an= y >> >> major objections against any of the two proposals? If not, I will ask >> >> Gregory Maxwell to assign them BIP numbers. >> >> >> >> The two BIP proposals can be found at >> >> https://github.com/kallerosenbaum/poppoc/wiki/Proof-of-Payment-BIP an= d >> >> https://github.com/kallerosenbaum/poppoc/wiki/btcpop-scheme-BIP. The >> >> source >> >> for the Proof of Payment BIP proposal is also in-lined below. >> >> >> >> A number of alternative names have been proposed: >> >> >> >> * Proof of Potential >> >> * Proof of Control >> >> * Proof of Signature >> >> * Signatory Proof >> >> * Popo: Proof of payment origin >> >> * Pots: Proof of transaction signer >> >> * proof of transaction intent >> >> * Declaration of intent >> >> * Asset-access-and-action-affirmation, AAaAA, or A5 >> >> * VeriBit >> >> * CertiBTC >> >> * VBit >> >> * PayID >> >> >> >> Given this list, I still think "Proof of Payment" is the most >> >> descriptive >> >> to non-technical people. >> >> >> >> Regards, >> >> Kalle >> >> >> >> >> >> ################################################# >> >> 
>> >>   BIP: 
>> >>   Title: Proof of Payment
>> >>   Author: Kalle Rosenbaum 
>> >>   Status: Draft
>> >>   Type: Standards Track
>> >>   Created: 
>> >>
>> >> >> >> =3D=3D Abstract =3D=3D >> >> >> >> This BIP describes how a wallet can prove to a server that it has the >> >> ability to sign a certain transaction. >> >> >> >> =3D=3D Motivation =3D=3D >> >> >> >> There are several scenarios in which it would be useful to prove that >> >> you >> >> have paid for something. For example: >> >> >> >> * A pre-paid hotel room where your PoP functions as a key to the door= . >> >> * An online video rental service where you pay for a video and watch = it >> >> on >> >> any device. >> >> * An ad-sign where you pay in advance for e.g. 2 weeks exclusivity. >> >> During >> >> this period you can upload new content to the sign whenever you like >> >> using >> >> PoP. >> >> * Log in to a pay site using a PoP. >> >> * A parking lot you pay for monthly and the car authenticates itself >> >> using >> >> PoP. >> >> * A lottery where all participants pay to the same address, and the >> >> winner >> >> is selected among the transactions to that address. You exchange the >> >> prize >> >> for a PoP for the winning transaction. >> >> >> >> With Proof of Payment, these use cases can be achieved without any >> >> personal information (user name, password, e-mail address, etc) being >> >> involved. >> >> >> >> =3D=3D Rationale =3D=3D >> >> >> >> Desirable properties: >> >> >> >> # A PoP should be generated on demand. >> >> # It should only be usable once to avoid issues due to theft. >> >> # It should be able to create a PoP for any payment, regardless of >> >> script >> >> type (P2SH, P2PKH, etc.). >> >> # It should prove that you have enough credentials to unlock all the >> >> inputs of the proven transaction. >> >> # It should be easy to implement by wallets and servers to ease >> >> adoption. >> >> >> >> Current methods of proving a payment: >> >> >> >> * In BIP0070, the PaymentRequest together with the transactions >> >> fulfilling >> >> the request makes some sort of proof. However, it does not meet 1, 2 = or >> >> 4 >> >> and it obviously only meets 3 if the payment is made through BIP0070. >> >> Also, >> >> there's no standard way to request/provide the proof. If standardized >> >> it >> >> would probably meet 5. >> >> * Signing messages, chosen by the server, with the private keys used = to >> >> sign the transaction. This could meet 1 and 2 but probably not 3. Thi= s >> >> is >> >> not standardized either. 4 Could be met if designed so. >> >> >> >> If an input script type is P2SH, any satisfying script should do, jus= t >> >> as >> >> if it was a payment. For M-of-N multisig scripts, that would mean tha= t >> >> any >> >> set of M keys should be sufficient, not neccesarily the same set of M >> >> keys >> >> that signed the transaction. This is important because strictly >> >> demanding >> >> the same set of M keys would defeat the purpose of a multisig address= . >> >> >> >> =3D=3D Specification =3D=3D >> >> >> >> =3D=3D=3D Data structure =3D=3D=3D >> >> >> >> A proof of payment for a transaction T, here called PoP(T), is used t= o >> >> prove that one has ownership of the credentials needed to unlock all >> >> the >> >> inputs of T. It has the exact same structure as a bitcoin transaction >> >> with >> >> the same inputs as T and in the same order as in T, but with each >> >> sequence >> >> number set to 0. There is exactly one output, here called the pop >> >> output, >> >> with value 0. The pop output must have the following format: >> >> >> >> OP_RETURN >> >> >> >> {| >> >> ! Field !! Size [B] !! Description >> >> |- >> >> | <version> || 2 || Version, little endian, currently 0x01 >> >> 0x00 >> >> |- >> >> | <txid> || 32 || The transaction to prove >> >> |- >> >> | <nonce> || 6 || Random data >> >> |} >> >> >> >> The lock_time of the PoP must be set to 499999999 to prevent the PoP >> >> from >> >> being included in a block, should it appear on the bitcoin p2p networ= k. >> >> This >> >> is also the reason for setting the sequence numbers to 0, since >> >> sequence >> >> number of ffffffff would make lock_time ineffective. This specificati= on >> >> demands that all input sequence numbers are 0, not just one of them, >> >> which >> >> would be sufficient to make lock_time effective. This is for simplici= ty >> >> reasons. >> >> >> >> An illustration of the PoP data structure and its original payment is >> >> shown below. >> >> >> >> 
>> >>   T
>> >>  +------------------------------------------------+
>> >>  |inputs                | outputs                 |
>> >>  |       Value,Sequence | Value,Script            |
>> >>  +------------------------------------------------+
>> >>  |input0 1,ffffffff     | 0,pay to A              |
>> >>  |input1 3,ffffffff     | 2,OP_RETURN  |
>> >>  |input2 4,ffffffff     | 1,pay to B              |
>> >>  |                      | 4,pay to C              |
>> >>  +------------------------------------------------+
>> >>
>> >>   PoP(T)
>> >>  +-------------------------------------------------------------+
>> >>  | inputs               | outputs                              |
>> >>  |       Value,Sequence | Value,Script                         |
>> >>  +-------------------------------------------------------------+
>> >>  |input0 1,00000000     | 0,OP_RETURN    |
>> >>  |input1 3,00000000     |                                      |
>> >>  |input2 4,00000000     |                                      |
>> >>  +-------------------------------------------------------------+
>> >>  | lock_time=3D499999999                                         |
>> >>  +-------------------------------------------------------------+
>> >>
>> >> >> >> The PoP is signed using the same signing process that is used for >> >> bitcoin >> >> transactions. >> >> >> >> The purpose of the nonce is to make it harder to use a stolen PoP; On= ce >> >> the PoP has reached the server, that PoP is useless since the server >> >> will >> >> generate a new nonce for every PoP request. >> >> >> >> =3D=3D=3D Process =3D=3D=3D >> >> >> >> # A proof of payment request is sent from the server to the wallet. T= he >> >> PoP request contains: >> >> ## a random nonce >> >> ## a destination where to send the PoP, for example a https URL >> >> ## data hinting the wallet which transaction to create a proof for. F= or >> >> example: >> >> ##* txid, if known by the server >> >> ##* PaymentRequest.PaymentDetails.merchant_data (in case of a BIP0070 >> >> payment) >> >> ##* amount, label, message or other information from a BIP0021 URI >> >> # The wallet identifies a transaction T, if possible. Otherwise it as= ks >> >> the user to select among the ones that match the hints in 1.iii. >> >> # The wallet creates an unsigned PoP (UPoP) for T, and asks the user = to >> >> sign it. >> >> # The user confirms >> >> # The UPoP(T) is signed by the wallet, creating PoP(T). >> >> # The PoP is sent to the destination in 1.ii. >> >> # The server receiving the PoP validates it and responds with =E2=80= =9Cvalid=E2=80=9D >> >> or >> >> =E2=80=9Cinvalid=E2=80=9D. >> >> # The wallet displays the response in some way to the user. >> >> >> >> '''Remarks:''' >> >> >> >> * The method of transferring the PoP request at step 1 is not specifi= ed >> >> here. Instead that is specified in separate specifications. See [btcp= op >> >> scheme BIP](btcpop scheme BIP). >> >> * The nonce must be randomly generated by the server for every new Po= P >> >> request. >> >> >> >> =3D=3D=3D Validating a PoP =3D=3D=3D >> >> >> >> The server needs to validate the PoP and reply with "valid" or >> >> "invalid". >> >> That process is outlined below. If any step fails, the validation is >> >> aborted >> >> and "invalid" is returned: >> >> >> >> # Check the format of the PoP. It must pass normal transaction checks= , >> >> except that the inputs may already be spent. >> >> # Check that lock_time is 499999999. >> >> # Check that there is exactly one output. This output must have value= 0 >> >> and conform to the OP_RETURN output format outlined above. >> >> # Check that the nonce is the same as the one requested. >> >> # Check that the inputs of the PoP are exactly the same as in >> >> transaction >> >> T, except that the sequence numbers must all be 0. The ordering of th= e >> >> inputs must also be the same as in T. >> >> # Run the scripts of all the inputs. All scipts must return true. >> >> # Check that the txid in the PoP output is the transaction you actual= ly >> >> want proof for. If you don=E2=80=99t know exactly what transaction yo= u want >> >> proof >> >> for, check that the transaction actually pays for the product/service >> >> you >> >> deliver. >> >> # Return "valid". >> >> >> >> =3D=3D Security considerations =3D=3D >> >> >> >> * Someone can intercept the PoP-request and change any parameter in i= t. >> >> These can be mitigated by using secure connections. For example: >> >> ** Pop destination - Stealing your PoP. >> >> ** label - Trick you to sign an unintended pop or set a label that yo= ur >> >> wallet doesn't have any record for, resulting in a broken service. >> >> Always >> >> check the PoP before signing. >> >> ** nonce - Your pop will not validate on server. >> >> * Someone can steal a PoP, for example by tampering with the PoP >> >> request, >> >> and try to use the service hoping to get a matching nonce. Probabilit= y >> >> per >> >> try: 1/(2^48). The server should have a mechanism for detecting a bru= te >> >> force attack of this kind, or at least slow down the process by >> >> delaying the >> >> PoP request by some 100 ms or so. >> >> * Even if a wallet has no funds it might still be valuable as a >> >> generator >> >> for PoPs. This makes it important to keep the security of the wallet >> >> after >> >> it has been emptied. >> >> * Transaction malleability may cause the server to have another >> >> transaction id for a payment than the client's wallet. In that case t= he >> >> wallet will not be able to prove the transaction to the server. Walle= ts >> >> should not rely on the transaction id of the outgoing transaction. >> >> Instead >> >> it should listen for the transaction on the network and put that in i= ts >> >> list >> >> of transactions. >> >> >> >> =3D=3D Reference implementation =3D=3D >> >> >> >> [https://github.com/kallerosenbaum/poppoc poppoc on GitHub] >> >> >> >> [https://github.com/kallerosenbaum/wallet Mycelium fork on GitHub] >> >> >> >> =3D=3D References =3D=3D >> >> >> >> [https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki >> >> BIP0021]: >> >> URI Scheme >> >> >> >> [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki >> >> BIP0070]: >> >> Payment Protocol >> >> >> >> [[btcpop scheme BIP]] >> >> >> >> ######################################################### >> >> >> >> 2015-06-06 23:25 GMT+02:00 Kalle Rosenbaum : >> >> > Thank you all for the feedback. >> >> > >> >> > I will change the data structure as follows: >> >> > >> >> > * There will be only one output, the "pop output", and no outputs >> >> > from >> >> > T will be copied to the PoP. >> >> > * The pop output will have value 0. >> >> > * The sequence number of all inputs of the PoP will be set to 0. I >> >> > chose to set it to 0 for all inputs for simplicity. >> >> > * The lock_time of the PoP is always set to 499999999. >> >> > >> >> > Any comments on this? >> >> > >> >> > /Kalle >> >> > >> >> > 2015-06-06 19:00 GMT+02:00 Kalle Rosenbaum : >> >> >> 2015-06-06 18:10 GMT+02:00 Tom Harding : >> >> >>> On Jun 6, 2015 8:05 AM, "Kalle Rosenbaum" >> >> >>> wrote: >> >> >>> >> >> >>>> I'm open to changes here. >> >> >>> >> >> >>> I suggest: >> >> >>> >> >> >>> - Don't include any real outputs. They are redundant because th= e >> >> >>> txid is >> >> >>> already referenced. >> >> >> >> >> >> with the nLocktime solution, the copied outputs are not needed. >> >> >> >> >> >>> >> >> >>> - Start the proof script, which should be invalid, with a magic >> >> >>> constant and >> >> >>> include space for future expansion. This makes PoP's easy to >> >> >>> identify >> >> >>> and >> >> >>> extend. >> >> >> >> >> >> I did remore the constant (a "PoP" literal ascii encoded string) >> >> >> because it didn't add much. The recipient will expect a pop, so it >> >> >> will simply treat it as one. I did add a 2 byte version field to >> >> >> make >> >> >> it extendable. >> >> >> >> >> >>> >> >> >>> - "Proof of Potential" >> >> >> >> >> >> Noted :-) >> >> >> >> >> >> Thank you >> >> >> /Kalle >> >> >> >> >> >> >> >> ---------------------------------------------------------------------= --------- >> >> >> >> _______________________________________________ >> >> Bitcoin-development mailing list >> >> Bitcoin-development@lists.sourceforge.net >> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> >> > > > > > -------------------------------------------------------------------------= ----- > > > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > -------------------------------------------------------------------------= ----- > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >