New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revert "Merge pull request #1178 from Cobra-Bitcoin/remove-coinbase" #1180

Merged
merged 1 commit into from Jan 12, 2016

Conversation

Projects
None yet
@hoffmabc
Contributor

hoffmabc commented Dec 27, 2015

This reverts commit 7d1cdd9, reversing
changes made to cc79a1e.

@spjakob

This comment has been minimized.

Show comment
Hide comment
@spjakob

spjakob Dec 27, 2015

Well done!

spjakob commented on f7d782c Dec 27, 2015

Well done!

This comment has been minimized.

Show comment
Hide comment
@Azulan

Azulan replied Dec 27, 2015

ACK

This comment has been minimized.

Show comment
Hide comment
@ShadowOfHarbringer

ShadowOfHarbringer replied Dec 27, 2015

ACK

This comment has been minimized.

Show comment
Hide comment
@drwasho

drwasho replied Dec 27, 2015

ACK

This comment has been minimized.

Show comment
Hide comment
@Hannott

Hannott replied Dec 27, 2015

ACK

This comment has been minimized.

Show comment
Hide comment
@Klakurka

Klakurka Dec 27, 2015

ACK. Thanks Brian.

Klakurka replied Dec 27, 2015

ACK. Thanks Brian.

This comment has been minimized.

Show comment
Hide comment
@jtoomim

jtoomim replied Dec 28, 2015

ACK.

This comment has been minimized.

Show comment
Hide comment
@hoffmabc

hoffmabc Dec 28, 2015

Owner

@Cobra-Bitcoin do the right thing and merge

Owner

hoffmabc replied Dec 28, 2015

@Cobra-Bitcoin do the right thing and merge

This comment has been minimized.

Show comment
Hide comment
@gladoscc

gladoscc Dec 28, 2015

This isn't even a pull request so you can't ACK.

gladoscc replied Dec 28, 2015

This isn't even a pull request so you can't ACK.

This comment has been minimized.

Show comment
Hide comment
@hoffmabc

hoffmabc Dec 28, 2015

Owner

It's a commit in the respective PR. You want to argue semantics?

Owner

hoffmabc replied Dec 28, 2015

It's a commit in the respective PR. You want to argue semantics?

@spjakob

This comment has been minimized.

Show comment
Hide comment
@spjakob

spjakob Dec 27, 2015

Well done!

spjakob commented on f7d782c Dec 27, 2015

Well done!

This comment has been minimized.

Show comment
Hide comment
@Azulan

Azulan replied Dec 27, 2015

ACK

This comment has been minimized.

Show comment
Hide comment
@ShadowOfHarbringer

ShadowOfHarbringer replied Dec 27, 2015

ACK

This comment has been minimized.

Show comment
Hide comment
@drwasho

drwasho replied Dec 27, 2015

ACK

This comment has been minimized.

Show comment
Hide comment
@Hannott

Hannott replied Dec 27, 2015

ACK

This comment has been minimized.

Show comment
Hide comment
@Klakurka

Klakurka Dec 27, 2015

ACK. Thanks Brian.

Klakurka replied Dec 27, 2015

ACK. Thanks Brian.

This comment has been minimized.

Show comment
Hide comment
@jtoomim

jtoomim replied Dec 28, 2015

ACK.

This comment has been minimized.

Show comment
Hide comment
@hoffmabc

hoffmabc Dec 28, 2015

Owner

@Cobra-Bitcoin do the right thing and merge

Owner

hoffmabc replied Dec 28, 2015

@Cobra-Bitcoin do the right thing and merge

This comment has been minimized.

Show comment
Hide comment
@gladoscc

gladoscc Dec 28, 2015

This isn't even a pull request so you can't ACK.

gladoscc replied Dec 28, 2015

This isn't even a pull request so you can't ACK.

This comment has been minimized.

Show comment
Hide comment
@hoffmabc

hoffmabc Dec 28, 2015

Owner

It's a commit in the respective PR. You want to argue semantics?

Owner

hoffmabc replied Dec 28, 2015

It's a commit in the respective PR. You want to argue semantics?

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Dec 27, 2015

Voting for.

ghost commented Dec 27, 2015

Voting for.

@jlopp

This comment has been minimized.

Show comment
Hide comment
@jlopp

jlopp Dec 27, 2015

Contributor

ACK, for all the good it will do...

Contributor

