Re: [Bitcoin-development] BIP72 amendment proposal
I agree that this would be another way of achieving the same goal. I'd be fine with that if there is a majority. However, I also see downsides of this approach: 1. It's more complicated. It touches more BIPs, and although signing is terribly difficult its still more difficult than just hashing. E.g. signing the payment request twice (ECC + X.509) poses the question in which order you sign, and which signature fields to null for signing. 2. Isn't it discouraged to disclose the public key you're going to receive coins on? (not sure about that) 3. Unlike an hash we can just re-assign to different objects (see my proposal) I think we cannot easily do the same with a signature. It's probably not very important to have this option, but still it should be considered. 4. I'm afraid of the idea of re-purposing the BIP21 address. Someone might send money to it although it isn't meant to receive money any more (service is already using an advanced BIP70 usecase). A clear separation into two parameters would prevent such mistakes, and as soon as the address can go away the URL needn't be longer than it used to be. 5. A hash can be checked without knowing a secret. Are we excluding stateless devices (e.g. proxies, smartwatches)? Generally about the URL length discussion: Currently we have address, amount and r, and it works well. In future we would have h and r. So all we need to do is make sure h not longer than address+amount. I think this is already the case with untruncated SHA256 hashes. But I'd be fine with truncating to maybe 192 bits to save a few characters. On 09/12/2014 06:31 PM, Mike Hearn wrote: Putting aside the question of necessity for a moment, a more efficient approach to this would be; 1. Add another marker param like s to the end of the URL 2. Add another field to PaymentRequest that contains an ECC signature calculated using the public key that hashes to the address in the URI 3. Upgraded wallets look for the additional param and if it's there, expect to find the PaymentDetails signed with the address key. PKI signing of course is still useful to provide an actual identity for receipts, display on hardware wallets, dispute mediation etc. This adds only a few characters to a normal backwards-compatible QR code, and is not hard to implement. On Fri, Sep 12, 2014 at 5:37 PM, Mike Hearn m...@plan99.net mailto:m...@plan99.net wrote: That way we leave up to implementers to experiment with different lengths and figure out what the optimum is Ah, that's a good suggestion if we do go this way. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP72 amendment proposal
On 09/12/2014 08:43 PM, Aaron Voisine wrote: Should BIP72 require that signed payment requests be from the same domain, Although it currently does not seem to be used that way, I'd like to see merchants sign their payment requests but store them on their payment processors server. Currently if you buy from Humble Bundle, all you see is Coinbase which is unfortunate. and also require https? I think that's unrealistic. HTTP is already in use, and also the proposed spec is open to other transports, e.g. Bluetooth which is also already in common use. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP72 amendment proposal
On Fri, Sep 12, 2014 at 10:59 PM, Mark van Cuijk m...@coinqy.com wrote: If you do so, please make sure the length of the hash is included in the PaymentDetails/PaymentRequest. If someone parses the URI and doesn’t have an authenticated way of knowing the expected length of the hash, a MITM attacker can just truncate the hash to lower security. But if they can truncate they can just as well pass a completely different hash that matches their payment request. If an attacker can change the bitcoin: URI, this scheme is broken. The point of the proposal is to make sure that the payment request matches the URI. So *if* you communicate the URI by secure means, this authenticates the associated payment request as well, even if fetched by insecure means (such as http:...) itself. Wladimir -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP72 amendment proposal
On Fri, Sep 12, 2014 at 11:29 AM, Andreas Schildbach andr...@schildbach.de wrote: This is the discussion post corresponding to this PR: https://github.com/bitcoin/bips/pull/106 Amend BIP72 by an h parameter, which contains a hash of the PaymentRequest message that is fetched via the r parameter. The hash is meant to link the trust anchor (e.g. the QR code) to the payment request message in a secure way. This will solve the problem several apps are comparing address+amount fields as a workaround instead, preventing some advanced BIP70 usecases. When these apps read a matching hash, they need not compare any of the other fields. Sounds like a good idea to me. I had no idea that some clients were comparing addresses and amounts in the URI with the payment request for security, that seems like a hacky and inflexible way. This is much better. Wladimir -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP72 amendment proposal
On 12 Sep 2014, at 11:55 , bitcoin-development-requ...@lists.sourceforge.net wrote: The hash is meant to link the trust anchor (e.g. the QR code) to the payment request message in a secure way. This will solve the problem several apps are comparing address+amount fields as a workaround instead, preventing some advanced BIP70 usecases. When these apps read a matching hash, they need not compare any of the other fields. Sounds like a good plan. Do you have a list (possibly incomplete) of apps that perform this kind of checking? We’re currently working with some parties in a supply chain to allow a consumer payment on a retail website to automatically pay supply chain parties, the way BIP70 allows with multiple outputs on a transaction. This behaviour would prohibit this use case. /Mark -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP72 amendment proposal
On 09/12/2014 12:11 PM, Mark van Cuijk wrote: On 12 Sep 2014, at 11:55 , bitcoin-development-requ...@lists.sourceforge.net wrote: The hash is meant to link the trust anchor (e.g. the QR code) to the payment request message in a secure way. This will solve the problem several apps are comparing address+amount fields as a workaround instead, preventing some advanced BIP70 usecases. When these apps read a matching hash, they need not compare any of the other fields. Sounds like a good plan. Do you have a list (possibly incomplete) of apps that perform this kind of checking? We’re currently working with some parties in a supply chain to allow a consumer payment on a retail website to automatically pay supply chain parties, the way BIP70 allows with multiple outputs on a transaction. This behaviour would prohibit this use case. Hard to say, but here is my last assertion: - Bitcoin Wallet - Hive Bitcoin Wallet (checked by source) - countless ( 300) forks/clones of Bitcoin Wallet Since you're planning an advanced BIP70 usecase, you'll also have to deal with the many wallets that don't support BIP70 at all. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP72 amendment proposal
A few thoughts on this: (1) Base64 of SHA256 seems overkill. 256 bits of hash is a lot. The risk here is that a MITM intercepts the payment request, which will be typically requested just seconds after the QR code is vended. 80 bits of entropy would still be a lot and take a long time to brute force, whilst keeping QR codes more compact, which impacts scannability. (2) This should *not* be necessary in the common HTTPS context. The QR code itself is going to be fetched from some service, over HTTPS. I see no reasonable attacker that can MITM the request for the BIP70 message but not the request to get the QR code. Adding a hash makes QR codes more bloated and harder to scan, all on the assumption that HTTPS is broken in some odd way that we haven't actually ever seen in practice. (3) This can be useful in the Bluetooth context, but then again, we could also do things a different way by signing with the key in the first part of the URI, thus avoiding the need for a hash. I know I've been around the loop on this one with Andreas many times. But this BIP doesn't fix any actually existing problem in the previous spec. It exists because Andreas thinks SSL is useless. If SSL is useless we all have much bigger problems. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP72 amendment proposal
Indeed -- Every byte added to the QR code makes it more difficult to be used in restaurants, pubs and other low-light conditions. BitPay tested some of these scenarios. Scannability is absolutely impacted. On Fri, Sep 12, 2014 at 9:49 AM, Mike Hearn m...@plan99.net wrote: A few thoughts on this: (1) Base64 of SHA256 seems overkill. 256 bits of hash is a lot. The risk here is that a MITM intercepts the payment request, which will be typically requested just seconds after the QR code is vended. 80 bits of entropy would still be a lot and take a long time to brute force, whilst keeping QR codes more compact, which impacts scannability. (2) This should not be necessary in the common HTTPS context. The QR code itself is going to be fetched from some service, over HTTPS. I see no reasonable attacker that can MITM the request for the BIP70 message but not the request to get the QR code. Adding a hash makes QR codes more bloated and harder to scan, all on the assumption that HTTPS is broken in some odd way that we haven't actually ever seen in practice. (3) This can be useful in the Bluetooth context, but then again, we could also do things a different way by signing with the key in the first part of the URI, thus avoiding the need for a hash. I know I've been around the loop on this one with Andreas many times. But this BIP doesn't fix any actually existing problem in the previous spec. It exists because Andreas thinks SSL is useless. If SSL is useless we all have much bigger problems. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP72 amendment proposal
On 09/12/2014 03:49 PM, Mike Hearn wrote: (1) Base64 of SHA256 seems overkill. 256 bits of hash is a lot. The risk here is that a MITM intercepts the payment request, which will be typically requested just seconds after the QR code is vended. 80 bits of entropy would still be a lot and take a long time to brute force, whilst keeping QR codes more compact, which impacts scannability. To put that into perspective, here is how a bitcoin: URI would look like: bitcoin:?h=J-J-4mra0VorfffEZm5J7mBmHGKX86Dpt-TnnmC_fhEr=http://wallet.schildbach.de/bip70/r1409992884.bitcoinpaymentrequest (obviously for real-world usage you would optimize the r parameter) I looked at the list in this doc to evaluate what's easily available: https://code.google.com/p/guava-libraries/wiki/HashingExplained I thought SHA1 has a bad reputation these days, and we don't save much by using it. I don't know anything about Murmur. MD5 is clearly broken. What hash function would you recommend? (2) This should *not* be necessary in the common HTTPS context. It is. People can't check names. People don't want to check names. People can't get certificates for lots of reasons. X.509 is centralized. X.509 has had serious security issues in the past. And shit continues to happen. To sum up, X.509 can't replace the trust anchor that is established by scanning a QR code or tapping two devices together. (3) This can be useful in the Bluetooth context, but then again, we could also do things a different way by signing with the key in the first part of the URI, thus avoiding the need for a hash. Sure. But signing is harder than just calculating a hash. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP72 amendment proposal
What hash function would you recommend? Due to the properties of hash functions, you can just take the first x bits of a SHA256 sum and they're pretty much as good as an equally secure hash function of that length. In fact SHA512/224 and SHA512/256 are defined in that way (Plus different initial values because you might as well do that when defining a standard). On Fri, Sep 12, 2014 at 10:36 AM, Andreas Schildbach andr...@schildbach.de wrote: On 09/12/2014 03:49 PM, Mike Hearn wrote: (1) Base64 of SHA256 seems overkill. 256 bits of hash is a lot. The risk here is that a MITM intercepts the payment request, which will be typically requested just seconds after the QR code is vended. 80 bits of entropy would still be a lot and take a long time to brute force, whilst keeping QR codes more compact, which impacts scannability. To put that into perspective, here is how a bitcoin: URI would look like: bitcoin:?h=J-J-4mra0VorfffEZm5J7mBmHGKX86Dpt-TnnmC_fhEr=http://wallet.schildbach.de/bip70/r1409992884.bitcoinpaymentrequest (obviously for real-world usage you would optimize the r parameter) I looked at the list in this doc to evaluate what's easily available: https://code.google.com/p/guava-libraries/wiki/HashingExplained I thought SHA1 has a bad reputation these days, and we don't save much by using it. I don't know anything about Murmur. MD5 is clearly broken. What hash function would you recommend? (2) This should *not* be necessary in the common HTTPS context. It is. People can't check names. People don't want to check names. People can't get certificates for lots of reasons. X.509 is centralized. X.509 has had serious security issues in the past. And shit continues to happen. To sum up, X.509 can't replace the trust anchor that is established by scanning a QR code or tapping two devices together. (3) This can be useful in the Bluetooth context, but then again, we could also do things a different way by signing with the key in the first part of the URI, thus avoiding the need for a hash. Sure. But signing is harder than just calculating a hash. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP72 amendment proposal
Specifically relevant here: http://security.stackexchange.com/questions/34796/truncating-the-output-of-sha256-to-128-bits. If you're going to truncate though, why not just leave the amount of bits up the the person generating the QR code? The client simply takes the hash prefix (any length up to full 256-bits) and makes sure it's a strict prefix of the actual hash of the payment request. That way we leave up to implementers to experiment with different lengths and figure out what the optimum is (which could depend on the security/convenience tradeoff of that particular transaction, as in more bits for large payments). On Fri, Sep 12, 2014 at 11:25 AM, Christophe Biocca christophe.bio...@gmail.com wrote: What hash function would you recommend? Due to the properties of hash functions, you can just take the first x bits of a SHA256 sum and they're pretty much as good as an equally secure hash function of that length. In fact SHA512/224 and SHA512/256 are defined in that way (Plus different initial values because you might as well do that when defining a standard). On Fri, Sep 12, 2014 at 10:36 AM, Andreas Schildbach andr...@schildbach.de wrote: On 09/12/2014 03:49 PM, Mike Hearn wrote: (1) Base64 of SHA256 seems overkill. 256 bits of hash is a lot. The risk here is that a MITM intercepts the payment request, which will be typically requested just seconds after the QR code is vended. 80 bits of entropy would still be a lot and take a long time to brute force, whilst keeping QR codes more compact, which impacts scannability. To put that into perspective, here is how a bitcoin: URI would look like: bitcoin:?h=J-J-4mra0VorfffEZm5J7mBmHGKX86Dpt-TnnmC_fhEr=http://wallet.schildbach.de/bip70/r1409992884.bitcoinpaymentrequest (obviously for real-world usage you would optimize the r parameter) I looked at the list in this doc to evaluate what's easily available: https://code.google.com/p/guava-libraries/wiki/HashingExplained I thought SHA1 has a bad reputation these days, and we don't save much by using it. I don't know anything about Murmur. MD5 is clearly broken. What hash function would you recommend? (2) This should *not* be necessary in the common HTTPS context. It is. People can't check names. People don't want to check names. People can't get certificates for lots of reasons. X.509 is centralized. X.509 has had serious security issues in the past. And shit continues to happen. To sum up, X.509 can't replace the trust anchor that is established by scanning a QR code or tapping two devices together. (3) This can be useful in the Bluetooth context, but then again, we could also do things a different way by signing with the key in the first part of the URI, thus avoiding the need for a hash. Sure. But signing is harder than just calculating a hash. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP72 amendment proposal
Your example doesn't have an address in it at all, so isn't compatible with non-BIP70 wallets. Maybe for QRcodes specifically there are no longer any such wallets out there. For clickable links it can still be an issue. I thought SHA1 has a bad reputation these days, and we don't save much by using it. I don't know anything about Murmur. MD5 is clearly broken. What hash function would you recommend? Can just truncate SHA256, I think. It is. People can't check names. People don't want to check names. Their wallet checks the name, though. It sees: bitcoin:1AbCd?r=https://bitpay.com/r/12345 and the wallet verifies that the presented certificate is for CN=bitpay.com People can't get certificates for lots of reasons. X.509 is centralized. X.509 has had serious security issues in the past. And shit continues to happen. Well, I wrote an article that argues with this PoV: https://medium.com/@octskyward/why-you-think-the-pki-sucks-b64cf5912aa7 No disagreement that it's a more complex mechanism. But seeing as we end up depending on it anyway the moment you load any kind of web page to find out the URI, adding another mechanism only increases complexity, it doesn't remove any. Sure. But signing is harder than just calculating a hash. Well, again, it saves qrcode bytes. You don't have to include a dedicated hash. The existing address hash can double up as both a backwards compatibility measure, and also an auth mechanism. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP72 amendment proposal
Putting aside the question of necessity for a moment, a more efficient approach to this would be; 1. Add another marker param like s to the end of the URL 2. Add another field to PaymentRequest that contains an ECC signature calculated using the public key that hashes to the address in the URI 3. Upgraded wallets look for the additional param and if it's there, expect to find the PaymentDetails signed with the address key. PKI signing of course is still useful to provide an actual identity for receipts, display on hardware wallets, dispute mediation etc. This adds only a few characters to a normal backwards-compatible QR code, and is not hard to implement. On Fri, Sep 12, 2014 at 5:37 PM, Mike Hearn m...@plan99.net wrote: That way we leave up to implementers to experiment with different lengths and figure out what the optimum is Ah, that's a good suggestion if we do go this way. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP72 amendment proposal
Are there any circumstances where the payment request object might be served over a different domain than the CNAME of the object's signer? BIP72 states Bitcoin wallets must support fetching PaymentRequests via http and https protocols;. If the request object is signed by the owner of the domain, then the worst an attacker who doesn't have the signing key can do is replace the request with another validly signed request intended for someone else, but that could be the attacker's own product order, tricking someone else into paying for it. Should BIP72 require that signed payment requests be from the same domain, and also require https? Aaron Aaron Voisine breadwallet.com On Fri, Sep 12, 2014 at 9:31 AM, Mike Hearn m...@plan99.net wrote: Putting aside the question of necessity for a moment, a more efficient approach to this would be; Add another marker param like s to the end of the URL Add another field to PaymentRequest that contains an ECC signature calculated using the public key that hashes to the address in the URI Upgraded wallets look for the additional param and if it's there, expect to find the PaymentDetails signed with the address key. PKI signing of course is still useful to provide an actual identity for receipts, display on hardware wallets, dispute mediation etc. This adds only a few characters to a normal backwards-compatible QR code, and is not hard to implement. On Fri, Sep 12, 2014 at 5:37 PM, Mike Hearn m...@plan99.net wrote: That way we leave up to implementers to experiment with different lengths and figure out what the optimum is Ah, that's a good suggestion if we do go this way. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP72 amendment proposal
On 12 Sep 2014, at 20:43 , bitcoin-development-requ...@lists.sourceforge.net wrote: Specifically relevant here: http://security.stackexchange.com/questions/34796/truncating-the-output-of-sha256-to-128-bits. If you're going to truncate though, why not just leave the amount of bits up the the person generating the QR code? The client simply takes the hash prefix (any length up to full 256-bits) and makes sure it's a strict prefix of the actual hash of the payment request. If you do so, please make sure the length of the hash is included in the PaymentDetails/PaymentRequest. If someone parses the URI and doesn’t have an authenticated way of knowing the expected length of the hash, a MITM attacker can just truncate the hash to lower security. /Mark -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
