path: root/cb/e1b119d40b5b496e58cdd06c9ebf161f8e64b9

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 <pieter.wuille@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <CAPswA9w5Sgg6AV=9Pqx5sqbkdrwv9LmwoxmMu7xZsQSNXtmZnQ@mail.gmail.com>
References: <CAPswA9w5Sgg6AV=9Pqx5sqbkdrwv9LmwoxmMu7xZsQSNXtmZnQ@mail.gmail.com>
Date: Sat, 6 Jun 2015 16:47:05 +0200
Message-ID: <CAPg+sBjtovFpLoibpVGLsNJXexBcoiYzjrvctraXntCUZBJsGg@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Kalle Rosenbaum <kalle@rosenbaum.se>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <kalle@rosenbaum.se> 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
>
> <pre>
>   BIP: <BIP number>
>   Title: Proof of Payment
>   Author: Kalle Rosenbaum <kalle@rosenbaum.se>
>   Status: Draft
>   Type: Standards Track
>   Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
> </pre>
>
> =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 <version> <txid> <nonce>
>
> {|
> ! Field        !! Size [B] !! Description
> |-
> | &lt;version> || 2        || Version, little endian, currently 0x01 0x00
> |-
> | &lt;txid>    || 32       || The transaction to prove
> |-
> | &lt;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.
>
> <pre>
>   T
>  +----------------------------------------------+
>  |inputs       | outputs                        |
>  |       Value | Value   Script                 |
>  +----------------------------------------------+
>  |input0 1     |     0   pay to A               |
>  |input1 3     |     2   OP_RETURN <some data>  |
>  |input2 4     |     1   pay to B               |
>  |             |     4   pay to C               |
>  +----------------------------------------------+
>
>   PoP(T)
>  +----------------------------------------------------------+
>  |inputs       | outputs                                    |
>  |       Value | Value   Script                             |
>  +----------------------------------------------------------+
>  |input0 1     |     3   OP_RETURN <version> <txid> <nonce> |
>  |input1 3     |     0   pay to A                           |
>  |input2 4     |     1   pay to B                           |
>  |             |     4   pay to C                           |
>  +----------------------------------------------------------+
> </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 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

<div dir=3D"ltr"><div>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.<br><br></div><div>Also, I would call it &quot;pr=
oof of transaction intent&quot;, as it&#39;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.<br></div><div><br=
></div><br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Sat, Jun 6, 2015 at 4:35 PM, Kalle Rosenbaum <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:kalle@rosenbaum.se" target=3D"_blank">kalle@rosenbaum.se</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi<br><=
br>Following earlier posts on Proof of Payment I&#39;m now proposing the fo=
llowing BIP (To read it formatted instead, go to <a href=3D"https://github.=
com/kallerosenbaum/poppoc/wiki/Proof-of-Payment-BIP" target=3D"_blank">http=
s://github.com/kallerosenbaum/poppoc/wiki/Proof-of-Payment-BIP</a>).<br><br=
>Regards,<br>Kalle Rosenbaum<br><br>&lt;pre&gt;<br>=C2=A0 BIP: &lt;BIP numb=
er&gt;<br>=C2=A0 Title: Proof of Payment<br>=C2=A0 Author: Kalle Rosenbaum =
&lt;<a href=3D"mailto:kalle@rosenbaum.se" target=3D"_blank">kalle@rosenbaum=
.se</a>&gt;<br>=C2=A0 Status: Draft<br>=C2=A0 Type: Standards Track<br>=C2=
=A0 Created: &lt;date created on, in ISO 8601 (yyyy-mm-dd) format&gt;<br>&l=
t;/pre&gt;<br><br>=3D=3D Abstract =3D=3D<br><br>This BIP describes how a wa=
llet can prove to a server that it has the ability to sign a certain transa=
ction.<br><br>=3D=3D Motivation =3D=3D<br><br>There are several scenarios i=
n which it would be useful to prove that you have paid for something. For e=
xample:<br><br>* A pre-paid hotel room where your PoP functions as a key to=
 the door.<br>* An online video rental service where you pay for a video an=
d watch it on any device.<br>* 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.<br>* Log in to a pay site using a PoP.<br=
>* A parking lot you pay for monthly and the car authenticates itself using=
 PoP.<br>* 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.<br><br>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.<br><br>=3D=3D Rationale=
 =3D=3D<br><br>Desirable properties:<br><br># A PoP should be generated on =
demand.<br># It should only be usable once to avoid issues due to theft.<br=
># It should be able to create a PoP for any payment, regardless of script =
type (P2SH, P2PKH, etc.).<br># It should prove that you have enough credent=
ials to unlock all the inputs of the proven transaction.<br># It should be =
easy to implement by wallets and servers to ease adoption.<br><br>Current m=
ethods of proving a payment:<br><br>* 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&#39;s no standard way to request/=
provide the proof. If standardized it would probably meet 5.<br>* 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.<br><br>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.<br><br>=3D=3D Specification =3D=3D<br><=
br>=3D=3D=3D Data structure =3D=3D=3D<br><br>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:<br><br>=C2=A0OP_RETURN &lt;version&gt; &lt;txid&gt; &lt;nonce&gt;<br>=
<br>{|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <br>! Field=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 !! Size [B] !! Description<br>|-<br>| &amp;lt;v=
ersion&gt; || 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 || Version, littl=
e endian, currently 0x01 0x00<br>|-<br>| &amp;lt;txid&gt;=C2=A0=C2=A0=C2=A0=
 || 32=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 || The transaction to prove<br>|=
-<br>| &amp;lt;nonce&gt;=C2=A0=C2=A0 || 6=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 || Random data<br>|}<br><br>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.<br><br=
>An illustration of the PoP data structure and its original payment is show=
n below.<br><br>&lt;pre&gt;<br>=C2=A0 T<br>=C2=A0+-------------------------=
---------------------+<br>=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=
 |<br>=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 |<br>=C2=A0+--------------------------------=
--------------+<br>=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 |<br>=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 &lt;some dat=
a&gt;=C2=A0 |<br>=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 |<br>=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 |<br>=C2=A0+-----------------------=
-----------------------+<br>=C2=A0<br>=C2=A0 PoP(T)<br>=C2=A0+-------------=
---------------------------------------------+<br>=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 |<br>=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 |<br>=C2=A0+--------------=
--------------------------------------------+<br>=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 &lt;versi=
on&gt; &lt;txid&gt; &lt;nonce&gt; |<br>=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 |<br>=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 |<br>=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 |<br>=C2=A0+--------------------------------------------------------=
--+<br>&lt;/pre&gt;<br><br>The PoP is signed using the same signing process=
 that is used for bitcoin transactions.<br><br>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.<br><br>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.<br><br>=3D=3D=3D Process =3D=3D=3D<br><br># A proof of payment =
request is sent from the server to the wallet. The PoP request contains:<br=
>## a random nonce<br>## a destination where to send the PoP, for example a=
 https URL<br>## data hinting the wallet which transaction to create a proo=
f for. For example:<br>##* txid, if known by the server<br>##* PaymentReque=
st.PaymentDetails.merchant_data (in case of a BIP0070 payment)<br>##* amoun=
t, label, message or other information from a BIP0021 URL<br># 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.<br># The wallet creates an =
unsigned PoP (UPoP) for T, and asks the user to sign it.<br># The user conf=
irms<br># The UPoP(T) is signed by the wallet, creating PoP(T).<br># The Po=
P is sent to the destination in 1.ii.<br># The server receiving the PoP val=
idates it and responds with =E2=80=9Cvalid=E2=80=9D or =E2=80=9Cinvalid=E2=
=80=9D.<br># The wallet displays the response in some way to the user.<br><=
br>&#39;&#39;&#39;Remarks:&#39;&#39;&#39;<br><br>* 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.<br><br>=3D=3D=3D Validating a PoP =3D=3D=3D<br><br>The server needs=
 to validate the PoP and reply with &quot;valid&quot; or &quot;invalid&quot=
;. That process is outlined below. If any step fails, the validation is abo=
rted and &quot;invalid&quot; is returned:<br><br># Check the format of the =
PoP. It must pass normal transaction checks, except that the inputs may alr=
eady be spent.<br># Check the PoP output at index 0. It must conform to the=
 OP_RETURN output format outlined above.<br># 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.<br># Check that the nonce is the same=
 as the one you requested.<br># Check that the inputs of the PoP are exactl=
y the same as in transaction T, and in the same order.<br># Check the scrip=
ts of all the inputs, as would be done on a normal transaction.<br># 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.<br># Return &quot;valid&quot;.<br><br>=3D=3D Security considerations =
=3D=3D<br><br>* Someone can intercept the PoP-request and change the PoP de=
stination so that the user sends the PoP to the bad actor.<br>* 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.<br>* 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.<br>* 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.<b=
r>* 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.<br=
><br>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.<br><br>=3D=3D Reference implementation =3D=3D<br><br>[<a href=3D"http=
s://github.com/kallerosenbaum/poppoc" target=3D"_blank">https://github.com/=
kallerosenbaum/poppoc</a> poppoc on GitHub]<br><br>[<a href=3D"https://gith=
ub.com/kallerosenbaum/wallet" target=3D"_blank">https://github.com/kalleros=
enbaum/wallet</a> Mycelium fork on GitHub]<br><br>=3D=3D References =3D=3D<=
br><br>[<a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0021.med=
iawiki" target=3D"_blank">https://github.com/bitcoin/bips/blob/master/bip-0=
021.mediawiki</a> BIP0021]: URI Scheme<br><br>[<a href=3D"https://github.co=
m/bitcoin/bips/blob/master/bip-0070.mediawiki" target=3D"_blank">https://gi=
thub.com/bitcoin/bips/blob/master/bip-0070.mediawiki</a> BIP0070]: Payment =
Protocol<br><br>[[btcpop scheme BIP]]<br><br></div>
<br>-----------------------------------------------------------------------=
-------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>

--047d7bd7678881bbe50517da7b32--