path: root/c4/7ce12514eb3bfda6b4a1d7406ee57d328c9d30

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 <pieter.wuille@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <CAPswA9zycU0pwZKaHU9J3Tvg=ovLJ8TZ9OH6ebTPONaRaiOE8g@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>
	<CAPswA9xk5QYAXxQ6ES3cnNPeB1FTiiSJgLahLEkSk4CLpoM_QQ@mail.gmail.com>
	<CAPg+sBiWykR6RaHhbyYQbL=A5t1TmHgEmS_sC7jj9d3SUTMO9g@mail.gmail.com>
	<CAPswA9zycU0pwZKaHU9J3Tvg=ovLJ8TZ9OH6ebTPONaRaiOE8g@mail.gmail.com>
Date: Mon, 15 Jun 2015 12:00:52 +0200
Message-ID: <CAPg+sBhuth22+vAHyS2iwpze8X=-b2wJQ5s1z2FhZ1jsLXobgQ@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Kalle Rosenbaum <kalle@rosenbaum.se>, 
	Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: <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 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" <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 longer
> 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) 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 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 <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 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.
> >>
> >> <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; 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 <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 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 <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 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

<p dir=3D"ltr">I did misunderstand that. That changes things significantly.=
</p>
<p dir=3D"ltr">However, having paid is not the same as having had access to=
 the input coins. What about shared wallets or coinjoin?</p>
<p dir=3D"ltr">Also, if I understand correctly, there is no commitment to a=
nything you&#39;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&#39;s=
 mine?</p>
<p dir=3D"ltr">Why does anyone care who paid? This is like walking into a c=
offeshop, noticing I don&#39;t have money with me, let me friend pay for me=
, and then have the shop insist that I can&#39;t drink it because I&#39;m n=
ot the buyer.</p>
<p dir=3D"ltr">Track payments, don&#39;t try to assign identities to payers=
.</p>
<div class=3D"gmail_quote">On Jun 15, 2015 11:35 AM, &quot;Kalle Rosenbaum&=
quot; &lt;<a href=3D"mailto:kalle@rosenbaum.se">kalle@rosenbaum.se</a>&gt; =
wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Pieter!<br=
>
<br>
It is intended to be a proof that you *have paid* for something. Not<br>
that you have the intent to pay for something. You cannot use PoP<br>
without a transaction to prove.<br>
<br>
So, yes, it&#39;s just a proof of access to certain coins that you no longe=
r have.<br>
<br>
Maybe I don&#39;t understand you correctly?<br>
<br>
/Kalle<br>
<br>
2015-06-15 11:27 GMT+02:00 Pieter Wuille &lt;<a href=3D"mailto:pieter.wuill=
e@gmail.com">pieter.wuille@gmail.com</a>&gt;:<br>
&gt; Now that you have removed the outputs, I don&#39;t think it&#39;s even=
 a intent of<br>
