Re: [Bitcoin-development] BIP for Proof of Payment
2015-06-16 21:48 GMT+02:00 Pieter Wuille pieter.wui...@gmail.com: I don't see why existing software could create a 40-byte OP_RETURN but not larger? The limitation comes from a relay policy in full nodes, not a limitation is wallet software... and PoPs are not relayed on the network. You are probably right here. The thing is that I don't know how *all* wallet signing and validating software is written, so I figure it's better to stick to a valid output. Since I don't *need* more data than 40 bytes, why bother. There's another constraint to this as well: The other BIP proposal, Proof of Payment URI scheme, includes a nonce parameter in the URI. If the nonce is very long, the QR code will be unnecessarily big. The server should try to detect a brute force of the 48 bit nonce, or at least delay the pop requests by some 100 ms or so. Do you think this is an actual problem, and why? Is your suggestion to use a bigger nonce, given the above? Regarding sharing, I think you're talking about a different use case. Say you want to pay for 1-week valid entrance to some venue. I thought the purpose of the PoP was to be sure that only the person who paid for it, and not anyone else can use it during that week. That's right. That's one use case. You pay for the 1-week entrance and then you use your wallet to sign PoPs when you enter the venue. My argument against that is that the original payer can also hand the private keys in his wallet to someone else, who would then become able to create PoPs for the service. He does not lose anything by this, assuming the address is not reused. Yes, that is possible. It's about the same as giving out a username/password for a service that you have paid for. In the case of a concert ticket, it's simple. Just allow one entrance per payment. But in the example you gave, it's a bit more complicated. You could for example give all guests a bracelet upon first entry or upon first exit. Or you can put a stamp on people leaving the venue, and demand that all re-entries show the stamp, possibly along with a new PoP. Pretty much as is done already. Different use cases will need different protection. In this example, the value added by PoP is that the venue does not have to distribute tickets in advance. This in turn allows for better privacy for the customer, who don't have to give out personal information such as an email-address. So, using a token does not change anything, except it can be provided to the payer - instead of relying on creating an implicit identity based on who seems to have held particular private keys in the past. Yes, that's a difference, but it comes at the cost of security. The stolen token can be used over and over. In the case of PoP it's only usable once, and it's only created when it's actually needed, minimizing the window of opportunity for the thief. Regards, Kalle On Jun 16, 2015 9:41 PM, Kalle Rosenbaum ka...@rosenbaum.se wrote: 2015-06-16 21:25 GMT+02:00 Pieter Wuille pieter.wui...@gmail.com: You can't avoid sharing the token, and you can't avoid sharing the private keys used for signing either. If they are single use, you don't lose anything by sharing them. Forwarding the PoP request would be a way to avoid sharing keys, as suggested above. Also you are not creating a real transaction. Why does the OP_RETURN limitation matter? This was discussed in the beginning of this thread: The idea is to simplify implementation. Existing software can be used as is to sign and validate PoPs Regards, Kalle On Jun 16, 2015 9:22 PM, Kalle Rosenbaum ka...@rosenbaum.se wrote: Thank you for your comments Pieter! Please find my answers below. 2015-06-16 16:31 GMT+02:00 Pieter Wuille pieter.wui...@gmail.com: On Mon, Jun 15, 2015 at 1:59 PM, Kalle Rosenbaum ka...@rosenbaum.se wrote: 2015-06-15 12:00 GMT+02:00 Pieter Wuille pieter.wui...@gmail.com: I'm not sure if we will be able to support PoP with CoinJoin. Maybe someone with more insight into CoinJoin have some input? Not really. The problem is that you assume a transaction corresponds to a single payment. This is true for simple wallet use cases, but not compatible with CoinJoin, or with systems that for example would want to combine multiple payments in a single transaction. Yes, you are right. It's not compatible with CoinJoin and the likes. 48 bits seems low to me, but it does indeed solve the problem. Why not 128 or 256 bits? The nonce is limited because of the OP_RETURN output being limited to 40 bytes of data: 2 bytes version, 32 bytes txid, 6 bytes nonce. Why does anyone care who paid? This is like walking into a coffeshop, noticing I don't have money with me, let me friend pay for me, and then have the shop insist that I can't drink it because I'm not the buyer. If you pay as you use the service (ie pay for coffee upfront), there's
Re: [Bitcoin-development] BIP for Proof of Payment
Another thing worth mentioning is that an SPV wallet cannot validate a PoP without fetching the input transactions of the PoP from an external (not bitcoin network) source, for example chain.com or some other trusted full node's API. The validation of the PoP depends on the external source(s) being honest. It can make a valid pop look invalid, but it cannot make an invalid pop look valid. /Kalle 2015-06-16 14:12 GMT+02:00 Kalle Rosenbaum ka...@rosenbaum.se: 2015-06-16 7:26 GMT+02:00 Tom Harding t...@thinlink.com: Kalle goes to some trouble to describe how merchants need to ensure that they only accept a PoP provided as a response to their challenge. Do you mean that it will be hard to explain to merchants that they must check the nonce in the PoP so that it matches the nonce in the pop request? I think not, this is a commonly used pattern that anyone should be able to grasp. Anyway, merchants will probably use a library (though yet non-existing) for PoP, that will hide the gory details. I also think that payment providers may want to add PoP to their offering to customers (merchants). Regards, /Kalle On 6/15/2015 3:00 AM, Pieter Wuille wrote: I did misunderstand that. That changes things significantly. However, having paid is not the same as having had access to the input coins. What about shared wallets or coinjoin? Also, if I understand correctly, there is no commitment to anything you're trying to say about the sender? So once I obtain a proof-of-payment from you about something you paid, I can go claim that it's mine? Why does anyone care who paid? This is like walking into a coffeshop, noticing I don't have money with me, let me friend pay for me, and then have the shop insist that I can't drink it because I'm not the buyer. Track payments, don't try to assign identities to payers. On Jun 15, 2015 11:35 AM, Kalle Rosenbaum ka...@rosenbaum.se wrote: Hi Pieter! It is intended to be a proof that you *have paid* for something. Not that you have the intent to pay for something. You cannot use PoP without a transaction to prove. So, yes, it's just a proof of access to certain coins that you no longer have. Maybe I don't understand you correctly? /Kalle 2015-06-15 11:27 GMT+02:00 Pieter Wuille pieter.wui...@gmail.com: Now that you have removed the outputs, I don't think it's even a intent of payment, but just a proof of access to certain coins. On Jun 15, 2015 11:24 AM, Kalle Rosenbaum ka...@rosenbaum.se wrote: Hi all! I have made the discussed changes and updated my implementation (https://github.com/kallerosenbaum/poppoc) accordingly. These are the changes: * There is now only one output, the pop output, of value 0. * The sequence number of all inputs of the PoP must be set to 0. I chose to set it to 0 for all inputs for simplicity. * The lock_time of the PoP must be set to 4 (max block height lock time). The comments so far has been mainly positive or neutral. Are there any major objections against any of the two proposals? If not, I will ask Gregory Maxwell to assign them BIP numbers. The two BIP proposals can be found at https://github.com/kallerosenbaum/poppoc/wiki/Proof-of-Payment-BIP and https://github.com/kallerosenbaum/poppoc/wiki/btcpop-scheme-BIP. The source for the Proof of Payment BIP proposal is also in-lined below. A number of alternative names have been proposed: * Proof of Potential * Proof of Control * Proof of Signature * Signatory Proof * Popo: Proof of payment origin * Pots: Proof of transaction signer * proof of transaction intent * Declaration of intent * Asset-access-and-action-affirmation, AAaAA, or A5 * VeriBit * CertiBTC * VBit * PayID Given this list, I still think Proof of Payment is the most descriptive to non-technical people. Regards, Kalle # pre BIP: BIP number Title: Proof of Payment Author: Kalle Rosenbaum ka...@rosenbaum.se Status: Draft Type: Standards Track Created: date created on, in ISO 8601 (-mm-dd) format /pre == Abstract == This BIP describes how a wallet can prove to a server that it has the ability to sign a certain transaction. == Motivation == 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. * Log in to a pay site using a PoP. * A parking lot you pay for monthly and the car authenticates itself using PoP. * A lottery where all participants pay to the same address, and the winner
Re: [Bitcoin-development] BIP for Proof of Payment
Thank you for the clarification Tom! /Kalle 2015-06-16 16:05 GMT+02:00 Tom Harding t...@thinlink.com: On 6/16/2015 5:12 AM, Kalle Rosenbaum wrote: 2015-06-16 7:26 GMT+02:00 Tom Harding t...@thinlink.com: Kalle goes to some trouble to describe how merchants need to ensure that they only accept a PoP provided as a response to their challenge. Do you mean that it will be hard to explain to merchants that they must check the nonce in the PoP so that it matches the nonce in the pop request? Sorry for the idiomatic language. No, I just meant that you have thought it out in detail! You standardize a latent capability of the cryptosystem. It seems very powerful for some classes of users. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP for Proof of Payment
The idea is to simplify implementation. Existing software can be used as is to sign and validate PoPs. But I do agree that it would be a cleaner specification if we would make the PoP invalid as a transaction. I'm open to changes here. I do like the idea to prepend a constant string. But that would require changes in transaction signing and validation code, wouldn't it? Yes, of course. An alternative is adding a 21M BTC output at the end, or bitflipping the txin prevout hashes, or another reversible transformation on the transaction data that is guaranteed to invalidate it. If we do decide to make Pops invalid as transactions, there are a lot of ways to do that. I guess the main question is if we should make Pops invalid as transactions or not. So far I prefer to keep them valid for the above reason. I think that the risk of asking people to sign something that is not an actual transaction, but could be used as one, is very scary. I would feel comfortable doing it. It's just a matter of trusting your wallet, which you already do with your ordinary transactions. Also, I would call it proof of transaction intent, as it's a commitment to a transaction and proof of its validity, but not a proof that an actual transaction took place, nor a means to prevent it from being double spent. Naming is hard. I think a simpler name that explains what its main purpose is (prove that you paid for something) is better than a name that exactly tries to explain what it is. Proof of Payment indeed does make me think it's something that proves you paid. But as described, that is not what a PoP does. It proves the ability to create a particular transaction, and committing to it. There is no actual payment involved (plus, payment makes me think you're talking about BIP70 payments, not simple Bitcoin transactions). Proof of transaction intent does not help me understand what this is about. But I would like to see more name suggestions. The name does not prevent people from using it for other purposes, ie internet over telephone network. I don't understand why something like Proof of Transaction Intent would be incompatible with internet over telephone network either... No, I meant that it's ok to call it Proof of Payment even though people may use it for other stuff. -- Pieter -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP for PoP URI scheme
Hi
Following earlier posts on Proof of Payment I'm now proposing the following
BIP for a Proof of Payment URI scheme (To read it formatted instead, go to
https://github.com/kallerosenbaum/poppoc/wiki/btcpop-scheme-BIP).
Regards,
Kalle Rosenbaum
pre
BIP: BIP number
Title: Proof of Payment URI scheme
Author: Kalle Rosenbaum ka...@rosenbaum.se
Status: Draft
Type: Standards Track
Created: date created on, in ISO 8601 (-mm-dd) format
/pre
== Abstract ==
This is a proposal for a URI scheme to be used in the Proof of Payment
process.
== Motivation ==
To make a Proof of Payment, the party that wants the proof needs to
transfer a Proof of Payment request to the wallet software of the
other party. To facilitate that transfer, a new URI scheme
representing the PoP request is proposed. This URI can then be encoded
in QR images or sent over NFC in order to transfer it to the wallet.
== Specification ==
The specification is the same as BIP0021, with the following
differences:
* The URI scheme is ttbtcpop/tt instead of ttbitcoin/tt
* The path component, i.e. the address part, is always empty.
* A mandatory ttp/tt parameter whose value contains the destination for
the PoP. This could for example be a tthttps:/tt URL or a ttmailto:/tt
URI.
* A mandatory ttn/tt parameter representing the nonce, base58 encoded.
* An optional tttxid/tt parameter containing the Base58 encoded hash of
the transaction to prove.
Just as in BIP0021, elements of the query component may contain
characters outside the valid range. These must first be encoded
according to UTF-8, and then each octet of the corresponding UTF-8
sequence must be percent-encoded as described in RFC 3986.
All parameters except ttp/tt and ttn/tt are hints to the
wallet on which transaction to create a PoP for.
The extensibility of BIP0021 applies to this scheme as well. For
example, a ttdate/tt parameter or a tttoaddr/tt parameter
might be useful. ttreq-*/tt parameters are also allowed and obey
the same rules as in BIP0021, clients not supporting a ttreq-*/tt
parameter must consider the URI invalid.
=== Keep URIs short ===
Implementations should keep the URIs as short as possible. This is
because it makes QR decoding more stable. A camera with a scratched
lens or low resolution may run into problems scanning huge QR
codes. This is why the tttxid/tt parameter is encoded in Base58
instead of the classic hex encoded string. We get away with 44
characters instead of 64. Also, the ttnonce/tt parameter is Base58
encoded for the same reason.
== Interpretation ==
=== Transaction hints ===
The wallet processing the URI must use the hints in the PoP request to
filter its transaction set. The ttlabel/tt, ttamount/tt and
ttmessage/tt parameters must, if present in the URI, exactly match
the data associated with the original payment according to the
following table:
{|
| ttbtcpop:/tt URI parameter || ttbitcoin:/tt URI parameter ||
BIP70 PaymentDetails data
|-
| ttlabel/tt || ttlabel/tt ||
ttmerchant_data/tt
|-
| ttamount/tt|| ttamount/tt ||
ttsum of outputs.amount/tt
|-
| ttmessage/tt || ttmessage/tt||
ttmemo/tt
|}
The tttxid/tt parameter value must match the transaction hash of
the payment.
After filtering, the resulting transaction set is displayed to the
user who selects one of them to prove. An implementation could also
automatically select a transaction in the filtered set, but
there must still be a way for the user to select freely among the
matching transactions. If the filtered set is empty, no transaction
fits the hints and a message about that is presented to the user. If
the filtered set contains exactly one transaction, which is
preferable, that transaction can be automatically selected.
As a fallback, there must also be a way for the user to select any
transaction from the wallet regardless of the transaction hints. This
can be useful if the metadata of the wallet is lost, possibly due to a
restore from backup.
=== PoP destination ttp/tt ===
The ttp/tt parameter value is the destination where to send the
PoP to. This destination is typically a tthttps:/tt URL or a
tthttp:/tt URL, but it could be any type of URI, for example
ttmailto:/tt. To keep ttbtcpop:/tt URIs short, users should
not make their ttp/tt parameter unneccesarily long.
tthttp:/tt and tthttps:/tt URLs
Wallet implementations must support the tthttp:/tt and
tthttps:/tt schemes in which case ttPOST/tt method must be
used. The content type of the POST request must be set to
Content-Type: application/bitcoin-pop
Content-Transfer-Encoding: binary
== Examples ==
Send PoP for a transaction with label video 42923 to
tthttps://www.example.com/pop/352/tt, using nonce tt0x73 0xd5
0x1a 0xbb 0xd8 0x9c/tt:
btcpop:?p=https://www.example.com/pop/352n=zgWTm8yHlabel=video 42923
Send PoP through mail using
ttmailto:p...@example.com?subject=pop444/tt, amount is 1337
satoshis
[Bitcoin-development] BIP for Proof of Payment
Hi
Following earlier posts on Proof of Payment I'm now proposing the following
BIP (To read it formatted instead, go to
https://github.com/kallerosenbaum/poppoc/wiki/Proof-of-Payment-BIP).
Regards,
Kalle Rosenbaum
pre
BIP: BIP number
Title: Proof of Payment
Author: Kalle Rosenbaum ka...@rosenbaum.se
Status: Draft
Type: Standards Track
Created: date created on, in ISO 8601 (-mm-dd) format
/pre
== Abstract ==
This BIP describes how a wallet can prove to a server that it has the
ability to sign a certain transaction.
== Motivation ==
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.
* Log in to a pay site using a PoP.
* A parking lot you pay for monthly and the car authenticates itself using
PoP.
* A lottery where all participants pay to the same address, and the winner
is selected among the transactions to that address. You exchange the prize
for a PoP for the winning transaction.
With Proof of Payment, these use cases can be achieved without any personal
information (user name, password, e-mail address, etc) being involved.
== Rationale ==
Desirable properties:
# A PoP should be generated on demand.
# It should only be usable once to avoid issues due to theft.
# It should be able to create a PoP for any payment, regardless of script
type (P2SH, P2PKH, etc.).
# It should prove that you have enough credentials to unlock all the inputs
of the proven transaction.
# It should be easy to implement by wallets and servers to ease adoption.
Current methods of proving a payment:
* In BIP0070, the PaymentRequest together with the transactions fulfilling
the request makes some sort of proof. However, it does not meet 1, 2 or 4
and it obviously only meets 3 if the payment is made through BIP0070. Also,
there's no standard way to request/provide the proof. If standardized it
would probably meet 5.
* Signing messages, chosen by the server, with the private keys used to
sign the transaction. This could meet 1 and 2 but probably not 3. This is
not standardized either. 4 Could be met if designed so.
If the script type is P2SH, any satisfying script should do, just like for
a payment. For M-of-N multisig scripts, that would mean that any set of M
keys should be sufficient, not neccesarily the same set of M keys that
signed the transaction. This is important because strictly demanding the
same set of M keys would undermine the purpose of a multisig address.
== Specification ==
=== Data structure ===
A proof of payment for a transaction T, here called PoP(T), is used to
prove that one has ownership of the credentials needed to unlock all the
inputs of T. It has the exact same structure as a bitcoin transaction with
the same inputs and outputs as T and in the same order as in T. There is
also one OP_RETURN output inserted at index 0, here called the pop output.
This output must have the following format:
OP_RETURN version txid nonce
{|
! Field!! Size [B] !! Description
|-
| lt;version || 2|| Version, little endian, currently 0x01 0x00
|-
| lt;txid|| 32 || The transaction to prove
|-
| lt;nonce || 6|| Random data
|}
The value of the pop output is set to the same value as the transaction fee
of T. Also, if the outputs of T contains an OP_RETURN output, that output
must not be included in the PoP because there can only be one OP_RETURN
output in a transaction. The value of that OP_RETURN output is instead
added to the value of the pop output.
An illustration of the PoP data structure and its original payment is shown
below.
pre
T
+--+
|inputs | outputs|
| Value | Value Script |
+--+
|input0 1 | 0 pay to A |
|input1 3 | 2 OP_RETURN some data |
|input2 4 | 1 pay to B |
| | 4 pay to C |
+--+
PoP(T)
+--+
|inputs | outputs|
| Value | Value Script |
+--+
|input0 1 | 3 OP_RETURN version txid nonce |
|input1 3 | 0 pay to A |
|input2 4 | 1 pay to B |
| | 4 pay to C |
+--+
/pre
The PoP is signed using the same signing process that is used
[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
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
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
[Bitcoin-development] Proof of Payment
. 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 -- 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
