Re: [Bitcoin-development] BIP72 amendment proposal

2014-09-12 Thread Mark van Cuijk
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=157508191&iu=/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

2014-09-12 Thread Aaron Voisine
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  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  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=157508191&iu=/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=157508191&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Small update to BIP 62

2014-09-12 Thread Pieter Wuille
On Mon, Sep 8, 2014 at 1:31 AM, Pieter Wuille  wrote:
> I've sent out a new pull request
> (https://github.com/bitcoin/bips/pull/102/files) that:
> * Changes the order of the rules.
> * Adds more reference documentation about minimal pushes and number encodings.
> * Clarified that extra consensus rules cannot prevent someone from
> creating outputs whose spending transactions will be malleable.
>
> I haven't changed which rules are mandatory in v3, so this is a pure
> clarification & reorganization of the text.

Changes: https://github.com/bitcoin/bips/pull/102/files

Gregory, Jeff: does this address your concerns?
Others: comments?

-- 
Pieter

--
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=157508191&iu=/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

2014-09-12 Thread Mike Hearn
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  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=157508191&iu=/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

2014-09-12 Thread Mike Hearn
>
> 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=157508191&iu=/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

2014-09-12 Thread Mike Hearn
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=157508191&iu=/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

2014-09-12 Thread Christophe Biocca
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
 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
>  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_fhE&r=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=157508191&iu=/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=157508191&iu=/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

2014-09-12 Thread Christophe Biocca
> 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
 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_fhE&r=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=157508191&iu=/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=157508191&iu=/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

2014-09-12 Thread Andreas Schildbach
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_fhE&r=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=157508191&iu=/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

2014-09-12 Thread Jeff Garzik
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) 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=157508191&iu=/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=157508191&iu=/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

2014-09-12 Thread Mike Hearn
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=157508191&iu=/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

2014-09-12 Thread Andreas Schildbach
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=157508191&iu=/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

2014-09-12 Thread Mark van Cuijk
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=157508191&iu=/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

2014-09-12 Thread Wladimir
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 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=157508191&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] BIP72 amendment proposal

2014-09-12 Thread Andreas Schildbach
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.

Thanks to Julian Haight for helping with the standard."


--
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=157508191&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development