* [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork
@ 2015-06-15 0:04 Adam Back
2015-06-15 9:56 ` Mike Hearn
2015-06-17 3:52 ` Troy Benjegerdes
0 siblings, 2 replies; 29+ messages in thread
From: Adam Back @ 2015-06-15 0:04 UTC (permalink / raw)
To: Bitcoin Dev
Mike Hearn <mike@plan99•net> wrote:
> Which is why there will soon be a fork that does it.
I understand why you would be keen to scale bitcoin, everyone here is.
But as you seem to be saying that you will do a unilateral hard-fork,
and fork the code-base simultaneously, probably a number of people
have questions, so I'll start with some:
( I noticed some of your initial thoughts are online here
https://www.youtube.com/watch?v=DB9goUDBAR0 or the full podcast
https://epicenterbitcoin.com/podcast/082/ )
- Are you releasing a BIP for that proposal for review?
- If the reviewers all say NACK will you take on board their suggestions?
- 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.
- 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.
- If you're going it alone as it were, are you proposing that you will
personally maintain bitcoin-XT? Or do you have a plan to later hand
over maintenance to the bitcoin developers?
- Do you have contingency plans for what to do if the non-consensus
hard-fork goes wrong and $3B is lost as a result?
As you can probably tell I think a unilateral fork without wide-scale
consensus from the technical and business communities is a deeply
inadvisable. While apparently some companies have expressed interest
in increased scale, I can only assume they do no yet understand the
risks. I suggest before they would actually go ahead that they seek
independent advice.
Of the overall process, I think you can agree we should not be making
technical decisions with this level of complexity and consensus risk
with financial implications of this magnitude under duress of haste?
This seems otherwise a little like the moral hazard of the 2008
financial collapse that Satoshi put the quote in the genesis block
about.
I think its best that we progress as Jeff Garzik has done to have
engineering discussions centre around BIPs, running code for review,
simulation and careful analysis.
I understand this has been going on for a long time, and some people
are frustrated with the rate of progress, but making hasty,
contentious or unilateral actions in this space is courting disaster.
Please use your considerable skills to, along with the rest of the
community, work on this problem collaboratively.
I can sincerely assure you everyone does want to scale bitcoin and
shares your long term objective on that.
Adam
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-15 0:04 [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork Adam Back @ 2015-06-15 9:56 ` Mike Hearn 2015-06-15 18:03 ` Adam Back ` (2 more replies) 2015-06-17 3:52 ` Troy Benjegerdes 1 sibling, 3 replies; 29+ messages in thread From: Mike Hearn @ 2015-06-15 9:56 UTC (permalink / raw) To: Adam Back; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 5913 bytes --] Hi Adam, Provisional answers below! - Are you releasing a BIP for that proposal for review? > The work splits like this: - Gavin is writing the code and I think a BIP as well - I will review both and mostly delegate to Gavin's good taste around the details, unless there is some very strong disagreement. But that seems unlikely. - I have been handling gitian and the patch rebases, the code signing and so on, so far. I've also been doing some work to setup the basic infrastructure of the project (website etc). - If the reviewers all say NACK will you take on board their suggestions? > Feedback will be read. There are no NACKS in Bitcoin XT. Patch requests aren't scored in any way. The final decision rests with the maintainer as in ~all open source projects. > - 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. > Yes, I have been working on an article that explains how we got to this point from my perspective. It is quite long, but only because I want it to be readable for people who weren't following the debate. Anyway, I think I've laid out the gist of it over and over again, but to summarise: If Bitcoin runs out of capacity *it will break and many of our users will leave*. That is not an acceptable outcome for myself or the many other wallet, service and merchant developers who have worked for years to build an ecosystem around this protocol. > - 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. > The approach is the same for other forks. Voting via block versions and then when there's been >X% for Y time units the 1mb limit is lifted/replaced. > - If you're going it alone as it were, are you proposing that you will > personally maintain bitcoin-XT? Or do you have a plan to later hand > over maintenance to the bitcoin developers? > Good question! I have various thoughts on this, but let's wait and see what happens first. Perhaps the new chain won't get the majority on it. In the event that the >1mb chain does eventually win, I would expect Core to apply the patch and rejoin the consensus rather than lose all its users. That would take XT back to being a fairly small patchset to improve the network protocol. - Do you have contingency plans for what to do if the non-consensus > hard-fork goes wrong and $3B is lost as a result? > Where did you get the $3B figure from? The fork either doesn't happen, or it happens after quite a long period of people knowing it's going to happen - for example because their full node is printing "You need to upgrade" messages due to seeing the larger block version, or because they read the news, or because they heard about it via some other mechanisms. Let me flip the question around. Do you have a contingency plan if Bitcoin runs out of capacity and significant user disruption occurs that results in exodus, followed by fall in BTC price? The only one I've seen is "we can perform an emergency hard fork in a few weeks"! > As you can probably tell I think a unilateral fork without wide-scale > consensus from the technical and business communities is a deeply > inadvisable. Gavin and I have been polling many key players in the ecosystem. The consensus you seek does exist. All wallet developers (except Lawrence), all the major exchanges, all the major payment processors and many of the major mining pools want to see the limit lifted (I haven't been talking to pools, Gavin has). This notion that the change has no consensus is based on you polling the people directly around you and people who like to spend all day on this mailing list. It's not an accurate reflection of the wider Bitcoin community and that is one of the leading reasons there is going to be a fork. A small number of people have been flatly ignoring LOTS of highly technical and passionate developers who have written vast amounts of code, built up the Bitcoin user base, designed hardware and software, and yes built companies. How do you think that makes Bitcoin Core look to the rest of the Bitcoin world? How much confidence does that give people? Of the overall process, I think you can agree we should not be making > technical decisions with this level of complexity and consensus risk > with financial implications of this magnitude under duress of haste? > This debate will never end until a fork makes it irrelevant. There is no process for ending it, despite me begging Wladimir to make one. And there is no haste. We have been debating the block size limit for *years*. We have known it must be lifted for *years*. I kicked off this current round of debates after realising that Wladimir's release timeline wouldn't allow a block size limit to be released before the end of the year. The reason we're talking about it now and not next year is exactly to ensure there is plenty of time. > I can sincerely assure you everyone does want to scale bitcoin and > shares your long term objective on that I really wish you were right, and I definitely feel you are one of the more reasonable ones Adam. But the overwhelming impression I get from a few others here is that no, they don't want to scale Bitcoin. They already decided it's a technological dead end. They want to kick end users out in order to "incentivise" (force) the creation of some other alternative, claiming that it's still Bitcoin whilst ignoring basic details ... like the fact that no existing wallets or services would work. Scaling Bitcoin can only be achieved by letting it grow, and letting people tackle each bottleneck as it arises at the right times. Not by convincing ourselves that success is failure. [-- Attachment #2: Type: text/html, Size: 8718 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-15 9:56 ` Mike Hearn @ 2015-06-15 18:03 ` Adam Back 2015-06-15 20:55 ` Mike Hearn 2015-06-16 12:33 ` Pindar Wong 2015-06-15 22:54 ` odinn 2015-06-16 5:18 ` Venzen 2 siblings, 2 replies; 29+ messages in thread From: Adam Back @ 2015-06-15 18:03 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev 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: > I will review both and mostly delegate to Gavin's good taste around the > details, unless there is some very strong disagreement. But that seems > unlikely. > ... > Feedback will be read. There are no NACKS in Bitcoin XT. Patch requests > aren't scored in any way. The final decision rests with the maintainer as in > ~all open source projects. 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. >> - 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. > > If Bitcoin runs out of capacity it will break and many of our users will > leave. That is not an acceptable outcome for myself or the many other > wallet, service and merchant developers who have worked for years to build > an ecosystem around this protocol. 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? > If Bitcoin runs out of capacity it will break and many of our users will > leave. That is not an acceptable outcome for myself or the many other > wallet, service and merchant developers who have worked for years to build > an ecosystem around this protocol. 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 >> - 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. > > The approach is the same for other forks. Voting via block versions and then > when there's been >X% for Y time units the 1mb limit is lifted/replaced. 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. >> - Do you have contingency plans for what to do if the non-consensus >> hard-fork goes wrong and $3B is lost as a result? > > Where did you get the $3B figure from? The fork either doesn't happen, or it > happens after quite a long period of people knowing it's going to happen - > for example because their full node is printing "You need to upgrade" > messages due to seeing the larger block version, or because they read the > news, or because they heard about it via some other mechanisms. 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 > Let me flip the question around. Do you have a contingency plan if Bitcoin > runs out of capacity and significant user disruption occurs that results in > exodus, followed by fall in BTC price? The only one I've seen is "we can > perform an emergency hard fork in a few weeks"! 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. >> As you can probably tell I think a unilateral fork without wide-scale >> consensus from the technical and business communities is a deeply >> inadvisable. > > Gavin and I have been polling many key players in the ecosystem. The > consensus you seek does exist. All wallet developers (except Lawrence), all > the major exchanges, all the major payment processors and many of the major > mining pools want to see the limit lifted (I haven't been talking to pools, > Gavin has). 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. > This notion that the change has no consensus is based on you polling the > people directly around you and people who like to spend all day on this > mailing list. It's not an accurate reflection of the wider Bitcoin community > and that is one of the leading reasons there is going to be a fork. A small > number of people have been flatly ignoring LOTS of highly technical and > passionate developers who have written vast amounts of code, built up the > Bitcoin user base, designed hardware and software, and yes built companies. 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. > the overwhelming impression I get from a few > others here is that no, they don't want to scale Bitcoin. They already > decided it's a technological dead end. 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-15 18:03 ` Adam Back @ 2015-06-15 20:55 ` Mike Hearn 2015-06-15 21:56 ` Bryan Bishop 2015-06-16 12:33 ` Pindar Wong 1 sibling, 1 reply; 29+ messages in thread From: Mike Hearn @ 2015-06-15 20:55 UTC (permalink / raw) To: Adam Back; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1413 bytes --] Hi Adam, I replied publicly because your questions were sent to the mailing list. I'd have been happy to reply in private if so asked. I started to write up a much longer reply, but I'm tired - we've long since been going in circles. I feel like I've written down answers to almost all your questions before, including some in the email above. Still, there are a few new ones. Let me work through them now. Yes, I am on the bitcoin-security list. I have always been on it. I have taken part in many threads there and started one or two myself. I guess you're not though, otherwise you'd know that. You can ask, I'm sure Gavin will add you if you like. Re: BIP. Gavin is working on a BIP to go along with his patch. I hope that will satisfy. I do not expect the resulting discussion to differ much from the discussion so far, though. Re: summit. No, I would not attend. I have been to several Bitcoin conferences over the years where the block size issue was discussed. No progress was ever made at these events. Re: if some flaw or bug was found in the patch. Yes, of course if there was some specific problem with the code then we would fix it. There will be time to review Gavin's patches for these reasons. Re: anyone who agrees with noted non-programmers Mike&Gavin must be non-technical, stupid, uninformed, etc .... OK, go ahead and show them the error of their ways. Anyone can write blogs. [-- Attachment #2: Type: text/html, Size: 1867 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-15 20:55 ` Mike Hearn @ 2015-06-15 21:56 ` Bryan Bishop 2015-06-15 22:17 ` Faiz Khan 2015-06-16 11:20 ` Mike Hearn 0 siblings, 2 replies; 29+ messages in thread From: Bryan Bishop @ 2015-06-15 21:56 UTC (permalink / raw) To: Mike Hearn, Bryan Bishop; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1234 bytes --] On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn <mike@plan99•net> wrote: > Re: anyone who agrees with noted non-programmers Mike&Gavin must be > non-technical, stupid, uninformed, etc .... OK, go ahead and show them the > error of their ways. Anyone can write blogs. > I worry that if this is the level of care you take with reading and (mis)interpreting Adam's messages, that you might not be taking extreme care with evaluating consensus changes, even while tired or sleeping. I encourage you to evaluate both messages and source code more carefully, especially in the world of bitcoin. However, this goes for everyone and not just you. Specifically, when Adam mentioned your conversations with non-technical people, he did not mean "Mike has talked with people who have possibly not made pull requests to Bitcoin Core, so therefore Mike is a non-programmer". Communication is difficult and I can understand that, but we really have to be more careful when evaluating each other's messages; technical miscommunication can be catastrophic in this context. On the topic of whether you are a programmer, I suspect that ever since you built CIA.vc we have all known you're a programmer, Mike. - Bryan http://heybryan.org/ 1 512 203 0507 [-- Attachment #2: Type: text/html, Size: 1794 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-15 21:56 ` Bryan Bishop @ 2015-06-15 22:17 ` Faiz Khan 2015-06-15 22:56 ` Brian Hoffman 2015-06-16 11:29 ` Mike Hearn 2015-06-16 11:20 ` Mike Hearn 1 sibling, 2 replies; 29+ messages in thread From: Faiz Khan @ 2015-06-15 22:17 UTC (permalink / raw) To: Bryan Bishop; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2852 bytes --] I'm quite puzzled by the response myself, it doesn't seem to address some of the (more serious) concerns that Adam put out, the most important question that was asked being the one regarding personal ownership of the proposed fork: "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?" I do genuinely hope that whomever (now and future) wishes to fork the protocol reconsider first whether they are truly ready to test/flex their reputation/skills/resources in this way... Intuitively, to me it seems counterproductive, and I don't fully believe it is within a single developer's talents to manage the process start-to-finish (as it is non-trivial to hard-fork successfully, others have rehashed this in other threads)... That being said I think it appropriate if Adam's questions were responded in-line when Mike is feeling up to it. I think that the answers are important for the community to hear when such a drastic change is being espoused. Faiz On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop <kanzure@gmail•com> wrote: > On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn <mike@plan99•net> wrote: > >> Re: anyone who agrees with noted non-programmers Mike&Gavin must be >> non-technical, stupid, uninformed, etc .... OK, go ahead and show them the >> error of their ways. Anyone can write blogs. >> > > I worry that if this is the level of care you take with reading and > (mis)interpreting Adam's messages, that you might not be taking extreme > care with evaluating consensus changes, even while tired or sleeping. I > encourage you to evaluate both messages and source code more carefully, > especially in the world of bitcoin. However, this goes for everyone and not > just you. Specifically, when Adam mentioned your conversations with > non-technical people, he did not mean "Mike has talked with people who have > possibly not made pull requests to Bitcoin Core, so therefore Mike is a > non-programmer". Communication is difficult and I can understand that, but > we really have to be more careful when evaluating each other's messages; > technical miscommunication can be catastrophic in this context. On the > topic of whether you are a programmer, I suspect that ever since you built > CIA.vc we have all known you're a programmer, Mike. > > - Bryan > http://heybryan.org/ > 1 512 203 0507 > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- > > My regards, > > Faiz Khan > > <https://lists.sourceforge.net/lists/listinfo/bitcoin-development> [-- Attachment #2: Type: text/html, Size: 4285 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-15 22:17 ` Faiz Khan @ 2015-06-15 22:56 ` Brian Hoffman 2015-06-15 23:05 ` [Bitcoin-development] questions about bitcoin-XT code fork &non-consensus hard-fork Raystonn . 2015-06-16 0:08 ` [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork Aaron Voisine 2015-06-16 11:29 ` Mike Hearn 1 sibling, 2 replies; 29+ messages in thread From: Brian Hoffman @ 2015-06-15 22:56 UTC (permalink / raw) To: Faiz Khan; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3291 bytes --] Who is actually planning to move to Bitcoin-XT if this happens? Just Gavin and Mike? > On Jun 15, 2015, at 6:17 PM, Faiz Khan <faizkhan00@gmail•com> wrote: > > I'm quite puzzled by the response myself, it doesn't seem to address some of the (more serious) concerns that Adam put out, the most important question that was asked being the one regarding personal ownership of the proposed fork: > > "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?" > > I do genuinely hope that whomever (now and future) wishes to fork the protocol reconsider first whether they are truly ready to test/flex their reputation/skills/resources in this way... Intuitively, to me it seems counterproductive, and I don't fully believe it is within a single developer's talents to manage the process start-to-finish (as it is non-trivial to hard-fork successfully, others have rehashed this in other threads)... > > That being said I think it appropriate if Adam's questions were responded in-line when Mike is feeling up to it. I think that the answers are important for the community to hear when such a drastic change is being espoused. > > Faiz > >> On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop <kanzure@gmail•com> wrote: >>> On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn <mike@plan99•net> wrote: >>> Re: anyone who agrees with noted non-programmers Mike&Gavin must be non-technical, stupid, uninformed, etc .... OK, go ahead and show them the error of their ways. Anyone can write blogs. >> >> I worry that if this is the level of care you take with reading and (mis)interpreting Adam's messages, that you might not be taking extreme care with evaluating consensus changes, even while tired or sleeping. I encourage you to evaluate both messages and source code more carefully, especially in the world of bitcoin. However, this goes for everyone and not just you. Specifically, when Adam mentioned your conversations with non-technical people, he did not mean "Mike has talked with people who have possibly not made pull requests to Bitcoin Core, so therefore Mike is a non-programmer". Communication is difficult and I can understand that, but we really have to be more careful when evaluating each other's messages; technical miscommunication can be catastrophic in this context. On the topic of whether you are a programmer, I suspect that ever since you built CIA.vc we have all known you're a programmer, Mike. >> >> - Bryan >> http://heybryan.org/ >> 1 512 203 0507 >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> -- >> >> My regards, >> >> Faiz Khan > > > ------------------------------------------------------------------------------ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development [-- Attachment #2.1: Type: text/html, Size: 5400 bytes --] [-- Attachment #2.2: image1.JPG --] [-- Type: image/jpeg, Size: 22107 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Bitcoin-development] questions about bitcoin-XT code fork &non-consensus hard-fork 2015-06-15 22:56 ` Brian Hoffman @ 2015-06-15 23:05 ` Raystonn . 2015-06-16 0:08 ` [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork Aaron Voisine 1 sibling, 0 replies; 29+ messages in thread From: Raystonn . @ 2015-06-15 23:05 UTC (permalink / raw) To: Brian Hoffman, Faiz Khan; +Cc: Bitcoin Dev [-- Attachment #1.1: Type: text/plain, Size: 3944 bytes --] http://xtnodes.com/ From: Brian Hoffman Sent: Monday, June 15, 2015 3:56 PM To: Faiz Khan Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] questions about bitcoin-XT code fork &non-consensus hard-fork Who is actually planning to move to Bitcoin-XT if this happens? Just Gavin and Mike? On Jun 15, 2015, at 6:17 PM, Faiz Khan <faizkhan00@gmail•com> wrote: I'm quite puzzled by the response myself, it doesn't seem to address some of the (more serious) concerns that Adam put out, the most important question that was asked being the one regarding personal ownership of the proposed fork: "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?" I do genuinely hope that whomever (now and future) wishes to fork the protocol reconsider first whether they are truly ready to test/flex their reputation/skills/resources in this way... Intuitively, to me it seems counterproductive, and I don't fully believe it is within a single developer's talents to manage the process start-to-finish (as it is non-trivial to hard-fork successfully, others have rehashed this in other threads)... That being said I think it appropriate if Adam's questions were responded in-line when Mike is feeling up to it. I think that the answers are important for the community to hear when such a drastic change is being espoused. Faiz On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop <kanzure@gmail•com> wrote: On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn <mike@plan99•net> wrote: Re: anyone who agrees with noted non-programmers Mike&Gavin must be non-technical, stupid, uninformed, etc .... OK, go ahead and show them the error of their ways. Anyone can write blogs. I worry that if this is the level of care you take with reading and (mis)interpreting Adam's messages, that you might not be taking extreme care with evaluating consensus changes, even while tired or sleeping. I encourage you to evaluate both messages and source code more carefully, especially in the world of bitcoin. However, this goes for everyone and not just you. Specifically, when Adam mentioned your conversations with non-technical people, he did not mean "Mike has talked with people who have possibly not made pull requests to Bitcoin Core, so therefore Mike is a non-programmer". Communication is difficult and I can understand that, but we really have to be more careful when evaluating each other's messages; technical miscommunication can be catastrophic in this context. On the topic of whether you are a programmer, I suspect that ever since you built CIA.vc we have all known you're a programmer, Mike. - Bryan http://heybryan.org/ 1 512 203 0507 ------------------------------------------------------------------------------ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists•sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- My regards, Faiz Khan ------------------------------------------------------------------------------ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists•sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -------------------------------------------------------------------------------- ------------------------------------------------------------------------------ -------------------------------------------------------------------------------- _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists•sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development [-- Attachment #1.2: Type: text/html, Size: 7344 bytes --] [-- Attachment #2: image1.JPG --] [-- Type: image/jpeg, Size: 22107 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-15 22:56 ` Brian Hoffman 2015-06-15 23:05 ` [Bitcoin-development] questions about bitcoin-XT code fork &non-consensus hard-fork Raystonn . @ 2015-06-16 0:08 ` Aaron Voisine 2015-06-16 0:41 ` Mark Friedenbach ` (2 more replies) 1 sibling, 3 replies; 29+ messages in thread From: Aaron Voisine @ 2015-06-16 0:08 UTC (permalink / raw) To: Brian Hoffman; +Cc: Bitcoin Dev [-- Attachment #1.1: Type: text/plain, Size: 4743 bytes --] Wasn't the XT hard fork proposed as a last resort, should the bitcoin-core maintainers simply refuse to lift the 1Mb limit? No one wants to go that route. An alternate hard-fork proposal like BIP100 that gets consensus, or a modified version of gavin's that ups the limit to 8Mb instead of 20Mb, or hell even some major changes to the non-consunsus code to make it adequately handle the situation when blocks fill up, and allow wallet software to continue working with a send-and-forget use pattern, any of these would be enough to avoid the need for an XT only hard-fork. So far BIP100 is the only one that seems to actually be getting any sort of momentum toward consensus, and it was proposed... 2 days ago? When the XT fork was proposed as a last resort, it was when the opponents were (to my understanding) suggesting we just let blocks fill up, and hopefully things would just work out on their own. Aaron Voisine co-founder and CEO breadwallet.com On Mon, Jun 15, 2015 at 3:56 PM, Brian Hoffman <brianchoffman@gmail•com> wrote: > Who is actually planning to move to Bitcoin-XT if this happens? > > Just Gavin and Mike? > > [image: image1.JPG] > > On Jun 15, 2015, at 6:17 PM, Faiz Khan <faizkhan00@gmail•com> wrote: > > I'm quite puzzled by the response myself, it doesn't seem to address some > of the (more serious) concerns that Adam put out, the most important > question that was asked being the one regarding personal ownership of the > proposed fork: > > "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?" > > I do genuinely hope that whomever (now and future) wishes to fork the > protocol reconsider first whether they are truly ready to test/flex their > reputation/skills/resources in this way... Intuitively, to me it seems > counterproductive, and I don't fully believe it is within a single > developer's talents to manage the process start-to-finish (as it is > non-trivial to hard-fork successfully, others have rehashed this in other > threads)... > > That being said I think it appropriate if Adam's questions were responded > in-line when Mike is feeling up to it. I think that the answers are > important for the community to hear when such a drastic change is being > espoused. > > Faiz > > On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop <kanzure@gmail•com> wrote: > >> On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn <mike@plan99•net> wrote: >> >>> Re: anyone who agrees with noted non-programmers Mike&Gavin must be >>> non-technical, stupid, uninformed, etc .... OK, go ahead and show them the >>> error of their ways. Anyone can write blogs. >>> >> >> I worry that if this is the level of care you take with reading and >> (mis)interpreting Adam's messages, that you might not be taking extreme >> care with evaluating consensus changes, even while tired or sleeping. I >> encourage you to evaluate both messages and source code more carefully, >> especially in the world of bitcoin. However, this goes for everyone and not >> just you. Specifically, when Adam mentioned your conversations with >> non-technical people, he did not mean "Mike has talked with people who have >> possibly not made pull requests to Bitcoin Core, so therefore Mike is a >> non-programmer". Communication is difficult and I can understand that, but >> we really have to be more careful when evaluating each other's messages; >> technical miscommunication can be catastrophic in this context. On the >> topic of whether you are a programmer, I suspect that ever since you built >> CIA.vc we have all known you're a programmer, Mike. >> >> - Bryan >> http://heybryan.org/ >> 1 512 203 0507 >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> -- >> >> My regards, >> >> Faiz Khan >> >> <https://lists.sourceforge.net/lists/listinfo/bitcoin-development> > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #1.2: Type: text/html, Size: 7432 bytes --] [-- Attachment #2: image1.JPG --] [-- Type: image/jpeg, Size: 22107 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-16 0:08 ` [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork Aaron Voisine @ 2015-06-16 0:41 ` Mark Friedenbach 2015-06-16 1:17 ` Alex Morcos 2015-06-18 15:23 ` Jorge Timón 2 siblings, 0 replies; 29+ messages in thread From: Mark Friedenbach @ 2015-06-16 0:41 UTC (permalink / raw) To: Aaron Voisine; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1085 bytes --] On Mon, Jun 15, 2015 at 5:08 PM, Aaron Voisine <voisine@gmail•com> wrote: > Wasn't the XT hard fork proposed as a last resort, should the bitcoin-core > maintainers simply refuse to lift the 1Mb limit? No one wants to go that > route. An alternate hard-fork proposal like BIP100 that gets consensus, or > a modified version of gavin's that ups the limit to 8Mb instead of 20Mb, or > hell even some major changes to the non-consunsus code to make it > adequately handle the situation when blocks fill up, and allow wallet > software to continue working with a send-and-forget use pattern, any of > these would be enough to avoid the need for an XT only hard-fork. > > So far BIP100 is the only one that seems to actually be getting any sort > of momentum toward consensus, and it was proposed... 2 days ago? When the > XT fork was proposed as a last resort, it was when the opponents were (to > my understanding) suggesting we just let blocks fill up, and hopefully > things would just work out on their own. > We are not reaching consensus about any proposal, Garzik's or otherwise. [-- Attachment #2: Type: text/html, Size: 1417 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-16 0:08 ` [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork Aaron Voisine 2015-06-16 0:41 ` Mark Friedenbach @ 2015-06-16 1:17 ` Alex Morcos 2015-06-16 4:00 ` Aaron Voisine 2015-06-18 15:23 ` Jorge Timón 2 siblings, 1 reply; 29+ messages in thread From: Alex Morcos @ 2015-06-16 1:17 UTC (permalink / raw) To: Aaron Voisine; +Cc: Bitcoin Dev [-- Attachment #1.1: Type: text/plain, Size: 6888 bytes --] Aaron, My understanding is that Gavin and Mike are proceeding with the XT fork, I hope that understanding is wrong. As for improving the non-consensus code to handle full blocks more gracefully. This is something I'm very interested in, block size increase or not. Perhaps I shouldn't hijack this thread, but maybe there are others who also believe this would ameliorate some of the time pressure for deciding on a block size increase. What is it that you would like to see improved? The fee estimation code that is included for 0.11 will give much more accurate fee estimates, which should allow adding the correct fee to a transaction to see it likely to be confirmed in a reasonable time. For further improvements: - There has recently been attention to overhauling the block creation and mempool limiting code in such a way that actual outstanding queues to be included in a block could also be incorporated in fee estimation. See https://github.com/bitcoin/bitcoin/pull/6281. - CPFP and RBF are candidates for inclusion in core soon, both of which could be integrated into transaction processing to handle the edge cases where a priori fee estimation fails. See https://github.com/bitcoin/bitcoin/pull/1647 and https://github.com/bitcoin/bitcoin/pull/6176 I know there has been much discussion of fee estimation not working for SPV clients, but I believe several independent servers which were serving the estimates from full nodes would go a long way towards allowing that information to be used by SPV clients even if its not a completely decentralized solution. See for example http://core2.bitcoincore.org/smartfee/latest.json On Mon, Jun 15, 2015 at 8:08 PM, Aaron Voisine <voisine@gmail•com> wrote: > Wasn't the XT hard fork proposed as a last resort, should the bitcoin-core > maintainers simply refuse to lift the 1Mb limit? No one wants to go that > route. An alternate hard-fork proposal like BIP100 that gets consensus, or > a modified version of gavin's that ups the limit to 8Mb instead of 20Mb, or > hell even some major changes to the non-consunsus code to make it > adequately handle the situation when blocks fill up, and allow wallet > software to continue working with a send-and-forget use pattern, any of > these would be enough to avoid the need for an XT only hard-fork. > > So far BIP100 is the only one that seems to actually be getting any sort > of momentum toward consensus, and it was proposed... 2 days ago? When the > XT fork was proposed as a last resort, it was when the opponents were (to > my understanding) suggesting we just let blocks fill up, and hopefully > things would just work out on their own. > > > > Aaron Voisine > co-founder and CEO > breadwallet.com > > On Mon, Jun 15, 2015 at 3:56 PM, Brian Hoffman <brianchoffman@gmail•com> > wrote: > >> Who is actually planning to move to Bitcoin-XT if this happens? >> >> Just Gavin and Mike? >> >> [image: image1.JPG] >> >> On Jun 15, 2015, at 6:17 PM, Faiz Khan <faizkhan00@gmail•com> wrote: >> >> I'm quite puzzled by the response myself, it doesn't seem to address some >> of the (more serious) concerns that Adam put out, the most important >> question that was asked being the one regarding personal ownership of the >> proposed fork: >> >> "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?" >> >> I do genuinely hope that whomever (now and future) wishes to fork the >> protocol reconsider first whether they are truly ready to test/flex their >> reputation/skills/resources in this way... Intuitively, to me it seems >> counterproductive, and I don't fully believe it is within a single >> developer's talents to manage the process start-to-finish (as it is >> non-trivial to hard-fork successfully, others have rehashed this in other >> threads)... >> >> That being said I think it appropriate if Adam's questions were responded >> in-line when Mike is feeling up to it. I think that the answers are >> important for the community to hear when such a drastic change is being >> espoused. >> >> Faiz >> >> On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop <kanzure@gmail•com> wrote: >> >>> On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn <mike@plan99•net> wrote: >>> >>>> Re: anyone who agrees with noted non-programmers Mike&Gavin must be >>>> non-technical, stupid, uninformed, etc .... OK, go ahead and show them the >>>> error of their ways. Anyone can write blogs. >>>> >>> >>> I worry that if this is the level of care you take with reading and >>> (mis)interpreting Adam's messages, that you might not be taking extreme >>> care with evaluating consensus changes, even while tired or sleeping. I >>> encourage you to evaluate both messages and source code more carefully, >>> especially in the world of bitcoin. However, this goes for everyone and not >>> just you. Specifically, when Adam mentioned your conversations with >>> non-technical people, he did not mean "Mike has talked with people who have >>> possibly not made pull requests to Bitcoin Core, so therefore Mike is a >>> non-programmer". Communication is difficult and I can understand that, but >>> we really have to be more careful when evaluating each other's messages; >>> technical miscommunication can be catastrophic in this context. On the >>> topic of whether you are a programmer, I suspect that ever since you built >>> CIA.vc we have all known you're a programmer, Mike. >>> >>> - Bryan >>> http://heybryan.org/ >>> 1 512 203 0507 >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Bitcoin-development mailing list >>> Bitcoin-development@lists•sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >>> >>> -- >>> >>> My regards, >>> >>> Faiz Khan >>> >>> <https://lists.sourceforge.net/lists/listinfo/bitcoin-development> >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #1.2: Type: text/html, Size: 10469 bytes --] [-- Attachment #2: image1.JPG --] [-- Type: image/jpeg, Size: 22107 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-16 1:17 ` Alex Morcos @ 2015-06-16 4:00 ` Aaron Voisine 2015-06-17 3:54 ` Peter Todd 0 siblings, 1 reply; 29+ messages in thread From: Aaron Voisine @ 2015-06-16 4:00 UTC (permalink / raw) To: Alex Morcos; +Cc: Bitcoin Dev [-- Attachment #1.1: Type: text/plain, Size: 9655 bytes --] Thanks Alex, the work you've pointed out is helpful. Limiting mempool size should at least prevent nodes from crashing. When I looked a few days ago I only found a few old PRs that seemed to have fallen by the wayside, so this new one is encouraging. I can respond in the PR comments if it's more appropriate there, but I believe ejecting tx from mempools rather than preemptively refusing them according to standard network wide propagation rules will result in spotty, inconsistent tx propagation, and possibly a large increase in tx re-broadcasts, so if those haven't been addressed they will need to be. It would also be prudent to run some simulations to see what other issues are going to pop-up. We're currently using CPFP already in breadwallet when spending unconfirmed non-change inputs. A small percentage of hashing power is using it, but enough to get a transaction unstuck assuming breadwallet's fee calculation is better than the sender's. The problem with RBF is that there's currently no way to tell if your tx has been picked up by miners or not in order to know if you need to replace it. Miners broadcasting partial block solutions would be helpful in this regard, but only for tx in the currently-being-worked-on block, not for tx that won't be picked up until the block after. If miners were to eject tx that were previously being worked on in favor of higher fee tx, then that causes another set of problems for wallets that thought their tx was going to get in but then it doesn't. The other problem with RBF is that users don't know up front what fee they're actually going to pay which is a big blow to real world usability. Also mobile wallets will have to sign lots of tx up front and rely on a service to replace as necessary. And this is all just on the send side. On the receive side it's much worse since you can't rely on the sender to do the replacing. The real problem seems to be the fact that RBF is an interactive iterative process rather than a send-and-forget one. What you really need is some way to tell up-front, is a transaction going to get mined with a high probability? That problem seems really difficult to solve with fixed-size blocks that are full. If the goal is simply to reduce or limit the growth of the blockchain, then there are much simpler solutions, which is why I've advocated for the blocksize increase, followed by tx selection and propagation rule changes to create fee pressure. Aaron Voisine co-founder and CEO breadwallet.com On Mon, Jun 15, 2015 at 6:17 PM, Alex Morcos <morcos@gmail•com> wrote: > Aaron, > > My understanding is that Gavin and Mike are proceeding with the XT fork, I > hope that understanding is wrong. > > As for improving the non-consensus code to handle full blocks more > gracefully. This is something I'm very interested in, block size increase > or not. Perhaps I shouldn't hijack this thread, but maybe there are others > who also believe this would ameliorate some of the time pressure for > deciding on a block size increase. > > What is it that you would like to see improved? > The fee estimation code that is included for 0.11 will give much more > accurate fee estimates, which should allow adding the correct fee to a > transaction to see it likely to be confirmed in a reasonable time. For > further improvements: > - There has recently been attention to overhauling the block creation and > mempool limiting code in such a way that actual outstanding queues to be > included in a block could also be incorporated in fee estimation. See > https://github.com/bitcoin/bitcoin/pull/6281. > - CPFP and RBF are candidates for inclusion in core soon, both of which > could be integrated into transaction processing to handle the edge cases > where a priori fee estimation fails. See > https://github.com/bitcoin/bitcoin/pull/1647 and > https://github.com/bitcoin/bitcoin/pull/6176 > > I know there has been much discussion of fee estimation not working for > SPV clients, but I believe several independent servers which were serving > the estimates from full nodes would go a long way towards allowing that > information to be used by SPV clients even if its not a completely > decentralized solution. See for example > http://core2.bitcoincore.org/smartfee/latest.json > > > > On Mon, Jun 15, 2015 at 8:08 PM, Aaron Voisine <voisine@gmail•com> wrote: > >> Wasn't the XT hard fork proposed as a last resort, should the >> bitcoin-core maintainers simply refuse to lift the 1Mb limit? No one wants >> to go that route. An alternate hard-fork proposal like BIP100 that gets >> consensus, or a modified version of gavin's that ups the limit to 8Mb >> instead of 20Mb, or hell even some major changes to the non-consunsus code >> to make it adequately handle the situation when blocks fill up, and allow >> wallet software to continue working with a send-and-forget use pattern, any >> of these would be enough to avoid the need for an XT only hard-fork. >> >> So far BIP100 is the only one that seems to actually be getting any sort >> of momentum toward consensus, and it was proposed... 2 days ago? When the >> XT fork was proposed as a last resort, it was when the opponents were (to >> my understanding) suggesting we just let blocks fill up, and hopefully >> things would just work out on their own. >> >> >> >> Aaron Voisine >> co-founder and CEO >> breadwallet.com >> >> On Mon, Jun 15, 2015 at 3:56 PM, Brian Hoffman <brianchoffman@gmail•com> >> wrote: >> >>> Who is actually planning to move to Bitcoin-XT if this happens? >>> >>> Just Gavin and Mike? >>> >>> [image: image1.JPG] >>> >>> On Jun 15, 2015, at 6:17 PM, Faiz Khan <faizkhan00@gmail•com> wrote: >>> >>> I'm quite puzzled by the response myself, it doesn't seem to address >>> some of the (more serious) concerns that Adam put out, the most important >>> question that was asked being the one regarding personal ownership of the >>> proposed fork: >>> >>> "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?" >>> >>> I do genuinely hope that whomever (now and future) wishes to fork the >>> protocol reconsider first whether they are truly ready to test/flex their >>> reputation/skills/resources in this way... Intuitively, to me it seems >>> counterproductive, and I don't fully believe it is within a single >>> developer's talents to manage the process start-to-finish (as it is >>> non-trivial to hard-fork successfully, others have rehashed this in other >>> threads)... >>> >>> That being said I think it appropriate if Adam's questions were >>> responded in-line when Mike is feeling up to it. I think that the answers >>> are important for the community to hear when such a drastic change is being >>> espoused. >>> >>> Faiz >>> >>> On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop <kanzure@gmail•com> wrote: >>> >>>> On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn <mike@plan99•net> wrote: >>>> >>>>> Re: anyone who agrees with noted non-programmers Mike&Gavin must be >>>>> non-technical, stupid, uninformed, etc .... OK, go ahead and show them the >>>>> error of their ways. Anyone can write blogs. >>>>> >>>> >>>> I worry that if this is the level of care you take with reading and >>>> (mis)interpreting Adam's messages, that you might not be taking extreme >>>> care with evaluating consensus changes, even while tired or sleeping. I >>>> encourage you to evaluate both messages and source code more carefully, >>>> especially in the world of bitcoin. However, this goes for everyone and not >>>> just you. Specifically, when Adam mentioned your conversations with >>>> non-technical people, he did not mean "Mike has talked with people who have >>>> possibly not made pull requests to Bitcoin Core, so therefore Mike is a >>>> non-programmer". Communication is difficult and I can understand that, but >>>> we really have to be more careful when evaluating each other's messages; >>>> technical miscommunication can be catastrophic in this context. On the >>>> topic of whether you are a programmer, I suspect that ever since you built >>>> CIA.vc we have all known you're a programmer, Mike. >>>> >>>> - Bryan >>>> http://heybryan.org/ >>>> 1 512 203 0507 >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Bitcoin-development mailing list >>>> Bitcoin-development@lists•sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >>>> >>>> -- >>>> >>>> My regards, >>>> >>>> Faiz Khan >>>> >>>> <https://lists.sourceforge.net/lists/listinfo/bitcoin-development> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Bitcoin-development mailing list >>> Bitcoin-development@lists•sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Bitcoin-development mailing list >>> Bitcoin-development@lists•sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >>> >>> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> > [-- Attachment #1.2: Type: text/html, Size: 13757 bytes --] [-- Attachment #2: image1.JPG --] [-- Type: image/jpeg, Size: 22107 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-16 4:00 ` Aaron Voisine @ 2015-06-17 3:54 ` Peter Todd 0 siblings, 0 replies; 29+ messages in thread From: Peter Todd @ 2015-06-17 3:54 UTC (permalink / raw) To: Aaron Voisine; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 5630 bytes --] On Mon, Jun 15, 2015 at 09:00:19PM -0700, Aaron Voisine wrote: > Thanks Alex, the work you've pointed out is helpful. Limiting mempool size > should at least prevent nodes from crashing. When I looked a few days ago I > only found a few old PRs that seemed to have fallen by the wayside, so this > new one is encouraging. BTW it's worth working out how many $ in fees you need for a given amount of MB worth of mempool. At the current 10uBTC/KB minimim relay fee 1MB of txs requires just $2.5 worth of fees - kinda ridiculous when a block earns a miner $6250 in revenue. Pretty much all txs pay significantly higher rates - more like 100uBTC/KB, or $25/MB. At that rate the 288MB max mempool size proposed by Patrick Strateman's pull-req requires at least $7.2k worth of BTC to fill to pay the fees, and in practice will probably quickly get higher. https://github.com/bitcoin/bitcoin/pull/6281 > I can respond in the PR comments if it's more appropriate there, but I > believe ejecting tx from mempools rather than preemptively refusing them > according to standard network wide propagation rules will result in spotty, > inconsistent tx propagation, and possibly a large increase in tx > re-broadcasts, so if those haven't been addressed they will need to be. It > would also be prudent to run some simulations to see what other issues are > going to pop-up. See above - filling the mempool like that will be both a slow process, and require lots of funds. Equally, once full, the sensible thing to do is raise the minimum relay fee appropriately, so those transactions that pay too low a fee will simply be rejected. It'd be reasonable to tell peers that, and what the minimum fee needed for acceptance would be for that particular node. > We're currently using CPFP already in breadwallet when spending unconfirmed > non-change inputs. A small percentage of hashing power is using it, but > enough to get a transaction unstuck assuming breadwallet's fee calculation > is better than the sender's. > The problem with RBF is that there's currently no way to tell if your tx > has been picked up by miners or not in order to know if you need to replace > it. Miners broadcasting partial block solutions would be helpful in this > regard, but only for tx in the currently-being-worked-on block, not for tx > that won't be picked up until the block after. If miners were to eject tx > that were previously being worked on in favor of higher fee tx, then that > causes another set of problems for wallets that thought their tx was going > to get in but then it doesn't. The other problem with RBF is that users > don't know up front what fee they're actually going to pay which is a big > blow to real world usability. Also mobile wallets will have to sign lots of > tx up front and rely on a service to replace as necessary. And this is all > just on the send side. For an interactive, mobile wallet, the best thing to do is estimate the fee correctly the first time, using RBF as a follow up mechanism only if needed. For other users - e.g. exchanges handling customer withdrawals - using RBF more agressively to get the minimum possible fee may make sense. > On the receive side it's much worse since you can't > rely on the sender to do the replacing. The real problem seems to be the > fact that RBF is an interactive iterative process rather than a > send-and-forget one. In any case, the *existance* of RBF makes no difference to any of these problems; RBF does make solving the easier. You can always choose to not use it after all, resulting in the same "send-and-forget" process. Having it available allows mistakes to be fixed after the fact, always an improved user experience over not being able to re-bid for block space. Incidentally, if my FSS-RBF bug bounty isn't collected in the next week or two, we'll likely have a major double-digits % of hashing power mining FSS-RBF soon after. http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08122.html > What you really need is some way to tell up-front, is a transaction going > to get mined with a high probability? That problem seems really difficult > to solve with fixed-size blocks that are full. Have you looked at the fee estimation code in Bitcoin Core? I have no reason to think it doesn't basically speaking work. Of course, SPV wallets will need a semi-trusted third party to securely get that data, but this seems to be a fundemental problem in a decentralized network - the purpose of the blockchain itself is to prove that some data was published to some audience, an analogous problem to proving to the SPV wallet that their transaction actually reached miners and they actually are considering it for inclusion. Guaranteed reliable transaction processing is only possible in centralized environments that can make service guarantees. > If the goal is simply to > reduce or limit the growth of the blockchain, then there are much simpler > solutions, which is why I've advocated for the blocksize increase, followed > by tx selection and propagation rule changes to create fee pressure. Few if any of those mechanisms can be deployed in a consensus-critical way that is resistant to attack; the blocksize limit is needed to - among other things - resist attacks by one miner on another to reduce the competitors profitability. Without an explicit limit tx selection and propagation rule changes can be gamed. -- 'peter'[:-1]@petertodd.org 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-16 0:08 ` [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork Aaron Voisine 2015-06-16 0:41 ` Mark Friedenbach 2015-06-16 1:17 ` Alex Morcos @ 2015-06-18 15:23 ` Jorge Timón 2 siblings, 0 replies; 29+ messages in thread From: Jorge Timón @ 2015-06-18 15:23 UTC (permalink / raw) To: Aaron Voisine; +Cc: Bitcoin Dev [-- Attachment #1.1: Type: text/plain, Size: 6898 bytes --] On Tue, Jun 16, 2015 at 2:08 AM, Aaron Voisine <voisine@gmail•com> wrote: > > hell even some major changes to the non-consunsus code to make it adequately handle the situation when blocks fill up This will have to eventually be done in addition to any other "alternative" unless the plan is to keep rising the limit until it is removed or irrelevant. Maybe this should be the priority? Maybe this is the "alternative" that some no-block-size-limit proponents (meaning people who think that centralization is not a concern when deciding the block size limit) claim nobody was putting forward? Anyway, it's sad that we're always mixing 2 different topics: hardfork deployment and blocksize limit. I wish we talked more about the former, I wish we would have talked about it it long before the block size debate became "urgent" (or at least before it was being perceived as urgent). We've had plenty of time to deploy non-emergency hardforks but apparently no one was interested (say, for fixing miner but known bugs like the timetravel attack). In fact, I plan to eventually propose such a fork, I agree with gavin that "hardforks aren't possible" is not an answer, though finding opposition to a concrete hardfork in a concrete point in time doesn't mean that "hardforks aren't possible". I believe I have proposed many more hardforks than Gavin, all of them rejected and I still hope some of them will eventually make it into bitcoin main. When it was clear that wouldn't be the case I'm afraid the only answer is creating an altcoin (like Mark and I did with Freicoin and "xtcoin" could become [hopefully not destroying bitcoin main in the process]). On Tue, Jun 16, 2015 at 2:08 AM, Aaron Voisine <voisine@gmail•com> wrote: > Wasn't the XT hard fork proposed as a last resort, should the bitcoin-core > maintainers simply refuse to lift the 1Mb limit? No one wants to go that > route. An alternate hard-fork proposal like BIP100 that gets consensus, or > a modified version of gavin's that ups the limit to 8Mb instead of 20Mb, or > hell even some major changes to the non-consunsus code to make it > adequately handle the situation when blocks fill up, and allow wallet > software to continue working with a send-and-forget use pattern, any of > these would be enough to avoid the need for an XT only hard-fork. > > So far BIP100 is the only one that seems to actually be getting any sort > of momentum toward consensus, and it was proposed... 2 days ago? When the > XT fork was proposed as a last resort, it was when the opponents were (to > my understanding) suggesting we just let blocks fill up, and hopefully > things would just work out on their own. > > > > Aaron Voisine > co-founder and CEO > breadwallet.com > > On Mon, Jun 15, 2015 at 3:56 PM, Brian Hoffman <brianchoffman@gmail•com> > wrote: > >> Who is actually planning to move to Bitcoin-XT if this happens? >> >> Just Gavin and Mike? >> >> [image: image1.JPG] >> >> On Jun 15, 2015, at 6:17 PM, Faiz Khan <faizkhan00@gmail•com> wrote: >> >> I'm quite puzzled by the response myself, it doesn't seem to address some >> of the (more serious) concerns that Adam put out, the most important >> question that was asked being the one regarding personal ownership of the >> proposed fork: >> >> "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?" >> >> I do genuinely hope that whomever (now and future) wishes to fork the >> protocol reconsider first whether they are truly ready to test/flex their >> reputation/skills/resources in this way... Intuitively, to me it seems >> counterproductive, and I don't fully believe it is within a single >> developer's talents to manage the process start-to-finish (as it is >> non-trivial to hard-fork successfully, others have rehashed this in other >> threads)... >> >> That being said I think it appropriate if Adam's questions were responded >> in-line when Mike is feeling up to it. I think that the answers are >> important for the community to hear when such a drastic change is being >> espoused. >> >> Faiz >> >> On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop <kanzure@gmail•com> wrote: >> >>> On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn <mike@plan99•net> wrote: >>> >>>> Re: anyone who agrees with noted non-programmers Mike&Gavin must be >>>> non-technical, stupid, uninformed, etc .... OK, go ahead and show them the >>>> error of their ways. Anyone can write blogs. >>>> >>> >>> I worry that if this is the level of care you take with reading and >>> (mis)interpreting Adam's messages, that you might not be taking extreme >>> care with evaluating consensus changes, even while tired or sleeping. I >>> encourage you to evaluate both messages and source code more carefully, >>> especially in the world of bitcoin. However, this goes for everyone and not >>> just you. Specifically, when Adam mentioned your conversations with >>> non-technical people, he did not mean "Mike has talked with people who have >>> possibly not made pull requests to Bitcoin Core, so therefore Mike is a >>> non-programmer". Communication is difficult and I can understand that, but >>> we really have to be more careful when evaluating each other's messages; >>> technical miscommunication can be catastrophic in this context. On the >>> topic of whether you are a programmer, I suspect that ever since you built >>> CIA.vc we have all known you're a programmer, Mike. >>> >>> - Bryan >>> http://heybryan.org/ >>> 1 512 203 0507 >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Bitcoin-development mailing list >>> Bitcoin-development@lists•sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >>> >>> -- >>> >>> My regards, >>> >>> Faiz Khan >>> >>> <https://lists.sourceforge.net/lists/listinfo/bitcoin-development> >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #1.2: Type: text/html, Size: 10246 bytes --] [-- Attachment #2: image1.JPG --] [-- Type: image/jpeg, Size: 22107 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-15 22:17 ` Faiz Khan 2015-06-15 22:56 ` Brian Hoffman @ 2015-06-16 11:29 ` Mike Hearn 1 sibling, 0 replies; 29+ messages in thread From: Mike Hearn @ 2015-06-16 11:29 UTC (permalink / raw) To: Faiz Khan; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2188 bytes --] > > "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?" > How do we plan to deal with security & incident response - exactly the same way as before. Remember that XT is basically Core plus a few patches. Gavin and myself are both on the bitcoin-security mailing list and have been for years. Both of us have experience of responding to very serious and tight-deadline security incidents, for example, the accidental bdb hard fork and (in my case) when we discovered that Android phones had so little entropy in them that different devices were actually generating the same keys! That one required co-ordinated crash rollouts of multiple wallets across the Bitcoin ecosystem because there was a parallel investigation into key collisions taking place in an open forum and they were not far from discovering the truth about how badly the Android RNG was broken (I knew because at the time I had access to the Google internal Android bug tracker). I organised the whole thing. So I think we'll manage. But I don't expect things to exist in a state of disjointness for very long. XT will rebase on top of Core and follow it's releases for as long as there seems to be interest in bigger blocks and as long as I have the time/energy/interest. If the >1mb chain wins then Core will have to adopt the new ruleset or simply stop being relevant, as it will have no users. That wouldn't make much sense. Now, there have been concerns raised that a hard fork is unbelievably risky, the sky will fall, the value of Bitcoin will drop to zero, etc. I don't believe it's anywhere near that risky. The patch Gavin is working on requires both a miner majority *and* also has a date trigger in it. Much like previous forks, in fact. So nobody should be taken by surprise if/when bigger blocks appear, because it will have been known for a long time beforehand that there was sufficiently strong consensus, there will have been messages printed to the node logs, announcements in various places and so on. Does that help clear things up? [-- Attachment #2: Type: text/html, Size: 2631 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-15 21:56 ` Bryan Bishop 2015-06-15 22:17 ` Faiz Khan @ 2015-06-16 11:20 ` Mike Hearn 1 sibling, 0 replies; 29+ messages in thread From: Mike Hearn @ 2015-06-16 11:20 UTC (permalink / raw) To: Bryan Bishop; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1486 bytes --] Hi Bryan, Specifically, when Adam mentioned your conversations with non-technical > people, he did not mean "Mike has talked with people who have possibly not > made pull requests to Bitcoin Core, so therefore Mike is a non-programmer". > Yes, my comment was prickly and grumpy. No surprises, I did not sleep well last night. I am upset about this constant insistence from Adam, Gregory and others that the "technical community" or "technical majority" agree with them and anyone who doesn't is "non technical" or "not a contributor" or not an expert or not had things properly explained to them. This is not true and needs to stop. Gavin and I have both been working on Bitcoin in substantial ways for longer than Gregory and Adam have been in the community at all. We are extremely technical, as are many of the people who want us to release XT+larger blocks. We cannot make progress in any kind of negotiation if one side constantly blows off the other and refuses to take anything they say seriously, which has been a feature of this "debate" from the start. In contrast Gavin and I have written vast amounts of analysis on the concerns raised by larger blocks. So many hours were spent, we could probably fill a small book by now. We have carefully read and addressed *dozens* of points raised by the 1mb camp. We have also done our best to open this debate to the whole community. So it would be nice if the people who are so keen on 1mb blocks show the same respect to us. [-- Attachment #2: Type: text/html, Size: 1959 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-15 18:03 ` Adam Back 2015-06-15 20:55 ` Mike Hearn @ 2015-06-16 12:33 ` Pindar Wong 2015-06-16 13:33 ` Peter Todd 1 sibling, 1 reply; 29+ messages in thread From: Pindar Wong @ 2015-06-16 12:33 UTC (permalink / raw) To: Adam Back; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 26818 bytes --] On Tue, Jun 16, 2015 at 2:03 AM, Adam Back <adam@cypherspace•org> wrote: > 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? > > Dear Adam, All: At the community's convenience, it would be an honour to arrange an initial open summit to meet with representatives of the Chinese miners in Hong Kong (UTC+8) to facilitate a better understand between the different stakeholders of the Bitcoin ecosystem on this important issue. This could be arranged for this October, or earlier, if deemed necessary. Remote online participation would be welcome from those who might not be able to attend in person. However, it is hoped that such a meeting would be primarily document driven to facilitate orderly translation, discussion and decision. p. > (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: > > I will review both and mostly delegate to Gavin's good taste around the > > details, unless there is some very strong disagreement. But that seems > > unlikely. > > ... > > Feedback will be read. There are no NACKS in Bitcoin XT. Patch requests > > aren't scored in any way. The final decision rests with the maintainer > as in > > ~all open source projects. > > 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. > > >> - 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. > > > > If Bitcoin runs out of capacity it will break and many of our users will > > leave. That is not an acceptable outcome for myself or the many other > > wallet, service and merchant developers who have worked for years to > build > > an ecosystem around this protocol. > > 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? > > > If Bitcoin runs out of capacity it will break and many of our users will > > leave. That is not an acceptable outcome for myself or the many other > > wallet, service and merchant developers who have worked for years to > build > > an ecosystem around this protocol. > > 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 > > >> - 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. > > > > The approach is the same for other forks. Voting via block versions and > then > > when there's been >X% for Y time units the 1mb limit is lifted/replaced. > > 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. > > >> - Do you have contingency plans for what to do if the non-consensus > >> hard-fork goes wrong and $3B is lost as a result? > > > > Where did you get the $3B figure from? The fork either doesn't happen, > or it > > happens after quite a long period of people knowing it's going to happen > - > > for example because their full node is printing "You need to upgrade" > > messages due to seeing the larger block version, or because they read the > > news, or because they heard about it via some other mechanisms. > > 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 > > > Let me flip the question around. Do you have a contingency plan if > Bitcoin > > runs out of capacity and significant user disruption occurs that results > in > > exodus, followed by fall in BTC price? The only one I've seen is "we can > > perform an emergency hard fork in a few weeks"! > > 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. > > >> As you can probably tell I think a unilateral fork without wide-scale > >> consensus from the technical and business communities is a deeply > >> inadvisable. > > > > Gavin and I have been polling many key players in the ecosystem. The > > consensus you seek does exist. All wallet developers (except Lawrence), > all > > the major exchanges, all the major payment processors and many of the > major > > mining pools want to see the limit lifted (I haven't been talking to > pools, > > Gavin has). > > 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. > > > This notion that the change has no consensus is based on you polling the > > people directly around you and people who like to spend all day on this > > mailing list. It's not an accurate reflection of the wider Bitcoin > community > > and that is one of the leading reasons there is going to be a fork. A > small > > number of people have been flatly ignoring LOTS of highly technical and > > passionate developers who have written vast amounts of code, built up the > > Bitcoin user base, designed hardware and software, and yes built > companies. > > 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. > > > the overwhelming impression I get from a few > > others here is that no, they don't want to scale Bitcoin. They already > > decided it's a technological dead end. > > 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 > [-- Attachment #2: Type: text/html, Size: 30069 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-16 12:33 ` Pindar Wong @ 2015-06-16 13:33 ` Peter Todd 2015-06-16 13:55 ` Pindar Wong 0 siblings, 1 reply; 29+ messages in thread From: Peter Todd @ 2015-06-16 13:33 UTC (permalink / raw) To: Pindar Wong; +Cc: Constance Choi, Bitcoin Dev, Primavera De Filippi [-- Attachment #1: Type: text/plain, Size: 2275 bytes --] On Tue, Jun 16, 2015 at 08:33:31PM +0800, Pindar Wong wrote: > On Tue, Jun 16, 2015 at 2:03 AM, Adam Back <adam@cypherspace•org> wrote: > Dear Adam, All: > > At the community's convenience, it would be an honour to arrange an initial > open summit to meet with representatives of the Chinese miners in Hong Kong > (UTC+8) to facilitate a better understand between the different > stakeholders of the Bitcoin ecosystem on this important issue. This could > be arranged for this October, or earlier, if deemed necessary. Great! FWIW there Constance Choi and Primavera De Filippi (CC'd) are holding a blockchain-tech conference October 14th-15th in Hong Kong as well; coordinating your summit with that conference could be useful. http://blockchainworkshops.org/ This workshop series has been attracting audiences of people looking to use blockchain tech in general; many of these use-cases will likely involve the Bitcoin blockchain in unpredictable ways. Importantly, these ways can drive demand significantly beyond our current assumptions based on most demand being consumer-merchant transactions. In addition, many of the attendees have significant experience with regulatory issues and interacting with governments on regulation of blockchain tech. Bitcoin faces existential risks to its existence by these regulation efforts, which include things like efforts to setup industry wide Anti-Money-Laundering/Know-Your-Customer programs, including programs that would tie on-chain transactions to identity information. Any blocksize discussion needs to be informed by these potential threats to usage of the technology, as well as challenges to using scaling solutions. > Remote online participation would be welcome from those who might not be > able to attend in person. > > However, it is hoped that such a meeting would be primarily document > driven to facilitate orderly translation, discussion and decision. Agreed. Pieter Wuille's recent work is a great example of the kind of science-driven investigations that need to be done - and haven't been done very much - to get us some hard data to make decisions on. -- 'peter'[:-1]@petertodd.org 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-16 13:33 ` Peter Todd @ 2015-06-16 13:55 ` Pindar Wong 2015-06-17 3:59 ` Peter Todd 0 siblings, 1 reply; 29+ messages in thread From: Pindar Wong @ 2015-06-16 13:55 UTC (permalink / raw) To: Peter Todd; +Cc: Constance Choi, Bitcoin Dev, Primavera De Filippi [-- Attachment #1: Type: text/plain, Size: 2720 bytes --] On Tue, Jun 16, 2015 at 9:33 PM, Peter Todd <pete@petertodd•org> wrote: > On Tue, Jun 16, 2015 at 08:33:31PM +0800, Pindar Wong wrote: > > On Tue, Jun 16, 2015 at 2:03 AM, Adam Back <adam@cypherspace•org> wrote: > > Dear Adam, All: > > > > At the community's convenience, it would be an honour to arrange an > initial > > open summit to meet with representatives of the Chinese miners in Hong > Kong > > (UTC+8) to facilitate a better understand between the different > > stakeholders of the Bitcoin ecosystem on this important issue. This > could > > be arranged for this October, or earlier, if deemed necessary. > > Great! > > FWIW there Constance Choi and Primavera De Filippi (CC'd) are holding a > blockchain-tech conference October 14th-15th in Hong Kong as well; > coordinating your summit with that conference could be useful. > > http://blockchainworkshops.org/ > > This workshop series has been attracting audiences of people looking to > use blockchain tech in general; many of these use-cases will likely > involve the Bitcoin blockchain in unpredictable ways. Importantly, these > ways can drive demand significantly beyond our current assumptions based > on most demand being consumer-merchant transactions. > > In addition, many of the attendees have significant experience with > regulatory issues and interacting with governments on regulation of > blockchain tech. Bitcoin faces existential risks to its existence by > these regulation efforts, which include things like efforts to setup > industry wide Anti-Money-Laundering/Know-Your-Customer programs, > including programs that would tie on-chain transactions to identity > information. Any blocksize discussion needs to be informed by these > potential threats to usage of the technology, as well as challenges to > using scaling solutions. > > > Remote online participation would be welcome from those who might not be > > able to attend in person. > > > > However, it is hoped that such a meeting would be primarily document > > driven to facilitate orderly translation, discussion and decision. > > Agreed. Pieter Wuille's recent work is a great example of the kind of > science-driven investigations that need to be done - and haven't been > done very much - to get us some hard data to make decisions on. > Thank you very much Peter for pointing this out! That is very kind of you. It would be great to work with Constance Choi, Primavera De Filippi, your goodself and others to make this happen. As you may know, the Hong Kong Monetary Authority considers bitcoin a virtual 'commodity' and not a currency per se. Regards, p. > > -- > 'peter'[:-1]@petertodd.org > 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 > [-- Attachment #2: Type: text/html, Size: 3759 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-16 13:55 ` Pindar Wong @ 2015-06-17 3:59 ` Peter Todd 2015-06-25 6:43 ` [bitcoin-dev] " Pindar Wong 0 siblings, 1 reply; 29+ messages in thread From: Peter Todd @ 2015-06-17 3:59 UTC (permalink / raw) To: Pindar Wong; +Cc: Constance Choi, Bitcoin Dev, Primavera De Filippi [-- Attachment #1: Type: text/plain, Size: 1323 bytes --] On Tue, Jun 16, 2015 at 09:55:13PM +0800, Pindar Wong wrote: > > Agreed. Pieter Wuille's recent work is a great example of the kind of > > science-driven investigations that need to be done - and haven't been > > done very much - to get us some hard data to make decisions on. > > > > Thank you very much Peter for pointing this out! That is very kind of you. > > It would be great to work with Constance Choi, Primavera De Filippi, your > goodself and others to make this happen. Great! They're excited to see this happen. I'm in London right now actually for the conference they were holding this week; the blocksize issue was being discussed a fair bit there among attendees. (notably, with rather different views than seen on reddit!) > As you may know, the Hong Kong Monetary Authority considers bitcoin a > virtual 'commodity' and not a currency per se. Yup, though keep in mind the regulatory question is more than just how your local jurisdiction views Bitcoin, but rather how your customers' jurisdictions view Bitcoin. Of course, when I say "customers" above, I mean the entire Bitcoin community that is ultimately buying the new coins produced by miners and paying fees to them! -- 'peter'[:-1]@petertodd.org 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-17 3:59 ` Peter Todd @ 2015-06-25 6:43 ` Pindar Wong 2015-06-26 19:30 ` Peter Todd 0 siblings, 1 reply; 29+ messages in thread From: Pindar Wong @ 2015-06-25 6:43 UTC (permalink / raw) To: Peter Todd; +Cc: Constance Choi, Bitcoin Dev, Primavera De Filippi, bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 2209 bytes --] On Wed, Jun 17, 2015 at 11:59 AM, Peter Todd <pete@petertodd•org> wrote: > On Tue, Jun 16, 2015 at 09:55:13PM +0800, Pindar Wong wrote: > > > Agreed. Pieter Wuille's recent work is a great example of the kind of > > > science-driven investigations that need to be done - and haven't been > > > done very much - to get us some hard data to make decisions on. > > > > > > > Thank you very much Peter for pointing this out! That is very kind of > you. > > > > It would be great to work with Constance Choi, Primavera De Filippi, your > > goodself and others to make this happen. > > Great! They're excited to see this happen. I'm in London right now > actually for the conference they were holding this week; the blocksize > issue was being discussed a fair bit there among attendees. (notably, > with rather different views than seen on reddit!) > > > As you may know, the Hong Kong Monetary Authority considers bitcoin a > > virtual 'commodity' and not a currency per se. > > Yup, though keep in mind the regulatory question is more than just how > your local jurisdiction views Bitcoin, but rather how your customers' > jurisdictions view Bitcoin. > > Of course, when I say "customers" above, I mean the entire Bitcoin > community that is ultimately buying the new coins produced by miners and > paying fees to them! > I'm sorry for the distraction with the mailing list problems. Taking an ecosystem view, the miners are important, so are all the other participants who rely on it and invest time, effort and energy to make Bitcoin work and work well. I am in contact with Primavera and it would appear that the Cyberport is available for use on October 14 and 15 (Wed/Thursday). Last November, this was where the Global Bitcoin Summit (Hong Kong) <http://www.cyberport.hk/en/about_cyberport/our_5_centres/collaboration_centre/collaboration_news/2146> was hosted with the participation of many of China's leading Bitcoin-related companies. There is a meeting now in Shanghai. It would be an honour to host a more technical meeting to discuss BIP100, 101 et al. should be interest to do so. p. > > -- > 'peter'[:-1]@petertodd.org > 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 > [-- Attachment #2: Type: text/html, Size: 3136 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-25 6:43 ` [bitcoin-dev] " Pindar Wong @ 2015-06-26 19:30 ` Peter Todd 0 siblings, 0 replies; 29+ messages in thread From: Peter Todd @ 2015-06-26 19:30 UTC (permalink / raw) To: Pindar Wong Cc: Constance Choi, Bitcoin Dev, Primavera De Filippi, bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1689 bytes --] On Thu, Jun 25, 2015 at 02:43:19PM +0800, Pindar Wong wrote: > > Yup, though keep in mind the regulatory question is more than just how > > your local jurisdiction views Bitcoin, but rather how your customers' > > jurisdictions view Bitcoin. > > > > Of course, when I say "customers" above, I mean the entire Bitcoin > > community that is ultimately buying the new coins produced by miners and > > paying fees to them! > > > > I'm sorry for the distraction with the mailing list problems. > > Taking an ecosystem view, the miners are important, so are all the other > participants who rely on it and invest time, effort and energy to make > Bitcoin work and work well. Agreed. IMO any change to the blocksize needs explicit mechanisms to let all Bitcoin holders have a say in it. > I am in contact with Primavera and it would appear that the Cyberport is > available for use on October 14 and 15 (Wed/Thursday). Great! Glad to hear. > Last November, this was where the Global Bitcoin Summit (Hong Kong) > <http://www.cyberport.hk/en/about_cyberport/our_5_centres/collaboration_centre/collaboration_news/2146> > was hosted with the participation of many of China's leading > Bitcoin-related companies. There is a meeting now in Shanghai. > > It would be an honour to host a more technical meeting to discuss BIP100, > 101 et al. should be interest to do so. Are you thinking this more technical meeting should be before or after the October event? Perhaps a better question, is what exactly do you see being discussed at a technical meeting? -- 'peter'[:-1]@petertodd.org 0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-15 9:56 ` Mike Hearn 2015-06-15 18:03 ` Adam Back @ 2015-06-15 22:54 ` odinn 2015-06-16 1:20 ` Eric Lombrozo 2015-06-16 5:18 ` Venzen 2 siblings, 1 reply; 29+ messages in thread From: odinn @ 2015-06-15 22:54 UTC (permalink / raw) To: Mike Hearn, Adam Back; +Cc: Bitcoin Dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mike, To sum it up, you are saying "bitcoin will break and many of our users will leave therefore OMG WTF so we have to do what GAVIN AND ME want to do to hardfork to XT which is the ONLY WAY, so GTFO!" And so, no. We don't have to accept that attitude. There are other proposals that actually would work here. Cameron Garnham's dynamic block size adjustment (needing soft fork only) mentioned here http://www.twitlonger.com/show/n_1smkanp Jeff Garzik's proposals (rewritten and published as a BIP) http://bitcoin-development.narkive.com/f5FMeA4D/comments-on-bip-100 and more. I also disagree with the notion that everybody's just ok with what Mike and Gavin are doing.... specifically, this statement by Mike > The consensus you seek does exist. All wallet developers (except > Lawrence), all the major exchanges, all the major payment > processors and many of the major mining pools want to see the limit > lifted was kind of twisting things, because it made it sound like everybody supports Gavin's proposal to hard fork to XT, which these folks don't. Example: 1) http://cointelegraph.com/news/114481/chinese-exchanges-reject-gavin-andr esens-20-mb-block-size-increase 2) https://twitter.com/GreenAddress/status/605037073725313024 This isn't to say they don't want to see a limit adjusted but not in the way that Gavin (and you, Mike) are proposing - not through this hard fork to XT. So go roll out your code for whatever it is you are going to put into XT and make a BIP, but stop saying that everyone supports it when obviously they don't and you don't even have something yet and there are already superior alternatives that don't involve Gavin's hard fork and your blessed XT. On 06/15/2015 02:56 AM, Mike Hearn wrote: > Hi Adam, > > Provisional answers below! > > - Are you releasing a BIP for that proposal for review? > > > The work splits like this: > > * Gavin is writing the code and I think a BIP as well > > * I will review both and mostly delegate to Gavin's good taste > around the details, unless there is some very strong disagreement. > But that seems unlikely. > > * I have been handling gitian and the patch rebases, the code > signing and so on, so far. I've also been doing some work to setup > the basic infrastructure of the project (website etc). > > > - If the reviewers all say NACK will you take on board their > suggestions? > > > Feedback will be read. There are no NACKS in Bitcoin XT. Patch > requests aren't scored in any way. The final decision rests with > the maintainer as in ~all open source projects. > > > > - 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. > > > Yes, I have been working on an article that explains how we got to > this point from my perspective. It is quite long, but only because > I want it to be readable for people who weren't following the > debate. > > Anyway, I think I've laid out the gist of it over and over again, > but to summarise: > > If Bitcoin runs out of capacity *it will break and many of our > users will leave*. That is not an acceptable outcome for myself or > the many other wallet, service and merchant developers who have > worked for years to build an ecosystem around this protocol. > > > > - 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. > > > The approach is the same for other forks. Voting via block versions > and then when there's been >X% for Y time units the 1mb limit is > lifted/replaced. > > > > > - If you're going it alone as it were, are you proposing that you > will personally maintain bitcoin-XT? Or do you have a plan to > later hand over maintenance to the bitcoin developers? > > > Good question! I have various thoughts on this, but let's wait and > see what happens first. Perhaps the new chain won't get the > majority on it. > > In the event that the >1mb chain does eventually win, I would > expect Core to apply the patch and rejoin the consensus rather than > lose all its users. That would take XT back to being a fairly small > patchset to improve the network protocol. > > > > - Do you have contingency plans for what to do if the > non-consensus hard-fork goes wrong and $3B is lost as a result? > > > Where did you get the $3B figure from? The fork either doesn't > happen, or it happens after quite a long period of people knowing > it's going to happen - for example because their full node is > printing "You need to upgrade" messages due to seeing the larger > block version, or because they read the news, or because they heard > about it via some other mechanisms. > > Let me flip the question around. Do you have a contingency plan if > Bitcoin runs out of capacity and significant user disruption occurs > that results in exodus, followed by fall in BTC price? The only one > I've seen is "we can perform an emergency hard fork in a few > weeks"! > > > > As you can probably tell I think a unilateral fork without > wide-scale consensus from the technical and business communities is > a deeply inadvisable. > > > Gavin and I have been polling many key players in the ecosystem. > The consensus you seek does exist. All wallet developers (except > Lawrence), all the major exchanges, all the major payment > processors and many of the major mining pools want to see the limit > lifted (I haven't been talking to pools, Gavin has). > > This notion that the change has no consensus is based on you > polling the people directly around you and people who like to spend > all day on this mailing list. It's not an accurate reflection of > the wider Bitcoin community and that is one of the leading reasons > there is going to be a fork. A small number of people have been > flatly ignoring LOTS of highly technical and passionate developers > who have written vast amounts of code, built up the Bitcoin user > base, designed hardware and software, and yes built companies. > > How do you think that makes Bitcoin Core look to the rest of the > Bitcoin world? How much confidence does that give people? > > > > Of the overall process, I think you can agree we should not be > making technical decisions with this level of complexity and > consensus risk with financial implications of this magnitude under > duress of haste? > > > This debate will never end until a fork makes it irrelevant. There > is no process for ending it, despite me begging Wladimir to make > one. > > And there is no haste. We have been debating the block size limit > for _years_. We have known it must be lifted for _years_. I kicked > off this current round of debates after realising that Wladimir's > release timeline wouldn't allow a block size limit to be released > before the end of the year. The reason we're talking about it now > and not next year is exactly to ensure there is plenty of time. > > > > > I can sincerely assure you everyone does want to scale bitcoin and > shares your long term objective on that > > > I really wish you were right, and I definitely feel you are one of > the more reasonable ones Adam. But the overwhelming impression I > get from a few others here is that no, they don't want to scale > Bitcoin. They already decided it's a technological dead end. They > want to kick end users out in order to "incentivise" (force) the > creation of some other alternative, claiming that it's still > Bitcoin whilst ignoring basic details ... like the fact that no > existing wallets or services would work. > > Scaling Bitcoin can only be achieved by letting it grow, and > letting people tackle each bottleneck as it arises at the right > times. Not by convincing ourselves that success is failure. > > > > ---------------------------------------------------------------------- - -------- > > > > > _______________________________________________ Bitcoin-development > mailing list Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > - -- http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVf1e3AAoJEGxwq/inSG8C7NwIAIah+HzWKB+aydCgarJB1Tuv 4wK6ffaWP3pzT/D1jNPMoMwL6bp+hi/ixyrV2y9a841Oc/9vgf75ws1l8QH2YtEE TM5cLnRtScXnbaHKAAQZyewURbmGKTUxhNLMIRlVMMq2uHwbUEqRrDaaBGhwC1HO +v3u5zK13H1UMKBuUY7yANWvOamjs17FmwZ6MURYdX8qBFVqMoTorhPHTebDGusS NxDm4uqphW7ylXISOm53v7i3/CPjW63YGB2fyk9J+BqxhOM7yAJSH0Ln/xtu/COa uXudO+SbMco+x+cKrFLf/5ItxR65aOnWvWPKw0o55f96uSabngs/QozDhaU2BJk= =gof9 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-15 22:54 ` odinn @ 2015-06-16 1:20 ` Eric Lombrozo 0 siblings, 0 replies; 29+ messages in thread From: Eric Lombrozo @ 2015-06-16 1:20 UTC (permalink / raw) To: odinn; +Cc: Bitcoin Dev [-- Attachment #1.1: Type: text/plain, Size: 814 bytes --] > On Jun 15, 2015, at 3:54 PM, odinn <odinn.cyberguerrilla@riseup•net> wrote: > > I also disagree with the notion that everybody's just ok with what > Mike and Gavin are doing.... specifically, this statement by Mike > > > The consensus you seek does exist. All wallet developers (except > > Lawrence), all the major exchanges, all the major payment > > processors and many of the major mining pools want to see the limit > > lifted This is certainly twisting words! We all agree that the limit needs to eventually be lifted - but some of us certainly disagree with the means being used to do so by Mike and Gavin. Most news publications keep the discussion rather shallow and like to keep the controversy pretty black and white - some of us have far more nuanced views! - Eric Lombrozo [-- Attachment #1.2: Type: text/html, Size: 5684 bytes --] [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 842 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-15 9:56 ` Mike Hearn 2015-06-15 18:03 ` Adam Back 2015-06-15 22:54 ` odinn @ 2015-06-16 5:18 ` Venzen 2015-06-16 6:09 ` Marcel Jamin 2015-06-16 11:01 ` Tier Nolan 2 siblings, 2 replies; 29+ messages in thread From: Venzen @ 2015-06-16 5:18 UTC (permalink / raw) To: bitcoin-development Mike Hearn, In the light of your responses to Adam Back's questions, below, I feel it is time to speak up because what I now understand, and is implied, is that Mike Hearn and Gavin Andresen have planned and deployed the infrastructure for a Bitcoin hard-fork and intend to action it despite majority opposition. http://xtnodes.com/ I'll try to keep it brief: Mike Hearn, you should cease your activity of a unilateral hard-fork immediately. You are doing untold damage by breaking FOSS governance protocol requiring methodical collaborative work and due process of change implementation by consensus. Your actions are bad for the Bitcoin project and its ideals, disrespectful of your peers and years of their passionate hard work, and dangerous for Bitcoin in the marketplace and bitcoin in peoples' wallets. Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically, you cannot have it. Your hard-fork is tantamount to theft and you and your collaborators will effectively ex-communicate yourselves from this project and community. It appears that you are consciously trying to usurp ownership and maintenance of Bitcoin. As if it is that easy! You clearly do not comprehend the array of risks - especially the unanticipated ones. As the market saying goes: "If you think speculation is easy, it is because you are ignorant about the risks". If you take the risks with Mike&GavCoin, that would be fine, but you are about to take them with community-owned Bitcoin and Other People's Money! You are causing a lot of stress, unnecessarily, and grave concern surrounds your proposed renegade action. You can dissolve the threat: those players to whom you have made promises can be appeased and eventually get most of what they need from this FOSS project. The developers whom you are railroading to get your way, and the way in which you are doing it, is about to cause a schism that will expand outward from this community. You may accuse the community for being antagonistic to you, and therefore uncooperative, but it is plain to see that your bullheaded manner eventually generates antagonism wherever you go. Taking Bitcoin away from this community, in anger, won't solve the problem and will be like killing the goose that lays the golden eggs. If an individual in an objectively agreed-to FOSS-modelled collaborative project has the audacity to threaten his peers and the world with a unilateral hard-fork despite majority objection and a probability distribution that includes terminal risks and unintended consequences, then what would an impartial outsider think? Some of their thoughts would include that the antagonist could be acting in self-interest, or may be a paid actor, or worse, a saboteur. What would they advise? Stop that individual, at once! Bitcoin is a Free and Open Source Software project that serves as flagship for the blockchain. It has a payment network but the key benefits are censorship resistance and trustless decentralization. There is protocol for how change is effected in a FOSS project. For the sake of everything that is good and useful in Bitcoin, reconsider your dangerous plan and its intended and unintended consequences. Put your feet back on the ground, return to the fold and let the collaborative FOSS model, and the skills available here, gradually scale Bitcoin to your (and all our) grand vision. Venzen Khaosan On 06/15/2015 04:56 PM, Mike Hearn wrote: > Hi Adam, > > Provisional answers below! > > - Are you releasing a BIP for that proposal for review? > > > The work splits like this: > > * Gavin is writing the code and I think a BIP as well > > * I will review both and mostly delegate to Gavin's good taste > around the details, unless there is some very strong disagreement. > But that seems unlikely. > > * I have been handling gitian and the patch rebases, the code > signing and so on, so far. I've also been doing some work to setup > the basic infrastructure of the project (website etc). > > > - If the reviewers all say NACK will you take on board their > suggestions? > > > Feedback will be read. There are no NACKS in Bitcoin XT. Patch > requests aren't scored in any way. The final decision rests with > the maintainer as in ~all open source projects. > > > > - 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. > > > Yes, I have been working on an article that explains how we got to > this point from my perspective. It is quite long, but only because > I want it to be readable for people who weren't following the > debate. > > Anyway, I think I've laid out the gist of it over and over again, > but to summarise: > > If Bitcoin runs out of capacity *it will break and many of our > users will leave*. That is not an acceptable outcome for myself or > the many other wallet, service and merchant developers who have > worked for years to build an ecosystem around this protocol. > > > > - 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. > > > The approach is the same for other forks. Voting via block versions > and then when there's been >X% for Y time units the 1mb limit is > lifted/replaced. > > > > > - If you're going it alone as it were, are you proposing that you > will personally maintain bitcoin-XT? Or do you have a plan to > later hand over maintenance to the bitcoin developers? > > > Good question! I have various thoughts on this, but let's wait and > see what happens first. Perhaps the new chain won't get the > majority on it. > > In the event that the >1mb chain does eventually win, I would > expect Core to apply the patch and rejoin the consensus rather than > lose all its users. That would take XT back to being a fairly small > patchset to improve the network protocol. > > > > - Do you have contingency plans for what to do if the > non-consensus hard-fork goes wrong and $3B is lost as a result? > > > Where did you get the $3B figure from? The fork either doesn't > happen, or it happens after quite a long period of people knowing > it's going to happen - for example because their full node is > printing "You need to upgrade" messages due to seeing the larger > block version, or because they read the news, or because they heard > about it via some other mechanisms. > > Let me flip the question around. Do you have a contingency plan if > Bitcoin runs out of capacity and significant user disruption occurs > that results in exodus, followed by fall in BTC price? The only one > I've seen is "we can perform an emergency hard fork in a few > weeks"! > > > > As you can probably tell I think a unilateral fork without > wide-scale consensus from the technical and business communities is > a deeply inadvisable. > > > Gavin and I have been polling many key players in the ecosystem. > The consensus you seek does exist. All wallet developers (except > Lawrence), all the major exchanges, all the major payment > processors and many of the major mining pools want to see the limit > lifted (I haven't been talking to pools, Gavin has). > > This notion that the change has no consensus is based on you > polling the people directly around you and people who like to spend > all day on this mailing list. It's not an accurate reflection of > the wider Bitcoin community and that is one of the leading reasons > there is going to be a fork. A small number of people have been > flatly ignoring LOTS of highly technical and passionate developers > who have written vast amounts of code, built up the Bitcoin user > base, designed hardware and software, and yes built companies. > > How do you think that makes Bitcoin Core look to the rest of the > Bitcoin world? How much confidence does that give people? > > > > Of the overall process, I think you can agree we should not be > making technical decisions with this level of complexity and > consensus risk with financial implications of this magnitude under > duress of haste? > > > This debate will never end until a fork makes it irrelevant. There > is no process for ending it, despite me begging Wladimir to make > one. > > And there is no haste. We have been debating the block size limit > for _years_. We have known it must be lifted for _years_. I kicked > off this current round of debates after realising that Wladimir's > release timeline wouldn't allow a block size limit to be released > before the end of the year. The reason we're talking about it now > and not next year is exactly to ensure there is plenty of time. > > > > > I can sincerely assure you everyone does want to scale bitcoin and > shares your long term objective on that > > > I really wish you were right, and I definitely feel you are one of > the more reasonable ones Adam. But the overwhelming impression I > get from a few others here is that no, they don't want to scale > Bitcoin. They already decided it's a technological dead end. They > want to kick end users out in order to "incentivise" (force) the > creation of some other alternative, claiming that it's still > Bitcoin whilst ignoring basic details ... like the fact that no > existing wallets or services would work. > > Scaling Bitcoin can only be achieved by letting it grow, and > letting people tackle each bottleneck as it arises at the right > times. Not by convincing ourselves that success is failure. > > > > ------------------------------------------------------------------------------ > > > > > _______________________________________________ Bitcoin-development > mailing list Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-16 5:18 ` Venzen @ 2015-06-16 6:09 ` Marcel Jamin 2015-06-16 9:21 ` Benjamin 2015-06-16 11:01 ` Tier Nolan 1 sibling, 1 reply; 29+ messages in thread From: Marcel Jamin @ 2015-06-16 6:09 UTC (permalink / raw) To: venzen; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 11746 bytes --] > Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically, you cannot have it. Neither do you or anyone else. > There is protocol for how change is effected in a FOSS project. And it allows the minority to hold the majority hostage. > If you take the risks with Mike&GavCoin, that would be fine, but you are about to take them with community-owned Bitcoin and Other People's Money! The same can be said about the other camp. BitcoinXT is not going to fork the chain on a specific date no matter what. People will be able to vote via block versions and once a sufficient majority supports the extensions, everyone else will have a grace period to upgrade. Only after that is a very small minority at risk of losing money. That being said, I'd rather see a solution that everyone agrees on. My personal opinion/hope is that Mike and Gavin are just applying pressure where it's needed. But in the end, they can do whatever they want if they have the necessary support. Permissionless innovation is one of bitcoins virtues. In the end, only adoption will decide what bitcoin is and isn't. 2015-06-16 7:18 GMT+02:00 Venzen <venzen@mail•bihthai.net>: > Mike Hearn, > > In the light of your responses to Adam Back's questions, below, I feel > it is time to speak up because what I now understand, and is implied, > is that Mike Hearn and Gavin Andresen have planned and deployed the > infrastructure for a Bitcoin hard-fork and intend to action it despite > majority opposition. http://xtnodes.com/ > > I'll try to keep it brief: > > Mike Hearn, you should cease your activity of a unilateral hard-fork > immediately. You are doing untold damage by breaking FOSS governance > protocol requiring methodical collaborative work and due process of > change implementation by consensus. Your actions are bad for the > Bitcoin project and its ideals, disrespectful of your peers and years > of their passionate hard work, and dangerous for Bitcoin in the > marketplace and bitcoin in peoples' wallets. > > Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically, > you cannot have it. Your hard-fork is tantamount to theft and you and > your collaborators will effectively ex-communicate yourselves from > this project and community. It appears that you are consciously trying > to usurp ownership and maintenance of Bitcoin. As if it is that easy! > You clearly do not comprehend the array of risks - especially the > unanticipated ones. As the market saying goes: "If you think > speculation is easy, it is because you are ignorant about the risks". > If you take the risks with Mike&GavCoin, that would be fine, but you > are about to take them with community-owned Bitcoin and Other People's > Money! > > You are causing a lot of stress, unnecessarily, and grave concern > surrounds your proposed renegade action. You can dissolve the threat: > those players to whom you have made promises can be appeased and > eventually get most of what they need from this FOSS project. The > developers whom you are railroading to get your way, and the way in > which you are doing it, is about to cause a schism that will expand > outward from this community. > > You may accuse the community for being antagonistic to you, and > therefore uncooperative, but it is plain to see that your bullheaded > manner eventually generates antagonism wherever you go. Taking Bitcoin > away from this community, in anger, won't solve the problem and will > be like killing the goose that lays the golden eggs. > > If an individual in an objectively agreed-to FOSS-modelled > collaborative project has the audacity to threaten his peers and the > world with a unilateral hard-fork despite majority objection and a > probability distribution that includes terminal risks and unintended > consequences, then what would an impartial outsider think? Some of > their thoughts would include that the antagonist could be acting in > self-interest, or may be a paid actor, or worse, a saboteur. What > would they advise? Stop that individual, at once! > > Bitcoin is a Free and Open Source Software project that serves as > flagship for the blockchain. It has a payment network but the key > benefits are censorship resistance and trustless decentralization. > There is protocol for how change is effected in a FOSS project. For > the sake of everything that is good and useful in Bitcoin, reconsider > your dangerous plan and its intended and unintended consequences. Put > your feet back on the ground, return to the fold and let the > collaborative FOSS model, and the skills available here, gradually > scale Bitcoin to your (and all our) grand vision. > > Venzen Khaosan > > > On 06/15/2015 04:56 PM, Mike Hearn wrote: > > Hi Adam, > > > > Provisional answers below! > > > > - Are you releasing a BIP for that proposal for review? > > > > > > The work splits like this: > > > > * Gavin is writing the code and I think a BIP as well > > > > * I will review both and mostly delegate to Gavin's good taste > > around the details, unless there is some very strong disagreement. > > But that seems unlikely. > > > > * I have been handling gitian and the patch rebases, the code > > signing and so on, so far. I've also been doing some work to setup > > the basic infrastructure of the project (website etc). > > > > > > - If the reviewers all say NACK will you take on board their > > suggestions? > > > > > > Feedback will be read. There are no NACKS in Bitcoin XT. Patch > > requests aren't scored in any way. The final decision rests with > > the maintainer as in ~all open source projects. > > > > > > > > - 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. > > > > > > Yes, I have been working on an article that explains how we got to > > this point from my perspective. It is quite long, but only because > > I want it to be readable for people who weren't following the > > debate. > > > > Anyway, I think I've laid out the gist of it over and over again, > > but to summarise: > > > > If Bitcoin runs out of capacity *it will break and many of our > > users will leave*. That is not an acceptable outcome for myself or > > the many other wallet, service and merchant developers who have > > worked for years to build an ecosystem around this protocol. > > > > > > > > - 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. > > > > > > The approach is the same for other forks. Voting via block versions > > and then when there's been >X% for Y time units the 1mb limit is > > lifted/replaced. > > > > > > > > > > - If you're going it alone as it were, are you proposing that you > > will personally maintain bitcoin-XT? Or do you have a plan to > > later hand over maintenance to the bitcoin developers? > > > > > > Good question! I have various thoughts on this, but let's wait and > > see what happens first. Perhaps the new chain won't get the > > majority on it. > > > > In the event that the >1mb chain does eventually win, I would > > expect Core to apply the patch and rejoin the consensus rather than > > lose all its users. That would take XT back to being a fairly small > > patchset to improve the network protocol. > > > > > > > > - Do you have contingency plans for what to do if the > > non-consensus hard-fork goes wrong and $3B is lost as a result? > > > > > > Where did you get the $3B figure from? The fork either doesn't > > happen, or it happens after quite a long period of people knowing > > it's going to happen - for example because their full node is > > printing "You need to upgrade" messages due to seeing the larger > > block version, or because they read the news, or because they heard > > about it via some other mechanisms. > > > > Let me flip the question around. Do you have a contingency plan if > > Bitcoin runs out of capacity and significant user disruption occurs > > that results in exodus, followed by fall in BTC price? The only one > > I've seen is "we can perform an emergency hard fork in a few > > weeks"! > > > > > > > > As you can probably tell I think a unilateral fork without > > wide-scale consensus from the technical and business communities is > > a deeply inadvisable. > > > > > > Gavin and I have been polling many key players in the ecosystem. > > The consensus you seek does exist. All wallet developers (except > > Lawrence), all the major exchanges, all the major payment > > processors and many of the major mining pools want to see the limit > > lifted (I haven't been talking to pools, Gavin has). > > > > This notion that the change has no consensus is based on you > > polling the people directly around you and people who like to spend > > all day on this mailing list. It's not an accurate reflection of > > the wider Bitcoin community and that is one of the leading reasons > > there is going to be a fork. A small number of people have been > > flatly ignoring LOTS of highly technical and passionate developers > > who have written vast amounts of code, built up the Bitcoin user > > base, designed hardware and software, and yes built companies. > > > > How do you think that makes Bitcoin Core look to the rest of the > > Bitcoin world? How much confidence does that give people? > > > > > > > > Of the overall process, I think you can agree we should not be > > making technical decisions with this level of complexity and > > consensus risk with financial implications of this magnitude under > > duress of haste? > > > > > > This debate will never end until a fork makes it irrelevant. There > > is no process for ending it, despite me begging Wladimir to make > > one. > > > > And there is no haste. We have been debating the block size limit > > for _years_. We have known it must be lifted for _years_. I kicked > > off this current round of debates after realising that Wladimir's > > release timeline wouldn't allow a block size limit to be released > > before the end of the year. The reason we're talking about it now > > and not next year is exactly to ensure there is plenty of time. > > > > > > > > > > I can sincerely assure you everyone does want to scale bitcoin and > > shares your long term objective on that > > > > > > I really wish you were right, and I definitely feel you are one of > > the more reasonable ones Adam. But the overwhelming impression I > > get from a few others here is that no, they don't want to scale > > Bitcoin. They already decided it's a technological dead end. They > > want to kick end users out in order to "incentivise" (force) the > > creation of some other alternative, claiming that it's still > > Bitcoin whilst ignoring basic details ... like the fact that no > > existing wallets or services would work. > > > > Scaling Bitcoin can only be achieved by letting it grow, and > > letting people tackle each bottleneck as it arises at the right > > times. Not by convincing ourselves that success is failure. > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > _______________________________________________ Bitcoin-development > > mailing list Bitcoin-development@lists•sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 15179 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-16 6:09 ` Marcel Jamin @ 2015-06-16 9:21 ` Benjamin 0 siblings, 0 replies; 29+ messages in thread From: Benjamin @ 2015-06-16 9:21 UTC (permalink / raw) To: Marcel Jamin; +Cc: Bitcoin Dev "And it allows the minority to hold the majority hostage" The Bitcoin protocol has no definitions about developer consensus . The reference to FOSS is quite arbitrary. The alternative of lobbying companies is equally indeterminate and arbitrary. One of the core problem is that you can't poll users about features, and even if one could users are unlikely to be able to make design decisions about the system. Voting is a quite imperfect mechanism. IF there would be a hardfork vote of this kind, at least each party should lay out a longterm plan and proposal. Mike and Gavin don't have any plans to implement new scaling facilities and Lightening is not a coherent proposal. In effect this fork battle would not be part of a BIP process, but a vote on a longterm plan/architecture. On Tue, Jun 16, 2015 at 8:09 AM, Marcel Jamin <marcel@jamin•net> wrote: >> Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically, > you cannot have it. > > Neither do you or anyone else. > >> There is protocol for how change is effected in a FOSS project. > > And it allows the minority to hold the majority hostage. > >> If you take the risks with Mike&GavCoin, that would be fine, but you are >> about to take them with community-owned Bitcoin and Other People's Money! > > The same can be said about the other camp. > > BitcoinXT is not going to fork the chain on a specific date no matter what. > People will be able to vote via block versions and once a sufficient > majority supports the extensions, everyone else will have a grace period to > upgrade. Only after that is a very small minority at risk of losing money. > > That being said, I'd rather see a solution that everyone agrees on. My > personal opinion/hope is that Mike and Gavin are just applying pressure > where it's needed. But in the end, they can do whatever they want if they > have the necessary support. Permissionless innovation is one of bitcoins > virtues. In the end, only adoption will decide what bitcoin is and isn't. > > 2015-06-16 7:18 GMT+02:00 Venzen <venzen@mail•bihthai.net>: >> >> Mike Hearn, >> >> In the light of your responses to Adam Back's questions, below, I feel >> it is time to speak up because what I now understand, and is implied, >> is that Mike Hearn and Gavin Andresen have planned and deployed the >> infrastructure for a Bitcoin hard-fork and intend to action it despite >> majority opposition. http://xtnodes.com/ >> >> I'll try to keep it brief: >> >> Mike Hearn, you should cease your activity of a unilateral hard-fork >> immediately. You are doing untold damage by breaking FOSS governance >> protocol requiring methodical collaborative work and due process of >> change implementation by consensus. Your actions are bad for the >> Bitcoin project and its ideals, disrespectful of your peers and years >> of their passionate hard work, and dangerous for Bitcoin in the >> marketplace and bitcoin in peoples' wallets. >> >> Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically, >> you cannot have it. Your hard-fork is tantamount to theft and you and >> your collaborators will effectively ex-communicate yourselves from >> this project and community. It appears that you are consciously trying >> to usurp ownership and maintenance of Bitcoin. As if it is that easy! >> You clearly do not comprehend the array of risks - especially the >> unanticipated ones. As the market saying goes: "If you think >> speculation is easy, it is because you are ignorant about the risks". >> If you take the risks with Mike&GavCoin, that would be fine, but you >> are about to take them with community-owned Bitcoin and Other People's >> Money! >> >> You are causing a lot of stress, unnecessarily, and grave concern >> surrounds your proposed renegade action. You can dissolve the threat: >> those players to whom you have made promises can be appeased and >> eventually get most of what they need from this FOSS project. The >> developers whom you are railroading to get your way, and the way in >> which you are doing it, is about to cause a schism that will expand >> outward from this community. >> >> You may accuse the community for being antagonistic to you, and >> therefore uncooperative, but it is plain to see that your bullheaded >> manner eventually generates antagonism wherever you go. Taking Bitcoin >> away from this community, in anger, won't solve the problem and will >> be like killing the goose that lays the golden eggs. >> >> If an individual in an objectively agreed-to FOSS-modelled >> collaborative project has the audacity to threaten his peers and the >> world with a unilateral hard-fork despite majority objection and a >> probability distribution that includes terminal risks and unintended >> consequences, then what would an impartial outsider think? Some of >> their thoughts would include that the antagonist could be acting in >> self-interest, or may be a paid actor, or worse, a saboteur. What >> would they advise? Stop that individual, at once! >> >> Bitcoin is a Free and Open Source Software project that serves as >> flagship for the blockchain. It has a payment network but the key >> benefits are censorship resistance and trustless decentralization. >> There is protocol for how change is effected in a FOSS project. For >> the sake of everything that is good and useful in Bitcoin, reconsider >> your dangerous plan and its intended and unintended consequences. Put >> your feet back on the ground, return to the fold and let the >> collaborative FOSS model, and the skills available here, gradually >> scale Bitcoin to your (and all our) grand vision. >> >> Venzen Khaosan >> >> >> On 06/15/2015 04:56 PM, Mike Hearn wrote: >> > Hi Adam, >> > >> > Provisional answers below! >> > >> > - Are you releasing a BIP for that proposal for review? >> > >> > >> > The work splits like this: >> > >> > * Gavin is writing the code and I think a BIP as well >> > >> > * I will review both and mostly delegate to Gavin's good taste >> > around the details, unless there is some very strong disagreement. >> > But that seems unlikely. >> > >> > * I have been handling gitian and the patch rebases, the code >> > signing and so on, so far. I've also been doing some work to setup >> > the basic infrastructure of the project (website etc). >> > >> > >> > - If the reviewers all say NACK will you take on board their >> > suggestions? >> > >> > >> > Feedback will be read. There are no NACKS in Bitcoin XT. Patch >> > requests aren't scored in any way. The final decision rests with >> > the maintainer as in ~all open source projects. >> > >> > >> > >> > - 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. >> > >> > >> > Yes, I have been working on an article that explains how we got to >> > this point from my perspective. It is quite long, but only because >> > I want it to be readable for people who weren't following the >> > debate. >> > >> > Anyway, I think I've laid out the gist of it over and over again, >> > but to summarise: >> > >> > If Bitcoin runs out of capacity *it will break and many of our >> > users will leave*. That is not an acceptable outcome for myself or >> > the many other wallet, service and merchant developers who have >> > worked for years to build an ecosystem around this protocol. >> > >> > >> > >> > - 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. >> > >> > >> > The approach is the same for other forks. Voting via block versions >> > and then when there's been >X% for Y time units the 1mb limit is >> > lifted/replaced. >> > >> > >> > >> > >> > - If you're going it alone as it were, are you proposing that you >> > will personally maintain bitcoin-XT? Or do you have a plan to >> > later hand over maintenance to the bitcoin developers? >> > >> > >> > Good question! I have various thoughts on this, but let's wait and >> > see what happens first. Perhaps the new chain won't get the >> > majority on it. >> > >> > In the event that the >1mb chain does eventually win, I would >> > expect Core to apply the patch and rejoin the consensus rather than >> > lose all its users. That would take XT back to being a fairly small >> > patchset to improve the network protocol. >> > >> > >> > >> > - Do you have contingency plans for what to do if the >> > non-consensus hard-fork goes wrong and $3B is lost as a result? >> > >> > >> > Where did you get the $3B figure from? The fork either doesn't >> > happen, or it happens after quite a long period of people knowing >> > it's going to happen - for example because their full node is >> > printing "You need to upgrade" messages due to seeing the larger >> > block version, or because they read the news, or because they heard >> > about it via some other mechanisms. >> > >> > Let me flip the question around. Do you have a contingency plan if >> > Bitcoin runs out of capacity and significant user disruption occurs >> > that results in exodus, followed by fall in BTC price? The only one >> > I've seen is "we can perform an emergency hard fork in a few >> > weeks"! >> > >> > >> > >> > As you can probably tell I think a unilateral fork without >> > wide-scale consensus from the technical and business communities is >> > a deeply inadvisable. >> > >> > >> > Gavin and I have been polling many key players in the ecosystem. >> > The consensus you seek does exist. All wallet developers (except >> > Lawrence), all the major exchanges, all the major payment >> > processors and many of the major mining pools want to see the limit >> > lifted (I haven't been talking to pools, Gavin has). >> > >> > This notion that the change has no consensus is based on you >> > polling the people directly around you and people who like to spend >> > all day on this mailing list. It's not an accurate reflection of >> > the wider Bitcoin community and that is one of the leading reasons >> > there is going to be a fork. A small number of people have been >> > flatly ignoring LOTS of highly technical and passionate developers >> > who have written vast amounts of code, built up the Bitcoin user >> > base, designed hardware and software, and yes built companies. >> > >> > How do you think that makes Bitcoin Core look to the rest of the >> > Bitcoin world? How much confidence does that give people? >> > >> > >> > >> > Of the overall process, I think you can agree we should not be >> > making technical decisions with this level of complexity and >> > consensus risk with financial implications of this magnitude under >> > duress of haste? >> > >> > >> > This debate will never end until a fork makes it irrelevant. There >> > is no process for ending it, despite me begging Wladimir to make >> > one. >> > >> > And there is no haste. We have been debating the block size limit >> > for _years_. We have known it must be lifted for _years_. I kicked >> > off this current round of debates after realising that Wladimir's >> > release timeline wouldn't allow a block size limit to be released >> > before the end of the year. The reason we're talking about it now >> > and not next year is exactly to ensure there is plenty of time. >> > >> > >> > >> > >> > I can sincerely assure you everyone does want to scale bitcoin and >> > shares your long term objective on that >> > >> > >> > I really wish you were right, and I definitely feel you are one of >> > the more reasonable ones Adam. But the overwhelming impression I >> > get from a few others here is that no, they don't want to scale >> > Bitcoin. They already decided it's a technological dead end. They >> > want to kick end users out in order to "incentivise" (force) the >> > creation of some other alternative, claiming that it's still >> > Bitcoin whilst ignoring basic details ... like the fact that no >> > existing wallets or services would work. >> > >> > Scaling Bitcoin can only be achieved by letting it grow, and >> > letting people tackle each bottleneck as it arises at the right >> > times. Not by convincing ourselves that success is failure. >> > >> > >> > >> > >> > ------------------------------------------------------------------------------ >> > >> > >> > >> > >> > _______________________________________________ Bitcoin-development >> > mailing list Bitcoin-development@lists•sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-16 5:18 ` Venzen 2015-06-16 6:09 ` Marcel Jamin @ 2015-06-16 11:01 ` Tier Nolan 1 sibling, 0 replies; 29+ messages in thread From: Tier Nolan @ 2015-06-16 11:01 UTC (permalink / raw) Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3798 bytes --] On Tue, Jun 16, 2015 at 6:18 AM, Venzen <venzen@mail•bihthai.net> wrote: > Mike Hearn, you should cease your activity of a unilateral hard-fork > immediately. You are doing untold damage by breaking FOSS governance > protocol requiring methodical collaborative work and due process of > change implementation by consensus. The main principle of open source software is that anyone can fork the code if they wish. They don't do it very often, but they can. This means that if a project dies, someone can take it over. If some of the devs want to take things in a different direction, they can. Users can decide which version they prefer. The software itself is what is valuable. In the case of bitcoin, the blockchain is also (very) valuable. Simply splitting into two projects is not possible for bitcoin. Otherwise, the discussion would have ended already, those who want a larger block would simply create a fork of the software and create an alt chain. The fundamental problem is that there is no clear way to make this decision once and for all. An agreed set of rules for a hard fork would be a nice thing to have, but it is hard to have rules about how to change fundamental rules. I think using the soft fork rules (maybe with a higher threshold than 95%) plus a delay is a reasonable compromise on hard fork rules. Even then, it would be nice to include users of the software too. Peter Todd's suggestion of encoding a vote in transactions is a step in that direction (YES transactions in YES blocks and NO transactions in NO blocks). > Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically, > you cannot have it. Nobody owns it, so there is no court of final appeal. If miners vote >95% for the fork, users could still refuse to accept the change. Maybe the sequence could be version 3 blocks means no opinion version 4 blocks means NO to fork version 5 blocks means YES to fork & YES transactions version 6 blocks means YES to fork & NO transactions Transaction matching rule: version 1, 2, 3 transactions means no opinion (can be in any block) version 4 transactions means YES to fork (cannot be in version 6 blocks) version 5 transactions means NO to fork (cannot be in version 5 blocks) Rules 0) if 750 of the last 1000 blocks are version 5 or 6 blocks, tx matching rule activates for version 5 & 6 blocks 1) if 950 of the last 1000 blocks are version 5 or 6 blocks, then version 4 blocks are rejected 2) if 750 of the last 1000 blocks are version 4 blocks, then version 5 & 6 blocks are rejected 3) if 750 of the last 1000 blocks are version 5 transactions and 950 of the last 1000 are version 5 or 6, then the fork is accepted 4) 25,000 blocks after 3 is accepted, hard fork actually takes effect Once miner acceptance is achieved, then only version 5 and 6 blocks are allowed. The split between version 5 and 6 blocks should be roughly in proportion to the number of transactions of each kind produced. 75% of miners can kill the fork by producing version 4 blocks, but 95% is needed for acceptance. Even then, transaction volume needs to support the fork. I think 75% is reasonable here. (95% of miners and 75% of merchants/users is a pretty strong majority). > You may accuse the community for being antagonistic to you, and > therefore uncooperative, but it is plain to see that your bullheaded > manner eventually generates antagonism wherever you go. Taking Bitcoin > away from this community, in anger, won't solve the problem and will > be like killing the goose that lays the golden eggs. > They are still suggesting some kind of fork threshold process (or at least that is what is being suggested) If their system requires 95% miner approval, they aren't taking unilateral action. Miners are though if they vote in favour. [-- Attachment #2: Type: text/html, Size: 5034 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 2015-06-15 0:04 [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork Adam Back 2015-06-15 9:56 ` Mike Hearn @ 2015-06-17 3:52 ` Troy Benjegerdes 1 sibling, 0 replies; 29+ messages in thread From: Troy Benjegerdes @ 2015-06-17 3:52 UTC (permalink / raw) To: Adam Back; +Cc: Bitcoin Dev > - 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. This is a non-issue. If the hard-fork is not a consensus, then those of us that don't consent ignore the fool that tried to hard-fork. If a fool attempting a non-consensus hard-fork actually breaks something, then you have a fragile system that needs some serious re-thinking. I think a non-consensus hard-fork would be the best thing that could happen to the bitcoin ecosystem long-term, because it would force some re-examination of some very bad assumptions. -- ---------------------------------------------------------------------------- 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2015-06-26 19:30 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-06-15 0:04 [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork Adam Back 2015-06-15 9:56 ` Mike Hearn 2015-06-15 18:03 ` Adam Back 2015-06-15 20:55 ` Mike Hearn 2015-06-15 21:56 ` Bryan Bishop 2015-06-15 22:17 ` Faiz Khan 2015-06-15 22:56 ` Brian Hoffman 2015-06-15 23:05 ` [Bitcoin-development] questions about bitcoin-XT code fork &non-consensus hard-fork Raystonn . 2015-06-16 0:08 ` [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork Aaron Voisine 2015-06-16 0:41 ` Mark Friedenbach 2015-06-16 1:17 ` Alex Morcos 2015-06-16 4:00 ` Aaron Voisine 2015-06-17 3:54 ` Peter Todd 2015-06-18 15:23 ` Jorge Timón 2015-06-16 11:29 ` Mike Hearn 2015-06-16 11:20 ` Mike Hearn 2015-06-16 12:33 ` Pindar Wong 2015-06-16 13:33 ` Peter Todd 2015-06-16 13:55 ` Pindar Wong 2015-06-17 3:59 ` Peter Todd 2015-06-25 6:43 ` [bitcoin-dev] " Pindar Wong 2015-06-26 19:30 ` Peter Todd 2015-06-15 22:54 ` odinn 2015-06-16 1:20 ` Eric Lombrozo 2015-06-16 5:18 ` Venzen 2015-06-16 6:09 ` Marcel Jamin 2015-06-16 9:21 ` Benjamin 2015-06-16 11:01 ` Tier Nolan 2015-06-17 3:52 ` Troy Benjegerdes
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
![[-- Attachment #2.2: image1.JPG --] [-- Type: image/jpeg, Size: 22107 bytes --]](../../9834E283-727C-47F7-A3D0-667951727E5F@gmail.com/2.2-image1.JPG){kind=link}
![[-- Attachment #2: image1.JPG --] [-- Type: image/jpeg, Size: 22107 bytes --]](../../COL131-DS234578F08A63967768C107CDB80@phx.gbl/2-image1.JPG){kind=link}
![[-- Attachment #2: image1.JPG --] [-- Type: image/jpeg, Size: 22107 bytes --]](../../CACq0ZD5TTJ=dvz+o-ex6vUWAnOtMfD=VE7JaZWXYM1Lo2L_9wA@mail.gmail.com/2-image1.JPG){kind=link}
![[-- Attachment #2: image1.JPG --] [-- Type: image/jpeg, Size: 22107 bytes --]](../../CAPWm=eWTnVCoRCGSycUGsYjx8M3NFdqEXAU1ykm08_FdJQCP5Q@mail.gmail.com/2-image1.JPG){kind=link}
![[-- Attachment #2: image1.JPG --] [-- Type: image/jpeg, Size: 22107 bytes --]](../../CACq0ZD6M5Rv_iaB8=7_XgG-QX21CvxCf_Wm5ciRALgRYPt=eYw@mail.gmail.com/2-image1.JPG){kind=link}
![[-- Attachment #2: image1.JPG --] [-- Type: image/jpeg, Size: 22107 bytes --]](../../CABm2gDocK9RgTtbcO8WE62=9uaEKMVmRz4QCB-dTD1E2ZymmDQ@mail.gmail.com/2-image1.JPG){kind=link}