Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
Remove copay from the "Choose your Wallet" page #1751
Comments
shesek
commented
Aug 17, 2017
•
|
Agreed. BitPay's plans to migrate away from the Bitcoin protocol without wide community consensus makes them an unsafe wallet that should not be recommended. |
|
Agreed. |
|
There should be a set of guidelines as to which wallets can be listed. Unfortunately as long as open sourcing, not stealing and freezing customers' funds are still not requirements for bitcoin.org (see #1336, #1336 (comment)) CoPay's removal due to misguiding their customers would not be consistent. |
friendsofbitcoin
commented
Aug 17, 2017
|
As far as I am aware the copay app in play store and apple app store is controlled 100% by bitpay's bitcore nodes, thus all copay wallets will indeed have their bitcoin funds frozen and will indeed be at risk of stolen funds without replay protection? |
paOol
commented
Aug 17, 2017
|
Core should add replay protection if worried about users funds as the result of the November hardfork. |
friendsofbitcoin
commented
Aug 17, 2017
|
@paOol This doesn't address the issue with slow historical node upgrades from users. Many users are going to be harmed by a hardfork spinoff lacking replay protection regardless if core adds replay protection or not. |
mariodian
commented
Aug 17, 2017
|
@friendsofbitcoin you can point Copay to your own server though. |
|
Agreed. By supporting a hard fork without replay protection, users can lose their coins on the main/core chain. You can set a custom backend server but i think very few users know about this. But we need to adapt the requierements for wallets first. |
|
ACK. |
friendsofbitcoin
commented
Aug 17, 2017
|
@mariodian while true the "Choose your wallet" page is primarily used to educate new users and 99.9% of them won't know how to setup a custom bitcore server or make those changes. We need to focus on risk mitigation and reducing loss of funds for new users. |
|
Maybe I'm misreading the page, but I don't think it says what's being claimed in this thread. Specifically, it says:
The rest of the instructions are about running a border node, specifically the HF'ing btc1. If you use Bitcoin Core 0.12.1 with a btc1 border node, you will not hard fork because Bitcoin Core 0.12.1 will not hard fork. Instead, the btc1 border node will accept the segwit2x mandatory >1MB hard fork block and relay it to the Bitcoin Core 0.12.1 node---but, critically, the Bitcoin Core 0.12.1 node will reject it as having an invalid block size. At that point, Copay and other Insight-based won't show any further confirmations for transactions made after the HF block. That's not good and we should certainly request that the Copay wallet authors address that concern, but (if I'm understanding this correctly) I don't think this requires immediately delisting under Bitcoin.org's hard fork policy. |
friendsofbitcoin
commented
Aug 17, 2017
|
@harding Good observation, except the last paragraph explains that in several weeks users will no longer need to run boundary nodes and the concern here is these lite clients push self upgrades in smart phones |
|
|
lichtamberg
commented
Aug 17, 2017
|
Full ACK |
d1gitalflow
commented
Aug 17, 2017
•
|
ACK See here: bitpay/bitcore-lib#50 They seem to have no intention of adding that commit that is mostly a year and half long coding to support segwit, and prefer to redirect users to a fork/altcoin. |
olalonde
commented
Aug 17, 2017
|
Segwit2x is not contentious, it is supported by most of the hash rate. |
chrisrico
commented
Aug 17, 2017
|
@friendsofbitcoin Copay is not "100% controlled" by Bitpay's Bitcore nodes. You can change to point at your own node, theirs are merely the default. |
friendsofbitcoin
commented
Aug 17, 2017
|
@olalonde A few industrial miners doesn't represent the whole ecosystem. segwit2x is supported by a mere 21% of companies - https://coin.dance/poli over 99% of full nodes aren't running btc1 and normal node upgrade speed is longer than 3 months - http://luke.dashjr.org/programs/bitcoin/files/charts/software.html Here is a comprehensive list of companies who still have not agreed - http://nob2x.org/ @chrisrico I have already acknowledged this, please read my comment addressed to @mariodian |
|
If someone wants to fork Copay, and adjust it to always stick to Bitcoin, that fork can be added. Copay itself seems to likely default to an altcoin, so it shouldn't be listed. |
runn1ng
commented
Aug 17, 2017
•
|
Copay servers are currently running on a software based on an old version of bitcoin, so currently it's bitcoin. Copay is not supporting segwit in any way, so it doesn't matter that they use 0.12.something Currently, bitcore is not running on bcoin (sic), but they are migrating to it - see https://github.com/bitpay/bitcore-node/commits/blocks . (Copay is using bitcore-wallet-service, which is using bitcore, which is using old bitcoin core but migrating to bcoin.) Right now, they are still technically on bitcoin chain, no matter what they do or don't recommend. I do not know your rules, but currently, they are using bitcoin. |
runn1ng
commented
Aug 17, 2017
|
Currently, you cannot run bitcore/insight/copay/... with segwit2x node. Not sure in what stadium is the bcoin implementation. bcoin is used there as the full node. I do not know which rules do bcoin support, but given their tone, I would guess they will use 2x rules. But yeah, they are indicating they will make users switch, so maybe removal is justified in the end |
olalonde
commented
Aug 17, 2017
•
|
The original chain will slow to a crawl and become vulnerable to 51% attacks soon after the hard fork though. I think it would be reasonable for Bitcoin.org to err on the side of caution/security and recommend wallets which will follow SegWit2x (and maybe have some visible warning/notification which explains the fork). |
friendsofbitcoin
commented
Aug 17, 2017
|
@olalonde Over 99% of full nodes don't run btc1 . Even if we were so reckless to support segwit2x this would not protect many users from the damage caused by a rushed HF due to the slow upgrade path users take and lack of ability to communicate to everyone effectively. Thus we must cautiously avoid actions which place them at risk from loss of funds. |
shesek
commented
Aug 17, 2017
•
I think that expressing the intent to diverge away from the bitcoin chain to a new protocol that didn't gain community consensus is enough of a reason for removal, as a preemptive step against the future losses this would cause to the wallet's users. But I'm not sure what are the rules either.
I'm working on making that happen. If anyone wants to help, shot me an email at nadav@bitrated.com. |
runn1ng
commented
Aug 17, 2017
•
|
@shesek you will need to run a server yourself probably. If you want to run bitcore node with 0.14.2, start here https://github.com/satoshilabs/bitcore If you are OK with running old node - again, since copay does not use segwit in any way, so you should be OK with that - you can just use bitpay's own repo. BWS runs on top of that. Note that you will need at least 300GB of space for bitcore alone, and probably should be an SSD, and should be a stable webserver. Good luck. |
jgarzik
commented
Aug 17, 2017
|
NAK. What happens if you continue to remove wallets that follow the blockchain w/ most hashpower? Users are left with tiny list of holdouts that point to an insecure, slow chain. |
friendsofbitcoin
commented
Aug 17, 2017
|
@jgarzik There shouldn't be a problem to re-add copay from a different repo that doesn't place users funds at risk. |
|
@olalonde Why should Bitcoin.org recommend an altcoin just because SHA2 miners defect to it? That's absurd. |
shesek
commented
Aug 18, 2017
•
|
@jgarzik The miners do not dictate bitcoin's rules. Bitcoin would be completely useless if they did. |
TheButterZone
commented
Aug 18, 2017
|
ACK |
olalonde
commented
Aug 18, 2017
|
@luke-jr because Bitcoin's security model is based on the assumption that no single entity controls 50+% of the hash rate. This assumption goes out of the window after the Segwit2x hard fork. There will probably be more than one entity capable of attacking the old chain due to its low difficulty. If you don't want to follow the hash rate, you are left with changing the PoW algorithm. |
|
ACK What BitPay did is a remarkably deceptive and dishonest thing to do. We should not advertise wallets from dishonest companies, so BitPay is out until they somehow restore that trust. |
JavierGonzalez
commented
Aug 18, 2017
•
|
@luke-jr Bitcoin is based on proof of work for a security reason (resistance to multiple hostile nations is required). If you want a currency based on "developers who like takeovers" please create an altcoin. Please try that without fucking Bitcoin. |
JavierGonzalez
commented
Aug 18, 2017
•
@shesek I think you're totally wrong. The GitHub hierarchy is like the IRC. A currency based on this shit will never be worth anything. Bitcoin is based on PoW. Bitcoin is in the hands of the miners totally. |
shesek
commented
Aug 18, 2017
•
|
Bitcoin is based on PoW for the purpose of ordering transactions into blocks and preventing the double-spend attack, not for determining protocol rules. See Bitcoin is not ruled by miners. |
JavierGonzalez
commented
Aug 18, 2017
•
|
@shesek That was true until some have broken the monopoly of Bitcoin Core by developing multiple client programs. Miners will deploy nodes as needed when needed. As you know, nodes can not cast a negative vote. This brings us to reality: The miners rules entirely in a PoW-based crypto. PD: And changing the algorithm only changes some miners for others, and eventually we will return to the same conflict: the attempt to steal future commissions from ASIC/GPU miners. |
vedran6
commented
Aug 18, 2017
•
|
ACK A network split is a bad thing in and of itself, but more sophisticated users have the ability to choose what chain to follow. What Bitpay did is dangerous and dishonest because:
|
windsok
commented
Aug 18, 2017
|
ACK |
omarshibli
commented
Aug 18, 2017
|
Hey @shesek This is a great idea, How may I help? Please send more info at omar@commerceblock.com Good luck and keep up the good work. |
CosmicHemorroid
commented
Aug 18, 2017
|
ACK |
Copay does not appear to use the SPV security model where the wallet follows the most hashpower, it uses the centralized validator model where a centralized authority is effectively trusted blindly for confirmations, this( |
SquirrelCoder
commented
Aug 18, 2017
|
Then which wallet do you recommend? |
is55555
commented
Aug 18, 2017
|
ACK |
runn1ng
commented
Aug 18, 2017
|
This debate is stupid There is no reason why should bitcoin core website show a wallet, that does not support bitcoin core consensus rules and has its own consensus rules. Unless we want to go into philosophical discussion of "what is bitcoin?" and "is bitcoin ABC bitcoin?" and "is bitcoin 2x / Unlimited / Classic / ??? bitcon?". Which is beyond the scope of this issue. The only reason against removing copay is that right now it uses backend with bitcoin core consensus rules, but that will probably change. So... yeah remove it |
JavierGonzalez
commented
Aug 18, 2017
•
|
This space is censored. |
|
I think there are two separate issues. Do I wish bitcoin.org was little bit easier to add things to. Yes. But, Copay/BitPay wont be doing bitcoin anymore, they have no place here. Support or don't support NYA, what matters for here is which software the projects are running. |
|
Resolved by #1752. |
friendsofbitcoin commentedAug 17, 2017
https://archive.fo/U8v26#selection-215.25-215.100
Bitpay recently began to deceptively promote a contentious hard fork proposal and encouraging all bitcore nodes to upgrade to a consensus splitting change without replay protection which would endanger many users running copay or bitpay wallets.
Lack of clarity on the risks this poses to users and dishonest representation make this wallet unsuitable for the time being for recommendation.