📅 Original date posted:2015-05-25
📝 Original message:I wouldn't say same trade-off because you need the whole 20mb block before you can start to use it where as a 1mb block can be used quicker thus transactions found in tge block quicker etc. As for tge higher rate of orphans, I think this would be complimented by a faster correction rate, so if you're pumping out blocks at a rate of 1 per minute, if we get a fork and the next block comes in 10 minutes and is the decider, it took 10 minutes to determine which block is the orphan. But at a rate of 1 block per 1 minute then it only takes 1 minute to resolve the orphan (obviously this is very simplified) so I'm not so sure that orphan rate is a big issue here. Indeed you would need to draw upon more confirmations for easier block creation but surely that is not an issue?
Why would sync time be longer as opposed to 20mb blocks?
________________________________
From: gabe appleton<mailto:gappleto97 at gmail.com>
Sent: 26/05/2015 12:41 PM
To: Thy Shizzle<mailto:thyshizzle at outlook.com>
Cc: Jim Phillips<mailto:jim at ergophobia.org>; Mike Hearn<mailto:mike at plan99.net>; Bitcoin Dev<mailto:bitcoin-development at lists.sourceforge.net>
Subject: Re: [Bitcoin-development] No Bitcoin For You
But don't you see the same trade-off in the end there? You're still
propagating the same amount of data over the same amount of time, so unless
I misunderstand, the costs of such a move should be approximately the same,
just in different areas. The risks as I understand are as follows:
20MB:
1. Longer per-block propagation (eventually)
2. Longer processing time (eventually)
3. Longer sync time
1 Minute:
1. Weaker individual confirmations (approx. equal per confirmation*time)
2. Higher orphan rate (immediately)
3. Longer sync time
That risk-set makes me want a middle-ground approach. Something where the
immediate consequences aren't all that strong, and where we have some idea
of what to do in the future. Is there any chance we can get decent network
simulations at various configurations (5MB/4min, etc)? Perhaps
re-appropriate the testnet?
On Mon, May 25, 2015 at 10:30 PM, Thy Shizzle <thyshizzle at outlook.com>
wrote:
> Nah don't make blocks 20mb, then you are slowing down block propagation
> and blowing out conf tikes as a result. Just decrease the time it takes to
> make a 1mb block, then you still see the same propagation times today and
> just increase the transaction throughput.
> ------------------------------
> From: Jim Phillips <jim at ergophobia.org>
> Sent: 26/05/2015 12:27 PM
> To: Mike Hearn <mike at plan99.net>
> Cc: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
> Subject: Re: [Bitcoin-development] No Bitcoin For You
>
>
> On Mon, May 25, 2015 at 1:36 PM, Mike Hearn <mike at plan99.net> wrote:
>
> This meme about datacenter-sized nodes has to die. The Bitcoin wiki is
> down right now, but I showed years ago that you could keep up with VISA on
> a single well specced server with today's technology. Only people living in
> a dreamworld think that Bitcoin might actually have to match that level of
> transaction demand with today's hardware. As noted previously, "too many
> users" is simply not a problem Bitcoin has .... and may never have!
>
>
> ... And will certainly NEVER have if we can't solve the capacity problem
> SOON.
>
> In a former life, I was a capacity planner for Bank of America's
> mid-range server group. We had one hard and fast rule. When you are
> typically exceeding 75% of capacity on a given metric, it's time to expand
> capacity. Period. You don't do silly things like adjusting the business
> model to disincentivize use. Unless there's some flaw in the system and
> it's leaking resources, if usage has increased to the point where you are
> at or near the limits of capacity, you expand capacity. It's as simple as
> that, and I've found that same rule fits quite well in a number of systems.
>
> In Bitcoin, we're not leaking resources. There's no flaw. The system is
> performing as intended. Usage is increasing because it works so well, and
> there is huge potential for future growth as we identify more uses and
> attract more users. There might be a few technical things we can do to
> reduce consumption, but the metric we're concerned with right now is how
> many transactions we can fit in a block. We've broken through the 75%
> marker and are regularly bumping up against the 100% limit.
>
> It is time to stop debating this and take action to expand capacity. The
> only questions that should remain are how much capacity do we add, and how
> soon can we do it. Given that most existing computer systems and networks
> can easily handle 20MB blocks every 10 minutes, and given that that will
> increase capacity 20-fold, I can't think of a single reason why we can't go
> to 20MB as soon as humanly possible. And in a few years, when the average
> block size is over 15MB, we bump it up again to as high as we can go then
> without pushing typical computers or networks beyond their capacity. We can
> worry about ways to slow down growth without affecting the usefulness of
> Bitcoin as we get closer to the hard technical limits on our capacity.
>
> And you know what else? If miners need higher fees to accommodate the
> costs of bigger blocks, they can configure their nodes to only mine
> transactions with higher fees.. Let the miners decide how to charge enough
> to pay for their costs. We don't need to cripple the network just for them.
>
> --
> *James G. Phillips IV*
> <https://plus.google.com/u/0/113107039501292625391/posts>;
>
> *"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
> -- David Ogilvy *
>
> *This message was created with 100% recycled electrons. Please think
> twice before printing.*
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150526/f03594e9/attachment.html>;
Thy Shizzle [ARCHIVE] /
npub183…eeux6
2023-06-07 15:35:20
in reply to nevent1q…mjvm
Author Public Key
npub1836zrd49hyr9aad6tvgng94uyy4r3xjcs5lkdza0ld9g5p8jkd0speeux6Published at
2023-06-07 15:35:20Event JSON
{
"id": "46b5c3dca6c725f79842c2e5c7f5e8028b4c5f7cb003d3d966e37af99faafe3b",
"pubkey": "3c7421b6a5b9065ef5ba5b113416bc212a389a58853f668baffb4a8a04f2b35f",
"created_at": 1686152120,
"kind": 1,
"tags": [
[
"e",
"e038424a0880fdf88b11436b26b240dbde656936eaeaf91ae69915695ced453d",
"",
"root"
],
[
"e",
"63f6cd93d83e9a0aadbbcf5ddcd5e5d0933630ba064b5a408f4bd2485cba48e9",
"",
"reply"
],
[
"p",
"8b64be8dfcb19730f674fdb0169f772317a629f8dd3b8d925d342a0273bbb37b"
]
],
"content": "📅 Original date posted:2015-05-25\n📝 Original message:I wouldn't say same trade-off because you need the whole 20mb block before you can start to use it where as a 1mb block can be used quicker thus transactions found in tge block quicker etc. As for tge higher rate of orphans, I think this would be complimented by a faster correction rate, so if you're pumping out blocks at a rate of 1 per minute, if we get a fork and the next block comes in 10 minutes and is the decider, it took 10 minutes to determine which block is the orphan. But at a rate of 1 block per 1 minute then it only takes 1 minute to resolve the orphan (obviously this is very simplified) so I'm not so sure that orphan rate is a big issue here. Indeed you would need to draw upon more confirmations for easier block creation but surely that is not an issue?\n\nWhy would sync time be longer as opposed to 20mb blocks?\n________________________________\nFrom: gabe appleton\u003cmailto:gappleto97 at gmail.com\u003e\nSent: 26/05/2015 12:41 PM\nTo: Thy Shizzle\u003cmailto:thyshizzle at outlook.com\u003e\nCc: Jim Phillips\u003cmailto:jim at ergophobia.org\u003e; Mike Hearn\u003cmailto:mike at plan99.net\u003e; Bitcoin Dev\u003cmailto:bitcoin-development at lists.sourceforge.net\u003e\nSubject: Re: [Bitcoin-development] No Bitcoin For You\n\nBut don't you see the same trade-off in the end there? You're still\npropagating the same amount of data over the same amount of time, so unless\nI misunderstand, the costs of such a move should be approximately the same,\njust in different areas. The risks as I understand are as follows:\n\n20MB:\n\n\n 1. Longer per-block propagation (eventually)\n 2. Longer processing time (eventually)\n 3. Longer sync time\n\n1 Minute:\n\n 1. Weaker individual confirmations (approx. equal per confirmation*time)\n 2. Higher orphan rate (immediately)\n 3. Longer sync time\n\nThat risk-set makes me want a middle-ground approach. Something where the\nimmediate consequences aren't all that strong, and where we have some idea\nof what to do in the future. Is there any chance we can get decent network\nsimulations at various configurations (5MB/4min, etc)? Perhaps\nre-appropriate the testnet?\n\nOn Mon, May 25, 2015 at 10:30 PM, Thy Shizzle \u003cthyshizzle at outlook.com\u003e\nwrote:\n\n\u003e Nah don't make blocks 20mb, then you are slowing down block propagation\n\u003e and blowing out conf tikes as a result. Just decrease the time it takes to\n\u003e make a 1mb block, then you still see the same propagation times today and\n\u003e just increase the transaction throughput.\n\u003e ------------------------------\n\u003e From: Jim Phillips \u003cjim at ergophobia.org\u003e\n\u003e Sent: 26/05/2015 12:27 PM\n\u003e To: Mike Hearn \u003cmike at plan99.net\u003e\n\u003e Cc: Bitcoin Dev \u003cbitcoin-development at lists.sourceforge.net\u003e\n\u003e Subject: Re: [Bitcoin-development] No Bitcoin For You\n\u003e\n\u003e\n\u003e On Mon, May 25, 2015 at 1:36 PM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e\n\u003e This meme about datacenter-sized nodes has to die. The Bitcoin wiki is\n\u003e down right now, but I showed years ago that you could keep up with VISA on\n\u003e a single well specced server with today's technology. Only people living in\n\u003e a dreamworld think that Bitcoin might actually have to match that level of\n\u003e transaction demand with today's hardware. As noted previously, \"too many\n\u003e users\" is simply not a problem Bitcoin has .... and may never have!\n\u003e\n\u003e\n\u003e ... And will certainly NEVER have if we can't solve the capacity problem\n\u003e SOON.\n\u003e\n\u003e In a former life, I was a capacity planner for Bank of America's\n\u003e mid-range server group. We had one hard and fast rule. When you are\n\u003e typically exceeding 75% of capacity on a given metric, it's time to expand\n\u003e capacity. Period. You don't do silly things like adjusting the business\n\u003e model to disincentivize use. Unless there's some flaw in the system and\n\u003e it's leaking resources, if usage has increased to the point where you are\n\u003e at or near the limits of capacity, you expand capacity. It's as simple as\n\u003e that, and I've found that same rule fits quite well in a number of systems.\n\u003e\n\u003e In Bitcoin, we're not leaking resources. There's no flaw. The system is\n\u003e performing as intended. Usage is increasing because it works so well, and\n\u003e there is huge potential for future growth as we identify more uses and\n\u003e attract more users. There might be a few technical things we can do to\n\u003e reduce consumption, but the metric we're concerned with right now is how\n\u003e many transactions we can fit in a block. We've broken through the 75%\n\u003e marker and are regularly bumping up against the 100% limit.\n\u003e\n\u003e It is time to stop debating this and take action to expand capacity. The\n\u003e only questions that should remain are how much capacity do we add, and how\n\u003e soon can we do it. Given that most existing computer systems and networks\n\u003e can easily handle 20MB blocks every 10 minutes, and given that that will\n\u003e increase capacity 20-fold, I can't think of a single reason why we can't go\n\u003e to 20MB as soon as humanly possible. And in a few years, when the average\n\u003e block size is over 15MB, we bump it up again to as high as we can go then\n\u003e without pushing typical computers or networks beyond their capacity. We can\n\u003e worry about ways to slow down growth without affecting the usefulness of\n\u003e Bitcoin as we get closer to the hard technical limits on our capacity.\n\u003e\n\u003e And you know what else? If miners need higher fees to accommodate the\n\u003e costs of bigger blocks, they can configure their nodes to only mine\n\u003e transactions with higher fees.. Let the miners decide how to charge enough\n\u003e to pay for their costs. We don't need to cripple the network just for them.\n\u003e\n\u003e --\n\u003e *James G. Phillips IV*\n\u003e \u003chttps://plus.google.com/u/0/113107039501292625391/posts\u003e\n\u003e\n\u003e *\"Don't bunt. Aim out of the ball park. Aim for the company of immortals.\"\n\u003e -- David Ogilvy *\n\u003e\n\u003e *This message was created with 100% recycled electrons. Please think\n\u003e twice before printing.*\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e One dashboard for servers and applications across Physical-Virtual-Cloud\n\u003e Widest out-of-the-box monitoring support with 50+ applications\n\u003e Performance metrics, stats and reports that give you Actionable Insights\n\u003e Deep dive visibility with transaction tracing using APM Insight.\n\u003e http://ad.doubleclick.net/ddm/clk/290420510;117567292;y\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\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150526/f03594e9/attachment.html\u003e",
"sig": "70d9fc599d15e10c1b599ed0d2e76bc7ca894ec1ef513b7a77c4ffaddf5683db9adb1e44ad5774e6276b7f2c2119e73e0f9762b3330a70987b0801d17b75d80c"
}