Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork
On Tue, Jun 16, 2015 at 2:03 AM, Adam Back a...@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
Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork
On Tue, Jun 16, 2015 at 08:33:31PM +0800, Pindar Wong wrote: On Tue, Jun 16, 2015 at 2:03 AM, Adam Back a...@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 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork
On Tue, Jun 16, 2015 at 9:33 PM, Peter Todd p...@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 a...@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 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork
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. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-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? 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? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork
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 vois...@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 brianchoff...@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 faizkha...@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 kanz...@gmail.com wrote: On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn m...@plan99.net wrote: Re: anyone who agrees with noted non-programmers MikeGavin 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
Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork
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 mor...@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 vois...@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
Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork
On Jun 15, 2015, at 3:54 PM, odinn odinn.cyberguerri...@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 signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork
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 m...@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
Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork
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 kanz...@gmail.com wrote: On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn m...@plan99.net wrote: Re: anyone who agrees with noted non-programmers MikeGavin 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
Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork
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 faizkha...@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 kanz...@gmail.com wrote: On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn m...@plan99.net wrote: Re: anyone who agrees with noted non-programmers MikeGavin 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 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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 faizkha...@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 kanz...@gmail.com wrote: On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn m...@plan99.net wrote: Re: anyone who agrees with noted non-programmers MikeGavin 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
Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork
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 brianchoff...@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 faizkha...@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 kanz...@gmail.com wrote: On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn m...@plan99.net wrote: Re: anyone who agrees with noted non-programmers MikeGavin 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
