From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0DBFFC9B for ; Wed, 6 Mar 2019 00:53:33 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A9807180 for ; Wed, 6 Mar 2019 00:53:31 +0000 (UTC) Received: by mail-lj1-f175.google.com with SMTP id d14so9292525ljl.9 for ; Tue, 05 Mar 2019 16:53:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=uj20FOvGtVqh0VbHBGwQFLWFo1SMiD2oD4XEW7k+gWo=; b=ch7Mf11DxOW5cTDkKdzP83OraacE7/b6p2dtM4gO8Ny+RA4EF0u+LS9pMPbR1A7qXQ ngCTCPAEelQ+6Sb9I1eHYBWEEnhywR000Mhe9PebeRqkJ8h4n9wNZDPirhkQofLXKn0M vDP7NQdeYK0xn68Q8V4dxUB+pId1VUx6f9KkuEPzIQeQhadd++Bdkw/uppXqAHsIurd/ kSlhlYhAHrTSIt7MCVjlwT7E8HCnim3EeANdJJ57Ul8K5qvI8+VS6Oi+neHK416Nh0NX 5Cns+20Y2X278/7N/VnH0UT/LZ42fEBR2hlQSMUCyZq7VWns6FSnpRu9+HtbcjjAnl9C T+Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=uj20FOvGtVqh0VbHBGwQFLWFo1SMiD2oD4XEW7k+gWo=; b=kVeJCxr4cgbGsq60kuPTYpA/mtL2NDN1FOG7kN7xOO6/yJpeDPl4QggP3k5oZY/Urb JSgGht6GVUjBJMTKdQ5ut1crhd5KKPMPacrqRspqg57tmy7uPBY864LYPT0T9+QOW+Cz 4kLjchw3Jgc/JP5FT7Ofe4hthStvqpfZB3dKHJasZ15VhAaQ6gg3Q3YJpYJNCDX6OmUl u0eK4fRC1QEQDzIbwi7EM2k2GUhYb3IZPePFXtqZyhqpZL0YasKBnIsALt2+VmWjhQUO NWyZixXS/9olR6HpG5ynWxFUBSBTEHBV7Y7dcTF7fQV7zEG5wzcSpWYNZV0hIWY3xjjM APmw== X-Gm-Message-State: APjAAAWcZD/rB+4qN8OPKcktzQHUNDmZsOGBcZ5VhQ0ufbeBIFIpXgof C3xwig9mAdwgHs0F8yQ9KBeRf1jP178M8DLoUSU8DBXP X-Google-Smtp-Source: APXvYqziGC4I+ZWIq7OH3/wMTgzmqqJVyK8+Uh9XvokcF7KoiqkHZKOFs9VHmKYTalxTc1yNLtS+FcNXpiv7Zivg8+o= X-Received: by 2002:a2e:8585:: with SMTP id b5mr758210lji.125.1551833609810; Tue, 05 Mar 2019 16:53:29 -0800 (PST) MIME-Version: 1.0 From: Marco Falke Date: Tue, 5 Mar 2019 19:53:18 -0500 Message-ID: To: Bitcoin Protocol Discussion 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: Wed, 06 Mar 2019 03:00:37 +0000 Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 00:53:33 -0000 Bitcoin Core may send "reject" messages as response to "tx", "block" or "version" messages from a network peer when the message could not be accepted. This feature is toggled by the `-enablebip61` command line option and has been disabled by default since Bitcoin Core version 0.18.0 (not yet released as of time of writing). 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. 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. Let us know if your application relies on this feature and you can not use any of the recommended alternatives: * Testing or debugging of implementations of the Bitcoin P2P network protocol should be done by inspecting the log messages that are produced by a recent version of Bitcoin Core. Bitcoin Core logs debug messages (`-debug=`) to a stream (`-printtoconsole`) or to a file (`-debuglogfile=`). * Testing the validity of a block can be achieved by specific RPCs: - `submitblock` - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with potentially invalid POW * Testing the validity of a transaction can be achieved by specific RPCs: - `sendrawtransaction` - `testmempoolaccept` * Wallets should not use the absence of "reject" messages to indicate a transaction has propagated the network, nor should wallets use "reject" messages to set transaction fees. Wallets should rather use fee estimation to determine transaction fees and set replace-by-fee if desired. Thus, they could wait until the transaction has confirmed (taking into account the fee target they set (compare the RPC `estimatesmartfee`)) or listen for the transaction announcement by other network peers to check for propagation. I propose to remove "reject" messages from Bitcoin Core 0.19.0 unless there are valid concerns about its removal. Marco