[Bitcoin-development] Video summarizations of blocksize issues?
On Thu, Jun 18, 2015 at 4:54 AM, odinn odinn.cyberguerri...@riseup.net wrote: Recently I saw the following video: https://www.youtube.com/watch?v=8JmvkyQyD8wt=47m58s For those loosely following the technical issues from outside development circles, but who may be pressed into a voting/adoption type position (miners, users, investors)... is there a parallel presentation of the concepts and arguments from the other side (both, or the various, sides) that they can refer to? Someplace where they are collated and presented? A wiki perhaps? Are these even valid or necessary questions? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
And allegations that the project is run like wikipedia or an edit war are verifyably untrue. Check the commit history. This was a reference to a post by Gregory on Reddit where he said if Gavin were to do a pull request for the block size change and then merge it, he would revert it. And I fully believe he would do so! -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
If you think it's not clear enough, which may explain why you did not even attempt to follow it for your block size increase, feel free to make improvements. As the outcome of a block size BIP would be a code change to Bitcoin Core, I cannot make improvements, only ask for them. Which is what I'm doing. I agree that BIP 1 is not clear enough. Gavin is writing a BIP to accompany his patch, because BIPs are best when they describe working code, and BIP 1 *is* at least clear about that. Otherwise it can turn out during implementation that something was different to what was anticipated. I'm sure you agree with this. So a BIP is coming. However, BIP 1 also says this: Vetting an idea publicly before going as far as writing a BIP is meant to save the potential author time and BIP authors are responsible for collecting community feedback on a BIP before submitting it for review OK. Gavin has been vetting the idea publicly and collecting community feedback. Note that the entire Bitcoin community is not on this list, so he published a series of blog posts to get wider feedback, and then was criticised for not doing it all here instead. But anyway - so far, so good. The procedure is being followed. What happens once a BIP is written? The process says: For a BIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly. Once a BIP has been accepted, the reference implementation must be completed. This is where the problem starts. The BIP process you refer to *does not state how acceptance will happen*. It merely sets out a few minimum requirements like making some sort of sense, having code. It's also full of extremely vague descriptions like must represent a net improvement. Improvement according to who? That's left unexplained. And then it says what happens once a BIP is accepted. The middle bit is missing. When there is disagreement over a consensus BIP, how are decisions made? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Thu, Jun 18, 2015 at 5:00 AM, Mike Hearn m...@plan99.net wrote: Dude, calm down. Well hold on, his concerns are real and he seems perfectly calm to me and others apparently. and Gavin already said long ago he wouldn't just commit something, even though he has the ability to do so. Nobody is worried about Gavin or anyone else making commits to git repositories. You'll notice that this wasn't even mentioned in the original email you were replying to. Instead, the email was talking about commit access, which is a property of GitHub's repositories. So why did I say it? Because it's consistent with what I've always said: (That's not a good reason.) you cannot run a codebase like Wikipedia Wikipedia is a top-down centralized authority-based hierarchy. That's pretty close to what you're proposing. That's what everyone else is disagreeing with. You seem to have switched your position mid-flight...? This is not a radical position. That's how nearly all coding projects work. I have been involved with open source for 15 years and the 'single maintainer who makes decisions' model is normal, even if in some large codebases subsystems have delegated submaintainers. There are a number of reasons why that perspective is broken; throughout our conversations others have repeatedly reminded you (such as in -wizards) that forking an open-source repository is not at all like a hard-fork of the blockchain. Anyone can be glorious leader of any repository they want, that's how open-source works. However, it's critical that bitcoin users are never convinced to trust BDFLs or anything else that can be compromised. Should all bitcoin users suddenly start using software with BDFLs, even multiple implementations with separate BDFLs, then those users can be trivially compromised through their trust in those individuals and projects. The alternative is that every developer and every user is personally responsible for self-validation of the rules, checking for correctness and validity. Happy coincidence that this seems to match the strategy of operating the bitcoin network itself, which is to run a node that sees everything and validates all the transactions. Anyone is able to find an error in logic or flaw in the system rules, and they should make it known as widely as possible so that others may evaluate the evidence and consider which solutions preserve the important properties of the system. This is not a matter of majorities or minorities; these arguments should be true for anyone independent of who or what they are, or what level of unpopularity they may have. Anything other than this is somewhat radical, and I am confused as to why others have been talking about developer consensus. I suspect that the reason why they have been saying developer consensus is because they are talking about the Bitcoin Core project on GitHub at the moment. But the topic switched to contentious hard-forks already, which is not a topic of repositories but a topic of the blockchain and network; and in the context of contentious hard-forks it is clear why everyone individually must evaluate the rules and decide whether they the software is correct, or whether changes can trivially cause catastrophic broken hard-forks. These lines of reasoning should be true for everyone, and not merely true for one person but not another. Users, companies and developers must be aware of this, even though it's different from their usual expectations of how systems operate and are maintained. And it is important to be careful to not misconstrue this to others because it is entirely possible to unintentionally convince others that traditional and centralized models are safely applicable here. I realise some people think this anti-process leads to better decision making. I disagree. It leads to no decision making, which is not the same thing at all. Well, if you're talking about the recent disputes regarding a certain patch to hard-fork the blockchain, a decision to not include such a patch seems like the very definition of a decision. Gavin and I say - there is a process, and that process is a hard fork of the block chain. I doubt that other bitcoin software maintainers would agree with that sort of toxic reasoning; contentious hard-forks are basically a weapon of war that you can use against any other collaborator on any bitcoin project. Why would anyone want to collaborate on such a hostile project? How would they even trust each other? - 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
Re: [Bitcoin-development] Ninki Wallet view on blocksize debate
Ben, How does your wallet calculate the fee that should be paid to miners? Do they automatically adjust when transactions take a long time to be confirmed? And how does it respond when transactions are not mined successfully, such as when blocks are full? I strongly urge Gavin to withdraw from this standoff and work with the bitcoin core devs via the existing and successful bip process. The BIP process has not resulted in any hard forks, so this is a little different. While I don't like MG's proposed solution of convincing miners and services to switch to Bitcoin-XT, I recognize that it is done out of a sense of urgency. These types of changes take a long time to roll out, and we should start them before it is too late. This whole debate comes down to: what is more risky, a consensus hard fork or letting bitcoin exceed its imposed capacity limits? The former could result in many services not being compatible and even loss of funds. The latter could result in software failures, instability, and inability to transact: essentially, what bitcoin is supposed to be good at. Both are dangerous and could result in a significant loss of public confidence. Something needs to be done, that's for sure. In the short term, I think we need to do one of two things: 1. All miners and wallet developers need to upgrade to support first-safe RBF, to allow for double spending one's own transactions when they lack sufficient fees to merit confirmations. Wallets also need to randomly request transactions from blocks to see what kind of fees are being paid to get confirmations, so that fees can be paid dynamically instead of with hard-coded values. 2. We can implement either Gavin's or Jeff Garzik's proposal to change the consensus parameters around the block size limit. So Ben, if really don't think that going with #2 is the right way to go (even though everyone agrees that we will need to increase the block size limit eventually anyway, why not now?), then I hope you start to work hard on implementing #1 so that your wallet software can handle hitting capacity limits gracefully. Best, Stephen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
So I'm *not* the decider for anything that concerns the behavior of the global consensus, and I cannot be, as I have explained in the previous post. The person who decides if a pull request is accepted is a decider and significantly affects the behavior of the global consensus. The only option for someone who doesn't agree is to hard fork. There is no way around that and you should just accept that fact and move on. Russ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Thu, Jun 18, 2015 at 6:31 AM, Mike Hearn m...@plan99.net wrote: The first issue is how are decisions made in Bitcoin Core? I struggle to explain this to others because I don't understand it myself. Is it a vote of people with commit access? Is it a 100% agreement of core developers and if so, who are these people? Is it whoever reverts the change last? Could I write down in a document a precise description of how decisions are made? No, and that's been a fairly frustrating problem for a long time. There is a quote from United States Supreme Court Justice Potter Stewart to describe his threshold test for obscenity which is relevant here: I know it when I see it. It is hard certainly, and perhaps even impossible to write down a system of rules that is used to resolve every dispute among core developers. But that doesn't mean it isn't obvious to all the participants what is going on. If a contentious change is proposed, and if after sufficient debate there are still members of the technical community with reasoned, comprehensible objections who are not merely being obstinate in the views -- a neutral observer would agree that their concerns have not been met -- then there is a lack of consensus. If there was some sort of formal process however, the system wouldn't work. Rules can be gamed, and if you add rules to a process then that process can be gamed. Instead we all have a reasonable understanding of what technical consensus is, and we all know it when we see it. Where we do not see it, we do not proceed. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 This kind of thing always happens as projects become larger and more diverse. Something that was once a small group turns into a big group of diverse stakeholders. When it gets too big for the informal processes then some people get upset and defensive. Happens all the time but it is not really a good excuse to keep doing things in an inefficient manner. The old ways just don't scale and if you ever worked on massive projects then you know these formal processes work better. So then: make a proposal for a better process, post it to this list. In practice there has been zero interest in improving the BIP process. E.g. the BIP process was adapted from the Python Enhancement Proposals by Amir Taaki (in 2009 or so?). It hasn't really changed since then, apart from some spelling and grammar corrections. It is not specifically adapted to Bitcoin, and doesn't make a distinction between for example, consensus changes and non-consensus changes. So that's up to someone to do. You seem to be enthousiastic about it, so go ahead. Wladimir -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJVgufFAAoJEHSBCwEjRsmmAmYIAI9ndrMoqEuoaP5t+7W42UuH sh5qR7hojCCoZZl1N+rQ63UXcPBO/V4NUkUG97S3qpEFDzuoYSbOX2Eh+TRfK+s+ U+BpLhWteSexJ3N9aiFuR0q5jgesAzLZ9wtq1gCPI/Zu5/fgYBP4AVTiQGdXCZtv m6ZDKCf+aB/fW/59/AiY44NkMDjVQieEVRiT1IPFJULWesOOdtv7UoqIpz0vDa/5 Jplm41j8IpTPioJKSwUi5qzSDrF7O39PC9LMXNRx/0FIuYfwqJpvF0Frc+vtPpjQ llKE7945uMXz3FLSV0Orx26XPal/MuF5AYOPNk6pJfwYw7q91AUvQxVFepBa9vw= =dMO9 -END PGP SIGNATURE- -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
So then: make a proposal for a better process, post it to this list. Alright. Here is a first cut of my proposal. It can be inserted into an amended BIP 1 after What belongs in a successful BIP?. Let me know what you think. The following section applies to BIPs that affect the block chain consensus rules or the peer to peer protocol and thus require changes to Bitcoin Core. Once a draft BIP has been submitted to bitcoin-development for consideration, the Bitcoin Core maintainer will deliver a preliminary yes/no verdict within three weeks. This verdict may be informed by the debate that has taken part in the previous three weeks. If more time is required, the maintainer is required to request an extension from the BIP author, who may then elect to force an immediate decision (risking a no), or choosing to allow more time. The verdict will meet the following criteria: - It will address the latest version of the BIP at the time the verdict is rendered. - In case of a rejection, it will spell out and describe the technical rationale for this decision. Opinions held by other people are not considered technical rationales: if the maintainer agrees with a technical point made during discussion, he must own that opinion for himself. Therefore no BIP will be rejected on grounds of controversy, disagreement, lack of consensus or otherwise. - In case of rejection, the maintainer will provide a clear, specific list of actionable steps the BIP author can take next. For example, a list of what changes would address the technical objections raised. In case the maintainer believes no change could ever make the BIP acceptable, the list must consist of instructions for how to create a patch set and, in the case of changes to the consensus rules, how to initiate a hard fork. A BIP, even once rejected, may live on in the BIPS repository, though its entry in the index may be sorted below others. The BIP author may update the BIP with a summary of any resulting discussion. As such a summary may be inherently contentious in case of a dispute, the authors wording of that summary is final and may not be subject to meta-debate. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
You misunderstand what I am saying. I am not saying I have a specific process that should be followed, I am saying that whatever the process is then it should be formalized or at least written down. That way the stakeholders have something to work with and keeps people on track. Since some people are saying they don't really know what the process is the first step would be to describe the current process. I don't fully understand the current process but I can see it is not formalized and nobody can even give me a clear description of what it is. Once you have it written down then changes/improvements can be proposed. The first baby step was already done by the Foundation in developing that risk study. A NIST guide for developing such a document is at http://csrc.nist.gov/publications/nistpubs/800-30-rev1/sp800_30_r1.pdf. No one person can come up with this and it would take buy in from several different people who have expertise in specific technical areas as well as experts in coming up with test plans. I recently suggested to the people running the MIT lab that they look into developing a program along those lines. Gavin also recently suggested that list of Bitcoin metrics be developed to help resolve the current disputes. I can help develop this process if there is interest. Russ On 6/18/2015 11:46 AM, Wladimir J. van der Laan wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 This kind of thing always happens as projects become larger and more diverse. Something that was once a small group turns into a big group of diverse stakeholders. When it gets too big for the informal processes then some people get upset and defensive. Happens all the time but it is not really a good excuse to keep doing things in an inefficient manner. The old ways just don't scale and if you ever worked on massive projects then you know these formal processes work better. So then: make a proposal for a better process, post it to this list. In practice there has been zero interest in improving the BIP process. E.g. the BIP process was adapted from the Python Enhancement Proposals by Amir Taaki (in 2009 or so?). It hasn't really changed since then, apart from some spelling and grammar corrections. It is not specifically adapted to Bitcoin, and doesn't make a distinction between for example, consensus changes and non-consensus changes. So that's up to someone to do. You seem to be enthousiastic about it, so go ahead. Wladimir -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJVgufFAAoJEHSBCwEjRsmmAmYIAI9ndrMoqEuoaP5t+7W42UuH sh5qR7hojCCoZZl1N+rQ63UXcPBO/V4NUkUG97S3qpEFDzuoYSbOX2Eh+TRfK+s+ U+BpLhWteSexJ3N9aiFuR0q5jgesAzLZ9wtq1gCPI/Zu5/fgYBP4AVTiQGdXCZtv m6ZDKCf+aB/fW/59/AiY44NkMDjVQieEVRiT1IPFJULWesOOdtv7UoqIpz0vDa/5 Jplm41j8IpTPioJKSwUi5qzSDrF7O39PC9LMXNRx/0FIuYfwqJpvF0Frc+vtPpjQ llKE7945uMXz3FLSV0Orx26XPal/MuF5AYOPNk6pJfwYw7q91AUvQxVFepBa9vw= =dMO9 -END PGP SIGNATURE- -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Thu, Jun 18, 2015 at 9:07 AM, justusranv...@riseup.net wrote: On 2015-06-18 14:53, Jeff Garzik wrote: Consensus changes - worded another way - change Bitcoin's Constitution - The Rules that everyone in the system is -forced- to follow, or be ignored by the system. Bitcoin does not and can not function as a set of rules imposed by some people onto other people. This is an engineering list. The quote precisely describes how the bitcoin consensus system functions. Users' choice is largely binary: Follow the rules, or bitcoin software ignores you. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Thu, Jun 18, 2015 at 06:05:58PM +0200, Mike Hearn wrote: Once a draft BIP has been submitted to bitcoin-development for consideration, the Bitcoin Core maintainer will deliver a preliminary yes/no verdict within three weeks. This verdict may be informed by the debate that has taken part in the previous three weeks. If more time is required, the maintainer is required to request an extension from the BIP author, who may then elect to force an immediate decision (risking a no), or choosing to allow more time. Again, for the last time: Bitcoin Core maintainer does not decide about protocol or consensus level changes. This is not a role for me. Find someone else, if you think you need an arbiter. There was an idea about a Bitcoin Standards Body once, but as far as I know that's not actively being worked on. BTW: for more exposure a proposal is better posted as a new thread, not as a deep reply to an existing topic. Wladimir -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015-06-18 16:28, Jeff Garzik wrote: This is an engineering list. The quote precisely describes how the bitcoin consensus system functions. Users' choice is largely binary: Follow the rules, or bitcoin software ignores you. Software engineers should understand that they have a binary choice: produce the software that your customers want, or the world will ignore your software. There is *no inherent value* to Bitcoin's software rules. The only value that is exists is that produced by the individuals who voluntarily choose to run the software. Failing to account for all design requirements is bad engineering. Nobody cares about the design features of a bridge to nowhere. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJVgvoDAAoJECpf2nDq2eYj0h4P/0YaTsS963qpb63zvB6WlIPS 2lhCJ9FtAd3II5Et+5c/cisfJ9YI2OnM0y8nQpyB9NEOeueN1L1sLFcayE5aHASd EgF7F81AhQD2iSIVwQNs2qAzrZNC2/Nx+nBzBDcrgZ6gRiPpQdsNLy2p0OuZdOgX yG4xl6tKADB2kNi6tVPtZqUC300uQHvggtm+pexYilT0ojEbeVHCoDV40MNDZC2h 1kcdTnGU2SHJJqeZN2vChJCOMfhmK4JwKgoz7JRXe/GHkUUJKriE6Kb7SVczii9e 9qfcosbnR3gjATMoHFYuJX/nsUx52Q1LM9eQgvE8Ml+6Mim5bj2KCJFh7YISxSq9 FhDujfZFCRRQLPJCSkEUePxU/LS7lmoTZXYl3Zz1j9zbq4ncpRHpIFy9QX6iIqK6 Dursnge9ELQwB+H6HoosWRzxOZyo+oiGj17OngJvZYcvzrc2wjHbpZfVqSkmZepU SfJZ64O7yjjXjITwhOc4XF2drzvhsjTsHH5BIwdbCn82SoCkJIwXraj7sxIundli LUJBPiAE0csdmsvW/2kkxLsd9JwTw9lJ9Pf8fiqH3itgrkPkO5mf10DPPnay1SNk Wnm1bAJ05WnKXSo0m0SzaFgZkdfFuhWR4fieSzhLpa+s/HHj18NZvJCmCBR6ic9G 0A+51wwSZnAdMIw7lwIb =r4Co -END PGP SIGNATURE- -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On 06/18/2015 06:33 PM, Mark Friedenbach wrote: * Get safe forms of replace-by-fee and child-pays-for-parent finished and in 0.12. * Develop cross-platform libraries for managing micropayment channels, and get wallet authors to adopt * Use fidelity bonds, solvency proofs, and other tricks to minimize the risk of already deployed off-chain solutions as an interim measure until: * Deploy soft-fork changes for truly scalable solutions like Lightning Network. One of my biggest concerns is that these solutions (lightning network in particular) could end up being worse, in terms of decentralization, than would be a bitcoin network using larger blocks. We don't exactly know what the economies of scale are for pay hubs and could very well end up with far fewer hubs than nodes at any conceivable block size. Of course, it could also turn out to be fantastic, but it seems like an enormous gamble to basically force everyone in the ecosystem to collectively spend millions of dollars upgrading to Lightning /and then/ see whether it's actually an improvement in terms of decentralization. To me, a much more sane approach would be to allow people to voluntarily opt in to those other solutions after we've had an opportunity to experiment with them and see how they actually function in practice, but that can't happen if the network runs out of capacity first. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] FYI - Mailing List Move Preparations
Thanks for setting this up, Warren! On Thu, Jun 18, 2015 at 9:57 PM, Warren Togami Jr. wtog...@gmail.com wrote: After discussions in #bitcoin-dev in the past day we decided it would be a bad idea to link the old and new lists in some way during a transition period. We decided we are better off announcing the switchover very soon, and after that point all posts to the old list will be rejected with a message telling them where to find the new list. The proposed switchover will be on Tuesday, June 23rd, 2015. We will know an exact scheduled time for the move probably tomorrow. At the time of the switchover, the old list will reject all messages, archives will be exported and imported into the new list server, then the new list will be opened. https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Please subscribe now and feel free to make test posts. We are testing configuration options to fix some long standing spam filter-related issues. Any posts to the new list prior to the final switchover will be wiped from the archives. If you have opinions on this, please join us in Freenode #bitcoin-dev and talk to warren. Warren Togami -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed
Nice insight Peter, This further confirms the real problem, which doesn't have much to do with blocksize but rather the connectivity of nodes in countries with not-so-friendly internet policies and deceptive connectivity. On Thu, Jun 18, 2015 at 6:00 PM, Tom Harding t...@thinlink.com wrote: On 06/12/2015 06:51 PM, Pieter Wuille wrote: However, it does very clearly show the effects of larger blocks on centralization pressure of the system. On 6/14/2015 10:45 AM, Jonas Nick wrote: This means that your scenario is not the result of a cartel but the result of a long-term network partition. Pieter, to Jonas' point, in your scenario the big miners are all part of the majority partition, so centralization pressure (pressure to merge with a big miner) cannot be separated from pressure to be connected to the majority partition. I ran your simulation with a large (20%) miner in a 20% minority partition, and 16 small (5%) miners in a majority 80% partition, well connected. The starting point was your recent update, which had a more realistic slow link speed of 100 Mbit/s (making all of the effects smaller). To summarize the results across both your run and mine: ** Making small blocks when others are making big ones - BAD ** As above, and fees are enormous - VERY BAD ** Being separated by a slow link from majority hash power - BAD ** Being a small miner with blocksize=20MB - *NOT BAD* Configuration: * Miner group 0: 20.00% hashrate, blocksize 2000.00 * Miner group 1: 80.00% hashrate, blocksize 100.00 * Expected average block size: 480.00 * Average fee per block: 0.25 * Fee per byte: 0.000521 Result: * Miner group 0: 20.404704% income (factor 1.020235 with hashrate) * Miner group 1: 79.595296% income (factor 0.994941 with hashrate) Configuration: * Miner group 0: 20.00% hashrate, blocksize 2000.00 * Miner group 1: 80.00% hashrate, blocksize 2000.00 * Expected average block size: 2000.00 * Average fee per block: 0.25 * Fee per byte: 0.000125 Result: * Miner group 0: 19.864232% income (factor 0.993212 with hashrate) * Miner group 1: 80.135768% income (factor 1.001697 with hashrate) Configuration: * Miner group 0: 20.00% hashrate, blocksize 2000.00 * Miner group 1: 80.00% hashrate, blocksize 100.00 * Expected average block size: 480.00 * Average fee per block: 25.00 * Fee per byte: 0.052083 Result: * Miner group 0: 51.316895% income (factor 2.565845 with hashrate) * Miner group 1: 48.683105% income (factor 0.608539 with hashrate) Configuration: * Miner group 0: 20.00% hashrate, blocksize 2000.00 * Miner group 1: 80.00% hashrate, blocksize 2000.00 * Expected average block size: 2000.00 * Average fee per block: 25.00 * Fee per byte: 0.012500 Result: * Miner group 0: 19.865943% income (factor 0.993297 with hashrate) * Miner group 1: 80.134057% income (factor 1.001676 with hashrate) -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- *Yifu Guo* *Life is an everlasting self-improvement.* -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] FYI - Mailing List Move Preparations
After discussions in #bitcoin-dev in the past day we decided it would be a bad idea to link the old and new lists in some way during a transition period. We decided we are better off announcing the switchover very soon, and after that point all posts to the old list will be rejected with a message telling them where to find the new list. The proposed switchover will be on Tuesday, June 23rd, 2015. We will know an exact scheduled time for the move probably tomorrow. At the time of the switchover, the old list will reject all messages, archives will be exported and imported into the new list server, then the new list will be opened. https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Please subscribe now and feel free to make test posts. We are testing configuration options to fix some long standing spam filter-related issues. Any posts to the new list prior to the final switchover will be wiped from the archives. If you have opinions on this, please join us in Freenode #bitcoin-dev and talk to warren. Warren Togami -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] FYI - Mailing List Move Preparations
BTW, if you are posting from a less popular mail server your initial post to the new list may be delayed by 5+ minutes due to greylisting. If your sending SMTP server is behaving properly then posts after the first should go through without delay. Warren On Thu, Jun 18, 2015 at 6:57 PM, Warren Togami Jr. wtog...@gmail.com wrote: After discussions in #bitcoin-dev in the past day we decided it would be a bad idea to link the old and new lists in some way during a transition period. We decided we are better off announcing the switchover very soon, and after that point all posts to the old list will be rejected with a message telling them where to find the new list. The proposed switchover will be on Tuesday, June 23rd, 2015. We will know an exact scheduled time for the move probably tomorrow. At the time of the switchover, the old list will reject all messages, archives will be exported and imported into the new list server, then the new list will be opened. https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Please subscribe now and feel free to make test posts. We are testing configuration options to fix some long standing spam filter-related issues. Any posts to the new list prior to the final switchover will be wiped from the archives. If you have opinions on this, please join us in Freenode #bitcoin-dev and talk to warren. Warren Togami -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On 18 June 2015 at 12:00, Mike Hearn m...@plan99.net wrote: Dude, calm down. I don't have commit access to Bitcoin Core and Gavin already said long ago he wouldn't just commit something, even though he has the ability to do so. So why did I say it? Because it's consistent with what I've always said: you cannot run a codebase like Wikipedia. Maintainers have to take part in debates, and then make a decision, and anyone else who was delegated commit access for robustness or convenience must then respect that decision. It's the only way to keep a project making progress at a reasonable pace. This is not a radical position. That's how nearly all coding projects work. I have been involved with open source for 15 years and the 'single maintainer who makes decisions' model is normal, even if in some large codebases subsystems have delegated submaintainers. This is also how all my own projects are run. Bitcoinj has multiple people with commit access. Regardless, if there were to be some design dispute or whatever, I wouldn't tolerate the others with commit access starting some kind of Wiki-style edit war in the code if they disagreed. Nor would I ever expect to get my own way in other people's projects by threatening to revert the maintainers changes. Core is in the weird position where there's no decision making ability at all, because anyone who shows up and shouts enough can generate 'controversy', then Wladimir sees there is disagreement and won't touch the issue in question. So it just runs and runs and *anyone* with commit access can then block any change. I realise some people think this anti-process leads to better decision making. I disagree. It leads to no decision making, which is not the same thing at all. Bicoin is not like other projects. There are large financial stakes involved. I was at a standards convention once and the head of standards at a large company joked to me: We know there are 6 people in the standards world that we can never buy. So we just buy everyone else. You have to luck out in a huge way to get a person like that running your project. Linux has done. Id say bitcoin has been lucky there too. But have a look at other projects, have a look at the alts, the *last* thing you want is a dictator in may cases. Ultimately bitcoin is a ledger based on consensus. There are 3 branches, the miners, the protocol and the market. They all play a role in regulating bitcoin and generally on the conservative side (which I think is a good thing). Whatever your view on the 20MB change, it's not a *conservative* approach, which is the approach that has served bitcoin very well so far. So bitcoin is not like other open source projects, and that's probably quite a good thing. -- ___ 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] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
Not that I know how to do this, but would you be willing to attempt some other method of measuring just how much of a super-majority we have before deploying code? Maybe that information would be helpful for everyone. Obviously such a poll couldn't be perfect, but maybe better than the information we have now. A) I don't believe we should consider changing the 1 MB limit now B) I conceptually believe in increasing block size, but would like to follow a more conservative process and wait to see if a stronger technical consensus on a plan to do so can develop. C) I'd like to go along with Gavin and Mike's 8MB proposal (maybe we wait til this is fully specified, but again not deployed) Perhaps there can even be 4 polls: Miners can vote in coinbases Known corporate entities can announce their vote Does the Bitcoin Foundation infrastructure still exist to represent some authenticated (I think) set of individuals A reddit poll I don't even know if I think this is a good idea, but just trying to find a way to move forward where more of us are on the same page. On Thu, Jun 18, 2015 at 2:23 PM, Gavin Andresen gavinandre...@gmail.com wrote: On Thu, Jun 18, 2015 at 1:42 PM, Alex Morcos mor...@gmail.com wrote: Let me take a pass at explaining how I see this. 1) Code changes to Bitcoin Core that don't change consensus: Wladimir is the decider but he works under a process that is well understood by developers on the project in which he takes under reasonable consideration other technical opinions and prefers to have clear agreement among them. Yes. 2) Changes to the consensus rules: As others have said, this isn't anyone's decision for anyone else. Yes. It's up to each individual user as to what code they run and what rules they enforce. So then why is everyone so up in arms about what Mike and Gavin are proposing if everyone is free to decide for themselves? I believe that each individual user should adhere to the principle that there should be no changes to the consensus rules unless there is near complete agreement among the entire community, users, developers, businesses miners etc. It is not necessary to define complete agreement exactly because every individual person decides for themselves. I believe that this is what gives Bitcoin, or really any money, its value and what makes it work, that we all agree on exactly what it is. So I believe that it is misleading and bad for Bitcoin to tell users and business that you can just choose without concern for everyone else which code you'll run and we'll see which one wins out. No. You should run the old consensus rules (on any codebase you want) until you believe that pretty much everyone has consented to a change in the rules. It is your choice, but I think a lot of people that have spent time thinking about the philosophy of consensus systems believe that when the users of the system have this principle in mind, it's what will make the system work best. I don't think I agree with pretty much everybody, because status-quo bias is a very powerful thing. Any change that disrupts the way they've been doing things will generate significant resistance -- there will be 10 or 20% of any population that will take a position of too busy to think about this, everything seems to be working great, I don't like change, NO to any change. For example, I think some of the resistance for bigger blocks is coming from contributors who are worried they, personally, won't be able to keep up with a bigger blockchain. They might not be able to run full nodes from their home network connections (or might not be able to run a full node AND stream Game of Thrones), on their old raspberry pi machines. The criteria for me is clear super-majority of the people and businesses who are using Bitcoin the most, and I think that criteria is met. 3) Code changes to Core that do change consensus: I think that Wladimir, all the other committers besides Gavin, and almost all of the other developers on Core would defer to #2 above and wait for its outcome to be clear before considering such a code change. Yes, that's the way it has mostly been working. But even before stepping down as Lead I was starting to wonder if there are ANY successful open source projects that didn't have either a Benevolent Dictator or some clear voting process to resolve disputes that cannot be settled with rough consensus. -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
2) Changes to the consensus rules: As others have said, this isn't anyone's decision for anyone else. It's up to each individual user as to what code they run and what rules they enforce. So then why is everyone so up in arms about what Mike and Gavin are proposing if everyone is free to decide for themselves? Because the notion that people are free to decide for themselves is just a rough approximation of the real world situation. If your software does not agree with merchants and exchanges you can't pay your bills and if Bitcoin splits the exchange rate could plummet and damage the ecosystem. People are free to decide within the constraints of the Bitcoin system. Russ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
Let me take a pass at explaining how I see this. 1) Code changes to Bitcoin Core that don't change consensus: Wladimir is the decider but he works under a process that is well understood by developers on the project in which he takes under reasonable consideration other technical opinions and prefers to have clear agreement among them. 2) Changes to the consensus rules: As others have said, this isn't anyone's decision for anyone else. It's up to each individual user as to what code they run and what rules they enforce. So then why is everyone so up in arms about what Mike and Gavin are proposing if everyone is free to decide for themselves? I believe that each individual user should adhere to the principle that there should be no changes to the consensus rules unless there is near complete agreement among the entire community, users, developers, businesses miners etc. It is not necessary to define complete agreement exactly because every individual person decides for themselves. I believe that this is what gives Bitcoin, or really any money, its value and what makes it work, that we all agree on exactly what it is. So I believe that it is misleading and bad for Bitcoin to tell users and business that you can just choose without concern for everyone else which code you'll run and we'll see which one wins out. No. You should run the old consensus rules (on any codebase you want) until you believe that pretty much everyone has consented to a change in the rules. It is your choice, but I think a lot of people that have spent time thinking about the philosophy of consensus systems believe that when the users of the system have this principle in mind, it's what will make the system work best. 3) Code changes to Core that do change consensus: I think that Wladimir, all the other committers besides Gavin, and almost all of the other developers on Core would defer to #2 above and wait for its outcome to be clear before considering such a code change. I'm sure my description of point 2 is not the most eloquent or clear, but maybe someone else can try to elucidate this principle if they've grasped what I'm trying to say. On Thu, Jun 18, 2015 at 1:04 PM, justusranv...@riseup.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015-06-18 16:28, Jeff Garzik wrote: This is an engineering list. The quote precisely describes how the bitcoin consensus system functions. Users' choice is largely binary: Follow the rules, or bitcoin software ignores you. Software engineers should understand that they have a binary choice: produce the software that your customers want, or the world will ignore your software. There is *no inherent value* to Bitcoin's software rules. The only value that is exists is that produced by the individuals who voluntarily choose to run the software. Failing to account for all design requirements is bad engineering. Nobody cares about the design features of a bridge to nowhere. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJVgvoDAAoJECpf2nDq2eYj0h4P/0YaTsS963qpb63zvB6WlIPS 2lhCJ9FtAd3II5Et+5c/cisfJ9YI2OnM0y8nQpyB9NEOeueN1L1sLFcayE5aHASd EgF7F81AhQD2iSIVwQNs2qAzrZNC2/Nx+nBzBDcrgZ6gRiPpQdsNLy2p0OuZdOgX yG4xl6tKADB2kNi6tVPtZqUC300uQHvggtm+pexYilT0ojEbeVHCoDV40MNDZC2h 1kcdTnGU2SHJJqeZN2vChJCOMfhmK4JwKgoz7JRXe/GHkUUJKriE6Kb7SVczii9e 9qfcosbnR3gjATMoHFYuJX/nsUx52Q1LM9eQgvE8Ml+6Mim5bj2KCJFh7YISxSq9 FhDujfZFCRRQLPJCSkEUePxU/LS7lmoTZXYl3Zz1j9zbq4ncpRHpIFy9QX6iIqK6 Dursnge9ELQwB+H6HoosWRzxOZyo+oiGj17OngJvZYcvzrc2wjHbpZfVqSkmZepU SfJZ64O7yjjXjITwhOc4XF2drzvhsjTsHH5BIwdbCn82SoCkJIwXraj7sxIundli LUJBPiAE0csdmsvW/2kkxLsd9JwTw9lJ9Pf8fiqH3itgrkPkO5mf10DPPnay1SNk Wnm1bAJ05WnKXSo0m0SzaFgZkdfFuhWR4fieSzhLpa+s/HHj18NZvJCmCBR6ic9G 0A+51wwSZnAdMIw7lwIb =r4Co -END PGP SIGNATURE- -- ___ 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] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Thu, Jun 18, 2015 at 1:42 PM, Alex Morcos mor...@gmail.com wrote: Let me take a pass at explaining how I see this. 1) Code changes to Bitcoin Core that don't change consensus: Wladimir is the decider but he works under a process that is well understood by developers on the project in which he takes under reasonable consideration other technical opinions and prefers to have clear agreement among them. Yes. 2) Changes to the consensus rules: As others have said, this isn't anyone's decision for anyone else. Yes. It's up to each individual user as to what code they run and what rules they enforce. So then why is everyone so up in arms about what Mike and Gavin are proposing if everyone is free to decide for themselves? I believe that each individual user should adhere to the principle that there should be no changes to the consensus rules unless there is near complete agreement among the entire community, users, developers, businesses miners etc. It is not necessary to define complete agreement exactly because every individual person decides for themselves. I believe that this is what gives Bitcoin, or really any money, its value and what makes it work, that we all agree on exactly what it is. So I believe that it is misleading and bad for Bitcoin to tell users and business that you can just choose without concern for everyone else which code you'll run and we'll see which one wins out. No. You should run the old consensus rules (on any codebase you want) until you believe that pretty much everyone has consented to a change in the rules. It is your choice, but I think a lot of people that have spent time thinking about the philosophy of consensus systems believe that when the users of the system have this principle in mind, it's what will make the system work best. I don't think I agree with pretty much everybody, because status-quo bias is a very powerful thing. Any change that disrupts the way they've been doing things will generate significant resistance -- there will be 10 or 20% of any population that will take a position of too busy to think about this, everything seems to be working great, I don't like change, NO to any change. For example, I think some of the resistance for bigger blocks is coming from contributors who are worried they, personally, won't be able to keep up with a bigger blockchain. They might not be able to run full nodes from their home network connections (or might not be able to run a full node AND stream Game of Thrones), on their old raspberry pi machines. The criteria for me is clear super-majority of the people and businesses who are using Bitcoin the most, and I think that criteria is met. 3) Code changes to Core that do change consensus: I think that Wladimir, all the other committers besides Gavin, and almost all of the other developers on Core would defer to #2 above and wait for its outcome to be clear before considering such a code change. Yes, that's the way it has mostly been working. But even before stepping down as Lead I was starting to wonder if there are ANY successful open source projects that didn't have either a Benevolent Dictator or some clear voting process to resolve disputes that cannot be settled with rough consensus. -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik jgar...@bitpay.com wrote: The whole point is getting out in front of the need, to prevent significant negative impact to users when blocks are consistently full. To do that, you need to (a) plan forward, in order to (b) set a hard fork date in the future. Or alternatively, fix the reasons why users would have negative experiences with full blocks, chiefly: * Get safe forms of replace-by-fee and child-pays-for-parent finished and in 0.12. * Develop cross-platform libraries for managing micropayment channels, and get wallet authors to adopt * Use fidelity bonds, solvency proofs, and other tricks to minimize the risk of already deployed off-chain solutions as an interim measure until: * Deploy soft-fork changes for truly scalable solutions like Lightning Network. Not raising the block size limit does not mean doing nothing to solve the problem. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Regarding this proposal from Mike Hearn to remove consensus process from the BIP, which I think is unsound philosophy. I will address this briefly below. On 06/18/2015 09:05 AM, Mike Hearn wrote: So then: make a proposal for a better process, post it to this list. Alright. Here is a first cut of my proposal. It can be inserted into an amended BIP 1 after What belongs in a successful BIP?. Let me know what you think. The following section applies to BIPs that affect the block chain consensus rules or the peer to peer protocol and thus require changes to Bitcoin Core. Once a draft BIP has been submitted to bitcoin-development for consideration, the Bitcoin Core maintainer will deliver a preliminary yes/no verdict within three weeks. For many things, that will simply be too fast. It is better to allow the primary maintainer to collaborate with other people who normally work on the code and determine what the schedule will be based on life, volume of work, and so on. This verdict may be informed by the debate that has taken part in the previous three weeks. If more time is required, the maintainer is required to request an extension from the BIP author, who may then elect to force an immediate decision (risking a no), or choosing to allow more time. Again, this three week thing doesn't work. But assume for a moment that there is a certain amount of time that is such and so and it is set by the maintainer. The notion that the maintainer would be required to request an extension from the BIP author is sheer lunacy. There is no need to codify the actions of the project maintainer such that he/she would be needing to be subject to the whims of whatever BIP author. In like manner, a BIP author should not have to be subject to forever delay of a BIP due to inaction of a maintainer, but should have an answer regarding whether it can be assigned a number, published as draft and so forth after a reasonable time. To me, a reasonable time is something that should be discussed amongst the maintainer, those who work regularly on code, and the BIP author. The verdict will meet the following criteria: * It will address the latest version of the BIP at the time the verdict is rendered. * In case of a rejection, it will spell out and describe the technical rationale for this decision. Opinions held by other people are not considered technical rationales: if the maintainer agrees with a technical point made during discussion, he must own that opinion for himself. Therefore no BIP will be rejected on grounds of controversy, disagreement, lack of consensus or otherwise. No, this is ridiculous, because the notion that no BIP will be rejected on grounds of controversy, disagreement, lack of consensus, or otherwise, is clearly an attempt to do away with consensus models of business, and it is also not a very logical statement because controversy and disagreement are a natural part of... coming to what eventually is an agreement. * In case of rejection, the maintainer will provide a clear, specific list of actionable steps the BIP author can take next. For example, a list of what changes would address the technical objections raised. This above section I agree with. In case the maintainer believes no change could ever make the BIP acceptable, the list must consist of instructions for how to create a patch set and, in the case of changes to the consensus rules, how to initiate a hard fork. This above section I do not agree with because of the obvious bias in favor of the hard fork. Everything here seems to be aligned to push for hard fork, hard fork, hard fork. It's like the author can't tear his mind off it. A BIP, even once rejected, may live on in the BIPS repository, though its entry in the index may be sorted below others. The BIP author may update the BIP with a summary of any resulting discussion. As such a summary may be inherently contentious in case of a dispute, the authors wording of that summary is final and may not be subject to meta-debate. This doesn't seem right at all. -- - ___ 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 iQEcBAEBAgAGBQJVg0sHAAoJEGxwq/inSG8CuFcH/0tzRWWyy3wmDegNx463xoaq EhG/dNqoIvavMlyJrKfKWPK6Mndgo9BtxkYbvOlO40Y51SW4SaisWGzHRg4HyIbJ 0Orp+C0jXhvnrJ7hRwKhrdZQUIRAI19NLVthSb9W6mHnXWJC8ilhlK9Ei9ILRjGl tM5pZ28SkyJ/b+CnltnYW8t6AvE4zlggC4QsCuUwA2cFoFWjQeESpqjy4kJNv464 yKlsrqoIzs2vNnoLIx1B0aLX9mNTQUwB1yMXtu8IVcAQe/G1LEEnNO56LGf8O0yJ
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Thu, Jun 18, 2015 at 3:33 PM, Mark Friedenbach m...@friedenbach.org wrote: On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik jgar...@bitpay.com wrote: The whole point is getting out in front of the need, to prevent significant negative impact to users when blocks are consistently full. To do that, you need to (a) plan forward, in order to (b) set a hard fork date in the future. Or alternatively, fix the reasons why users would have negative experiences with full blocks, chiefly: * Get safe forms of replace-by-fee and child-pays-for-parent finished and in 0.12. * Develop cross-platform libraries for managing micropayment channels, and get wallet authors to adopt * Use fidelity bonds, solvency proofs, and other tricks to minimize the risk of already deployed off-chain solutions as an interim measure until: * Deploy soft-fork changes for truly scalable solutions like Lightning Network. Not raising the block size limit does not mean doing nothing to solve the problem. This is a long, unreasonable list of work. None of this exists and it equates to upgrade all wallets and websites everywhere It requires all exchanges, payment processors, merchants, etc. to - basically everybody but miners - to update. It is a far, far larger amount of work to write, test and deploy than simply increasing the block size limit. Think through roll-out of these ambitious suggestions, before suggesting as an alternative! Not a realistic alternative except in an alternate universe where (a) developer work at all companies is cost free, plus (b) we can pause the business universe while we wait for The Perfect Solution. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
Matt, I for one do not think that the block size limit should be raised at this time. Matt Corallo also started the public conversation over this issue on the mailing list by stating that he was not in favor of acting now to raise the block size limit. I find it a reasonable position to take that even if you feel the block size limit should be raised at some time in the future, there are reasons why now is not the best time to do it. On Thu, Jun 18, 2015 at 2:42 PM, Matt Whitlock b...@mattwhitlock.name wrote: On Thursday, 18 June 2015, at 8:31 pm, Ross Nicoll wrote: I may disagree with Mike Gavin on timescale, but I do believe there's a likelihood inaction will kill Bitcoin An honest question: who is proposing inaction? I haven't seen anyone in this whole, agonizing debate arguing that 1MB blocks are adequate. The debate has been about *how* to increase the block-size limit and whether to take action ASAP (at the risk of fracturing Bitcoin) or to delay action for further debate (at the risk of overloading Bitcoin). Even those who are arguing for further debate are not arguing for *inaction*. -- ___ 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] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
There's some actually proposing inaction as an outright decision, but I more meant that at times it has felt like we would end up with inaction through momentum, combined with adoption rate making any hard fork more complex if it continues to be delayed. On 18/06/2015 22:42, Matt Whitlock wrote: On Thursday, 18 June 2015, at 8:31 pm, Ross Nicoll wrote: I may disagree with Mike Gavin on timescale, but I do believe there's a likelihood inaction will kill Bitcoin An honest question: who is proposing inaction? I haven't seen anyone in this whole, agonizing debate arguing that 1MB blocks are adequate. The debate has been about *how* to increase the block-size limit and whether to take action ASAP (at the risk of fracturing Bitcoin) or to delay action for further debate (at the risk of overloading Bitcoin). Even those who are arguing for further debate are not arguing for *inaction*. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed
On 06/12/2015 06:51 PM, Pieter Wuille wrote: However, it does very clearly show the effects of larger blocks on centralization pressure of the system. On 6/14/2015 10:45 AM, Jonas Nick wrote: This means that your scenario is not the result of a cartel but the result of a long-term network partition. Pieter, to Jonas' point, in your scenario the big miners are all part of the majority partition, so centralization pressure (pressure to merge with a big miner) cannot be separated from pressure to be connected to the majority partition. I ran your simulation with a large (20%) miner in a 20% minority partition, and 16 small (5%) miners in a majority 80% partition, well connected. The starting point was your recent update, which had a more realistic slow link speed of 100 Mbit/s (making all of the effects smaller). To summarize the results across both your run and mine: ** Making small blocks when others are making big ones - BAD ** As above, and fees are enormous - VERY BAD ** Being separated by a slow link from majority hash power - BAD ** Being a small miner with blocksize=20MB - *NOT BAD* Configuration: * Miner group 0: 20.00% hashrate, blocksize 2000.00 * Miner group 1: 80.00% hashrate, blocksize 100.00 * Expected average block size: 480.00 * Average fee per block: 0.25 * Fee per byte: 0.000521 Result: * Miner group 0: 20.404704% income (factor 1.020235 with hashrate) * Miner group 1: 79.595296% income (factor 0.994941 with hashrate) Configuration: * Miner group 0: 20.00% hashrate, blocksize 2000.00 * Miner group 1: 80.00% hashrate, blocksize 2000.00 * Expected average block size: 2000.00 * Average fee per block: 0.25 * Fee per byte: 0.000125 Result: * Miner group 0: 19.864232% income (factor 0.993212 with hashrate) * Miner group 1: 80.135768% income (factor 1.001697 with hashrate) Configuration: * Miner group 0: 20.00% hashrate, blocksize 2000.00 * Miner group 1: 80.00% hashrate, blocksize 100.00 * Expected average block size: 480.00 * Average fee per block: 25.00 * Fee per byte: 0.052083 Result: * Miner group 0: 51.316895% income (factor 2.565845 with hashrate) * Miner group 1: 48.683105% income (factor 0.608539 with hashrate) Configuration: * Miner group 0: 20.00% hashrate, blocksize 2000.00 * Miner group 1: 80.00% hashrate, blocksize 2000.00 * Expected average block size: 2000.00 * Average fee per block: 25.00 * Fee per byte: 0.012500 Result: * Miner group 0: 19.865943% income (factor 0.993297 with hashrate) * Miner group 1: 80.134057% income (factor 1.001676 with hashrate) -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I maintain that you should apologize to those who traverse this list. What you are saying is digging yourself a deeper hole and is not merely embarrassing but is crossing a threshold in which you have used words, albeit subtly, to attack a community. If you refuse to apologize, I get it. You have not apologized thus far, and pressing for an apology is unlikely to get an (authentic) one. But then, you should voluntarily step back and let others do the hard work of coming to the consensus that you seem to think is impossible to accomplish based on how bitcoin is run. I believe this matter will be resolved, but not with the help of those who make threatening statements (and who are unable to apologize for having made them). - -O On 06/18/2015 03:00 AM, Mike Hearn wrote: Dude, calm down. I don't have commit access to Bitcoin Core and Gavin already said long ago he wouldn't just commit something, even though he has the ability to do so. So why did I say it? Because it's consistent with what I've always said: you cannot run a codebase like Wikipedia. Maintainers have to take part in debates, and then make a decision, and anyone else who was delegated commit access for robustness or convenience must then respect that decision. It's the only way to keep a project making progress at a reasonable pace. This is not a radical position. That's how nearly all coding projects work. I have been involved with open source for 15 years and the 'single maintainer who makes decisions' model is normal, even if in some large codebases subsystems have delegated submaintainers. This is also how all my own projects are run. Bitcoinj has multiple people with commit access. Regardless, if there were to be some design dispute or whatever, I wouldn't tolerate the others with commit access starting some kind of Wiki-style edit war in the code if they disagreed. Nor would I ever expect to get my own way in other people's projects by threatening to revert the maintainers changes. Core is in the weird position where there's no decision making ability at all, because anyone who shows up and shouts enough can generate 'controversy', then Wladimir sees there is disagreement and won't touch the issue in question. So it just runs and runs and /anyone/ with commit access can then block any change. I realise some people think this anti-process leads to better decision making. I disagree. It leads to no decision making, which is not the same thing at all. - -- 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 iQEcBAEBAgAGBQJVg0HiAAoJEGxwq/inSG8CXOwIAKSGRJPtSx+untgMERwE7lW7 9p0gWz4jvKhyO+RrGPXlofckvp4Fp/7Yxa+TDLcXbzGi6OesX9yIyN7e06LJW4DP h7V2PwzS49ZyB/krd03HjvWMFnhoGy7zB7M1okq5myIvx+h1htX9TirNbDl7PU9Z SWyNNw+GXPsIV/xuPu81LP5GrR3gIxwwhhopOq2qcm08AUiuIJ8EA31mT2ZgwMWB RxrnktFRzMbW2fD7Z7njTz1gjw1duPyGApJ+xpqtcjjS2idPNuw1nESZTCE3+TwG Dk1AKmYt8TvZzFWyo/0ly7vYFFW27Yh7SC3oeDJBoWkvySuIFrevux7ekfKxPOc= =wc2m -END PGP SIGNATURE- -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
I'm struggling to illustrate how incredibly low 7 transactions per second is, not just for a payment network, but even just for a clearance network (i.e. to balance transactions between institutions and/or chains). As an example, the Clearing House Interbank Payments System (CHIPS) is a US-only, inter-bank only clearance network, which handled about 3.5 transactions per second (average) in 2014 (https://www.theclearinghouse.org/~/media/tch/pay%20co/chips/reports%20and%20guides/chips%20volume%20through%20may%202015.pdf?la=en). While it seems likely the US population of 300 million makes more transactions individually than many other countries, and therefore we can't simply multiply that by 20 to estimate what a global clearance network might require, hopefully it's clear that if Bitcoin is to scale globally, it needs substantially more transaction throughput even if main chain transactions become something for banks and the super rich. I don't know how much more, but I can't look at the 8MB reportedly backed by a number of mining pools and say it's clearly insufficient, at least. I should emphasise that I don't think we need to jump straight to 8MB (or otherwise), if a scaling protocol can be decided upon that would be ideal, but we should be planning ahead while it's still relatively easy to make these changes. Ross On 18/06/2015 23:33, Mark Friedenbach wrote: On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik jgar...@bitpay.com mailto:jgar...@bitpay.com wrote: The whole point is getting out in front of the need, to prevent significant negative impact to users when blocks are consistently full. To do that, you need to (a) plan forward, in order to (b) set a hard fork date in the future. Or alternatively, fix the reasons why users would have negative experiences with full blocks, chiefly: * Get safe forms of replace-by-fee and child-pays-for-parent finished and in 0.12. * Develop cross-platform libraries for managing micropayment channels, and get wallet authors to adopt * Use fidelity bonds, solvency proofs, and other tricks to minimize the risk of already deployed off-chain solutions as an interim measure until: * Deploy soft-fork changes for truly scalable solutions like Lightning Network. Not raising the block size limit does not mean doing nothing to solve the problem. -- ___ 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] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Regarding the bit on getting out in front of the need, to prevent significant negative impacts to users I had suggested the following: On 06/18/2015 03:52 PM, Jeff Garzik wrote: On Thu, Jun 18, 2015 at 3:33 PM, Mark Friedenbach m...@friedenbach.org mailto:m...@friedenbach.org wrote: On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik jgar...@bitpay.com mailto:jgar...@bitpay.com wrote: The whole point is getting out in front of the need, to prevent significant negative impact to users when blocks are consistently full. My thoughts on that: Possible scope narrowing to one of the following concepts (but please, someone tell me if this scope narrowing is unwise, not timely, or if there is some other factors that would make it just stupid right now because other things are in the works or whatever: ~ Jeff Garzik, with respect to his BIP 100 (note Evan Mo, CEO of Huobi's mining project Digcoin, clarified that the big Chinese mining pools consider further adjustments to the protocol beyond the suggested 8 MB block size limit adjustment — such as the Bitcoin core developer Jeff Garzik's BIP-100 draft — to be feasible) ~ Adam Back, with a simplified soft-fork one-way peg ~ Gavin Andresen, developing an 8 MB block size limit adjustment in the context of Core (as an example) with one or more of the above authors rather than focusing on XT. (This is a big assumption but, roll with it) All of this assumes that developer(s) are willing to abandon intentionally contentious proposals such as the hard fork to XT w/ 20 MB, remain within the context of Core and be reasonable. Here I am being aware of the fact that Pushing a hard fork in the face of such controversy is a folly, a danger to the network, and that deserves to be said. - Wladimir J. van der Laan https://github.com/bitcoin/bitcoin.org/pull/894#issuecomment-112113917 To do that, you need to (a) plan forward, in order to (b) set a hard fork date in the future. Or alternatively, fix the reasons why users would have negative experiences with full blocks, chiefly: * Get safe forms of replace-by-fee and child-pays-for-parent finished and in 0.12. * Develop cross-platform libraries for managing micropayment channels, and get wallet authors to adopt * Use fidelity bonds, solvency proofs, and other tricks to minimize the risk of already deployed off-chain solutions as an interim measure until: * Deploy soft-fork changes for truly scalable solutions like Lightning Network. Not raising the block size limit does not mean doing nothing to solve the problem. This is a long, unreasonable list of work. None of this exists and it equates to upgrade all wallets and websites everywhere It requires all exchanges, payment processors, merchants, etc. to - basically everybody but miners - to update. It is a far, far larger amount of work to write, test and deploy than simply increasing the block size limit. Think through roll-out of these ambitious suggestions, before suggesting as an alternative! Not a realistic alternative except in an alternate universe where (a) developer work at all companies is cost free, plus (b) we can pause the business universe while we wait for The Perfect Solution. Something else I wanted to point out here in this thread is the subject of the problem of developers going off the deep end which is what started this thread: Suppose you have a developer with full commit access who happens to start threatening to revoking the other developers' commit access on the repository, or that person doesn't even threaten, one day it just happens. What do you have then? Peter Todd has stated that all one would achieve by that sabotage is setting a key-value pair in a centralised registry. But is that what we want? The answer, obviously, is no. This leads to other questions. What technical mechanisms exist to keep developers from (in some dubious emotional or psycho state) to just going off the deep and doing exactly what has been described above, if they have full commit access? Is there a process whereby that can't actually happen unless another developer provides a signature (e.g. a multisignature type of process)? What keeps bitcoin safe from The Hearn Threat? If nothing does, then how would you change that? And go ahead and tell me if these are dumb questions and I should just be quiet, but if they are, please do explain why they are such dumb questions. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- - ___ 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
[Bitcoin-development] Scope narrowing for proposals to address block size limit debate, an inquiry
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The purpose of this post is to present an inquiry related to the possible narrowing of scope of what sort of proposals are likely to bear fruit at this stage. The inquiry or question is, Are there some proposals that are more likely to succeed, in addressing the whole block size limit debate meaningfully? The flip side of this inquiry, is that if you think that an attempt to do such scope narrowing _at this time_ is foolhardy, inappropriate, wrong, or otherwise flawed, please say so and explain. I'm not religious about this notion. I throw out proposals below which I think would be likely to advance further ~ and thus I ask the question again, and rephrase, Are there some proposals (some shown below as examples, not all-inclusive) that are more likely to succeed, in addressing the whole block size limit debate meaningfully? ~ Jeff Garzik, with respect to his BIP 100 (note Evan Mo, CEO of Huobi's mining project Digcoin, clarified that the big Chinese mining pools consider further adjustments to the protocol beyond the suggested 8 MB block size limit adjustment — such as the Bitcoin core developer Jeff Garzik's BIP-100 draft — to be feasible) ~ Adam Back, with a simplified soft-fork one-way peg ~ Gavin Andresen, developing an 8 MB block size limit adjustment in the context of Core (as an example) with one or more of the above authors rather than focusing on XT. (This is a big assumption but, roll with it) All of this assumes that developer(s) are willing to abandon intentionally contentious proposals such as the hard fork to XT w/ 20 MB, remain within the context of Core and be reasonable. Here I am being aware of the fact that Pushing a hard fork in the face of such controversy is a folly, a danger to the network, and that deserves to be said. - Wladimir J. van der Laan https://github.com/bitcoin/bitcoin.org/pull/894#issuecomment-112113917 And if I'm lucky, this thread may get comments from DumbFruit, who writes stuff like this: https://bitcointalk.org/index.php?topic=1085436.msg11643203#msg11643203 So now... your thoughts? - -- 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 iQEcBAEBAgAGBQJVgnLuAAoJEGxwq/inSG8CchMH/0zm+A7Uqp8SpU+CsJr3lF2+ 0re+5Ql4qVVmOI560918BtkdFjcq33jsKU9cYUDXqZ4wHfJTAGLGDqNgUZGpGkmJ bqGgSvdF64P52Vb9PVnz1I9+aClas8Mjvl8XUYoD0yEA14XVBakYDRbVqZ5yPM8n hBi6EpWLUnkFvvEj2dkgwddvPCvrnhVL/aRfmhet1pfOELfIrXtXI7hs2F1RyaqK sbR/Qg3SFlyHzbxSzRVcZQ0G81exq/fxHqxc5kSLMiR7TODIJxCl6cJDCjf8LbeS n6tL/I8vWN2zraYfb0cWu5uIjz5XnXpsitu951109zoS8IYle3uTfCF+6xdG3tY= =HQ9R -END PGP SIGNATURE- -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
