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.
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
15 matches
Mail list logo
