From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z4RCP-0002xs-7u for bitcoin-development@lists.sourceforge.net; Mon, 15 Jun 2015 10:01:01 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.53 as permitted sender) client-ip=209.85.213.53; envelope-from=pieter.wuille@gmail.com; helo=mail-yh0-f53.google.com; Received: from mail-yh0-f53.google.com ([209.85.213.53]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z4RCM-0004eh-LX for bitcoin-development@lists.sourceforge.net; Mon, 15 Jun 2015 10:01:01 +0000 Received: by yhid80 with SMTP id d80so39171121yhi.1 for ; Mon, 15 Jun 2015 03:00:53 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.13.252.1 with SMTP id m1mr33809602ywf.153.1434362453125; Mon, 15 Jun 2015 03:00:53 -0700 (PDT) Received: by 10.37.93.67 with HTTP; Mon, 15 Jun 2015 03:00:52 -0700 (PDT) Received: by 10.37.93.67 with HTTP; Mon, 15 Jun 2015 03:00:52 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Jun 2015 12:00:52 +0200 Message-ID: From: Pieter Wuille To: Kalle Rosenbaum , Bitcoin Dev Content-Type: multipart/alternative; boundary=94eb2c064ab87f6e2e05188b882e 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: 1Z4RCM-0004eh-LX Subject: Re: [Bitcoin-development] BIP for Proof of Payment X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 10:01:01 -0000 --94eb2c064ab87f6e2e05188b882e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I did misunderstand that. That changes things significantly. However, having paid is not the same as having had access to the input coins. What about shared wallets or coinjoin? Also, if I understand correctly, there is no commitment to anything you're trying to say about the sender? So once I obtain a proof-of-payment from you about something you paid, I can go claim that it's mine? Why does anyone care who paid? This is like walking into a coffeshop, noticing I don't have money with me, let me friend pay for me, and then have the shop insist that I can't drink it because I'm not the buyer. Track payments, don't try to assign identities to payers. On Jun 15, 2015 11:35 AM, "Kalle Rosenbaum" wrote: > Hi Pieter! > > It is intended to be a proof that you *have paid* for something. Not > that you have the intent to pay for something. You cannot use PoP > without a transaction to prove. > > So, yes, it's just a proof of access to certain coins that you no longer > have. > > Maybe I don't understand you correctly? > > /Kalle > > 2015-06-15 11:27 GMT+02:00 Pieter Wuille : > > Now that you have removed the outputs, I don't think it's even a intent > of > > payment, but just a proof of access to certain coins. > > > > On Jun 15, 2015 11:24 AM, "Kalle Rosenbaum" wrote: > >> > >> Hi all! > >> > >> I have made the discussed changes and updated my implementation > >> (https://github.com/kallerosenbaum/poppoc) accordingly. These are the > >> changes: > >> > >> * There is now only one output, the "pop output", of value 0. > >> * The sequence number of all inputs of the PoP must be set to 0. I > >> chose to set it to 0 for all inputs for simplicity. > >> * The lock_time of the PoP must be set to 499999999 (max block height > lock > >> time). > >> > >> The comments so far has been mainly positive or neutral. Are there 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 > >> > >> > >> ################################################# > >> 
> >>   BIP: 
> >>   Title: Proof of Payment
> >>   Author: Kalle Rosenbaum 
> >>   Status: Draft
> >>   Type: Standards Track
> >>   Created: 
> >>
> >> > >> =3D=3D Abstract =3D=3D > >> > >> This BIP describes how a wallet can prove to a server that it has the > >> ability to sign a certain transaction. > >> > >> =3D=3D Motivation =3D=3D > >> > >> There are several scenarios in which it would be useful to prove that > you > >> have paid for something. For example: > >> > >> * A pre-paid hotel room where your PoP functions as a key to the door. > >> * An online video rental service where you pay for a video and watch i= t > 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 o= r > 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 t= o > >> 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 t= he > >> inputs of T. It has the exact same structure as a bitcoin transaction > with > >> the same inputs as T and in the same order as in T, but with each > sequence > >> number set to 0. There is exactly one output, here called the pop > output, > >> with value 0. The pop output must have the following format: > >> > >> OP_RETURN > >> > >> {| > >> ! Field !! Size [B] !! Description > >> |- > >> | <version> || 2 || Version, little endian, currently 0x01 > 0x00 > >> |- > >> | <txid> || 32 || The transaction to prove > >> |- > >> | <nonce> || 6 || Random data > >> |} > >> > >> The lock_time of the PoP must be set to 499999999 to prevent the PoP > from > >> being included in a block, should it appear on the bitcoin p2p network= . > This > >> is also the reason for setting the sequence numbers to 0, since sequen= ce > >> number of ffffffff would make lock_time ineffective. This specificatio= n > >> 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 simplicit= y > >> reasons. > >> > >> An illustration of the PoP data structure and its original payment is > >> shown below. > >> > >> 
> >>   T
> >>  +------------------------------------------------+
> >>  |inputs                | outputs                 |
> >>  |       Value,Sequence | Value,Script            |
> >>  +------------------------------------------------+
> >>  |input0 1,ffffffff     | 0,pay to A              |
> >>  |input1 3,ffffffff     | 2,OP_RETURN  |
> >>  |input2 4,ffffffff     | 1,pay to B              |
> >>  |                      | 4,pay to C              |
> >>  +------------------------------------------------+
> >>
> >>   PoP(T)
> >>  +-------------------------------------------------------------+
> >>  | inputs               | outputs                              |
> >>  |       Value,Sequence | Value,Script                         |
> >>  +-------------------------------------------------------------+
> >>  |input0 1,00000000     | 0,OP_RETURN    |
> >>  |input1 3,00000000     |                                      |
> >>  |input2 4,00000000     |                                      |
> >>  +-------------------------------------------------------------+
> >>  | lock_time=3D499999999                                         |
> >>  +-------------------------------------------------------------+
> >>
> >> > >> The PoP is signed using the same signing process that is used for > bitcoin > >> transactions. > >> > >> The purpose of the nonce is to make it harder to use a stolen PoP; Onc= e > >> 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. Th= e > >> 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. Fo= r > >> 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 ask= s > >> 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 t= o > >> sign it. > >> # The user confirms > >> # The UPoP(T) is signed by the wallet, creating PoP(T). > >> # The PoP is sent to the destination in 1.ii. > >> # The server receiving the PoP validates it and responds with =E2=80= =9Cvalid=E2=80=9D or > >> =E2=80=9Cinvalid=E2=80=9D. > >> # The wallet displays the response in some way to the user. > >> > >> '''Remarks:''' > >> > >> * The method of transferring the PoP request at step 1 is not specifie= d > >> here. Instead that is specified in separate specifications. See [btcpo= p > >> 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 actuall= y > >> 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 you= r > >> 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 brut= e > >> 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 th= e > >> wallet will not be able to prove the transaction to the server. Wallet= s > >> 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 it= s > list > >> of transactions. > >> > >> =3D=3D Reference implementation =3D=3D > >> > >> [https://github.com/kallerosenbaum/poppoc poppoc on GitHub] > >> > >> [https://github.com/kallerosenbaum/wallet Mycelium fork on GitHub] > >> > >> =3D=3D References =3D=3D > >> > >> [https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki > BIP0021]: > >> URI Scheme > >> > >> [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki > BIP0070]: > >> Payment Protocol > >> > >> [[btcpop scheme BIP]] > >> > >> ######################################################### > >> > >> 2015-06-06 23:25 GMT+02:00 Kalle Rosenbaum : > >> > Thank you all for the feedback. > >> > > >> > I will change the data structure as follows: > >> > > >> > * There will be only one output, the "pop output", and no outputs fr= om > >> > T will be copied to the PoP. > >> > * The pop output will have value 0. > >> > * The sequence number of all inputs of the PoP will be set to 0. I > >> > chose to set it to 0 for all inputs for simplicity. > >> > * The lock_time of the PoP is always set to 499999999. > >> > > >> > Any comments on this? > >> > > >> > /Kalle > >> > > >> > 2015-06-06 19:00 GMT+02:00 Kalle Rosenbaum : > >> >> 2015-06-06 18:10 GMT+02:00 Tom Harding : > >> >>> On Jun 6, 2015 8:05 AM, "Kalle Rosenbaum" > wrote: > >> >>> > >> >>>> I'm open to changes here. > >> >>> > >> >>> I suggest: > >> >>> > >> >>> - Don't include any real outputs. They are redundant because 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 ma= ke > >> >> it extendable. > >> >> > >> >>> > >> >>> - "Proof of Potential" > >> >> > >> >> Noted :-) > >> >> > >> >> Thank you > >> >> /Kalle > >> > >> > >> > -------------------------------------------------------------------------= ----- > >> > >> _______________________________________________ > >> Bitcoin-development mailing list > >> Bitcoin-development@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >> > > > --94eb2c064ab87f6e2e05188b882e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I did misunderstand that. That changes things significantly.=

However, having paid is not the same as having had access to= the input coins. What about shared wallets or coinjoin?

Also, if I understand correctly, there is no commitment to a= nything you're trying to say about the sender? So once I obtain a proof= -of-payment from you about something you paid, I can go claim that it's= mine?

Why does anyone care who paid? This is like walking into a c= offeshop, noticing I don't have money with me, let me friend pay for me= , and then have the shop insist that I can't drink it because I'm n= ot the buyer.

Track payments, don't try to assign identities to payers= .

On Jun 15, 2015 11:35 AM, "Kalle Rosenbaum&= quot; <kalle@rosenbaum.se> = wrote:
Hi Pieter!
It is intended to be a proof that you *have paid* for something. Not
that you have the intent to pay for something. You cannot use PoP
without a transaction to prove.

So, yes, it's just a proof of access to certain coins that you no longe= r have.

Maybe I don't understand you correctly?

/Kalle

2015-06-15 11:27 GMT+02:00 Pieter Wuille <pieter.wuille@gmail.com>:
> Now that you have removed the outputs, I don't think it's even= a intent of
> payment, but just a proof of access to certain coins.
>
> On Jun 15, 2015 11:24 AM, "Kalle Rosenbaum" <kalle@rosenbaum.se> wrote:
>>
>> Hi all!
>>
>> I have made the discussed changes and updated my implementation >> (https://github.com/kallerosenbaum/poppoc) acco= rdingly. These are the
>> changes:
>>
>> * There is now only one output, the "pop output", of val= ue 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 hei= ght 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/kaller= osenbaum/poppoc/wiki/Proof-of-Payment-BIP and
>> https://github.com/kallerose= nbaum/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>
>>=C2=A0 =C2=A0BIP: <BIP number>
>>=C2=A0 =C2=A0Title: Proof of Payment
>>=C2=A0 =C2=A0Author: Kalle Rosenbaum <kalle@rosenbaum.se>
>>=C2=A0 =C2=A0Status: Draft
>>=C2=A0 =C2=A0Type: Standards Track
>>=C2=A0 =C2=A0Created: <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 t= hat you
>> have paid for something. For example:
>>
>> * A pre-paid hotel room where your PoP functions as a key to the d= oor.
>> * An online video rental service where you pay for a video and wat= ch 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 li= ke using
>> PoP.
>> * Log in to a pay site using a PoP.
>> * A parking lot you pay for monthly and the car authenticates itse= lf using
>> PoP.
>> * A lottery where all participants pay to the same address, and th= e winner
>> is selected among the transactions to that address. You exchange t= he prize
>> for a PoP for the winning transaction.
>>
>> With Proof of Payment, these use cases can be achieved without any=
>> personal information (user name, password, e-mail address, etc) be= ing
>> 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 t= he
>> inputs of the proven transaction.
>> # It should be easy to implement by wallets and servers to ease ad= option.
>>
>> Current methods of proving a payment:
>>
>> * In BIP0070, the PaymentRequest together with the transactions fu= lfilling
>> 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 BIP00= 70. Also,
>> there's no standard way to request/provide the proof. If stand= ardized it
>> would probably meet 5.
>> * Signing messages, chosen by the server, with the private keys us= ed 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 o= f M keys
>> that signed the transaction. This is important because strictly de= manding
>> the same set of M keys would defeat the purpose of a multisig addr= ess.
>>
>> =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 use= d to
>> prove that one has ownership of the credentials needed to unlock a= ll the
>> inputs of T. It has the exact same structure as a bitcoin transact= ion 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:
>>
>>=C2=A0 OP_RETURN <version> <txid> <nonce>
>>
>> {|
>> ! Field=C2=A0 =C2=A0 =C2=A0 =C2=A0 !! Size [B] !! Description
>> |-
>> | &lt;version> || 2=C2=A0 =C2=A0 =C2=A0 =C2=A0 || Version, = little endian, currently 0x01 0x00
>> |-
>> | &lt;txid>=C2=A0 =C2=A0 || 32=C2=A0 =C2=A0 =C2=A0 =C2=A0||= The transaction to prove
>> |-
>> | &lt;nonce>=C2=A0 =C2=A0|| 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 ||= Random data
>> |}
>>
>> The lock_time of the PoP must be set to 499999999 to prevent the P= oP from
>> being included in a block, should it appear on the bitcoin p2p net= work. This
>> is also the reason for setting the sequence numbers to 0, since se= quence
>> number of ffffffff would make lock_time ineffective. This specific= ation
>> demands that all input sequence numbers are 0, not just one of the= m, which
>> would be sufficient to make lock_time effective. This is for simpl= icity
>> reasons.
>>
>> An illustration of the PoP data structure and its original payment= is
>> shown below.
>>
>> <pre>
>>=C2=A0 =C2=A0T
>>=C2=A0 +------------------------------------------------+
>>=C2=A0 |inputs=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=A0Value,Sequence | Value,Script=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>>=C2=A0 +------------------------------------------------+
>>=C2=A0 |input0 1,ffffffff=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 |input1 3,ffffffff=C2=A0 =C2=A0 =C2=A0| 2,OP_RETURN <some= data> |
>>=C2=A0 |input2 4,ffffffff=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 =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=A0PoP(T)
>>=C2=A0 +-----------------------------------------------------------= --+
>>=C2=A0 | inputs=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=A0Value,Sequence | Value,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 |input0 1,00000000=C2=A0 =C2=A0 =C2=A0| 0,OP_RETURN <vers= ion> <txid> <nonce> |
>>=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 |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 | 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 +-----------------------------------------------------------= --+
>> </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 serv= er 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 BIP0= 070
>> 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 us= er to
>> sign it.
>> # The user confirms
>> # The UPoP(T) is signed by the wallet, creating PoP(T).
>> # The PoP is sent to the destination in 1.ii.
>> # The server receiving the PoP validates it and responds with =E2= =80=9Cvalid=E2=80=9D or
>> =E2=80=9Cinvalid=E2=80=9D.
>> # The wallet displays the response in some way to the user.
>>
>> '''Remarks:'''
>>
>> * The method of transferring the PoP request at step 1 is not spec= ified
>> here. Instead that is specified in separate specifications. See [b= tcpop
>> 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&qu= ot; 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 che= cks,
>> 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 va= lue 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 tran= saction
>> 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.<= br> >> # Check that the txid in the PoP output is the transaction you act= ually
>> 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/serv= ice you
>> deliver.
>> # Return "valid".
>>
>> =3D=3D Security considerations =3D=3D
>>
>> * Someone can intercept the PoP-request and change any parameter i= n 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 serv= ice. 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 r= equest,
>> and try to use the service hoping to get a matching nonce. Probabi= lity 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 de= laying the
>> PoP request by some 100 ms or so.
>> * Even if a wallet has no funds it might still be valuable as a ge= nerator
>> for PoPs. This makes it important to keep the security of the wall= et 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. Wa= llets
>> should not rely on the transaction id of the outgoing transaction.= Instead
>> it should listen for the transaction on the network and put that i= n its list
>> of transactions.
>>
>> =3D=3D Reference implementation =3D=3D
>>
>> [https://github.com/kallerosenbaum/poppoc poppo= c on GitHub]
>>
>> [https://github.com/kallerosenbaum/wallet Mycel= ium fork on GitHub]
>>
>> =3D=3D References =3D=3D
>>
>> [https://github.com/bitcoin/b= ips/blob/master/bip-0021.mediawiki BIP0021]:
>> URI Scheme
>>
>> [https://github.com/bitcoin/b= ips/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" &= lt;kalle@rosenbaum.se> wrote:<= br> >> >>>
>> >>>> I'm open to changes here.
>> >>>
>> >>> I suggest:
>> >>>
>> >>> - Don't include any real outputs.=C2=A0 =C2=A0The= y are redundant because the
>> >>> txid is
>> >>> already referenced.
>> >>
>> >> with the nLocktime solution, the copied outputs are not n= eeded.
>> >>
>> >>>
>> >>> - Start the proof script, which should be invalid, wi= th a magic
>> >>> constant and
>> >>> include space for future expansion.=C2=A0 This makes = PoP's easy to identify
>> >>> and
>> >>> extend.
>> >>
>> >> I did remore the constant (a "PoP" literal asci= i 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 f= ield to make
>> >> it extendable.
>> >>
>> >>>
>> >>> - "Proof of Potential"
>> >>
>> >> Noted :-)
>> >>
>> >> Thank you
>> >> /Kalle
>>
>>
>> ------------------------------------------------------------------= ------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitco= in-development@lists.sourceforge.net
>> https://lists.sourceforge.n= et/lists/listinfo/bitcoin-development
>>
>
--94eb2c064ab87f6e2e05188b882e--