Topic: Why Using SSL's PKI For BIP 70 is a Big Mistake (Read 1862 times)
For those who may be looking for a way to implement this I have a template in my github repo here using python 2.7
Many people would be so happy, if guys like Adam Beck, Andreas Antonopoulos, Gregory Maxwell or Peter Todd would lead the project.
No one would complain. Because they are trusted to share, argue and work/fight for Bitcoins real values & ideas following Satoshis intentions & goals.
No one would complain. Because they are trusted to share, argue and work/fight for Bitcoins real values & ideas following Satoshis intentions & goals.
They won't change it and won't understand/acknowledge why it matters and is wrong.
Hearn and Andresen both work for big Bitcoin payment processing companies. So they design the payment protocol in a way, that it favours their employer. Making it complex and expensive, introducing technologies (SSL) and ideas, that they know won't get accepted in the community, so market share and influence of their companies are kept and newcomers are excluded, direct payment processing by merchants (without PSPs between) gets less attractive, ...
Hearn and Andresen both are gang leaders at the "Bitcoin Foundation", an American business club of VC funded companies and professionell scamming entrepreneurs. These people welcome any form of surveillance, regulation, standardization of ideas that are against Bitcoin values & ideas and the use of backdoored, commercial, patented, proprietary technologies for various reasons.
Last but not least, both are controlled by US intelligence services in an attempt to manipulate/misguide and sabotage Bitcoin development.
They don't share the values of the orginal Bitcoin paper or the Bitcoin community (anymore).
So everybody understands your thread. But BIP70 won't be changed.
Hearn and Andresen both work for big Bitcoin payment processing companies. So they design the payment protocol in a way, that it favours their employer. Making it complex and expensive, introducing technologies (SSL) and ideas, that they know won't get accepted in the community, so market share and influence of their companies are kept and newcomers are excluded, direct payment processing by merchants (without PSPs between) gets less attractive, ...
Hearn and Andresen both are gang leaders at the "Bitcoin Foundation", an American business club of VC funded companies and professionell scamming entrepreneurs. These people welcome any form of surveillance, regulation, standardization of ideas that are against Bitcoin values & ideas and the use of backdoored, commercial, patented, proprietary technologies for various reasons.
Last but not least, both are controlled by US intelligence services in an attempt to manipulate/misguide and sabotage Bitcoin development.
They don't share the values of the orginal Bitcoin paper or the Bitcoin community (anymore).
So everybody understands your thread. But BIP70 won't be changed.
This is what happens if you don't adjust your tinfoil hat properly. Too tight and it cuts off circulation to your brain.
Meanwhile, back in reality, cacert is just a root cert. If you want to use cacert, just add their root to your OS cert store. If you want to use cacert exclusively, also remove the other root certs.
A not insignificant number of developers think pragmatism >>> principle. It sucks, but it is what it is.
Fuck them.'Cuz all well respected developers think principle >>> pragmatism.
A not insignificant number of developers think pragmatism >>> principle. It sucks, but it is what it is.
Here's a realistic way to look at it
Most people who matter in this debate are just not in a position where they'll immediately switch to 2 different systems in their organisation, especially when these are seen as competing solutions to things they already have.
If the dev team were rejecting implementations of alternatives for spurious reasons, I'd understand this POV. But so far, no-one's had any alternative rejected. I'd much prefer something like CA Cert though, and would almost certainly use that as an alternative to just using raw addresses or X.509.
- The majority accepting Bitcoin payments uses X.509 anyway, out of ignorance or laziness
- Someone implements CA Cert and/or any other verification scheme and gets it accepted into the Bitcoin Core codebase
- Time passes, people depend on bitcoin payments, problems with X.509 occur
- Solution is already integrated, tested and ready to use. Case to switch proven. Minimal impact to switchover
Most people who matter in this debate are just not in a position where they'll immediately switch to 2 different systems in their organisation, especially when these are seen as competing solutions to things they already have.
If the dev team were rejecting implementations of alternatives for spurious reasons, I'd understand this POV. But so far, no-one's had any alternative rejected. I'd much prefer something like CA Cert though, and would almost certainly use that as an alternative to just using raw addresses or X.509.
They won't change it and won't understand/acknowledge why it matters and is wrong.
Hearn and Andresen both work for big Bitcoin payment processing companies. So they design the payment protocol in a way, that it favours their employer. Making it complex and expensive, introducing technologies (SSL) and ideas, that they know won't get accepted in the community, so market share and influence of their companies are kept and newcomers are excluded, direct payment processing by merchants (without PSPs between) gets less attractive, ...
Hearn and Andresen both are gang leaders at the "Bitcoin Foundation", an American business club of VC funded companies and professionell scamming entrepreneurs. These people welcome any form of surveillance, regulation, standardization of ideas that are against Bitcoin values & ideas and the use of backdoored, commercial, patented, proprietary technologies for various reasons.
Last but not least, both are controlled by US intelligence services in an attempt to manipulate/misguide and sabotage Bitcoin development.
They don't share the values of the orginal Bitcoin paper or the Bitcoin community (anymore).
So everybody understands your thread. But BIP70 won't be changed.
Hearn and Andresen both work for big Bitcoin payment processing companies. So they design the payment protocol in a way, that it favours their employer. Making it complex and expensive, introducing technologies (SSL) and ideas, that they know won't get accepted in the community, so market share and influence of their companies are kept and newcomers are excluded, direct payment processing by merchants (without PSPs between) gets less attractive, ...
Hearn and Andresen both are gang leaders at the "Bitcoin Foundation", an American business club of VC funded companies and professionell scamming entrepreneurs. These people welcome any form of surveillance, regulation, standardization of ideas that are against Bitcoin values & ideas and the use of backdoored, commercial, patented, proprietary technologies for various reasons.
Last but not least, both are controlled by US intelligence services in an attempt to manipulate/misguide and sabotage Bitcoin development.
They don't share the values of the orginal Bitcoin paper or the Bitcoin community (anymore).
So everybody understands your thread. But BIP70 won't be changed.
The point is that HTTPS is flawed in a number of ways, though more political than technical. (He who controls the CA's controls the world. The CA's charge a shitload of money for certs, but hardly do any verification and refuse to be held liable when they issue a cert to a known phishing site, etc.)
Bitcoin could write its own protocol, or else include the CA Cert root certificates in the clients by default. Otherwise, as Grigg has pointed out, Bitcoin merchants will find themselves at the mercy of CA's in order to accept Bitcoin payments. That hands control over a substantial part of the Bitcion network back to the Establishment.
If you don't want to do a better protocol than HTTPS, then at least include the CA Cert root certificates in every client so Bitcoin merchants can use a decentralized CA without paying exorbitant fees for SSL certs.
Bitcoin could write its own protocol, or else include the CA Cert root certificates in the clients by default. Otherwise, as Grigg has pointed out, Bitcoin merchants will find themselves at the mercy of CA's in order to accept Bitcoin payments. That hands control over a substantial part of the Bitcion network back to the Establishment.
If you don't want to do a better protocol than HTTPS, then at least include the CA Cert root certificates in every client so Bitcoin merchants can use a decentralized CA without paying exorbitant fees for SSL certs.
The dev team recently announced the decision to chose SSL's PKI for the new Bitcoin merchant API , called BIP 70.
Mike Hearn defended the choice in this article by claiming that nobody offered any workable alternatives.
However, CACert is an alternative that works and should be considered for three reasons:
1. CACert works with SSL. It is a decentralized Certificate Authority that does not charge for SSL certs, with 20,000 members.
2. CACert has a working arbitration forum that has the potential to solve many of the problems that crop up with Bitcoin - the lack of trust and enforcability of contracts between users across national borders.
3. CACert has thus far successfully repelled attempts by intelligence agencies to insert their people into key positions in the organization.
In this article at financialcryptography.com, Ian Grigg argues that Bitcoin is throwing the baby out with the bathwater by adopting the mainstream SSL PKI.
Grigg says:
The Bitcoin community is exactly the kind of community that has the chops to provide a much needed alternative to the centralized corrupt corporate SSL PKI. If they aren't willing to give it a go, at least use CA Cert which is far more in line with Bitcoin's ethos.
Mike Hearn defended the choice in this article by claiming that nobody offered any workable alternatives.
However, CACert is an alternative that works and should be considered for three reasons:
1. CACert works with SSL. It is a decentralized Certificate Authority that does not charge for SSL certs, with 20,000 members.
2. CACert has a working arbitration forum that has the potential to solve many of the problems that crop up with Bitcoin - the lack of trust and enforcability of contracts between users across national borders.
3. CACert has thus far successfully repelled attempts by intelligence agencies to insert their people into key positions in the organization.
In this article at financialcryptography.com, Ian Grigg argues that Bitcoin is throwing the baby out with the bathwater by adopting the mainstream SSL PKI.
Grigg says:
Quote
But what's the alternative, Mike Hearn asks? His fundamental claim seems to stand: there isn't a clear alternative. This is true. If you ignore Bitcoin's purpose in life, if you ignore your own capabilities and you ignore [the Bitcoin] community, then ... I agree! If you ignore CAcert, too, I agree. There is no alternate.
The Bitcoin community is exactly the kind of community that has the chops to provide a much needed alternative to the centralized corrupt corporate SSL PKI. If they aren't willing to give it a go, at least use CA Cert which is far more in line with Bitcoin's ethos.
All HTTPS coomunication is based on PKI, anyway. Even BIP70 does nothing better, it won't be worse
BTW, I think one could simply import the CAcert CA to the BIP70-compliant client
The dev team recently announced the decision to chose SSL's PKI for the new Bitcoin merchant API , called BIP 70.
Mike Hearn defended the choice in this article by claiming that nobody offered any workable alternatives.
However, CA Cert is an alternative that works and should be considered for three reasons:
1. CA Cert works with SSL. It is a decentralized Certificate Authority that does not charge for SSL certs, with 20,000 members.
2. CA Cert has a working arbitration forum that has the potential to solve many of the problems that crop up with Bitcoin - the lack of trust and enforcability of contracts between users across national borders.
3. CA Cert has thus far successfully repelled attempts by intelligence agencies to insert their people into key positions in the organization.
In this article at financialcryptography.com, Ian Grigg argues that Bitcoin is throwing the baby out with the bathwater by adopting the mainstream SSL PKI.
Grigg says:
The Bitcoin community is exactly the kind of community that has the chops to provide a much needed alternative to the centralized corrupt corporate SSL PKI. If they aren't willing to give it a go, at least use CA Cert which is far more in line with Bitcoin's ethos.
Mike Hearn defended the choice in this article by claiming that nobody offered any workable alternatives.
However, CA Cert is an alternative that works and should be considered for three reasons:
1. CA Cert works with SSL. It is a decentralized Certificate Authority that does not charge for SSL certs, with 20,000 members.
2. CA Cert has a working arbitration forum that has the potential to solve many of the problems that crop up with Bitcoin - the lack of trust and enforcability of contracts between users across national borders.
3. CA Cert has thus far successfully repelled attempts by intelligence agencies to insert their people into key positions in the organization.
In this article at financialcryptography.com, Ian Grigg argues that Bitcoin is throwing the baby out with the bathwater by adopting the mainstream SSL PKI.
Grigg says:
Quote
But what's the alternative, Mike Hearn asks? His fundamental claim seems to stand: there isn't a clear alternative. This is true. If you ignore Bitcoin's purpose in life, if you ignore your own capabilities and you ignore [the Bitcoin] community, then ... I agree! If you ignore CAcert, too, I agree. There is no alternate.
The Bitcoin community is exactly the kind of community that has the chops to provide a much needed alternative to the centralized corrupt corporate SSL PKI. If they aren't willing to give it a go, at least use CA Cert which is far more in line with Bitcoin's ethos.
Jump to: