From: Kalle Rosenbaum <kalle@rosenbaum•se>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Proof of Payment
Date: Wed, 22 Apr 2015 22:03:47 +0200 [thread overview]
Message-ID: <CAPswA9wZk_8EjbN8J-VbMGQ6nrZ7SthopJ=HYMtpxhSCsm_neA@mail.gmail.com> (raw)
In-Reply-To: <CAPswA9wNS2J=4YhpqWN8SmzJuUF8mek8XLUYTE+twLX9vM4Jhg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 11999 bytes --]
Hi again
I've built a proof-of-concept for Proof of Payment. It's available at
http://www.rosenbaum.se:8080. The site contains links to the source code
for both the server and a Mycelium fork as well as pre-built apk:s.
I'm still very interested in feedback on this, so please let me know what
you think.
Stuff that has come up so far, and my answers:
* Some people think it's too complicated. I disagree. Using transactions as
the data structure actually makes it simple to implement both on the server
and in wallets. Just use existing wallet software to sign and verify PoPs.
* Other ideas on Proof of Payment use a single key from the proven
transaction, for example the first key from the first input of the
transaction. This is problematic when multisig and other P2SH transactions
are used. I also think that it's necessary to use *all* credentials used
for the transaction. Otherwise we wouldn't be sure that the sender actually
have all the needed credentials.
* Another suggestion is that a payment request from BIP70 is used as proof.
That is possible, but it's reusable which makes it inappropriate to send
over networks; If it is stolen somewhere, anyone can use it as many times
they like. As stated in BIP70, the payment request is suitable for dispute
resolution, more like a receipt. On the other hand, I think that PoP would
fit nicely into the workflow of BIP70: a) Read a url for the PoP request,
b) get the (possibly signed) PoP request. c) send the PoP through http POST
to the URL in the PoP request, d) profit!
* A thought of my own: The txid used in the PoP output is not strictly
necessary. It's more of a convenience for the verifier of the PoP. Without
it, the verifier would need to lookup the transaction based on the inputs
of the PoP,
Regards,
Kalle Rosenbaum
2015-03-14 19:16 GMT+01:00 Kalle Rosenbaum <kalle@rosenbaum•se>:
> Den 14 mar 2015 00:59 skrev "Patrick Mccorry (PGR)" <
> patrick.mccorry@newcastle•ac.uk>:
> >
> > That all seems more complicated than it needs to be - the service you
> are paying knows that it had received a payment from some public key Q
> (regardless of script type, as all scripts require a public key).
>
> The service knows it had received a payment from Q1, Q2,...,Qn. A tx may
> have multiple inputs and each input may have several public keys.
>
> >
> > So I want to rent a movie, they send me a challenge and I respond with a
> zero knowledge proof to demonstrate that I am the owner of Q, and as they
> know that Q made a payment - then there is a proof of payment - as this is
> provided by the time stamped transaction on the blockchain - in this sense
> you are bootstrapping trust from the blockchain.
> >
>
> Ok. Without knowing much about zero knowledge proof, i guess you'd need a
> challenge/response for each of the keys Q1,..,Qn. If we settle on only a
> single key, what key from what input should we use? One input may be a
> multisig (2 of 3) input. Is it ok to settle on only one of the multisig
> keys? Probably not. I'd say that we need 2 of 3 signatures (just as in a
> bitcoin transaction), and not necessarily the same two that made the
> payment.
>
> > For all of your scenarios, a simple challenge-response scheme would
> work. Adding an op_return makes the payment transaction worse as it is now
> distinguishable on the blockchain - you want use information that is
> already available on that transaction.
>
> I'm not sure I follow. Do you mean that it's a problem that the PoP itself
> reveals what transaction I'm proving? Well, maybe it is a problem under
> some circumstances. The least you can do to protect yourself from revealing
> information to third party is to communicate over secure channels. Could
> you please elaborate on this?
>
> Anyway, if both the client and the server knows what transaction to prove
> (ad-sign example) you are right that the tx info is kind of redundant. But
> if we don't send the tx hints from server to client, the client user must
> manually select the transaction to prove which makes the user experience
> worse.
>
> Thank you very much for your comments,
>
> /Kalle
>
> >
> > Sent from my iPhone
> >
> > On 13 Mar 2015, at 19:58, Kalle Rosenbaum <kalle@rosenbaum•se> wrote:
> >
> >> Hi all,
> >>
> >> I've been thinking about how a person can prove that she has made a
> payment. I came up with an idea I call Proof of Payment (PoP) and I would
> highly appreciate your comments. Has something like this been discussed
> somewhere before?
> >>
> >> Use cases
> >>
> >> 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.
> >> A lottery where all participants pay to the same address, and the
> winner of the T-shirt is selected among the transactions to that address.
> You exchange the T-shirt for a PoP for the winning transaction.
> >>
> >> These use cases can be achieved without any personal information (no
> accounts, no e-mails, etc) being involved.
> >>
> >> 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.).
> >> Current methods of proving a payment, as I know of:
> >> BIP0070, The PaymentRequest together with the transactions fulfilling
> the payment makes some sort of proof. However, it does not meet 1 or 2 and
> it obviously only meets 3 if the payment is made through BIP0070. Also,
> there's no standard way to request/provide the proof.
> >> Signing messages, chosen by the entity that the proof is provided to,
> with the private keys used to sign the transaction. This could meet 1 and 2
> but probably not 3. This is not standardized either.
> >> Proof of Payment, the data structure
> >>
> >> A proof of payment for a transaction T, 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 with a single OP_RETURN output:
> >>
> >> OP_RETURN PoP <txid> <nonce>
> >>
> >> | Field | Size [B] | Description |
> >> |-----------|----------|------------------------------------|
> >> | PoP | 3 | Literal identifying this as a PoP |
> >> | <txid> | 32 | The transaction to Prove |
> >> | <nonce> | 5 | Unsigned integer |
> >>
> >> 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 destination, that PoP is useless
> since the destination will generate a new nonce for every PoP.
> >>
> >> Proof of Payment, the process
> >> A proof of payment request is sent from the server to the wallet. The
> request contains:
> >> a random nonce
> >> a destination where to send the PoP, for example a https URL
> >> data hinting the wallet which transaction to create a proof for. For
> example:
> >> txid, if known by the server
> >> PaymentRequest.PaymentDetails.merchant_data (in case of a BIP0070
> payment)
> >> amount
> >> label, message or other information from a BIP0021 URL
> >> The wallet identifies the transaction T, if possible. Otherwise asks
> the user to select among the ones that fit the hints in 1.3.
> >> The wallet checks that T is on the blockchain, meaning all the inputs
> are spent.
> >> 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.2.
> >> The server receiving the PoP validates it and responds with “valid” or
> “invalid”
> >> The wallet displays the response in some way to the user.
> >> Remarks:
> >> The method of transferring the PoP request at step 1 is not very well
> thought through, but I think we can extend BIP0021 to cater for this. For
> example read a URI, representing a PoP request, using QR code or NFC. A
> more advanced approach would be to extend BIP0070.
> >> The nonce must be randomly generated by the server for every new PoP
> request.
> >> Validating a PoP
> >>
> >> The server needs to validate the PoP and reply with “valid” or
> “invalid”. That process is outlined below:
> >> Check the format of the PoP. It must pass normal transaction checks,
> except for the inputs being already spent.
> >> Check the output script. It must conform to the OP_RETURN output format
> outlined above.
> >> Check that the nonce is the same as the one you requested.
> >> Check that the txid in the output is the transaction you actually want
> proof for. If you don’t know what transaction you want proof for, check
> that the transaction actually pays for the product/service you deliver (in
> the video rental case, find the transaction among all payments for that
> specific video).
> >> Check that the inputs of the PoP are exactly the same as in transaction
> T.
> >> Check the signatures of all the inputs, as would be done on a normal
> transaction.
> >> If the signatures are valid, the PoP is valid.
> >> Security issues
> >> Someone can intercept the PoP-request and change the destination so
> that the user sends the PoP to the bad actor.
> >> Someone can intercept the PoP-request and change for example the txid
> to trick the user to sign a PoP for another transaction than the intended.
> This can of course be avoided by actually looking at the UPoP before
> signing it. The bad actor could also set hints for a transaction that the
> user didn’t make, resulting in a broken service.
> >> Someone can steal a PoP and try to use the service hoping to get a
> matching nonce. Probability per try: 1/(2^40). The server should have
> 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.
> >> The first two issues are the same as for traditional bitcoin payments.
> They could be mitigated by using secure connections and possibly also
> extending BIP0070 to support PoPs.
> >>
> >> Further work
> >> Figure out how to make use of, and extend, BIP0070 for the purpose of
> PoPs
> >> Define an extension for BIP0021 to support PoP requests (something
> along the lines of BIP0072)
> >> Implement a proof-of-concept
> >> Possibly propose BIPs for the different parts.
> >> Looking forward to reading your comments
> >> Regards,
> >> Kalle Rosenbaum
> >>
> >>
> ------------------------------------------------------------------------------
> >> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> >> by Intel and developed in partnership with Slashdot Media, is your hub
> for all
> >> things parallel software development, from weekly thought leadership
> blogs to
> >> news, videos, case studies, tutorials and more. Take a look and join
> the
> >> conversation now. http://goparallel.sourceforge.net/
> >>
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development@lists•sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 13784 bytes --]
next prev parent reply other threads:[~2015-04-22 20:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-13 19:29 Kalle Rosenbaum
2015-03-13 20:30 ` Natanael
2015-03-13 21:31 ` Mike Hearn
2015-03-13 21:47 ` Kalle Rosenbaum
2015-03-13 22:03 ` Mike Hearn
[not found] ` <CAPswA9y5bDs1urRCmh8Oxeho4As8pBt2rRVP6fjhjJA0cZrvfA@mail.gmail.com>
[not found] ` <CANEZrP35_h_-2c=A-1+M8umSpAC70DJ7sYhPPo_62dm2QKHCEg@mail.gmail.com>
2015-03-14 9:28 ` Kalle Rosenbaum
[not found] ` <A2849710-1069-45A1-89C0-9D8E40C4A8D6@newcastle.ac.uk>
2015-03-14 18:16 ` Kalle Rosenbaum
2015-04-22 20:03 ` Kalle Rosenbaum [this message]
[not found] ` <55384AC9.80501@datamagi.no>
2015-04-23 14:39 ` Kalle Rosenbaum
2015-04-27 0:50 ` Tom Harding
2015-04-27 12:35 ` Kalle Rosenbaum
2015-04-27 12:41 ` Kalle Rosenbaum
2015-04-28 7:23 ` Jorge Timón
2015-04-28 12:41 ` Kalle Rosenbaum
2015-04-28 12:53 ` Jorge Timón
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPswA9wZk_8EjbN8J-VbMGQ6nrZ7SthopJ=HYMtpxhSCsm_neA@mail.gmail.com' \
--to=kalle@rosenbaum$(echo .)se \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox