📅 Original date posted:2011-12-22
🗒️ Summary of this message: Bitcoin's 1MB/10min limit will cause scalability issues. Trusted supernodes or hash space partitioning are options for scalability, but supernodes break P2P features.
📝 Original message: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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Michael Grønager [ARCHIVE] /
npub15f…xlq6h
2023-06-07 02:51:01
in reply to nevent1q…nsy6
Author Public Key
npub15fmnxm546tg2sv0l7elusrvqsgezdzdg3m0flpml5fr2qf3f5slskxlq6hPublished at
2023-06-07 02:51:01Event JSON
{
"id": "d66010b023b25701a779a56effce11530f9d94481fae8316aebb1fffeba9df90",
"pubkey": "a277336e95d2d0a831fff67fc80d8082322689a88ede9f877fa246a02629a43f",
"created_at": 1686106261,
"kind": 1,
"tags": [
[
"e",
"4af0205fae641367dcfd78e02a7a0b6f75f880a1f702affe5d70f7b792eb8207",
"",
"root"
],
[
"e",
"d58f3394fb283a7606139b8a065f6e379ae5c9138b2d89b26a67b2a2612ee8d0",
"",
"reply"
],
[
"p",
"3900ae5aebfcedc10896ff09261ba18b16c6812fe8d8bea34333d56fdb4826d0"
]
],
"content": "📅 Original date posted:2011-12-22\n🗒️ Summary of this message: Bitcoin's 1MB/10min limit will cause scalability issues. Trusted supernodes or hash space partitioning are options for scalability, but supernodes break P2P features.\n📝 Original message:Agree, but even before that, we will meet problems of the current 1MB/10min limit.\n\nThe 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. \n\nCheers,\n\nM\n\nOn 21/12/2011, at 18:17, Jordan Mack wrote:\n\n\u003e I think it would be a lot more than that. According to the Scalability \n\u003e page (https://en.bitcoin.it/wiki/Scalability) if Bitcoin took over all \n\u003e credit card transactions, that would be about 1.14GB per block. I \n\u003e believe that is 58.5PB per year. (6*24*365*1.14/1024) This would also \n\u003e mean the distribution of 2MB of block data per second, which doesn't \n\u003e include broadcast overhead.\n\u003e \n\u003e On 12/21/2011 12:50 AM, Michael Grønager wrote:\n\u003e\u003e when bitcoin takes over all credit card transactions (!), and even before that,\n\u003e\u003e we will meet a scalability problem. The blockchain will grow rapidly,\n\u003e\u003e (1MB/10min or 50GB/yr)\n\u003e \n\u003e ------------------------------------------------------------------------------\n\u003e Write once. Port to many.\n\u003e Get the SDK and tools to simplify cross-platform app development. Create \n\u003e new or port existing apps to sell to consumers worldwide. Explore the \n\u003e Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join\n\u003e http://p.sf.net/sfu/intel-appdev\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development",
"sig": "7a6fbd6582bf3b38efea2915bba88cbf68f5a9d8171794847962ea4ac2c8421d1ac75f353b31c27e42c6556e74897650d8e643b93a867c7aed7e1c84c3298021"
}