public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Eric Lombrozo <elombrozo@gmail.com>
To: Adam Back <adam@cypherspace.org>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] comments on BIP 100
Date: Sun, 14 Jun 2015 17:53:05 -0700	[thread overview]
Message-ID: <674CED15-3F4C-4E24-BCA2-3C474CC01708@gmail.com> (raw)
In-Reply-To: <CALqxMTENbj+E7ypJASrM1r04eW3kYe+afwy+Rt3i9ubeT-=2mA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5715 bytes --]

I think the whole complexity talk is missing the bigger issue.

Sure, per block validation scales linearly (or quasilinearly…there’s an O(log n) term in there somewhere but it’s probably dominated by linear factors at current levels…asymptotic limits don’t always apply very well to finite systems). And there’s an O(n^2) bandwidth issue.

The real issue, though, is validation cost. The n in O(n) here does not represent block size - it represents the size of the entire block chain for every new validator that must be synchronized! It means we have no way to construct short proofs (or at least arguments that are computationally *hard* to forge) without requiring the validator to maintain the complete system state. And currently, there is no mechanism for directly compensating validators.

A full validator that goes offline even for a short period of time takes a while to fully catch up to the rest of the network - and starting up a new validator from scratch will continue to be painful…even for those of us who’ve turned this into routine by now, let alone new nontechnical users.

Satoshi’s SPV is not a real solution - it’s a mere suggestion that wasn’t fully thought out at the time of the Bitcoin white paper. Besides lacking a good validation security model, practical implementations of it weaken privacy and complicate client implementations substantially…and the worst part, it still doesn’t scale all that well. The validator still has to query every single block (even if filtered) back to the first transaction (which cannot be determined without doing a blockchain scan anyway).

So yes, we will most certainly need algorithmic improvements!

- Eric Lombrozo


> On Jun 14, 2015, at 4:58 PM, Adam Back <adam@cypherspace.org> wrote:
> 
> Hi Mike
> 
> On 15 June 2015 at 00:23, Mike Hearn <mike@plan99.net> wrote:
>>> One thing that is concerning is that few in industry seem inclined to
>>> take any development initiatives or even integrate a library.
>> 
>> Um, you mean except all the people who have built more scalable wallets over
>> the past few years, which is the only reason anyone can even use Bitcoin
>> from their phone?
> 
> No slight intended obviously to people who do write actual client code.
> 
> That was probably insufficiently specific, let me rephrase: I am
> referring to the trend that much of the industry is built on web2.0
> technology using bitcoin via a library in a web scripting language,
> often with consensus bugs, and even outsourcing and not even running
> their own full node, so that the service itself offered to their users
> isn't even SPV secure to the operator.  As well as being heavily based
> on a third-party custody model that is the root cause of the repeated
> wallet breaches.  Some of these companies have a noted tendency not to
> upgrade or fix code.
> 
> So I mean this not to call out specific companies, but in the sense
> that if we're technologists we should be trying to move the technology
> forward, not just changing parameters which run into an O(n^2) scaling
> wall or break decentralisation security.  And we shouldnt take the
> above state of affairs as an immutable reality.  It can not persist
> for bitcoin to reach maturity on scale nor security.
> 
>> I still think you guys don't recognise what you are actually asking for here
>> - scrapping virtually the entire existing investment in software, wallets
>> and tools.
> 
> As I said I dont think we can expect Bitcoin to scale with no further
> algorithmic improvements.  Algorithmic improvements take code.  There
> is reasonable scope to build in an incrementally deployable way,
> there's plenty of time for people to code, test and opt-in to things,
> the sky is not falling.  Companies do care about scaling, and can
> invest in the integration and coding implied to improve their products
> scalability, they have an economic incentive to do it and there is no
> scalable and safe way todo it without this work.
> 
>> Computational complexity for the entire network is O(nm) where
>> n=transactions and m=fully validating nodes. There is no fixed relationships
>> between those two variables.
> 
> I am referring to global bandwidth O(n^2) with n=users, or O(n) per
> user bandwidth cost to the system, while O(nm) is accurate nodes is an
> internal system concept.  Anyway suffice to say the network does not
> scale O(1) in per user cost.
> 
>> "Exposing the companies to back-pressure" sounds quite nice and gentle. Let
>> me rephrase it to be equivalent but perhaps more direct: you mean "breaking
>> the current software ecosystem to force people into a new, fictional system
>> that bears little resemblance to the Bitcoin we use today, whether they want
>> that or not".
>> 
>> As nothing that has been proposed so far (Lightning, merge mined chains,
>> extension blocks etc) has much chance of actual deployment any time soon,
>> that leaves raising the block size limit as the only possible path left.
> 
> A hard-fork takes a long period of time to deploy due to the
> non-upgrade risk, people are working on things in the mean-time.
> There can be a case for some increase to create some breathing room to
> work on scaling and decentralising tech, I just mean to say that if we
> do it in isolation, we're not focussing on the big picture.
> 
> Adam
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

  reply	other threads:[~2015-06-15  0:53 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-14 21:23 [Bitcoin-development] comments on BIP 100 Adam Back
2015-06-14 22:23 ` Mike Hearn
2015-06-14 23:58   ` Adam Back
2015-06-15  0:53     ` Eric Lombrozo [this message]
2015-06-15  0:55       ` Eric Lombrozo
2015-06-15  4:11       ` Peter Todd
2015-06-15  4:43         ` Eric Lombrozo
2015-06-15  9:27     ` Mike Hearn
2015-06-15  9:39       ` Eric Lombrozo
2015-06-15 10:24       ` Pieter Wuille
2015-06-15 10:36         ` Mike Hearn
2015-06-15 10:40           ` Pieter Wuille
2015-06-15 10:50             ` Mike Hearn
2015-06-15 11:16               ` Rebroad (sourceforge)
2015-06-15 17:53                 ` Raystonn .
2015-06-15 18:14                   ` Adam Back
2015-06-15 18:57                     ` [Bitcoin-development] The Bitcoin Node Market Raystonn .
2015-06-15 19:18                       ` sickpig
2015-06-15 19:36                         ` Raystonn .
2015-06-15 20:12                           ` sickpig
2015-06-16  3:30                             ` Kevin Greene
2015-06-16  3:41                               ` Luke Dashjr
2015-06-16  3:49                                 ` Kevin Greene
2015-06-16  4:05                                   ` Kevin Greene
2015-06-16  4:12                                   ` Aaron Voisine
2015-06-16  5:28                                   ` justusranvier
2015-06-16  5:30                                     ` Potter QQ
2015-06-16  7:55                                     ` Aaron Voisine
2015-06-16 13:32                                       ` justusranvier
2015-06-16 17:04                                         ` Aaron Voisine
2015-06-16 17:22                                         ` Aaron Voisine
2015-06-16 15:52                                       ` devrandom
2015-06-15  4:43   ` [Bitcoin-development] comments on BIP 100 Peter Todd
2015-06-15  9:06     ` Mike Hearn
2015-06-15  2:28 ` Jeff Garzik
2015-06-15  2:44   ` Jeff Garzik

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=674CED15-3F4C-4E24-BCA2-3C474CC01708@gmail.com \
    --to=elombrozo@gmail.com \
    --cc=adam@cypherspace.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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