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
|
Return-Path: <ithkuil@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5B82C11C5
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 14 Sep 2015 01:47:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com
[209.85.213.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0245363
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 14 Sep 2015 01:47:06 +0000 (UTC)
Received: by igbkq10 with SMTP id kq10so76761528igb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 13 Sep 2015 18:47:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:from:date:message-id:subject:to:content-type;
bh=ltBS2T1FOhhTuhF4KjVKJM5e7Lbhfz1KIZSiJ5qVRGI=;
b=o2fYd0+3OdRYFKMWYoMj0zL2o7Ag2X+kx1iCY1DSsCNooyVGF3YqG965wbX4iqnyzQ
o3W8VllPZr5pa1beD3a+EJVLrMBSu/vyxWtI+5CtC/uQtMl8S8JHIumuLYbwg14Ps24Z
o3ki36ogIUbvgSpu40x2CxAAov66LZHCzwNiEiSE6WmD/NWl5Ej+2H9gVNADHWZdfVe/
fhqM8badHLeVY2Pgd/RjcGg4plD8RxKa0zD9/Hkb/o3hKn07lFiWDodp2Mw6gBCQBmpO
tv0e/ZjNHsTMVLC8nV8EDyn3c10xWQ6U0Bq9Eq6kbZ2e7+VQy+58PRMEXWe1h0vxH5wQ
Nkyg==
X-Received: by 10.50.43.202 with SMTP id y10mr13121173igl.86.1442195226437;
Sun, 13 Sep 2015 18:47:06 -0700 (PDT)
MIME-Version: 1.0
From: Jason Livesay <ithkuil@gmail.com>
Date: Mon, 14 Sep 2015 01:46:57 +0000
Message-ID: <CAORTeX=4pCAwnPSkLRb4w0vh116ZtTKJfq-RkeU69Fp67CwinQ@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=089e011604ba2b3002051fab3ea9
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] Quick Bitcoin/Pre-Christmas modest blocksize max
increase
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: Mon, 14 Sep 2015 01:47:07 -0000
--089e011604ba2b3002051fab3ea9
Content-Type: text/plain; charset=UTF-8
After studying the issues I believe that the situation warrants a
short-term modest blockchain increase. Somewhere between 2mb-5mb, whatever
the community will swallow. I recommend that happen before the winter
shopping rush.
Then, because of the fundamental technical limitations of scaling, a new
system needs to be adopted for fast transactions. To maintain momentum
etc., the new system ultimately settles with traditional bitcoins.
In order to keep the existing brand momentum, network, and business
investment, I believe the smoothest path forward is to build a new,
additional system re-using the bitcoin name. I suggest this new system
come packaged with the bitcoin core client and be referred to as
QuickBitcoin or qbtc or something similar. As far as the public is
concerned it could simply continue to be called bitcoin. The system will
work on top of traditional bitcoins but have a mechanism for more/faster
transactions. Exactly what mechanism doesn't have to be perfect, it just
needs to be reasonably secure/useful and something that the community will
accept.
I believe this is the best way to scale bitcoin while maintaining the
strength of its existing network, community, and branding.
--089e011604ba2b3002051fab3ea9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">After studying the issues I believe that the situation warra=
nts a short-term modest blockchain increase.=C2=A0 Somewhere between 2mb-5m=
b, whatever the community will swallow.=C2=A0 I recommend that happen befor=
e the winter shopping rush.</p>
<p dir=3D"ltr">Then, because of the fundamental technical limitations of sc=
aling, a new system needs to be adopted for fast transactions.=C2=A0 To mai=
ntain momentum etc., the new system ultimately settles with traditional bit=
coins.</p>
<p dir=3D"ltr">In order to keep the existing brand momentum, network, and b=
usiness investment, I believe the smoothest path forward is to build a new,=
additional system re-using the bitcoin name.=C2=A0 I suggest this new syst=
em come packaged with the bitcoin core client and be referred to as QuickBi=
tcoin or qbtc or something similar.=C2=A0 As far as the public is concerned=
it could simply continue to be called bitcoin.=C2=A0 The system will work =
on top of traditional bitcoins but have a mechanism for more/faster transac=
tions.=C2=A0 Exactly what mechanism doesn't have to be perfect, it just=
needs to be reasonably secure/useful and something that the community will=
accept.</p>
<p dir=3D"ltr">I believe this is the best way to scale bitcoin while mainta=
ining the strength of its existing network,=C2=A0 community, and branding.<=
br></p>
--089e011604ba2b3002051fab3ea9--
|
