📅 Original date posted:2015-08-11
📝 Original message:Sure, most people probably would be happy with cheaper off-chain systems.
There already are and will probably continue to be more transactions
happening off-chain partly for this very reason. That's not the issue we're
trying to address though: The main chain is the lynch-pin to the whole
system. We've got to do a good job meeting demand that people have for
wanting to utilize the main-chain, or else we'll risk being replaced by
some other main-chain solution that does it better.
On Tue, Aug 11, 2015 at 4:34 PM, Adam Back <adam at cypherspace.org> wrote:
> So if they dont care about decentralisation, they'll be happy using
> cheaper off-chain systems, right?
>
> Adam
>
> On 11 August 2015 at 22:30, Angel Leon <gubatron at gmail.com> wrote:
> > tell that to people in poor countries, or even in first world countries.
> The
> > competitive thing here is a deal breaker for a lot of people who have no
> > clue/don't care for decentralization, they just want to send money from
> A to
> > B, like email.
> >
> > http://twitter.com/gubatron
> >
> > On Tue, Aug 11, 2015 at 5:23 PM, Adam Back via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >> I dont think Bitcoin being cheaper is the main characteristic of
> >> Bitcoin. I think the interesting thing is trustlessness - being able
> >> to transact without relying on third parties.
> >>
> >> Adam
> >>
> >>
> >> On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev
> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> > The only reason why Bitcoin has grown the way it has, and in fact the
> >> > only
> >> > reason why we're all even here on this mailing list talking about
> this,
> >> > is
> >> > because Bitcoin is growing, since it's "better money than other
> money".
> >> > One
> >> > of the key characteristics toward that is Bitcoin being inexpensive to
> >> > transact. If that characteristic is no longer true, then Bitcoin isn't
> >> > going
> >> > to grow, and in fact Bitcoin itself will be replaced by better money
> >> > that is
> >> > less expensive to transfer.
> >> >
> >> > So the importance of this issue cannot be overstated -- it's compete
> or
> >> > die
> >> > for Bitcoin -- because people want to transact with global consensus
> at
> >> > high
> >> > volume, and because technology exists to service that want, then it's
> >> > going
> >> > to be met. This is basic rules of demand and supply. I don't
> necessarily
> >> > disagree with your position on only wanting to support uncontroversial
> >> > commits, but I think it's important to get consensus on the
> criticality
> >> > of
> >> > the block size issue: do you agree, disagree, or not take a side, and
> >> > why?
> >> >
> >> >
> >> > On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille <
> pieter.wuille at gmail.com>
> >> > wrote:
> >> >>
> >> >> 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
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > bitcoin-dev mailing list
> >> > bitcoin-dev at lists.linuxfoundation.org
> >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> >
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/68f2cc6f/attachment-0001.html>;
Michael Naber [ARCHIVE] /
npub13r…cy5l4
2023-06-07 17:33:48
in reply to nevent1q…l90p
Author Public Key
npub13rv3raner7hu6npy7vxxvdswdapae65pnw8jjs4c80wtp2nmg4xq9cy5l4Published at
2023-06-07 17:33:48Event JSON
{
"id": "301a7183e29bb41b701e49a09106c627d6ccfc8834dfa1b6c4f29f462771a33a",
"pubkey": "88d911f6791fafcd4c24f30c66360e6f43dcea819b8f2942b83bdcb0aa7b454c",
"created_at": 1686159228,
"kind": 1,
"tags": [
[
"e",
"0be39125a55b736c93365735a614c6c3adbad06ad3effa6f21e6b42bef7ccb51",
"",
"root"
],
[
"e",
"37d41055f2de9e13821c6d0c83168f6e5546fd8a6d9c60553f55363b1447d637",
"",
"reply"
],
[
"p",
"ee0fa66772f633411e4432e251cfb15b1c0fe8cd8befd8b0d86eb302402a8b4a"
]
],
"content": "📅 Original date posted:2015-08-11\n📝 Original message:Sure, most people probably would be happy with cheaper off-chain systems.\nThere already are and will probably continue to be more transactions\nhappening off-chain partly for this very reason. That's not the issue we're\ntrying to address though: The main chain is the lynch-pin to the whole\nsystem. We've got to do a good job meeting demand that people have for\nwanting to utilize the main-chain, or else we'll risk being replaced by\nsome other main-chain solution that does it better.\n\nOn Tue, Aug 11, 2015 at 4:34 PM, Adam Back \u003cadam at cypherspace.org\u003e wrote:\n\n\u003e So if they dont care about decentralisation, they'll be happy using\n\u003e cheaper off-chain systems, right?\n\u003e\n\u003e Adam\n\u003e\n\u003e On 11 August 2015 at 22:30, Angel Leon \u003cgubatron at gmail.com\u003e wrote:\n\u003e \u003e tell that to people in poor countries, or even in first world countries.\n\u003e The\n\u003e \u003e competitive thing here is a deal breaker for a lot of people who have no\n\u003e \u003e clue/don't care for decentralization, they just want to send money from\n\u003e A to\n\u003e \u003e B, like email.\n\u003e \u003e\n\u003e \u003e http://twitter.com/gubatron\n\u003e \u003e\n\u003e \u003e On Tue, Aug 11, 2015 at 5:23 PM, Adam Back via bitcoin-dev\n\u003e \u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\u003e\n\u003e \u003e\u003e I dont think Bitcoin being cheaper is the main characteristic of\n\u003e \u003e\u003e Bitcoin. I think the interesting thing is trustlessness - being able\n\u003e \u003e\u003e to transact without relying on third parties.\n\u003e \u003e\u003e\n\u003e \u003e\u003e Adam\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev\n\u003e \u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\u003e \u003e The only reason why Bitcoin has grown the way it has, and in fact the\n\u003e \u003e\u003e \u003e only\n\u003e \u003e\u003e \u003e reason why we're all even here on this mailing list talking about\n\u003e this,\n\u003e \u003e\u003e \u003e is\n\u003e \u003e\u003e \u003e because Bitcoin is growing, since it's \"better money than other\n\u003e money\".\n\u003e \u003e\u003e \u003e One\n\u003e \u003e\u003e \u003e of the key characteristics toward that is Bitcoin being inexpensive to\n\u003e \u003e\u003e \u003e transact. If that characteristic is no longer true, then Bitcoin isn't\n\u003e \u003e\u003e \u003e going\n\u003e \u003e\u003e \u003e to grow, and in fact Bitcoin itself will be replaced by better money\n\u003e \u003e\u003e \u003e that is\n\u003e \u003e\u003e \u003e less expensive to transfer.\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e \u003e So the importance of this issue cannot be overstated -- it's compete\n\u003e or\n\u003e \u003e\u003e \u003e die\n\u003e \u003e\u003e \u003e for Bitcoin -- because people want to transact with global consensus\n\u003e at\n\u003e \u003e\u003e \u003e high\n\u003e \u003e\u003e \u003e volume, and because technology exists to service that want, then it's\n\u003e \u003e\u003e \u003e going\n\u003e \u003e\u003e \u003e to be met. This is basic rules of demand and supply. I don't\n\u003e necessarily\n\u003e \u003e\u003e \u003e disagree with your position on only wanting to support uncontroversial\n\u003e \u003e\u003e \u003e commits, but I think it's important to get consensus on the\n\u003e criticality\n\u003e \u003e\u003e \u003e of\n\u003e \u003e\u003e \u003e the block size issue: do you agree, disagree, or not take a side, and\n\u003e \u003e\u003e \u003e why?\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e \u003e On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille \u003c\n\u003e pieter.wuille at gmail.com\u003e\n\u003e \u003e\u003e \u003e wrote:\n\u003e \u003e\u003e \u003e\u003e\n\u003e \u003e\u003e \u003e\u003e On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev\n\u003e \u003e\u003e \u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e \u003e\u003e\u003e Hitting the limit in and of itself is not necessarily a bad thing.\n\u003e The\n\u003e \u003e\u003e \u003e\u003e\u003e question at hand is whether we should constrain that limit below\n\u003e what\n\u003e \u003e\u003e \u003e\u003e\u003e technology is capable of delivering. I'm arguing that not only we\n\u003e \u003e\u003e \u003e\u003e\u003e should\n\u003e \u003e\u003e \u003e\u003e\u003e not, but that we could not even if we wanted to, since competition\n\u003e \u003e\u003e \u003e\u003e\u003e will\n\u003e \u003e\u003e \u003e\u003e\u003e deliver capacity for global consensus whether it's in Bitcoin or in\n\u003e \u003e\u003e \u003e\u003e\u003e some\n\u003e \u003e\u003e \u003e\u003e\u003e other product / fork.\n\u003e \u003e\u003e \u003e\u003e\n\u003e \u003e\u003e \u003e\u003e\n\u003e \u003e\u003e \u003e\u003e The question is not what the technology can deliver. The question is\n\u003e \u003e\u003e \u003e\u003e what\n\u003e \u003e\u003e \u003e\u003e price we're willing to pay for that. It is not a boolean \"at this\n\u003e size,\n\u003e \u003e\u003e \u003e\u003e things break, and below it, they work\". A small constant factor\n\u003e \u003e\u003e \u003e\u003e increase\n\u003e \u003e\u003e \u003e\u003e will unlikely break anything in the short term, but it will come with\n\u003e \u003e\u003e \u003e\u003e higher\n\u003e \u003e\u003e \u003e\u003e centralization pressure of various forms. There is discussion about\n\u003e \u003e\u003e \u003e\u003e whether\n\u003e \u003e\u003e \u003e\u003e these centralization pressures are significant, but citing that it's\n\u003e \u003e\u003e \u003e\u003e artificially constrained under the limit is IMHO a misrepresentation.\n\u003e \u003e\u003e \u003e\u003e It is\n\u003e \u003e\u003e \u003e\u003e constrained to aim for a certain balance between utility and risk,\n\u003e and\n\u003e \u003e\u003e \u003e\u003e neither extreme is interesting, while possibly still \"working\".\n\u003e \u003e\u003e \u003e\u003e\n\u003e \u003e\u003e \u003e\u003e Consensus rules are what keeps the system together. You can't simply\n\u003e \u003e\u003e \u003e\u003e switch to new rules on your own, because the rest of the system will\n\u003e \u003e\u003e \u003e\u003e end up\n\u003e \u003e\u003e \u003e\u003e ignoring you. These rules are there for a reason. You and I may agree\n\u003e \u003e\u003e \u003e\u003e about\n\u003e \u003e\u003e \u003e\u003e whether the 21M limit is necessary, and disagree about whether we\n\u003e need\n\u003e \u003e\u003e \u003e\u003e a\n\u003e \u003e\u003e \u003e\u003e block size limit, but we should be extremely careful with change. My\n\u003e \u003e\u003e \u003e\u003e position as Bitcoin Core developer is that we should merge consensus\n\u003e \u003e\u003e \u003e\u003e changes\n\u003e \u003e\u003e \u003e\u003e only when they are uncontroversial. Even when you believe a more\n\u003e \u003e\u003e \u003e\u003e invasive\n\u003e \u003e\u003e \u003e\u003e change is worth it, others may disagree, and the risk from\n\u003e disagreement\n\u003e \u003e\u003e \u003e\u003e is\n\u003e \u003e\u003e \u003e\u003e likely larger than the effect of a small block size increase by\n\u003e itself:\n\u003e \u003e\u003e \u003e\u003e the\n\u003e \u003e\u003e \u003e\u003e risk that suddenly every transaction can be spent twice (once on each\n\u003e \u003e\u003e \u003e\u003e side\n\u003e \u003e\u003e \u003e\u003e of the fork), the very thing that the block chain was designed to\n\u003e \u003e\u003e \u003e\u003e prevent.\n\u003e \u003e\u003e \u003e\u003e\n\u003e \u003e\u003e \u003e\u003e My personal opinion is that we should aim to do a block size increase\n\u003e \u003e\u003e \u003e\u003e for\n\u003e \u003e\u003e \u003e\u003e the right reasons. I don't think fear of rising fees or unreliability\n\u003e \u003e\u003e \u003e\u003e should\n\u003e \u003e\u003e \u003e\u003e be an issue: if fees are being paid, it means someone is willing to\n\u003e pay\n\u003e \u003e\u003e \u003e\u003e them. If people are doing transactions despite being unreliable,\n\u003e there\n\u003e \u003e\u003e \u003e\u003e must\n\u003e \u003e\u003e \u003e\u003e be a use for them. That may mean that some use cases don't fit\n\u003e anymore,\n\u003e \u003e\u003e \u003e\u003e but\n\u003e \u003e\u003e \u003e\u003e that is already the case.\n\u003e \u003e\u003e \u003e\u003e\n\u003e \u003e\u003e \u003e\u003e --\n\u003e \u003e\u003e \u003e\u003e Pieter\n\u003e \u003e\u003e \u003e\u003e\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e \u003e _______________________________________________\n\u003e \u003e\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e _______________________________________________\n\u003e \u003e\u003e bitcoin-dev mailing list\n\u003e \u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e\n\u003e \u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/68f2cc6f/attachment-0001.html\u003e",
"sig": "dcc115381e1c551c9f711787f5740cc6e26a6cc68b033bb14119b9f5e09371f7702efa57c4d9db98f5d414765455bdfde3c332cca64cb06de083e50f47624ab4"
}