jlopp commented Dec 27, 2015

ACK, for all the good it will do...

@ddehueck

This comment has been minimized.

Show comment
Hide comment
@ddehueck

ddehueck commented Dec 27, 2015

ACK

@jcliff

This comment has been minimized.

Show comment
Hide comment
@jcliff

jcliff Dec 27, 2015

ACK. Coinbase is too important of an onramp for new users to be left out.

jcliff commented Dec 27, 2015

ACK. Coinbase is too important of an onramp for new users to be left out.

@barmstrong

This comment has been minimized.

Show comment
Hide comment
@barmstrong

barmstrong commented Dec 27, 2015

ACK 👍

@nomnombtc

This comment has been minimized.

Show comment
Hide comment
@nomnombtc

nomnombtc commented Dec 27, 2015

ACK

3 similar comments
@tomasvdw

This comment has been minimized.

Show comment
Hide comment
@tomasvdw

tomasvdw commented Dec 28, 2015

ACK

@guruvan

This comment has been minimized.

Show comment
Hide comment
@guruvan

guruvan commented Dec 28, 2015

ACK

@arodic

This comment has been minimized.

Show comment
Hide comment
@arodic

arodic commented Dec 28, 2015

ACK

@jrmithdobbs

This comment has been minimized.

Show comment
Hide comment
@jrmithdobbs

jrmithdobbs Dec 28, 2015

NACK. Bitcoin.org is not for altcoins.

jrmithdobbs commented Dec 28, 2015

NACK. Bitcoin.org is not for altcoins.

@maddenw

This comment has been minimized.

Show comment
Hide comment
@maddenw

maddenw commented Dec 28, 2015

ACK

@Cobra-Bitcoin

This comment has been minimized.

Show comment
Hide comment
@Cobra-Bitcoin

Cobra-Bitcoin Dec 28, 2015

Contributor

NACK

Contributor

Cobra-Bitcoin commented Dec 28, 2015

NACK

@Grix

This comment has been minimized.

Show comment
Hide comment
@Grix

Grix Dec 28, 2015

Yes please.

Grix commented Dec 28, 2015

Yes please.

@taariq

This comment has been minimized.

Show comment
Hide comment
@taariq

taariq commented Dec 28, 2015

ACK.

@shinohai

This comment has been minimized.

Show comment
Hide comment
@shinohai

shinohai Dec 28, 2015

NACK. Please no altcoins.

shinohai commented Dec 28, 2015

NACK. Please no altcoins.

@hoffmabc

This comment has been minimized.

Show comment
Hide comment
@hoffmabc

hoffmabc Dec 28, 2015

Contributor

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?

Contributor

hoffmabc commented Dec 28, 2015

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?

@cscott

This comment has been minimized.

Show comment
Hide comment
@cscott

cscott commented Dec 28, 2015

ACK

1 similar comment
@MorgUK

This comment has been minimized.

Show comment
Hide comment
@MorgUK

MorgUK commented Dec 28, 2015

ACK

@jrmithdobbs

This comment has been minimized.

Show comment
Hide comment
@jrmithdobbs

jrmithdobbs Dec 28, 2015

Close and lock already.

jrmithdobbs commented Dec 28, 2015

Close and lock already.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Dec 28, 2015

@jrmithdobbs "Discussion is ok unless you don't agree with me"

ghost commented Dec 28, 2015

@jrmithdobbs "Discussion is ok unless you don't agree with me"

@wesmint

This comment has been minimized.

Show comment
Hide comment
@wesmint

wesmint Dec 29, 2015

+1 to merge

wesmint commented Dec 29, 2015

+1 to merge

@ABISprotocol

This comment has been minimized.

Show comment
Hide comment
@ABISprotocol

ABISprotocol Dec 29, 2015

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:

  1. One should analyze whether or not we should have the Coinbase item in the wallet category. Although I was not in favor of the pull request 1178 which was so contentious and which has led to this suggested pull request #1180 - nonetheless, I personally don't feel that Coinbase belongs in the wallet category. You can see some of my reasoning on that from an open issue on Bitcoin bank listings as well as a comment from @crwatkins - here - which merits consideration in the context of this discussion and analysis.

  2. The person who is originating the pull request should not be the person who actually makes the merge. I'm not sure how this is to be handled for this repository -- @harding / @Cobra-Bitcoin -- I've brought this up before in other issues or pull requests in this repository. Perhaps one way of managing this would be to use PullApprove? This is a concern of mine regardless of what pull request we are talking about. Having one person propose some pull request and slam through a merge regardless of who it is, decreases the collaborative aspect of this endeavor associated with this repository and effort for bitcoin-dot-org.

  3. I do not agree with any practice which involves locking out people who are not designated collaborators. Because this was done on PR 1178, I was unable to comment there, even though I had waited to comment and watched the discussion.

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 commented Dec 29, 2015

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:

  1. One should analyze whether or not we should have the Coinbase item in the wallet category. Although I was not in favor of the pull request 1178 which was so contentious and which has led to this suggested pull request #1180 - nonetheless, I personally don't feel that Coinbase belongs in the wallet category. You can see some of my reasoning on that from an open issue on Bitcoin bank listings as well as a comment from @crwatkins - here - which merits consideration in the context of this discussion and analysis.

  2. The person who is originating the pull request should not be the person who actually makes the merge. I'm not sure how this is to be handled for this repository -- @harding / @Cobra-Bitcoin -- I've brought this up before in other issues or pull requests in this repository. Perhaps one way of managing this would be to use PullApprove? This is a concern of mine regardless of what pull request we are talking about. Having one person propose some pull request and slam through a merge regardless of who it is, decreases the collaborative aspect of this endeavor associated with this repository and effort for bitcoin-dot-org.

  3. I do not agree with any practice which involves locking out people who are not designated collaborators. Because this was done on PR 1178, I was unable to comment there, even though I had waited to comment and watched the discussion.

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.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Dec 29, 2015

@ABISprotocol @theymos' "censorship of users is just one of many of the aspects of such problems or dangers."

ghost commented Dec 29, 2015

@ABISprotocol @theymos' "censorship of users is just one of many of the aspects of such problems or dangers."

@arodic

This comment has been minimized.

Show comment
Hide comment
@arodic

arodic Dec 29, 2015

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.

arodic commented Dec 29, 2015

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.

@MarcoFalke

This comment has been minimized.

Show comment
Hide comment
@MarcoFalke

MarcoFalke Dec 29, 2015

Contributor

not approved by core team

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.

Contributor

MarcoFalke commented Dec 29, 2015

not approved by core team

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.

@RobinHoutevelts

This comment has been minimized.

Show comment
Hide comment
@RobinHoutevelts

RobinHoutevelts commented Jan 9, 2016

ACK

@cr3473

This comment has been minimized.

Show comment
Hide comment
@cr3473

cr3473 commented Jan 9, 2016

ACK!

@amnesiac84

This comment has been minimized.

Show comment
Hide comment
@amnesiac84

amnesiac84 commented Jan 9, 2016

ACK

@bitcoin-dot-org bitcoin-dot-org locked and limited conversation to collaborators Jan 9, 2016

@theymos

This comment has been minimized.

Show comment
Hide comment
@theymos

theymos Jan 9, 2016

Contributor

This is not a vote. I will unlock this when it is no longer being brigaded.

Contributor

theymos commented Jan 9, 2016

This is not a vote. I will unlock this when it is no longer being brigaded.

@theymos

This comment has been minimized.

Show comment
Hide comment
@theymos

theymos Jan 12, 2016

Contributor

Coinbase CEO Brian Armstrong clarified:

Coinbase will always support the longest chain in bitcoin. Actually lets say longest valid chain where valid is an economic majority.

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

Contributor

theymos commented Jan 12, 2016

Coinbase CEO Brian Armstrong clarified:

Coinbase will always support the longest chain in bitcoin. Actually lets say longest valid chain where valid is an economic majority.

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

@bitcoin-dot-org bitcoin-dot-org unlocked this conversation Jan 12, 2016

@coblee

This comment has been minimized.

Show comment
Hide comment
@coblee

coblee Jan 12, 2016

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

coblee commented Jan 12, 2016

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

@btcdrak

This comment has been minimized.

Show comment
Hide comment
@btcdrak

btcdrak Jan 12, 2016

Contributor

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

Contributor

btcdrak commented Jan 12, 2016

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

@petertodd

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd Jan 12, 2016

Contributor

Re:

Coinbase will always support the longest valid chain in bitcoin.

ACK

Contributor

petertodd commented Jan 12, 2016

Re:

Coinbase will always support the longest valid chain in bitcoin.

ACK

@crwatkins

This comment has been minimized.

Show comment
Hide comment
@crwatkins

crwatkins Jan 12, 2016

Contributor

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"

Contributor

crwatkins commented Jan 12, 2016

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"

@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Jan 12, 2016

Contributor

Concept re-ACK (did not confirm correctness of webpage code change, but it doesn't look obviously wrong).

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.

@btcdrak I think you reworded that very wrong... Perhaps you meant "the valid chain with the most work"?

Contributor

luke-jr commented Jan 12, 2016

Concept re-ACK (did not confirm correctness of webpage code change, but it doesn't look obviously wrong).

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.

@btcdrak I think you reworded that very wrong... Perhaps you meant "the valid chain with the most work"?

@harding

This comment has been minimized.

Show comment
Hide comment
@harding

harding Jan 12, 2016

Contributor

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.)

Contributor

harding commented Jan 12, 2016

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.)

@harding harding merged commit f7d782c into bitcoin-dot-org:master Jan 12, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

harding added a commit that referenced this pull request Jan 12, 2016

@sunnankar

This comment has been minimized.

Show comment
Hide comment
@sunnankar

sunnankar Jan 12, 2016

Contributor

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

bitcoinclassic/website#3

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.

Contributor

sunnankar commented Jan 12, 2016

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

bitcoinclassic/website#3

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.

@lichtamberg

This comment has been minimized.

Show comment
Hide comment
@lichtamberg

lichtamberg commented Jan 12, 2016

ACK

@Aquentus

This comment has been minimized.

Show comment
Hide comment
@Aquentus

Aquentus Jan 12, 2016

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.

Aquentus commented Jan 12, 2016

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.

@barmstrong

This comment has been minimized.

Show comment
Hide comment
@barmstrong

barmstrong Jan 12, 2016

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).

barmstrong commented Jan 12, 2016

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).

@jameshilliard

This comment has been minimized.

Show comment
Hide comment
@jameshilliard

jameshilliard Jan 12, 2016

Contributor

@barmstrong

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.

Contributor

jameshilliard commented Jan 12, 2016

@barmstrong

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.

@Azulan

This comment has been minimized.

Show comment
Hide comment
@Azulan

Azulan Jan 12, 2016

@theymos isn't reasonable, he's a wannabe tyrant. The great thing about bitcoin is that it doesn't enable tyranny.

Azulan commented Jan 12, 2016

@theymos isn't reasonable, he's a wannabe tyrant. The great thing about bitcoin is that it doesn't enable tyranny.

@tulip0

This comment has been minimized.

Show comment
Hide comment
@tulip0

tulip0 Jan 12, 2016

@barmstrong

Coinbase will always stay on the longest valid chain.

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 commented Jan 12, 2016

@barmstrong

Coinbase will always stay on the longest valid chain.

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.

@jojva

This comment has been minimized.

Show comment
Hide comment
@jojva

jojva Jan 12, 2016

@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).

jojva commented Jan 12, 2016

@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).

@chriswheeler

This comment has been minimized.

Show comment
Hide comment
@chriswheeler

chriswheeler Jan 13, 2016

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.

@jameshilliard Circular logic there surely? The oppose it, because they oppose it?

chriswheeler commented Jan 13, 2016

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.

@jameshilliard Circular logic there surely? The oppose it, because they oppose it?

@jameshilliard

This comment has been minimized.

Show comment
Hide comment
@jameshilliard

jameshilliard Jan 13, 2016

Contributor

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

Contributor

jameshilliard commented Jan 13, 2016

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

@ABISprotocol

This comment has been minimized.

Show comment
Hide comment
@ABISprotocol

ABISprotocol Jan 14, 2016

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 commented Jan 14, 2016

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.

@harding

This comment has been minimized.

Show comment
Hide comment
@harding

harding Jan 14, 2016

Contributor

@ABISprotocol pull requests are always welcome.

Contributor

harding commented Jan 14, 2016

@ABISprotocol pull requests are always welcome.

@ABISprotocol

This comment has been minimized.

Show comment
Hide comment
@ABISprotocol

ABISprotocol Jan 19, 2016

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

ABISprotocol commented Jan 19, 2016

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

@ABISprotocol

This comment has been minimized.

Show comment
Hide comment
@ABISprotocol

ABISprotocol Oct 12, 2017

ABISprotocol commented Oct 12, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment