Revert "Merge pull request #1178 from Cobra-Bitcoin/remove-coinbase" #1180
Conversation
|
Voting for. |
|
ACK, for all the good it will do... |
|
ACK |
|
ACK. Coinbase is too important of an onramp for new users to be left out. |
|
ACK 👍 |
|
ACK |
3 similar comments
|
ACK |
|
ACK |
|
ACK |
|
NACK. Bitcoin.org is not for altcoins. |
|
ACK |
|
NACK |
|
Yes please. |
|
ACK. |
|
NACK. Please no altcoins. |
|
It's not about altcoins @shinohai it's about a wallet that clearly supports Bitcoin. @Cobra-Bitcoin probably should just close this as it seems like while it enjoys a clear majority for reinstatement you will not merge it. Is there any type of warning text or additional modification that can be made here to save the PR? |
|
ACK |
1 similar comment
|
ACK |
|
Close and lock already. |
|
@jrmithdobbs "Discussion is ok unless you don't agree with me" |
|
+1 to merge |
|
Hello, I would like to make a comment here. I was going to make a comment in #1178 (having watched the conversation and observed the merge that was made) but by the time I could get around to it, having been on vacation, and getting back to reading everything again carefully (including this pull request and comments), then 1178 ended up being locked except for collaborators, thus I never had a chance to express my views on the subject. So I would like to express them here. Unfortunately I don't think my ideas will make anyone happy because I don't agree specifically with a straight removal of Coinbase as it was done in pull request 1178, nor do I agree particularly with the simple revert which is proposed by this pull request on which I am commenting. In the past, I have pointed out, in a still-open issue in this repository that the definitions and characterizations associated with web wallets that are displayed when you click on them, which are a result of the scoring, leave something to be desired, and need to be re-written and improved. As that applies to Coinbase: Note that at the time I made my remarks I suggested that with respect to that language which is applied to Coinbase, I did not suggest changing the language as it existed prior to the merge in pull request 1178, and my reasoning was, because I felt the language presented properly warned the user about the deficiencies inherent in Coinbase before the user would download or use anything. (However, as I will explain further below, that is not the only issue to analyze here.) This is a complex issue, and I would suggest that anyone reading my remarks not take them out of context. To get the bigger picture of how people are thinking about it, please read all comments on Issue #996 and perhaps add your own thoughts to that thread. Furthermore, there are additional issues to analyze (in my humble opinion) before you should take the action of making a merge in connection with this pull request, namely, the following:
In conclusion, I do not agree with PR 1178, nor do I agree with this pull request (PR 1180) as it is currently written. I have been one of the most vocal opponents of use of web wallets and have often warned against the problems and dangers associated with their use; Coinbase's financial censorship of users is just one of many of the aspects of such problems or dangers. However, I do not agree with the idea of excluding entirely a presentation of things like Coinbase from bitcoin-dot-org, but rather, I think things like Coinbase (which is a brokerage that offers a wallet application) should be given a different listing category and placed in a spot where it will get less traffic than other wallets. I feel similarly about web wallets, again, please see my remarks at Issue #996 for more details. Thank you for reading this comment and for your consideration as you evaluate how to move forward. |
|
@ABISprotocol @theymos' "censorship of users is just one of many of the aspects of such problems or dangers." |
|
The most important thing about #1178 it that it sends a signal that no company should even consider ideas that are not approved by core team without consequences. |
The bitcoin core developers and the bitcoin.org site maintainers are two different parties. In fact most of the bitcoin core developers did not even comment on #1178 or gave an "ACK" on the pull. |
|
@MarcoFalke |
|
ACK - this situation is completely unprofessional, and the removal PR should have never been merged. I already had users asking me on twitter if Coinbase-BTC was still safe to use. This looks like amateur hour to outsiders - a business experiments with something that diverts from the Official Line, and bitcoin.org immediately de-lists them. That's anti-innovation, anti-freedom-of-choice and discourages anyone from diverging from the Official Line. Ultimately bitcoin.org is devalued not Coinbase. |
|
ACK |
|
ACK! |
|
ACK |
|
This is not a vote. I will unlock this when it is no longer being brigaded. |
|
Coinbase CEO Brian Armstrong clarified:
"Economic majority" might (debatably) not be quite correct, but I think that this is sufficient to show that Coinbase is on Bitcoin now and will remain on Bitcoin in at least most likely future cases. It's actually a stronger statement than I ever expected to see. I talked with Cobra previously about the conditions necessary to allow Coinbase's reinstatement, and Brian's statement here seems to satisfy these conditions. So as things look now, we will not veto Coinbase's reinstatement. This PR is kind of confusing because there are so many people who have never contributed to bitcoin.org but are posting meaningless ACKs. Can some bitcoin.org regular contributors share their thoughts as to whether you think Coinbase should be reinstated and whether this PR is technically OK? I think that Coinbase has gone above and beyond on this hardfork issue, so while they're probably worse than some Web wallets like GreenAddress, I tend to think now that they're at least not significantly worse than Circle. So while these sorts of Bitcoin banks are allowed, I'm OK with reinstating Coinbase. |
|
@theymos Thanks for being reasonable. Even though we may have different ideas on how best to scale Bitcoin, we all want the best for Bitcoin. Even within the same company, Brian and I don't fully agree on how to scale Bitcoin. That's fine because we both agree that Bitcoin belongs to everyone. And in the end, it will overcome this debate and find the right path. |
|
@theymos I am not a regular contributor, but I have contributed a little to the site. I think @barmstrong Brian Armstrong's statement lacks the right nuance, but I think shows good intent. The correct wording would be that they will always "support the longest chain with the most work", since that is by definition consensus under Bitcoin's rules. It seems to me that bitcoin.org exists to bring awareness about Bitcoin and that involves list of Bitcoin services (like wallets and exchanges). I do think bitcoin.org requires minimum standards so it's not just an advertising platform like it's competitors, so that users can make informed decisions about the software and services they chose. I like that bitcoin.org has a set of minimum criterion for wallets based on security, and that there wallets are categorised and labelled according to security trade-offs. As such, I am OK with listing "bitcoin Banks" and custodial services even if they arent "pure bitcoin", so long as they are marked correctly as such with all the caveats to educate users about their risks. I think this is already the case. I agree Coinbase's public conduct has been a bit disappointing, especially coming directly from the CEO. I would hope in the future they chose to engage more positively rather than stir and divide. It certainly does not help to feed negativity which only serves to distract and demotivate. Companies should stop lobbying privately to trying and force their own agendas. There should be more open dialogue and communication from all parties and stakeholders because changing Bitcoin consensus rules really does require almost unanimous support, by design. While multiple Bitcoin implementations are inevitable, they will actually make consensus building harder because ultimately one project will propose a consensus change and will either need to get unanimous adoption of their client, or convince all other software implementations to also roll out their proposal to their users. As such, I would hope vendors can be encouraged at the very least, not be divisive. That may be something the domain owners would like to address in their mission statement/policy for the site because it does not make sense to me, to promote vendors who try to wield axes. Overall, I am glad there is a possibility to consider re-add Coinbase. ACK on re-adding. |
|
Re:
ACK |
|
I definitely recommend Coinbase for listing. Coinbase meets our current criteria for wallet listing. I also believe that Coinbase meets each of the stated requirements in our Hard Fork Policy. In regards to the discussions about "Bitcoin banks" a.k.a "custodial wallets", Coinbase meets our current criteria for that type of wallet. We are currently working on some ideas to address the concerns about different types of wallets providing different capabilities and currently have an issue open to discuss that. @theymos I believe "this PR is technically OK" |
|
Concept re-ACK (did not confirm correctness of webpage code change, but it doesn't look obviously wrong).
@btcdrak I think you reworded that very wrong... Perhaps you meant "the valid chain with the most work"? |
|
Per recommendations above from regular contributors (including @crwatkins, our wallet maintainer), I'm building a local preview and will merge as soon as I've verified everything looks good. (Note: it takes another 10-15 minutes after merge for the change to go live on the site.) |
|
@theymos I am not a regular contributor but am #16 in terms of commits Concept ACK and NACK https://bitcoinclassic.com/ has asserted that Gavin Andresen (a Coinbase Advisor https://www.coinbase.com/about), Brian Armstrong and Coinbase are in agreement with: "We are hard forking bitcoin to a 2 MB blocksize limit. Please join us." Within the past 24 hours @barmstrong issued the Twitter statement about following the longest valid chain with economic consensus and also issued an ACK of bitcoinclassic's statement. Very confusing. Assuming Brian and Gavin both will publicly disavow bitcoinclassic.com and make the pull requests to remove them from the bitcoinclassic website then I do think Coinbase should be readded to bitcoin.org based on your requirements with @Cobra-Bitcoin Nevertheless, the NACK portion would apply to Coinbase but also to any other custodian service that also lacks TOS, UAs, etc. that address this issue. I think the statement from @barmstrong is rather meaningless from a legal perspective. What matters is what is written into the legal documents and agreed to by the company and user. Any type of custodian relationship entails serious financial and legal implications for customers because those customers do not solely hold the private keys themselves. And what matters with regards to customer's property rights is what is in the Terms of Service, User Agreements, etc. that are agreed to (usually with only a click and are not read). I think it is possible to imagine that many users will not read the TOS, UAs, etc. but instead rely on bitcoin.org's assessment. Consequently, bitcoin.org should have some type of a requirement for listing any custodian type services where the TOS directly addresses this issue in particular ways that meet what bitcoin.org considers to be a high standard of care that will help encourage TOSs, UAs, etc. that are written in such a way that customers have extremely strong legal rights and protections regarding any property, funds or other type of financial interest. |
|
ACK |
|
bitcoin.org is a website with the primary aim of educating newbies about bitcoin and the bitcoin ecosystem. Those newbies have no clue about forks, about XT, about classic, about unlimited or any other matter that relates to the blocksize and anything about it simply fully confuses them. Any information, content, or decision that has relation to the blocksize should be buried somewhere deep in some advanced section, with the primary content being to inform individuals who may have never heard of bitcoin about what bitcoin is, how it can be used, how it can be easily bought, etc. No person with any influence or decision making ability reads bitcoin.org or is in anyway influenced by it. Nor, may I say, any current bitcoin user because they would be aware of the information it contains. Therefore any decision aimed as a weapon is very limited in influence and, of course, as shown by say bitpay's statements or bitstamp's statements or BCCC any such threats have been called bluff. Bitcoin is changing and it is changing for the better. While in 2013 we had only one exchange and were prisoners to it's ddosing, amateurism, the chaos it created and it's eventual huge terrible and devastating bang, we now have multiple exchanges which gives the ecosystem high resilience. Equally, just one client is a dangerous centralised point that can be coerced/corrupted/attacked from within/without. Multiple implementations add resilience. Bitcoin.org should reflect the ecosystem and educate newbies about the nature of bitcoin, how it works, how it can easily be acquired, as well as about the nascent new implementations. Perhaps not bitcoin xt, but bitcoin.org should certainly inform individuals about bitcoin unlimited in a neutral - informative only - manner, about bitcoin classic, about bitcoin core, etc. The decision in regards to coinbase therefore is outdated. XT is a was. It is time now for all who truly hold bitcoin's interest at heart to recognise that the ecosystem is changing for the better and that we need to get around the table, co-operate where we agree, and politely agree to disagree where we don't. No man holds power in bitcoin land. If any man does then bitcoin's proof of work is worthless. Equally, bitcoin relies on no man to defend it. It is not possible for a charismatic man to seduce the bitcoin masses. If it is then bitcoin works not. You ought to end all this theymos, recognise the beneficial changes and prove to us all that you have been acting in good faith. Otherwise you will be asserting malicious intentions which can not further down the line be explained away. |
|
Thanks @theymos for making the change. Happy to stay in touch in the future so miscommunications don't happen. It's great that we were able to clear things up once we chatted (although it took a long time and happened in public). In the future happy to discuss in private as well. @sunnankar Coinbase will always stay on the longest valid chain. But we will also publicly discuss and vote on various proposals to improve bitcoin. I don't think this is inconsistent. (Just like you might vote in an election, but still support the winner regardless of whether they are the one you voted for). |
It really comes down to your definition of what a valid chain is then. Since hard forks require all nodes to upgrade they should not be done unless there is rough consensus among all bitcoin companies. If coinbase chooses to redefine what a valid chain is without community consensus then there will potentially be two competing chains. The real issue comes down to if you are merely supporting a proposal or supporting activation of a proposal in the face of significant objection. Activation of bitcoin classic is already opposed by at least 25% of the hashing power precisely because it is being pushed for activation without community consensus even though those same miners would be ok with an increase to 2MB if there was community consensus. |
|
@theymos isn't reasonable, he's a wannabe tyrant. The great thing about bitcoin is that it doesn't enable tyranny. |
This is very fuzzy statement, validity is determined by the software you are running, and therefor so is "longest". Do note that the Bitcoin consensus does not actually use longest chain but the valid chain with the most cumulative proof of work, this is a very important distinction. |
|
@tulip0 and many others: I think @barmstrong obviously means the most proof of work when he says longest chain. It's just a shortcut we all understand (or so I thought). |
@jameshilliard Circular logic there surely? The oppose it, because they oppose it? |
|
@chriswheeler The difference is between supporting a proposal and supporting activation of a proposal, supporting activation should only be when there is widespread consensus across the entire bitcoin industry. |
|
I agree with the earlier comment of @Aquentus which suggested simplification of bitcoin.org via movement of complex topics to a less obvious area to make things smoother on newcomers to bitcoin, so that the more basic ideas, how-to's, and where do I get a wallet is more up front. |
|
@ABISprotocol pull requests are always welcome. |
|
@harding well, maybe with things toning down a little bit, I will consider crafting one... I don't ordinarily like crafting PRs. I will consider it though, having made enough suggestions in issues on language. |
|
This is a response to a stale and old pull request. It seems like some
of these issues and arguments just come up over and over again. I've
long been opposed to the methods and models of Coinbase and Bitpay. I
agree that bitcoin belongs to everyone, but at the same point, there is
a path of insanity that we just shouldn't go down.
That path of insanity is the one Coinbase, BitPay and others are taking.
But enough chitchat - I understand the position of bitcoin.org as of
late with respect to Coinbase, BitPay etc. I also understand why some
are upset at bitcoin.org, but ah well. I simply recommend that people
run the latest version of Core, don't lose so much of one's time on
fora, get sleep, enjoy the outdoors, and enjoy life more.
Oh, and continue to create amazing things.
Cheers,
- o
Charlie Lee:
… @theymos Thanks for being reasonable. Even though we may have different ideas on how best to scale Bitcoin, we all want the best for Bitcoin. Even within the same company, Brian and I don't fully agree on how to scale Bitcoin. That's fine because we both agree that Bitcoin belongs to everyone. And in the end, it will overcome this debate and find the right path.
---
Reply to this email directly or view it on GitHub:
#1180 (comment)
--
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
|
This reverts commit 7d1cdd9, reversing
changes made to cc79a1e.