What is Nostr?
Jorge Timón [ARCHIVE] /
npub1fx9…l2d8
2023-06-07 15:48:00
in reply to nevent1q…axac

Jorge Timón [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-21 📝 Original message:On Thu, Aug 20, 2015 at ...

📅 Original date posted:2015-08-21
📝 Original message:On Thu, Aug 20, 2015 at 12:23 PM, Milly Bitcoin via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>> For the 73th time or so this month on this list:
>>
>> The maximum block size consensus rule limits mining centralization
>> (which is currently pretty bad).
>
>
> Instead of posting all these messages with bald claims why don't you work on
> a decentralization metric which you can point to?

Please start with the centralization metrics we both agree are
necessary instead of keeping insulting me publicly and privately.

> (instead of trying to
> claim people don't understand things which is clearly not the case, You are
> just attacking people you don't agree with).

I'm not inventing this, he recently said so himself publicly on this
mailing list:

"I don't believe that the maximum block size has much at all to do with
mining centralization"

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/009960.html

It is therefore not surprising that non-developers and developers with
less experience in Bitcoin than Gavin have similar misunderstandings.

That claim seems in contradiction with his earlier analysis:
http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners

"I ran some simulations, and if blocks take 20 seconds to propagate, a
network with a miner that has 30% of the hashing power will get 30.3%
of the blocks."

That's why I was surprised when he denied the relation between the
consensus maximum size and mining centralization, but hey, people
change their minds and that's completely fine. I change my mind about
many things quite often myself. For example, I will change my mind
about not touching the maximum blocksize consensus rule as soon as I
see some data that convinces that the proposed sizes are not very
risky.
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8