<div dir="ltr">How about this for mitigating this potential attack:<div><br></div><div>1. Limit the memory pool to some reasonable number of blocks-worth of transactions (e.g. 11)</div><div>2. If evicting transactions from the memory pool, prefer to evict transactions that are part of long chains of unconfirmed transactions.</div><div>3. Allow blocks to grow in size in times of high transaction demand.</div><div><br></div><div>The combination of (1) and (2) means an attacker needs to prepare lots of confirmed inputs to pull off the attack. By itself that means they MUST pay transaction fees.</div><div><br></div><div>(3) further mitigates the attack because it allows miners to just absorb fees that the attacker is throwing at miners.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 9, 2015 at 5:33 AM, Loi Luu <span dir="ltr"><<a href="mailto:loi.luuthe@gmail.com" target="_blank">loi.luuthe@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The proposed fix is to add a new rule on how<br>fees are handled. Some amount of every fee should be considered as burned<br>and can never be spent. I will propose 50% of the fee here, but there may<br>be better numbers that can be discovered prior to putting this into place.<br>If we'd like miners to continue to collect the same fees after this change,<br>we can suggest the default fee per transaction to be doubled</blockquote><div class="gmail_extra"><br></div></span><div class="gmail_extra">I would propose another practical rule rather than burning 50% of the fee. For example, you can</div><div class="gmail_extra">credit 50% of the transaction fee to the next block. Thus, the attacker cannot perform</div><div class="gmail_extra">the attack with 0-fee any more, yet you don't have to double the price of the TX fee for the fix.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div><div><div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse;color:rgb(136,136,136)"><span style="color:rgb(0,0,102)"><div>Thanks,</div><div>Loi Luu.<br></div></span></span></div></div></div><div><div class="h5">
<br><div class="gmail_quote">On Tue, Jun 9, 2015 at 4:07 AM, Raystonn . <span dir="ltr"><<a href="mailto:raystonn@hotmail.com" target="_blank">raystonn@hotmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">When implemented, the block size limit was put in place to prevent the<br>
potential for a massive block to be used as an attack to benefit the miner<br>
of that block. The theory goes that such a massive block would enrich its<br>
miner by delaying other miners who are now busy downloading and validating<br>
that huge block. The original miner of that large-block would be free to<br>
continue hashing the next block, giving it an advantage.<br>
<br>
Unfortunately, this block size limit opened a different attack. Prior to<br>
the limit, any attempt to spam the network by anyone other than someone<br>
mining their own transactions would have been economically unfeasible. As<br>
every transaction would have a fee, there would have been a real cost for<br>
every minute of spam. The end result would have been a transfer of wealth<br>
from spammer to Bitcoin miners, which would have harmed the spammers and<br>
encouraged further mining of Bitcoin, a very antifragile outcome.<br>
<br>
But now we have the block size limit. Things are very different with this<br>
feature in place. The beginning of a spam attack on the Bitcoin network<br>
will incur transaction fees, just like before. But if spam continues at a<br>
rate exceeding the block size limit long enough for transactions to be<br>
dropped from mempools, the vast majority of spam transaction fees will never<br>
have to be paid. In fact, as real users gain in desperation and pay higher<br>
fees to get their transactions through in a timely manner, the spammers will<br>
adjust their fees to minimize the cost of the attack and maximize<br>
effectiveness. Using this method, they keep their fees at a point that<br>
causes most of the spam transactions to be dropped without confirmation<br>
(free spam), while forcing a floor for transaction fees. Thus, while spam<br>
could be used by attackers to disable the network entirely, by paying<br>
high-enough fees to actually fill the blocks with spam, it can also be used<br>
by a single entity to force a transaction fee floor. Real users will be<br>
forced to pay a transaction fee higher than the majority of the spam to get<br>
their transactions confirmed. So this is an effective means for a minority<br>
of miners to force higher fees through spam attacks, even in the face of<br>
benevolent miners who would not support a higher fee floor by policy.<br>
Miners would simply have no way to fix this, as they can only put in the<br>
transactions that will fit under the block size limit.<br>
<br>
In the face of such a spam attack, Bitcoin's credibility and usability would<br>
be severely undermined. The block size limit enables this attack, and I now<br>
argue for its removal. But we can't just remove it and ignore the problem<br>
that it was intended to address. We need a new fix for the large-block<br>
problem described in the first paragraph that does not suffer from the<br>
dropped-transaction spam-attack problem that is enabled by the block size<br>
limit today. My proposal is likely to be controversial, and I'm very much<br>
open to hearing other better proposals.<br>
<br>
Large blocks created by a miner as a means to spam other miners out of<br>
competition is a problem because miners do not pay fees for their own<br>
transactions when they mine them. They collect the fees they pay. This<br>
breaks the economic barrier keeping people from spamming the network, as the<br>
spamming is essentially free. The proposed fix is to add a new rule on how<br>
fees are handled. Some amount of every fee should be considered as burned<br>
and can never be spent. I will propose 50% of the fee here, but there may<br>
be better numbers that can be discovered prior to putting this into place.<br>
If we'd like miners to continue to collect the same fees after this change,<br>
we can suggest the default fee per transaction to be doubled. Half of every<br>
fee would be burned and disappear forever, effectively distributing the<br>
value of those bitcoins across the entire money supply. The other half<br>
would be collected by the miner of the block as is done today. This<br>
solution would mean large blocks would cost a significant number of bitcoin<br>
to create, even when all of the transactions are created by the miner of<br>
that block. For this to work, we'd need to ensure a minimum fee is paid for<br>
most of the transactions in every block, and the new transaction fee rule is<br>
in place. Then the block size limit can be removed.<br>
<br>
Raystonn<br>
<br>
<br>
------------------------------------------------------------------------------<br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net" target="_blank">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
</blockquote></div><br></div></div></div></div>
<br>------------------------------------------------------------------------------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">--<br>Gavin Andresen<br></div>
</div>