[Bitcoin-ml] Transaction mining priorities.

Andrew Johnson andrew.johnson83 at gmail.com
Tue Sep 19 19:51:09 UTC 2017


Carrying the wrapper doesn't have a financial penalty, this does. The only
reason to mine is to make money, there are more complex motivations behind
the candy bar, I don't think this is a valid analogy.

On Tue, Sep 19, 2017 at 2:44 PM Edward.stockton via bitcoin-ml <
bitcoin-ml at lists.linuxfoundation.org> wrote:

> 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/ <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 <https://zander.github.io>
> *>>>* Vlog: https://vimeo.com/channels/tomscryptochannel <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 <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 <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml>
> *>>>--
> >Andrew Johnson
>
>
> _______________________________________________
> bitcoin-ml mailing list
> bitcoin-ml at lists.linuxfoundation.org
> 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/ba8a62b8/attachment.html>


More information about the bitcoin-ml mailing list