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 i
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
On Fri, Sep 12, 2014 at 10:59 PM, Mark van Cuijk 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
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 th
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
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 t
>
> 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 da
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
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 f
> 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
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 tak
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 wrote:
> A few thoughts on this:
>
> (1) Base
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 for
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 a
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
> in
On Fri, Sep 12, 2014 at 11:29 AM, Andreas Schildbach
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
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
17 matches
Mail list logo
