Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6BC50D0D for ; Thu, 3 Mar 2016 15:04:43 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from smtp.uni-ulm.de (smtp.uni-ulm.de [134.60.1.26]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9EB27175 for ; Thu, 3 Mar 2016 15:04:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at uni-ulm.de Received: from banane.informatik.uni-ulm.de (banane.informatik.uni-ulm.de [134.60.77.114]) (authenticated bits=0) by mail.uni-ulm.de (8.14.9/8.14.9) with ESMTP id u23F4Ndr001695 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 3 Mar 2016 16:04:31 +0100 (CET) Date: Thu, 3 Mar 2016 16:04:18 +0100 From: Henning Kopp To: Alice Wonder Message-ID: <20160303150418.GA2341@banane.informatik.uni-ulm.de> References: <56D835D3.9070902@librelamp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56D835D3.9070902@librelamp.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-DCC-INFN-TO-Metrics: poseidon 1233; Body=2 Fuz1=2 Fuz2=2 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, RP_MATCHES_RCVD 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, 03 Mar 2016 15:22:41 +0000 Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] consensus rule change for TX fee safety X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 15:04:43 -0000 Hi, I think there is no need to do a hardfork for this. Rather it should be implemented as a safety-mechanism in the client. Perhaps a warning can pop up, if one of your conditions A) or B) is met. All the best Henning Kopp On Thu, Mar 03, 2016 at 05:02:11AM -0800, Alice Wonder via bitcoin-dev wrote: > I think the next hard fork should require a safety rule for TX fees. > > https://blockchain.info/tx/6fe69404e6c12b25b60fcd56cc6dc9fb169b24608943def6dbe1eb0a9388ed08 > > 15 BTC TX fee for < 7 BTC of outputs. > > Probably either a typo or client bug. > > My guess is the user was using a client that does not adjust TX fee, and > needed to manually set it in order to get the TX in the block sooner, and > meant 15 mBTC or something. > > I suggest that either : > > A) TX fee may not be larger than sum of outputs > B) TX fee per byte may not be larger than 4X largest fee per byte in > previous block > > Either of those would have prevented this TX from going into a block. > > Many people I know are scared of bitcoin, that they will make a TX and make > a mistake they can't undo. > > Adding protections may help give confidence and there is precedence to doing > things to prevent typo blunders - a public address has a four byte checksum > to reduce the odds of a typo. > > This kind of mistake is rare, so a fix could be included in the coming HF > for the possible July 2017 block increase. > > Thank you for your time. > > Alice Wonder > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- Henning Kopp Institute of Distributed Systems Ulm University, Germany Office: O27 - 3402 Phone: +49 731 50-24138 Web: http://www.uni-ulm.de/in/vs/~kopp