Why Nostr? What is Njump?
2023-06-07 15:45:50
in reply to

Jorge Timón [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-11 📝 Original message:On Aug 11, 2015 8:55 PM, ...

📅 Original date posted:2015-08-11
📝 Original message:On Aug 11, 2015 8:55 PM, "Michael Naber" <mickeybob at gmail.com> wrote:
>
> It generally doesn't matter that every node validate your coffee
transaction, and those transactions can and will probably be moved onto
offchain solutions in order to avoid paying the cost of achieving global
consensus. But you still don't get to set the cost of global consensus
artificially. Market forces will ensure that supply will meet demand there,
so if there is demand for access to global consensus, and technology exists
to meet that demand at a cost of one cent per transaction -- or whatever
the technology-limited cost of global consensus happens to be -- then
that's what the market will supply.

Assuming we maintain any block size maximum consensus rule, the market will
adapt to whatever maximum size is imposed by the consensus rules.
For example, with the current demand and the current consensus block size
maximum, the market has settled on a minimum fee of zero satoshis per
transaction. That's why I cannot understand the urgency to rise the maximum
size.

In any case, yhe consensus maximum shouldn't be based on current or
projected demand, only on centralization concerns, which is what the
consensus rule serves for (to limit centralization).
For example, Gavin advocates for 20 MB because he is not worried about how
that could increase centralization because he believes it won't.
I can't agree with that because I believe 20 MB could make mining
centralization (and centralization in general) much worse.

But if I have to chose between 2 "centralization safe" sizes, sure, the
bigger the better, why not.
In my opinion the main source of disagreement is that one: how the maximum
block size limits centralization.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/f89400cf/attachment.html>;
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8