summaryrefslogtreecommitdiff
path: root/b5/28ebdace1ceb765a47831ceb0a45999935c13b
blob: 2903e6ff32c7a4445858d756608588b55c67983b (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
84
85
86
87
88
89
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 0E98B93D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  8 Dec 2015 23:49:55 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 9911F145
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  8 Dec 2015 23:49:54 +0000 (UTC)
Received: from ishibashi.localnet (unknown
	[IPv6:2001:470:5:265:61b6:56a6:b03d:28d6])
	(Authenticated sender: luke-jr)
	by zinan.dashjr.org (Postfix) with ESMTPSA id B9E3A38A8071;
	Tue,  8 Dec 2015 23:48:55 +0000 (UTC)
X-Hashcash: 1:25:151208:bitcoin-dev@lists.linuxfoundation.org::YncQrjTzYC6pcfiS:dbdJ
X-Hashcash: 1:25:151208:j@toom.im::MeSFBwSkI=bX/KfK:clS7T
X-Hashcash: 1:25:151208:justus@openbitcoinprivacyproject.org::1aJ5/8pqqd0MDVT9:fp95P
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
 Jonathan Toomim <j@toom.im>
Date: Tue, 8 Dec 2015 23:48:53 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.13-gentoo; KDE/4.14.8; x86_64; ; )
References: <CAAS2fgQyVs1fAEj+vqp8E2=FRnqsgs7VUKqALNBHNxRMDsHdVg@mail.gmail.com>
	<5666FD8D.8050201@openbitcoinprivacyproject.org>
	<2030FF3C-4F65-44E6-A9D5-9CD144179994@toom.im>
In-Reply-To: <2030FF3C-4F65-44E6-A9D5-9CD144179994@toom.im>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201512082348.54788.luke@dashjr.org>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
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: Tue, 08 Dec 2015 23:49:55 -0000

On Tuesday, December 08, 2015 11:40:42 PM Jonathan Toomim via bitcoin-dev 
wrote:
> Agree. This data does not belong in the coinbase. That space is for miners
> to use, not devs.

This has never been guaranteed, nor are softforks a "dev action" in the first 
place.

> I also think that a hard fork is better for SegWit, as it reduces the size
> of fraud proofs considerably, makes the whole design more elegant and less
> kludgey, and is safer for clients who do not upgrade in a timely fashion.

How about we pursue the SegWit softfork, and at the same time* work on a 
hardfork which will simplify the proofs and reduce the kludgeyness of merge-
mining in general? Then, if the hardfork is ready before the softfork, they 
can both go together, but if not, we aren't stuck delaying the improvements of 
SegWit until the hardfork is completed.

* I have been in fact working on such a proposal for a while now, since before 
SegWit.

> I don't like the idea that SegWit would invalidate the security
> assumptions of non-upgraded clients (including SPV wallets). I think that
> for these clients, no data is better than invalid data. Better to force
> them to upgrade by cutting them off the network than to let them think
> they're validating transactions when they're not.

There isn't an option for "no data", as non-upgraded nodes in a hardfork are 
left completely vulnerable to attacking miners, even much lower hashrate than 
the 51% attack risk. So the alternatives are:
- hardfork: complete loss of all security for the old nodes
- softfork: degraded security for old nodes

Luke