&gt; payment, but just a proof of access to certain coins.<br>
&gt;<br>
&gt; On Jun 15, 2015 11:24 AM, &quot;Kalle Rosenbaum&quot; &lt;<a href=3D"m=
ailto:kalle@rosenbaum.se">kalle@rosenbaum.se</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Hi all!<br>
&gt;&gt;<br>
&gt;&gt; I have made the discussed changes and updated my implementation<br=
>
&gt;&gt; (<a href=3D"https://github.com/kallerosenbaum/poppoc" rel=3D"noref=
errer" target=3D"_blank">https://github.com/kallerosenbaum/poppoc</a>) acco=
rdingly. These are the<br>
&gt;&gt; changes:<br>
&gt;&gt;<br>
&gt;&gt; * There is now only one output, the &quot;pop output&quot;, of val=
ue 0.<br>
&gt;&gt; * The sequence number of all inputs of the PoP must be set to 0. I=
<br>
&gt;&gt; chose to set it to 0 for all inputs for simplicity.<br>
&gt;&gt; * The lock_time of the PoP must be set to 499999999 (max block hei=
ght lock<br>
&gt;&gt; time).<br>
&gt;&gt;<br>
&gt;&gt; The comments so far has been mainly positive or neutral. Are there=
 any<br>
&gt;&gt; major objections against any of the two proposals? If not, I will =
ask<br>
&gt;&gt; Gregory Maxwell to assign them BIP numbers.<br>
&gt;&gt;<br>
&gt;&gt; The two BIP proposals can be found at<br>
&gt;&gt; <a href=3D"https://github.com/kallerosenbaum/poppoc/wiki/Proof-of-=
Payment-BIP" rel=3D"noreferrer" target=3D"_blank">https://github.com/kaller=
osenbaum/poppoc/wiki/Proof-of-Payment-BIP</a> and<br>
&gt;&gt; <a href=3D"https://github.com/kallerosenbaum/poppoc/wiki/btcpop-sc=
heme-BIP" rel=3D"noreferrer" target=3D"_blank">https://github.com/kallerose=
nbaum/poppoc/wiki/btcpop-scheme-BIP</a>. The source<br>
&gt;&gt; for the Proof of Payment BIP proposal is also in-lined below.<br>
&gt;&gt;<br>
&gt;&gt; A number of alternative names have been proposed:<br>
&gt;&gt;<br>
&gt;&gt; * Proof of Potential<br>
&gt;&gt; * Proof of Control<br>
&gt;&gt; * Proof of Signature<br>
&gt;&gt; * Signatory Proof<br>
&gt;&gt; * Popo: Proof of payment origin<br>
&gt;&gt; * Pots: Proof of transaction signer<br>
&gt;&gt; * proof of transaction intent<br>
&gt;&gt; * Declaration of intent<br>
&gt;&gt; * Asset-access-and-action-affirmation, AAaAA, or A5<br>
&gt;&gt; * VeriBit<br>
&gt;&gt; * CertiBTC<br>
&gt;&gt; * VBit<br>
&gt;&gt; * PayID<br>
&gt;&gt;<br>
&gt;&gt; Given this list, I still think &quot;Proof of Payment&quot; is the=
 most descriptive<br>
&gt;&gt; to non-technical people.<br>
&gt;&gt;<br>
&gt;&gt; Regards,<br>
&gt;&gt; Kalle<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; #################################################<br>
&gt;&gt; &lt;pre&gt;<br>
&gt;&gt;=C2=A0 =C2=A0BIP: &lt;BIP number&gt;<br>
&gt;&gt;=C2=A0 =C2=A0Title: Proof of Payment<br>
&gt;&gt;=C2=A0 =C2=A0Author: Kalle Rosenbaum &lt;<a href=3D"mailto:kalle@ro=
senbaum.se">kalle@rosenbaum.se</a>&gt;<br>
&gt;&gt;=C2=A0 =C2=A0Status: Draft<br>
&gt;&gt;=C2=A0 =C2=A0Type: Standards Track<br>
&gt;&gt;=C2=A0 =C2=A0Created: &lt;date created on, in ISO 8601 (yyyy-mm-dd)=
 format&gt;<br>
&gt;&gt; &lt;/pre&gt;<br>
&gt;&gt;<br>
&gt;&gt; =3D=3D Abstract =3D=3D<br>
&gt;&gt;<br>
&gt;&gt; This BIP describes how a wallet can prove to a server that it has =
the<br>
&gt;&gt; ability to sign a certain transaction.<br>
&gt;&gt;<br>
&gt;&gt; =3D=3D Motivation =3D=3D<br>
&gt;&gt;<br>
&gt;&gt; There are several scenarios in which it would be useful to prove t=
hat you<br>
&gt;&gt; have paid for something. For example:<br>
&gt;&gt;<br>
&gt;&gt; * A pre-paid hotel room where your PoP functions as a key to the d=
oor.<br>
&gt;&gt; * An online video rental service where you pay for a video and wat=
ch it on<br>
&gt;&gt; any device.<br>
&gt;&gt; * An ad-sign where you pay in advance for e.g. 2 weeks exclusivity=
. During<br>
&gt;&gt; this period you can upload new content to the sign whenever you li=
ke using<br>
&gt;&gt; PoP.<br>
&gt;&gt; * Log in to a pay site using a PoP.<br>
&gt;&gt; * A parking lot you pay for monthly and the car authenticates itse=
lf using<br>
&gt;&gt; PoP.<br>
&gt;&gt; * A lottery where all participants pay to the same address, and th=
e winner<br>
&gt;&gt; is selected among the transactions to that address. You exchange t=
he prize<br>
&gt;&gt; for a PoP for the winning transaction.<br>
&gt;&gt;<br>
&gt;&gt; With Proof of Payment, these use cases can be achieved without any=
<br>
&gt;&gt; personal information (user name, password, e-mail address, etc) be=
ing<br>
&gt;&gt; involved.<br>
&gt;&gt;<br>
&gt;&gt; =3D=3D Rationale =3D=3D<br>
&gt;&gt;<br>
&gt;&gt; Desirable properties:<br>
&gt;&gt;<br>
&gt;&gt; # A PoP should be generated on demand.<br>
&gt;&gt; # It should only be usable once to avoid issues due to theft.<br>
&gt;&gt; # It should be able to create a PoP for any payment, regardless of=
 script<br>
&gt;&gt; type (P2SH, P2PKH, etc.).<br>
&gt;&gt; # It should prove that you have enough credentials to unlock all t=
he<br>
&gt;&gt; inputs of the proven transaction.<br>
&gt;&gt; # It should be easy to implement by wallets and servers to ease ad=
option.<br>
&gt;&gt;<br>
&gt;&gt; Current methods of proving a payment:<br>
&gt;&gt;<br>
&gt;&gt; * In BIP0070, the PaymentRequest together with the transactions fu=
lfilling<br>
&gt;&gt; the request makes some sort of proof. However, it does not meet 1,=
 2 or 4<br>
&gt;&gt; and it obviously only meets 3 if the payment is made through BIP00=
70. Also,<br>
&gt;&gt; there&#39;s no standard way to request/provide the proof. If stand=
ardized it<br>
&gt;&gt; would probably meet 5.<br>
&gt;&gt; * Signing messages, chosen by the server, with the private keys us=
ed to<br>
&gt;&gt; sign the transaction. This could meet 1 and 2 but probably not 3. =
This is<br>
&gt;&gt; not standardized either. 4 Could be met if designed so.<br>
&gt;&gt;<br>
&gt;&gt; If an input script type is P2SH, any satisfying script should do, =
just as<br>
&gt;&gt; if it was a payment. For M-of-N multisig scripts, that would mean =
that any<br>
&gt;&gt; set of M keys should be sufficient, not neccesarily the same set o=
f M keys<br>
&gt;&gt; that signed the transaction. This is important because strictly de=
manding<br>
&gt;&gt; the same set of M keys would defeat the purpose of a multisig addr=
ess.<br>
&gt;&gt;<br>
&gt;&gt; =3D=3D Specification =3D=3D<br>
&gt;&gt;<br>
&gt;&gt; =3D=3D=3D Data structure =3D=3D=3D<br>
&gt;&gt;<br>
&gt;&gt; A proof of payment for a transaction T, here called PoP(T), is use=
d to<br>
&gt;&gt; prove that one has ownership of the credentials needed to unlock a=
ll the<br>
&gt;&gt; inputs of T. It has the exact same structure as a bitcoin transact=
ion with<br>
&gt;&gt; the same inputs as T and in the same order as in T, but with each =
sequence<br>
&gt;&gt; number set to 0. There is exactly one output, here called the pop =
output,<br>
&gt;&gt; with value 0. The pop output must have the following format:<br>
&gt;&gt;<br>
&gt;&gt;=C2=A0 OP_RETURN &lt;version&gt; &lt;txid&gt; &lt;nonce&gt;<br>
&gt;&gt;<br>
&gt;&gt; {|<br>
&gt;&gt; ! Field=C2=A0 =C2=A0 =C2=A0 =C2=A0 !! Size [B] !! Description<br>
&gt;&gt; |-<br>
&gt;&gt; | &amp;lt;version&gt; || 2=C2=A0 =C2=A0 =C2=A0 =C2=A0 || Version, =
little endian, currently 0x01 0x00<br>
&gt;&gt; |-<br>
&gt;&gt; | &amp;lt;txid&gt;=C2=A0 =C2=A0 || 32=C2=A0 =C2=A0 =C2=A0 =C2=A0||=
 The transaction to prove<br>
&gt;&gt; |-<br>
&gt;&gt; | &amp;lt;nonce&gt;=C2=A0 =C2=A0|| 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 ||=
 Random data<br>
&gt;&gt; |}<br>
&gt;&gt;<br>
&gt;&gt; The lock_time of the PoP must be set to 499999999 to prevent the P=
oP from<br>
&gt;&gt; being included in a block, should it appear on the bitcoin p2p net=
work. This<br>
&gt;&gt; is also the reason for setting the sequence numbers to 0, since se=
quence<br>
&gt;&gt; number of ffffffff would make lock_time ineffective. This specific=
ation<br>
&gt;&gt; demands that all input sequence numbers are 0, not just one of the=
m, which<br>
&gt;&gt; would be sufficient to make lock_time effective. This is for simpl=
icity<br>
&gt;&gt; reasons.<br>
&gt;&gt;<br>
&gt;&gt; An illustration of the PoP data structure and its original payment=
 is<br>
&gt;&gt; shown below.<br>
&gt;&gt;<br>
&gt;&gt; &lt;pre&gt;<br>
&gt;&gt;=C2=A0 =C2=A0T<br>
&gt;&gt;=C2=A0 +------------------------------------------------+<br>
&gt;&gt;=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=
|<br>
&gt;&gt;=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 |<br>
&gt;&gt;=C2=A0 +------------------------------------------------+<br>
&gt;&gt;=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 |<br>
&gt;&gt;=C2=A0 |input1 3,ffffffff=C2=A0 =C2=A0 =C2=A0| 2,OP_RETURN &lt;some=
 data&gt; |<br>
&gt;&gt;=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 |<br>
&gt;&gt;=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 |<br>
&gt;&gt;=C2=A0 +------------------------------------------------+<br>
&gt;&gt;<br>
&gt;&gt;=C2=A0 =C2=A0PoP(T)<br>
&gt;&gt;=C2=A0 +-----------------------------------------------------------=
--+<br>
&gt;&gt;=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 |<br>
&gt;&gt;=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|<br>
&gt;&gt;=C2=A0 +-----------------------------------------------------------=
--+<br>
&gt;&gt;=C2=A0 |input0 1,00000000=C2=A0 =C2=A0 =C2=A0| 0,OP_RETURN &lt;vers=
ion&gt; &lt;txid&gt; &lt;nonce&gt; |<br>
&gt;&gt;=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 |<br>
&gt;&gt;=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 |<br>
&gt;&gt;=C2=A0 +-----------------------------------------------------------=
--+<br>
&gt;&gt;=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|<br>
&gt;&gt;=C2=A0 +-----------------------------------------------------------=
--+<br>
&gt;&gt; &lt;/pre&gt;<br>
&gt;&gt;<br>
&gt;&gt; The PoP is signed using the same signing process that is used for =
bitcoin<br>
&gt;&gt; transactions.<br>
&gt;&gt;<br>
&gt;&gt; The purpose of the nonce is to make it harder to use a stolen PoP;=
 Once<br>
&gt;&gt; the PoP has reached the server, that PoP is useless since the serv=
er will<br>
&gt;&gt; generate a new nonce for every PoP request.<br>
&gt;&gt;<br>
&gt;&gt; =3D=3D=3D Process =3D=3D=3D<br>
&gt;&gt;<br>
&gt;&gt; # A proof of payment request is sent from the server to the wallet=
. The<br>
&gt;&gt; PoP request contains:<br>
&gt;&gt; ## a random nonce<br>
&gt;&gt; ## a destination where to send the PoP, for example a https URL<br=
>
&gt;&gt; ## data hinting the wallet which transaction to create a proof for=
. For<br>
&gt;&gt; example:<br>
&gt;&gt; ##* txid, if known by the server<br>
&gt;&gt; ##* PaymentRequest.PaymentDetails.merchant_data (in case of a BIP0=
070<br>
&gt;&gt; payment)<br>
&gt;&gt; ##* amount, label, message or other information from a BIP0021 URI=
<br>
&gt;&gt; # The wallet identifies a transaction T, if possible. Otherwise it=
 asks<br>
