[Bitcoin-development] Proof of Payment BIP-able?
Hi all! As indicated in my first email regarding Proof of Payment (Mars 13, subject Proof of Payment), I would like to BIP it. I have two proposals: * PoP datastructure and process: https://github.com/kallerosenbaum/poppoc/wiki/Proof-of-Payment * btcpop: URI scheme: https://github.com/kallerosenbaum/poppoc/wiki/btcpop-scheme Basically, my question to the community is: Do you agree that these are BIP-able? The proposals are not yet BIP formatted, but pretty complete. An implementation is avaliable at https://github.com/kallerosenbaum/poppoc. Specifically, the PoP validating code is in PopValidator.java https://github.com/kallerosenbaum/poppoc/blob/master/src/main/java/se/rosenbaum/poppoc/core/validate/PopValidator.java . As far as I can tell from the previous thread, no major objection against the idea was raised. PoP, if standardized, would bring a lot of utility to bitcoin: Paysite login, concert tickets, left luggage lockers, lotteries, video rental, etc. Further on, I'd like to extend BIP70 to support PoP, but that will have to wait until we have consensus around the two basic proposals above. I have received some great feedback from the community and included most of it in the updated version of the specification. The essential changes are: * If a PoP for some reason appears in the bitcoin p2p network, we must make sure that IF it is included in a block it should have minimal impact. The solution I chose was to include all outputs of the original paymet in the PoP. That way, if the PoP is included it will not alter the payees. (Thanks to Tom Harding for pointing out the problem and Magnus Andersson for the initial solution). * The check if the transaction is actually a tx that you want proof for is moved to later in the validation process. Otherwise, one could get information on what transactions pays for which services by simply sending erroneously signed PoPs with a transaction id we're interested in. * A version field of 2 bytes is included. Currently the only valid version is 0x00 0x01. (Thanks Martin Lie) * The PoP literal is removed. It provides little value as the receiver of a PoP expects a PoP. (Again, thanks Martin Lie for making me think about this.) Regards, Kalle Rosenbaum -- 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
Re: [Bitcoin-development] Proof of Payment
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 ka...@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 ka...@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 -- 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
Re: [Bitcoin-development] Proof of Payment
Forget it, sorry, I misunderstood the proposal entirely, re-reading with more care... On Tue, Apr 28, 2015 at 2:41 PM, Kalle Rosenbaum ka...@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 ka...@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 ka...@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 -- 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
Re: [Bitcoin-development] Proof of Payment
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 ka...@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 ka...@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 -- 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
Re: [Bitcoin-development] Proof of Payment
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
Re: [Bitcoin-development] Proof of Payment
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 ka...@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
Re: [Bitcoin-development] Proof of Payment
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. -- 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
Re: [Bitcoin-development] Proof of Payment
Hi Martin, Thank you very much for your comments. See my answers inline: Den 23 apr 2015 03:28 skrev Martin Lie mar...@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/5286github.com https://github.com/bitcoin/bitcoin/pull/5286/ https://github.com/bitcoin/bitcoin/pull/5286bitcoin https://github.com/bitcoin/bitcoin/pull/5286/ https://github.com/bitcoin/bitcoin/pull/5286bitcoin 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 -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proof of Payment
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 ka...@rosenbaum.se: Den 14 mar 2015 00:59 skrev Patrick Mccorry (PGR) patrick.mcco...@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 ka...@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.
Re: [Bitcoin-development] Proof of Payment
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 -- 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
Re: [Bitcoin-development] Proof of Payment
Den 14 mar 2015 00:59 skrev Patrick Mccorry (PGR) patrick.mcco...@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 ka...@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
Re: [Bitcoin-development] Proof of Payment
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. -- 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
[Bitcoin-development] Proof of Payment
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.
Re: [Bitcoin-development] Proof of Payment
Den 13 mar 2015 20:57 skrev Kalle Rosenbaum ka...@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. -- 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
Re: [Bitcoin-development] Proof of Payment
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? -- 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
Re: [Bitcoin-development] Proof of Payment
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 m...@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? -- 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
