Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork
----- Forwarded message from Adam Back <adam@cypherspace.org> ----- Date: Mon, 15 Jun 2015 20:03:25 +0200 From: Adam Back <adam@cypherspace.org> To: Mike Hearn <mike@plan99.net> Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> Subject: Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork Message-ID: <CALqxMTFC7zBN9GvHAZLQj4SbXjzkCAM9meSErd3qn7uCoON98Q@mail.gmail.com> Hi Mike Well thank you for replying openly on this topic, its helpful. I apologise in advance if this gets quite to the point and at times blunt, but transparency is important, and we owe it to the users who see Bitcoin as the start of a new future and the$3b of invested funds and $600m of VC funds invested in companies, we owe it to them that we be open and transparent here. I would really prefer on a personal nor professional basis to be having this conversation period, never mind in public, but Mike - your and Gavin's decision to promote a unilateral hard-fork and code fork are extremely high risk for bitcoin and so there remains little choice. So I apologise again that we have to have this kind of conversation on a technical discussion list. This whole thing is hugely stressful and worrying for developers, companies and investors. I strongly urge that we return to the existing collaborative constructive review process that has been used for the last 4 years which is a consensus by design to prevent one rogue person from inserting a backdoor, or lobbying for a favoured change on behalf of a special interest group, or working for bad actor (without accusing you of any of those - I understand you personally just want to scale bitcoin, but are inclined to knock heads and try to force an issue you see, rather than work collaboratively). For you (and everyone) - Should there be a summit of some kind, that is open attendance, and video recorded so that people who are unable to attend can participate too, so that people can present the technical proposals and risks in an unbiased way? (It is not theoretical question, I may have a sponsor and host - not Blockstream, an independent, its a question for everyone, developers, users, CTOs, CEOs.) So here I come back to more frank questions: Governance The rest of the developers are wise to realise that they do not want exclusive control, to avoid governance centralising into the hands of one person, and this is why they have shared it with a consensus process over the last 4 years. No offence but I dont think you personally are thinking far enough ahead to think you want personal control of this industry. Maybe some factions dont trust your motives, or they dont mind, but feel more assured if a dozen other people are closely reviewing and have collective review authority. - Do you understand that attempting to break this process by unilateral hard-fork is extremely weakening of Bitcoin's change governance model? - Do you understand that change governance is important, and that it is important that there be multiple reviewers and sign-off to avoid someone being blackmailed or influenced by an external party - which could potentially result in massive theft of funds if something were missed? - Secondarily do you understand that even if you succeed in a unilateral fork (and the level of lost coins and market cap and damage to confidence is recoverable), that it sets a precedent that others may try to follow in the future to introduce coercive features that break the assurances of bitcoin, like fungibility reducing features say (topically I hear you once proposed on a private forum the concept of red-lists, other such proposals have been made and quickly abandoned), or ultimately if there is a political process to obtain unpopular changes by unilateral threat, the sky is the limit - rewrite the social contract at that point without consensus, but by calculation that people will value Bitcoin enough that they will follow a lead to avoid risk to the system? Security As you probably know some extremely subtle bugs in Bitcoin have at times slipped past even the most rigorous testings, often with innocuous but unexpected behaviours, but some security issues Some extremely intricate and time-sensitive security defect and incident response happens from time to time which is not necessarily publicly disclosed until after the issue has been rolled out and fixed, which can take some time due to the nature of protocol upgrades, work-arounds, software upgrade via contacting key miners etc. We could take an example of the openSSL bug. - How do you plan to deal with security & incident response for the duration you describe where you will have control while you are deploying the unilateral hard-fork and being in sole maintainership control? - Are you a member of the bitcoin security reporting list? On 15 June 2015 at 11:56, Mike Hearn <mike@plan99.net> wrote:
As you know the people who have written 95% of the code (and reviewed, and tested, and formally proved segments etc) are strenuously advising not to push any consensus code into public use without listening to and addressing review questions which span beyond rigorous code & automated guided fuzz testers, simulation and sometimes formal proofs, but also economics, game-theory and critically very subtle determinism/consensus safety that they have collectively 4-5 years experience of each. - Will you pause your release plans if all of the other developers insist that the code or algorithm is defective? - Please don't take this the wrong way, and I know your bitcoinj work was a significant engineering project which required porting bitcoin logic. But If the answer to the above question is no, as you seemed to indicate in your response, as you not have not written much bitcoin core code yourself (I think 3 PRs in total), do you find yourself more qualified than the combination of peer review of the group of people who have written 95% of it, and maintained it and refactored most of it over the last 4-5 years? I presume from your security background you are quite familiar with the need for review of crypto protocol changes & rigorous code review. That is even more the case with Bitcoin given the consensus criticality.
That you are frustrated, is not a sufficient answer as to why you are proposing to go ahead with a universally acknowledged extreme network divergence danger unilateral hard-fork, lacking wide-spread consensus. People are quite concerned about this. Patience, caution and prudence is necessary in a software system with such high assurance requirements. So I ask again: - On the idea of a non-consensus hard-fork at all, I think we can assume you will get a row of NACKs. Can you explain your rationale for going ahead anyway? The risks are well understood and enormous. Note the key point is that you are working on a unilateral hard-fork, where there is a clear 4 year established process for proposing improvements and an extremely well thought out and important change management governance process. While there has been much discussion, you nor Gavin, have not actually posted a BIP for review. Nor actually was much of the discussion even conducted in the open: it was only when Matt felt the need to clear the air and steer this conversation into the open that discussion arose here. During that period of private discussion you and Gavin were largely unknown to most of us lobbying companies with your representation of a method that concerns everyone of the Bitcoin users. Now that the technical community aware aware they are strenuously discouraging you on the basis of risks. Openness - Do you agree that bitcoin technical discussions should happen in the open? - As this is a FOSS project, do you agree that companies should also be open, about their requirements and trade-offs they would prefer? - Can you disclose the list of companies you have lobbied in private whether they have spoken publicly or not, and whether they have indicated approval or not? - Did you share a specific plan, like a BIP or white paper with these companies, and if so can we see it? - If you didnt submit a plan, could you summarise what you asked them and what you proposed, and if you discussed also the risks? (If you asked them if they would like Bitcoin to scale, I expect almost everyone does, including every member of the technical community, so that for example would not fairly indicate approval for a unilateral hard-fork) I and others will be happy to talk with the CTO and CEOs of companies you have lobbied in private, for balance to assure ourselves and the rest of the community that their support was given - and with full understanding of the risks of doing it unilaterally, without peer review, benefit of maintenance and security inidence management, and what exactly they are being quoting as having signed up for. (This maybe more efficiently and openly achieved by the open process, on a mailing list, maybe a different one even special purpose to this topic, with additional option of the open public meeting I proposed at the top). - Do you agree that it would be appropriate, that companies be aware of both the scaling opportunities (of course, great everyone wants scalability) as well as the technical limits and risks with various approaches? And that these be presented by parties from a range of views to ensure balance? - Do you consider your expression of issues to hold true to the ideal of representing balanced nuanced view of all sides of a technical debate, even when under pressure or feeling impatient about the process? You may want to review the opening few minutes of your epicenter 82 bitcoin for example where you claimed and I quote "[the rest of the technical community] dont want capacity to ever increase and want it to stay where it is and when it fills up people move to other systems". - Do you think that is an accurate depiction of the complex trade-offs we have been discussing on this list? (For the record I am not aware of a single person who has said they do not agree with scaling Bitcoin. Changing a constant is not the hard-part. The hard part is validating a plan and the other factors that go into it. It's not a free choice it is a security/scalability tradeoff. No one will thank us if we "scale" bitcoin but break it in hard to recover ways at the same time.) - Were you similarly balanced in your explanations when talking to companies in private discussions? - Do you understand that if we do not work from balanced technical discussion, that we may end up with some biased criteria? Authority Neither you nor Gavin have any particular authority here to speak on behalf of Bitcoin (eg you acknowledge in your podcast that Wladimir is dev lead, and you and Gavin are both well aware of the 4 year established change management consensus decision making model where all of the technical reviewers have to come to agreement before changes go in for security reasons explained above). I know Gavin has a "Chief Scientist" title from the Bitcoin Foundation, but sadly that organisation is not held in as much regard as it once was, due to various irregularities and controversies, and as I understand it no longer employs any developers, due to lack of funds. Gavin is now employed by MIT's DCI project as a researcher in some capacity. As you know Wladimir is doing the development lead role now, and it seems part of your personal frustration you said was because he did not agree with your views. Neither you nor Gavin have been particularly involved in bitcoin lately, even Gavin, for 1.5 years or so. - Do you agree that if you presume to speak where you do not have authority you may confuse companies?
But I think this is a false dichotomy. As I said in previous mail I understand people are frustrated that it has taken so long, but it is not the case that no progress has been made on scalability. I itemised a long list of scalability work which you acknowledged as impressive work (CPU, memory, network bandwidth/latency) and RBF, CPFP fee work, fee-estimation, and so on, which you acknowledged and are aware of. There are multiple proposals and BIPs under consideration on the list right now. - what is the reason that you (or Gavin) would not post your BIP along side the others to see if it would win based on technical merit? - why would you feel uniquely qualified to override the expert opinion of the rest of the technical community if your proposal were not considered to have most technical merit? (Given that this is not a simple market competition thing where multiple hard-forks can be considered - it is a one only decision, and if it is done in a divisive unilateral way there are extreme risks of the ledger diverging.) Network Divergence Risk
But this is not a soft-fork, it is a hard-fork. Miner voting is only peripherally related. Even if in the extremis 75% of miners tried a unilateral hard-fork but 100% of the users stayed on the maintained original code, no change would occur other than those miners losing reward (mining fork-coins with no resale value) and the difficulty would adjust. The miners who made an error in choice would lose money and go out of business or rejoin the chain. However if something in that direction happens with actual users and companies on both sides of it users will lose money, the ledger will diverge as soon as a single double-spend happens, and never share a block again, companies will go instantly insolvent, and chaos will break out. This is the dangerous scenario we are concerned about. So the same question again: - How do you propose to deal with the extra risks that come from non-consensus hard-forks? Hard-forks themselves are quite risky, but non-consensus ones are extremely dangerous for consensus. Being sensitive to alarming the market It is something akin to Greece or Portugal or Italy exiting the euro currency in a disorderly way. Economists and central bank policy makers are extremely worried about such an eventuality and talk about related factors in careful, measured terms, watch Mario Draghi when he speaks. Imagine that bitcoin is 10x or 100x bigger. Bitcoin cant have people taking unilateral actions such as you have been proposing. It is not following the consensus governance process, and not good policy and it is probably affecting bitcoin confidence and price at this moment.
This is not a soft-fork, and the community will not want to take the risks once they understand them, and they have months in which to understand them and at this point you've motivated and wasted 100s of developer man hours such that we will feel impelled to make sure that no one opts into a unilateral hard-fork without understanding the risks. It would be negligent to allow people to do that. Before this gets very far FAQs will be on bitcoin.org etc explaining this risk I would imagine. Its just starting not finished. What makes you think the rest of the community may not instead prefer Jeff Garzik's BIP after revisions that he is making now with review comments from others? Or another proposal. Taken together with a deployment plan that sees work on decentralisation tying into that plan. - If you persisted anyway, what makes you think bitcoin could not make code changes defensively relating to your unilateral fork? (I am sure creative minds can find some ways to harden bitcoin against a unilateral fork, with a soft-fork or non-consensus update can be deployed much faster than a hard-fork). I tried to warn Gavin privately that I thought he was under-estimating the risk of failure to his fork proposal due to it being unilateral. Ie as you both seem sincere in your wish to have your proposal succeed, then obviously the best way to do that is to release a BIP in the open collaborative process and submit it to review like everyone else. Doing it unilaterally only increases its chance of failure. The only sensible thing to do here is submit a BIP and stop the unilateral fork threat. Scalability Plans
Yes people have proposed other plans. Bryan Bishop posted a list of them. Jeff Garzik has a proposal, BIP-100 which seems already better than Gavin's having benefit of peer review which he has been incorporating. I proposed several soft-fork models which can be deployed safely and immediately, which do not have ledger risk. I have another proposal relating to simplified soft-fork one-way pegs which I'll write up in a bit. I think there are still issues in Jeff's proposal but he is very open and collaborating and there maybe related but different proposals presently.
It does not seem to me that you understand the issue. Of course they want to increase the scalability of bitcoin. So does everyone else on this mailing list. That they would support that is obvious. If you presented your unilateral action plan without explaining the risks too. I think I covered this further above. If you would like to share the company list, or we can invite them to the proposed public physical meeting, I think it would be useful for them to have a balanced view of the ledger divergence risks, and alternative in-consensus proposals underway, as well as the governance risks, maintenance risks, security incident risks. Note that other people talk to companies too, as part of their day to day jobs, or from contacts from being in the industry. You have no special authority or unique ability to talk with business people. Its just that the technical community did not know you were busy doing that. I can not believe that any company that would listen to their CTO, CSO or failing that board would be ok with the risks implied by what you are proposing on full examination.
I know you want scale bitcoin, as I said everyone here does. I think what you're experiencing is that you've had more luck explaining your pragmatic unilateral plan to non-technical people without peer review, and so not experienced the kind of huge pushback you are getting from the technical community. The whole of bitcoin is immensely complicated such that it takes an uber-geek CS genius years to catchup, this is not a slight of any of the business people who are working hard to deploy Bitcoin into the world, its just complicated and therefore not easy to understand the game-theory, security, governance and distributed system thinking. I have a comp sci PhD in distributed systems, implemented p2p network systems and have 2 decades of applied crypto experience with a major interest in electronic cash crypto protocols, and it took me a several years to catchup and even I have a few hazy spots on low-level details, and I addictively into read everything I could find. Realistically all of us are still learning, as bitcoin combines so many fields that it opens new possibilities. What I am expecting that yourself and Gavin are thinking is that you'll knock heads and force the issue and get to consensus. However I think you have seriously misjudged the risks and have not adequately explained them to companies you are talking with. Indeed you do not fully seem to acknowledge the risks, nor to have a well thought out plan here of how you would actually manage it, nor the moral hazards of having a lone developer in hugely divisive circumstances in sole control of bitcoins running code. Those are exactly the reasons for the code change governance process! Even though you are trying to help, the full result is you are not helping achieve anything by changing a constant and starting a unilateral hard-fork (not to trivialise the work of making a patch to do that). The work to even make the constant change be feasible was a result of 1000s of hours of work by others in the development community, that is emphatically and unilaterally telling you that hard-forks are hugely inadvisable. You are trying to break the code change governance security procedure that were put in place for good reason for the security of $3b of other peoples money, even if you have a pragmatic intent to help, this is flat out unacceptable. There are also security implications to what you are proposing, which I have heard you attempting to trivialise, that are core to Bitcoins security and core functionality.
I think this is a significant mischaracterisation, and I think almost everybody is on board with a combination plan: 1. work to improve decentralisation (specific technical work already underway, and education) 2. create a plan to increase block-size in a slow fashion to not cause system shocks (eg like Jeff is proposing or some better variant) 3. work on actual algorithmic scaling In this way we can have throughput needed for scalability and security work to continue. As I said you can not scale a O(n^2) broadcast network by changing constants, you need algorithmic improvements. People are working on them already. All of those 3 things are being actively worked on RIGHT NOW, and in the case of algorithmic scaling and improve decentralisation have been worked on for months. You may have done one useful thing which is to remind people that blocks are only 3x-4x below capacity such that we should look at it. But we can not work under duress of haste, nor unilateral ultimatums, this is the realm of human action that leads to moral hazard, and ironically reminds us of why Satoshi put the quote in the genesis block. Bitcoin is too complex a system with too much at stake to be making political hasty decisions, it would be negligent to act in such a way. Again please consider that you did your job, caused people to pay attention, but return to the process, submit a BIP, retract the unilateral hard-fork which is so dangerous and lets have things be calm, civil and collaborative in the technical zone of Bitcoin and not further alarm companies and investors. Adam ------------------------------------------------------------------------------ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development ----- End forwarded message -----
So anyone want to take bets on if it's Gavin+Hearn that have a short position on bitcoin, or if it's Adam Back? (Well, okay, who's *paying* them that has a short position.. they probably have been conditioned to believe they are doing the 'right' thing) This to me looks like someone is engineering an engineering basis for a bitcoin price crash, just as demand is going to pick up. On Tue, Jun 16, 2015 at 10:11:31AM +0200, Eugen Leitl wrote:
-- ---------------------------------------------------------------------------- Troy Benjegerdes 'da hozer' hozer@hozed.org 7 elements earth::water::air::fire::mind::spirit::soul grid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash
It seems to me the real problem would be the community making a big deal about the fork, not the fork itself. Maybe the fork will take off, in which case anyone who has a position in Bitcoin now will have a position in the forked currency, or it won't, in which case who cares? Sure, Bitcoin might be less valuable for a while while people wait and see how the fork does, but anyone who thinks a hard fork is a large risk to Bitcoin compared to all the other risks it faces is deluding themselves. I think we would all be better off if the community said, "Fine, fork if you want. May the best fork win," than to sing doom and gloom every time someone decides not to follow the community process. Besides, a bunch of different people being involved does not a decentralized system make. Not if they all have to follow the same process and forks without consensus are not allowed. That can actually be worse in many ways than a benevolent dictatorship, because it will quickly ossify as the community grows larger and more diverse. If Bitcoin itself had to get community consensus before it was tried, we'd have no Bitcoin. I have no problem at all with someone deciding to fork it. In fact, I *prefer* it, because I think in the long run it makes my own position *more* valuable to have different forks trying different things. Anyone who holds Bitcoin before the fork gets the sum of the values of their account on each fork. Over the long run, the value on most forks will go to zero, but then it's at worst a max function. Claiming that forks make Bitcoin less valuable sounds to me a lot like Bernie Sanders saying we don't need so many choices of deodorant.
I would recommend to read the post. I thought it was fairly comprehensive and this is extremely bad both in network fork risk (which not everyone may understand details of as its quite intricate). Hard-forks should only be done with wide-spread consensus, and are fairly risky even then, but by doing it in a contentious divisive way - understand everyone in the technical community is very concerned - just unnecessarily magnifies the risk of failure. The other major issues being the precedent set and loss of decentralised code governance described in the post. A "distributed system" which has one or two developers, one who has a slight history for proposed a number of objectionable things in the past (red-lists etc) is not really distributed. How do we know other than assumption that they are not taking money to push preferred features, or under duress/blackmail etc. This is the point of the existing code change approval system to review and cross check against things like that. If people on *cypherpunks* cant get the points in the post, I think the world has a problem. The price of security in a distributed system like bitcoin is eternal vigilance, but if people dont understand what constitutes a risk and hence what to be vigilant for, the meta-system can be unreliable and lose its assurances. I think we need to explain some more concepts and probably people will over time learn things and and an influencer pyramid emerge as happened in privacy technology. Adam On 17 June 2015 at 17:44, Sean Lynch <seanl@literati.org> wrote:
On 6/17/15, Dr Adam Back <adam@cypherspace.org> wrote:
Adam, there are plenty who do understand. ... and clearly some who don't. for some of us, this question was answered *years* ago. NO HARD FORK! and at times feelings so heated there have been death threats against those pushing for a non-consensus hard-fork. they should take the fury and conviction regarding these concerns to heart, lest they under estimate the stakes at play and potential risks ahead. a hard fork is not Bitcoin - it is distraction. thank you for keeping the heat on this subject! best regards,
On Wed, Jun 17, 2015 at 3:51 PM Dr Adam Back <adam@cypherspace.org> wrote:
Yes, I'm sure that when people who disagree with you, it's always because they are wrong and never because you don't understand the situation as well as you think you do. I'm sure you know more about Bitcoin than Gavin does.
Its clear Gavin knows more about Bitcoin code and detailed micro algorithms than I do (there are many detailed algorithms for anti-DoS etc at code level which I do not know). Its possible I know more than Gavin or have a better internalised reasoning about the logic and design parameters for about decentralised systems and distributed trust systems, and ecash protocols, threat models in p2p privacy systems - which is quite a big slice of what Bitcoin is trying to do. Or not - I dont know all of Gavin's expertise nor career experience! Something you may not realise is a bunch of us on the cypherpunks list back in like 1995-2005 spent a lot of applied research effort into finding a way to do something with the characteristics of bitcion. My PhD is in distributed systems also. Anyway I do not mean to have claims to authority, particularly because I believe firmly in pure meritocracy philosophically and detest such argumentation as a failure of reason, but coincidentally I do actually know something about it and worked on it on Bitcoin-like system design and p2p novel trust-model & security model on and off for 20 years. But I do think people who are proposing big-blocks are underestimating and being super-optimistic about a range of things, almost to naive extent. I am not imputing unsaid things, Gavin wrote many blog posts on these topics. Mike Hearn made some videos and posts about his views, and they are quite disconnected from p2p privacy system design thinking. Someone should probably respond to some of those posts to clarify why they think some of these assumptions are incorrect and optimistic to prior experience and precedent. Adam On 18 June 2015 at 20:24, Sean Lynch <seanl@literati.org> wrote:
Coming in a bit later here. To me the essence of the reasoning for the fork is to head off the possibility that sometime in the not too distant future the demand of bitcoin users to transact on the blockchain will exceed the supply. That certainly might happen if fees don't respond to supply-demand economics. Those pushing bitcoin to compete with MasterCard/VISA are, IMHO, a bit crazy. Like shoemakers always reaching for a hammer every time these people see a transactional opportunity they reach for the blockchain. I think that's just plain silly. Bitcoin is not well suited for all transactional situations. In the longer-term it seems great to replace, for example, SWIFT and bank wires but rather poor for those that require cheap- or ultra-cheap real-time settlement whereas some alternatives seem tailor-made for this. Then again maybe I am missing the key reasoning for this fork. On Fri, Jun 19, 2015 at 5:07 AM, Dr Adam Back <adam@cypherspace.org> wrote:
Dnia czwartek, 18 czerwca 2015 18:24:14 Sean Lynch pisze:
Wow, that's a low blow. Arguing by authority, and then a false dichotomy: "either you know more about Bitcoin than X, or you should not have a voice at all on this" Might I suggest considering arguing on the merits instead, next time? :) -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147
On Sun, Jun 28, 2015, 12:38 rysiek <rysiek@hackerspace.pl> wrote: Dnia czwartek, 18 czerwca 2015 18:24:14 Sean Lynch pisze:
Wow, that's a low blow. Arguing by authority, and then a false dichotomy: "either you know more about Bitcoin than X, or you should not have a voice at all on this" Might I suggest considering arguing on the merits instead, next time? :) Perhaps if you bothered to read more than the last message in the thread you would realize that I already attempted that. I think your expectations are a bit high when there are people on the thread arguing that we should really consider the opinions of those making death threats. IOW listen to the terrorists. It seems to me that people are terrified by a hard fork because they have a huge stake in Bitcoin. To me that's the best argument there could possibly be to fork now and get it out of the way. Bitcoin can't survive if it ossifies due to the fears of morons who can't be bothered to diversify their investment, and who have such low morals that they'd stoop to making death threats. If we're going to argue based on the merits then let's do that, and leave the death threats and doom and gloom out of it. We need to be thinking beyond Bitcoin to the future of cryptocurrencies on general, and a healthy cryptocurrencies ecosystem cannot survive as an ossified monoculture.
By the way, "consensus" is a red herring thrown out by those who never want there to be a fork. There can never be consensus for a fork, because otherwise it wouldn't be a fork. Claiming there needs to be consensus is just a way to try to make it look like any fork is somehow unilateral and undemocratic. But to succeed, any fork by definition needs broad support. In fact, it's about the most democratic you can get: people put their money and their mining power on the fork they want. It's those opposing any fork who are the authoritarians. Obviously, when you consider who's making the death threats.
It's not the miners that count, rather than economic majority. It's a surprising fact, but here's how it works: lets imagine 75% of the miners decided they'd change the economic rules, in a protocol incompatible way. Result: the miners form a new alt-coin with no users. Bitcoin difficulty adjusts, and carries on as if nothing happened. The hostile miners earn 25 forkcoins which have a market price of 0. They are burning electricity so they either go bankrupt or the give up and rejoin the network. There's a lot to game theory that is subtle. It could do with a FAQ writing on it really. Adam On 28 June 2015 at 23:04, Sean Lynch <seanl@literati.org> wrote:
Which means that those with a stake in Bitcoin are better off if a fork becomes popular than if an altcoin does, because if a fork becomes popular they will already have a stake in the fork, whereas if the altcoin becomes popular at the expense of Bitcoin they will have nothing. Of course, if a fork undermines faith in Bitcoin without becoming popular, everyone will be screwed. But I don't think this is likely; either it will become popular and we'll all be better off, or it will flop and nobody will care. The worst case scenario is that some fatal flaw eventually emerges in Bitcoin, one that would not have affected a proposed fork or altcoin but that instead wipes out Bitcoin holders and undermines faith in all cryptocurrencies. On Sun, Jun 28, 2015, 15:52 Sean Lynch <seanl@literati.org> wrote:
On 6/28/15, Sean Lynch <seanl@literati.org> wrote:
you make lots of false dichotomies here, neglecting the variations in exchange value between these possible altcoins and forks. "will have nothing" is not correct. maybe a little, maybe a lot, but more than "nothing".
totally screwed - this is where the heated passions about a non-census hard fork come in. lives on the line, in a not so exaggerated sense. and by no means am i threating anyone with harm! i am explaining that when someone puts the last half decade of their life and fortune into a thing, messing with it will always generate inflamed arguments. regardless of if you're ultimately right or not. i don't care how you describe that messing, consensus or not, it's poking in sensitive places all the same...
But I don't think this is likely; either it will become popular and we'll all be better off, or it will flop and nobody will care.
"not likely" - you're going to gamble livelihoods on a hunch that it's not likely? you can see why many are so reluctant - the due diligence is lacking and the demeanor more experiment than careful transition... best regards,
On Mon, Jun 29, 2015, 16:41 coderman <coderman@gmail.com> wrote: On 6/28/15, Sean Lynch <seanl@literati.org> wrote:
you make lots of false dichotomies here, neglecting the variations in exchange value between these possible altcoins and forks. "will have nothing" is not correct. maybe a little, maybe a lot, but more than "nothing" I'm simplifying out of necessity. Obviously there are intermediate outcomes possible.
totally screwed - this is where the heated passions about a non-census hard fork come in. lives on the line, in a not so exaggerated sense. Yes. And a failure to accept responsibility for one's own decisions. Anyone gambling everything on Bitcoin right now is an idiot, in my view. Their opinions should be discounted as they have proven their own judgement lacking. Perhaps they will be vindicated, but the fact that you happen to win a poker hand you played badly doesn't retroactively mean you played the hand well. It means you got lucky. and by no means am i threating anyone with harm! i am explaining that when someone puts the last half decade of their life and fortune into a thing, messing with it will always generate inflamed arguments. regardless of if you're ultimately right or not. Never said you were the one making threats, and I agree this sort of thing will create inflamed passions. All the more reason to try to filter out the opinions of those with a large stake. i don't care how you describe that messing, consensus or not, it's poking in sensitive places all the same... A fact that makes Satoshi's decision to remain anonymous seem even wiser in retrospect. Perhaps this will be required of any such system in the future.
But I don't think this is likely; either it will become popular and we'll all be better off, or it will flop and nobody will care.
"not likely" - you're going to gamble livelihoods on a hunch that it's not likely? I'm not proposing anyone gambling anything. The gambling is being done by those holding Bitcoin. Holding Bitcoin places no obligation on anyone else. It's not a stock or bond or other instrument with an associated contract. you can see why many are so reluctant - the due diligence is lacking and the demeanor more experiment than careful transition... I doubt there is anything the larger stakeholders (as fraction of their net worth) would accept as due diligence. Nor is any required to start a fork. Any due diligence is the responsibility of those choosing to operate on the fork. Those involved should do it to maintain their reputations, but if they don't, and people get burned, their reputations will suffer. Death threats and advance pseudo-democracy not required. best regards,
On 6/29/15, Sean Lynch <seanl@literati.org> wrote:
... Yes. And a failure to accept responsibility for one's own decisions.
this is not about poor user decisions, this is about violation of the contract "a bitcoin is forever (and in the blockchain)" you see expediency, and no excuses for those lacking judgment. their eyes prescient instead, until one comes to change the rules out from under their feet... to assume old coins can "just be" resolved for all holders in all circumstances is to lie, and there is nothing else to call "deprecating old coins unilaterally" other than a hard-fork, and a non-consensus one at that.
I doubt there is anything the larger stakeholders (as fraction of their net worth) would accept as due diligence. Nor is any required to start a fork.
sure; these are very different from a "non-consensus hard-fork" [deprecate old, force to new] intentionally trying to divert and betray the contract inherent since the start - a bitcoin is forever - is more than "just a fork", it's also a stab in the back. i don't know how to solve a transition like this, but i know a forced hard fork is near the worst way to handle it.
Any due diligence is the responsibility of those choosing to operate on the fork.
agreed; thanks for the patient response to my dismissive retort. best regards,
On 6/29/15, coderman <coderman@gmail.com> wrote:
...
not to belabor the point, but the summary presented by Adam is spot on: """ ... everybody is on board with a combination plan: 1. work to improve decentralisation (specific technical work already underway, and education) 2. create a plan to increase block-size in a slow fashion to not cause system shocks (eg like Jeff is proposing or some better variant) 3. work on actual algorithmic scaling In this way we can have throughput needed for scalability and security work to continue. As I said you can not scale a O(n^2) broadcast network by changing constants, you need algorithmic improvements. People are working on them already. All of those 3 things are being actively worked on RIGHT NOW, and in the case of algorithmic scaling and improve decentralisation have been worked on for months. You may have done one useful thing which is to remind people that blocks are only 3x-4x below capacity such that we should look at it. But we can not work under duress of haste, nor unilateral ultimatums, this is the realm of human action that leads to moral hazard, and ironically reminds us of why Satoshi put the quote in the genesis block. """ time spent joining others on these efforts is time well spent. time spent advocating for a non-consensus hard-fork is less than helpful.
On Mon, Jun 29, 2015, 20:12 coderman <coderman@gmail.com> wrote: On 6/29/15, Sean Lynch <seanl@literati.org> wrote:
... Yes. And a failure to accept responsibility for one's own decisions.
this is not about poor user decisions, this is about violation of the contract "a bitcoin is forever (and in the blockchain)" With a hard fork, the Bitcoins exist in both forks. If one dies, they live on in the remaining one. If Bitcoin itself is never forked and dies, the contract is violated. But I have to ask, contract with whom? This is part of the specification of the protocol, but people are only bound by it insofar as they choose to implement the protocol. And probably as far as they choose to participate in the network. But a fork need not require any interaction with the original network aside from fetching the block chain prior to the block it forks from. you see expediency, and no excuses for those lacking judgment. their eyes prescient instead, until one comes to change the rules out from under their feet... I see what could be the only viable course. Consensus is not practical in a large, diverse community with vastly divergent goals. to assume old coins can "just be" resolved for all holders in all circumstances is to lie, and there is nothing else to call "deprecating old coins unilaterally" other than a hard-fork, and a non-consensus one at that. Nobody can deprecate old coins unilaterally. It's up to each individual to decide what they're worth and whether to participate. As I said, as I understand your use of the term "consensus", a hard fork is by definition non-consensus, because if there were consensus everyone would just switch to the new protocol. Sure, people could consent to allow others to work on another protocol, but there will always be plenty of people who only want there to be one chain, so consensus of that form is impossible.
Any due diligence is the responsibility of those choosing to operate on
sure; these are very different from a "non-consensus hard-fork" [deprecate old, force to new] intentionally trying to divert and betray the contract inherent since the start - a bitcoin is forever - is more than "just a fork", it's also a stab in the back. I am sympathetic to the view that "law" = people's reasonable expectations, but whether those expectations are reasonable is really what we're discussing here. I think Bitcoin is both too immature and too decentralized to be able to say yes. Maturity will eventually trump decentralization for this purpose. i don't know how to solve a transition like this, but i know a forced hard fork is near the worst way to handle it. I think "forced" is too strong a word here. Against whom is force being used? Who is having to do something against their will? Or who was defrauded and by whom? From a consent standpoint, this is no different than forking any other open source project. the
fork.
agreed; thanks for the patient response to my dismissive retort. best regards, And thanks for taking the time to discuss this.
Dnia niedziela, 28 czerwca 2015 20:52:43 Sean Lynch pisze:
But that's exactly why I was so surprised. I filter out the people that make no sense or deat5h threats, but when I see a person that usually seems to make sense, and yet lands a straw man, I'm taken aback. :)
Fair point.
The question is: can the *cryptocurrency* ecosystem survive if BitCoin hard- forks. Some say "no, because loss of trust"; some say "yeah, it will actually grow strong". I'm not convinced either way. -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147
2015-07-02 18:38 GMT+09:00 rysiek <rysiek@hackerspace.pl>:
Saying Gavin knows quite a lot about Bitcoin is not an argument of authority. It doesn't make him right, but it does make him very likely to be right. Certainly more likely than the heapings of shitty arguments, especially those that are technically disconnected from what bitcoin is. When you listen to the arguments about blocksize it usually goes something like: Pro: * Cheaper transactions * More truly Bitcoin transactions * Simplest way to scale There's some derivative arguments regarding poor people's access to Bitcoin and a herd of applications that just require cheap access to the blockchain. I think the most noteworthy argument is: * Bitcoin becomes more competitive/attractive as a result of cheaper transactions Con: * We can already fit quite some txs * the blockchain will be less wieldable * the bandwidth required to keep up with the blockchain (regardless of storage) will increase * we can scale externally The derivative arguments here are also poor people's access to Bitcoin, wrt bandwidth, but the argument holds up much worse as SPV would work just fine over those rare very slow connections. Then there's a lot of downright fearmongering like "only institutions will run full nodes". Economically that's just not true, and technologically it's not important - crypto features allow usability immediately (simplefied (commercial) APIs, "blind" tx broadcasting), strong guarantees *very *quickly (SPV), and certainty and independence if you'd like it (a pruning full node), and history novelty at only minor hassle (less than a day's work). Even a 100 fold increase in blocksize would not radically change this. It's pretty annoying to have an even bigger blockchain, don't get me wrong on that, but that's just the way Bitcoin works: a blockchain that grows with use. There's no reason for it to truly upset you, either. Running a full node is already something you don't do for no reason at all. I can't really make this argument as well as I like. The point is that if you have a reason you would still do it later, and if you don't you don't already. Some people noted that the pruning makes it possible to run a full node on their phones. Cool! But there's no reason to. In fact, you won't because it'd drain your battery. We'll be okay without the one silly geek that does it anyway. So.. these points were already hard to argue against clearly. Then there's "we can scale externally".... The trouble is that there's so many ways, like pinning (sidechains/mastercoin), exclusively inter-institutional settlement, debt based moneys ("the bearer of this token is entitled to..."), and all of them could work! In fact, we could just abandon Bitcoin alltogether! And that's the core of my counterargument: we don't have to cripple Bitcoin, so let's not. Let's not make it more complicated than it has to be. If we do scale externally, let it be for exceedingly good reasons and at exceedingly competitive prices. Mostly I see people haggling over nothing on Reddit, and even here. There's also confusion about roles in the Bitcoin ecosystem, and about ideals. Then there's confusion about consent, and how to manage it. It's probably because all those things are badly fleshed out. Hard-to-achieve consensus has advantages; Bitcoin will be technologically stable. The roles will shift anyway. Ideals are not inherent, only cold hard currency is. It's implications depend on culture and math, both generally not very well understood. Reddit has never been conducive to quality argument - at fantastic loss to everyone but the populists. I think, ultimately, that giving Gavin ultimate authority for 10 years then freezing the whole ordeal would probably work out rather well. I think it's ran afoul of his control too soon. We already have some weird bugs in Bitcoin. Then there's some strange (unstudied) economical effects like the halving (and why not gradual decrease?). I'm sure lots of people found similar oddities from their perspectives. There's just not much to do about it anymore now. The Chinese mining pools stamping their document regarding increasing the blocksize to 8mb was extraordinary. They ignored Gavin's 20mb or anything proposal ("or anything" probably mostly to make 20mb seem reasonable). They stamped - a thing completely outdated in the West, yet common in Asia (and pretty badass). They are a group of Chinese making law for everyone. (not-a-magnet-or-similar-document-oriented-link: http://i.imgur.com/JUnQcue.jpg) Gavin appeased them and provided for unattended growth with a period 8mb increase. Smart move. So - conclusively - Gavin is a hero, the Internet's retarded, Bitcoin is in policy jail but it likes it there. Oh, and the free-est market of the world is already significantly run by Chinese. If you read this far, thanks.
On 7/2/15, Lodewijk andré de la porte <l@odewijk.nl> wrote:
thank you for the patient summarization of many complex points of contention around this subject, including the social(market) aspects which may not come easy to a technical mind.
speaking of "not much to do about it now..." :)
agreed. onward to proof of useful work! [sounds trivial, let's r/AskReddit! ...] best regards,
On 7/2/15, coderman <coderman@gmail.com> more bullshit...:
...
btw, actual consensus hard fork - early days of bitcoin you get a badtx/freminehack it was possible and tractable to manage a coordinated, voluntary consensus move to specific re-wind, specific revision, and resume. it took exceptional circumstances - and as per thread above and long discussions else where, there is nothing nearly so dire facing BTC's present or near future. beyond that, who can say with confidence? including those proposing unprecedented actions against consensus? if i was back in FR for the fourth, i'd have some of this tenderized horse corpse for meal. instead, end of my opinion here. best regards,
On 2015-07-03 09:24, Lodewijk andré de la porte wrote:
Way back in the beginning I said an ever growing block chain would cause unacceptable costs and inconvenience, and lo and behold, it is causing substantial and ever growing costs and inconvenience. Of course, restraining the block chain to manageable growth without losing other good characteristics is inherently hard, and it was a lot easier for me to point at the problem than to fix it.
On Sun, Jul 5, 2015, 18:44 James A. Donald <jamesd@echeque.com> wrote: Way back in the beginning I said an ever growing block chain would cause unacceptable costs and inconvenience, and lo and behold, it is causing substantial and ever growing costs and inconvenience. Of course, restraining the block chain to manageable growth without losing other good characteristics is inherently hard, and it was a lot easier for me to point at the problem than to fix it. I had been hoping that we would see more stuff happening off-blockchain by now, with Bitcoin acting more as a clearing house between smaller payment providers, but all the regulations protecting the big banks from competition make it really hard to do anything off-blockchain that looks even remotely like a payments service. Side chains of some kind seem like a reasonable approach, and I'm guessing that it will be the difficulty of dealing with the "central" block chain that will finally force people "over the hump" into using some kind of sidechain payments system. I really want to see micropayments, for example, and those seem to be too unwieldy and expensive to do the main chain.
On Mon, 06 Jul 2015 11:39:00 +1000 "James A. Donald" <jamesd@echeque.com> wrote:
But look at the bright side! Every single transaction gets recorded and stored, until jesus destroys the universe (it's in the bible). What else can privacy advocates wish for?
On Sun, Jul 5, 2015 at 10:41 PM Juan <juan.g71@gmail.com> wrote:
Transparency is also useful, and privacy can be built on top of it through the use of, say, Chaumian e-cash backed by a blockchain-based cryptocurrency. It's a lot easier for the issuing organization to prove that it has a certain amount of Bitcoin than a certain amount of gold. E-gold and even one of the gold ETFs have been accused of double-counting. And if you're using Tor to connect to the network and break up your transactions, it's pretty easy to obfuscate, even without ZeroCoin, and ZeroCoin just fixes the whole problem.
On Mon, 06 Jul 2015 17:04:56 +0000 Sean Lynch <seanl@literati.org> wrote:
Well, I wasn't advocating any solution in particular, just making a snarky remark on one of bitcoin's most notable (IMO at least) properties. But since you mention something like e-gold (or similar systems) : yes, I realize they have the same problmes any ordinary bank has - how to make sure they are not lying.
I guess it's wait and see for me. I freely admit I'm tad a skeptical about the whole crypto infrastructure... (not even taking 'solutions' like tor into account...)
2015-07-06 10:39 GMT+09:00 James A. Donald <jamesd@echeque.com>:
It is, but also it really isn't. Spending an hour of my lawyer talks to your lawyer costs more than the whole blockchain, including operational costs, for a long time. If you'd like to do anything with a bank, for a fraction of the features at IMMENSELY OVERSIZED WTF prices - just the time spent negotiating it is outrageously more expensive. We're nowhere near unacceptable, and it doesn't seem we will ever be. It's something to think about, and you'll have to use SPV/API's in many cases where there would be some value to not having to use them. That's definitely not convenient, but also not that big a deal. Juan:
Bitcoin is often misrepresented to be: * Private * Free * Promoting equality (it does the /exact/ opposite!) * Jesus Don't play a satire of the shims, Juan. Whales pay liars, just ignore people's words and hear their arguments. The only thing that's hard is realizing so few are doing it.
On Sun, Jul 5, 2015 at 9:39 PM, James A. Donald <jamesd@echeque.com> wrote:
Doubt there's any use case that requires "bignum" worth of single fully independant "full" nodes trucking around tens of TB worth of ancient history. With new things come new rules. Bitcoin could declare 1/2/5/10 year checkpoint intervals by which addresses must forward to new addresses. It could distribute the legacy data across legacy archive farms who demand monetize their existance as daily tx miners do. If for some reason user wasn't able to forward in time, the farms could issue checkpoint statements [for all] or sign their tx for a fee, user might dissolve value back into and out of the farms under contract, etc. Seems many different ways to solve the petabytes / phone problem. And as long as no one, not even the anonymous ever has to go outside bitcoin, such as to an exchange... it's still bitcoin. What's "hard" about bitcoin is deciding how to do the tech while still remaining true to the original philosophies.
participants (12)
-
Adam Back
-
coderman
-
Dr Adam Back
-
Eugen Leitl
-
grarpamp
-
James A. Donald
-
Juan
-
Lodewijk andré de la porte
-
rysiek
-
Sean Lynch
-
Steven Schear
-
Troy Benjegerdes