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 24495CAC1 for ; 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 ; Fri, 8 Mar 2019 00:09:12 +0000 (UTC) Received: by mail-it1-f171.google.com with SMTP id d125so9192213ith.1 for ; 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: In-Reply-To: From: Wilmer Paulino Date: Thu, 7 Mar 2019 16:09:01 -0800 Message-ID: To: Marco Falke , 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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