summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorKalle Rosenbaum <kalle@rosenbaum.se>2015-06-15 11:21:06 +0200
committerbitcoindev <bitcoindev@gnusha.org>2015-06-15 09:21:14 +0000
commitd9fabb3ef5457752f1676e2f6a9c46f0af08cd63 (patch)
tree4010ebf9aadc43f1936389f2d76a7242a948d37f
parent7db1b7761c5fd5b2a4fae792796f2c8c392ac6f9 (diff)
downloadpi-bitcoindev-d9fabb3ef5457752f1676e2f6a9c46f0af08cd63.tar.gz
pi-bitcoindev-d9fabb3ef5457752f1676e2f6a9c46f0af08cd63.zip
Re: [Bitcoin-development] BIP for Proof of Payment
-rw-r--r--06/257492247f743769ee0aa673e2bf3e9e51816d619
1 files changed, 619 insertions, 0 deletions
diff --git a/06/257492247f743769ee0aa673e2bf3e9e51816d b/06/257492247f743769ee0aa673e2bf3e9e51816d
new file mode 100644
index 000000000..991fef253
--- /dev/null
+++ b/06/257492247f743769ee0aa673e2bf3e9e51816d
@@ -0,0 +1,619 @@
+Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
+ helo=mx.sourceforge.net)
+ by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
+ (envelope-from <kalle@rosenbaum.se>) id 1Z4QZu-0000Yb-MK
+ for bitcoin-development@lists.sourceforge.net;
+ Mon, 15 Jun 2015 09:21:14 +0000
+X-ACL-Warn:
+Received: from mail-qk0-f178.google.com ([209.85.220.178])
+ by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
+ (Exim 4.76) id 1Z4QZs-0003Cn-3i
+ for bitcoin-development@lists.sourceforge.net;
+ Mon, 15 Jun 2015 09:21:14 +0000
+Received: by qkdm188 with SMTP id m188so29380401qkd.1
+ for <bitcoin-development@lists.sourceforge.net>;
+ Mon, 15 Jun 2015 02:21:06 -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:content-type;
+ bh=//yCnDWS4yHf5IGjbc95HbxbxrdXd4mbffmp2q2gGEQ=;
+ b=ddvW1c+QRzPtrHcZeu2F64zpPWhsbjSysWIO/GkGfvYF9N+o7v9XZaDPW1FQzDtH0D
+ 3b2lxWzjiUKkM0C9c5LggmML2gRt0vSgXb0e5mFNSp7HaOq5WNCMLxN42RAlK4NbU4+E
+ IoyHSCDm1T2wqtd8IHU/wJshkuVM/gEc7L7Oce92zlWeCqdFgaRadOb3POnTRS8ILyxa
+ NZ5hOw/Q/DTkjBZkuHGqL85kGdgnPR6Qj34xoBXIK5dcV97jyT2WPIAjIMKTkjOrtRdL
+ d+yTEiRcQ+fyGS2dekrz6uf2lW/efTkFis0VWVOslbJOw5J24P1/geVZvSxwzybHZZbS
+ kTpw==
+X-Gm-Message-State: ALoCoQlN1zSnOMwiVPEtGr+yxQQjPRLI2uPQdz7TOS/JPUlsSx5HSLHYZlK0Re2SG/unostSr14T
+MIME-Version: 1.0
+X-Received: by 10.55.16.74 with SMTP id a71mr56678155qkh.15.1434360066605;
+ Mon, 15 Jun 2015 02:21:06 -0700 (PDT)
+Received: by 10.96.145.9 with HTTP; Mon, 15 Jun 2015 02:21:06 -0700 (PDT)
+In-Reply-To: <CAPswA9z_xKY6v9=Ejh=01mZN0QCVo1e0RY1FTzXzS39i3tjgAw@mail.gmail.com>
+References: <CAPswA9w5Sgg6AV=9Pqx5sqbkdrwv9LmwoxmMu7xZsQSNXtmZnQ@mail.gmail.com>
+ <CAPg+sBjtovFpLoibpVGLsNJXexBcoiYzjrvctraXntCUZBJsGg@mail.gmail.com>
+ <CAPswA9zhB4GV=JJ28RRLFNrkVwExUv36zujmuAjwPd6rG6rvzQ@mail.gmail.com>
+ <CALJP9GCBJiofY7k2RJ460CuLuWQunHcx7EcLi1-d07v76Y-E2g@mail.gmail.com>
+ <CAPswA9wqdbU0z8ydBt+9M0iQX0VSi1ce=dg3fR2_2bx3-vEqzA@mail.gmail.com>
+ <CAPswA9z_xKY6v9=Ejh=01mZN0QCVo1e0RY1FTzXzS39i3tjgAw@mail.gmail.com>
+Date: Mon, 15 Jun 2015 11:21:06 +0200
+Message-ID: <CAPswA9xk5QYAXxQ6ES3cnNPeB1FTiiSJgLahLEkSk4CLpoM_QQ@mail.gmail.com>
+From: Kalle Rosenbaum <kalle@rosenbaum.se>
+To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
+Content-Type: multipart/alternative; boundary=001a11374472401ab905188afa6b
+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
+ 0.0 T_FILL_THIS_FORM_SHORT Fill in a short form with personal
+ information
+X-Headers-End: 1Z4QZs-0003Cn-3i
+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: Mon, 15 Jun 2015 09:21:14 -0000
+
+--001a11374472401ab905188afa6b
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: quoted-printable
+
+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 any
+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 and
+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
+
+
+#################################################
+<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 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. This is
+not standardized either. 4 Could be met if designed so.
+
+If an input script type is P2SH, any satisfying script should do, just as
+if it was 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 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 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 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 <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 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 network.
+This is also the reason for setting the sequence numbers to 0, since
+sequence number of ffffffff would make lock_time ineffective. This
+specification 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
+simplicity reasons.
+
+An illustration of the PoP data structure and its original payment is shown
+below.
+
+<pre>
+ T
+ +------------------------------------------------+
+ |inputs | outputs |
+ | Value,Sequence | Value,Script |
+ +------------------------------------------------+
+ |input0 1,ffffffff | 0,pay to A |
+ |input1 3,ffffffff | 2,OP_RETURN <some data> |
+ |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 <version> <txid> <nonce> |
+ |input1 3,00000000 | |
+ |input2 4,00000000 | |
+ +-------------------------------------------------------------+
+ | lock_time=3D499999999 |
+ +-------------------------------------------------------------+
+</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.
+
+=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 URI
+# 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=9Cvali=
+d=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 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 the
+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 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
+deliver.
+# Return "valid".
+
+=3D=3D Security considerations =3D=3D
+
+* Someone can intercept the PoP-request and change any parameter in it.
+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 your
+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. Probability per
+try: 1/(2^48). The server should have a mechanism for detecting 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 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 the wallet will not
+be able to prove the transaction to 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=
+.
+
+=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 <kalle@rosenbaum.se>:
+> 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 <kalle@rosenbaum.se>:
+>> 2015-06-06 18:10 GMT+02:00 Tom Harding <tomh@thinlink.com>:
+>>> On Jun 6, 2015 8:05 AM, "Kalle Rosenbaum" <kalle@rosenbaum.se> wrote:
+>>>
+>>>> I'm open to changes here.
+>>>
+>>> I suggest:
+>>>
+>>> - Don't include any real outputs. They are redundant because the 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
+
+--001a11374472401ab905188afa6b
+Content-Type: text/html; charset=UTF-8
+Content-Transfer-Encoding: quoted-printable
+
+<div dir=3D"ltr"><div><div>Hi all!<br><br>I have made the discussed changes=
+ and updated my implementation (<a href=3D"https://github.com/kallerosenbau=
+m/poppoc">https://github.com/kallerosenbaum/poppoc</a>) accordingly. These =
+are the changes:<br><br>* There is now only one output, the &quot;pop outpu=
+t&quot;, of value 0.<br>* The sequence number of all inputs of the PoP must=
+ be set to 0. I<br>chose to set it to 0 for all inputs for simplicity.<br>*=
+ The lock_time of the PoP must be set to 499999999 (max block height lock t=
+ime).<br><br></div>The comments so far has been mainly positive or neutral.=
+ Are there any major objections against any of the two proposals? If not, I=
+ will ask Gregory Maxwell to assign them BIP numbers.<br><div><br><div>The =
+two BIP proposals can be found at <a href=3D"https://github.com/kallerosenb=
+aum/poppoc/wiki/Proof-of-Payment-BIP" target=3D"_blank">https://github.com/=
+kallerosenbaum/poppoc/wiki/<span class=3D"">Proof</span>-of-<span class=3D"=
+">Payment</span>-BIP</a> and <a href=3D"https://github.com/kallerosenbaum/p=
+oppoc/wiki/btcpop-scheme-BIP">https://github.com/kallerosenbaum/poppoc/wiki=
+/btcpop-scheme-BIP</a>. The source for the Proof of Payment BIP proposal is=
+ also in-lined below.<br></div><br></div>A number of alternative names have=
+ been proposed:<br><br></div>* Proof of Potential<br><span class=3D"">* Pro=
+of</span> of Control<br>
+<span class=3D"">* Proof</span> of Signature<br>* Signatory <span class=3D"=
+">Proof</span><br><div class=3D"">
+* Popo: Proof of payment origin<br>* Pots: Proof of transaction signer</div=
+>* <span class=3D"">proof</span> of transaction intent<br>* Declaration of =
+intent<br>* Asset-access-and-action-affirmation, AAaAA, or A5<br>* VeriBit
+<br>* CertiBTC<br>* VBit<br><div><div><div>* PayID<br><br></div><div>Given =
+this list, I still think &quot;Proof of Payment&quot; is the most descripti=
+ve to non-technical people.<br></div><div><br>Regards,<br>Kalle<br><br><br>=
+#################################################<br>&lt;pre&gt;<br>=C2=A0 =
+BIP: &lt;BIP number&gt;<br>=C2=A0 Title: Proof of Payment<br>=C2=A0 Author:=
+ Kalle Rosenbaum &lt;<a href=3D"mailto:kalle@rosenbaum.se">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 an input script type is =
+P2SH, any satisfying script should do, just as if it was a payment. For M-o=
+f-N multisig scripts, that would mean that any set of M keys should be suff=
+icient, 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.<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 transaction T, here called PoP(T), is used to prove that one has ownersh=
+ip of the credentials needed to unlock all the inputs of T. It has the exac=
+t 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 ex=
+actly one output, here called the pop output, with value 0. The pop output =
+must have the following format:<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] !! Descri=
+ption<br>|-<br>| &amp;lt;version&gt; || 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
+=A0=C2=A0 || Version, little 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 || Th=
+e 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 lock_t=
+ime of the PoP must be set to 499999999 to prevent the PoP from being inclu=
+ded in a block, should it appear on the bitcoin p2p network. This is also t=
+he reason for setting the sequence numbers to 0, since sequence number of f=
+fffffff would make lock_time ineffective. This specification demands that a=
+ll input sequence numbers are 0, not just one of them, which would be suffi=
+cient to make lock_time effective. This is for simplicity reasons.<br><br>A=
+n illustration of the PoP data structure and its original payment is shown =
+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=
+=C2=A0=C2=A0=C2=A0=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 |<br>=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Value,Sequenc=
+e | Value,Script=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,ffffffff=C2=A0=C2=A0=C2=A0=C2=A0 | 0,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 |<br>=C2=
+=A0|input1 3,ffffffff=C2=A0=C2=A0=C2=A0=C2=A0 | 2,OP_RETURN &lt;some data&g=
+t; |<br>=C2=A0|input2 4,ffffffff=C2=A0=C2=A0=C2=A0=C2=A0 | 1,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 |<=
+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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 4,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 |<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=C2=
+=A0=C2=A0=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 |<br>=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Value,Sequence | Va=
+lue,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 |<br>=C2=A0+--------------------------------------------------------=
+-----+<br>=C2=A0|input0 1,00000000=C2=A0=C2=A0=C2=A0=C2=A0 | 0,OP_RETURN &l=
+t;version&gt; &lt;txid&gt; &lt;nonce&gt; |<br>=C2=A0|input1 3,00000000=C2=
+=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
+=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
+=C2=A0=C2=A0=C2=A0=C2=A0=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|input2 4,00000000=C2=A0=C2=A0=C2=A0=C2=A0=
+ |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
+=A0=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| lock_time=3D499999999=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
+=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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 tran=
+sactions.<br><br>The purpose of the nonce is to make it harder to use a sto=
+len PoP; Once the PoP has reached the server, that PoP is useless since the=
+ server will generate a new nonce for every PoP request.<br><br>=3D=3D=3D P=
+rocess =3D=3D=3D<br><br># A proof of payment request is sent from the serve=
+r to the wallet. The PoP request contains:<br>## a random nonce<br>## a des=
+tination where to send the PoP, for example a https URL<br>## data hinting =
+the wallet which transaction to create a proof for. For example:<br>##* txi=
+d, if known by the server<br>##* PaymentRequest.PaymentDetails.merchant_dat=
+a (in case of a BIP0070 payment)<br>##* amount, label, message or other inf=
+ormation from a BIP0021 URI<br># The wallet identifies a transaction T, if =
+possible. Otherwise it asks the user to select among the ones that match th=
+e hints in 1.iii.<br># The wallet creates an unsigned PoP (UPoP) for T, and=
+ asks the user to sign it.<br># The user confirms<br># The UPoP(T) is signe=
+d by the wallet, creating PoP(T).<br># The PoP is sent to the destination i=
+n 1.ii.<br># The server receiving the PoP validates it and responds with =
+=E2=80=9Cvalid=E2=80=9D or =E2=80=9Cinvalid=E2=80=9D.<br># The wallet displ=
+ays the response in some way to the user.<br><br>&#39;&#39;&#39;Remarks:&#3=
+9;&#39;&#39;<br><br>* 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).<br>* The nonce must be random=
+ly generated by the server for every new PoP request.<br><br>=3D=3D=3D Vali=
+dating a PoP =3D=3D=3D<br><br>The server needs to validate the PoP and repl=
+y with &quot;valid&quot; or &quot;invalid&quot;. That process is outlined b=
+elow. If any step fails, the validation is aborted and &quot;invalid&quot; =
+is returned:<br><br># Check the format of the PoP. It must pass normal tran=
+saction checks, except that the inputs may already be spent.<br># Check tha=
+t lock_time is 499999999.<br># Check that there is exactly one output. This=
+ output must have value 0 and conform to the OP_RETURN output format outlin=
+ed above.<br># Check that the nonce is the same as the one requested.<br># =
+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 the inputs =
+must also be the same as in T.<br># Run the scripts of all the inputs. All =
+scipts must return true.<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 pa=
+ys for the product/service you deliver.<br># Return &quot;valid&quot;.<br><=
+br>=3D=3D Security considerations =3D=3D<br><br>* Someone can intercept the=
+ PoP-request and change any parameter in it. These can be mitigated by usin=
+g secure connections. For example:<br>** Pop destination - Stealing your Po=
+P.<br>** label - Trick you to sign an unintended pop or set a label that yo=
+ur wallet doesn&#39;t have any record for, resulting in a broken service. A=
+lways check the PoP before signing.<br>** nonce - Your pop will not validat=
+e on server.<br>* Someone can steal a PoP, for example by tampering with th=
+e PoP request, and try to use the service hoping to get a matching nonce. P=
+robability per try: 1/(2^48). The server should have a mechanism for detect=
+ing 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 has n=
+o funds it might still be valuable as a generator for PoPs. This makes it i=
+mportant to keep the security of the wallet after it has been emptied.<br>*=
+ Transaction malleability may cause the server to have another transaction =
+id for a payment than the client&#39;s wallet. In that case the wallet will=
+ not be able to prove the transaction to the server. Wallets should not rel=
+y on the transaction id of the outgoing transaction. Instead it should list=
+en for the transaction on the network and put that in its list of transacti=
+ons.<br><br>=3D=3D Reference implementation =3D=3D<br><br>[<a href=3D"https=
+://github.com/kallerosenbaum/poppoc">https://github.com/kallerosenbaum/popp=
+oc</a> poppoc on GitHub]<br><br>[<a href=3D"https://github.com/kallerosenba=
+um/wallet">https://github.com/kallerosenbaum/wallet</a> Mycelium fork on Gi=
+tHub]<br><br>=3D=3D References =3D=3D<br><br>[<a href=3D"https://github.com=
+/bitcoin/bips/blob/master/bip-0021.mediawiki">https://github.com/bitcoin/bi=
+ps/blob/master/bip-0021.mediawiki</a> BIP0021]: URI Scheme<br><br>[<a href=
+=3D"https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki">https:/=
+/github.com/bitcoin/bips/blob/master/bip-0070.mediawiki</a> BIP0070]: Payme=
+nt Protocol<br><br>[[btcpop scheme BIP]]<br><br>###########################=
+##############################<br><br>2015-06-06 23:25 GMT+02:00 Kalle Rose=
+nbaum &lt;<a href=3D"mailto:kalle@rosenbaum.se">kalle@rosenbaum.se</a>&gt;:=
+<br>&gt; Thank you all for the feedback.<br>&gt;<br>&gt; I will change the =
+data structure as follows:<br>&gt;<br>&gt; * There will be only one output,=
+ the &quot;pop output&quot;, and no outputs from<br>&gt; T will be copied t=
+o the PoP.<br>&gt; * The pop output will have value 0.<br>&gt; * The sequen=
+ce number of all inputs of the PoP will be set to 0. I<br>&gt; chose to set=
+ it to 0 for all inputs for simplicity.<br>&gt; * The lock_time of the PoP =
+is always set to 499999999.<br>&gt;<br>&gt; Any comments on this?<br>&gt;<b=
+r>&gt; /Kalle<br>&gt;<br>&gt; 2015-06-06 19:00 GMT+02:00 Kalle Rosenbaum &l=
+t;<a href=3D"mailto:kalle@rosenbaum.se">kalle@rosenbaum.se</a>&gt;:<br>&gt;=
+&gt; 2015-06-06 18:10 GMT+02:00 Tom Harding &lt;<a href=3D"mailto:tomh@thin=
+link.com">tomh@thinlink.com</a>&gt;:<br>&gt;&gt;&gt; On Jun 6, 2015 8:05 AM=
+, &quot;Kalle Rosenbaum&quot; &lt;<a href=3D"mailto:kalle@rosenbaum.se">kal=
+le@rosenbaum.se</a>&gt; wrote:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; I&#39;m =
+open to changes here.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; I suggest:<br>&gt;&gt=
+;&gt;<br>&gt;&gt;&gt; - Don&#39;t include any real outputs. =C2=A0 They are=
+ redundant because the txid is<br>&gt;&gt;&gt; already referenced.<br>&gt;&=
+gt;<br>&gt;&gt; with the nLocktime solution, the copied outputs are not nee=
+ded.<br>&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; - Start the proof script, =
+which should be invalid, with a magic constant and<br>&gt;&gt;&gt; include =
+space for future expansion.=C2=A0 This makes PoP&#39;s easy to identify and=
+<br>&gt;&gt;&gt; extend.<br>&gt;&gt;<br>&gt;&gt; I did remore the constant =
+(a &quot;PoP&quot; literal ascii encoded string)<br>&gt;&gt; because it did=
+n&#39;t add much. The recipient will expect a pop, so it<br>&gt;&gt; will s=
+imply treat it as one. I did add a 2 byte version field to make<br>&gt;&gt;=
+ it extendable.<br>&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; - &quot;Proof o=
+f Potential&quot;<br>&gt;&gt;<br>&gt;&gt; Noted :-)<br>&gt;&gt;<br>&gt;&gt;=
+ Thank you<br>&gt;&gt; /Kalle</div></div></div></div>
+
+--001a11374472401ab905188afa6b--
+
+