summaryrefslogtreecommitdiff
path: root/2c/0f34bf73fab71d1457355d6322447c65566240
blob: a8c87a48f39f54eb7df7cc2061f2985ccb822141 (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
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
Return-Path: <rgrant@rgrant.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id A7E6140A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  8 Apr 2017 04:49:06 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f177.google.com (mail-yw0-f177.google.com
	[209.85.161.177])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CE43D16A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  8 Apr 2017 04:49:05 +0000 (UTC)
Received: by mail-yw0-f177.google.com with SMTP id d191so42350319ywe.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 07 Apr 2017 21:49:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=rgrant-org.20150623.gappssmtp.com; s=20150623;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to:cc;
	bh=Lskh80Z9fn8USW66K3A4fB/uF+0k9/aHD9Q+GX/twN4=;
	b=ivg9Cmhd4C32dxRPJzGYs3dhs8x+8W5VtIzaRK9hcVcdePTGwCYmt/N8SYv3JwL258
	XKsAu2B4E/X969wnZnUPoY06GB8ktaN/iWWjLM7QFzLFXu9gluEcqsE2sl7QrBJUw94A
	VqhOhxiJcrk7SCKvmerTsMrCzcdvmDw20NFGayDBt8Ha2iGIO+ysxJAgSw97t86KfnCy
	h39zsqXdMe1Tczk9T5ZeeV1bS2nx1VlnNtX8jsMzxTen8demi0/QMdDfnA4ned7kdoy7
	r6uQd22JrREWZGu6eDAZgd8CEKdUMezLftD7IdHzBp8/Qmf2WZvdGbsB6mdGzyTZyOm7
	vcvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
	:date:message-id:subject:to:cc;
	bh=Lskh80Z9fn8USW66K3A4fB/uF+0k9/aHD9Q+GX/twN4=;
	b=FyU1+OdwTDpXBqLKDDdGw9Z2Mxi84sSn4bDVjI/pIbeWbeV+s674fjAoz1gDcyRrH3
	yskyhFT+3YQeaNzQtx7ewIFUzGdpumcfNmcs+tT+h7C7y7DxMwMDOgjphqPlPjDMz17T
	lKfXaKlTUvvX+fGcRsQjOSrTvGxaPxaURETQkstFZgJwyloHp2jeF8P/9cuTA3dxbivI
	5jr3XEVFNBJ1bwbrb1pXK9v3Q5buzXfek+0PFlrYdxAZ2hsGnEQMMywcLn6BuGYT+NoP
	GBfG/loNn8Fi/Rhn720RvkeFVMAGdqZHqyU67ZMPdypOBHeMCu0hlgzSlOqc27x3tg4v
	24pw==
X-Gm-Message-State: AFeK/H1EIVmJYJfk6ATnhYyf4uPXYs5g1b+bYRK0dBi2Nap6YEBH5yrK4LQHsbbrGhioCryubxOp4oDSIonAvQ==
X-Received: by 10.129.98.2 with SMTP id w2mr29085854ywb.336.1491626944925;
	Fri, 07 Apr 2017 21:49:04 -0700 (PDT)
MIME-Version: 1.0
Sender: rgrant@rgrant.org
Received: by 10.37.172.210 with HTTP; Fri, 7 Apr 2017 21:48:34 -0700 (PDT)
In-Reply-To: <6aTsiLggIIoxf0V0RsV1i0B_DLZasJBjUdTTQewxIZYLFHvDVv3sRCFQBNCZ91gkin6vBi_AJgYZ1tVfsnigSAo8JOvDEcQCn7eRbfeH-CA=@protonmail.com>
References: <oO9hdZXHMpEDF84P5wXwMd0JsIeRqcDGVDHjgdNWxq81WpkqCIqrdMgEHmWAmM4a6i1cxDrUkgTPp_kx7N5CZxqwWP_5MtZ5DTAF2VorCp4=@protonmail.ch>
	<G5La89Lv4mv4xT4iey5PieUSZAwELWfUFrNQV--7SvAV8-ps7W6id6Xoj-9pkq5wTJmL8WXTDKhFWWNmJecyG27BdZr9bNe51Z-PtRrAPWY=@protonmail.com>
	<CAMnpzfq1WRn_=juvur8JZ4CeOKpk2QeLoCOvszVa63MPhRjuWw@mail.gmail.com>
	<6aTsiLggIIoxf0V0RsV1i0B_DLZasJBjUdTTQewxIZYLFHvDVv3sRCFQBNCZ91gkin6vBi_AJgYZ1tVfsnigSAo8JOvDEcQCn7eRbfeH-CA=@protonmail.com>
From: Ryan Grant <bitcoin-dev@rgrant.org>
Date: Fri, 7 Apr 2017 23:48:34 -0500
X-Google-Sender-Auth: baaJbIwIrmS2Je4d0vX81C8cNVc
Message-ID: <CAMnpzfpMdikBvoJcQriS6487LmFPB4cxtVj+kQGmqhoOMfyjQg@mail.gmail.com>
To: praxeology_guy <praxeology_guy@protonmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Draft BIP: Version bits extension with guaranteed
	lock-in
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, 08 Apr 2017 04:49:06 -0000

Praxeology Guy,

On Fri, Apr 7, 2017 at 12:56 PM, praxeology_guy
<praxeology_guy@protonmail.com> wrote:
> TLDR Unless I'm missing something, your claim that a
> misconfiguration would result in a stop chain is wrong because BIP9
> only works on soft forks.

If our rule change timing is different from changes on the chain with
most work, then (extending Johnson Lau's terminology a bit) we may
experience subjective hardfork-ness; due to miners creating blocks
which the economic majority goes on to accept, though they have a less
restrictive ruleset than ours.

> The user would have to adopt a soft fork at a time where no miner
> has also done the same, and where someone creates a contradictory
> block (which normally wouldn't happen unless someone was being
> malicious).

Correct for the segwit soft fork, which is narrowing the definition
of a nonstandard transaction.  It's safe to say that if a block with a
tx violating cleanstack were to occur on a non-segwit chain, that it
was for malicious reasons.

However, some future forks - that a full node experiences as
low subjective hardfork-ness (i.e. soft forks) - might restrict
more common things.

> Never the less, I kind of like the idea of the user being notified
> when a newly activated more stringent soft fork rule caused a block
> to be rejected.  The first time it happens, a message could come up,
> and then for some time after maybe it would be logged somewhere
> easily accessible.

Sure, a nice-to-have would be a SetfLargeWorkInvalidChainFound() that
was aware as well, though clients can make these decisions themselves.