&gt;&gt; the user to select among the ones that match the hints in 1.iii.<b=
r>
&gt;&gt; # The wallet creates an unsigned PoP (UPoP) for T, and asks the us=
er to<br>
&gt;&gt; sign it.<br>
&gt;&gt; # The user confirms<br>
&gt;&gt; # The UPoP(T) is signed by the wallet, creating PoP(T).<br>
&gt;&gt; # The PoP is sent to the destination in 1.ii.<br>
&gt;&gt; # The server receiving the PoP validates it and responds with =E2=
=80=9Cvalid=E2=80=9D or<br>
&gt;&gt; =E2=80=9Cinvalid=E2=80=9D.<br>
&gt;&gt; # The wallet displays the response in some way to the user.<br>
&gt;&gt;<br>
&gt;&gt; &#39;&#39;&#39;Remarks:&#39;&#39;&#39;<br>
&gt;&gt;<br>
&gt;&gt; * The method of transferring the PoP request at step 1 is not spec=
ified<br>
&gt;&gt; here. Instead that is specified in separate specifications. See [b=
tcpop<br>
&gt;&gt; scheme BIP](btcpop scheme BIP).<br>
&gt;&gt; * The nonce must be randomly generated by the server for every new=
 PoP<br>
&gt;&gt; request.<br>
&gt;&gt;<br>
&gt;&gt; =3D=3D=3D Validating a PoP =3D=3D=3D<br>
&gt;&gt;<br>
&gt;&gt; The server needs to validate the PoP and reply with &quot;valid&qu=
ot; or &quot;invalid&quot;.<br>
&gt;&gt; That process is outlined below. If any step fails, the validation =
is aborted<br>
&gt;&gt; and &quot;invalid&quot; is returned:<br>
&gt;&gt;<br>
&gt;&gt; # Check the format of the PoP. It must pass normal transaction che=
cks,<br>
&gt;&gt; except that the inputs may already be spent.<br>
&gt;&gt; # Check that lock_time is 499999999.<br>
&gt;&gt; # Check that there is exactly one output. This output must have va=
lue 0<br>
&gt;&gt; and conform to the OP_RETURN output format outlined above.<br>
&gt;&gt; # Check that the nonce is the same as the one requested.<br>
&gt;&gt; # Check that the inputs of the PoP are exactly the same as in tran=
saction<br>
&gt;&gt; T, except that the sequence numbers must all be 0. The ordering of=
 the<br>
