diff options
author | Kalle Rosenbaum <kalle@rosenbaum.se> | 2015-06-15 11:21:06 +0200 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-06-15 09:21:14 +0000 |
commit | d9fabb3ef5457752f1676e2f6a9c46f0af08cd63 (patch) | |
tree | 4010ebf9aadc43f1936389f2d76a7242a948d37f | |
parent | 7db1b7761c5fd5b2a4fae792796f2c8c392ac6f9 (diff) | |
download | pi-bitcoindev-d9fabb3ef5457752f1676e2f6a9c46f0af08cd63.tar.gz pi-bitcoindev-d9fabb3ef5457752f1676e2f6a9c46f0af08cd63.zip |
Re: [Bitcoin-development] BIP for Proof of Payment
-rw-r--r-- | 06/257492247f743769ee0aa673e2bf3e9e51816d | 619 |
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 +|- +| <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 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 "pop outpu= +t", 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 "Proof of Payment" is the most descripti= +ve to non-technical people.<br></div><div><br>Regards,<br>Kalle<br><br><br>= +#################################################<br><pre><br>=C2=A0 = +BIP: <BIP number><br>=C2=A0 Title: Proof of Payment<br>=C2=A0 Author:= + Kalle Rosenbaum <<a href=3D"mailto:kalle@rosenbaum.se">kalle@rosenbaum.= +se</a>><br>=C2=A0 Status: Draft<br>=C2=A0 Type: Standards Track<br>=C2= +=A0 Created: <date created on, in ISO 8601 (yyyy-mm-dd) format><br>&l= +t;/pre><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'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 <version> <= +txid> <nonce><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>| &lt;version> || 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= +=A0=C2=A0 || Version, little endian, currently 0x01 0x00<br>|-<br>| &lt= +;txid>=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>| &lt;nonce>=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><pre><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 <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> <txid> <nonce> |<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></pre><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>'''Remarks:= +9;''<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 "valid" or "invalid". That process is outlined b= +elow. If any step fails, the validation is aborted and "invalid" = +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 "valid".<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'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'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 <<a href=3D"mailto:kalle@rosenbaum.se">kalle@rosenbaum.se</a>>:= +<br>> Thank you all for the feedback.<br>><br>> I will change the = +data structure as follows:<br>><br>> * There will be only one output,= + the "pop output", and no outputs from<br>> T will be copied t= +o the PoP.<br>> * The pop output will have value 0.<br>> * The sequen= +ce number of all inputs of the PoP will be set to 0. I<br>> chose to set= + it to 0 for all inputs for simplicity.<br>> * The lock_time of the PoP = +is always set to 499999999.<br>><br>> Any comments on this?<br>><b= +r>> /Kalle<br>><br>> 2015-06-06 19:00 GMT+02:00 Kalle Rosenbaum &l= +t;<a href=3D"mailto:kalle@rosenbaum.se">kalle@rosenbaum.se</a>>:<br>>= +> 2015-06-06 18:10 GMT+02:00 Tom Harding <<a href=3D"mailto:tomh@thin= +link.com">tomh@thinlink.com</a>>:<br>>>> On Jun 6, 2015 8:05 AM= +, "Kalle Rosenbaum" <<a href=3D"mailto:kalle@rosenbaum.se">kal= +le@rosenbaum.se</a>> wrote:<br>>>><br>>>>> I'm = +open to changes here.<br>>>><br>>>> I suggest:<br>>>= +;><br>>>> - Don't include any real outputs. =C2=A0 They are= + redundant because the txid is<br>>>> already referenced.<br>>&= +gt;<br>>> with the nLocktime solution, the copied outputs are not nee= +ded.<br>>><br>>>><br>>>> - Start the proof script, = +which should be invalid, with a magic constant and<br>>>> include = +space for future expansion.=C2=A0 This makes PoP's easy to identify and= +<br>>>> extend.<br>>><br>>> I did remore the constant = +(a "PoP" literal ascii encoded string)<br>>> because it did= +n't add much. The recipient will expect a pop, so it<br>>> will s= +imply treat it as one. I did add a 2 byte version field to make<br>>>= + it extendable.<br>>><br>>>><br>>>> - "Proof o= +f Potential"<br>>><br>>> Noted :-)<br>>><br>>>= + Thank you<br>>> /Kalle</div></div></div></div> + +--001a11374472401ab905188afa6b-- + + |