[Bitcoin-development] Proof of Payment

[Bitcoin-development] Proof of Payment

[Kalle Rosenbaum]

[-- Attachment #1: Type: text/plain, Size: 6897 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 7238 bytes --]

Re: [Bitcoin-development] Proof of Payment

[Natanael]

[-- Attachment #1: Type: text/plain, Size: 2556 bytes --]

Den 13 mar 2015 20:57 skrev "Kalle Rosenbaum" <kalle@rosenbaum.se>:
>
> 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.).

Relevant: https://idemix.wordpress.com/

Anonymous Credentials allows an issuer to declare that you have certain
rights. For example, upon paying the service provider could issue you the
credentials for using their service up until a certain date.

When challenged to prove a statement about what credentials you have, you
can prove the fact that you've got the right credentials without revealing
anything else. You don't even reveal you're the same person as the last
time, if you prove the right to access a VPN multiple times there's no data
in it that links the different sessions together.

The main difference is that issuance of Anonymous Credentials aren't
"atomic" with the payment transactions, which can open up the risk for
certain types of dishonest behavior by the seller. You could however use a
proof in court of having paid for the credentials but not getting them
issued to you (maybe throw in usage of Factom to log issuance of
credentials?). With this construction of using both these methods, you add
stronger privacy for the usage of the services while simultaneously keeping
a degree of accountability for the payment.

The Zerocoin developers also got a paper on a blockchain version,
"Distributed Anonymous Credentials".

[-- Attachment #2: Type: text/html, Size: 2965 bytes --]

Re: [Bitcoin-development] Proof of Payment

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 855 bytes --]

Hi Kalle,

I think you're thinking along the right lines, but I am skeptical that this
protocol adds much. A saved payment request is meant to be unique per
transaction e.g. because the destination address is unique for that payment
(for privacy reasons). Where would you store the signed payment request?
Probably in the wallet. You could just extract the metadata that's useful
for UI rendering into a separate structure and then encrypt the original
full payment request under the wallet key. At least this is how I imagine
it would work.

So then, if someone can steal a payment request they can probably steal the
wallet signing keys too, and thus signing a challenge with the wallet keys
doesn't add much. It means the wallet doesn't have to store the
PaymentRequest encrypted. But AFAICT that's about all it does.

Do you agree with this analysis?

[-- Attachment #2: Type: text/html, Size: 1000 bytes --]

Re: [Bitcoin-development] Proof of Payment

[Kalle Rosenbaum]

[-- Attachment #1: Type: text/plain, Size: 1369 bytes --]

Hi

No I don't agree with the analysis.

Yes, the PaymentRequest can be stored with the same security as the private
keys are stored. The big difference is that the keys never leave the
wallet. As soon as that PaymentRequest leaves the wallet on its way to the
hotel server, it is up for grabs which makes it inappropriate for use as a
proof of payment other than for resolving disputes and other one-time stuff.

/Kalle


2015-03-13 22:31 GMT+01:00 Mike Hearn <mike@plan99.net>:

> Hi Kalle,
>
> I think you're thinking along the right lines, but I am skeptical that
> this protocol adds much. A saved payment request is meant to be unique per
> transaction e.g. because the destination address is unique for that payment
> (for privacy reasons). Where would you store the signed payment request?
> Probably in the wallet. You could just extract the metadata that's useful
> for UI rendering into a separate structure and then encrypt the original
> full payment request under the wallet key. At least this is how I imagine
> it would work.
>
> So then, if someone can steal a payment request they can probably steal
> the wallet signing keys too, and thus signing a challenge with the wallet
> keys doesn't add much. It means the wallet doesn't have to store the
> PaymentRequest encrypted. But AFAICT that's about all it does.
>
> Do you agree with this analysis?
>

[-- Attachment #2: Type: text/html, Size: 1888 bytes --]

Re: [Bitcoin-development] Proof of Payment

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 373 bytes --]

>
> As soon as that PaymentRequest leaves the wallet on its way to the hotel
> server, it is up for grabs
>

Is it? I'm assuming TLS is being used here. And the hotel server also has a
copy of the PaymentRequest, as the hotel actually issued it and that's how
they're deciding the receipt is valid. So I don't know how it could be
stolen unless the attacker can break TLS.

[-- Attachment #2: Type: text/html, Size: 637 bytes --]

Re: [Bitcoin-development] Proof of Payment

[Kalle Rosenbaum]

[-- Attachment #1: Type: text/plain, Size: 2088 bytes --]

>
> Actually, the security of the PaymetRequest is pretty much out of your
>> control as soon as the PaymentRequest is created on the server. You have no
>> idea what the hotel does with it. Also if it's stored in the hotel server I
>> have to trust the hotel to keep it safe for me.
>>
>
> Well, yes. But if the hotel itself is hacked then the whole process is
> meaningless, no? The hacker could just make the hotel think the proof of
> payment is correct even though it was never made at all, for instance.
>

Maybe the hotel example is not perfect for this discussion. Let's instead
assume that the server holds yearly subscriptions to some expensive video
service. If that service stores PaymentRequests for all their subscribers,
and accept them as proof of payment, that would be similar to storing
username and (possibly hashed) passwords for all subscribers. If all the
PaymentRequests for all users are stolen, then they have to shut down all
accounts if they discover the theft. If they don't discover the theft the
"accounts" are out in the wild, for sale, for blackmail, etc.

Wouldn't it be better if the service don't accept the reusable
PaymentRequests as proof, and instead accept a proof generated on demand,
at the very moment it is needed, and that it is only usable once? From a
usability perspective there is no difference; The users simply need access
the service and authorize the proof being sent to the server.


>
>
>> Another thing is that you assume BIP0070 is used for payments, which
>> isn't necessarily is the case.
>>
>
> It's just a convenient place to put things. There are lots of useful
> features that need BIP 70. I hope eventually all wallets will support it.
>

I also hope BIP0070 will take off. It would greatly improve the user
experience. But even then, all payments are not BIP0070. BIP0070 is
primarily for merchants who have the skills, time and money to use
certificates. I don't think a lottery at the local church would want to set
up a secure BIP0070 server, but they still might want to use bitcoin for
their lottery.

Regards,
Kalle

[-- Attachment #2: Type: text/html, Size: 3197 bytes --]

Re: [Bitcoin-development] Proof of Payment

[Kalle Rosenbaum]

[-- Attachment #1: Type: text/plain, Size: 9686 bytes --]

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: 11299 bytes --]

Re: [Bitcoin-development] Proof of Payment

[Kalle Rosenbaum]

[-- 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 --]

Re: [Bitcoin-development] Proof of Payment

[Kalle Rosenbaum]

[-- Attachment #1: Type: text/plain, Size: 3787 bytes --]

Hi Martin,

Thank you very much for your comments. See my answers inline:

Den 23 apr 2015 03:28 skrev "Martin Lie" <martin@datamagi.no>:
>
> Hej, Kalle.
>
> I love the idea of standardised PoPs, including a protocol for
requesting/sending them as an extension of BIP-70.
>

Me too!

>
> A couple of comments:
>
> 1. You admit that the txid is just a convenience and not strictly
necessary. Perhaps this should be reflected in the sequence of bits/bytes
in the record you're proposing, e.g. "OP_RETURN POP_LITERAL <nonce> <txid>"?
>

I was thinking that txid should be mandatory just as the nonce so the order
was arbitrarily chosen. I think you may be right that it's more intuitive
to put txid last if it's not mandatory in a future version. It makes sense
to swap order. I'll put that on my todo list.

> 2. Building on #1, perhaps there could be other identifying information
than a txid? Perhaps a txid field shouldn't be "hardcoded" into the
standard at all?
>
> How about taking the same approach as BIP-43 (and others) and use a
prefix that determines how the rest of the records should be interpreted,
i.e. a "type" (or "purpose" or "version" or whatever you'd like to call it)
field. This would allow for different purposes/versions of a PoP, including
as of now unforeseen ones.
>
> The new structure would then be:
> OP_RETURN POP_PREFIX POP_TYPE POP_NONCE POP_PAYLOAD
>
> POP_PREFIX (? bytes): I'll leave it up to you to specify the exact bits
(and length) of the POP_PREFIX, but if your literal is used, it'd be 3
bytes: 0x506f50.
>
> Literals in Bitcoin protocols generally seem to be of the "binary" sort
as opposed to human-readable text, so perhaps the devs wouldn't ACK
something as "wasteful" as using 3 bytes just to identify it as a PoP
record? Obviously, this is a small detail that can be changed at short
notice, but as with all standards - once people start using it, you're
mostly stuck with what you have. ;)
>

Yes, maybe we could drop POP_PREFIX altogether. The server is expecting a
pop and can therefore just assume it's a pop. No need to explicitly write
that inside the pop. Can you think of a scenario where it is actually
needed. Keeping the POP_PREFIX makes sense only if other transaction-like
data structures with OP_RETURN appears in the same contexts as pops. What
do you think?

> POP_TYPE: (1 byte): 0x01 for your "standard" version, which would mean
that the payload contains a txid.
>

This is a good idea. Todo!

> POP_NONCE: (4 bytes): "2^32 re-uses should be enough for everyone", no? ;)
>

Euhm, well, I don't know... The bigger the better. If we drop POP_PREFIX we
could allow for 2 bytes version and 6 bytes nonce. Or 1 byte version and 7
bytes nonce.

> POP_PAYLOAD (32+ bytes): The contents of which is determined by POP_TYPE,
e.g. a txid or possibly extra nonce data. Or perhaps some text that makes
the purpose or context of this PoP human-readable? (This could then be
stored by wallets in order to show a list of what kind of proofs you've
sent.)
>

For now I think I'll stick to "txid is mandatory".

>
> 3. I noticed that your post-OP_RETURN structure included exactly 40
bytes. Is that due to the 40-byte limitation on OP_RETURN's "data"? Are you
aware that it will be increased to 80 bytes? Cf. https://
<https://github.com/bitcoin/bitcoin/pull/5286>github.com
<https://github.com/bitcoin/bitcoin/pull/5286>/
<https://github.com/bitcoin/bitcoin/pull/5286>bitcoin
<https://github.com/bitcoin/bitcoin/pull/5286>/
<https://github.com/bitcoin/bitcoin/pull/5286>bitcoin
<https://github.com/bitcoin/bitcoin/pull/5286>/pull/5286
<https://github.com/bitcoin/bitcoin/pull/5286>
>

Yes, I deliberately limited the data to 40 bytes for that reason. With
versioning, this may change in the future.

> :)
>
>
> Vennlig hilsen
> Martin Lie

[-- Attachment #2: Type: text/html, Size: 4656 bytes --]

Re: [Bitcoin-development] Proof of Payment

[Tom Harding]

On 4/22/2015 1:03 PM, Kalle Rosenbaum wrote:
>
> 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.
>
>
>     >> 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.
>

Kalle,

You propose a standard format for proving that wallet-controlled funds
COULD HAVE BEEN spent as they were in a real transaction.  Standardized
PoP would give wallets a new way to communicate with the outside world.

PoP could allow payment and delivery to be separated in time in a
standard way, without relying on a mechanism external to bitcoin's
cryptosystem, and enable standardized real-world scenarios where sender
!= beneficiary, and/or receiver != provider.

Payment:
sender -> receiver

Delivery:
beneficiary <- provider

Some more use cases might be:
Waiting in comfort:
 - Send a payment ahead of time, then wander over and collect the goods
after X confirmations.

Authorized pickup :
 - Hot wallet software used by related people could facilitate the use
of 1 of N multisig funds.  Any one of the N wallets could collect goods
and services purchased by any of the others.

Non-monetary gifts:
 - Sender exports spent keys to a beneficiary, enabling PoP to work as a
gift claim

Contingent services:
 - Without Bob's permission, a 3rd party conditions action on a payment
made from Alice to Bob.  For example, if you donated at least .02 BTC to
Dorian, you (or combining scenarios, any of your N authorized family
members), can come to my dinner party.

I tried out your demo wallet and service and it worked as advertised.

Could the same standard also be used to prove that a transaction COULD
BE created?  To generalize the concept beyond actual payments, you could
call it something like proof of payment potential.

Why not make these proofs permanently INVALID transactions, to remove
any possibility of their being mined and spending everything to fees
when used in this way, and also in cases involving reorganizations?

I agree that PoP seems complementary to BIP70.

Re: [Bitcoin-development] Proof of Payment

[Kalle Rosenbaum]

[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]

>
> Some more use cases might be:
> Waiting in comfort:
>  - Send a payment ahead of time, then wander over and collect the goods
> after X confirmations.
>
> Authorized pickup :
>  - Hot wallet software used by related people could facilitate the use
> of 1 of N multisig funds.  Any one of the N wallets could collect goods
> and services purchased by any of the others.

I like this one, because it shows the power of reusing the transaction data
structure.

>
> Non-monetary gifts:
>  - Sender exports spent keys to a beneficiary, enabling PoP to work as a
> gift claim
>
> Contingent services:
>  - Without Bob's permission, a 3rd party conditions action on a payment
> made from Alice to Bob.  For example, if you donated at least .02 BTC to
> Dorian, you (or combining scenarios, any of your N authorized family
> members), can come to my dinner party.

This is an interesting one.

>
> I tried out your demo wallet and service and it worked as advertised.
>
> Could the same standard also be used to prove that a transaction COULD
> BE created?  To generalize the concept beyond actual payments, you could
> call it something like proof of payment potential.

I guess it's possible, but we'd have to remove the txid from the output,
since there is none. This is a way of saying "I'm in control of these
addresses". The other party/parties can then verify the funds on the
blockchain and watch those addresses for changes. Maybe there are some
interesting use cases here. Ideas?

>
> Why not make these proofs permanently INVALID transactions, to remove
> any possibility of their being mined and spending everything to fees
> when used in this way, and also in cases involving reorganizations?

Yes. Initially I thought it would be enough that the funds are already
spent, but I think you're right here. Reorgs could be a problem. Worse, you
also might want to prove 0-confirmation transactions, in which case it's a
huge security problem. Someone might intercept the PoP and publish it on
the bitcoin network, spending all the funds. But I still would like wallets
to be able to build/verify PoPs with little or no modifications. Could we
possibly change the version number on the PoP to something other than 1?
Maybe 2^4-1? Or a really high lock_time, but it would not make it invalid,
just delayed. Any suggestions here?

>
> I agree that PoP seems complementary to BIP70.
>
>

Thank you very much for your comments!

/Kalle

[-- Attachment #2: Type: text/html, Size: 2914 bytes --]

Re: [Bitcoin-development] Proof of Payment

[Kalle Rosenbaum]

[-- Attachment #1: Type: text/plain, Size: 2783 bytes --]

"Or a really high lock_time, but it would not make it invalid, just
delayed."

Ok, this was a bad idea, since nodes would have to keep it in memory.
Please disregard that idea...

Kalle

Den 27 apr 2015 14:35 skrev "Kalle Rosenbaum" <kalle@rosenbaum.se>:
>
> >
> > Some more use cases might be:
> > Waiting in comfort:
> >  - Send a payment ahead of time, then wander over and collect the goods
> > after X confirmations.
> >
> > Authorized pickup :
> >  - Hot wallet software used by related people could facilitate the use
> > of 1 of N multisig funds.  Any one of the N wallets could collect goods
> > and services purchased by any of the others.
>
> I like this one, because it shows the power of reusing the transaction
data structure.
>
> >
> > Non-monetary gifts:
> >  - Sender exports spent keys to a beneficiary, enabling PoP to work as a
> > gift claim
> >
> > Contingent services:
> >  - Without Bob's permission, a 3rd party conditions action on a payment
> > made from Alice to Bob.  For example, if you donated at least .02 BTC to
> > Dorian, you (or combining scenarios, any of your N authorized family
> > members), can come to my dinner party.
>
> This is an interesting one.
>
> >
> > I tried out your demo wallet and service and it worked as advertised.
> >
> > Could the same standard also be used to prove that a transaction COULD
> > BE created?  To generalize the concept beyond actual payments, you could
> > call it something like proof of payment potential.
>
> I guess it's possible, but we'd have to remove the txid from the output,
since there is none. This is a way of saying "I'm in control of these
addresses". The other party/parties can then verify the funds on the
blockchain and watch those addresses for changes. Maybe there are some
interesting use cases here. Ideas?
>
> >
> > Why not make these proofs permanently INVALID transactions, to remove
> > any possibility of their being mined and spending everything to fees
> > when used in this way, and also in cases involving reorganizations?
>
> Yes. Initially I thought it would be enough that the funds are already
spent, but I think you're right here. Reorgs could be a problem. Worse, you
also might want to prove 0-confirmation transactions, in which case it's a
huge security problem. Someone might intercept the PoP and publish it on
the bitcoin network, spending all the funds. But I still would like wallets
to be able to build/verify PoPs with little or no modifications. Could we
possibly change the version number on the PoP to something other than 1?
Maybe 2^4-1? Or a really high lock_time, but it would not make it invalid,
just delayed. Any suggestions here?
>
> >
> > I agree that PoP seems complementary to BIP70.
> >
> >
>
> Thank you very much for your comments!
>
> /Kalle

[-- Attachment #2: Type: text/html, Size: 3472 bytes --]

Re: [Bitcoin-development] Proof of Payment

[Jorge Timón]

[-- Attachment #1: Type: text/plain, Size: 3799 bytes --]

So at the low level, how does a "proof of payment" differ from just proving
that a given transaction is in a given block (what SPV nodes take as proof
of payment today)?
On Apr 27, 2015 2:42 PM, "Kalle Rosenbaum" <kalle@rosenbaum.se> wrote:

> "Or a really high lock_time, but it would not make it invalid, just
> delayed."
>
> Ok, this was a bad idea, since nodes would have to keep it in memory.
> Please disregard that idea...
>
> Kalle
>
> Den 27 apr 2015 14:35 skrev "Kalle Rosenbaum" <kalle@rosenbaum.se>:
> >
> > >
> > > Some more use cases might be:
> > > Waiting in comfort:
> > >  - Send a payment ahead of time, then wander over and collect the goods
> > > after X confirmations.
> > >
> > > Authorized pickup :
> > >  - Hot wallet software used by related people could facilitate the use
> > > of 1 of N multisig funds.  Any one of the N wallets could collect goods
> > > and services purchased by any of the others.
> >
> > I like this one, because it shows the power of reusing the transaction
> data structure.
> >
> > >
> > > Non-monetary gifts:
> > >  - Sender exports spent keys to a beneficiary, enabling PoP to work as
> a
> > > gift claim
> > >
> > > Contingent services:
> > >  - Without Bob's permission, a 3rd party conditions action on a payment
> > > made from Alice to Bob.  For example, if you donated at least .02 BTC
> to
> > > Dorian, you (or combining scenarios, any of your N authorized family
> > > members), can come to my dinner party.
> >
> > This is an interesting one.
> >
> > >
> > > I tried out your demo wallet and service and it worked as advertised.
> > >
> > > Could the same standard also be used to prove that a transaction COULD
> > > BE created?  To generalize the concept beyond actual payments, you
> could
> > > call it something like proof of payment potential.
> >
> > I guess it's possible, but we'd have to remove the txid from the output,
> since there is none. This is a way of saying "I'm in control of these
> addresses". The other party/parties can then verify the funds on the
> blockchain and watch those addresses for changes. Maybe there are some
> interesting use cases here. Ideas?
> >
> > >
> > > Why not make these proofs permanently INVALID transactions, to remove
> > > any possibility of their being mined and spending everything to fees
> > > when used in this way, and also in cases involving reorganizations?
> >
> > Yes. Initially I thought it would be enough that the funds are already
> spent, but I think you're right here. Reorgs could be a problem. Worse, you
> also might want to prove 0-confirmation transactions, in which case it's a
> huge security problem. Someone might intercept the PoP and publish it on
> the bitcoin network, spending all the funds. But I still would like wallets
> to be able to build/verify PoPs with little or no modifications. Could we
> possibly change the version number on the PoP to something other than 1?
> Maybe 2^4-1? Or a really high lock_time, but it would not make it invalid,
> just delayed. Any suggestions here?
> >
> > >
> > > I agree that PoP seems complementary to BIP70.
> > >
> > >
> >
> > Thank you very much for your comments!
> >
> > /Kalle
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 4880 bytes --]

Re: [Bitcoin-development] Proof of Payment

[Kalle Rosenbaum]

[-- Attachment #1: Type: text/plain, Size: 4056 bytes --]

Hi Jorge,

I don't think I understand the question. Proof of Payment is used to prove
that you have the credentials needed for a certain transaction. It does not
care where in the blockchain the transaction is. Or if it's in the
blockchain at all.

/Kalle

So at the low level, how does a "proof of payment" differ from just proving
that a given transaction is in a given block (what SPV nodes take as proof
of payment today)?
On Apr 27, 2015 2:42 PM, "Kalle Rosenbaum" <kalle@rosenbaum.se> wrote:

> "Or a really high lock_time, but it would not make it invalid, just
> delayed."
>
> Ok, this was a bad idea, since nodes would have to keep it in memory.
> Please disregard that idea...
>
> Kalle
>
> Den 27 apr 2015 14:35 skrev "Kalle Rosenbaum" <kalle@rosenbaum.se>:
> >
> > >
> > > Some more use cases might be:
> > > Waiting in comfort:
> > >  - Send a payment ahead of time, then wander over and collect the goods
> > > after X confirmations.
> > >
> > > Authorized pickup :
> > >  - Hot wallet software used by related people could facilitate the use
> > > of 1 of N multisig funds.  Any one of the N wallets could collect goods
> > > and services purchased by any of the others.
> >
> > I like this one, because it shows the power of reusing the transaction
> data structure.
> >
> > >
> > > Non-monetary gifts:
> > >  - Sender exports spent keys to a beneficiary, enabling PoP to work as
> a
> > > gift claim
> > >
> > > Contingent services:
> > >  - Without Bob's permission, a 3rd party conditions action on a payment
> > > made from Alice to Bob.  For example, if you donated at least .02 BTC
> to
> > > Dorian, you (or combining scenarios, any of your N authorized family
> > > members), can come to my dinner party.
> >
> > This is an interesting one.
> >
> > >
> > > I tried out your demo wallet and service and it worked as advertised.
> > >
> > > Could the same standard also be used to prove that a transaction COULD
> > > BE created?  To generalize the concept beyond actual payments, you
> could
> > > call it something like proof of payment potential.
> >
> > I guess it's possible, but we'd have to remove the txid from the output,
> since there is none. This is a way of saying "I'm in control of these
> addresses". The other party/parties can then verify the funds on the
> blockchain and watch those addresses for changes. Maybe there are some
> interesting use cases here. Ideas?
> >
> > >
> > > Why not make these proofs permanently INVALID transactions, to remove
> > > any possibility of their being mined and spending everything to fees
> > > when used in this way, and also in cases involving reorganizations?
> >
> > Yes. Initially I thought it would be enough that the funds are already
> spent, but I think you're right here. Reorgs could be a problem. Worse, you
> also might want to prove 0-confirmation transactions, in which case it's a
> huge security problem. Someone might intercept the PoP and publish it on
> the bitcoin network, spending all the funds. But I still would like wallets
> to be able to build/verify PoPs with little or no modifications. Could we
> possibly change the version number on the PoP to something other than 1?
> Maybe 2^4-1? Or a really high lock_time, but it would not make it invalid,
> just delayed. Any suggestions here?
> >
> > >
> > > I agree that PoP seems complementary to BIP70.
> > >
> > >
> >
> > Thank you very much for your comments!
> >
> > /Kalle
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 5352 bytes --]

Re: [Bitcoin-development] Proof of Payment

[Jorge Timón]

Forget it, sorry, I misunderstood the proposal entirely, re-reading
with more care...

On Tue, Apr 28, 2015 at 2:41 PM, Kalle Rosenbaum <kalle@rosenbaum.se> wrote:
> Hi Jorge,
>
> I don't think I understand the question. Proof of Payment is used to prove
> that you have the credentials needed for a certain transaction. It does not
> care where in the blockchain the transaction is. Or if it's in the
> blockchain at all.
>
> /Kalle
>
> So at the low level, how does a "proof of payment" differ from just proving
> that a given transaction is in a given block (what SPV nodes take as proof
> of payment today)?
>
> On Apr 27, 2015 2:42 PM, "Kalle Rosenbaum" <kalle@rosenbaum.se> wrote:
>>
>> "Or a really high lock_time, but it would not make it invalid, just
>> delayed."
>>
>> Ok, this was a bad idea, since nodes would have to keep it in memory.
>> Please disregard that idea...
>>
>> Kalle
>>
>> Den 27 apr 2015 14:35 skrev "Kalle Rosenbaum" <kalle@rosenbaum.se>:
>> >
>> > >
>> > > Some more use cases might be:
>> > > Waiting in comfort:
>> > >  - Send a payment ahead of time, then wander over and collect the
>> > > goods
>> > > after X confirmations.
>> > >
>> > > Authorized pickup :
>> > >  - Hot wallet software used by related people could facilitate the use
>> > > of 1 of N multisig funds.  Any one of the N wallets could collect
>> > > goods
>> > > and services purchased by any of the others.
>> >
>> > I like this one, because it shows the power of reusing the transaction
>> > data structure.
>> >
>> > >
>> > > Non-monetary gifts:
>> > >  - Sender exports spent keys to a beneficiary, enabling PoP to work as
>> > > a
>> > > gift claim
>> > >
>> > > Contingent services:
>> > >  - Without Bob's permission, a 3rd party conditions action on a
>> > > payment
>> > > made from Alice to Bob.  For example, if you donated at least .02 BTC
>> > > to
>> > > Dorian, you (or combining scenarios, any of your N authorized family
>> > > members), can come to my dinner party.
>> >
>> > This is an interesting one.
>> >
>> > >
>> > > I tried out your demo wallet and service and it worked as advertised.
>> > >
>> > > Could the same standard also be used to prove that a transaction COULD
>> > > BE created?  To generalize the concept beyond actual payments, you
>> > > could
>> > > call it something like proof of payment potential.
>> >
>> > I guess it's possible, but we'd have to remove the txid from the output,
>> > since there is none. This is a way of saying "I'm in control of these
>> > addresses". The other party/parties can then verify the funds on the
>> > blockchain and watch those addresses for changes. Maybe there are some
>> > interesting use cases here. Ideas?
>> >
>> > >
>> > > Why not make these proofs permanently INVALID transactions, to remove
>> > > any possibility of their being mined and spending everything to fees
>> > > when used in this way, and also in cases involving reorganizations?
>> >
>> > Yes. Initially I thought it would be enough that the funds are already
>> > spent, but I think you're right here. Reorgs could be a problem. Worse, you
>> > also might want to prove 0-confirmation transactions, in which case it's a
>> > huge security problem. Someone might intercept the PoP and publish it on the
>> > bitcoin network, spending all the funds. But I still would like wallets to
>> > be able to build/verify PoPs with little or no modifications. Could we
>> > possibly change the version number on the PoP to something other than 1?
>> > Maybe 2^4-1? Or a really high lock_time, but it would not make it invalid,
>> > just delayed. Any suggestions here?
>> >
>> > >
>> > > I agree that PoP seems complementary to BIP70.
>> > >
>> > >
>> >
>> > Thank you very much for your comments!
>> >
>> > /Kalle
>>
>>
>>
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>