From: Adam Back <adam@cypherspace•org>
To: Raystonn <raystonn@hotmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit
Date: Sun, 28 Jun 2015 12:07:40 +0200 [thread overview]
Message-ID: <CALqxMTHbeyyVAO9qXO4wrQo3sCh89gwMRS9BjiN+4iMs-bt5ow@mail.gmail.com> (raw)
In-Reply-To: <COL402-EAS1148599DFFBB257C33F293ACDAB0@phx.gbl>
On 28 June 2015 at 07:34, Raystonn <raystonn@hotmail•com> wrote:
> nodes are limited to 133 connections. This is 8 outgoing connections and
> 125 incoming connections. [...] Once your full node reaches 133 connections,
> it will see no further increase in load [...] Only transaction rate will affect the
> load on your node.
The total system cost is more relevant, or total cost per user. I think you
are stuck on the O( t * m ) t = tx, m = nodes thinking. Total cost per user
is increasing. That better scaling algorithms need to be found. That's why
people are working on lightning-like systems.
> fear larger blocks based on an assumption of exponential growth of work, which just
> isn't the case.
People have been explaining quadratic system level increase, which is
not exponential,
wrong assumption.
> Decentralisation is planned to scale down once the 133 connection limit is
> hit. Like it or not, this is the current state of the code.
No people are not assuming decentralisation would decrease. They are assuming
the number of economically dependent full nodes would increase, that's where the
O( n^2 ) comes from! If we assume say c= 0.1% of users will run full nodes,
and users make some small-world assumed number of transactions that doesnt
increase greatly as more users are added to the network, then O( t * m
) => O( n^2 ).
Seeing decentralisation failing isn't a useful direction as Bitcoin depends on
decentralisation for most of it's useful security properties. People running
around saying great lets centralise Bitcoin and scale it, are not working on
Bitcoin. They may more usefully go work on competing systems without
proof of work as that's where this line of reasoning ends up. There
are companies working on such things. Some of them support Bitcoin IOUs.
Some of them have job openings.
We can improve decentralisation, and use bandwidth and relay improvements
to get some increase in throughput. But starting a direction of simplistic
thinking about an ever increasing block-size mode of thinking is destructive
and not Bitcoin. If you want to do that, you need to do it in an offchain
system. You cant build on sand so your offchain system wont be useful
if Bitcoin doesnt have reasonable decentralisation to retain useful meaning.
Hence lightning. There are existing layer 2 things that have on-chain netting.
Go work on one of those. But people need to understand the constraints
and stop arguing to break Bitcoin to "scale". It's too simplistic.
Even Gavin's proposal is not trying to do that, hence reference to
Nielsen's law.
His parameters are too high for too long for basic safety or prudence, but the
general idea to reclaim some throughput from network advances, is reasonable.
Also decentralisation is key, and that is something we can improve with pooling
protocols to phase out the artificial centralisation. We can also
educate people
to use fullnode they economically depend on to keep the full to SPV ratio
reasonable which is also needed for security.
Adam
next prev parent reply other threads:[~2015-06-28 10:07 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-28 5:34 Raystonn
2015-06-28 10:07 ` Adam Back [this message]
2015-06-28 10:29 ` Benjamin
2015-06-28 12:37 ` Adam Back
2015-06-28 16:32 ` Raystonn .
2015-06-28 17:12 ` Mark Friedenbach
2015-06-28 17:18 ` Benjamin
2015-06-28 17:29 ` Gavin Andresen
2015-06-28 17:45 ` Mark Friedenbach
2015-06-28 17:51 ` Adam Back
2015-06-28 18:58 ` Adam Back
2015-06-28 21:05 ` Gavin Andresen
2015-06-28 21:23 ` Michael Naber
2015-06-28 22:07 ` Adam Back
2015-06-29 0:59 ` Eric Lombrozo
2015-06-29 1:13 ` Eric Lombrozo
2015-06-29 1:45 ` Andy Schroder
2015-06-30 0:42 ` Tom Harding
2015-07-10 2:55 ` Tom Harding
2015-06-28 17:53 ` Jorge Timón
2015-06-28 19:22 ` Andrew Lapp
2015-06-28 19:40 ` Benjamin
2015-06-28 12:32 ` Milly Bitcoin
-- strict thread matches above, loose matches on Subject: below --
2015-06-27 14:39 Michael Naber
2015-06-27 15:21 ` Peter Todd
2015-06-27 15:29 ` Randi Joseph
2015-06-27 15:32 ` Peter Todd
2015-06-27 16:19 ` Michael Naber
2015-06-27 17:20 ` Peter Todd
2015-06-27 17:26 ` Benjamin
2015-06-27 17:37 ` Peter Todd
2015-06-27 17:46 ` Benjamin
2015-06-27 17:54 ` Peter Todd
2015-06-27 17:58 ` Venzen Khaosan
2015-06-27 19:34 ` Benjamin
2015-06-27 15:33 ` Adam Back
2015-06-27 16:09 ` Michael Naber
2015-06-27 16:28 ` Mark Friedenbach
2015-06-27 16:37 ` Peter Todd
2015-06-27 17:25 ` Michael Naber
2015-06-27 17:34 ` Peter Todd
2015-06-27 18:02 ` Jameson Lopp
2015-06-27 18:47 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALqxMTHbeyyVAO9qXO4wrQo3sCh89gwMRS9BjiN+4iMs-bt5ow@mail.gmail.com \
--to=adam@cypherspace$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=raystonn@hotmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox