New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build: Add --disable-bip70 configure option #11622

Closed
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
@laanwj
Member

laanwj commented Nov 6, 2017

This patch adds a --disable-bip70 configure option that disables BIP70 payment request support in the wallet GUI. BIP70 support remains enabled by default.

When disabled, this breaks the dependency of the GUI on OpenSSL and Protobuf.

(triggered by discussion on IRC today)

@TheBlueMatt

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Nov 6, 2017

Contributor

Concept ACK generally, though I'm curious where you see this going longer-term - do we want to deprecate BIP 70 support (I think I'd be generally in favor of this, it seems to provide almost 0 utility which results in it being mostly unused, and even if it were used broadly, its unclear that it provides any real security benefit) or start shipping binaries without BIP 70 support or will this just be yet another build-time option we support (which I'd definitely use)?

Contributor

TheBlueMatt commented Nov 6, 2017

Concept ACK generally, though I'm curious where you see this going longer-term - do we want to deprecate BIP 70 support (I think I'd be generally in favor of this, it seems to provide almost 0 utility which results in it being mostly unused, and even if it were used broadly, its unclear that it provides any real security benefit) or start shipping binaries without BIP 70 support or will this just be yet another build-time option we support (which I'd definitely use)?

@MeshCollider

This comment has been minimized.

Show comment
Hide comment
@MeshCollider

MeshCollider Nov 6, 2017

Member

Concept ACK after reading the discussion on IRC

Member

MeshCollider commented Nov 6, 2017

Concept ACK after reading the discussion on IRC

@promag

This comment has been minimized.

Show comment
Hide comment
@promag

promag Nov 7, 2017

Member

Should add to travis matrix?

Member

promag commented Nov 7, 2017

Should add to travis matrix?

@NicolasDorier

This comment has been minimized.

Show comment
Hide comment
@NicolasDorier

NicolasDorier Nov 7, 2017

Member

For information, I plan to make BIP70 deprecated into NBitcoin. (By removing it from main lib, and moving it to separate package)

This led me to too much dependency issues, as well as cross implementation issues as you can't check correctly the signature of the payment request without serializing the payment request exactly as all other implementations does. (Typically, my implementation works against all wallets, except copay for reasons...)

As a library/service developer, I would love to see another simple standard, filling the same need, Json simple binary based, just using HTTPS for securing the communication between wallet and server.

I remember there was discussions about making a new payment protocol long time ago, I think it was initiated by @sipa.

Concept ACK

Member

NicolasDorier commented Nov 7, 2017

For information, I plan to make BIP70 deprecated into NBitcoin. (By removing it from main lib, and moving it to separate package)

This led me to too much dependency issues, as well as cross implementation issues as you can't check correctly the signature of the payment request without serializing the payment request exactly as all other implementations does. (Typically, my implementation works against all wallets, except copay for reasons...)

As a library/service developer, I would love to see another simple standard, filling the same need, Json simple binary based, just using HTTPS for securing the communication between wallet and server.

I remember there was discussions about making a new payment protocol long time ago, I think it was initiated by @sipa.

Concept ACK

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Nov 7, 2017

Member

Concept ACK generally, though I'm curious where you see this going longer-term

My opinion on it is really divided. I like BIP70 in concept (automatic refund addresses, key expiration, allowing the wallet to directly authenticate vendors, direct transaction submission), but not the technical implementation, and also not the dependency burden it puts on bitcoin core.

Additionally it also seems the code is not maintained. No one is working on BIP70 support in bitcoin core.

So I'm ok with signalling that in the future we might be going to deprecate it, without any commitments - this would be the first step, to allow builders to disable it.

(my personal motivation is that I want to have the option to build the GUI without protobuf and without OpenSSL after the last remnants of OpenSSL use are removed from the rest of the code)

For information, I plan to make BIP70 deprecated into NBitcoin. (By removing it from main lib, and moving it to separate package)

Seems to be better design anyhow. Here it's been peppered all over the GUI code :( Also for lib-ifying, isolating the parts affected like this is the first step.

Should add to travis matrix?

Agree that that's a good idea to warrant that this keeps working.

Member

laanwj commented Nov 7, 2017

Concept ACK generally, though I'm curious where you see this going longer-term

My opinion on it is really divided. I like BIP70 in concept (automatic refund addresses, key expiration, allowing the wallet to directly authenticate vendors, direct transaction submission), but not the technical implementation, and also not the dependency burden it puts on bitcoin core.

Additionally it also seems the code is not maintained. No one is working on BIP70 support in bitcoin core.

So I'm ok with signalling that in the future we might be going to deprecate it, without any commitments - this would be the first step, to allow builders to disable it.

(my personal motivation is that I want to have the option to build the GUI without protobuf and without OpenSSL after the last remnants of OpenSSL use are removed from the rest of the code)

For information, I plan to make BIP70 deprecated into NBitcoin. (By removing it from main lib, and moving it to separate package)

Seems to be better design anyhow. Here it's been peppered all over the GUI code :( Also for lib-ifying, isolating the parts affected like this is the first step.

Should add to travis matrix?

Agree that that's a good idea to warrant that this keeps working.

@luke-jr

Concept ACK.

I suggest also indenting nested #ifs with a single space.

Show outdated Hide outdated src/Makefile.qt.include
@@ -1292,6 +1313,7 @@ echo " with wallet = $enable_wallet"
echo " with gui / qt = $bitcoin_enable_qt"
if test x$bitcoin_enable_qt != xno; then
echo " qt version = $bitcoin_qt_got_major_vers"
echo " with bip70 = $enable_bip70"

This comment has been minimized.

@luke-jr

luke-jr Nov 7, 2017

Member

Probably would be better to mention "(payment protocol)" here as well.

@luke-jr

luke-jr Nov 7, 2017

Member

Probably would be better to mention "(payment protocol)" here as well.

This comment has been minimized.

@laanwj

laanwj Nov 7, 2017

Member

Yep. Although that breaks the alignment...

@laanwj

laanwj Nov 7, 2017

Member

Yep. Although that breaks the alignment...

Show outdated Hide outdated src/qt/bitcoin.cpp
Show outdated Hide outdated src/qt/bitcoin.cpp
Show outdated Hide outdated src/qt/coincontroldialog.cpp
Show outdated Hide outdated src/qt/guiutil.cpp
Show outdated Hide outdated src/qt/test/compattests.cpp
Show outdated Hide outdated src/qt/test/wallettests.cpp
@Sjors

This comment has been minimized.

Show comment
Hide comment
@Sjors

Sjors Nov 9, 2017

Member

"this breaks the dependency" -> "this removes the dependency"?

I know the goal is to get rid of OpenSLL, but what's with Protobuf? Just fewer dependencies, or is there a specific problem with it?

Breaking bitcoin://1A1...Na&amount=0.001 would be bad; it's used by various services. It's often embedded in a QR code, which isn't that useful on a desktop, but it can also be a link on a webpage or email too.

Member

Sjors commented Nov 9, 2017

"this breaks the dependency" -> "this removes the dependency"?

I know the goal is to get rid of OpenSLL, but what's with Protobuf? Just fewer dependencies, or is there a specific problem with it?

Breaking bitcoin://1A1...Na&amount=0.001 would be bad; it's used by various services. It's often embedded in a QR code, which isn't that useful on a desktop, but it can also be a link on a webpage or email too.

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Nov 9, 2017

Member

I know the goal is to get rid of OpenSLL, but what's with Protobuf? Just fewer dependencies, or is there a specific problem with it?

Advantage of less dependencies is mainly: less stuff to build while cross-compiling, less attack surface (yet another parsing library), etc.

Breaking bitcoin://1A1...Na&amount=0.001 would be bad; it's used by various services. It's often embedded in a QR code, which isn't that useful on a desktop, but it can also be a link on a webpage or email too.

I agree. It's --disable-bip70 not --disable-bip21. @luke-jr already commented that, though. I'll see if I can keep that part.

Member

laanwj commented Nov 9, 2017

I know the goal is to get rid of OpenSLL, but what's with Protobuf? Just fewer dependencies, or is there a specific problem with it?

Advantage of less dependencies is mainly: less stuff to build while cross-compiling, less attack surface (yet another parsing library), etc.

Breaking bitcoin://1A1...Na&amount=0.001 would be bad; it's used by various services. It's often embedded in a QR code, which isn't that useful on a desktop, but it can also be a link on a webpage or email too.

I agree. It's --disable-bip70 not --disable-bip21. @luke-jr already commented that, though. I'll see if I can keep that part.

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Nov 9, 2017

Member

I've restored BIP21 functionality, sifting through paymentserver.cpp/h to disable the parts relating to payment requests, instead of removing the whole file from the build.

Member

laanwj commented Nov 9, 2017

I've restored BIP21 functionality, sifting through paymentserver.cpp/h to disable the parts relating to payment requests, instead of removing the whole file from the build.

@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Nov 10, 2017

Member

But if (PaymentServer::ipcSendCommandLine()) is still #ifdef'd out...

Member

luke-jr commented Nov 10, 2017

But if (PaymentServer::ipcSendCommandLine()) is still #ifdef'd out...

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Nov 10, 2017

Member

But if (PaymentServer::ipcSendCommandLine()) is still #ifdef'd out...

Whoops, missed that. Fixed.

Member

laanwj commented Nov 10, 2017

But if (PaymentServer::ipcSendCommandLine()) is still #ifdef'd out...

Whoops, missed that. Fixed.

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Nov 11, 2017

Member

Concept ACK

Member

sipa commented Nov 11, 2017

Concept ACK

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Nov 11, 2017

Member

Nice!
Concept ACK. I could see this for 0.16 and a default to disable in 0.17.

(my personal motivation is that I want to have the option to build the GUI without protobuf and without OpenSSL after the last remnants of OpenSSL use are removed from the rest of the code)

AFAIK OpenSSL (crypto) is still in use for the PRNG seeding (see currently closed #10299, waiting for new approach).
And as far as I can see there is a RAND_event in winshutdownmonitor.cpp.

Member

jonasschnelli commented Nov 11, 2017

Nice!
Concept ACK. I could see this for 0.16 and a default to disable in 0.17.

(my personal motivation is that I want to have the option to build the GUI without protobuf and without OpenSSL after the last remnants of OpenSSL use are removed from the rest of the code)

AFAIK OpenSSL (crypto) is still in use for the PRNG seeding (see currently closed #10299, waiting for new approach).
And as far as I can see there is a RAND_event in winshutdownmonitor.cpp.

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Nov 11, 2017

Member

AFAIK OpenSSL (crypto) is still in use for the PRNG seeding (see currently closed #10299, waiting for new approach).

Agree. The rand_ stuff should be removed in one go in a separate PR, it's orthogonal to the changes here.
(I don't change the build system with regard to OpenSSL in this PR)

Member

laanwj commented Nov 11, 2017

AFAIK OpenSSL (crypto) is still in use for the PRNG seeding (see currently closed #10299, waiting for new approach).

Agree. The rand_ stuff should be removed in one go in a separate PR, it's orthogonal to the changes here.
(I don't change the build system with regard to OpenSSL in this PR)

@Sjors

This comment has been minimized.

Show comment
Hide comment
@Sjors

Sjors Nov 13, 2017

Member

I did a make clean, ./autogen.sh, ./configure --disable-bip70 (which shows with bip70 = no) and make deploy.

I then tested BIP-21 using: ./Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt bitcoin://1F1tAaz5x1HUXrCNLbtMDqcw6o5GNn4xqX?amount=0.1. This worked, but it did throw a warning (?):

QObject::connect: No such signal PaymentServer::receivedPaymentACK(QString) in qt/paymentserver.cpp:234

I think you need another #ifdef there.

Member

Sjors commented Nov 13, 2017

I did a make clean, ./autogen.sh, ./configure --disable-bip70 (which shows with bip70 = no) and make deploy.

I then tested BIP-21 using: ./Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt bitcoin://1F1tAaz5x1HUXrCNLbtMDqcw6o5GNn4xqX?amount=0.1. This worked, but it did throw a warning (?):

QObject::connect: No such signal PaymentServer::receivedPaymentACK(QString) in qt/paymentserver.cpp:234

I think you need another #ifdef there.

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Nov 13, 2017

Member

QObject::connect: No such signal PaymentServer::receivedPaymentACK(QString) in qt/paymentserver.cpp:234

Thanks, added, also rebased and squashed.

Member

laanwj commented Nov 13, 2017

QObject::connect: No such signal PaymentServer::receivedPaymentACK(QString) in qt/paymentserver.cpp:234

Thanks, added, also rebased and squashed.

@Sjors

This comment has been minimized.

Show comment
Hide comment
@Sjors

Sjors Nov 13, 2017

Member

Warning is gone (also without the //, see #11645 (comment)).

Member

Sjors commented Nov 13, 2017

Warning is gone (also without the //, see #11645 (comment)).

@fanquake

This comment has been minimized.

Show comment
Hide comment
@fanquake

fanquake Nov 17, 2017

Member

Concept ACK. Needs another rebase.

Member

fanquake commented Nov 17, 2017

Concept ACK. Needs another rebase.

@Sjors Sjors referenced this pull request Nov 18, 2017

Open

iOS Deployment Target for RPC #11720

0 of 1 task complete

laanwj added some commits Nov 6, 2017

build: Add --disable-bip70 configure option
This patch adds a --disable-bip70 configure option that disables BIP70
payment request support. When disabled, this removes the dependency of
the GUI on OpenSSL and Protobuf.
qt: cleanup: Move BIP70 functions together in paymentserver
Reduces the number of separate `#ifdefs` spans.
@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Nov 28, 2017

Member

Rebased for the #include change. Might want to re-review include changes.

Member

laanwj commented Nov 28, 2017

Rebased for the #include change. Might want to re-review include changes.

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Nov 29, 2017

Member

Going to close this for now, bitpay going to require BIP70 kind of messes up our plans to deprecate BIP70, and I'm not sure this option is worth carrying if that's not the long-term goal.

Member

laanwj commented Nov 29, 2017

Going to close this for now, bitpay going to require BIP70 kind of messes up our plans to deprecate BIP70, and I'm not sure this option is worth carrying if that's not the long-term goal.

@laanwj laanwj closed this Nov 29, 2017

@Sjors

This comment has been minimized.

Show comment
Hide comment
@Sjors

Sjors Nov 29, 2017

Member

In that case, does it make sense to remove the OpenSSL dependency from the BIP70 implementation in some other way?

Member

Sjors commented Nov 29, 2017

In that case, does it make sense to remove the OpenSSL dependency from the BIP70 implementation in some other way?

@TheBlueMatt

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Dec 4, 2017

Contributor

It is my understanding that there are enough other wallets that do not implement BIP 70 that it probably makes sense to still target deprecating it. Either way, I think we should at least be targeting moving towards a world in which the bitcoin URI which generates a payment request includes a signature over the payment request (or a pubkey which will sign it), because the use of https/TLS alone to authenticate the payment request probably makes it end up with significantly worse overall security than simply not using BIP 70.

Contributor

TheBlueMatt commented Dec 4, 2017

It is my understanding that there are enough other wallets that do not implement BIP 70 that it probably makes sense to still target deprecating it. Either way, I think we should at least be targeting moving towards a world in which the bitcoin URI which generates a payment request includes a signature over the payment request (or a pubkey which will sign it), because the use of https/TLS alone to authenticate the payment request probably makes it end up with significantly worse overall security than simply not using BIP 70.

@NicolasDorier

This comment has been minimized.

Show comment
Hide comment
@NicolasDorier

NicolasDorier Dec 5, 2017

Member

I disagree. This is just reinventing the wheel.

If you want to separate the payment processor from the merchant, just make so the payment processor give an https link to the merchant, and show the merchant domain of the merchant (+ certificate information if something could parse it before handling to the app) in the wallet inside the payment confirmation screen.

Adding your own protocol for signing a payment request is a bad idea that should never have existed in the first place. It bring this kind of heavy weight dependency without any advantage.

Member

NicolasDorier commented Dec 5, 2017

I disagree. This is just reinventing the wheel.

If you want to separate the payment processor from the merchant, just make so the payment processor give an https link to the merchant, and show the merchant domain of the merchant (+ certificate information if something could parse it before handling to the app) in the wallet inside the payment confirmation screen.

Adding your own protocol for signing a payment request is a bad idea that should never have existed in the first place. It bring this kind of heavy weight dependency without any advantage.

@TheBlueMatt

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Dec 6, 2017

Contributor

@NicolasDorier absolutely not...If you are purchasing from a merchant, then you're already interacting with their website and it is what gave you the payment link, we should be using that as a root-of-trust where at all possible, not using both that and existing SSL CAs (after all, no user is going to verify that the merchant XYZ is actually using https://co1nbase.com/ as their payment processor, or that the 1 should really be an i and they're getting mitm'd).

Contributor

TheBlueMatt commented Dec 6, 2017

@NicolasDorier absolutely not...If you are purchasing from a merchant, then you're already interacting with their website and it is what gave you the payment link, we should be using that as a root-of-trust where at all possible, not using both that and existing SSL CAs (after all, no user is going to verify that the merchant XYZ is actually using https://co1nbase.com/ as their payment processor, or that the 1 should really be an i and they're getting mitm'd).

@NicolasDorier

This comment has been minimized.

Show comment
Hide comment
@NicolasDorier

NicolasDorier Dec 7, 2017

Member

I am not sure I understand.

I think we should at least be targeting moving towards a world in which the bitcoin URI which generates a payment request includes a signature over the payment request (or a pubkey which will sign it)

Which I disagree, because the payment request already come from HTTPS link. HTTPS can be used to show who you are paying to on the mobile wallet. (no need of adding your own signature on top of that)

..If you are purchasing from a merchant, then you're already interacting with their website and it is what gave you the payment link, we should be using that as a root-of-trust where at all possible, not using both that and existing SSL CAs

Which I completely agree but which seems to be the contrary of your previous sentence.

Member

NicolasDorier commented Dec 7, 2017

I am not sure I understand.

I think we should at least be targeting moving towards a world in which the bitcoin URI which generates a payment request includes a signature over the payment request (or a pubkey which will sign it)

Which I disagree, because the payment request already come from HTTPS link. HTTPS can be used to show who you are paying to on the mobile wallet. (no need of adding your own signature on top of that)

..If you are purchasing from a merchant, then you're already interacting with their website and it is what gave you the payment link, we should be using that as a root-of-trust where at all possible, not using both that and existing SSL CAs

Which I completely agree but which seems to be the contrary of your previous sentence.

@TheBlueMatt

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Dec 8, 2017

Contributor

@NicolasDorier My point is you start from a root of trust (the bitcoin: URI), which no one is going to do almost anything to cross-check (cause if it references co1nbase.com instead of coinbase.com, who cares? thats the link you got). We should thus be using that as the root of trust, instead of introducing a second one (CAs), where if someone has a cert for coinbase.com (either cause they broke a CA somehow, or because you have a bad CA installed due to your work/antivirus software), they can intercept a payment even after you got a good bitcoin: URI!

Contributor

TheBlueMatt commented Dec 8, 2017

@NicolasDorier My point is you start from a root of trust (the bitcoin: URI), which no one is going to do almost anything to cross-check (cause if it references co1nbase.com instead of coinbase.com, who cares? thats the link you got). We should thus be using that as the root of trust, instead of introducing a second one (CAs), where if someone has a cert for coinbase.com (either cause they broke a CA somehow, or because you have a bad CA installed due to your work/antivirus software), they can intercept a payment even after you got a good bitcoin: URI!

@NicolasDorier

This comment has been minimized.

Show comment
Hide comment
@NicolasDorier

NicolasDorier Dec 8, 2017

Member

If you get the signed payment request inside the bitcoin:, how does the signer know that the pubkey signing it is from Coinbase? Response to this question is about re-implementing PKI, which browsers does out of the box, or is there any other alternatives?

Member

NicolasDorier commented Dec 8, 2017

If you get the signed payment request inside the bitcoin:, how does the signer know that the pubkey signing it is from Coinbase? Response to this question is about re-implementing PKI, which browsers does out of the box, or is there any other alternatives?

@TheBlueMatt

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Dec 8, 2017

Contributor

The PKI usage in BIP70 is rarely used to verify the merchant itself, but is instead some third-party payment services provider (eg coinbase/bitpay/etc). Expecting to know which payment services provider a given merchant is using is not realistic for users, so I'm skeptical the PKI usage here is of really any value. Note that probably a better solution than requiring a signature over the payment request in the URI is requiring a public key which signs the eventual payment request in the URI. This also resolves the issue of having to get payment providers to get valid SSL/TLS certs for their domain and then use them for a secondary purpose (signing payment requests), which is generally (rightfully) considered bad practice.

Contributor

TheBlueMatt commented Dec 8, 2017

The PKI usage in BIP70 is rarely used to verify the merchant itself, but is instead some third-party payment services provider (eg coinbase/bitpay/etc). Expecting to know which payment services provider a given merchant is using is not realistic for users, so I'm skeptical the PKI usage here is of really any value. Note that probably a better solution than requiring a signature over the payment request in the URI is requiring a public key which signs the eventual payment request in the URI. This also resolves the issue of having to get payment providers to get valid SSL/TLS certs for their domain and then use them for a secondary purpose (signing payment requests), which is generally (rightfully) considered bad practice.

@NicolasDorier

This comment has been minimized.

Show comment
Hide comment
@NicolasDorier

NicolasDorier Dec 8, 2017

Member

The PKI usage in BIP70 is rarely used to verify the merchant itself, but is instead some third-party payment services provider (eg coinbase/bitpay/etc). Expecting to know which payment services provider a given merchant is using is not realistic for users, so I'm skeptical the PKI usage here is of really any value

Yes I agree, PKI as used in BIP70 is useless. What I am arguing is that by successfully downloading the payment request over a HTTPS channel, you also verified PKI through whatever arbitrary trust store you use underneath. (OpenSSL, Windows trust store, or iOS trust store)
Most of HTTP libraries in all languages are already doing it out of the box, so there is no need to implement our own.

a better solution than requiring a signature over the payment request in the URI is requiring a public key which signs the eventual payment request in the URI

This is better, but you still have the problem of identity misbinding. How do you know that the public key which sign is coming from the merchant/coinbase? how can you be sure about the identity behind the key without relying on a PKI stack (SSL/TLS) or a web of trust?

Member

NicolasDorier commented Dec 8, 2017

The PKI usage in BIP70 is rarely used to verify the merchant itself, but is instead some third-party payment services provider (eg coinbase/bitpay/etc). Expecting to know which payment services provider a given merchant is using is not realistic for users, so I'm skeptical the PKI usage here is of really any value

Yes I agree, PKI as used in BIP70 is useless. What I am arguing is that by successfully downloading the payment request over a HTTPS channel, you also verified PKI through whatever arbitrary trust store you use underneath. (OpenSSL, Windows trust store, or iOS trust store)
Most of HTTP libraries in all languages are already doing it out of the box, so there is no need to implement our own.

a better solution than requiring a signature over the payment request in the URI is requiring a public key which signs the eventual payment request in the URI

This is better, but you still have the problem of identity misbinding. How do you know that the public key which sign is coming from the merchant/coinbase? how can you be sure about the identity behind the key without relying on a PKI stack (SSL/TLS) or a web of trust?

@TheBlueMatt

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Dec 8, 2017

Contributor

Yes I agree, PKI as used in BIP70 is useless. What I am arguing is that by successfully downloading the payment request over a HTTPS channel, you also verified PKI through whatever arbitrary trust store you use underneath. (OpenSSL, Windows trust store, or iOS trust store)

So what? You haven't gained anything in doing so aside from validating that your attacker is capable of getting an SSL cert issued, which is a free and automated process these days. Not sure what your point is here.

This is better, but you still have the problem of identity misbinding. How do you know that the public key which sign is coming from the merchant/coinbase? how can you be sure about the identity behind the key without relying on a PKI stack (SSL/TLS) or a web of trust?

My point is you dont get that via BIP70 either, and I dont see that changing at any point in the future. Still, you do get this (somewhat) from bitcoin: URIs, as you may expect a user to only click such a link on the expected website's checkout flow (no different from where they enter their credit card). That is a very weak guarantee, but it is infinitely better than what BIP70 provides.

Contributor

TheBlueMatt commented Dec 8, 2017

Yes I agree, PKI as used in BIP70 is useless. What I am arguing is that by successfully downloading the payment request over a HTTPS channel, you also verified PKI through whatever arbitrary trust store you use underneath. (OpenSSL, Windows trust store, or iOS trust store)

So what? You haven't gained anything in doing so aside from validating that your attacker is capable of getting an SSL cert issued, which is a free and automated process these days. Not sure what your point is here.

This is better, but you still have the problem of identity misbinding. How do you know that the public key which sign is coming from the merchant/coinbase? how can you be sure about the identity behind the key without relying on a PKI stack (SSL/TLS) or a web of trust?

My point is you dont get that via BIP70 either, and I dont see that changing at any point in the future. Still, you do get this (somewhat) from bitcoin: URIs, as you may expect a user to only click such a link on the expected website's checkout flow (no different from where they enter their credit card). That is a very weak guarantee, but it is infinitely better than what BIP70 provides.

@NicolasDorier

This comment has been minimized.

Show comment
Hide comment
@NicolasDorier

NicolasDorier Dec 8, 2017

Member

Ah ok I think I understand you now.

bitcoin://?r=https://paymentprovider/id=invoiceId&merchantPubKey=abc

You then remove the PKI verification at BIP70 level (which is, as you said and I agree, useless).
You replace is by a signature embedded in the payment request of this pubkey.

By doing so, you are sure that the payment uri and the payment request are at least bound together.

I was confused because in general this bitcoin: uri is not generated by the merchant's website but by the payment processor. If both, the uri and the payment request is controlled by the payment processor, this scheme is not very useful.

Member

NicolasDorier commented Dec 8, 2017

Ah ok I think I understand you now.

bitcoin://?r=https://paymentprovider/id=invoiceId&merchantPubKey=abc

You then remove the PKI verification at BIP70 level (which is, as you said and I agree, useless).
You replace is by a signature embedded in the payment request of this pubkey.

By doing so, you are sure that the payment uri and the payment request are at least bound together.

I was confused because in general this bitcoin: uri is not generated by the merchant's website but by the payment processor. If both, the uri and the payment request is controlled by the payment processor, this scheme is not very useful.

@MarcoFalke

This comment has been minimized.

Show comment
Hide comment
@MarcoFalke

MarcoFalke Sep 19, 2018

Member

Why was this closed again? I think having an option that is disabled by default makes it easier for people to compile from source without having to pull in a ton of dependencies and build mess. See e.g. #14273, which could simply be worked around by setting --disable-bip70.

Member

MarcoFalke commented Sep 19, 2018

Why was this closed again? I think having an option that is disabled by default makes it easier for people to compile from source without having to pull in a ton of dependencies and build mess. See e.g. #14273, which could simply be worked around by setting --disable-bip70.

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Sep 19, 2018

Member

AFAIK our BIP70 support isn't compatible with Bitpay anyways (because they require spec violating behaviour), so I don't know if that argument for not having this option applies.

Member

gmaxwell commented Sep 19, 2018

AFAIK our BIP70 support isn't compatible with Bitpay anyways (because they require spec violating behaviour), so I don't know if that argument for not having this option applies.

@Sjors

This comment has been minimized.

Show comment
Hide comment
@Sjors

Sjors Sep 20, 2018

Member

@gmaxwell I use BitPay occasionally with Bitcoin Core. The payment goes through just fine, but you get an error popup afterwards.

Member

Sjors commented Sep 20, 2018

@gmaxwell I use BitPay occasionally with Bitcoin Core. The payment goes through just fine, but you get an error popup afterwards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment