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