📅 Original date posted:2016-12-10
📝 Original message:Agreed, the clear goal of 10 minutes per block is why the difficulty
adjustment works well. Blocks averaging 75% full is the clear goal of the
described method. That's the target to attempt.
Under Block75, there will still be full blocks. There will still be
transaction fees and a fee market. The fees will be lower than they are now
of course.
Hardcoding a cap will inevitably become a roadblock (again), and we'll be
back in the same position as we are now. Permanent solutions are preferred.
On Sat, Dec 10, 2016 at 6:12 PM, Bram Cohen <bram at bittorrent.com> wrote:
> 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/fff14476/attachment.html>;
t. khan [ARCHIVE] /
npub1lu…hjqch
2023-06-07 17:54:53
in reply to nevent1q…g7dn
Author Public Key
npub1lupuse8cysuanxcpq8h4d32359xxzedzjj83rmwv4yr9qxfmhtzqghjqchPublished at
2023-06-07 17:54:53Event JSON
{
"id": "43dddb4640a6f8d67f55bd8fd4469374acb812a7985f605caca9aab0923e636a",
"pubkey": "ff03c864f82439d99b0101ef56c551a14c6165a2948f11edcca90650193bbac4",
"created_at": 1686160493,
"kind": 1,
"tags": [
[
"e",
"93f229f84c7a0d580081719bdeab8a0791a31bea972b61b4a96af898141b5a6b",
"",
"root"
],
[
"e",
"670eac3346f736c19083a3eac13ff643c1aa9d357b18f14c9f0a6fff2c2660bf",
"",
"reply"
],
[
"p",
"fb7007c42a06687e3cd3fbbb1a3b17972e2a949ae679445f6b96579114d05cd9"
]
],
"content": "📅 Original date posted:2016-12-10\n📝 Original message:Agreed, the clear goal of 10 minutes per block is why the difficulty\nadjustment works well. Blocks averaging 75% full is the clear goal of the\ndescribed method. That's the target to attempt.\n\nUnder Block75, there will still be full blocks. There will still be\ntransaction fees and a fee market. The fees will be lower than they are now\nof course.\n\nHardcoding a cap will inevitably become a roadblock (again), and we'll be\nback in the same position as we are now. Permanent solutions are preferred.\n\nOn Sat, Dec 10, 2016 at 6:12 PM, Bram Cohen \u003cbram at bittorrent.com\u003e wrote:\n\n\u003e On Mon, Dec 5, 2016 at 7:27 AM, t. khan via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e\n\u003e\u003e Put another way: let’s stop thinking about what the max block size should\n\u003e\u003e be and start thinking about how full we want the average block to be\n\u003e\u003e regardless of size. Over the last year, we’ve had averages of 75% or\n\u003e\u003e higher, so aiming for 75% full seems reasonable, hence naming this concept\n\u003e\u003e ‘Block75’.\n\u003e\u003e\n\u003e\n\u003e That's effectively making the blocksize limit completely uncapped and only\n\u003e preventing spikes, and even in the case of spikes it doesn't differentiate\n\u003e between 'real' traffic and low value spam attacks. It suffers from the same\n\u003e fundamental problems as bitcoin unlimited: There are in the end no\n\u003e transaction fees, and inevitably some miners will want to impose some cap\n\u003e on block size for practical purposes, resulting in a fork.\n\u003e\n\u003e Difficulty adjustment works because there's a clear goal of having a\n\u003e certain rate of making new blocks. Without a target to attempt automatic\n\u003e adjustment makes no sense.\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161210/fff14476/attachment.html\u003e",
"sig": "da08e07de85b175f7c82230408061ee80ee0a9755ad5a1f9a58e8bdf968d5821671a36c983b567abb92c0b07db80e7dff663fd6b9b24e6d4191a32942595bb52"
}