Kalle Rosenbaum [ARCHIVE] on Nostr: đź“… Original date posted:2015-03-13 đź“ť Original message:Hi all, I've been thinking ...
đź“… Original date posted:2015-03-13
đź“ť Original message: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:
1. A PoP should be generated on demand.
2. It should only be usable once to avoid issues due to theft.
3. 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*
1. A proof of payment request is sent from the server to the wallet. The
request contains:
1. a random nonce
2. a destination where to send the PoP, for example a https URL
3. 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
2. The wallet identifies the transaction T, if possible. Otherwise
asks the user to select among the ones that fit the hints in 1.3.
3. The wallet checks that T is on the blockchain, meaning all the inputs
are spent.
4. The wallet creates an unsigned PoP (UPoP) for T, and asks the user to
sign it.
5. The user confirms
6. The UPoP(T) is signed by the wallet, creating PoP(T).
7. The PoP is sent to the destination in 1.2.
8. The server receiving the PoP validates it and responds with “valid”
or “invalid”
9. 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:
1. Check the format of the PoP. It must pass normal transaction checks,
except for the inputs being already spent.
2. Check the output script. It must conform to the OP_RETURN output
format outlined above.
3. Check that the nonce is the same as the one you requested.
4. 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).
5. Check that the inputs of the PoP are exactly the same as in
transaction T.
6. Check the signatures of all the inputs, as would be done on a normal
transaction.
7. 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150313/0c9b5dab/attachment.html>;
đź“ť Original message: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:
1. A PoP should be generated on demand.
2. It should only be usable once to avoid issues due to theft.
3. 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*
1. A proof of payment request is sent from the server to the wallet. The
request contains:
1. a random nonce
2. a destination where to send the PoP, for example a https URL
3. 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
2. The wallet identifies the transaction T, if possible. Otherwise
asks the user to select among the ones that fit the hints in 1.3.
3. The wallet checks that T is on the blockchain, meaning all the inputs
are spent.
4. The wallet creates an unsigned PoP (UPoP) for T, and asks the user to
sign it.
5. The user confirms
6. The UPoP(T) is signed by the wallet, creating PoP(T).
7. The PoP is sent to the destination in 1.2.
8. The server receiving the PoP validates it and responds with “valid”
or “invalid”
9. 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:
1. Check the format of the PoP. It must pass normal transaction checks,
except for the inputs being already spent.
2. Check the output script. It must conform to the OP_RETURN output
format outlined above.
3. Check that the nonce is the same as the one you requested.
4. 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).
5. Check that the inputs of the PoP are exactly the same as in
transaction T.
6. Check the signatures of all the inputs, as would be done on a normal
transaction.
7. 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150313/0c9b5dab/attachment.html>;