Topic: Bug? Reduced minrelaytxfee allows creating (not just relaying) non-standard tx (Read 2912 times)

Sorry for the necropost, but I have to agree with Foxpup.

I would love the ability to set the minimum fee for transactions that my local node creates, independently of the minimum fee that will be required in order to accept transactions from others.

(earlier question removed, it seems not to be necessary anymore)

Nice, on IRC sipa told me of a third setting!  Simply use the -txfee command line option.  So, we do have 3 knobs to turn:

"mintxfee" in bitcoin.conf = Affects mined blocks that my node solves (I should be so lucky!)

"minrelaytxfee" in bitcoin.conf = Affects relayed transactions that my node receives from others

-txfee on command line (not bitcoin.conf) = Affects wallet transactions that my node originates

Is this right?

Josh

Understood. The behaviour just seems awfully counterintuitive, though.

Before the change this wasn't even exposed as a user reachable knob.

The behavior is intentional and was discussed, and the implications of lowering it were also pointed out here. If it's wise or not is, perhaps, another story.

I expect that we'd split them in the reference client when we'd lower the default, the primary intention behind adding a knob was to smooth the deployment of new relay settings by giving people an option to move relaying nodes to new rules without replacing their software.

A problem here is that the people complaining where complaining specifically about what their client would create, so unhooking creation from that wouldn't have satisfied practically any of the complaints and would have created even more testing surface area.

We've never had a wallet/relay distinction, so your read on what the relay settings did is a little off. What we've had is a _mining_ / relay distinction, and in the past the wallet used the mining setting, which was equal or more restrictive than relay. (I mention this to improve your context, for the point of what you're arguing it's a very similar thing).

(FWIW, citing 'postel's law' is perhaps not the best argument, as wise as Postel was in many ways, it is now the widely held view e.g. in standard groups that he was mistaken on that point... and the result is a legacy of many incredibility costly to maintain protocols, where obscure implementation quirks have become normative.  I see it more frequently referred to cynically than as good advice these days. It's absolutely applicable in wallet vs relay behavior though.)

Being willing to relay a transaction is a necessary, but not sufficient, condition for creating it. The client will (if mintxfee is higher than minrelaytxfee) refuse to create a transaction with insufficient fees, even if it would gladly relay such a transaction from another peer (Postel's law). That's the difference between mintxfee and minrelaytxfee. This distinction ought to apply to anything involving transaction fees, including calculation of the dust threshold, but it doesn't.

I know, and the outcome of that discussion was that people who opposed the change should just set minrelaytxfee to zero. I expected that doing so would simply allow clients to relay the non-standard transactions, while still refusing to create such transactions. Before the change, minrelaytxfee had no effect whatsoever on transactions the client created, only those it relayed from other peers (that's why it's called minrelaytxfee), and I was quite surprised when I checked the code and found this was no longer the case.

The rationale is that since a node cannot know the relay policy of the peers it connects to, it will only create transactions that it itself would relay if they came from a peer.

This was actually discussed quite a bit, but that change produced such a flood of crap posts...

As we all know, ever since the new dust definition, transactions with outputs larger than 5430 satoshis are non-standard, and the reference client with default settings will neither create nor relay such transactions. The threshold of 5430 satoshis is derived from the default transaction fee, and so will be reduced when the transactions fees are. Therefore, one might expect that reducing minrelaytxfee will allow the client to relay transactions with dust outputs, and it does.

What one might not expect, however, is that the client can also create transactions with dust outputs if minrelaytxfee is reduced, as it always uses minrelaytxfee to calculate the dust threshold. Instead, it ought to be using mintxfee instead of minrelaytxfee for transactions that it is creating instead of merely relaying, as that's the whole reason for having two separate options in the first place.