📅 Original date posted:2015-06-27
📝 Original message:The goal of Bitcoin Core is to meet the demand for global consensus as
effectively as possible. Please let's keep the conversation on how to best
meet that goal.
The off-chain solutions you enumerate are are useful solutions in their
respective domains, but none of them solves the global consensus problem
with any greater efficiency than Bitcoin does.
On Sat, Jun 27, 2015 at 11:33 AM, Adam Back <adam at cypherspace.org> wrote:
> Michael Naber wrote:
> > Bitcoin Core must remain the lowest-fee, highest-capacity, most secure,
> distributed, fastest, overall best solution possible to the global
> consensus problem.
>
> Everyone here is excited about the potential of Bitcoin and would
> aspirationally like it to reach its full potential as fast as
> possible. But the block-size is not a free variable, half those
> parameters you listed are in conflict with each other. We're trying
> to improve both decentralisation and throughput short-term while
> people work on algorithmic improvements mid-term. If you are
> interested you can take a look through the proposals:
>
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008603.html
>
> Note that probably 99% of Bitcoin transactions already happen
> off-chain in exchanges, tipping services, hosted wallets etc. Maybe
> you're already using them, assuming you are a bitcoin user.
> They constitute an early stage layer 2, some of them even have on
> chain netting and scale faster than the block-chain.
>
> You can also read about layer 2, the lightning network paper and the
> duplex micropayment channel paper:
>
> http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf
>
> http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf
>
> and read the development list and look at the code:
>
> http://lists.linuxfoundation.org/pipermail/lightning-dev/
> https://github.com/ElementsProject/lightning
>
> Adam
>
>
> On 27 June 2015 at 16:39, Michael Naber <mickeybob at gmail.com> wrote:
> > Demand to participate in a low-fee global consensus network will likely
> > continue to rise. Technology already exists to meet that rising demand
> using
> > a blockchain with sufficient block size. Whether that blockchain is
> Bitcoin
> > Core with an increased block size, or whether it is a fork, market forces
> > make it almost certain that demand will be met by a blockchain with
> adequate
> > capacity. These forces ensure that not only today’s block size will be
> > increased, but also that future increases will occur should the demand
> > arise.
> >
> > In order to survive, Bitcoin Core must remain the lowest-fee,
> > highest-capacity, most secure, distributed, fastest, overall best
> solution
> > possible to the global consensus problem. Attempting to artificially
> > constrain the block size below the limits of technology for any reason
> is a
> > conflict with this objective and a threat to the survival of Bitcoin
> Core.
> > At the same time, scheduling large future increases or permitting
> unlimited
> > dynamic scaling of the block size limit raises concerns over
> availability of
> > future computing resources. Instead, we should manually increase the
> block
> > size limit as demand occurs, except in the special case that increasing
> the
> > limit would cause an undue burden upon users wishing to validate the
> > integrity of the blockchain.
> >
> > Compromise: Can we agree that raising the block size to a static 8MB now
> > with a plan to increase it further should demand necessitate except in
> the
> > special case above is a reasonable path forward?
> >
> > _______________________________________________
> > 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/20150627/ec2e5cfc/attachment-0001.html>;
Michael Naber [ARCHIVE] /
npub13r…cy5l4
2023-06-07 15:40:51
in reply to nevent1q…mnl0
Author Public Key
npub13rv3raner7hu6npy7vxxvdswdapae65pnw8jjs4c80wtp2nmg4xq9cy5l4Published at
2023-06-07 15:40:51Event JSON
{
"id": "14543eae71f0720e4e893b0fea10c43c9fd15f01dc745ea358fa503316896709",
"pubkey": "88d911f6791fafcd4c24f30c66360e6f43dcea819b8f2942b83bdcb0aa7b454c",
"created_at": 1686152451,
"kind": 1,
"tags": [
[
"e",
"302bda6b5cc3b22bc31708bc8101794c3e35655f608a2a34ebc62e92bc3dada4",
"",
"root"
],
[
"e",
"7880c6cb28ec4932a2a1a628b443d56e3e151f37a61f914590d2cc2681b94760",
"",
"reply"
],
[
"p",
"ee0fa66772f633411e4432e251cfb15b1c0fe8cd8befd8b0d86eb302402a8b4a"
]
],
"content": "📅 Original date posted:2015-06-27\n📝 Original message:The goal of Bitcoin Core is to meet the demand for global consensus as\neffectively as possible. Please let's keep the conversation on how to best\nmeet that goal.\n\nThe off-chain solutions you enumerate are are useful solutions in their\nrespective domains, but none of them solves the global consensus problem\nwith any greater efficiency than Bitcoin does.\n\n\nOn Sat, Jun 27, 2015 at 11:33 AM, Adam Back \u003cadam at cypherspace.org\u003e wrote:\n\n\u003e Michael Naber wrote:\n\u003e \u003e Bitcoin Core must remain the lowest-fee, highest-capacity, most secure,\n\u003e distributed, fastest, overall best solution possible to the global\n\u003e consensus problem.\n\u003e\n\u003e Everyone here is excited about the potential of Bitcoin and would\n\u003e aspirationally like it to reach its full potential as fast as\n\u003e possible. But the block-size is not a free variable, half those\n\u003e parameters you listed are in conflict with each other. We're trying\n\u003e to improve both decentralisation and throughput short-term while\n\u003e people work on algorithmic improvements mid-term. If you are\n\u003e interested you can take a look through the proposals:\n\u003e\n\u003e\n\u003e http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008603.html\n\u003e\n\u003e Note that probably 99% of Bitcoin transactions already happen\n\u003e off-chain in exchanges, tipping services, hosted wallets etc. Maybe\n\u003e you're already using them, assuming you are a bitcoin user.\n\u003e They constitute an early stage layer 2, some of them even have on\n\u003e chain netting and scale faster than the block-chain.\n\u003e\n\u003e You can also read about layer 2, the lightning network paper and the\n\u003e duplex micropayment channel paper:\n\u003e\n\u003e http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf\n\u003e\n\u003e http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf\n\u003e\n\u003e and read the development list and look at the code:\n\u003e\n\u003e http://lists.linuxfoundation.org/pipermail/lightning-dev/\n\u003e https://github.com/ElementsProject/lightning\n\u003e\n\u003e Adam\n\u003e\n\u003e\n\u003e On 27 June 2015 at 16:39, Michael Naber \u003cmickeybob at gmail.com\u003e wrote:\n\u003e \u003e Demand to participate in a low-fee global consensus network will likely\n\u003e \u003e continue to rise. Technology already exists to meet that rising demand\n\u003e using\n\u003e \u003e a blockchain with sufficient block size. Whether that blockchain is\n\u003e Bitcoin\n\u003e \u003e Core with an increased block size, or whether it is a fork, market forces\n\u003e \u003e make it almost certain that demand will be met by a blockchain with\n\u003e adequate\n\u003e \u003e capacity. These forces ensure that not only today’s block size will be\n\u003e \u003e increased, but also that future increases will occur should the demand\n\u003e \u003e arise.\n\u003e \u003e\n\u003e \u003e In order to survive, Bitcoin Core must remain the lowest-fee,\n\u003e \u003e highest-capacity, most secure, distributed, fastest, overall best\n\u003e solution\n\u003e \u003e possible to the global consensus problem. Attempting to artificially\n\u003e \u003e constrain the block size below the limits of technology for any reason\n\u003e is a\n\u003e \u003e conflict with this objective and a threat to the survival of Bitcoin\n\u003e Core.\n\u003e \u003e At the same time, scheduling large future increases or permitting\n\u003e unlimited\n\u003e \u003e dynamic scaling of the block size limit raises concerns over\n\u003e availability of\n\u003e \u003e future computing resources. Instead, we should manually increase the\n\u003e block\n\u003e \u003e size limit as demand occurs, except in the special case that increasing\n\u003e the\n\u003e \u003e limit would cause an undue burden upon users wishing to validate the\n\u003e \u003e integrity of the blockchain.\n\u003e \u003e\n\u003e \u003e Compromise: Can we agree that raising the block size to a static 8MB now\n\u003e \u003e with a plan to increase it further should demand necessitate except in\n\u003e the\n\u003e \u003e special case above is a reasonable path forward?\n\u003e \u003e\n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150627/ec2e5cfc/attachment-0001.html\u003e",
"sig": "6e8a46b24463381618b6900c3ec3f099ff2f3543c50bc0fba2002672301d92e5db0258830beebdc9e6d818f1fbef1c66c64b7403a87ab04b9ac9be8f1853ba0d"
}