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
|
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3CBFCCC67
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Mar 2019 00:53:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com
[209.85.208.42])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A051B180
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Mar 2019 00:53:09 +0000 (UTC)
Received: by mail-ed1-f42.google.com with SMTP id p27so15053046edc.6
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 07 Mar 2019 16:53:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=fF5hTtggFSGvak4hGzUJJBwsAjgLNjMjMTS6kMYoOx4=;
b=ILagmj4aJRrAT4wuPck+otpNIfKYm/9o5C5zixSmWVq2EuSnxZn6f2baEYN1AdD5H7
qbApz1pyS+n687PYoKnHzOaIAMt0t+qo3mEMcFsuibVkc4UBSO66tX1RSjHwKckyvnuG
NUKDwnzaH+U7G5vuQbHFVs4dPixDCoMlChFIjPlV2pwapVf8NHyLn+vM86hyIEscp9Zt
1/oEMpq5VZi69mElrVz9F4pjmKYvqLCMKKRN7XWcGsUWu+2akAE8NPS1+eVMfoAt16P3
JeTznx1Y5jl13/qX2Ul9ngRhiMOcf8kKbXEixZDFiiBd+tUNEAhshOSlAua29PdeoyQn
0PVQ==
X-Gm-Message-State: APjAAAUCnJWP2zLcdfoX8GjHnb9JvTwXF7ST/FA/OAeirWPG0SWQO0uW
WJF4hqAkrx/Iab8z59SMA2tLd35XwJDsRuYamau9mg==
X-Google-Smtp-Source: APXvYqwkXfRi9nhDnqPLs6isWICdW3g0dfPm9UAMs6IEsiQh+jeZaukob4UYB16nHaKjNaR+evb1ny32Y1c3TUlrryw=
X-Received: by 2002:a17:906:81d0:: with SMTP id
e16mr9766458ejx.243.1552006388277;
Thu, 07 Mar 2019 16:53:08 -0800 (PST)
MIME-Version: 1.0
References: <CAK51vgDO2Tg38XbW0pqAnO3ETJ_qf8owRsUYsTXmrf7H2yGZtw@mail.gmail.com>
<q5otmg$4vh7$1@blaine.gmane.org>
<78CAF294-56E2-477C-B46F-C65A56357820@sprovoost.nl>
<q5rm39$87ck$1@blaine.gmane.org>
In-Reply-To: <q5rm39$87ck$1@blaine.gmane.org>
From: Gregory Maxwell <greg@xiph.org>
Date: Fri, 8 Mar 2019 00:52:56 +0000
Message-ID: <CAAS2fgR5D_jo6eZp5Z09TzBg8ux8wP24=km_0O-XhLsJQPtVxw@mail.gmail.com>
To: Andreas Schildbach <andreas@schildbach.de>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
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
X-Mailman-Approved-At: Fri, 08 Mar 2019 18:57:26 +0000
Subject: Re: [bitcoin-dev] Removal of reject network messages from Bitcoin
Core (BIP61)
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, 08 Mar 2019 00:53:10 -0000
On Thu, Mar 7, 2019 at 11:46 PM Andreas Schildbach via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> First and foremost, reject messages are an indication that the
> transaction isn't going to confirm. Without these messages, we'd need to
> revert to pre-BIP61 behaviour of using a timeout for reception of
> network confirmations.
That is already required because even in the presence of perfectly
honest and cooperative hosts reject messages at most can only tell you
about first-hop behaviour. It won't even tell you if the transaction
was ever even attempted to be sent to a next hop. So alternative
handling must be provided and must be reliable for the software to
work at all regardless of reject messages.
> - Not enough fee
Rejection on low fee (over the static minimum feerate) only happens at
the point where the nodes mempool is full, which is already at a point
where you might be waiting weeks for confirmation.
Rejection causes were also not stable or reliable because the validity
criteria cannot generally be tested independently. For example, if a
transaction is queued due to missing a parent it isn't rejected
because missing the parent is often a temporary issue, but its feerate
cannot be measured without the parent. Later, when the parent is
obtained, the transaction can then be rejected due to feerate-- but no
reject is sent then.
Output already spend is often completely indistinguishable from a
missing parent and can't get rejects generated for it generally.
Similarly, the error state detected for things like invalid signatures
are often not very useful. The software knows that script execution
returned false, but in the general case _why_ it returned false is not
clear, and a straightforward high performance validation
implementation doesn't necessarily yield a good way of figuring out
and propagating up that information. (I think invalid signatures end
up returning a stack-nonempty state from validation currently, as an
example of that).
|