&gt;&gt; inputs must also be the same as in T.<br>
&gt;&gt; # Run the scripts of all the inputs. All scipts must return true.<=
br>
&gt;&gt; # Check that the txid in the PoP output is the transaction you act=
ually<br>
&gt;&gt; want proof for. If you don=E2=80=99t know exactly what transaction=
 you want proof<br>
&gt;&gt; for, check that the transaction actually pays for the product/serv=
ice you<br>
&gt;&gt; deliver.<br>
&gt;&gt; # Return &quot;valid&quot;.<br>
&gt;&gt;<br>
&gt;&gt; =3D=3D Security considerations =3D=3D<br>
&gt;&gt;<br>
&gt;&gt; * Someone can intercept the PoP-request and change any parameter i=
n it.<br>
&gt;&gt; These can be mitigated by using secure connections. For example:<b=
r>
&gt;&gt; ** Pop destination - Stealing your PoP.<br>
&gt;&gt; ** label - Trick you to sign an unintended pop or set a label that=
 your<br>
&gt;&gt; wallet doesn&#39;t have any record for, resulting in a broken serv=
ice. Always<br>
&gt;&gt; check the PoP before signing.<br>
&gt;&gt; ** nonce - Your pop will not validate on server.<br>
&gt;&gt; * Someone can steal a PoP, for example by tampering with the PoP r=
equest,<br>
&gt;&gt; and try to use the service hoping to get a matching nonce. Probabi=
lity per<br>
&gt;&gt; try: 1/(2^48). The server should have a mechanism for detecting a =
brute<br>
&gt;&gt; force attack of this kind, or at least slow down the process by de=
laying the<br>
&gt;&gt; PoP request by some 100 ms or so.<br>
&gt;&gt; * Even if a wallet has no funds it might still be valuable as a ge=
nerator<br>
&gt;&gt; for PoPs. This makes it important to keep the security of the wall=
et after<br>
&gt;&gt; it has been emptied.<br>
&gt;&gt; * Transaction malleability may cause the server to have another<br=
>
&gt;&gt; transaction id for a payment than the client&#39;s wallet. In that=
 case the<br>
