[bitcoin-dev] consensus rule change for TX fee safety

[Alice Wonder via bitcoin-dev]

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

[Henning Kopp via bitcoin-dev]

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

Post by Alice Wonder via bitcoin-dev
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.
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Peter Todd via bitcoin-dev]

Post by Henning Kopp via bitcoin-dev
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.

[Marco Falke via bitcoin-dev]

2016-03-03 16:28 GMT+01:00 Peter Todd via bitcoin-dev

Post by Peter Todd via bitcoin-dev
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

[Jorge Timón via bitcoin-dev]

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" <

Post by Henning Kopp via bitcoin-dev
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

Post by Alice Wonder via bitcoin-dev
I think the next hard fork should require a safety rule for TX fees.

https://blockchain.info/tx/6fe69404e6c12b25b60fcd56cc6dc9fb169b24608943def6dbe1eb0a9388ed08

Post by Alice Wonder via bitcoin-dev
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.
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

Post by Alice Wonder via bitcoin-dev
a mistake they can't undo.
Adding protections may help give confidence and there is precedence to

doing

Post by Alice Wonder via bitcoin-dev
things to prevent typo blunders - a public address has a four byte

checksum

Post by Alice Wonder via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--
Henning Kopp
Institute of Distributed Systems
Ulm University, Germany
Office: O27 - 3402
Phone: [phone]
Web: http://www.uni-ulm.de/in/vs/~kopp
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Dave Scotese via bitcoin-dev]

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 <

Post by Jorge Timón via bitcoin-dev
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" <

Post by Henning Kopp via bitcoin-dev
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

Post by Alice Wonder via bitcoin-dev
I think the next hard fork should require a safety rule for TX fees.

https://blockchain.info/tx/6fe69404e6c12b25b60fcd56cc6dc9fb169b24608943def6dbe1eb0a9388ed08

Post by Alice Wonder via bitcoin-dev
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

Post by Alice Wonder via bitcoin-dev
meant 15 mBTC or something.
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

Post by Alice Wonder via bitcoin-dev
a mistake they can't undo.
Adding protections may help give confidence and there is precedence to

doing

Post by Alice Wonder via bitcoin-dev
things to prevent typo blunders - a public address has a four byte

checksum

Post by Alice Wonder via bitcoin-dev
to reduce the odds of a typo.
This kind of mistake is rare, so a fix could be included in the coming

HF

Post by Alice Wonder via bitcoin-dev
for the possible July 2017 block increase.
Thank you for your time.
Alice Wonder
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--
Henning Kopp
Institute of Distributed Systems
Ulm University, Germany
Office: O27 - 3402
Phone: [phone]
Web: http://www.uni-ulm.de/in/vs/~kopp
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto

[Jonas Schnelli via bitcoin-dev]

Hi

Post by Alice Wonder via bitcoin-dev
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.
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>