Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 82CF8B19 for ; Thu, 3 Mar 2016 15:36:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f52.google.com (mail-vk0-f52.google.com [209.85.213.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AB4C5109 for ; Thu, 3 Mar 2016 15:36:50 +0000 (UTC) Received: by mail-vk0-f52.google.com with SMTP id e185so25101770vkb.1 for ; Thu, 03 Mar 2016 07:36:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=op6Zu6VVMGDnhzzroQq5wfhyXXPp0EnIc/ANaCLZL9s=; b=thjvsdPACe3+CnfkLrBwb91Z2W48uo8KH+AEHjNI929RVtMcM5sbr2Dj52R9xrViiq 617b0df9YVC9mPIzb7yDbnZuFi3XHAM8Vp1HaOw4594aqoMGkTW4v/YuIkP7InUrS380 SmKtIyMa4/czyEJ8IrfvNF2rM/VUzl1hvAOI80vOYMkijfZh1l20+U1Sb2iZ5EU5XVKu 2xuqnTGrefEEf6gRwUFfk4AeAeGzkJP0BSATETLFAxRQ76JpJTf9i0aifLB6swMaigO6 RoCkkCOS0brr7Ia0AktkySowSyTaoawlnu4ZjRw5LHerXLW8E0hScbuYpzclxHJ44noS POPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=op6Zu6VVMGDnhzzroQq5wfhyXXPp0EnIc/ANaCLZL9s=; b=J7uQgxVboIvUXlMGIfC3lBDVDUgSmuuS+kX2pNgXeJCYCQLu4xCJpMQblIyXxG3uHc hRPgeWKvRwjQeF5dqyhXpGv7b1rN3tR3aqj2+d5bV5dmXUrrvwd13kKX9r3qVEmG1D4W 7JDLG3e9hq0NVmAB+/fMZOEgKAVdOzR6u1btuk/mFdFaI3TQxCE83fzAvvE7uTbMLnjN IkBnHnq4b29kaQiKhPgBfcsNu08s7oPEvQOUGAsQ4LChq6ulhk74wwSeX3qAJ699gZS7 ONjLXsl/Ujf0wP4BX8aIH34lgzvBeO97r0AyRDtX4T5DffBkf9ttXzJvMzmTP68y5hi7 bucQ== X-Gm-Message-State: AD7BkJLYGPnF/sYl1mwKniqWzREh+67M34f3LEZG36+Prt2tvLXc4YLeIGFO54g/9/rApSlf9kcpMFlzx6YBCA== MIME-Version: 1.0 X-Received: by 10.31.154.21 with SMTP id c21mr2414962vke.38.1457019409917; Thu, 03 Mar 2016 07:36:49 -0800 (PST) Received: by 10.31.141.73 with HTTP; Thu, 3 Mar 2016 07:36:48 -0800 (PST) Received: by 10.31.141.73 with HTTP; Thu, 3 Mar 2016 07:36:48 -0800 (PST) In-Reply-To: <20160303150418.GA2341@banane.informatik.uni-ulm.de> References: <56D835D3.9070902@librelamp.com> <20160303150418.GA2341@banane.informatik.uni-ulm.de> Date: Thu, 3 Mar 2016 16:36:48 +0100 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Henning Kopp Content-Type: multipart/alternative; boundary=001a1140ed445c1153052d26c472 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,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, 03 Mar 2016 15:37:52 +0000 Cc: Bitcoin Dev 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:36:51 -0000 --001a1140ed445c1153052d26c472 Content-Type: text/plain; charset=UTF-8 There's an absurd fee (non-consensus) check already. Maybe that check can be improved, but probably the wallet layer is more appropriate for this. On Mar 3, 2016 16:23, "Henning Kopp via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a1140ed445c1153052d26c472 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

There's=C2=A0 an absurd fee (non-consensus) check alread= y. Maybe that check can be improved, but probably the wallet layer is more = appropriate for this.

On Mar 3, 2016 16:23, "Henning Kopp via bit= coin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
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 wrot= e:
> I think the next hard fork should require a safety rule for TX fees. >
> http= s://blockchain.info/tx/6fe69404e6c12b25b60fcd56cc6dc9fb169b24608943def6dbe1= eb0a9388ed08
>
> 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, a= nd
> 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.<= br> >
> 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 che= cksum
> 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@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev
>

--
Henning Kopp
Institute of Distributed Systems
Ulm University, Germany

Office: O27 - 3402
Phone: +49 7= 31 50-24138
Web: http://www.uni-ulm.de/in/vs/~kopp
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--001a1140ed445c1153052d26c472--