Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
On Fri, May 29, 2015 at 12:26 PM, Mike Hearn m...@plan99.net wrote: IMO it's not even clear there needs to be a size limit at all. Currently the 32mb message cap imposes one anyway If the plan is a fix once and for all, then that should be changed too. It could be set so that it is at least some multiple of the max block size allowed. Alternatively, the merkle block message already incorporates the required functionality. Send - headers message (with 1 header) - merkleblock messages (max 1MB per message) The transactions for each merkleblock could be sent directly before each merkleblock, as is currently the case. That system can send a block of any size. It would require a change to the processing of any merkleblocks received. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
By the time a hard fork can happen, I expect average block size will be above 500K. Yes, possibly. Would you support a rule that was larger of 1MB or 2x average size ? That is strictly better than the situation we're in today. It is, but only by a trivial amount - hitting the limit is still very likely. I don't want to see this issue come up over and over again. Ideally never. We shouldn't be artificially throttling organic growth of the network, especially not by accident. IMO it's not even clear there needs to be a size limit at all. Currently the 32mb message cap imposes one anyway, but if miners can always just discourage blocks over some particular size if they want to. But I can get behind a 20mb limit (or 20mb+N) as it represents a reasonable compromise: the limit still exists, it's far below VISA capacity etc, but it should also free up enough space that everyone can get back to what we *should* be focusing on, which is user growth! -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
If the plan is a fix once and for all, then that should be changed too. It could be set so that it is at least some multiple of the max block size allowed. Well, but RAM is not infinite :-) Effectively what these caps are doing is setting the minimum hardware requirements for running a Bitcoin node. That's OK by me - I don't think we are actually going to exhaust the hardware abilities of any reasonable computer any time soon, but still, having the software recognise the finite nature of a computing machine doesn't seem unwise. That system can send a block of any size. It would require a change to the processing of any merkleblocks received. Not any size because, again, the remote node must buffer things up and have the transaction data actually in memory in order to digest it. But a much larger size, yes. However, that's a bigger change. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
What do other people think? If we can't come to an agreement soon, then I'll ask for help reviewing/submitting patches to Mike's Bitcoin-Xt project that implement a big increase now that grows over time so we may never have to go through all this rancor and debate again. I'll then ask for help lobbying the merchant services and exchanges and hosted wallet companies and other bitcoind-using-infrastructure companies (and anybody who agrees with me that we need bigger blocks sooner rather than later) to run Bitcoin-Xt instead of Bitcoin Core, and state that they are running it. We'll be able to see uptake on the network by monitoring client versions. Perhaps by the time that happens there will be consensus bigger blocks are needed sooner rather than later; if so, great! The early deployment will just serve as early testing, and all of the software already deployed will ready for bigger blocks. But if there is still no consensus among developers but the bigger blocks now movement is successful, I'll ask for help getting big miners to do the same, and use the soft-fork block version voting mechanism to (hopefully) get a majority and then a super-majority willing to produce bigger blocks. The purpose of that process is to prove to any doubters that they'd better start supporting bigger blocks or they'll be left behind, and to give them a chance to upgrade before that happens. Because if we can't come to consensus here, the ultimate authority for determining consensus is what code the majority of merchants and exchanges and miners are running. -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
Are you really that pig headed that you are going to try and blow up the entire system just to get your way? A bunch of ignorant redditors do not make consensus, mercifully. On 2015-05-29 12:39, Gavin Andresen wrote: What do other people think? If we can't come to an agreement soon, then I'll ask for help reviewing/submitting patches to Mike's Bitcoin-Xt project that implement a big increase now that grows over time so we may never have to go through all this rancor and debate again. I'll then ask for help lobbying the merchant services and exchanges and hosted wallet companies and other bitcoind-using-infrastructure companies (and anybody who agrees with me that we need bigger blocks sooner rather than later) to run Bitcoin-Xt instead of Bitcoin Core, and state that they are running it. We'll be able to see uptake on the network by monitoring client versions. Perhaps by the time that happens there will be consensus bigger blocks are needed sooner rather than later; if so, great! The early deployment will just serve as early testing, and all of the software already deployed will ready for bigger blocks. But if there is still no consensus among developers but the bigger blocks now movement is successful, I'll ask for help getting big miners to do the same, and use the soft-fork block version voting mechanism to (hopefully) get a majority and then a super-majority willing to produce bigger blocks. The purpose of that process is to prove to any doubters that they'd better start supporting bigger blocks or they'll be left behind, and to give them a chance to upgrade before that happens. Because if we can't come to consensus here, the ultimate authority for determining consensus is what code the majority of merchants and exchanges and miners are running. -- -- Gavin Andresen -- ___ 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] Proposed alternatives to the 20MB step function
How is this being pigheaded? In my opinion, this is leadership. If *something* isn't implemented soon, the network is going to have some real problems, right at the time when adoption is starting to accelerate. I've been seeing nothing but navel-gazing and circlejerks on this issue for weeks now. Gavin or Mike or someone at some point needs to step up and say follow me. Braun Brelin On Fri, May 29, 2015 at 5:00 PM, insecurity@national.shitposting.agency wrote: Are you really that pig headed that you are going to try and blow up the entire system just to get your way? A bunch of ignorant redditors do not make consensus, mercifully. On 2015-05-29 12:39, Gavin Andresen wrote: What do other people think? If we can't come to an agreement soon, then I'll ask for help reviewing/submitting patches to Mike's Bitcoin-Xt project that implement a big increase now that grows over time so we may never have to go through all this rancor and debate again. I'll then ask for help lobbying the merchant services and exchanges and hosted wallet companies and other bitcoind-using-infrastructure companies (and anybody who agrees with me that we need bigger blocks sooner rather than later) to run Bitcoin-Xt instead of Bitcoin Core, and state that they are running it. We'll be able to see uptake on the network by monitoring client versions. Perhaps by the time that happens there will be consensus bigger blocks are needed sooner rather than later; if so, great! The early deployment will just serve as early testing, and all of the software already deployed will ready for bigger blocks. But if there is still no consensus among developers but the bigger blocks now movement is successful, I'll ask for help getting big miners to do the same, and use the soft-fork block version voting mechanism to (hopefully) get a majority and then a super-majority willing to produce bigger blocks. The purpose of that process is to prove to any doubters that they'd better start supporting bigger blocks or they'll be left behind, and to give them a chance to upgrade before that happens. Because if we can't come to consensus here, the ultimate authority for determining consensus is what code the majority of merchants and exchanges and miners are running. -- -- Gavin Andresen -- ___ 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] Proposed alternatives to the 20MB step function
On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen gavinandre...@gmail.com wrote: But if there is still no consensus among developers but the bigger blocks now movement is successful, I'll ask for help getting big miners to do the same, and use the soft-fork block version voting mechanism to (hopefully) get a majority and then a super-majority willing to produce bigger blocks. The purpose of that process is to prove to any doubters that they'd better start supporting bigger blocks or they'll be left behind, and to give them a chance to upgrade before that happens. How do you define that the movement is successful? For Because if we can't come to consensus here, the ultimate authority for determining consensus is what code the majority of merchants and exchanges and miners are running. The measure is miner consensus. How do you intend to measure exchange/merchant acceptance? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction
Regarding Tier’s proposal: The lower security you mention for extended blocks would delay, possibly forever, the larger blocks maximum block size that we want for the entire network. That doesn’t sound like an optimal solution. Regarding consensus for larger maximum block size, what we are seeing on this list is typical of what we see in the U.S. Congress. Support for changes by the stakeholders (support for bills by the citizens as a whole) has become irrelevant to the probability of these changes being adopted. Lobbyists have all the sway in getting their policies enacted. In our case, I would bet on some lobbying of core developers by wealthy miners. Someone recently proposed that secret ballots could help eliminate the power of lobbyists in Congress. Nobody invests in that which cannot be confirmed. Secret ballots mean the vote you are buying cannot be confirmed. Perhaps this will work for Bitcoin Core as well. From: Tier Nolan Sent: Friday, May 29, 2015 7:22 AM Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction On Fri, May 29, 2015 at 3:09 PM, Tier Nolan tier.no...@gmail.com wrote: On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen gavinandre...@gmail.com wrote: But if there is still no consensus among developers but the bigger blocks now movement is successful, I'll ask for help getting big miners to do the same, and use the soft-fork block version voting mechanism to (hopefully) get a majority and then a super-majority willing to produce bigger blocks. The purpose of that process is to prove to any doubters that they'd better start supporting bigger blocks or they'll be left behind, and to give them a chance to upgrade before that happens. How do you define that the movement is successful? Sorry again, I keep auto-sending from gmail when trying to delete. In theory, using the nuclear option, the block size can be increased via soft fork. Version 4 blocks would contain the hash of the a valid extended block in the coinbase. block height 32 byte extended hash To send coins to the auxiliary block, you send them to some template. OP_P2SH_EXTENDED scriptPubKey hash OP_TRUE This transaction can be spent by anyone (under the current rules). The soft fork would lock the transaction output unless it transferred money from the extended block. To unlock the transaction output, you need to include the txid of transaction(s) in the extended block and signature(s) in the scriptSig. The transaction output can be spent in the extended block using P2SH against the scriptPubKey hash. This means that people can choose to move their money to the extended block. It might have lower security than leaving it in the root chain. The extended chain could use the updated script language too. This is obviously more complex than just increasing the size though, but it could be a fallback option if no consensus is reached. It has the advantage of giving people a choice. They can move their money to the extended chain or not, as they wish. -- ___ 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] Proposed alternatives to the 20MB stepfunction
On Fri, May 29, 2015 at 5:39 PM, Raystonn . rayst...@hotmail.com wrote: Regarding Tier’s proposal: The lower security you mention for extended blocks would delay, possibly forever, the larger blocks maximum block size that we want for the entire network. That doesn’t sound like an optimal solution. I don't think so. The lower security is the potential centralisation risk. If you have your money in the root chain, then you can watch it. You can probably also watch it in a 20MB chain. Full nodes would still verify the entire block (root + extended). It is a nuclear option, since you can make any changes you want to the rules for the extended chain. The only safe guard is that people have to voluntarly transfer coins to the extended block. The extended block might have 10-15% of the total bitcoins, but still be useful, since they would be the ones that move the most. If you want to store your coins long term, you move them back to the root block where you can watch them more closely. It does make things more complex though. Wallets would have to list 2 balances. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
What about trying the dynamic scaling method within the 20MB range + 1 year with a 40% increase of that cap? Until a way to dynamically scale is found, the cap will only continue to be an issue. With 20 MB + 40% yoy, we're either imposing an arbitrary cap later, or achieving less than great DOS protection always. Why not set that policy as a maximum for 2 years as a protection against the possibility of dynamic scaling abuse, and see what happens with a dynamic method in the mean time. The policy of Max(1MB, (average size over previous 144 blocks) * 2) calculated at each block seems pretty reasonable. As an outsider, the real 'median' here seems to be 'keeping the cap as small as possible while allowing for larger blocks still'.We know miners will want to keep space in their blocks relatively scarce, but we also know that doesn't exclude the more powerful miners from including superfluous transactions to increase their effective share of the network. I have the luck of not being drained by this topic over the past three years, so it looks to me as if its two poles of 'block size must increase' and 'block size must not increase' are forcing what is the clear route to establishing the 'right' block size off the table. --Andrew Len (sorry if anybody received this twice, sent as the wrong email the first time around). On Fri, May 29, 2015 at 5:39 AM, Gavin Andresen gavinandre...@gmail.com wrote: What do other people think? If we can't come to an agreement soon, then I'll ask for help reviewing/submitting patches to Mike's Bitcoin-Xt project that implement a big increase now that grows over time so we may never have to go through all this rancor and debate again. I'll then ask for help lobbying the merchant services and exchanges and hosted wallet companies and other bitcoind-using-infrastructure companies (and anybody who agrees with me that we need bigger blocks sooner rather than later) to run Bitcoin-Xt instead of Bitcoin Core, and state that they are running it. We'll be able to see uptake on the network by monitoring client versions. Perhaps by the time that happens there will be consensus bigger blocks are needed sooner rather than later; if so, great! The early deployment will just serve as early testing, and all of the software already deployed will ready for bigger blocks. But if there is still no consensus among developers but the bigger blocks now movement is successful, I'll ask for help getting big miners to do the same, and use the soft-fork block version voting mechanism to (hopefully) get a majority and then a super-majority willing to produce bigger blocks. The purpose of that process is to prove to any doubters that they'd better start supporting bigger blocks or they'll be left behind, and to give them a chance to upgrade before that happens. Because if we can't come to consensus here, the ultimate authority for determining consensus is what code the majority of merchants and exchanges and miners are running. -- -- Gavin Andresen -- ___ 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] Proposed alternatives to the 20MB step function
miners would definitely be squeezing out transactions / putting pressure to increase transaction fees I'd just like to re-iterate that transactions getting squeezed out (failure after a lengthy period of uncertainty) is a radical change from the current behavior of the network. There are plenty of avenues to create fee pressure without resorting to such a drastic change in how the network works today. Aaron Voisine co-founder and CEO breadwallet.com On Thu, May 28, 2015 at 8:53 AM, Gavin Andresen gavinandre...@gmail.com wrote: On Fri, May 8, 2015 at 3:20 AM, Matt Whitlock b...@mattwhitlock.name wrote: Between all the flames on this list, several ideas were raised that did not get much attention. I hereby resubmit these ideas for consideration and discussion. - Perhaps the hard block size limit should be a function of the actual block sizes over some trailing sampling period. For example, take the median block size among the most recent 2016 blocks and multiply it by 1.5. This allows Bitcoin to scale up gradually and organically, rather than having human beings guessing at what is an appropriate limit. A lot of people like this idea, or something like it. It is nice and simple, which is really important for consensus-critical code. With this rule in place, I believe there would be more fee pressure (miners would be creating smaller blocks) today. I created a couple of histograms of block sizes to infer what policy miners are ACTUALLY following today with respect to block size: Last 1,000 blocks: http://bitcoincore.org/~gavin/sizes_last1000.html Notice a big spike at 750K -- the default size for Bitcoin Core. This graph might be misleading, because transaction volume or fees might not be high enough over the last few days to fill blocks to whatever limit miners are willing to mine. So I graphed a time when (according to statoshi.info) there WERE a lot of transactions waiting to be confirmed: http://bitcoincore.org/~gavin/sizes_357511.html That might also be misleading, because it is possible there were a lot of transactions waiting to be confirmed because miners who choose to create small blocks got lucky and found more blocks than normal. In fact, it looks like that is what happened: more smaller-than-normal blocks were found, and the memory pool backed up. So: what if we had a dynamic maximum size limit based on recent history? The average block size is about 400K, so a 1.5x rule would make the max block size 600K; miners would definitely be squeezing out transactions / putting pressure to increase transaction fees. Even a 2x rule (implying 800K max blocks) would, today, be squeezing out transactions / putting pressure to increase fees. Using a median size instead of an average means the size can increase or decrease more quickly. For example, imagine the rule is median of last 2016 blocks and 49% of miners are producing 0-size blocks and 51% are producing max-size blocks. The median is max-size, so the 51% have total control over making blocks bigger. Swap the roles, and the median is min-size. Because of that, I think using an average is better-- it means the max size will change (up or down) more slowly. I also think 2016 blocks is too long, because transaction volumes change quicker than that. An average over 144 blocks (last 24 hours) would be better able to handle increased transaction volume around major holidays, and would also be able to react more quickly if an economically irrational attacker attempted to flood the network with fee-paying transactions. So my straw-man proposal would be: max size 2x average size over last 144 blocks, calculated at every block. There are a couple of other changes I'd pair with that consensus change: + Make the default mining policy for Bitcoin Core neutral-- have its target block size be the average size, so miners that don't care will go along with the people who do care. + Use something like Greg's formula for size instead of bytes-on-the-wire, to discourage bloating the UTXO set. - When I've proposed (privately, to the other core committers) some dynamic algorithm the objection has been but that gives miners complete control over the max block size. I think that worry is unjustified right now-- certainly, until we have size-independent new block propagation there is an incentive for miners to keep their blocks small, and we see miners creating small blocks even when there are fee-paying transactions waiting to be confirmed. I don't even think it will be a problem if/when we do have size-independent new block propagation, because I think the combination of the random timing of block-finding plus a dynamic limit as described above will create a healthy system. If I'm wrong, then it seems to me the miners will have a very strong incentive to, collectively, impose whatever rules are necessary (maybe a soft-fork to put a hard cap on block size) to
Re: [Bitcoin-development] Block Size Increase Requirements
Matt brought this up on Twitter, I have no idea why I didn't respond weeks ago (busy writing blog posts, probably): On Thu, May 7, 2015 at 6:02 PM, Matt Corallo bitcoin-l...@bluematt.me wrote: * Though there are many proposals floating around which could significantly decrease block propagation latency, none of them are implemented today. If block propagation isn't fixed, then mines have a strong incentive to create smaller blocks. So the max block size is irrelevant, it won't get hit. In addition, I'd expect to see analysis of how these systems perform in the worst-case, not just packet-loss-wise, but in the face of miners attempting to break the system. See http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners for analysis of but that means bigger miners can get an advantage argument. Executive summary: if little miners are stupid and produce huge blocks, then yes, big miners have an advantage. But they're not, so they won't. Until the block reward goes away, and assuming transaction fees become an important source of revenue for miners. I think it is too early to worry about that; see: http://gavinandresen.ninja/when-the-block-reward-goes-away * I'd very much like to see someone working on better scaling technology, both in terms of development and in terms of getting traction in the marketplace. Ok. What does this have to do with the max block size? Are you arguing that work won't happen if the max block size increases? * I'd like to see some better conclusions to the discussion around long-term incentives within the system. Again, see http://gavinandresen.ninja/when-the-block-reward-goes-away for what I think about that. -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase Requirements
On 05/29/15 22:36, Gavin Andresen wrote: Matt brought this up on Twitter, I have no idea why I didn't respond weeks ago (busy writing blog posts, probably): On Thu, May 7, 2015 at 6:02 PM, Matt Corallo bitcoin-l...@bluematt.me mailto:bitcoin-l...@bluematt.me wrote: * Though there are many proposals floating around which could significantly decrease block propagation latency, none of them are implemented today. If block propagation isn't fixed, then mines have a strong incentive to create smaller blocks. So the max block size is irrelevant, it won't get hit. Sadly, this is very far from the whole story. The issue of miners optimizing for returns has been discussed several times during this discussion, and, sadly, miners who are geographically colocated who are optimizing for returns with a free-floating blocksize will optimize away 50% of the network! In addition, I'd expect to see analysis of how these systems perform in the worst-case, not just packet-loss-wise, but in the face of miners attempting to break the system. See http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners for analysis of but that means bigger miners can get an advantage argument. Executive summary: if little miners are stupid and produce huge blocks, then yes, big miners have an advantage. I'll talk about transaction fees in a second, but there are several problems with this already. As pointed out in the original mail, gfw has already been known to interfere with Bitcoin P2P traffic. So now by little miners, you mean any miner who is not located in mainland China? Whats worse, the disadvantage is symmetric - little miners are at a disadvantage when *anyone* mines a bigger block, and miners dont even have to be evil for this to happen - just optimize for profits. But they're not, so they won't. I dont know what you're referring to with this. Are you claiming little miners today optimize for relay times and have good visibility into the Bitcoin network and calculate an optimal block size based on this (or would with a 20MB block size)? Until the block reward goes away, and assuming transaction fees become an important source of revenue for miners. I think it is too early to worry about that; see: http://gavinandresen.ninja/when-the-block-reward-goes-away You dont make any points here with which I can argue, but let me respond with the reason /I/ think it is a problem worth thinking a little bit about...If we increase the blocksize sufficiently such that transaction fees are not the way in which miners make their money, then either miners are not being funded (ie hashpower has to drop to very little), or the only people mining/funding miners are large orgs who are running Bitcoin (ie the web wallets, payment processors, big merchants, and exchanges of the world). Sadly, this is no longer a decentralized Bitcoin and is, in fact, pretty much how the banking world works today. I'm not sure who, if anyone, claims Bitcoin is novel or interesting for any reason other than its decentralization properties, and, in a world which you are apparently proposing, the natural course of things is to very strongly centralize. * I'd very much like to see someone working on better scaling technology, both in terms of development and in terms of getting traction in the marketplace. Ok. What does this have to do with the max block size? Are you arguing that work won't happen if the max block size increases? Yes, I am arguing that by increasing the blocksize the incentives to actually make Bitcoin scale go away. Even if amazing technologies get built, no one will have any reason to use them. * I'd like to see some better conclusions to the discussion around long-term incentives within the system. Again, see http://gavinandresen.ninja/when-the-block-reward-goes-away for what I think about that. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase Requirements
Hello. I am from F2Pool. We are currently mining the biggest blocks on the network. So far top 100 biggest bitcoin blocks are all from us. We do support bigger blocks and sooner rather than later. But we cannot handle 20 MB blocks right now. I know most blocks would not be 20 MB over night. But only if a small fraction of blocks more than 10 MB, it could dramatically increase of our orphan rate, result of higher fee to miners. Bad miners could attack us and the network with artificial big blocks. As yhou know, other Chinese pools, AntPool, BW, they produces ASIC chips and mining mostly with their own machines. They do not care about a few percent of orphan increase as much as we do. They would continue their zero fee policy. We would be the biggest loser. As the exchanges had taught us, zero fee is not health to the network. Also we have to redevelop our block broadcast logic. Server bandwidth is a lot more expensive in China. And the Internet is slow. Currently China has more than 50% of mining power, if block size increases, I bet European and American pools could suffer more than us. We think the max block size should be increased, but must be increased smoothly, 2 MB first, and then after one or two years 4 MB, then 8 MB, and so on. Thanks. On Fri, May 8, 2015 at 6:02 AM, Matt Corallo bitcoin-l...@bluematt.me wrote: OK, so lets do that. I've seen a lot of I'm not entirely comfortable with committing to this right now, but think we should eventually, but not much I'd be comfortable with committing to this when I see X. In the interest of ignoring debate and pushing people towards a consensus at all costs, ( ;) ) I'm gonna go ahead and suggest we talk about the second. Personally, there are several things that worry me significantly about committing to a blocksize increase, which I'd like to see resolved before I'd consider supporting a blocksize increase commitment. * Though there are many proposals floating around which could significantly decrease block propagation latency, none of them are implemented today. I'd expect to see these not only implemented but being used in production (though I dont particularly care about them being all that stable). I'd want to see measurements of how they perform both in production and in the face of high packet loss (eg across the GFW or in the case of small/moderate DoS). In addition, I'd expect to see analysis of how these systems perform in the worst-case, not just packet-loss-wise, but in the face of miners attempting to break the system. * I'd very much like to see someone working on better scaling technology, both in terms of development and in terms of getting traction in the marketplace. I know StrawPay is working on development, though its not obvious to me how far they are from their website, but I dont know of any commitments by large players (either SPV wallets, centralized wallet services, payment processors, or any others) to support such a system (to be fair, its probably too early for such players to commit to anything, since anything doesnt exist in public). * I'd like to see some better conclusions to the discussion around long-term incentives within the system. If we're just building Bitcoin to work in five years, great, but if we want it all to keep working as subsidy drops significantly, I'd like a better answer than we'll deal with it when we get there or it will happen, all the predictions based on people's behavior today say so (which are hopefully invalid thanks to the previous point). Ideally, I'd love to see some real free pressure already on the network starting to develop when we commit to hardforking in a year. Not just full blocks with some fees because wallets are including far greater fees than they really need to, but software which properly handles fees across the ecosystem, smart fee increases when transactions arent confirming (eg replace-by-fee, which could be limited to increase-in-fees-only for those worried about double-spends). I probably forgot one or two and certainly dont want to back myself into a corner on committing to something here, but those are a few things I see today as big blockers on larger blocks. Luckily, people have been making progress on building the software needed in all of the above for a while now, but I think they're all very, very immature today. On 05/07/15 19:13, Jeff Garzik wrote: On Thu, May 7, 2015 at 3:03 PM, Matt Corallo bitcoin-l...@bluematt.me mailto:bitcoin-l...@bluematt.me wrote: -snip- If, instead, there had been an intro on the list as I think we should do the blocksize increase soon, what do people think?, the response could likely have focused much more around creating a specific list of things we should do before we (the technical community) think we are prepared for a blocksize increase. Agreed, but that is water under the bridge at this point. You - rightly - opened the topic here and now we're discussing it.
[Bitcoin-development] soft-fork block size increase (extension blocks) Re: Proposed alternatives to the 20MB stepfunction
I discussed the extension block idea on wizards a while back and it is a way to soft-fork an opt-in block-size increase. Like everything here there are pros and cons. The security is better than Raylstonn inferred from Tier's explanation I think.. It works as Tier described - there is an extension block (say 10MB) and the existing 1MB block. The extension block is committed to in the 1MB chain. Users can transfer bitcoin into the extension block, and they can transfer them out. The interesting thing is this makes block sizes changes opt-in and gives users choice. Choice is good. Bitcoin has a one-size-fits-all blocksize at present hence the block size debate. If a bigger block-size were an opt-in choice, and some people wanted 10MB or even 100MB blocks for low value transactions I expect it would be far easier a discussion - people who think 100MB blocks are dangerously centralising, would not opt to use them (or would put only small values they can afford to lose in them). There are some security implications though, so this also is nuanced, and more on that in a bit. Fee pressure still exists for blocks of difference size as the security assurances are not the same. It is plausible that some people would pay more for transactions in the 1MB block. Now there are three choices of validation level, rather than the normal 2-levels of SPV or full-node, with extension blocks we get a choice: A) a user could run a full node for both 1MB and 10MB blocks, and get full security for both 1MB and 10MB block transactions (but at higher bandwidth cost), or B) a user could run a full node on the 1MB block, but operate as an SPV node for the 10MB block, or C) run in SPV mode for both 1MB and 10MB blocks. Similarly for mining - miners could validate 1MB and 10MB transactions (solo mine or GBT-style), or they could self-validate 1MB transactions and pool mine 10MB transactions (have a pool validate those). 1MB full node users who do not upgrade to software that understands extension blocks, could run in SPV mode with respect to 10MB blocks. Here lies the risk - this imposes a security downgrade on the 1MB non-upgraded users, and also on users who upgrade but dont have the bandwidth to validate 10MB blocks. We could defend non-upgrade users by making receiving funds that came via the extension block opt-in also, eg an optional to use new address version and construct the extension block so that payments out of it can only go to new version addresses. We could harden 1MB block SPV security (when receiving weaker extension block transactions) in a number of ways: UTXO commitments, fraud proofs (and fraud bounties) for moving from the extension block to the 1MB block. We could optionally require coins moving via the extension block to the 1MB block to be matured (eg 100 blocks delay) Anyway something else to evaluate. Not as simple to code as a hard-fork, but way safer transition than a hard-fork, and opt-in - if you prefer the higher decentralisation of 1MB blocks, keep using them; if you prefer 10MB blocks you can opt-in to them. Adam On 29 May 2015 at 17:39, Raystonn . rayst...@hotmail.com wrote: Regarding Tier’s proposal: The lower security you mention for extended blocks would delay, possibly forever, the larger blocks maximum block size that we want for the entire network. That doesn’t sound like an optimal solution. Regarding consensus for larger maximum block size, what we are seeing on this list is typical of what we see in the U.S. Congress. Support for changes by the stakeholders (support for bills by the citizens as a whole) has become irrelevant to the probability of these changes being adopted. Lobbyists have all the sway in getting their policies enacted. In our case, I would bet on some lobbying of core developers by wealthy miners. Someone recently proposed that secret ballots could help eliminate the power of lobbyists in Congress. Nobody invests in that which cannot be confirmed. Secret ballots mean the vote you are buying cannot be confirmed. Perhaps this will work for Bitcoin Core as well. From: Tier Nolan Sent: Friday, May 29, 2015 7:22 AM Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction On Fri, May 29, 2015 at 3:09 PM, Tier Nolan tier.no...@gmail.com wrote: On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen gavinandre...@gmail.com wrote: But if there is still no consensus among developers but the bigger blocks now movement is successful, I'll ask for help getting big miners to do the same, and use the soft-fork block version voting mechanism to (hopefully) get a majority and then a super-majority willing to produce bigger blocks. The purpose of that process is to prove to any doubters that they'd better start supporting bigger blocks or they'll be left behind, and to give them a chance to upgrade before that happens. How do you define that the movement is successful? Sorry again, I
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
On Fri, May 29, 2015 at 5:39 AM, Gavin Andresen gavinandre...@gmail.com wrote: What do other people think? If we can't come to an agreement soon, then I'll ask for help reviewing/submitting patches to Mike's Bitcoin-Xt project that implement a big increase now that grows over time so we may never have to go through all this rancor and debate again. I'll then ask for help lobbying the merchant services and exchanges and hosted wallet companies and other bitcoind-using-infrastructure companies (and anybody who agrees with me that we need bigger blocks sooner rather than later) to run Bitcoin-Xt instead of Bitcoin Core, and state that they are running it. We'll be able to see uptake on the network by monitoring client versions. While I think we'd all prefer Core to make changes like this, the current environment may make that impossible. If this change happens in XT, we will support the necessary changes in our own implementation. The block size limit is a problem _today_, and I'd rather we solve today's problems with today's understanding rather than let speculation about future unknowns stop our ability to respond to known issues. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
On Fri, May 29, 2015 at 10:09 AM, Tier Nolan tier.no...@gmail.com wrote: How do you intend to measure exchange/merchant acceptance? Public statements saying we're running software that is ready for bigger blocks. And looking at the version (aka user-agent) strings of publicly reachable nodes on the network. (e.g. see the count at https://getaddr.bitnodes.io/nodes/ ) -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
The measure is miner consensus. How do you intend to measure exchange/merchant acceptance? Asking them. In fact, we already have. I have been talking to well known people and CEOs in the Bitcoin community for some time now. *All* of them support bigger blocks, this includes: - Every wallet developer I have asked (other than Bitcoin Core) - So far, every payment processor and every exchange company I know Gavin has also been talking to people about this. There's a feeling on this list that there's no consensus, or that Gavin and myself are on the wrong side of it. I'd put it differently - there's very strong consensus out in the wider community and this list is something of an aberration. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
On Fri, May 29, 2015 at 3:09 PM, Tier Nolan tier.no...@gmail.com wrote: On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen gavinandre...@gmail.com wrote: But if there is still no consensus among developers but the bigger blocks now movement is successful, I'll ask for help getting big miners to do the same, and use the soft-fork block version voting mechanism to (hopefully) get a majority and then a super-majority willing to produce bigger blocks. The purpose of that process is to prove to any doubters that they'd better start supporting bigger blocks or they'll be left behind, and to give them a chance to upgrade before that happens. How do you define that the movement is successful? Sorry again, I keep auto-sending from gmail when trying to delete. In theory, using the nuclear option, the block size can be increased via soft fork. Version 4 blocks would contain the hash of the a valid extended block in the coinbase. block height 32 byte extended hash To send coins to the auxiliary block, you send them to some template. OP_P2SH_EXTENDED scriptPubKey hash OP_TRUE This transaction can be spent by anyone (under the current rules). The soft fork would lock the transaction output unless it transferred money from the extended block. To unlock the transaction output, you need to include the txid of transaction(s) in the extended block and signature(s) in the scriptSig. The transaction output can be spent in the extended block using P2SH against the scriptPubKey hash. This means that people can choose to move their money to the extended block. It might have lower security than leaving it in the root chain. The extended chain could use the updated script language too. This is obviously more complex than just increasing the size though, but it could be a fallback option if no consensus is reached. It has the advantage of giving people a choice. They can move their money to the extended chain or not, as they wish. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
And looking at the version (aka user-agent) strings of publicly reachable nodes on the network. (e.g. see the count at https://getaddr.bitnodes.io/nodes/ ) Yeah, though FYI Luke informed me last week that I somehow managed to take out the change to the user-agent string in Bitcoin XT, presumably I made a mistake during a rebase of the rebranding change. So the actual number of XT nodes is a bit higher than counting user-agent strings would suggest. I sort of neglected XT lately. If we go ahead with this then I'll fix things like this. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
