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
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <adam@cypherspace.org>) id 1Z5toE-0007Gc-Cn
for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 10:46:06 +0000
X-ACL-Warn:
Received: from mout.perfora.net ([74.208.4.194])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Z5toB-00045u-Tn
for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 10:46:06 +0000
Received: from mail-qg0-f44.google.com ([209.85.192.44]) by mrelay.perfora.net
(mreueus002) with ESMTPSA (Nemesis) id 0MQxMe-1ZYxEx3rNW-00UIrf for
<bitcoin-development@lists.sourceforge.net>;
Fri, 19 Jun 2015 12:45:58 +0200
Received: by qged89 with SMTP id d89so34886239qge.0
for <bitcoin-development@lists.sourceforge.net>;
Fri, 19 Jun 2015 03:45:57 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.55.17.95 with SMTP id b92mr33845898qkh.16.1434710757093;
Fri, 19 Jun 2015 03:45:57 -0700 (PDT)
Received: by 10.96.20.164 with HTTP; Fri, 19 Jun 2015 03:45:57 -0700 (PDT)
In-Reply-To: <CALqxMTGCkTZAs74bXk57L6JWK29Xzbn1ZUkWN_NuBp+EufjEQg@mail.gmail.com>
References: <CALqxMTGCkTZAs74bXk57L6JWK29Xzbn1ZUkWN_NuBp+EufjEQg@mail.gmail.com>
Date: Fri, 19 Jun 2015 12:45:57 +0200
Message-ID: <CALqxMTFx6DF0Re+pCwB1AjYo6eYuKtX1cqUpo=wXmHSOsN74dQ@mail.gmail.com>
From: Dr Adam Back <adam@cypherspace.org>
To: Dr Adam Back <adam@cypherspace.org>
Content-Type: text/plain; charset=UTF-8
X-Provags-ID: V03:K0:TvVlSr//gN6YaiPeJgL9hzf4hly7xL1japb8XxOTlzeUXh+ZOmB
a9yDKWA0HKWSFtRmSGzua7X3huUA0Tmu8Zdmi+DWkPmR0dNRLUitiyqvPt2WIgACH80UPVO
4+NH+gPd1kV7WWlBtEA6IXdadWxiOnVDJDijey9aL9U5Qwg7K4SEWVKHKQTrSi8umgXXQo/
VLxmIEiavHPbc2Y0WB7zA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:SadoPzcWK0U=:OYALZbRU3XhgFH4nZRYrcF
Enecnb0NrGO2tm8DDBLWN7ujTZbkiwlVnWzjso8zcUyZKn9HwfavOS/3oPLUF5eX9b8n7j71j
gMFOQeFYrvVMiP8MpOEwPUm1t0zdzy74qj6t/+R8RpTPOfcCHZvEf8y9dqqCo52JZgohhUkBh
FkslE5nS3GuurAtSXc8G1paoLbK7+MGTjf2sPGHvP5ubqA4AARrhFuGzf5gJXtAXSVMxX4ZoP
vHlbAiYpJpJiNIBoN+Lcfjfr1YtijhT4UiKd2nfWWgwvXMBKnMcidLNMCcdIer4JmnQzEiKvU
J43oMm6YciZ0QnB3b0gpgSHyYd2WQWyfo7wgGsAkyPezfEuCvXjipUTEbXipyMFcAzbRzhZoL
Zsq7QkVqIomQ4WBAOo3J+BX40oEE+fYRNcyiDb7F401KJURGT/arMGcl6mBP01qbQQ/WPDhxV
17L42Gtsu0xVrYBgC/dWpedJ/rVvty3CkW1n/VIe1DU4+gQZEIK2+s/otyZUIMXAEUvJ+NP31
CcnKBTULo8fdpHohq5gsTITpDD4qyvDYkyYfXrEEL9OBtT0/xt1gaewqMlcND+ff0WjTSYu1o
eKs5/h5A6e3x7Ud9dmNhN/fWuvxDSEjGOAT/TjMt6J8B9GnlSli+jrV0Jjks/96/f3qyFWgUc
xP1PUTtgsIbFaDCjLgmCQjb+FhDUl9s7+hT6BjhsGPbCpoA==
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [74.208.4.194 listed in list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
0.0 T_HK_NAME_DR T_HK_NAME_DR
X-Headers-End: 1Z5toB-00045u-Tn
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] improving development model (Re: Concerns
Regarding Threats by a Developer to Remove Commit Access from Other
Developers
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 19 Jun 2015 10:46:06 -0000
A lot of people think a layer2 is needed, that has a higher
(algorithmic) scale in use of layer1 block-space but preserves
functionality and uplifts security from layer1. An example would be
lightning or similar.
But there are many things that could be done. Pure offchain is a weak
form of layer2. Its running today and maybe its handling 90-99% range
of all transactions right now (mostly in exchanges for example). This
layer can be incrementally hardened. It can also have standardised
APIs across vendors of custodians, and opt-in support of those APIs in
wallets. This would provide a convenience choice. Greenaddress also
for low-mid assurances solves the unconfirmed transactions. It's
probably not reasonable to expect bitcoin directly solve fast
unconfirmed transactions. Probably intermediate configurations in
complexity somewhere between greenaddress (2 of 2 + timelocked 1 sig)
and lightning may exist also. The internet doesnt stop at layer1.
(Which would then leave people who are uninterested in changing client
software to handle layer2, as "layer1 will always be enough die-hards"
(in the refusing the future and facing the O(n^2) scaling wall or
centralisation death with perplexing optimism :) Ok, not so
constructive but maybe a gentle reminder that it is not constructive
in the reverse direction either to throw around often false
characterisations. We're here now to improve bitcoin so lets do that.
What I said here seemed like it maybe subject to misinterpretation so
to clarify:
On 19 June 2015 at 11:22, Dr Adam Back <adam@cypherspace.org> wrote:
> For example it could hypothetically allow 10MB blocks on
> one chain and 100kB blocks on the main chain. People say complexity,
> scary. Sure I am talking longer term, but we have to also make
> concrete forward progress to the future or we'll be stuck here talking
> about perilously large constant changes in 5 years time!
I should clarify that I meant there I was assuming we do one increase
within the next 12 months frame that gives buffer for 5 years r&d to
improve things and build layer2.
But if we do no R&D on layer2, and insist that clients can never
change to become layer2 aware, and layer2 is too hard etc then our
risk would be we'd be back in the discussion of kicking the can afresh
again in some years with some even more centralising size change.
Sure we should make the transition and introduction to layer2 and an
intermediate crunch smoother, but "20MB now or else" isn't really
helping. It did help get the conversation revived, but at this point
its a hindrance. Seriously a big hindrance. No offence but please
find a way to gracefully stop and rejoin the constructive process.
You can disagree on factors and points and be collaborative others
disagree frequently and have done productive work cordially for years
under the BIP process.
About scaling again:
Here is what I said before in my TL;DR post about my thoughts on how
we would start on throughput short-term to have space to do layer2
development.
> I think almost everybody is on board with a combination plan:
>
> 1. work to improve decentralisation (specific technical work already
> underway, and education)
> 2. create a plan to increase block-size in a slow fashion to not cause
> system shocks (eg like Jeff is proposing or some better variant)
> 3. work on actual algorithmic scaling
>
> In this way we can have throughput needed for scalability and security
> work to continue.
>
> As I said you can not scale a O(n^2) broadcast network by changing
> constants, you need algorithmic improvements.
>
> People are working on them already. All of those 3 things are being
> actively worked on right now, and in the case of algorithmic scaling
> and improve decentralisation have been worked on for months.
Btw I wonder if Gavin or Mike would be willing to answer another
question I forgot from my TL;DR post which was:
- Did you accept payment from companies to lobby for 20MB blocks? Do
you consider that something appropriate to publicly disclose if so?
Do you consider that user rights should come above or below company
interests in Bitcoin?
FWIW on pondering that last question "should user rights come above or
below company interests" I think my view of the guiding principle is
starkly clear to me: that user rights should be the primary thing to
optimise for. Businesses are providing service to users, their
interests are secondary in so far as if they are enabled to provide
better service thats good.
Bitcoin is a user p2p currency, with a social contract and a strong
user ethos. Importing and forcing company interests would likely be
the start of a slippery slope towards an end to Bitcoin. If we allow
business rights to be paramount it seems likely that we will end back
at the status quo as bitcoin payment processors grow, conglomerate and
become paypal/bank like or actual banks and then their interests and
exposures are the same as the banks and they'll want to import their
business models into Bitcoin and erode the user ethos features that
are actually what gives Bitcoin any meaning and value in the majority.
That wont be good for the companies either, but they may not see that
until they've killed it, many companies operate on a1 or 2 year
time-horizon. They may say screw layer2, I have a runway and I need
micropayments to the wazoo and I dont have the dev resources for that.
Thats a conflict and the resolution isn't to override bitcoin's
meaning, but rather that they should do it at layer2 (eg changeTip
does this.. simple trustme layer2 which is OK given the amounts). The
world needs a neutral social contract enforcing layer1. Layer1 must
be neutral and free from policy and dispute resolution otherwise
dispute resolution costs are imported and you lose viral open
innovation growth vector the internet benefitted from. Jurisdiction
and regulation related things belong at the interfaces and at the
payment protocol layer in my view. (If thats not obvious to some
lurkers I elaborate on that argument amongst other things here:
https://www.youtube.com/watch?v=3dAdI3Gzodo )
Adam
ps the O(n^2) misunderstanding of varying assumptions was explored at
length on reddit
http://www.reddit.com/r/Bitcoin/comments/3a5f1v/mike_hearn_on_those_who_want_all_scaling_to_be/csboslb
if people are interested in that topic. I do not think O( t*n ) is a
useful metric because its predictive but only of the obvious and
internal, the useful predictive thing is resources vs users (for
nodes/users or whole-system).
|
