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

laanwj · 2017-11-06T18:16:53Z

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 · 2017-11-06T20:16:25Z

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 · 2017-11-06T20:54:39Z

Concept ACK after reading the discussion on IRC

promag · 2017-11-07T00:47:10Z

Should add to travis matrix?

NicolasDorier · 2017-11-07T01:01:38Z

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 · 2017-11-07T06:25:00Z

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.

luke-jr · 2017-11-07T06:30:44Z

src/Makefile.qt.include

@@ -161,6 +160,9 @@ QT_MOC_CPP = \
  qt/moc_walletmodel.cpp \
  qt/moc_walletview.cpp

+QT_MOC_CPP_BIP70 = \


IMO would be cleaner to just QT_MOC_CPP += (and BITCOIN_QT_CPP +=) the actual files below, keeping all the stuff together.

I agree, but I just followed the flow already used in the makefile for the wallet, to not have to move large blocks around (which complicates review). A refactor like that could be done separately.

luke-jr · 2017-11-07T06:31:54Z

configure.ac

@@ -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"


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

Yep. Although that breaks the alignment...

luke-jr · 2017-11-07T06:33:05Z

src/qt/bitcoin.cpp

@@ -250,8 +252,10 @@ public Q_SLOTS:
    ClientModel *clientModel;
    BitcoinGUI *window;
    QTimer *pollShutdownTimer;
-#ifdef ENABLE_WALLET
+#if defined(ENABLE_WALLET) && defined(ENABLE_BIP70)


Might be less messy to just leave the pointer here and not use it.

I don't think I agree. Accidentally using it would not generate a compile error in that case anymore.

Can't we just allow ENABLE_BIP70 if ENABLE_WALLET is true? In that case #if defined(ENABLE_BIP70) would be enough all over the place.

That'd make sense (ENABLE_BIP70 implying ENABLE_WALLET).

luke-jr · 2017-11-07T06:34:08Z

src/qt/bitcoin.cpp

@@ -659,7 +667,7 @@ int main(int argc, char *argv[])
    // Re-initialize translations after changing application name (language in network-specific settings can be different)
    initTranslations(qtTranslatorBase, qtTranslator, translatorBase, translator);

-#ifdef ENABLE_WALLET
+#if defined(ENABLE_WALLET) && defined(ENABLE_BIP70)


Won't this break opening non-BIP70 bitcoin: URIs?

Yes, as a by-effect this currently removes bitcoin: URL support too.
(it probably shouldn't)

That would break opening links from a browser or a mail client.

luke-jr · 2017-11-07T06:34:36Z

src/qt/coincontroldialog.cpp

 #include "coincontroldialog.h"
 #include "ui_coincontroldialog.h"

 #include "addresstablemodel.h"
+#include "base58.h"


These changes seem out of place here...?

These extra includes are necessary now that paymentserver.h doesn't indirectly include them anymore.

luke-jr · 2017-11-07T06:34:54Z

src/qt/guiutil.cpp

@@ -9,6 +9,8 @@
 #include "qvalidatedlineedit.h"
 #include "walletmodel.h"

+#include "base58.h"
+#include "chainparams.h"


More out of place...

luke-jr · 2017-11-07T06:37:19Z

src/qt/test/compattests.cpp

 #include "paymentrequestplus.h" // this includes protobuf's port.h which defines its own bswap macos
+#endif


Do we need to get bswap macros from somewhere else?

No, we have our own bswap macros. The only reason this is tested is that there was a collision between our bswap macros and protobuf's. So commenting this out is harmless.

luke-jr · 2017-11-07T06:38:11Z

src/qt/test/wallettests.cpp

@@ -1,5 +1,6 @@
 #include "wallettests.h"

+#include "base58.h"


Out of place

Sjors · 2017-11-09T11:38:37Z

"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 · 2017-11-09T11:44:14Z

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 · 2017-11-09T15:51:13Z

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 · 2017-11-10T16:34:03Z

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

laanwj · 2017-11-10T17:13:04Z

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

Whoops, missed that. Fixed.

sipa · 2017-11-11T00:14:17Z

Concept ACK

jonasschnelli · 2017-11-11T06:58:34Z

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 · 2017-11-11T07:25:37Z

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)

