Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A0B0ED35F for ; Thu, 7 Mar 2019 14:05:29 +0000 (UTC) X-Greylist: delayed 00:05:38 by SQLgrey-1.7.6 Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0CF6AD3 for ; Thu, 7 Mar 2019 14:05:28 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 70E2122291; Thu, 7 Mar 2019 08:59:50 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 07 Mar 2019 08:59:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sprovoost.nl; h= from:content-type:content-transfer-encoding:mime-version:subject :date:references:to:in-reply-to:message-id; s=fm2; bh=zel/LzqTX5 o88p/31C8rY0s7s3JYpqRpOJUH+CAYMrI=; b=Y2A3/B7QQ6naBocHdWI+TMvDJA XmkbXkI7BLPKtlY3XN5rYFn9k/r5KPodTrxqrnN1+iCqrI4J1BMi7Fbk1ZXTem76 NsyUcfCXLD0pTC9FXVskjgEFurmrrtp9PbIfpLvnVVXBnjZIEYZ4hU4OTgeaiGKw sAjKrI7YnYdIZm+FZkIUfQiUz8GWt6HC+M2PYck3LrgwXtNG5Lub7J4rd0YI6MU4 wAWG33g9pZMr9eY4NgHW3bkAP6ymttwqK0hlVGZjjvXAMybqF40hYEqDvSE9/N3v LRBjGUbJNZKPyEWFuA9odQQrbgNzk6dmHjrBpii0VzmszPHVM/YsaV7WLbBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=zel/LzqTX5o88p/31C8rY0s7s3JYpqRpOJUH+CAYM rI=; b=LDruTQZq/Z4JV4L5vODFM8ykJz1B4vkd9y++AVPdOwawPWu+xnNaQ/rAv pf8F6InMHWHzj7Eq6N4dBlhGhtOpZI0Lx7GO0RMG2/LbMkzepy4dU+eD+ZT+pb8N L+md8C6xVye144PLInPE1nO6i7HAJxLXShLyEn7862Ld3MoPPZZFekJxZW+nFrlk 2OgImdIIOfcLY1Ou68Rja/kpuWJOLhc0zOcgyu+7wBTCpDjJEKlEIVdut21stnrc PKqlJ+8+fCqC7eSt9G+f9irMStLXlY/yFtCf3nLlspmZFg+UcC1/gIHLfwXchwGA uhxadP83VPLZeLo/TRMEuF9Ra1PIA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrfeekgdeitdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhtgfgggfuffhfvfgjkffosehtqhhmtdhhtddvnecuhfhrohhmpefujhhorhhs ucfrrhhovhhoohhsthcuoehsjhhorhhssehsphhrohhvohhoshhtrdhnlheqnecuffhomh grihhnpehlihhnuhigfhhouhhnuggrthhiohhnrdhorhhgnecukfhppeekgedruddthedr iedurdduheenucfrrghrrghmpehmrghilhhfrhhomhepshhjohhrshesshhprhhovhhooh hsthdrnhhlnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from [192.168.178.185] (54693d0f.cm-12-2a.dynamic.ziggo.nl [84.105.61.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 2A65CE408B; Thu, 7 Mar 2019 08:59:49 -0500 (EST) From: Sjors Provoost Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 7 Mar 2019 14:59:47 +0100 References: To: Andreas Schildbach , Bitcoin Protocol Discussion In-Reply-To: Message-Id: <78CAF294-56E2-477C-B46F-C65A56357820@sprovoost.nl> X-Mailer: Apple Mail (2.3445.102.3) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW 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: Thu, 07 Mar 2019 14:29:49 +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 14:05:29 -0000 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: >=20 > 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). >=20 > 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. >=20 > I strongly suggest re-enabling reject messages by default before 0.18. >=20 >=20 > 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. >>=20 >> 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: >>=20 >> * 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=3D`) to a stream (`-printtoconsole`) or to a file >> (`-debuglogfile=3D`). >>=20 >> * 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 >>=20 >> * Testing the validity of a transaction can be achieved by specific = RPCs: >> - `sendrawtransaction` >> - `testmempoolaccept` >>=20 >> * 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. >>=20 >> I propose to remove "reject" messages from Bitcoin Core 0.19.0 unless = there are >> valid concerns about its removal. >>=20 >> Marco >>=20 >=20 >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev