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
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 96BBA305
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 15:45:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com
[209.85.212.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6B9F2A7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 15:45:26 +0000 (UTC)
Received: by wicgi11 with SMTP id gi11so52854086wic.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 08:45:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=+NKK+xHSGhu8t93lFtz276Y575jQjjq0W4a1PoSCa2g=;
b=kTpX2rRMoaSqFaoTTs4AxeN0//dDwzZo37QYcOFwQvRlz172trTqj4sWg4u2ZIRVkG
088nIETjere1EIKDbEsmCd4QKAcw68wBkBTi1/ipB55EwhZBxp6yaSli5+wduCSFtsDo
klhXUy/HCXz6DmjwtTAk5Ys23j6j8pviRVEZ4KJQGhSC1FA55mNN3MncaZUPjk9YjKlt
Ey49uM5UUTt0NZlf9c8g0GmsnydO5AYhTcYAyQdaSb6fLCj3cwWJdmLcq+vnJgsLxRhx
OWd1/8CClIuZtkTCiyQ+8Hz6hQ8Ix5Nwa3XCNd2sC++XCgjYxFipgztRVgyjAld90ZRy
qJ/Q==
X-Gm-Message-State: ALoCoQkNGTuPrgpCzCeMa21scZsabsi0MycpDKpSsQxYs3lYqDWCkpfzvq54oDW9EkocpDAufAQP
MIME-Version: 1.0
X-Received: by 10.194.58.7 with SMTP id m7mr20314789wjq.109.1435506324985;
Sun, 28 Jun 2015 08:45:24 -0700 (PDT)
Received: by 10.194.95.168 with HTTP; Sun, 28 Jun 2015 08:45:24 -0700 (PDT)
In-Reply-To: <559012A9.3050606@sky-ip.org>
References: <CAPg+sBjOj9eXiDG0F6G54SVKkStF_1HRu2wzGqtFF5X_NAWy4w@mail.gmail.com>
<20150627074259.GA25420@amethyst.visucore.com>
<20150627095501.C59B541A40@smtp.hushmail.com>
<20150627100400.GC25420@amethyst.visucore.com>
<20150627102912.06E2641A3E@smtp.hushmail.com>
<CABm2gDpnzjph5SKTf+8GWgwe+njS=k2GNm9uL73RC-EV=Y5wug@mail.gmail.com>
<20150627121016.2360041A3E@smtp.hushmail.com>
<CABm2gDovynxmZmf_voz-19mmb5k0R4Snxcucx-WObt_stkAL9A@mail.gmail.com>
<559012A9.3050606@sky-ip.org>
Date: Sun, 28 Jun 2015 17:45:24 +0200
Message-ID: <CABm2gDrWfJwk3jQCC0+7JWkXAWWSuRaXLwLeUQB23GNPOQkaMA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: s7r@sky-ip.org
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,
URIBL_BLACK autolearn=no 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] The need for larger blocks
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 15:45:28 -0000
On Sun, Jun 28, 2015 at 5:28 PM, s7r <s7r@sky-ip.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> +1 for this Jorge.
> Agreed the majority should not be able to enforce rules over the
> minority. But if the majority will just leave and create an altcoin or
> whatever, this will leave the remaining minority with a less value (or
> even 0 value) product or service. By enforcing some rules agreed by
> the majority or supermajority, the minority will be dragged along and
> even so with rules they haven't signed up for, they will still have a
> product or service which is worth something.
If the Schism fork goes wrong (ie 2 chains coexist in parallel for
long) the result may as well be that NOBODY will be left any value.
Both the majority and the minority can lose simultaneusly.
See https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org#schism1-hardforks
That kind of hardfork is basically like forcing the users to go to war
against each other.
Really, I don't think civil war is an exaggerated analogy.
> That is why we have to be very careful into deciding this.
>
> This debate is good, there are lots of valid points from smart people
> and I am happy to see there is so much interest in this project, and
> regardless if the blocksize hard cap will be changed or not I do hope,
> if a hardfork will happen, it will also include a smart change that
> will allow future changes (requiring hardforks) simpler, with less
> headache and risks involved.
That sounds great. Do you have any proposal in mind?
I really want hardforks to be made, I just don't want to kill the
system attempting it.
|
