consensus rule change for TX fee safety
7 messages, 3 Mar 2016. Started by Alice Wonder.
Alice Wonder, Henning Kopp, Peter Todd, Jonas Schnelli, Jorge Timón, Marco Falke, Dave Scotese
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
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:
Quoted text (38 lines)
> 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 >
On Thu, Mar 03, 2016 at 04:04:18PM +0100, Henning Kopp via bitcoin-dev wrote:
Quoted text (4 lines)
> 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.
Bitcoin Core already implements this safety limit with the "absurd fee" limit of 10000 * the minimum relay fee. This limit is active in both the wallet and the sendrawtransaction RPC call. Additionally for the wallet there is a user configurable -maxtxfee option to limit fees set by the wallet which currently defaults to 0.1 BTC.
Hi
Quoted text (9 lines)
> 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
I don't think a such "feature" or lets say protection should be part of the consensus layer.
Such checks should be done by the tx creation clients (wallets) – or – nodes could have an option to not accept transaction with insane fees into their mempool (policy).
</jonas>
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:
Quoted text (67 lines)
> 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 >
2016-03-03 16:28 GMT+01:00 Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org>:
Quoted text (5 lines)
> Bitcoin Core already implements this safety limit with the "absurd fee" > limit of 10000 * the minimum relay fee. This limit is active in both the > wallet and the sendrawtransaction RPC call. Additionally for the wallet > there is a user configurable -maxtxfee option to limit fees set by the > wallet which currently defaults to 0.1 BTC.
It is planned for Bitcoin Core 0.13 to use -maxtxfee for both, the wallet and the RPC interface (sendrawtransaction). (c.f. https://github.com/bitcoin/bitcoin/pull/7084)
In regard to the issue, I agree with Jonas. Such large transaction fees were historically caused by no or insufficient warnings from the wallet software. And it's the responsibility of the operators to make the wallet user friendly.
Apart from that, there are legit use cases where one would want to "pay" a large transaction fee: It may be convenient for the miner to just collect the fees instead of sending back the change on their own transactions. Of course making sure to mine the high-fee tx themself. Moreover, it could increase privacy if another party decides to "wash" their bitcoins by letting the miner claim the "fee" and then have the miner send back a fraction of the fee to a fresh address. Though, this probably works best if a lot of participants are doing this.
Marco
It would be a shame to prohibit someone from rewarding whoever mines their transaction. A good example would be a transaction designed to record some information which is damning to powerful authorities, sort of like the service cryptograffiti offers. When we try to protect others by prohibiting behavior we think is foolish, we may save some fools, but at the same time, we hurt the best of us.
On Thu, Mar 3, 2016 at 7:36 AM, Jorge Timón < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (81 lines)
> 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 >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >