summaryrefslogtreecommitdiff
path: root/6d/55deda31fff97bbb2d9786937c82fe10b5165f
blob: b85d694faa2dd95d56de5fbf4df3557534a35d38 (plain)
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
Return-Path: <dermoth@aei.ca>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id A90A2CBB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  1 Sep 2017 19:40:55 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail001.aei.ca (mail001.aei.ca [206.123.6.130])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3C4BC79
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  1 Sep 2017 19:40:54 +0000 (UTC)
Received: (qmail 26468 invoked by uid 89); 1 Sep 2017 19:40:53 -0000
Received: by simscan 1.2.0 ppid: 26455, pid: 26464, t: 0.0040s
	scanners: regex: 1.2.0 attach: 1.2.0
Received: from mail002.aei.ca (HELO mail002.contact.net) (206.123.6.132)
	by mail001.aei.ca with (DHE-RSA-AES256-SHA encrypted) SMTP;
	1 Sep 2017 19:40:53 -0000
Received: (qmail 21527 invoked by uid 89); 1 Sep 2017 19:40:53 -0000
Received: by simscan 1.2.0 ppid: 21481, pid: 21483, t: 8.5494s
	scanners: regex: 1.2.0 attach: 1.2.0 clamav: 0.97.8/m: spam: 3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,
	RP_MATCHES_RCVD autolearn=disabled version=3.3.1
Received: from dsl-66-36-132-63.mtl.aei.ca (HELO ?192.168.67.200?)
	(dermoth@66.36.132.63)
	by mail.aei.ca with ESMTPA; 1 Sep 2017 19:40:44 -0000
To: Cserveny Tamas <cserveny.tamas+bc@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Lucas Clemente Vella <lvella@gmail.com>, Tom Zander <tomz@freedommail.ch>
References: <CACY+MSO8PM89VTtKfuZiQGvAs7a7R6_4mY+onhZh9KnvwxW2uw@mail.gmail.com>
	<1570222.Uh686LP1o4@strawberry>
	<CAGCathxjDsST6xD+CvKN_3md3UcWuKqgSvV+CjaTqS4gPaPGZg@mail.gmail.com>
	<CACY+MSOPWhTnR-ZR67T1a5ZU2w4pWa6FkXsGF3_C+n3gKFCPSA@mail.gmail.com>
From: Thomas Guyot-Sionnest <dermoth@aei.ca>
Message-ID: <e9531342-db9b-ffdf-5ada-0c143eb89d9e@aei.ca>
Date: Fri, 1 Sep 2017 15:40:44 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
	Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CACY+MSOPWhTnR-ZR67T1a5ZU2w4pWa6FkXsGF3_C+n3gKFCPSA@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 01 Sep 2017 19:53:24 +0000
Subject: Re: [bitcoin-dev] Horizontal scaling of blockchain
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Fri, 01 Sep 2017 19:40:55 -0000

On 01/09/17 02:15 PM, Cserveny Tamas via bitcoin-dev wrote:
> Yes. I meant the single thread as an analogy, if a block is found,
> other blocks are worthless. (more or less) Longest chain wins.
>
> My line of though was, that currently the only way to scale with the
> traffic (and lowering the fees) is increasing the block size (which is
> hard as I learned from recent events), or reducing the complexity
> which is less secure (most likely more controversial)
>

It wouldn't be less secure as long as you adjust the confirmation
accordingly. If we decided to mine one block every minute, then your
usual 6 confirmation should become 60 confirmation. In the end, the same
amount of work will have been done to prove the transaction is legit and
so it's just as secure... Actually, one could argue since the average
hash rate over 60 block is more accurate than over 6, it's actually more
secure if you also pay attention to hash rate variation as part of the
confirmation... That help in the scenario a very large pool goes dark to
mine a sidechain.

-- 
Thomas