📅 Original date posted:2015-05-08
📝 Original message:Actually I believe that side chains and off-main-chain transactions will be
a critical part for the overall scalability of the network. I was actually
trying to make the point that (insert some huge block size here) will be
needed to even accommodate the reduced traffic.
I believe that it is definitely over 20MB. If it was determined to be 100
MB ten years from now, that wouldn't surprise me.
Sent from my overpriced smartphone
On May 8, 2015 1:17 PM, "Andrew" <onelineproof at gmail.com> wrote:
>
>
> On Fri, May 8, 2015 at 2:59 PM, Alan Reiner <etotheipi at gmail.com> wrote:
>
>>
>> This isn't about "everyone's coffee". This is about an absolute minimum
>> amount of participation by people who wish to use the network. If our
>> goal is really for bitcoin to really be a global, open transaction network
>> that makes money fluid, then 7tps is already a failure. If even 5% of the
>> world (350M people) was using the network for 1 tx per month (perhaps to
>> open payment channels, or shift money between side chains), we'll be above
>> 100 tps. And that doesn't include all the non-individuals (organizations)
>> that want to use it.
>>
>
>> The goals of "a global transaction network" and "everyone must be able to
>> run a full node with their $200 dell laptop" are not compatible. We need
>> to accept that a global transaction system cannot be fully/constantly
>> audited by everyone and their mother. The important feature of the network
>> is that it is open and anyone *can* get the history and verify it. But not
>> everyone is required to. Trying to promote a system wher000e the history
>> can be forever handled by a low-end PC is already falling out of reach,
>> even with our miniscule 7 tps. Clinging to that goal needlessly limits the
>> capability for the network to scale to be a useful global payments system
>>
>
> These are good points and got me thinking (but I think you're wrong). If
> we really want each of the 10 billion people soon using bitcoin once per
> month, that will require 500MB blocks. That's about 2 TB per month. And if
> you relay it to 4 peers, it's 10 TB per month. Which I suppose is doable
> for a home desktop, so you can just run a pruned full node with all
> transactions from the past month. But how do you sync all those
> transactions if you've never done this before or it's been a while since
> you did? I think it currently takes at least 3 hours to fully sync 30 GB of
> transactions. So 2 TB will take 8 days, then you take a bit more time to
> sync the days that passed while you were syncing. So that's doable, but at
> a certain point, like 10 TB per month (still only 5 transactions per month
> per person), you will need 41 days to sync that month, so you will never
> catch up. So I think in order to keep the very important property of anyone
> being able to start clean and verify the thing, then we need to think of
> bitcoin as a system that does transactions for a large number of users at
> once in one transaction, and not a system where each person will make a
> ~monthly transaction on. We need to therefore rely on sidechains,
> treechains, lightning channels, etc...
>
> I'm not a bitcoin wizard and this is just my second post on this mailing
> list, so I may be missing something. So please someone, correct me if I'm
> wrong.
>
>>
>>
>>
>> On 05/07/2015 03:54 PM, Jeff Garzik wrote:
>>
>> On Thu, May 7, 2015 at 3:31 PM, Alan Reiner <etotheipi at gmail.com> wrote:
>>
>>
>>> (2) Leveraging fee pressure at 1MB to solve the problem is actually
>>> really a bad idea. It's really bad while Bitcoin is still growing, and
>>> relying on fee pressure at 1 MB severely impacts attractiveness and
>>> adoption potential of Bitcoin (due to high fees and unreliability). But
>>> more importantly, it ignores the fact that for a 7 tps is pathetic for a
>>> global transaction system. It is a couple orders of magnitude too low for
>>> any meaningful commercial activity to occur. If we continue with a cap of
>>> 7 tps forever, Bitcoin *will* fail. Or at best, it will fail to be
>>> useful for the vast majority of the world (which probably leads to
>>> failure). We shouldn't be talking about fee pressure until we hit 700 tps,
>>> which is probably still too low.
>>>
>> [...]
>>
>> 1) Agree that 7 tps is too low
>>
>> 2) Where do you want to go? Should bitcoin scale up to handle all the
>> world's coffees?
>>
>> This is hugely unrealistic. 700 tps is 100MB blocks, 14.4 GB/day --
>> just for a single feed. If you include relaying to multiple nodes, plus
>> serving 500 million SPV clients en grosse, who has the capacity to run such
>> a node? By the time we get to fee pressure, in your scenario, our network
>> node count is tiny and highly centralized.
>>
>> 3) In RE "fee pressure" -- Do you see the moral hazard to a software-run
>> system? It is an intentional, human decision to flood the market with
>> supply, thereby altering the economics, forcing fees to remain low in the
>> hopes of achieving adoption. I'm pro-bitcoin and obviously want to see
>> bitcoin adoption - but I don't want to sacrifice every decentralized
>> principle and become a central banker in order to get there.
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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 at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> --
> PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/4f232d91/attachment.html>;
Alan Reiner [ARCHIVE] /
npub1sm…mnq7h
2023-06-07 15:33:21
in reply to nevent1q…u5sz
Author Public Key
npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7hPublished at
2023-06-07 15:33:21Event JSON
{
"id": "b0cf686788dd8820ff5c6cc8c4e058e6ea24d22ed92bb14b13bbab98ccf12e65",
"pubkey": "86f42bcb76a431c128b596c36714ae73a42cae48706a9e5513d716043447f5ec",
"created_at": 1686152001,
"kind": 1,
"tags": [
[
"e",
"0def597b074aa190bf159e12f9433ea74d157ee52321b38d195ba644ad5c177f",
"",
"root"
],
[
"e",
"a9011867f33295aeb1695164edf59c48e472f4da7ed34c48567a708e2472d199",
"",
"reply"
],
[
"p",
"f9ca566c8a15d0510cba9326659e9d235ad5681c8eb6f5594af50b92b640fb66"
]
],
"content": "📅 Original date posted:2015-05-08\n📝 Original message:Actually I believe that side chains and off-main-chain transactions will be\na critical part for the overall scalability of the network. I was actually\ntrying to make the point that (insert some huge block size here) will be\nneeded to even accommodate the reduced traffic.\n\nI believe that it is definitely over 20MB. If it was determined to be 100\nMB ten years from now, that wouldn't surprise me.\n\nSent from my overpriced smartphone\nOn May 8, 2015 1:17 PM, \"Andrew\" \u003conelineproof at gmail.com\u003e wrote:\n\n\u003e\n\u003e\n\u003e On Fri, May 8, 2015 at 2:59 PM, Alan Reiner \u003cetotheipi at gmail.com\u003e wrote:\n\u003e\n\u003e\u003e\n\u003e\u003e This isn't about \"everyone's coffee\". This is about an absolute minimum\n\u003e\u003e amount of participation by people who wish to use the network. If our\n\u003e\u003e goal is really for bitcoin to really be a global, open transaction network\n\u003e\u003e that makes money fluid, then 7tps is already a failure. If even 5% of the\n\u003e\u003e world (350M people) was using the network for 1 tx per month (perhaps to\n\u003e\u003e open payment channels, or shift money between side chains), we'll be above\n\u003e\u003e 100 tps. And that doesn't include all the non-individuals (organizations)\n\u003e\u003e that want to use it.\n\u003e\u003e\n\u003e\n\u003e\u003e The goals of \"a global transaction network\" and \"everyone must be able to\n\u003e\u003e run a full node with their $200 dell laptop\" are not compatible. We need\n\u003e\u003e to accept that a global transaction system cannot be fully/constantly\n\u003e\u003e audited by everyone and their mother. The important feature of the network\n\u003e\u003e is that it is open and anyone *can* get the history and verify it. But not\n\u003e\u003e everyone is required to. Trying to promote a system wher000e the history\n\u003e\u003e can be forever handled by a low-end PC is already falling out of reach,\n\u003e\u003e even with our miniscule 7 tps. Clinging to that goal needlessly limits the\n\u003e\u003e capability for the network to scale to be a useful global payments system\n\u003e\u003e\n\u003e\n\u003e These are good points and got me thinking (but I think you're wrong). If\n\u003e we really want each of the 10 billion people soon using bitcoin once per\n\u003e month, that will require 500MB blocks. That's about 2 TB per month. And if\n\u003e you relay it to 4 peers, it's 10 TB per month. Which I suppose is doable\n\u003e for a home desktop, so you can just run a pruned full node with all\n\u003e transactions from the past month. But how do you sync all those\n\u003e transactions if you've never done this before or it's been a while since\n\u003e you did? I think it currently takes at least 3 hours to fully sync 30 GB of\n\u003e transactions. So 2 TB will take 8 days, then you take a bit more time to\n\u003e sync the days that passed while you were syncing. So that's doable, but at\n\u003e a certain point, like 10 TB per month (still only 5 transactions per month\n\u003e per person), you will need 41 days to sync that month, so you will never\n\u003e catch up. So I think in order to keep the very important property of anyone\n\u003e being able to start clean and verify the thing, then we need to think of\n\u003e bitcoin as a system that does transactions for a large number of users at\n\u003e once in one transaction, and not a system where each person will make a\n\u003e ~monthly transaction on. We need to therefore rely on sidechains,\n\u003e treechains, lightning channels, etc...\n\u003e\n\u003e I'm not a bitcoin wizard and this is just my second post on this mailing\n\u003e list, so I may be missing something. So please someone, correct me if I'm\n\u003e wrong.\n\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On 05/07/2015 03:54 PM, Jeff Garzik wrote:\n\u003e\u003e\n\u003e\u003e On Thu, May 7, 2015 at 3:31 PM, Alan Reiner \u003cetotheipi at gmail.com\u003e wrote:\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\u003e (2) Leveraging fee pressure at 1MB to solve the problem is actually\n\u003e\u003e\u003e really a bad idea. It's really bad while Bitcoin is still growing, and\n\u003e\u003e\u003e relying on fee pressure at 1 MB severely impacts attractiveness and\n\u003e\u003e\u003e adoption potential of Bitcoin (due to high fees and unreliability). But\n\u003e\u003e\u003e more importantly, it ignores the fact that for a 7 tps is pathetic for a\n\u003e\u003e\u003e global transaction system. It is a couple orders of magnitude too low for\n\u003e\u003e\u003e any meaningful commercial activity to occur. If we continue with a cap of\n\u003e\u003e\u003e 7 tps forever, Bitcoin *will* fail. Or at best, it will fail to be\n\u003e\u003e\u003e useful for the vast majority of the world (which probably leads to\n\u003e\u003e\u003e failure). We shouldn't be talking about fee pressure until we hit 700 tps,\n\u003e\u003e\u003e which is probably still too low.\n\u003e\u003e\u003e\n\u003e\u003e [...]\n\u003e\u003e\n\u003e\u003e 1) Agree that 7 tps is too low\n\u003e\u003e\n\u003e\u003e 2) Where do you want to go? Should bitcoin scale up to handle all the\n\u003e\u003e world's coffees?\n\u003e\u003e\n\u003e\u003e This is hugely unrealistic. 700 tps is 100MB blocks, 14.4 GB/day --\n\u003e\u003e just for a single feed. If you include relaying to multiple nodes, plus\n\u003e\u003e serving 500 million SPV clients en grosse, who has the capacity to run such\n\u003e\u003e a node? By the time we get to fee pressure, in your scenario, our network\n\u003e\u003e node count is tiny and highly centralized.\n\u003e\u003e\n\u003e\u003e 3) In RE \"fee pressure\" -- Do you see the moral hazard to a software-run\n\u003e\u003e system? It is an intentional, human decision to flood the market with\n\u003e\u003e supply, thereby altering the economics, forcing fees to remain low in the\n\u003e\u003e hopes of achieving adoption. I'm pro-bitcoin and obviously want to see\n\u003e\u003e bitcoin adoption - but I don't want to sacrifice every decentralized\n\u003e\u003e principle and become a central banker in order to get there.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e One dashboard for servers and applications across Physical-Virtual-Cloud\n\u003e\u003e Widest out-of-the-box monitoring support with 50+ applications\n\u003e\u003e Performance metrics, stats and reports that give you Actionable Insights\n\u003e\u003e Deep dive visibility with transaction tracing using APM Insight.\n\u003e\u003e http://ad.doubleclick.net/ddm/clk/290420510;117567292;y\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\n\u003e\u003e\n\u003e\n\u003e\n\u003e --\n\u003e PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/4f232d91/attachment.html\u003e",
"sig": "157f1e4d90273a42093e1943e19e04f813384a0c4fe1300483ed0682b09a14114f932f52019ae630fc0ada17d482061b81ff15e4d2ac75342db92afc2ffac0f5"
}