[Bitcoin-ml] Transaction mining priorities.

Jared Lee Richardson jaredr26 at gmail.com
Tue Sep 19 13:59:05 UTC 2017

This is better than nothing, but an even better approach would be a
change to the consensus rules so tiny outputs can be closed without
incurring heavy fees.  Front-loading the fees onto the UTXO creation
event would solve the problem.  Since that requires a hardfork and
can't be done any time soon, this seems like a good approach.  How do
you plan on weighting the different 1-5 elements?

On Tue, Sep 19, 2017 at 4:44 AM, Tom Zander via bitcoin-ml
<bitcoin-ml at lists.linuxfoundation.org> wrote:
> I’m writing here to ask for feedback before I implement this in Classic.
> This is a copy of a less technical and more aimed at the broad audience text
> on Yours.
> https://www.yours.org/content/
> 3135d4927234a736b972e6f669aba8d78c3ef74ce87facfb68c2ad055a9dec03
> Transactions are picked by the miners currently based on the amount of fees
> they pay. Zero-fee transactions have been seen as people taking advantage of
> the system for some time. And I think its time to look at this and find out
> if that actually makes sense.
> I want to propose that miners start to prioritize transactions based on the
> properties of the individual transaction. The higher the priority, the
> better chance of inclusion in the next block. The factors of giving priority
> are;
> 1. Coin-age of spent coin (days-destroyed). Older is better.
> 2. Ratio of inputs to outputs in one transaction. More inputs is better.
> 3. Sigops count. Less is better.
> 4. Transaction size in bytes. Smaller is better.
> 5. Fees paid to the miner.
> This change essentially means that if your transaction scores high in any of
> the first items, that means the fee you need to pay to get mined goes down.
> The reason we have been told fees were good is because they would protect us
> against spam attacks.
> And I see that need, if we drop fees then people could create many many
> transactions with the effect that if I went and tried to pay my beer in the
> pub, it would not go through. We can't ignore that threat.
> I would argue that this problem can be solved much better with "Coin Age".
> Money I received a month ago would have a higher priority to be mined. This
> makes sense because it rate-limits the "spammer" to one transaction a month
> if his goal is to stop me from being able to spend my money. So the longer a
> coin is untouched, the higher priority it gets.
> If a spammer spends tons of 10 minute old coins, it would have no effect on
> real uses transactions that in general are quite a bit older.
> Point 2 is a bit more complex.
> A transaction that has outputs consumes space in the UTXO (unspent
> transaction output) database. Its inputs remove rows in that database. So
> stating we prefer a ratio where the database gets smaller is a good idea.
> Especially if that means people can pay a lower fee to get their transaction
> mined.
> But that is not the full story.
> Imagine how a mining pool, or even Yours is handling transactions. There are
> a lot of people paying very small amounts to a single person. Each payment
> to you is added to your balance, but on the blockchain you have hundreds of
> inputs to sign in order to move that money afterwards. At some point
> creation of a single output is useless because it would be too expensive to
> spend it later (due to fees).
> With point 2 giving a higher priority the natural consequence is that
> spending those hundreds of tiny transactions you received requires a much
> lower fee. And this brings into question the setting of the 'dust limit'.
> We can probably significantly lower the dust limit when its no longer a
> problem to spend inputs that are not holding a lot of value each
> individually.
> How do you see this priority table? Is it better than the current one that
> only looks at fees?
> How would you feel about the implied effect to lower the dust limits?
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> _______________________________________________
> bitcoin-ml mailing list
> bitcoin-ml at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml

More information about the bitcoin-ml mailing list