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 1B904C579 for ; Thu, 7 Mar 2019 17:58:12 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from blaine.gmane.org (unknown [195.159.176.226]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 28B4C180 for ; Thu, 7 Mar 2019 17:58:11 +0000 (UTC) Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1h1xHT-00005n-9W for bitcoin-dev@lists.linuxfoundation.org; Thu, 07 Mar 2019 18:58:07 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bitcoin-dev@lists.linuxfoundation.org From: Andreas Schildbach Date: Thu, 7 Mar 2019 18:58:01 +0100 Message-ID: References: <78CAF294-56E2-477C-B46F-C65A56357820@sprovoost.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Openpgp: preference=signencrypt Autocrypt: addr=andreas@schildbach.de; keydata= xsDiBD/S9DARBACgg0IF3cCFaNXbQtCAZBpiZRawQAfsfL87sHhy1xq3UwR4RmQKsWjtZQ9C 7kSDTkzzn7Sqg+YtXgiJdGeYinSMy+6mBKQjtrIKLikbjB1ORTfA29m7m7VTBY9X3Cvmpm0+ 0mWvrQ9hSpq8adXitY4Z+/VB/1YSo77RakfNr3sQOwCgzrXH37AlAu307IgOOFnI1y78Y4cD /29gtaY3/u8ThFI/mXBOHnfXaIVGLYKtlf2Lyj2JnixhhzxEpuDJ0lkcyNQ0N7Ky8ohJS3tG ShwHjsQNtqK2V1DomsUnDI/W4hJNCSd0zfIoQgHvE1RbOyOpz4F+CNw8uQcxwE5FmwRtk6xa zJsiMVKLFhKr6LnMoVaNi8mZZFKzA/9HcXAse5epfrZD1tt7dHr58+egIA0OkoQ8oUgqCgN1 4qmUxQoWTdmvet0E+XaHcowr1fXu79uQ2zuvHSk/S4mjP6uT+XOxENVcKRUtyEBtSzFDyyCj 853KrBQSppCgxS8loHj1g1YIKqu97kGVtfmHM9L9TPVA1opuYOcJh7iJ9s0qQW5kcmVhcyBT Y2hpbGRiYWNoIDxhbmRyZWFzQHNjaGlsZGJhY2guZGU+wl4EExECAB4FAj/S9DACGwMGCwkI BwMCAxUCAwMWAgECHgECF4AACgkQymYr4YuHemD4NACePnpSANmR2vrZVv+BteOva6gzOJ0A nioa6JoKCYx3jQOIqoBGcBUkc8q1zsFNBD/S9DgQCACctel4AnL7nuh+Uv+IBz0GMvu6Ewdn sVCOLf54neIxuaW4BC5RYAdS6Tkp3hxv+ZfA0Uv6X3nz4tOsVHD50+CCq51pRlnbUwcWcn9e nynJyddTjei+JmJrdOJOAzWa/al8YagjQSZqgD6mmPUy/a201Bh0L2zbLmxQMFg+PPB81j4y UmSXmhYzg/+SonZ3lr9pJNtoZszg95NDyYBceiF5RSw4Qusi+C5/W3nIKzuaIKZijE9Dvo6D W6ggbB/gSxDTSjvrnvvXeG1SdlKLeFvsJ9y/0ro3EP01RRVJvA5RaM5W2MRbwGuSRcSw8B74 6ijEOqSh0IYLXoHdV7Vj4Qt/AAMFB/9ZcgxVGvs2ob6MCTVdPLlVKRKDn7RjZiDE6hRa/jp7 ewdstjjc22DU/jCz16IX75B/sr1cDJqbChONFdljjQNWe2cTFXSazUjsyZa35+KvehDi7cAU +vCYmisMpkPM41hR6HYqjadDp6gOVJTnHPcJ6EPdgUQTsNQH3dCTD68b5WwzBEBNLdwyDGLK McExzaOClwwSeHBmnj72O7Chdhn/M/2+fpTUPqhp/0sflVyR/ILyc/KEp85pwani2dXuZ02i gSaSIBwQJOVrjsUTwp2Wxdmywt13/cGGVlsGLe8lY0Kv6G43/eip+42OfIVhxRgARRtJ5KjK chTLwfl3tbgawkkEGBECAAkFAj/S9DgCGwwACgkQymYr4YuHemAWjACgtRlmiISVlCf7/mum klJfLM6wKIMAnA2uS1BS4d7GJkQp09ViaWmUUsMc In-Reply-To: <78CAF294-56E2-477C-B46F-C65A56357820@sprovoost.nl> Content-Language: en-US X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_ADSP_ALL, RDNS_NONE autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 07 Mar 2019 23:46:12 +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: Thu, 07 Mar 2019 17:58:12 -0000 Yes, I'm talking about P2P connections. 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. Regarding the content, these cases are useful to distinguish: - Not enough fee - UTXO already spent - Tx validity/standardness (e.g. invalid signature) While the last one in theority wouldn't be necessary if you produced your software bug-free to begin with, this just isn't how software development works. Developers need any indication they can get. The first two happen even in the ideal case. Fees are impossible to predict, and unintentional double spends happen because users clone their wallet state. On 07/03/2019 14.59, Sjors Provoost via bitcoin-dev wrote: > Can you elaborate a bit on what kind of reject messages your users are getting? I assume the users wallet connects directly to the Bitcoin p2p network? > > What does the wallet do when a transaction is rejected? Does it forget about it (that seems unsafe) or compose another one (with overlapping inputs)? > > Sjors > >> Op 6 mrt. 2019, om 17:49 heeft Andreas Schildbach via bitcoin-dev het volgende geschreven: >> >> Reject messages cannot be replaced for debugging user problems. At least >> unless you plan to make RPC or bitcoind logfiles available via the P2P >> protocol (both probably not a good idea). >> >> The typical case is, I get mailed a wallet logfile with reject messages >> and that's all I have. I cannot access the bitcoind logfile(s) of the >> node(s) that generated the reject message in the first place. Nor can I >> access their RPC interface. >> >> I strongly suggest re-enabling reject messages by default before 0.18. >> >> >> On 06/03/2019 01.53, Marco Falke via bitcoin-dev wrote: >>> 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 >>> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev