Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z1FNR-0002F5-KZ for bitcoin-development@lists.sourceforge.net; Sat, 06 Jun 2015 14:47:13 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.182 as permitted sender) client-ip=209.85.214.182; envelope-from=pieter.wuille@gmail.com; helo=mail-ob0-f182.google.com; Received: from mail-ob0-f182.google.com ([209.85.214.182]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z1FNP-0001Jj-EW for bitcoin-development@lists.sourceforge.net; Sat, 06 Jun 2015 14:47:13 +0000 Received: by obbir4 with SMTP id ir4so30216262obb.1 for ; Sat, 06 Jun 2015 07:47:06 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.173.7 with SMTP id bg7mr7409511oec.86.1433602025960; Sat, 06 Jun 2015 07:47:05 -0700 (PDT) Received: by 10.60.94.36 with HTTP; Sat, 6 Jun 2015 07:47:05 -0700 (PDT) In-Reply-To: References: Date: Sat, 6 Jun 2015 16:47:05 +0200 Message-ID: From: Pieter Wuille To: Kalle Rosenbaum Content-Type: multipart/alternative; boundary=047d7bd7678881bbe50517da7b32 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.0 T_FILL_THIS_FORM_SHORT Fill in a short form with personal information -0.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Z1FNP-0001Jj-EW 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: Sat, 06 Jun 2015 14:47:13 -0000 --047d7bd7678881bbe50517da7b32 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable What do you gain by making PoPs actually valid transactions? You could for example change the signature hashing algorithm (prepend a constant string, or add a second hashing step) for signing, rendering the signatures in a PoP unusable for actual transaction, while still committing to the same actual transaction. That would also remove the need for the OP_RETURN to catch fees. Also, I would call it "proof of transaction intent", as it's a commitment to a transaction and proof of its validity, but not a proof that an actual transaction took place, nor a means to prevent it from being double spent. On Sat, Jun 6, 2015 at 4:35 PM, Kalle Rosenbaum wrote: > Hi > > Following earlier posts on Proof of Payment I'm now proposing the > following BIP (To read it formatted instead, go to > https://github.com/kallerosenbaum/poppoc/wiki/Proof-of-Payment-BIP). > > Regards, > Kalle Rosenbaum > > 
>   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 o= n > any device. > * An ad-sign where you pay in advance for e.g. 2 weeks exclusivity. Durin= g > this period you can upload new content to the sign whenever you like usin= g > PoP. > * Log in to a pay site using a PoP. > * A parking lot you pay for monthly and the car authenticates itself usin= g > PoP. > * A lottery where all participants pay to the same address, and the winne= r > is selected among the transactions to that address. You exchange the priz= e > 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 fulfillin= g > 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. Als= o, > 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. This is > not standardized either. 4 Could be met if designed so. > > If the script type is P2SH, any satisfying script should do, just like fo= r > a payment. For M-of-N multisig scripts, that would mean that 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 undermine 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 to > 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 wit= h > the same inputs and outputs as T and in the same order as in T. There is > also one OP_RETURN output inserted at index 0, here called the pop output= . > This 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 value of the pop output is set to the same value as the transaction > fee of T. Also, if the outputs of T contains an OP_RETURN output, that > output must not be included in the PoP because there can only be one > OP_RETURN output in a transaction. The value of that OP_RETURN output is > instead added to the value of the pop output. > > An illustration of the PoP data structure and its original payment is > shown below. > > 
>   T
>  +----------------------------------------------+
>  |inputs       | outputs                        |
>  |       Value | Value   Script                 |
>  +----------------------------------------------+
>  |input0 1     |     0   pay to A               |
>  |input1 3     |     2   OP_RETURN   |
>  |input2 4     |     1   pay to B               |
>  |             |     4   pay to C               |
>  +----------------------------------------------+
>
>   PoP(T)
>  +----------------------------------------------------------+
>  |inputs       | outputs                                    |
>  |       Value | Value   Script                             |
>  +----------------------------------------------------------+
>  |input0 1     |     3   OP_RETURN    |
>  |input1 3     |     0   pay to A                           |
>  |input2 4     |     1   pay to B                           |
>  |             |     4   pay to C                           |
>  +----------------------------------------------------------+
>
> > 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; Once > the PoP has reached the server, that PoP is useless since the server will > generate a new nonce for every PoP request. > > Since a PoP is indistinguishable from a bitcoin transaction, there is a > risk that it, accidently or maliciously, enters the bitcoin p2p network. = If > T is still unconfirmed, or if a reorg takes place, chances are that PoP(T= ) > ends up in a block, invalidating T. Therefore it is important that the > outputs of the PoP are the same as in T. The zero transaction fee in PoP(= T) > is to minimize the incentives for miners to select PoP(T) for inclusion. > > =3D=3D=3D Process =3D=3D=3D > > # A proof of payment request is sent from the server to the wallet. The > 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. For > 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 URL > # The wallet identifies a transaction T, if possible. Otherwise it asks > 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=9Cva= lid=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 specified > here. Instead that is specified in separate specifications. See [btcpop > scheme BIP](btcpop scheme BIP). > * The nonce must be randomly generated by the server for every new PoP > 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 the PoP output at index 0. It must conform to the OP_RETURN outpu= t > format outlined above. > # Check that the rest of the outputs exactly corresponds to the outputs o= f > T and that they appear in the same order as in T. An exception to this is > that any OP_RETURN outputs of T must not be included in the PoP. All outp= ut > value from the OP_RETURN must instead be included in the PoP output. > # Check that the nonce is the same as the one you requested. > # Check that the inputs of the PoP are exactly the same as in transaction > T, and in the same order. > # Check the scripts of all the inputs, as would be done on a normal > transaction. > # Check that the txid in the PoP output is the transaction you actually > want proof for. If you don=E2=80=99t know exactly what transaction you wa= nt 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 the PoP destination so > that the user sends the PoP to the bad actor. > * Someone can intercept the PoP-request and change for example the txid t= o > trick the user to sign a PoP for another transaction than the intended. > This can of course be avoided if the user is actually looking at the UPoP > before signing it. The bad actor could also set hints for a transaction, > existing or not, that the user didn=E2=80=99t make, resulting in a broken= service. > * Someone can steal a PoP and try to use the service hoping to get a > matching nonce. Probability per try: 1/(2^48). The server should have a > mechanism for detecting a brute force attack of this kind, or at least sl= ow > 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 afte= r > it has been emptied. > * Transaction malleability may cause the server to have another > transaction id than the wallet for the payment. In that case the wallet > will not be able to prove the transaction for the server. Wallets 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 its list > of transactions. > > The first two issues are the same attack vector as for traditional, ie > BIP0021, bitcoin payments. They could be mitigated by using secure > connections. > > =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]] > > > > -------------------------------------------------------------------------= ----- > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --047d7bd7678881bbe50517da7b32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What do you gain by making PoPs actually valid transa= ctions? You could for example change the signature hashing algorithm (prepe= nd a constant string, or add a second hashing step) for signing, rendering = the signatures in a PoP unusable for actual transaction, while still commit= ting to the same actual transaction. That would also remove the need for th= e OP_RETURN to catch fees.

Also, I would call it "pr= oof of transaction intent", as it's a commitment to a transaction = and proof of its validity, but not a proof that an actual transaction took = place, nor a means to prevent it from being double spent.


= On Sat, Jun 6, 2015 at 4:35 PM, Kalle Rosenbaum <kalle@rosenbaum.se&g= t; wrote:
Hi
<= br>Following earlier posts on Proof of Payment I'm now proposing the fo= llowing BIP (To read it formatted instead, go to http= s://github.com/kallerosenbaum/poppoc/wiki/Proof-of-Payment-BIP).
Regards,
Kalle Rosenbaum

<pre>
=C2=A0 BIP: <BIP numb= er>
=C2=A0 Title: Proof of Payment
=C2=A0 Author: Kalle Rosenbaum = <kalle@rosenbaum= .se>
=C2=A0 Status: Draft
=C2=A0 Type: Standards Track
=C2= =A0 Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
&l= t;/pre>

=3D=3D Abstract =3D=3D

This BIP describes how a wa= llet can prove to a server that it has the ability to sign a certain transa= ction.

=3D=3D Motivation =3D=3D

There are several scenarios i= n which it would be useful to prove that you have paid for something. For e= xample:

* 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 an= d 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 th= e winner is selected among the transactions to that address. You exchange t= he prize for a PoP for the winning transaction.

With Proof of Paymen= t, these use cases can be achieved without any personal information (user n= ame, 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 credent= ials to unlock all the inputs of the proven transaction.
# It should be = easy to implement by wallets and servers to ease adoption.

Current m= ethods of proving a payment:

* In BIP0070, the PaymentRequest togeth= er with the transactions fulfilling the request makes some sort of proof. H= owever, it does not meet 1, 2 or 4 and it obviously only meets 3 if the pay= ment is made through BIP0070. Also, there's no standard way to request/= provide the proof. If standardized it would probably meet 5.
* Signing m= essages, chosen by the server, with the private keys used to sign the trans= action. This could meet 1 and 2 but probably not 3. This is not standardize= d either. 4 Could be met if designed so.

If the script type is P2SH,= any satisfying script should do, just like for a payment. For M-of-N multi= sig scripts, that would mean that any set of M keys should be sufficient, n= ot neccesarily the same set of M keys that signed the transaction. This is = important because strictly demanding the same set of M keys would undermine= the purpose of a multisig address.

=3D=3D Specification =3D=3D
<= br>=3D=3D=3D Data structure =3D=3D=3D

A proof of payment for a trans= action T, here called PoP(T), is used to prove that one has ownership of th= e credentials needed to unlock all the inputs of T. It has the exact same s= tructure as a bitcoin transaction with the same inputs and outputs as T and= in the same order as in T. There is also one OP_RETURN output inserted at = index 0, here called the pop output. This output must have the following fo= rmat:

=C2=A0OP_RETURN <version> <txid> <nonce>
=
{|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
! Field=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 !! Size [B] !! Description
|-
| &lt;v= ersion> || 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 || Version, littl= e endian, currently 0x01 0x00
|-
| &lt;txid>=C2=A0=C2=A0=C2=A0= || 32=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 || The transaction to prove
|= -
| &lt;nonce>=C2=A0=C2=A0 || 6=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 || Random data
|}

The value of the pop output is set to= the same value as the transaction fee of T. Also, if the outputs of T cont= ains an OP_RETURN output, that output must not be included in the PoP becau= se there can only be one OP_RETURN output in a transaction. The value of th= at OP_RETURN output is instead added to the value of the pop output.
An illustration of the PoP data structure and its original payment is show= n below.

<pre>
=C2=A0 T
=C2=A0+-------------------------= ---------------------+
=C2=A0|inputs=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= | outputs=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |
=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Value | Value=C2=A0=C2=A0= Script=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0+--------------------------------= --------------+
=C2=A0|input0 1=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2= =A0=C2=A0 0=C2=A0=C2=A0 pay to A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0|input1 3=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 2=C2=A0=C2=A0 OP_RETURN <some dat= a>=C2=A0 |
=C2=A0|input2 4=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2= =A0=C2=A0 1=C2=A0=C2=A0 pay to B=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0|=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0= =C2=A0 4=C2=A0=C2=A0 pay to C=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0+-----------------------= -----------------------+
=C2=A0
=C2=A0 PoP(T)
=C2=A0+-------------= ---------------------------------------------+
=C2=A0|inputs=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 | outputs=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 |
=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Valu= e | Value=C2=A0=C2=A0 Script=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0+--------------= --------------------------------------------+
=C2=A0|input0 1=C2=A0=C2= =A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 3=C2=A0=C2=A0 OP_RETURN <versi= on> <txid> <nonce> |
=C2=A0|input1 3=C2=A0=C2=A0=C2=A0=C2= =A0 |=C2=A0=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0 pay to A=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0|in= put2 4=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 1=C2=A0=C2=A0 pay = to B=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |
=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 4=C2=A0=C2=A0 pay to C= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |
=C2=A0+--------------------------------------------------------= --+
</pre>

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; Once the PoP has reached the server,= that PoP is useless since the server will generate a new nonce for every P= oP request.

Since a PoP is indistinguishable from a bitcoin transact= ion, there is a risk that it, accidently or maliciously, enters the bitcoin= p2p network. If T is still unconfirmed, or if a reorg takes place, chances= are that PoP(T) ends up in a block, invalidating T. Therefore it is import= ant that the outputs of the PoP are the same as in T. The zero transaction = fee in PoP(T) is to minimize the incentives for miners to select PoP(T) for= inclusion.

=3D=3D=3D Process =3D=3D=3D

# A proof of payment = request is sent from the server to the wallet. The 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 proo= f for. For example:
##* txid, if known by the server
##* PaymentReque= st.PaymentDetails.merchant_data (in case of a BIP0070 payment)
##* amoun= t, label, message or other information from a BIP0021 URL
# The wallet i= dentifies a transaction T, if possible. Otherwise it asks the user to selec= t 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 conf= irms
# The UPoP(T) is signed by the wallet, creating PoP(T).
# The Po= P is sent to the destination in 1.ii.
# The server receiving the PoP val= idates 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.
<= br>'''Remarks:'''

* The method of transferri= ng the PoP request at step 1 is not specified here. Instead that is specifi= ed in separate specifications. See [btcpop scheme BIP](btcpop scheme BIP).<= br>* The nonce must be randomly generated by the server for every new PoP r= equest.

=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 abo= rted and "invalid" is returned:

# Check the format of the = PoP. It must pass normal transaction checks, except that the inputs may alr= eady be spent.
# Check the PoP output at index 0. It must conform to the= OP_RETURN output format outlined above.
# Check that the rest of the ou= tputs exactly corresponds to the outputs of T and that they appear in the s= ame order as in T. An exception to this is that any OP_RETURN outputs of T = must not be included in the PoP. All output value from the OP_RETURN must i= nstead be included in the PoP output.
# Check that the nonce is the same= as the one you requested.
# Check that the inputs of the PoP are exactl= y the same as in transaction T, and in the same order.
# Check the scrip= ts of all the inputs, as would be done on a normal transaction.
# Check = that the txid in the PoP output is the transaction you actually want proof = for. If you don=E2=80=99t know exactly what transaction you want proof for,= check that the transaction actually pays for the product/service you deliv= er.
# Return "valid".

=3D=3D Security considerations = =3D=3D

* Someone can intercept the PoP-request and change the PoP de= stination so that the user sends the PoP to the bad actor.
* Someone can= intercept the PoP-request and change for example the txid to trick the use= r to sign a PoP for another transaction than the intended. This can of cour= se be avoided if the user is actually looking at the UPoP before signing it= . The bad actor could also set hints for a transaction, existing or not, th= at the user didn=E2=80=99t make, resulting in a broken service.
* Someon= e can steal a PoP and try to use the service hoping to get a matching nonce= . Probability per try: 1/(2^48). The server should have a mechanism for det= ecting a brute 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 ha= s no funds it might still be valuable as a generator for PoPs. This makes i= t important to keep the security of the wallet after it has been emptied.* Transaction malleability may cause the server to have another transacti= on id than the wallet for the payment. In that case the wallet will not be = able to prove the transaction for the server. Wallets should not rely on th= e transaction id of the outgoing transaction. Instead it should listen for = the transaction on the network and put that in its list of transactions.
The first two issues are the same attack vector as for traditional, ie= BIP0021, bitcoin payments. They could be mitigated by using secure connect= ions.

=3D=3D Reference implementation =3D=3D

[https://github.com/= kallerosenbaum/poppoc poppoc on GitHub]

[https://github.com/kalleros= enbaum/wallet Mycelium fork on GitHub]

=3D=3D References =3D=3D<= br>
[https://github.com/bitcoin/bips/blob/master/bip-0= 021.mediawiki BIP0021]: URI Scheme

[https://gi= thub.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP0070]: Payment = Protocol

[[btcpop scheme BIP]]


-----------------------------------------------------------------------= -------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--047d7bd7678881bbe50517da7b32--