[Bitcoin-ml] Transaction mining priorities.

Edward.stockton edward.stockton at protonmail.com
Tue Sep 19 18:29:45 UTC 2017


It's very easy to fall into the trap of applying game theory ideas in a naive way.

I think that's what happens when we imagine that miners are so foolish that they
are unable to think long term. So the answer to the question:

>How do you expect to convince miners to do anything but what's in their best short term interest(which is revenue maximization)?

is that miners are intelligent beings, able to understand their own long term interests
as well as their short term interests.

Basic game theory is too basic. The selfish, short-sighted ideal profit-maximizing
entity that it imagines is easy to model but it's not what people actually do, and it's
certainly not what they should do.

If we suppose that miners are trapped by their desire to earn one more satoshi
right now and will make decisions that lead to long-term disaster, then we're
not imagining real people but some simple automatons which only exist in
naive game theory analyses.

Somebody who eats a candy bar on the street might understand that he or
she can drop the candy wrapper on the ground and that this is easier than
carrying it for a few minutes until it can be deposited into a garbage can.

It would be incorrect to deduce from this that everybody will drop their
litter on the street instead of making the tiny effort needed to put it in
a garbage can.

It would be very foolish and wrong to say that people *should* drop litter
on the street, because it's slightly better for them short-term.

But that's what naive game theory says they should do.

>On Tue Sep 19 16:38:16 UTC 2017 Andrew Johnson via bitcoin-ml < [>bitcoin-ml at lists.linuxfoundation.org](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml)> wrote:

>And here's the problem with this proposal. How do you expect to convince
>miners to do anything but what's in their best short term interest(which is
>revenue maximization)?  This proposal clashes with the basic game theory
>that bitcoin is based on, I think.
>
>It sounds good in theory, and those are all noble and worthwhile goals, but
>what's the incentive for miners to prioritize transactions in this way
>instead of based on total revenue?
>
>If bitcoin needs miner altruism to survive, we've already lost...  Bitcoin
>has to work based on greedy participants doing whatever is most
>advantageous for them, not a moral sense of wanting to make the network a
>better place.  I don't think it's reasonable to expect miners to eschew
>short term revenue in favor of long term network health.
>
>Some miners may appreciate code that helps them change the way they
>prioritize transactions at their leisure(you may get some miners to run
>this alternate prioritization model occasionally when mempool fees are
>lowish), but you're definitely not going to make a consensus rule out of
>it, and you're probably not going to get a ton of participants, in my
>opinion.
>
>Which makes me wonder how effective of a use of your time this is going to
>be in the first place. If this prioritization method is used for n% of
>transactions, how much impact did it have?  Would probably need to try and
>measure the effect at different adoption rates to see if the time spent is
>worthwhile or not...
>
>On Tue, Sep 19, 2017 at 9:22 AM Jeff Garzik via bitcoin-ml <
[>bitcoin-ml at lists.linuxfoundation.org](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml)
> wrote:
>
>>

The miners have two notable incentives:

>>

>>

1) Maximize fee revenue

>>

2) Minimize time spent creating blocks

>>

>>

It has long been a goal to remove the 2nd pass through the mempool for

>>

transaction priority.  Miners will prefer fewer CPU cycles spent building

>>

new blocks, and prefer more revenue to less.

>>

>>

>>

>>

>>

>>

On Tue, Sep 19, 2017 at 7:44 AM, Tom Zander via bitcoin-ml <

>>

[bitcoin-ml at lists.linuxfoundation.org](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml)
> 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)
>>>

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
>>>

>>

>>

>>

>>

--

>>

Jeff Garzik

>>

CEO and Co Founder

>>

Bloq, Inc.

>>

>>

_______________________________________________

>>

bitcoin-ml mailing list

>>

[bitcoin-ml at lists.linuxfoundation.org](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml)
>>

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
>>

>--
>Andrew Johnson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20170919/e3666245/attachment-0001.html>


More information about the bitcoin-ml mailing list