Topic: The minimum transfer fee is not trivial anymore (Read 9917 times)

The only way around that is to have some kind of charge for storage of coins in the transaction set. 

Maybe add a 1 satoshi fee to every transaction output into the mining fees.

This actually won't be that hard to work out.  The UTXO set is already held in memory as some kind of map.  You just add that count times 1 satoshi to the max allowable mining fee.

Second when a transaction is spent, you just have to look at what block the transaction was in to see how much value it has lost.

Another option would be to block old coins from being spent unless the network is notified first.  There could be a specific protocol message for that.

Having said that, miners probably would unload dust transactions to disk anyway, and not store them in RAM.  If you tried to spend them, miners might have to look for the input in a slower data store.

+1

One suggestion here is to have an option in the GUI to add the dust created by a transaction to the transaction fee.

Oh, rest assured, I'm taking notes.

(Not that I'm an altcoin developer... yet.)

The developers agree with you.  Where is the code submission?  Pull requests to do this are welcome.

+1.000011

I agree x10000! I was thinking the exact same thing just before 

+1.000001

Then how would you know when sending a transaction if you need to include a fee or not?

edit... I hadn't yet read Gavin's first post. That does sound like a much more elegant solution.

Satoshi invented that concept later.

That said, I think we should be able to get wallets defragmenting themselves. Miners have an incentive to keep the output set small so there's no reason not to accept transactions that consolidate coins of their CPU is otherwise idle, which most of the time it is. It just needs smarter rules and software.

What they're worth and how they're supposed to be used is not up to any single individual or group to decide.
Dust may be used as a way to send messages. Dust may be used in Smart Property contracts. Whatever.

My point is that what you're making here is a "judgement of value", and that's not up to the Bitcoin infrastructure to make. It's the users that should choose how they spend their coins. As long as they pay for the service being provided (and whether they're paying enough or not is up to miners to decide), and as long as the infrastructure is protected against attacks (DoS), everything is fine.

Please don't embed judgments of value in Bitcoin's backend.


I thought it was you that came up with the concept of standard and non-standard transactions.... it was there since the beginning?

Hopefully alt-coin developers take note of the lessons learned.  Or wait never mind there is no innovation to make a better coin they are just weak "I want to be richz" attempts.  Well someday someone will try to make a superior coin and hopefully they spend 6-12 months studying bitcoin to actually make a better coin.

Well that isn't exactly true.  It is possible the inclusion of the dust input lowers the priority making it low priority and thus mandating the min mandatory fee.  While improvement in coin selection is a good thing each input uses roughly 200 bytes.  You can't include many dust outputs without increasing the tx size.   Merely removing one or two dust outputs from the UXTO every couple days is like emptying the ocean with a teaspoon.  A single martingale SD player can generate a thousand or more new dust outputs in an hour or so.

There is no realistic reason why someone would need to send an amount less than the min fee.  I mean it is like mailing a penny to someone (at a cost of 46 pennies).  That small limitation would make the UXTO more efficient (a higher % of the outputs in the UXTO will actually be used in a future tx).  Note I am not saying coin selection shouldn't improve and priority should take into account uspent output reduction but something bigger is needed.

Because dust have a unique cost.  They likely will never be spent.  They just remain part of the UXTO forever.  So more dust is continually being produced but none (or very little) is being used in new tx.  Eventually on a long enough timeline the UXTO (pruned database) will run into hundreds of TBs.  It makes Bitcoin far less scalable than if the UXTO remained spendable outputs.

It is not difficult to spend dust. The problem is how bitcoind chooses coins to include. I modify my bitcoind to ignore "dust coins" when choosing coins for a transaction. Then after choosing enough non-dust coins it adds as many "dust coins" to the input as possible without pushing the transaction to the next KiB in size. This allows my wallet to stay relatively dust free automatically and does not cause extra tx fees.

Because dust outputs are more trouble than they're worth. They bloat wallets, cost more in fees to spend than they're worth (unless you go to ridiculous lengths to spend them), and are abused as a side-channel-in-the-blockchain-communication-mechanism.

If I could go back in time, I would go back and try to convince Satoshi to make them non-standard to begin with....

D&T made the same remark, to which I responded above. You'd had to filter which you would relay, and then priority vs fees kicks in. The only difference is that it's not a binary decision (has/hasn't enough fees to get relayed), it's just a way of sorting what gets relayed from what does not. You may end up relaying a transaction that today would not be relayed if there's enough "room" for it.


That's nice, better than what is done today and better than what I was saying above. Much more flexible. Nice.


Why not applying the same logic you described above? (they only get dropped if they can't fit in your memory pool)

Certainly.  Eligius will send non-standard transactions that include a certain set-by-Eligius fee.  Because non-standard transactions are not relayed, you must submit such transactions directly to Eligius.

I wish more miners would offer services like this.

However the min-fee to relay low-priority (spam) tx is much lower 0.0001 BTC (0.1 mBTC) which is currently about 1 US cent.  There probably is no reason state there is a "min-mandatory" fee for inclusion in a block (0.0005) as it isn't exactly mandatory.  Miners are free to ignore that.

Here's the thumbnail sketch on the code that I think needs to be written to handle fees properly:

1). Memory-limit the memory pool-- the set of transactions waiting in memory eligible to be included in a block. Matt Corallo has been working on that.  The limit should be a small multiple of the median block size of the last few hundred blocks.

2) Use the same algorithm/parameters/etc for adding transactions to the memory pool that we use to fill blocks.

3) Only relay transactions that fit into your memory pool.  This is the DoS prevention, your transaction won't get relayed if your node doesn't think it will end up in a block soon.

4) Estimate minimum transaction fee / priority needed to get into a block, based one:
    a) At startup:  the transactions in the last few blocks
    b) If you've been running long enough to "warm up" your memory pool:  transactions in the memory pool

5) Expose the estimate in the GUI's "suggested transaction fee" dialog.

All of that will give a floating fee that will change based on how many transactions, at what priorities/fees, are currently waiting to get into blocks.

There is one more change I'd like to make that is independent; re-define "dust" based on the floating transaction fee (e.g. a dust output is any output with a value of less than 1/4 the minimum fee-per-kb required to get into one of the next 6 blocks).  And make any transactions with dust outputs non-standard, so they're not included in the memory pool or relayed.