1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
|
Return-Path: <adam@cypherspace.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E1B95305
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 10:07:42 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 420407C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 10:07:42 +0000 (UTC)
Received: from mail-qk0-f171.google.com ([209.85.220.171]) by
mrelay.perfora.net (mreueus003) with ESMTPSA (Nemesis) id
0M56jI-1Yrutf1UtS-00zGuJ for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 12:07:41 +0200
Received: by qkbp125 with SMTP id p125so79741138qkb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 03:07:40 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.97.230 with SMTP id m93mr12793210qge.32.1435486060688;
Sun, 28 Jun 2015 03:07:40 -0700 (PDT)
Received: by 10.96.28.39 with HTTP; Sun, 28 Jun 2015 03:07:40 -0700 (PDT)
In-Reply-To: <COL402-EAS1148599DFFBB257C33F293ACDAB0@phx.gbl>
References: <COL402-EAS1148599DFFBB257C33F293ACDAB0@phx.gbl>
Date: Sun, 28 Jun 2015 12:07:40 +0200
Message-ID: <CALqxMTHbeyyVAO9qXO4wrQo3sCh89gwMRS9BjiN+4iMs-bt5ow@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Raystonn <raystonn@hotmail.com>
Content-Type: text/plain; charset=UTF-8
X-Provags-ID: V03:K0:q5OyrEI3PUQZwchtM68m9p+UjvNkd3O3QfXE9XuNafGQqWISDy8
OhrJPFd9/7dfr3mAuIre5p93PLcAb1SIuPQ8XGsmIGbLy5NvD0+7POWn7C1MnuXKSE74jhF
h2UL2zj1Xr6bz6k6OzRIKXF6j1f8ZZMYRFfaC7tDrcXYsrS/GfxKHX+ymy0fdBTyRHKgygs
/Wjkyk6Ejk4PYXHdoNt4A==
X-UI-Out-Filterresults: notjunk:1;V01:K0:URop/dzh4R4=:bySirfa8+v0huxtIQWAHTH
K6mOokrA/lO3f1GZFMLoBk5iyKsO0344G1o6rKovjUCa2clJ6Y3/3sqxkP+i4feA4pdCpfdDV
bbWYYmmodIjmvCCjBa6ohPHxKVW6WtyiDtx3zmh4BAbjImwUCd4qXdoU0KoepDfcV+rAy1IGf
NYNPaV8jYbtKyXP6Gd3EgoY/CVdxn8Soq2F4RqeT7ysvnNSBu7wCo6GiOhW3L6jM/3PMxYGsJ
9y57xewwIWkNwsArzHnAGAaMvFS9hirgo1dtScUFzUJzHUGGiw6KI56PSU4px96mYPx8SF/d0
MSkUCwFwVq5UVQzeIBn+WFqzUFchMsbgN6ZcUt7FbaZ4gxUSNrvCo8ntA6bIDGNT5Q5Iply+7
qAGbxMC58v4XNKbjVmJQaE/ea1pa6tG2wvA2wn1eixd/zOkfjXCC4exGk99QMeKUwNbPubPwb
wjNdZ2Y8iONpHx7MVdxaQCnVJ9g73Nm/XbbZ7S7R+Q/+WceHhiwdwRsURN4+P2B36TMXutN7f
oiLAMoN69Vq8jHdsUyi019thsU/XCziWa/kpnbQN+KBNTrIFNz98ti5h+O6I2ay6ZjleWS0RM
6gdiNopF3vKS77Dg/TGDril0hjnz7WtXiMbrJghIkz6CUEire3pqcURE0NG0ecH5fWInL4FEQ
EUt78sj+Ov15rEH/4YWX18UpWSB/KCGqSZ6h6ApFsO0BPUQ==
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Jun 2015 10:07:43 -0000
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
|
