consensus rule change for TX fee safety

consensus rule change for TX fee safety
2016-03-03 15:04 ` Henning Kopp
  2016-03-03 15:29 ` Jonas Schnelli
  
From: Alice Wonder @ 2016-03-03 13:02 UTC (permalink / raw)
  To: 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


 permalink raw reply	[|nested]
2016-03-03 13:02 [bitcoin-dev] consensus rule change for TX fee safety Alice Wonder

  2016-03-03 15:28   ` Peter Todd
  2016-03-03 15:36   ` Jorge Timón
  2016-03-03 15:29 ` Jonas Schnelli
  
From: Henning Kopp @ 2016-03-03 15:04 UTC (permalink / raw)
  To: Alice Wonder;  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


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


 permalink raw reply	[|nested]
2016-03-03 15:04 ` Henning Kopp

  2016-03-03 15:55     ` Marco Falke
  2016-03-03 15:36   ` Jorge Timón
  
From: Peter Todd @ 2016-03-03 15:28 UTC (permalink / raw)
  To: Henning Kopp;  bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 751 bytes --]

On Thu, Mar 03, 2016 at 04:04:18PM +0100, Henning Kopp via bitcoin-dev 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.

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.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
0000000000000000024eabe5049843ea6d73558e960d6bcead9e91a24cab1161

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

 permalink raw reply	[|nested]
2016-03-03 13:02 [bitcoin-dev] consensus rule change for TX fee safety Alice Wonder
  2016-03-03 15:04 ` Henning Kopp

  
From: Jonas Schnelli @ 2016-03-03 15:29 UTC (permalink / raw)
  To: bitcoin-dev


[-- Attachment #1.1: Type: text/plain, Size: 652 bytes --]

Hi

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

 permalink raw reply	[|nested]
2016-03-03 15:04 ` Henning Kopp
  2016-03-03 15:28   ` Peter Todd

  2016-03-03 16:38     ` Dave Scotese
  
From: Jorge Timón @ 2016-03-03 15:36 UTC (permalink / raw)
  To: Henning Kopp;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 2344 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 3528 bytes --]

 permalink raw reply	[|nested]
2016-03-03 15:28   ` Peter Todd

  
From: Marco Falke @ 2016-03-03 15:55 UTC (permalink / raw)
  Cc: bitcoin-dev

2016-03-03 16:28 GMT+01:00 Peter Todd via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org>:
> 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


 permalink raw reply	[|nested]
2016-03-03 15:36   ` Jorge Timón

  
From: Dave Scotese @ 2016-03-03 16:38 UTC (permalink / raw)
  To: Jorge Timón;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 3642 bytes --]

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:

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


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

[-- Attachment #2: Type: text/html, Size: 5473 bytes --]

 permalink raw reply	[|nested]