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
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
|
Return-Path: <wilmer.paulino@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 24495CAC1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Mar 2019 00:09:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it1-f171.google.com (mail-it1-f171.google.com
[209.85.166.171])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B33DD180
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Mar 2019 00:09:12 +0000 (UTC)
Received: by mail-it1-f171.google.com with SMTP id d125so9192213ith.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 07 Mar 2019 16:09:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=sV9Jpm3ik/7qgFYKGheM0scjWb7InLq2m14RtNTWdEA=;
b=UmWtPTYWByVXu3K3ztZ6j0tVkZ3se+aKn3ZbWwWKiKqoglSyqXSaLbgFLNMdGK0d0P
ui+EBBBBktmlP7G8ccFKuYCSStblKTpbIPQoqWkQflIDsGkRqfaCQdXXZevVx1umV65w
tV0xOunLthKSq8lQ+k3MkKaClJNgy83L+5bUgrrWZhnmLaN5w2TOrxuX3Nubl6rQ6z0W
8N9WKLoi+HwOAzXRejIDdqixZuRArWj5dHSqZVvIzX3B8Df3lNsFSVu+PksUYBnrpYbI
590g6FqW1T0hKWcPDTxf/Y9kXpA/pXX/xRJ4PWQikfo3MCf1/cu0tb7uoBGxqAHyQN++
5yjg==
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=sV9Jpm3ik/7qgFYKGheM0scjWb7InLq2m14RtNTWdEA=;
b=ITD4IJAg5a+uoH2g6dHK4BcGxoec2O/9hrA2K7SJTaCi3aI7x34HEpXFmBQ4rlJ1M2
ImVh13sXi0D/pGJpxiVeewWL3wpWJKOdk2JXPID3ZtwlW3GIdW9Hp9eqvSjjjLmyoexy
7vwPwkgYa0aV66xIL8fpneZ22Eu4xgJ3caiFOD4sumn6yLQtHrwvd1zmEwz5gbcTF1sw
fUFyi6eDIE+2D1OK3zRFOuicb6+vjReBlbWSd1CyC64q2uhPHdz5Hywmvf3yLof4PD69
h3hBllAXq7G6B0Wzehfptpkp51rsZHpP3DWSFcBB7MkuQASAWUeeMUbki1WzaoUCWHhD
a35w==
X-Gm-Message-State: APjAAAXgGGY7/l5Yak0cbdWvSJULKzeQ2yTZTzR7747dLX+6Gi+uhU8n
/ZDakSlYTpYUwWmQpqLZ/QtIz0Qr4kBmgZh5Tnc=
X-Google-Smtp-Source: APXvYqy5tU3YQKjOmI86lSKcvcY+feg+4X/l4y3BKjmjj1dqKP2gLW41jvazIlWknpjkkLutmafi9AooP5jtsaIb+to=
X-Received: by 2002:a24:5d44:: with SMTP id w65mr7316687ita.143.1552003751913;
Thu, 07 Mar 2019 16:09:11 -0800 (PST)
MIME-Version: 1.0
References: <CAK51vgDO2Tg38XbW0pqAnO3ETJ_qf8owRsUYsTXmrf7H2yGZtw@mail.gmail.com>
In-Reply-To: <CAK51vgDO2Tg38XbW0pqAnO3ETJ_qf8owRsUYsTXmrf7H2yGZtw@mail.gmail.com>
From: Wilmer Paulino <wilmer.paulino@gmail.com>
Date: Thu, 7 Mar 2019 16:09:01 -0800
Message-ID: <CAA5BidvSesGyofaApZY43tEziHsUcOnu6108p-UYj0Lu1+PFAA@mail.gmail.com>
To: Marco Falke <falke.marco@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, 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 00:10:11 +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:09:13 -0000
Hi Marco,
> At this time, I am not aware of any software that requires this feature, and I
> would like to remove if from Bitcoin Core to make the codebase slimmer, easier
> to understand and maintain.
Neutrino[1], a light client implementation that uses BIPs 157 and 158,
currently relies on receiving reject messages from its peers when broadcasting
a transaction to the network. I've personally gone through the relevant parts
of the Bitcoin Core codebase involving reject messages and respectfully
disagree that removing it would help much in terms of comprehension and
maintainability. IMO, the benefits outweigh this small cost.
> Nodes on the network can not generally be trusted to send valid ("reject")
> messages, so this should only ever be used when connected to a trusted node.
Nodes in the network generally rely on the assumption that they are connected
to at least one honest peer, so we can actually converge on the set of honest
peers and ban/disconnect any who send an invalid reject message for a valid
transaction.
> Let us know if your application relies on this feature and you can not use any
> of the recommended alternatives:
Unfortunately, none of the recommended alternatives work for our use case. The
main thing we want to identify when broadcasting a transaction is whether is
it invalid or not. As long as it is valid, reject messages aren't required as
the light client can just rebroadcast the transaction upon every new block to
ensure it is eventually included in the chain. It can then stop rebroadcasting
it once it detects it has confirmed on-chain through its filters. However, if
it is invalid, some of the validity checks required cannot be performed by
light clients as they do not have a mempool and/or UTXO set.
Reject messages also useful when developing new light clients, as we can get
some feedback from the network on why a transaction was rejected, which helps
identify potential bugs in their transaction crafting logic. I understand that
this can be done by setting up test nodes with the flag enabled, but this
justifies that the feature should at least exist and not be completely
removed.
> * Testing the validity of a transaction can be achieved by specific RPCs:
> - `sendrawtransaction`
> - `testmempoolaccept`
These RPCs are not helpful for light clients. Even for full nodes, in the case
of `testmempoolaccept`, mempool conditions can quickly change and cause a
transaction to be rejected after the fact. One alternative would be for a
third-party to set up an endpoint where users can submit their transactions
to, but now you're placing your trust solely on them, rather than the network,
which doesn't seem like a reasonable or comparable compromise.
With that said, I believe the feature should remain enabled by default in
order to aid the light clients of the network. If we disable them by default,
no one will bother to enable them manually, and light clients won't be able to
realize they are broadcasting invalid transactions.
[1] https://github.com/lightninglabs/neutrino
- Wilmer
|
