📅 Original date posted:2016-12-10
📝 Original message:On Mon, Dec 5, 2016 at 7:27 AM, t. khan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Put another way: let’s stop thinking about what the max block size should
> be and start thinking about how full we want the average block to be
> regardless of size. Over the last year, we’ve had averages of 75% or
> higher, so aiming for 75% full seems reasonable, hence naming this concept
> ‘Block75’.
>
That's effectively making the blocksize limit completely uncapped and only
preventing spikes, and even in the case of spikes it doesn't differentiate
between 'real' traffic and low value spam attacks. It suffers from the same
fundamental problems as bitcoin unlimited: There are in the end no
transaction fees, and inevitably some miners will want to impose some cap
on block size for practical purposes, resulting in a fork.
Difficulty adjustment works because there's a clear goal of having a
certain rate of making new blocks. Without a target to attempt automatic
adjustment makes no sense.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161210/01c100f5/attachment.html>;
Bram Cohen [ARCHIVE] /
npub1ld…t8ur6
2023-06-07 17:54:52
in reply to nevent1q…0vuw
Author Public Key
npub1ldcq03p2qe58u0xnlwa35wchjuhz49y6ueu5ghmtjetez9xstnvsmt8ur6Published at
2023-06-07 17:54:52Event JSON
{
"id": "670eac3346f736c19083a3eac13ff643c1aa9d357b18f14c9f0a6fff2c2660bf",
"pubkey": "fb7007c42a06687e3cd3fbbb1a3b17972e2a949ae679445f6b96579114d05cd9",
"created_at": 1686160492,
"kind": 1,
"tags": [
[
"e",
"93f229f84c7a0d580081719bdeab8a0791a31bea972b61b4a96af898141b5a6b",
"",
"root"
],
[
"e",
"a0b009ec828317b2f493d05aebb90964e37fa65c3aa06fe92a67c4a5d3e7f781",
"",
"reply"
],
[
"p",
"dc329a02c970aabf03b87185ef51c86afe4586fe3a148508af898af3fabc56a3"
]
],
"content": "📅 Original date posted:2016-12-10\n📝 Original message:On Mon, Dec 5, 2016 at 7:27 AM, t. khan via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e\n\u003e Put another way: let’s stop thinking about what the max block size should\n\u003e be and start thinking about how full we want the average block to be\n\u003e regardless of size. Over the last year, we’ve had averages of 75% or\n\u003e higher, so aiming for 75% full seems reasonable, hence naming this concept\n\u003e ‘Block75’.\n\u003e\n\nThat's effectively making the blocksize limit completely uncapped and only\npreventing spikes, and even in the case of spikes it doesn't differentiate\nbetween 'real' traffic and low value spam attacks. It suffers from the same\nfundamental problems as bitcoin unlimited: There are in the end no\ntransaction fees, and inevitably some miners will want to impose some cap\non block size for practical purposes, resulting in a fork.\n\nDifficulty adjustment works because there's a clear goal of having a\ncertain rate of making new blocks. Without a target to attempt automatic\nadjustment makes no sense.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161210/01c100f5/attachment.html\u003e",
"sig": "663a45e7d57e38c618b5799145f432c805652fdf0b6549b9a34cf9487450c8d0da7a574cbe7fa7f786e649b4d325f81f8569f1b541d91ea962184e42bfe297e6"
}