From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z23LD-0002Cn-85 for bitcoin-development@lists.sourceforge.net; Mon, 08 Jun 2015 20:08:15 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of hotmail.com designates 65.55.34.204 as permitted sender) client-ip=65.55.34.204; envelope-from=raystonn@hotmail.com; helo=COL004-OMC4S2.hotmail.com; Received: from col004-omc4s2.hotmail.com ([65.55.34.204]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Z23LC-0004BI-Av for bitcoin-development@lists.sourceforge.net; Mon, 08 Jun 2015 20:08:15 +0000 Received: from COL131-DS25 ([65.55.34.199]) by COL004-OMC4S2.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Mon, 8 Jun 2015 13:08:08 -0700 X-TMN: [CMv3MvztATh2JpcuvbsQhHdR0ilBVnMC] X-Originating-Email: [raystonn@hotmail.com] Message-ID: From: "Raystonn ." To: "Bitcoin Dev" References: <5574E39C.3090904@thinlink.com> In-Reply-To: <5574E39C.3090904@thinlink.com> Date: Mon, 8 Jun 2015 13:07:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-OriginalArrivalTime: 08 Jun 2015 20:08:08.0548 (UTC) FILETIME=[D688A240:01D0A226] X-Spam-Score: 0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.2 STOX_REPLY_TYPE STOX_REPLY_TYPE -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raystonn[at]hotmail.com) -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [65.55.34.204 listed in list.dnswl.org] 1.9 STOX_REPLY_TYPE_WITHOUT_QUOTES STOX_REPLY_TYPE_WITHOUT_QUOTES X-Headers-End: 1Z23LC-0004BI-Av Subject: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 20:08:15 -0000 When implemented, the block size limit was put in place to prevent the potential for a massive block to be used as an attack to benefit the miner of that block. The theory goes that such a massive block would enrich its miner by delaying other miners who are now busy downloading and validating that huge block. The original miner of that large-block would be free to continue hashing the next block, giving it an advantage. Unfortunately, this block size limit opened a different attack. Prior to the limit, any attempt to spam the network by anyone other than someone mining their own transactions would have been economically unfeasible. As every transaction would have a fee, there would have been a real cost for every minute of spam. The end result would have been a transfer of wealth from spammer to Bitcoin miners, which would have harmed the spammers and encouraged further mining of Bitcoin, a very antifragile outcome. But now we have the block size limit. Things are very different with this feature in place. The beginning of a spam attack on the Bitcoin network will incur transaction fees, just like before. But if spam continues at a rate exceeding the block size limit long enough for transactions to be dropped from mempools, the vast majority of spam transaction fees will never have to be paid. In fact, as real users gain in desperation and pay higher fees to get their transactions through in a timely manner, the spammers will adjust their fees to minimize the cost of the attack and maximize effectiveness. Using this method, they keep their fees at a point that causes most of the spam transactions to be dropped without confirmation (free spam), while forcing a floor for transaction fees. Thus, while spam could be used by attackers to disable the network entirely, by paying high-enough fees to actually fill the blocks with spam, it can also be used by a single entity to force a transaction fee floor. Real users will be forced to pay a transaction fee higher than the majority of the spam to get their transactions confirmed. So this is an effective means for a minority of miners to force higher fees through spam attacks, even in the face of benevolent miners who would not support a higher fee floor by policy. Miners would simply have no way to fix this, as they can only put in the transactions that will fit under the block size limit. In the face of such a spam attack, Bitcoin's credibility and usability would be severely undermined. The block size limit enables this attack, and I now argue for its removal. But we can't just remove it and ignore the problem that it was intended to address. We need a new fix for the large-block problem described in the first paragraph that does not suffer from the dropped-transaction spam-attack problem that is enabled by the block size limit today. My proposal is likely to be controversial, and I'm very much open to hearing other better proposals. Large blocks created by a miner as a means to spam other miners out of competition is a problem because miners do not pay fees for their own transactions when they mine them. They collect the fees they pay. This breaks the economic barrier keeping people from spamming the network, as the spamming is essentially free. The proposed fix is to add a new rule on how fees are handled. Some amount of every fee should be considered as burned and can never be spent. I will propose 50% of the fee here, but there may be better numbers that can be discovered prior to putting this into place. If we'd like miners to continue to collect the same fees after this change, we can suggest the default fee per transaction to be doubled. Half of every fee would be burned and disappear forever, effectively distributing the value of those bitcoins across the entire money supply. The other half would be collected by the miner of the block as is done today. This solution would mean large blocks would cost a significant number of bitcoin to create, even when all of the transactions are created by the miner of that block. For this to work, we'd need to ensure a minimum fee is paid for most of the transactions in every block, and the new transaction fee rule is in place. Then the block size limit can be removed. Raystonn