• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Dash Improvement Proposal: Reject transactions containing excessive fees using masternode network

HinnomTX

HinnomTX

Active member
As many of you are aware, from time to time there's a post on /r/bitcoin where everyone takes in the schadenfreude from the poor sap who accidentally sent a 4 BTC transaction fee with his 1 BTC purchase. The poor guy has to go running to the miners to beg them for a refund. Apparently the miners do sometimes send the mistaken fee back, and sometimes not.

Obviously, a well designed wallet should not even allow such crazy fees to be sent, but somehow they happen anyway. The improvement proposal I would like to float is to let the DASH masternode network monitor transactions, and when a transaction with out of the ordinary fee is seen by the network, it rejects the transaction.

Does building this functionality into the protocol seem like excessive policing, or would this be viewed as a user friendly failsafe that puts DASH at an advantage to its competitors?
 
Last edited by a moderator:
Talking of which, I wish I had the option to set a "claim by" date on transactions I send. For example, I could give a taxi driver a paper tip for them to claim by a certain date... if they don't bother to collect then at least the money isn't lost.
 
meh - not really liking a 'charge-back' idea
but I see your point
Some kinda contract that expires - meh
 
I don't like it right now, but maybe in Evolution when we have decentralized account objects, each user could have the option to set a maximum fee amount above which the network will reject transactions coming from that account.
 
HinnomTX said:
I'm not the best code reader, but this looks to be a failsafe check for the QT wallet. I was looking for some checking logic from a masternode's point of view. How can this prevent a third party wallet from allowing a transaction with insane fee to be broadcast?
Click to expand...
I don't think it should. That should be an option for people who want to, and most wallets will already warn if a TX fee is unusually large (I'm pretty sure Electrum does this).

More importantly, this would feel like we're turning into a nanny-crypto instead of the network just doing what it's told, whether or not it's in the best interest of the user.

An example of what I mean (and what this feels like):

Windows won't let you do a lot of things they consider "bad", even if you want to. It's incredibly frustrating for power-users and admins. UNIX/Linux just does what it's told, regardless. That freedom is why I have loved and continue to love those OS flavours, even if they do allow me to shoot myself in the foot.
 
nmarley said:
I don't think it should. That should be an option for people who want to, and most wallets will already warn if a TX fee is unusually large (I'm pretty sure Electrum does this).

More importantly, this would feel like we're turning into a nanny-crypto instead of the network just doing what it's told, whether or not it's in the best interest of the user.

An example of what I mean (and what this feels like):

Windows won't let you do a lot of things they consider "bad", even if you want to. It's incredibly frustrating for power-users and admins. UNIX/Linux just does what it's told, regardless. That freedom is why I have loved and continue to love those OS flavours, even if they do allow me to shoot myself in the foot.
Click to expand...

I can appreciate being a power user. Like actually logging in as root, or fiddling with dd or rm -rf .
It's certainly worth doing a bit more research to understand how these high fee transactions occur. My guess is they happen despite a warning message, as a distracted or impatient user clicks through the dialog box. Maybe the fees should be hidden (like in Breadwallet) or be completely unalterable unless a 'testmode=1' field is placed in the dash.conf file, for example. The key to this approach would be to have consistently failsafe behavior in every 3rd party wallet.
 
HinnomTX said:
I can appreciate being a power user. Like actually logging in as root, or fiddling with dd or rm -rf .
It's certainly worth doing a bit more research to understand how these high fee transactions occur. My guess is they happen despite a warning message, as a distracted or impatient user clicks through the dialog box. Maybe the fees should be hidden (like in Breadwallet) or be completely unalterable unless a 'testmode=1' field is placed in the dash.conf file, for example. The key to this approach would be to have consistently failsafe behavior in every 3rd party wallet.
Click to expand...
Afaik qt is smart enough to actually restrict user to send transactions with insane fees now (i.e. it does not only warn but actually stops you from doing do). So imo currently it's a power user only (or some service) who can shoot himself in the foot by doing createrawtransaction without including change address or miscalculating the amount to be sent or smth like this (leftover is sent to fees by design).
 
HinnomTX said:
My guess is they happen despite a warning message, as a distracted or impatient user clicks through the dialog box.
Click to expand...

UdjinM6 said:
Afaik qt is smart enough to actually restrict user to send transactions with insane fees now (i.e. it does not only warn but actually stops you from doing do). So imo currently it's a power user only (or some service) who can shoot himself in the foot by doing createrawtransaction without including change address or miscalculating the amount to be sent or smth like this (leftover is sent to fees by design).
Click to expand...

So it seems like the few ones that do happen (and this completely makes sense) is when people are fiddling with creating their own transactions and forget to send change back to themselves (thus creating a high fee). Which makes complete sense.

Now if only we could get people to use testnet for things like this instead of mainnet. It can be an expensive lesson though, so I'm sure people don't do it more than once.
 
You must log in or register to reply here.
Back
Top