Re: [Bitcoin-development] Protocol extensions
Agree, but even before that, we will meet problems of the current 1MB/10min limit. The calculations from the scalability link surely indicates that there are 2 options for scalability either go for trusted supernodes backed by huge hardware resources or something else would be needed. The supernode approach is simple and easy to implement, but it also breaks a lot of the nice features about bitcoin. So if we want bitcoin to stay p2p we need to deploy other strategies. The hash space partitioning is one of them. And the nice thing is that it can be made to scale even for a javascript based validating and fully connected client running on a smartphone in a bitcoin future with billions of clients and transactions, and still it does not exclude you from running a trusted supernode either. Cheers, M On 21/12/2011, at 18:17, Jordan Mack wrote: I think it would be a lot more than that. According to the Scalability page (https://en.bitcoin.it/wiki/Scalability) if Bitcoin took over all credit card transactions, that would be about 1.14GB per block. I believe that is 58.5PB per year. (6*24*365*1.14/1024) This would also mean the distribution of 2MB of block data per second, which doesn't include broadcast overhead. On 12/21/2011 12:50 AM, Michael Grønager wrote: when bitcoin takes over all credit card transactions (!), and even before that, we will meet a scalability problem. The blockchain will grow rapidly, (1MB/10min or 50GB/yr) -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Protocol extensions
On 2011 December 21 Wednesday, Christian Decker wrote: Supernodes will be those nodes that verify all transactions and make them available to miners. Since miners will become more and more specialized these supernodes are likely to be owned by the miners themself. To be a miner either you need to verify all the transactions you include (otherwise others might be able to find an error in your block and thus drop it) or have someone that verifies them for you. In the end I think we'll end up with a hierarchical network, with the miners/supernodes tighly interconnected at the top and the lightweight clients that simply verify transactions (or their inputs to be precise) that are destined for them at the bottom. A thought occurred to me. We already run a decentralised system, but it's done by making everyone duplicate all other work. There is no fundamental reason why all work needs to be duplicated though. What about this: every node randomly chooses whether to verify any particular transaction. If we assume the network is large and the random factor is correctly chosen, then we can still guarantee that every transaction is verified. Then, we simply add a protocol message that is a negative-announce transaction. That is to say, we give nodes a way of telling other nodes that they think a transaction is invalid. The other nodes are then free to verify _that_ assertion and forward the negative-announce. Miners can then listen for negative-announcements and use them to decide were to dedicate their verification efforts. They then don't need to verify all (or perhaps even any) transactions themselves and can dedicate their processing power to mining. (I've actually mentioned this idea before, but that time I was using it as a double-spend prevention method). Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
