Remove Trezor from Choose your Wallet Page #1564
Conversation
Removes Trezor from choose your wallet page
|
Trezor already supports other altcoins (e.g. Ethereum, Litecoin, DASH and Zcash), that's never been a reason to remove them before. |
|
I can understand your point somehow, but since there are several wallets which support multiple currencies, I don't see why trezor should be removed. Also hardware wallets usually dont have to do anything, to be UASF ready: https://i.imgur.com/fT1vbEB.png NACK |
|
I was going to write something else, but first I would ask for a source on "bitcoin.org does not promote wallets that attempt to alter (or follow nodes that do alter) the existing consensus without overwhelming support" |
It's consistent bitcoin.org policy, we've applied the same standard during the Bitcoin XT situation too. This is bitcoin.org, and not chooseyourflavorofbitcoin.org. We can't just go along haphazardly promoting wallets that redefine what they see as "Bitcoin" on a whim. All users expect consistency, and shouldn't be expected to pick out what flavour of Bitcoin they want. There's no indication that Trezor will label the UASF chain as "UASFCoin", so it's unclear to me whether they're going to try to present it as a flavour of Bitcoin (which confuses users) or just label it as "Bitcoin". Either way, UASFCoin is not Bitcoin, and if a service claims to be ready for it, then they need to be clear that they're going to present it as an alt (which as of right now, it would almost certainly be, but that might change in the future). |
|
@slush0 maybe you want to comment? |
|
The Trezor itself is a UASF-unaware device, I think, sort of like SPV wallets are unaware of such things. I'd guess that that tweet is merely indicating that the Trezor would not fail if connected to a wallet that follows UASF. This does not make it a non-Bitcoin device IMO. If on the other hand they're saying that the Trezor web service will by default convert BTC to UASF-coins, then removing it may be reasonable, but I suspect that this is not the case. |
|
@theymos The worry is what the user will see presented to them on the Trezor web wallet service as "BTC" (or whether that will even happen, maybe they're suddenly presented with a confusing choice of flavour of BTC). @slush0 Can you clarify about whether you plan on supporting two flavours of Bitcoin? Since there can't be two Bitcoin's at once, it's important that any UASF chain must be labelled as UASFCoin, or given a unique name so as to not be confused with Bitcoin until such time that it becomes Bitcoin through overwhelming consensus. |
|
NACK. When we review hardware wallet devices, we review them separately from their software wallets, so even if we felt a particular software wallet should not be listed, that should not affect the hardware wallet device(s) supported by that software. I don't believe that the hardware device has been changed in any way. |
|
I think TREZOR is just voicing readiness for implementation of BIP 148 (UASF) to Bitcoin Core, if it progresses beyond a draft. Also, it's my understanding that the percentage of nodes some in the community are referring to that are in favor of UASF aren't actually "signaling" from a technical standpoint, running an alternative client or modified software. They're running official versions of Bitcoin Core and setting I'm failing to understand why any of the above would preclude TREZOR from being a part of the site. |
|
TREZOR is just a signing device and is blockchain-unaware. TREZOR Wallet (browser UI for TREZOR) already support BTC, DASH, LTC, Zcash and will support BIP148/UASF in the same manner - by separate backend running on BIP148 code, so people will have choice to pick which coin they want to use. I don't see any problem here. Please calm down and close the PR. |
|
NACK. Removing TREZOR seems to be very wired. |
|
NACK. This PR seems a little rash. Signalling UASF readiness for the Web Wallet should not lead to the removal of the agnostic hardware wallet. Also scheduling a merge date before having even a discussion on such a controversial topic is not the way bitcoin.org should be run. |
|
NACK. As stated hardware wallets are UASF agnostic and it's pretty clear that the plan is not to push a different chain as being Bitcoin. |
|
this is f. ridiculous. Go get yourself a job and stop waisting other people time. |
|
Bitcoin.org is no longer a reliable source of bitcoin information. |
|
NACK. It's not clear if UASF will reach consensus or not at this point. If UASF doesn't reach consensus and Trezor still insist then ACK. |
|
IMO I would draw the line on overwhelming HF and any SF consensus client should be allowed. |
|
This policy doesn't make anyone any more safe. If you did manage to pressure trezor into only supporting the most-worked upon chain, and the UASF happens -- then all the users are at risk from a potential reorg wipeout. This is really what makes the UASF rather dangerous, you need to pick between being a potential minority chain or being on a chain that might end up wiped out. I think it's best left up to trezor to how to handle it in a way that's safest for their users. |
|
Everything @slush0 said. NACK |
|
NACK |
|
Per @Slush comment, this is a NACK. But I agree with having posted this for discussion. UASF is very risky and trezor seems to understand the problem correctly. Please unschedule this merge. |
@slush0 Will UASF coin initially be presented as an alt coin and clearly marked as such on your service and not as "BTC"? Or will it be presented as a flavour of Bitcoin? |
|
Who are we to attempt to dictate what people are allowed to label as the bitcoin? Frankly I don't think it matters that much, as long as Trezor users will be able to access coins on all live chains, which @slush0 has made clear is the case. I think this measure is uncalled for because it is clear there is no risk to users losing their coin on either chain through the actions of Trezor. NACK. |
|
@Cobra-Bitcoin Does it matter? This is about the TREZOR hardware wallet, not the TREZOR Web Wallet. To quote https://bitcoin.org/en/choose-your-wallet
|
|
@Cobra-Bitcoin doesn't know what he's doing and should no longer be responsible for maintaining the website. |
|
I agree with @Azulan , this behaviour is really irritating? |
|
@Azulan If @Cobra-Bitcoin can admit their mistake, I don't think it needs to come to that But continuing to defend a totally incorrect position is destroying any reputation they had |
|
NACK because this is a shamefully political move on @Cobra-Bitcoin's part that is logically inconsistent. Let's break down the stated policy: "bitcoin.org does not promote wallets that attempt to alter (or follow nodes that do alter) the existing consensus without overwhelming support." OK, so wallets that follow changes to consensus without "overwhelming support" should be delisted. Since you haven't defined the criteria for determining "overwhelming support" I'm assuming that you mean percentage of network hashrate, since apparently soft forks requiring 95% hashrate are allowed. I also seem to recall you previously delisting wallets that were in support of proposals that activated at 75% hashrate signaling. Logically it follows that any wallets that are not fully validating nodes and just use the blockchain with the greatest cumulative proof of work should be delisted, as they would follow a hard fork that is performed without overwhelming consensus, as could be done via nodes that support Emergent Consensus or some similar scheme. By my count, in order to consistently enforce this policy you'll need to remove any wallets that are SPV clients, any hardware wallets that operate without being backed by full nodes, and possibly some of the web wallets. I'm willing to change my position to an ACK if the stated policy is applied consistently. My recommendation, however, is that the policy should be defined more precisely so as to leave little room for interpretation. |
|
I don't know where the policy described in the OP came from. The closest written policy Bitcoin.org has on this says (in part),
@slush0 above says about the optional Satoshi Labs's Trezor backend,
@crwatkins, Bitcoin.org's wallet maintainer, also points out that Bitcoin.org historically only considers hardware wallets in combination with their software, and that the Trezor is compatible with several Bitcoin.org-listed wallets that do not have BIP148 enforcement code or policies. This does not sound to me like the Trezor will be moving its users to BIP148 enforcement by default, so I don't believe the prior written policy can be used to argue for delisting Trezor. I think it's good that @Cobra-Bitcoin is working to protect novice Bitcoin users (the type of user who most often visits Bitcoin.org) from preventable consensus failures that could put user money at risk. I also think it's good that @slush0 is giving advanced users extra options. Thank you both. |
|
NACK. Inconsistent PR. |
Hm, I'd note that my logic still holds true for SPV client wallets based upon this phrasing. Any wallet that merely follows the chain with the greatest cumulative proof of work and doesn't fully validate would fall into this category and should be delisted. I'd suggest that this policy also be re-examined. |
|
@jlopp please read the whole policy, not just the small extracted quote. E.g.,
|
|
Ah, good to know @harding. In that case, it appears that @Cobra-Bitcoin's proposal violates this section of the policy:
To be clear, "services that claim to support" a change should not be construed as "services that will move users onto a hard fork by default." On a related note, the policy is specifically referring to hard forks whereas this particular conversation is a proposed soft fork. It still seems to me that said policy should be revisited in light of recent events. |
|
@jlopp I agree an updated policy is warranted, but enforcing this policy over the past two years has been the source of repeated annoying dramas. I'd rather find a more universally acceptable (and boring) alternative. |
|
I don't know why you're all making this so complicated when it isn't. The main issue here is what Trezor will present to the user as "BTC" on its services (that are a key part of the overall package and experience of owning Trezor hardware). @slush0 has commented on here and Twitter talking about the users getting to choose between coins, and how Trezor is ready for UASF. It's still unclear what Trezor services will display to the user as "BTC" during a contentious UASF (because if it wasn't contentious, @slush0 wouldn't even be talking about their being choices to pick from). If UASF creates a contentious split, and splits away from the existing consensus, then it's an altcoin and has to be presented that way and not as some flavour of "Bitcoin" to choose from. Imagine for a moment that you're a complete noob and aren't aware of any Bitcoin politics, and that you deposit 10 BTC into a wallet, and then login 20 days later and find that all your BTC are gone, and you suddenly see that all your balances are presented in 3 different currencies: CRC (Core Coin), USF (UASF Coin), and BUC (BU), while this makes sense to most of us since we keep up with all the politics, for a new user they're going to end up confused, scared and might inadvertently trade away the true BTC. You can't slice up people's perception of value in this way, there is one Bitcoin, and users never choose between flavours of it. Either you be clear that during the initial fork, the UASF chain will be presented as an alt coin (which it is) and you won't try to confuse users by trying to present it as some flavour of Bitcoin, or you continue to present the existing consensus as "BTC" until UASF chain gains broad support and "becomes" BTC, and then you reverse coins and the pre-UASF coin is presented as the alt instead. If you all stepped outside your little bubble and try to look at things through the perspective of an average user, and not someone who keeps up with all our petty internet drama every day, then you'll understand why this is necessary and why bitcoin.org can't promote services that are so vague and unclear about what they'll consider "BTC". I have to think about the future, and if we don't do this now, then in the future someone is going to make a really dangerous UASF, promote it everywhere, or convince some services to treat it as a flavour of BTC, and if we try to remove any wallets from bitcoin.org that support it, they'll cite that we were OK with the Segwit UASF so why not this one? If you want to alter the current consensus, then good luck, but please don't expect bitcoin.org to send users to your service so you can have them decide between a million different flavours of Bitcoin. |
|
Being "ready" for UASF doesn't mean "altering consensus rules" in any way. I don't see what sort of deranged logic would lead to that conclusion. |
Trezor is signing device. Record on bitcoin.org is about this hardware token. Record on bitcoin.org does not mention any particular web interface. Citation from bitcoin.org: "Trezor is a hardware wallet providing a high level of security without sacrificing convenience. Unlike cold storage, Trezor is able to sign transactions while connected to an online device." You're commenting another application, which is not promoted on bitcoin.org. That web app is one of many applications you can use with TREZOR device. It is even kind of funny how strictly you argue with some points, but then you vaguely defines "services that are a key part of the overall package and experience of owning Trezor hardware". There's not a single mention of web wallet on bitcoin.org and you don't need such app to get TREZOR working. Period. The key point is that you're blaming us for something what's non-existing issue. Our primary goal and primary philosophy with TREZOR is to make things as easy as possible and we spend last few years to don't confuse our users with anything. Your fear of TREZOR users being misinformed about contentious fork is only in your head. But I'm simply refusing to play your game and let you dictate us how we should communicate with our customers in our application, which has no mention on bitcoin.org. Please stop this trolling and close PR. |
|
Anyway, if you want to be so strict, you should remove also Electrum. ThomasV, main developer and operator of "official" Electrum server at ecdsa.org already runs UASF patch on his instance. I'm pointing that out not because I think Electrum should be withdrawn from the bitcoin.org, but to show how ridiculous your requirement is; Electrum can be connected to any backend, UASF or non-UASF. The same apply for TREZOR. |
|
From a really high level, I think the fundamental problem is that it's not possible to define the "true Bitcoin" with a simple policy. Given that consensus can be fluid in nature, any attempts to define Bitcoin must necessarily also be flexible. And it may be impossible to define the true Bitcoin during periods of transition. |
Anyway, direct answer to your question is "yes, TREZOR will see both UASF and non-UASF as BTC and there's nothing we can do with it". TREZOR is unaware of consensus rules and there's technically no way how to recognize on which chain he's operating. The same apply for any hardware wallets and it's nothing we can change on your request. Even web wallet is unaware of consensus rules. Only the backend is, and users will be told what backend uses what rules, in the same way like altcoins are promoted in the app. |
|
@Cobra-Bitcoin You are the one making this too complicated
Please can we get this merge cancelled and PR closed. |
This is exactly the part that I'm wondering about. If there's a split because of UASF, then by definition the soft fork failed, and it's not Bitcoin but an altcoin instead. So I'm guessing by a separate backend you're saying that UASF coins will be distinct from "BTC" and not presented to the user as "BTC" or a flavour of Bitcoin? If you can confirm that's the case, then I can cancel this pull request. We're just wondering what your suite of products will present to the user as "BTC", that's all, and there's been no clear answer yet. It's fine if you want to support two different backends and versions of Bitcoin, and to allow choice between the two under a "Bitcoin" description, but I just don't think it's right for us to send users to your service(s) if we can't at least guarantee that you'll commit to there being only one "BTC". |
IMO, supporting UASF is not a reason to remove them from the site:
Please, let's not turn this into another thing that splits the community. |
|
@slush0 Hey, I'm very sorry - I disagree with this PR and think you're being unfairly singled out. It seems the majority consensus within this PR from other participants is uniform as well that this should not be merged. If Cobra feels this must be addressed as a potential change in the codebase, I think the right thing to do would be to first open an issue or even better, contact you all directly so that hopefully a less threatening or hostile dialogue can be had in order to reach a common understanding. What has happened here in this space so far, which I hope we can all agree, is not good. It's not too late to come together despite differences and turn this thread around, though. As an aside to this, I just want to take a moment to mention to everyone here (and to whoever reads this), that while I cannot prove it, I have been in the space for several years, and believe that there is an ongoing, clearly organized and well-funded professional effort (as mentioned by my friend Andreas) to fracture us as a Bitcoin community. In military conflicts, this is known as fog of war. Groups looking to divide and conquer a given area, may use this to create a strategic advantage by creating confusion surrounding who is threatening their sovereignty. In this case, who is threatening Bitcoin's sovereignty? Is it TREZOR? Will removing it solve the problem? Or Electrum since their lead developer is running an Electrum server with a UASF patch? Should we remove them, too? Will that make this problem go away? I do not think it will, but I do think it will drive us further apart. It will cause more infighting and finger pointing. At what point does it hurt the new user that we are all seeking to protect? Aren't things that are happening right now already hurting the new user enough? We are all brothers and sisters in this Bitcoin community, as we are on this planet that we share. I have seen @Cobra-Bitcoin go to great lengths to make this site available to everyone as well as tirelessly fight the spread of misinformation out there in places like reddit, standing up for many of us, fighting against efforts that are trying to pull us apart. Likewise, @slush0 and the TREZOR team have made great contributions to the space, and have gone at great lengths to make their code available for peer review. If only some companies we can all think of had used their hardware wallet in the past, how many millions of dollars worth of stolen bitcoin would have been saved? How many more people might not have been dissuaded from entering the space because they heard about a large hack on the news? = = = = = = Tomorrow, 5 minutes or half an hour from now is not guaranteed to any one of us. The only thing any of us can act upon is this very moment, the present. None of us are perfect, and we all carry our flaws as we persevere here in our existence. I have many many flaws, but I try to persevere. Tomorrow may not come, but most likely, it will. I hope and think about a possibility of something greater, tomorrow - something more perfect and less flawed than each and every one of us. Something that can be that way because we all put our positive energy and hopes into it and built it together, today. I call this Bitcoin, and have spent several years working on it with many of you. And since nothing is guaranteed, I will do my best to work with the present moment, so that it may deliver something greater for the moment that comes after. To me, this is one of the greatest websites in the Bitcoin space. It's not just the domain name that makes it awesome. It's all of you. In fact, it's amazing, look at everything this community has built. Look at how amazing we have all become. From the newest user who just learned how to become his or her own bank, to the elite developer who just made that user's wallet. I am a private person and prefer to keep my thoughts to myself and out of public view, but can't stop being bothered by what's happening here in our space. With that in mind I wrote down something the other day inspired by a thing I read long ago, that I would like to follow, whether it's on this Bitcoin project or another. So I'll share it here in hopes it might help us rise together out of this situation:
We talk about consensus a lot in Bitcoin. It is clear on this PR that it should not be merged. There is no brigading, and some great engineers and community members are taking a time out for multiple days, now, from being productive on other things to come together here. Days that those who are against us are able to pick up slack and hasten their efforts. I am the website maintainer for Bitcoin.org, however, Cobra is the domain owner. As such, if I close this PR, he can reopen it. He can make any change he wants, and ultimately, what happens with the site is his decision (e.g. who has commit access, who can maintain the repository, what goes on the site, etc). I volunteer to work on this site in hopes that the actions I take, are serving the community. I am hopeful that he will close this PR, because I think that merging it will hurt everyone. To that I say to Cobra, and everyone, let's get back to work and let's build in this present moment. Let us not take down one another or destroy. If we move forward together, those against us will always be one step behind. Let's move upward, and onward, together, to the moon and beyond. Geronimo... |
|
I've replaced the pull request from "Merge Scheduled" to on hold. Since this is a controversial change, the decision to merge or not will be decided through a vote by bitcoin.org contributors that have been keeping up with this thread: @theymos @crwatkins @wbnns @harding and myself. Given all that's been discussed so far, my vote is to merge, since it's going to cause us a lot of problems in the future if we don't do this, and from what I've seen so far, everything suggests that Trezor services plan on supporting multiple flavours of Bitcoin as they deliberately avoid saying that they'll display only one coin as "BTC". |
|
@Cobra-Bitcoin , I don't think that's what Trezor are suggesting. To be fair, their device is not aware to such a change as BIP148, so aside from preparing their online service for that kind of fork, the device itself would work the same. I see my previous comments were regarded as off topic when I mentioned this, but I do think this relates to what's at stake here. Trezor isn't de-listed because it could support an alt-chain, in fact the device already supports altcoins, but as there is no setting on the device itself, for a user, two different chains would look like the same Bitcoin, depending on the service currently accessing the device. You can't expect no loss of funds if something like that happens. @wbnns , thank you for taking the time to write your post. |
|
@Cobra-Bitcoin Thanks. My vote is to close, unmerged (based on what I mentioned above). |
|
I think there's merit to @Cobra-Bitcoin's concern and that the only reasonable default wallet policies during a potential consensus failure are (1) cease accepting or spending new transactions until the situation clears up, or (2) follow the previous consensus rules at least as well as the software or hardware did previously. I'm personally comfortable with wallets offering users a choice of full-node backends, provided the default backend implements one of the two aforementioned options and that before users can choose an alternative backend, they are informed of the risks inherent in a potential consensus failure. Trezor's compatibility with multiple wallets complicates this issue, and I think it brings us back to something @crwatkins has been talking about for a long time---that we need to evaluate and recommend (or not) hardware wallets in context of the software they're being used with. Based on the above, my recommendation is that we attempt to address @Cobra-Bitcoin's concerns by improving the wallet page. Specifically,
If the above seems reasonable, then I suggest that this PR be closed (without necessarily deleting the branch) or left in the Please note that the above is not a vote, just a suggestion. If we have to vote, my vote is for whatever Bitcoin.org's wallet maintainer, @crwatkins, decides. I think he's done an excellent job in that role for two years now in interacting with wallet developers in an effective but low-drama way, and I'd like to empower him to continue doing so as best as possible. |
|
I remain NACK. |
Trezor claims to be "ready" for UASF, unfortunately while I personally do support a UASF to activate Segwit, bitcoin.org does not promote wallets that attempt to alter (or follow nodes that do alter) the existing consensus without overwhelming support. In the case of a failed UASF, an altcoin is created which is not Bitcoin.
Services that claim to support or be ready for this new altcoin don't belong on bitcoin.org. It's impossible for there to be two Bitcoin's, so bitcoin.org can't promote services that incorrectly label an altcoin as "Bitcoin" (such as a failed UASF) or services that present the user with two different Bitcoin "flavours" (as would happen in a contentious UASF) to pick from.
UASFCoin is not bitcoin, and until it becomes "bitcoin" by gaining overwhelming consensus (almost all nodes, all exchanges, all miners and all developers), then this policy will be applied to all wallets. It's very dangerous to break apart from the existing consensus, or to present the user a million different flavours of Bitcoin to choose from ("What Bitcoin version would you like? CoreCoin, UASFCoin, or BUCoin?"). There is only 1 Bitcoin and only 1 Bitcoin Blockchain, and bitcoin.org exists to serve that.
Merge scheduled for one week from now.