luke-jr · 2017-11-11T12:22:38Z

src/qt/bitcoin.cpp

@@ -647,7 +651,7 @@ int main(int argc, char *argv[])
        QMessageBox::critical(0, QObject::tr(PACKAGE_NAME), QObject::tr("Error: %1").arg(e.what()));
        return EXIT_FAILURE;
    }
-#ifdef ENABLE_WALLET


We need this for BIP21 too.

Sjors · 2017-11-13T12:57:12Z

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 · 2017-11-13T13:25:16Z

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

Thanks, added, also rebased and squashed.

Sjors · 2017-11-13T14:09:45Z

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

fanquake · 2017-11-17T14:07:42Z

Concept ACK. Needs another rebase.

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.

TheBlueMatt · 2017-12-04T17:38:44Z

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 · 2017-12-05T05:41:35Z

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 · 2017-12-06T20:53:27Z

@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 · 2017-12-07T01:42:47Z

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 · 2017-12-08T00:11:34Z

@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 · 2017-12-08T05:35:43Z

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 · 2017-12-08T15:29:49Z

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 · 2017-12-08T15:42:40Z

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 · 2017-12-08T15:46:11Z

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 · 2017-12-08T16:11:02Z

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.

maflcko · 2018-09-19T21:54:03Z

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 · 2018-09-19T22:26:28Z

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 · 2018-09-20T09:47:55Z

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

…thout BIP70 support 48439b3 Don't link SSL_LIBS with GUI unless BIP70 is enabled (James Hilliard) fbb643d Add BIP70 deprecation warning (James Hilliard) 38b9850 qt: cleanup: Move BIP70 functions together in paymentserver (Wladimir J. van der Laan) 9dcf6c0 build: Add --disable-bip70 configure option (Wladimir J. van der Laan) Pull request description: This is based off of #11622 and adds a deprecation warning when a BIP70 URL is used. Rational: - BIP70 increases attack surface in multiple ways and is difficult for third party wallets to implement in a secure manner - Very few merchants use the standard BIP70 variant supported by Bitcoin Core - The one major payment processor that doesn't support BIP21 and currently uses a customized non-standard version of BIP70 has indicated that "Unfortunately the original BIP70 is not useful for us." Tree-SHA512: 1e16ee8d2cdac9499f751ee7b50d058278150f9e38a87a47ddb5105dd0353cdedabe462903f54ead6209b249b249fe5e6a10d29631531be27400f2f69c25b9b9

fanquake · 2018-12-09T13:36:52Z

Removed "Up for grabs", this was done in #14451.

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. Github-Pull: bitcoin#11622 Rebased-From: 04c52eb

… GUI without BIP70 support 48439b3 Don't link SSL_LIBS with GUI unless BIP70 is enabled (James Hilliard) fbb643d Add BIP70 deprecation warning (James Hilliard) 38b9850 qt: cleanup: Move BIP70 functions together in paymentserver (Wladimir J. van der Laan) 9dcf6c0 build: Add --disable-bip70 configure option (Wladimir J. van der Laan) Pull request description: This is based off of bitcoin#11622 and adds a deprecation warning when a BIP70 URL is used. Rational: - BIP70 increases attack surface in multiple ways and is difficult for third party wallets to implement in a secure manner - Very few merchants use the standard BIP70 variant supported by Bitcoin Core - The one major payment processor that doesn't support BIP21 and currently uses a customized non-standard version of BIP70 has indicated that "Unfortunately the original BIP70 is not useful for us." Tree-SHA512: 1e16ee8d2cdac9499f751ee7b50d058278150f9e38a87a47ddb5105dd0353cdedabe462903f54ead6209b249b249fe5e6a10d29631531be27400f2f69c25b9b9

laanwj added Build system GUI Wallet labels Nov 6, 2017

luke-jr reviewed Nov 7, 2017

View reviewed changes

laanwj force-pushed the 2017_11_bip70_disable branch 3 times, most recently from c67de2e to a23a648 Compare November 9, 2017 15:49

laanwj force-pushed the 2017_11_bip70_disable branch from a23a648 to 197188a Compare November 9, 2017 18:08

luke-jr reviewed Nov 11, 2017

View reviewed changes

laanwj force-pushed the 2017_11_bip70_disable branch 2 times, most recently from 7844b28 to 7311492 Compare November 13, 2017 13:24

Sjors mentioned this pull request Nov 18, 2017

iOS Deployment Target for RPC #11720

Closed

1 task

build: Add --disable-bip70 configure option

04c52eb

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.

Sjors mentioned this pull request Feb 24, 2018

Remove OpenSSL for non-QT builds #12530

Closed

maflcko added the Up for grabs label Sep 19, 2018

laanwj mentioned this pull request Oct 9, 2018

qt: Revert "Force TLS1.0+ for SSL connections" #14403

Merged

jameshilliard mentioned this pull request Oct 9, 2018

Add BIP70 deprecation warning and allow building GUI without BIP70 support #14451

Merged

fanquake removed the Up for grabs label Dec 9, 2018

MaxHillebrand mentioned this pull request Jul 11, 2019

Integrate Payment Protocol from Bitpay (BIP 70) zkSNACKs/zIPs#28

Closed

bitcoin locked as resolved and limited conversation to collaborators Feb 15, 2022

		#include "paymentrequestplus.h" // this includes protobuf's port.h which defines its own bswap macos
		#endif

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

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

Conversation

laanwj commented Nov 6, 2017

TheBlueMatt commented Nov 6, 2017

meshcollider commented Nov 6, 2017

promag commented Nov 7, 2017

NicolasDorier commented Nov 7, 2017 • edited

laanwj commented Nov 7, 2017 • edited

luke-jr left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

laanwj Nov 7, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

laanwj Nov 7, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

promag Nov 7, 2017 • edited

Choose a reason for hiding this comment

laanwj Nov 7, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

laanwj Nov 7, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Sjors commented Nov 9, 2017

laanwj commented Nov 9, 2017 • edited

laanwj commented Nov 9, 2017

luke-jr commented Nov 10, 2017

laanwj commented Nov 10, 2017

sipa commented Nov 11, 2017

jonasschnelli commented Nov 11, 2017

laanwj commented Nov 11, 2017 • edited

Choose a reason for hiding this comment

Sjors commented Nov 13, 2017

laanwj commented Nov 13, 2017

Sjors commented Nov 13, 2017 • edited

fanquake commented Nov 17, 2017

TheBlueMatt commented Dec 4, 2017 • edited

NicolasDorier commented Dec 5, 2017 • edited

TheBlueMatt commented Dec 6, 2017

NicolasDorier commented Dec 7, 2017

TheBlueMatt commented Dec 8, 2017

NicolasDorier commented Dec 8, 2017

TheBlueMatt commented Dec 8, 2017

NicolasDorier commented Dec 8, 2017 • edited

TheBlueMatt commented Dec 8, 2017

NicolasDorier commented Dec 8, 2017 • edited

maflcko commented Sep 19, 2018 • edited

gmaxwell commented Sep 19, 2018

Sjors commented Sep 20, 2018

fanquake commented Dec 9, 2018

NicolasDorier commented Nov 7, 2017 •

edited

laanwj commented Nov 7, 2017 •

edited

laanwj Nov 7, 2017 •

edited

laanwj Nov 7, 2017 •

edited

promag Nov 7, 2017 •

edited

laanwj Nov 7, 2017 •

edited

laanwj Nov 7, 2017 •

edited

laanwj commented Nov 9, 2017 •

edited

laanwj commented Nov 11, 2017 •

edited

Sjors commented Nov 13, 2017 •

edited

TheBlueMatt commented Dec 4, 2017 •

edited

NicolasDorier commented Dec 5, 2017 •

edited

NicolasDorier commented Dec 8, 2017 •

edited

NicolasDorier commented Dec 8, 2017 •

edited

maflcko commented Sep 19, 2018 •

edited