summaryrefslogtreecommitdiff
path: root/b7/f140f4e95de92ebc1c900837c068d9b969a3e2
blob: 09e5e6d82cd82a697df8824c202c7a7d6d6b81d4 (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
Return-Path: <adam.back@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 220FB720;
	Sat,  1 Apr 2017 13:18:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com
	[209.85.220.171])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 82AA3147;
	Sat,  1 Apr 2017 13:18:19 +0000 (UTC)
Received: by mail-qk0-f171.google.com with SMTP id g195so14036002qke.2;
	Sat, 01 Apr 2017 06:18:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:reply-to:from:date:message-id:subject:to:cc;
	bh=Sblz0Nih1p02FSpoNiOaC7I7l2vep3ehX1sRhu+RvBU=;
	b=mP9t44NLd+AICKeXxbHNR/S/QWxrUq9CSKI0gQkTjpW7BaLvEGEZK8dJJv0WGC69BJ
	7n32fa1l1TEhV8/ANnZM6VimoRfawxeu7qPLyIBevjbkt8uCVeNCNHTVbBJj8nBXbqeW
	EB3A/ilwkFHnL6qGogl0v+XfATsinpwoCC9eD4+WkasEB6gQoK6igx6HY5X6YkdIt8fm
	6Z0/oOKyEO+e5QK8V4wkqkOz6Aj7e799qvT4fCEkFeRuLRjtdFzkG0oXeTkHkV9NOcBT
	ii9wFXV8GcX/QRoCnyqmHav00taNZF6jmI+CmX0xywkQA1OwGeg1DVApuVGn/ulohM5D
	lQQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:reply-to:from:date:message-id
	:subject:to:cc;
	bh=Sblz0Nih1p02FSpoNiOaC7I7l2vep3ehX1sRhu+RvBU=;
	b=Qzk2gqxZ/rCXng66UjXK4+5rQ96nwgJ3bOY6LAh0zfK4esnS9AjS8AL7qlP3O4BJoS
	+CvnKnIaF4SWKyoV9rmIo7AzbDIR5hGbZRQqsCqTJlx6KIN9NiGc6WETULoxbHd80IHT
	g5VVMV6BFNN2ZUBMVSDUn7NQ1+EZKoIUl55lGNFMeined1YyPDrCTCD4smG1h7q//Vgz
	xjWt5wTLtoUjJKVczjDLmTC188+GZsiFRLewbMRjCcvKtBBLV+dRULh5r+TsZcxGrUXz
	G9bSugtPF39yi+SWNwbQXJUe3n7fKW/f73Gy6jy/EMLB7i7pnMqut78c7c00u9P+VHu7
	mHrA==
X-Gm-Message-State: AFeK/H2OmmwIaoCeyyXmBuLnFtauqR346RnsKSaNPHiEwluilBzQDeJIT2Fy8IDfZ1dhDpwifYOZjqfwRLsL8w==
X-Received: by 10.55.115.65 with SMTP id o62mr6747153qkc.286.1491052698569;
	Sat, 01 Apr 2017 06:18:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.132.102 with HTTP; Sat, 1 Apr 2017 06:18:18 -0700 (PDT)
Reply-To: bitcoin-discuss@lists.linuxfoundation.org
From: Adam Back <adam.back@gmail.com>
Date: Sat, 1 Apr 2017 15:18:18 +0200
Message-ID: <CALqxMTHjsCeyy+y-ViouHP7DBNrBGp4QxgpP2nq0uStBC10BfQ@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: bitcoin-discuss@lists.linuxfoundation.org
Subject: [bitcoin-dev] hard-fork "X+Y" compromise discussion re-run
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: Sat, 01 Apr 2017 13:18:20 -0000

I agree with everything Matt said.  This "X+Y" "compromise" is not a
new proposal and has been hashed over multiple times in the past
dating back to at least fall 2015, ignores basically all design
considerations and research over the last  years, doesn't understand
the real-politic of the delays, and so doesn't even help in the
political domain.

I have taken the liberty of making a reddit thread with some of the
previous explainers about why this doesn't work in practice (even
ignoring all politics and hypothetically assuming it was a great
all-new idea), let the discussion commence!

https://www.reddit.com/r/Bitcoin/comments/62rrlv/how_about_a_new_compromise_activate_the_existing/

UASF is a more logical step, than these "X+Y" politically motivated
hard-forks, though UASF has risks vs SegWit BIPs in flight, the delay
and risk is far lower than political hard-forks.

I have set the reply-to to bitcoin-discuss.

Adam