When I asked a non-tech friend to do a BIP 70 payment using our wallet as a
first round of user experience testing, he made the remark the he wanted to do
a payment to a merchant, but instead our software shows a payment to “BitPay,
Inc.”
This can be problematic for a couple of reasons:
- As a
Good to see that it has been discussed, but I see the idea has been postponed.
I agree our proposals don’t differ substantially. Besides naming, I think the
differences are the algorithms that are used for signing the extended
certificate / mandate by the merchant and the way backwards compatibi
On 28 Jul 2014, at 14:46 , Mike Hearn wrote:
> I do like the idea coined by Mike that a PP can issue non-SSL certificates
> for the purpose of merchant identification, as long as a customer is free to
> determine whether he trusts the PP for this purpose.
>
> I don't think I proposed this exac
On 28 Jul 2014, at 15:32 , Mike Hearn wrote:
> So what now? To be honest my next priority with BIP70 was to formalise the
> extensions process, I've been dragging my feet over that because I'm working
> on other things. And then after that to knock some heads together over at
> BitPay/Coinbase
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 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
6 matches
Mail list logo
