Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit
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 I would propose another practical rule rather than burning 50% of the fee. For example, you can credit 50% of the transaction fee to the next block. Thus, the attacker cannot perform the attack with 0-fee any more, yet you don't have to double the price of the TX fee for the fix. Thanks, Loi Luu. On Tue, Jun 9, 2015 at 4:07 AM, Raystonn . rayst...@hotmail.com wrote: 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
Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit
On Tue, Jun 9, 2015 at 2:36 PM, Gavin Andresen gavinandre...@gmail.com wrote: How about this for mitigating this potential attack: 1. Limit the memory pool to some reasonable number of blocks-worth of transactions (e.g. 11) 2. If evicting transactions from the memory pool, prefer to evict transactions that are part of long chains of unconfirmed transactions. 3. Allow blocks to grow in size in times of high transaction demand. I think 2 should just be fee per kB. If the pool is full and a transaction arrives, it has to have a fee per kB that is higher than the lowest transaction in the pool. The effect is that the fee per kB threshold for getting a transaction into the memory pool increases as the attack proceeds. This means that the cost to maintain the attack increases. With replace by fee, the new transaction would have to have a fee that is more than a fixed amount more than the lowest already in the pool. I think the replace by fee code already does this. This prevents transactions with fees that increase by 1 Satoshi at a time being relayed. For allowing large blocks when block space is in high demand, you could limit the average block size. If the average was set to 1MB, the rule could be that blocks must be 2MB or lower and the total size of the a block and the previous 99 must be 100MB or lower. This gives an average of 1MB per block, but allows bursts. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit
That does sound good on the surface, but how do we enforce #1 and #2? They seem to be unenforceable, as a miner can adjust the size of the memory pool in his local source. From: Gavin Andresen Sent: Tuesday, June 09, 2015 6:36 AM To: Loi Luu Cc: Raystonn . ; Bitcoin Dev Subject: Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit How about this for mitigating this potential attack: 1. Limit the memory pool to some reasonable number of blocks-worth of transactions (e.g. 11) 2. If evicting transactions from the memory pool, prefer to evict transactions that are part of long chains of unconfirmed transactions. 3. Allow blocks to grow in size in times of high transaction demand. 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. (3) further mitigates the attack because it allows miners to just absorb fees that the attacker is throwing at miners. On Tue, Jun 9, 2015 at 5:33 AM, Loi Luu loi.luu...@gmail.com wrote: 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 I would propose another practical rule rather than burning 50% of the fee. For example, you can credit 50% of the transaction fee to the next block. Thus, the attacker cannot perform the attack with 0-fee any more, yet you don't have to double the price of the TX fee for the fix. Thanks, Loi Luu. On Tue, Jun 9, 2015 at 4:07 AM, Raystonn . rayst...@hotmail.com wrote: 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
Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit
On Tue, Jun 9, 2015 at 1:52 PM, Raystonn . rayst...@hotmail.com wrote: That does sound good on the surface, but how do we enforce #1 and #2? They seem to be unenforceable, as a miner can adjust the size of the memory pool in his local source. It doesn't have to be enforced. As long as a reasonable percentage of hash rate is following that policy an attacker that tries to flood the network will fail to prevent normal transaction traffic from going through and will just end up transferring some wealth to the miners. Although the existing default mining policy (which it seems about 70% of hashpower follows) of setting aside some space for high-priority transactions regardless of fee might also be enough to cause this attack to fail in practice. -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit
There was this wonderful technology invented a few years ago to deal with spam. It's called Hashcash. All these hacky heuristics like block size are just dancing around the problem, and the natural solution is already present in bitcoin: smaller blocks, (down to the point of individual transactions) each mined. Don't relay things that haven't been mined. As spam or transaction levels go up, mining targets for submission go up too. Of course this is a pretty serious redesign of bitcoin, and I'm not offering a concrete proposal at this time (but have one in the works, and I'd like to see others). I call the parameters of these hacky heuristics Consensus Threatening Quantities (CTQs) because changing them induces a hard fork. Bitcoin is full of them (block time, block size, target difficulty, retarget time, etc) and bitcoin would do well to face difficult redesign questions head on, and remove them entirely. (Proposal to appear...) On June 8, 2015 5:44:43 PM EDT, Peter Todd p...@petertodd.org wrote: On Mon, Jun 08, 2015 at 02:33:54PM -0700, Raystonn . wrote: the attack would be expensive. For attacks being waged to destroy Bitcoin by filling all blocks with spam transactions, the attack succeeds when the attacker is well funded. This gives well-funded private and/or public entities the means to destroy Bitcoin if they desire. This is only true after the block size limit was implemented. Without the block size limit, the spam doesn’t harm Bitcoin. It simply enriches miners at the cost of the spammers, which is a nicely antifragile quality. There will always be a blocksize limit based on technological considerations - the network has a finite bandwidth limit. Without a blocksize limit the attacker would just flood the network until the bandwidth usage became so great that consensus would fail, rendering Bitcoin both worthless, and insecure. The worst an attacker flooding the network with transactions with a blocksize limit can do is raise costs, without harming security. Keep in mind, that at some point it'd be cheaper to just 51% attack the network. Based on the current block subsidy of 25BTC/MB that's at the point where transaction fees are 25mBTC/KB, which corresponds to $2/tx fees - not that cheap, but still quite affordable for a large percentage of Bitcoin's users right now. And that's the *absolute worst-case* attack possible. -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 -- !DSPAM:55760d26244955859016385! ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development !DSPAM:55760d26244955859016385! -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit
On Mon, Jun 08, 2015 at 06:06:00PM -0400, Bob McElrath wrote: There was this wonderful technology invented a few years ago to deal with spam. It's called Hashcash. All these hacky heuristics like block size are just dancing around the problem, and the natural solution is already present in bitcoin: smaller blocks, (down to the point of individual transactions) each mined. Don't relay things that haven't been mined. As spam or transaction levels go up, mining targets for submission go up too. You know, you can think of Bitcoin as a system that maintains a ledger for transferrable hashcash... Which means transaction fees *are* paid in hashcash. -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit
On Mon, Jun 08, 2015 at 02:33:54PM -0700, Raystonn . wrote: the attack would be expensive. For attacks being waged to destroy Bitcoin by filling all blocks with spam transactions, the attack succeeds when the attacker is well funded. This gives well-funded private and/or public entities the means to destroy Bitcoin if they desire. This is only true after the block size limit was implemented. Without the block size limit, the spam doesn’t harm Bitcoin. It simply enriches miners at the cost of the spammers, which is a nicely antifragile quality. There will always be a blocksize limit based on technological considerations - the network has a finite bandwidth limit. Without a blocksize limit the attacker would just flood the network until the bandwidth usage became so great that consensus would fail, rendering Bitcoin both worthless, and insecure. The worst an attacker flooding the network with transactions with a blocksize limit can do is raise costs, without harming security. Keep in mind, that at some point it'd be cheaper to just 51% attack the network. Based on the current block subsidy of 25BTC/MB that's at the point where transaction fees are 25mBTC/KB, which corresponds to $2/tx fees - not that cheap, but still quite affordable for a large percentage of Bitcoin's users right now. And that's the *absolute worst-case* attack possible. -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit
On Mon, Jun 08, 2015 at 10:13:10PM +, Patrick Mccorry (PGR) wrote: With the 0.01mBTC/KB minimum relay fee and $230 USD/BTC that works out to about $2.3kUSD/GB of ram IIRC, the fee is 0.1mBTC, so it's $23/MB (assuming 1,000 tx * 2.3 cents) and $23k/GB (assuming $23 * 1000, as each $23 is 1mb). Only pointing out as it highlights thats it's even more expense to do. Mike Hearn reduced the minimum relay fee to 0.01mBTC/KB: https://github.com/bitcoin/bitcoin/pull/3305 -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
