📅 Original date posted:2015-08-11
📝 Original message:On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hitting the limit in and of itself is not necessarily a bad thing. The
> question at hand is whether we should constrain that limit below what
> technology is capable of delivering. I'm arguing that not only we should
> not, but that we could not even if we wanted to, since competition will
> deliver capacity for global consensus whether it's in Bitcoin or in some
> other product / fork.
>
The question is not what the technology can deliver. The question is what
price we're willing to pay for that. It is not a boolean "at this size,
things break, and below it, they work". A small constant factor increase
will unlikely break anything in the short term, but it will come with
higher centralization pressure of various forms. There is discussion about
whether these centralization pressures are significant, but citing that
it's artificially constrained under the limit is IMHO a misrepresentation.
It is constrained to aim for a certain balance between utility and risk,
and neither extreme is interesting, while possibly still "working".
Consensus rules are what keeps the system together. You can't simply switch
to new rules on your own, because the rest of the system will end up
ignoring you. These rules are there for a reason. You and I may agree about
whether the 21M limit is necessary, and disagree about whether we need a
block size limit, but we should be extremely careful with change. My
position as Bitcoin Core developer is that we should merge consensus
changes only when they are uncontroversial. Even when you believe a more
invasive change is worth it, others may disagree, and the risk from
disagreement is likely larger than the effect of a small block size
increase by itself: the risk that suddenly every transaction can be spent
twice (once on each side of the fork), the very thing that the block chain
was designed to prevent.
My personal opinion is that we should aim to do a block size increase for
the right reasons. I don't think fear of rising fees or unreliability
should be an issue: if fees are being paid, it means someone is willing to
pay them. If people are doing transactions despite being unreliable, there
must be a use for them. That may mean that some use cases don't fit
anymore, but that is already the case.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/851e0acb/attachment.html>;
Pieter Wuille [ARCHIVE] /
npub1tj…jtl6r
2023-06-07 15:45:52
in reply to nevent1q…r77x
Author Public Key
npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rPublished at
2023-06-07 15:45:52Event JSON
{
"id": "27da5f934e33dadccb7792f6ba4dafc0adb45ca491396541e4173d5751aba378",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686152752,
"kind": 1,
"tags": [
[
"e",
"cf6411bfecea99b0c4ea78e985838b5e3fd62429f4968960ffd260356286401f",
"",
"root"
],
[
"e",
"0be3f86bfa21e0af03ca7b60fc245181a0dbcd0e577d0c9b939593089e0eea2d",
"",
"reply"
],
[
"p",
"88d911f6791fafcd4c24f30c66360e6f43dcea819b8f2942b83bdcb0aa7b454c"
]
],
"content": "📅 Original date posted:2015-08-11\n📝 Original message:On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hitting the limit in and of itself is not necessarily a bad thing. The\n\u003e question at hand is whether we should constrain that limit below what\n\u003e technology is capable of delivering. I'm arguing that not only we should\n\u003e not, but that we could not even if we wanted to, since competition will\n\u003e deliver capacity for global consensus whether it's in Bitcoin or in some\n\u003e other product / fork.\n\u003e\n\nThe question is not what the technology can deliver. The question is what\nprice we're willing to pay for that. It is not a boolean \"at this size,\nthings break, and below it, they work\". A small constant factor increase\nwill unlikely break anything in the short term, but it will come with\nhigher centralization pressure of various forms. There is discussion about\nwhether these centralization pressures are significant, but citing that\nit's artificially constrained under the limit is IMHO a misrepresentation.\nIt is constrained to aim for a certain balance between utility and risk,\nand neither extreme is interesting, while possibly still \"working\".\n\nConsensus rules are what keeps the system together. You can't simply switch\nto new rules on your own, because the rest of the system will end up\nignoring you. These rules are there for a reason. You and I may agree about\nwhether the 21M limit is necessary, and disagree about whether we need a\nblock size limit, but we should be extremely careful with change. My\nposition as Bitcoin Core developer is that we should merge consensus\nchanges only when they are uncontroversial. Even when you believe a more\ninvasive change is worth it, others may disagree, and the risk from\ndisagreement is likely larger than the effect of a small block size\nincrease by itself: the risk that suddenly every transaction can be spent\ntwice (once on each side of the fork), the very thing that the block chain\nwas designed to prevent.\n\nMy personal opinion is that we should aim to do a block size increase for\nthe right reasons. I don't think fear of rising fees or unreliability\nshould be an issue: if fees are being paid, it means someone is willing to\npay them. If people are doing transactions despite being unreliable, there\nmust be a use for them. That may mean that some use cases don't fit\nanymore, but that is already the case.\n\n-- \nPieter\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/851e0acb/attachment.html\u003e",
"sig": "e117016d4b7bf9c664175f0633d78f9078dbd456f30f6b7ac496a3e62b3594be80667ca1f25e79ca180b23662ff59ec316eee9f52e804d3b59f364a739c692a3"
}