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
|
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 C1DF1273
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jun 2015 15:33:13 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout.perfora.net (mout.perfora.net [74.208.4.197])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E38807C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jun 2015 15:33:12 +0000 (UTC)
Received: from mail-qk0-f176.google.com ([209.85.220.176]) by
mrelay.perfora.net (mreueus001) with ESMTPSA (Nemesis) id
0LdnYT-1Yi5vI452p-00izJ6 for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jun 2015 17:33:12 +0200
Received: by qkbp125 with SMTP id p125so71026535qkb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jun 2015 08:33:11 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.101.8 with SMTP id t8mr9385432qge.9.1435419191347; Sat,
27 Jun 2015 08:33:11 -0700 (PDT)
Received: by 10.96.28.39 with HTTP; Sat, 27 Jun 2015 08:33:11 -0700 (PDT)
In-Reply-To: <CALgxB7udA85BWetBGc-RN=72ZtVPK9Q5HW8YRDKA08M38XqJqQ@mail.gmail.com>
References: <CALgxB7udA85BWetBGc-RN=72ZtVPK9Q5HW8YRDKA08M38XqJqQ@mail.gmail.com>
Date: Sat, 27 Jun 2015 17:33:11 +0200
Message-ID: <CALqxMTHjszPcf=S20kquF=5y3zfYb+foP6tL1okOT2jhdrW08A@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Michael Naber <mickeybob@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K0:7izOrFj0UvFuFggYuf3WOZy0V/cPapy57sKsz0nIxGg8U0nV6q8
+ci6uy6NZOjP8IQRonMMJi3xDIDRQsXrlkkdPLsEnRPr77XkUkVxSNvd/FXlrSabxQr7lUg
WG98TL0U3yuNxavybDvsiaFpu8XxeYzoLLoEIpiMD2tUXSaQs8BEy8aFYJoDJK0MypnAk8N
5+hknfGwSC+O8Dz5x+JfA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:HVNwmggl/Ao=:BYeXE84M/hSymdI4LLDlgd
6kNvnfyLc7wGjpFPcq1ntZsm7woyIyxB+6LNzKCi8k+RlUGJqSTxXvXzPn/ZY1PAclNEsUsb2
f6M7CHVN/OdOqH4jLN4TViDK6vsTMfUtCbFduIi90LPgeiUNPalv0C4QZOzbE6UW4hFHVdv3o
PMuSMKF5/0W8g89Vgn92z/WhN3PKNLNvdmNyfnBxXZupEjVHa2WvS+q8BPpL0lwFI66t90xJf
59PEK0K6AL8VHQOu7kLPQ93iZHkX+iMWko4CGJ1S4nTaxyUb5+FU40pg1Ym9PA0Nl4rSNGmHx
sMJ+Uy7Yo/R9F7J4iAG2YztT/AqQqYrLyMTXOV/rmULU8lVQdAZPeRWEjQFIOKWD6Gh0H7xQJ
uEypM3x7LUQWIB8R7lBbCMAwicAtNIQmReT8tnX+r5FCwouTGaXFmHEjCnZq7WoxHdgqx+var
kHhMMxpqIv+oZYuhcsUdy+V7LSrS6P92GpTJ5oserlxu8+IY59dZhgFNp+DLOTNaelU/PH0dk
bvskYzzJAKWHHnlGRlb2BV2GPP9yd0ydRwY8GfrSXhlZ1dX0XsWFLeQApTWGw9BgPutNpW1Qt
lUFNJmYgrhgC/eu2PpiC4xymVnncCmvyucZT6WFAgN01AtMETpcJvZQ/lMVX33HxHQ2XLL/cC
E5zo143+Ekwi3iSjLdKKtMQ6M4N/PqED9wMMSDs1uayKNwg==
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: Sat, 27 Jun 2015 15:33:13 -0000
Michael Naber wrote:
> Bitcoin Core must remain the lowest-fee, highest-capacity, most secure, d=
istributed, 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.htm=
l
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-micr=
opayment-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@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 us=
ing
> a blockchain with sufficient block size. Whether that blockchain is Bitco=
in
> 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 adequ=
ate
> capacity. These forces ensure that not only today=E2=80=99s block size wi=
ll 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 solutio=
n
> 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 unlimit=
ed
> dynamic scaling of the block size limit raises concerns over availability=
of
> future computing resources. Instead, we should manually increase the bloc=
k
> size limit as demand occurs, except in the special case that increasing t=
he
> 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 th=
e
> special case above is a reasonable path forward?
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