&gt;&gt; wallet will not be able to prove the transaction to the server. Wa=
llets<br>
&gt;&gt; should not rely on the transaction id of the outgoing transaction.=
 Instead<br>
&gt;&gt; it should listen for the transaction on the network and put that i=
n its list<br>
&gt;&gt; of transactions.<br>
&gt;&gt;<br>
&gt;&gt; =3D=3D Reference implementation =3D=3D<br>
&gt;&gt;<br>
&gt;&gt; [<a href=3D"https://github.com/kallerosenbaum/poppoc" rel=3D"noref=
errer" target=3D"_blank">https://github.com/kallerosenbaum/poppoc</a> poppo=
c on GitHub]<br>
&gt;&gt;<br>
&gt;&gt; [<a href=3D"https://github.com/kallerosenbaum/wallet" rel=3D"noref=
errer" target=3D"_blank">https://github.com/kallerosenbaum/wallet</a> Mycel=
ium fork on GitHub]<br>
&gt;&gt;<br>
&gt;&gt; =3D=3D References =3D=3D<br>
&gt;&gt;<br>
&gt;&gt; [<a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0021.m=
ediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/b=
ips/blob/master/bip-0021.mediawiki</a> BIP0021]:<br>
&gt;&gt; URI Scheme<br>
&gt;&gt;<br>
&gt;&gt; [<a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0070.m=
ediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/b=
ips/blob/master/bip-0070.mediawiki</a> BIP0070]:<br>
&gt;&gt; Payment Protocol<br>
&gt;&gt;<br>
&gt;&gt; [[btcpop scheme BIP]]<br>
&gt;&gt;<br>
&gt;&gt; #########################################################<br>
&gt;&gt;<br>
&gt;&gt; 2015-06-06 23:25 GMT+02:00 Kalle Rosenbaum &lt;<a href=3D"mailto:k=
alle@rosenbaum.se">kalle@rosenbaum.se</a>&gt;:<br>
&gt;&gt; &gt; Thank you all for the feedback.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I will change the data structure as follows:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; * There will be only one output, the &quot;pop output&quot;, =
and no outputs from<br>
&gt;&gt; &gt; T will be copied to the PoP.<br>
&gt;&gt; &gt; * The pop output will have value 0.<br>
&gt;&gt; &gt; * The sequence number of all inputs of the PoP will be set to=
 0. I<br>
&gt;&gt; &gt; chose to set it to 0 for all inputs for simplicity.<br>
&gt;&gt; &gt; * The lock_time of the PoP is always set to 499999999.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Any comments on this?<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; /Kalle<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; 2015-06-06 19:00 GMT+02:00 Kalle Rosenbaum &lt;<a href=3D"mai=
lto:kalle@rosenbaum.se">kalle@rosenbaum.se</a>&gt;:<br>
&gt;&gt; &gt;&gt; 2015-06-06 18:10 GMT+02:00 Tom Harding &lt;<a href=3D"mai=
lto:tomh@thinlink.com">tomh@thinlink.com</a>&gt;:<br>
&gt;&gt; &gt;&gt;&gt; On Jun 6, 2015 8:05 AM, &quot;Kalle Rosenbaum&quot; &=
lt;<a href=3D"mailto:kalle@rosenbaum.se">kalle@rosenbaum.se</a>&gt; wrote:<=
br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt;&gt; I&#39;m open to changes here.<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; I suggest:<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; - Don&#39;t include any real outputs.=C2=A0 =C2=A0The=
y are redundant because the<br>
&gt;&gt; &gt;&gt;&gt; txid is<br>
&gt;&gt; &gt;&gt;&gt; already referenced.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; with the nLocktime solution, the copied outputs are not n=
eeded.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; - Start the proof script, which should be invalid, wi=
th a magic<br>
&gt;&gt; &gt;&gt;&gt; constant and<br>
&gt;&gt; &gt;&gt;&gt; include space for future expansion.=C2=A0 This makes =
PoP&#39;s easy to identify<br>
&gt;&gt; &gt;&gt;&gt; and<br>
&gt;&gt; &gt;&gt;&gt; extend.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; I did remore the constant (a &quot;PoP&quot; literal asci=
i encoded string)<br>
&gt;&gt; &gt;&gt; because it didn&#39;t add much. The recipient will expect=
 a pop, so it<br>
&gt;&gt; &gt;&gt; will simply treat it as one. I did add a 2 byte version f=
ield to make<br>
&gt;&gt; &gt;&gt; it extendable.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; - &quot;Proof of Potential&quot;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Noted :-)<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Thank you<br>
&gt;&gt; &gt;&gt; /Kalle<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; ------------------------------------------------------------------=
------------<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; Bitcoin-development mailing list<br>
&gt;&gt; <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitco=
in-development@lists.sourceforge.net</a><br>
&gt;&gt; <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment" rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.n=
et/lists/listinfo/bitcoin-development</a><br>
&gt;&gt;<br>
&gt;<br>
</blockquote></div>

--94eb2c064ab87f6e2e05188b882e--