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] Reducing the block rate instead of increasing the maximum block size
So if the server pushes new block header candidates to clients, then the problem boils down to increasing bandwidth of the servers to achieve a tenfold increase in work distribution. Most Stratum pools already do multiple updates of the header every block period, bandwidth is really inconsequential, it's the latency that kills. At the present time you are looking up to 15 seconds between the first and last pools to push headers to their clients for the latest block. It's sort of inconsequential with a 10 minute block time, but it cuts into a 1 minute one very heavily. Some pools already don't do their own validation of blocks, but simply mirror other pools, pushing them to be even more latency focused will just make this an epidemic of invalidity rather than a solution. There are several proof-of-work cryptocurrencies in existence that have lower than 1 minute block intervals and they work just fine. First there was Bitcoin with a 10 minute interval, then was LiteCoin using a 2.5 interval, then was DogeCoin with 1 minute, and then QuarkCoin with just 30 seconds. You can't really use these as examples of things going just fine. None of these networks see anything approaching the Bitcoin transaction volume and none have even remotely the same network size. Some Bitcoin forks use floats in consensus critical code and work just fine, for the moment. We can't justify poor decisions with but the altcoins are doing it. Is there even a single study of the stale rates within these networks? -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reducing the block rate instead of increasing the maximum block size
On 2015-05-11 10:34, Peter Todd wrote: How do you see that blacklisting actually being done? Same way ghash.io was banned from the network when used Finney attacks against BetCoin Dice. As Andreas Antonopoulos says, if any of the miners do anything bad, we just ban them from mining. Any sort of attack like this only lasts 10 minutes as a result. Stop worrying so much. https://youtu.be/ncPyMUfNyVM?t=20s -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Long-term mining incentives
On 2015-05-11 16:28, Thomas Voegtlin wrote: My problem is that this seems to lacks a vision. If the maximal block size is increased only to buy time, or because some people think that 7 tps is not enough to compete with VISA, then I guess it would be healthier to try and develop off-chain infrastructure first, such as the Lightning network. If your end goal is compete with VISA you might as well just give up and go home right now. There's lots of terrible proposals where people try to demonstrate that so many hundred thousand transactions a second are possible if we just make the block size 500GB. In the real world with physical limits, you literally can not verify more than a few thousand ECDSA signatures a second on a CPU core. The tradeoff taken in Bitcoin is that the signatures are pretty small, but they are also slow to verify on any sort of scale. There's no way competing with a centralised entity using on-chain transactions is even a sane goal. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
