From: Gavin Andresen <gavinandresen@gmail•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
Date: Wed, 31 Jul 2013 21:19:05 +1000 [thread overview]
Message-ID: <CABsx9T1WB+ZraSGXrLJw1F9a4k+KHZYBPJ2cL8ufUYkayfQStA@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP3pp6N+B4HgRF_xpp-sm7gkkK-NoV6nKKnOzes_2ubT4g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2944 bytes --]
Thanks, Mike!
"PaymentRequest messages larger than 50,000 bytes should be rejected by
> the merchant's server, to mitigate denial-of-service attacks."
>
> Do you mean "users wallet" here?
>
Yes, fixed.
> You could note in the motivation section two more motivations:
> 1) That the protocol can be a foundation on which other features are built
>
I don't like putting "this is what we think will happen in the future"
types of statements in specifications, so I'm inclined to leave that out.
> 2) That it is required to assist hardware wallets when there is a virus on
> the system
>
Added:
"Resistance from man-in-the-middle attacks that replace a merchant's
bitcoin address with an attacker's address before a transaction is
authorized with a hardware wallet."
Perhaps note in the BIP that the merchant should not assume the
> merchant_data field is trustworthy - malicious buyers could rewrite it as
> they see fit. Point out that a good way to use this is to serialize server
> state, signed by a merchant-only key, in the same way one might use an HTTP
> cookie.
>
Added:
"Note that malicious clients may modify the merchant_data, so should be
authenticated in some way (for example, signed with a merchant-only key)."
> "PaymentDetails.payment_url must be secure against man-in-the-middle
> attacks that might alter Payment.refund_to (if using HTTP, it must be
> TLS-protected).
>
> This says "must", but what should a client do here if the payment URL is
> not HTTPS? I suggest weakening this to "should", as sometimes TLS is
> redundant (e.g. if you're sending to a Tor hidden service).
>
done.
> The PaymentACK message contains a copy of Payment, but the BIP doesn't say
> what to do with it. I assume this means a client is free to ignore it and
> rely on TCP state to figure out the payment/ack connection instead? It may
> be worth noting that explicitly.
>
Added:
"payment | Copy of the Payment message that triggered this PaymentACK.
Clients may ignore this if they implement another way of associating
Payments with PaymentACKs."
>
> In the certificates section, you could observe that "validation" means
> "verification that it correctly chains to a trusted root authority, where
> trusted roots may be obtained from the operating system. If there is no
> operating system, the Mozilla root store is recommended".
>
Modified that section to say:
"...followed by additional certificates, with each subsequent certificate
being the one used to certify the previous one, up to a trusted root
authority. The recipient must verify the certificate chain according to
[RFC5280] and reject the PaymentRequest if any validation failure occurs.
Trusted root certificates may be obtained from the operating system; if
validation is done on a device without an operating system, the Mozilla
root store<http://www.mozilla.org/projects/security/certs/included/index.html>
is
recommended."
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 6386 bytes --]
next prev parent reply other threads:[~2013-07-31 11:19 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-31 6:28 Gavin Andresen
2013-07-31 8:45 ` Roy Badami
[not found] ` <CABsx9T3Xvnw2H6awgnT7mr-HzJOqCp_nOVM57BD-B9mY4R43aQ@mail.gmail.com>
2013-07-31 11:33 ` Gavin Andresen
2013-07-31 11:45 ` Melvin Carvalho
2013-07-31 23:30 ` E willbefull
2013-07-31 23:38 ` Gavin Andresen
2013-07-31 23:52 ` E willbefull
2013-08-07 20:12 ` Roy Badami
2013-07-31 8:59 ` Mike Hearn
2013-07-31 11:19 ` Gavin Andresen [this message]
2013-08-07 20:31 ` Pieter Wuille
2013-08-07 21:10 ` Gavin Andresen
2013-08-07 21:17 ` Mike Hearn
2013-08-07 21:36 ` Pieter Wuille
2013-08-07 21:44 ` Mike Hearn
2013-08-07 21:49 ` Pieter Wuille
2013-08-07 21:28 ` Roy Badami
2013-08-07 21:47 ` Alan Reiner
2013-08-14 10:56 ` Jouke Hofman
2013-08-07 21:47 ` Roy Badami
2013-08-07 21:54 ` Pieter Wuille
2013-08-07 22:03 ` Roy Badami
2013-08-08 0:48 ` Gavin Andresen
2013-08-08 9:13 ` Mike Hearn
2013-08-08 14:13 ` Pieter Wuille
2013-08-19 22:15 ` Andreas Petersson
2013-08-19 23:19 ` Gavin Andresen
2013-08-20 10:05 ` Mike Hearn
2013-09-24 13:52 ` Mike Hearn
2013-09-24 23:35 ` Gavin Andresen
2013-09-25 9:27 ` Mike Hearn
2013-09-25 10:28 ` Andreas Schildbach
2013-09-25 11:15 ` Mike Hearn
2013-09-25 11:33 ` Andreas Schildbach
2013-09-25 11:45 ` Mike Hearn
2013-09-25 11:59 ` Andreas Schildbach
2013-09-25 14:31 ` Jeff Garzik
2013-09-25 14:38 ` Mike Hearn
2013-09-25 11:35 ` Melvin Carvalho
2013-09-25 16:12 ` The Doctor
2013-09-26 6:37 ` Peter Todd
2013-09-25 14:26 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABsx9T1WB+ZraSGXrLJw1F9a4k+KHZYBPJ2cL8ufUYkayfQStA@mail.gmail.com \
--to=gavinandresen@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox