Re: [Bitcoin-development] Lexicographical Indexing of Transaction Inputs and Outputs
Hey Peter, thanks for your experienced feedback. On Sat, Jun 6, 2015 at 10:35 PM, Peter Todd p...@petertodd.org wrote: Why mention SIGHASH_SINGLE at all? Its use-case is highly specialized protocols; you haven't taken into account the needs of those protocols. For BIP's it's better to stick to the use-cases where the need is clear and there exists running code that to speculate too much on future uses. With signature hashing in particular it's not yet clear at all what future OP_CHECKSIG's will look like, let alone the various ways people will use sighash for smart contract type stuff. You'd be better off presenting the BIP in terms of a generic statement that except when otherwise prevented by advanced signature hashing requirements, wallet software must emit transactions sorted according to the following You can then specify the two common cases in detail: 1) SIGHASH_ALL: input and output order signed, so sort appropriately 2) SIGHASH_ANYONECANPAY: input order not signed, so software should emit transactions sorted, recognising that the actual mined order may be changed. That makes sense. I updated the language as follows -- your thoughts? Keep in mind this BIP is informational, and so people are free to ignore it. Applicability: This BIP applies to all transactions of signature hash type SIGHASH_ALL. Additionally, software compliant with this BIP that allows later parties to update the transaction (e.g. using signature hash types SIGHASH_NONE or a variant of SIGHASH_ANYONECANPAY) should emit lexicographically sorted inputs and outputs, although they may later be modified. Transactions that have index dependencies between transactions or within the same transaction are covered under the section of this BIP entitled “Handling Input/Output Dependencies.” As for IsStandard() rules - let alone soft forks - better to leave discussion of them out for now. In particular, for the soft-fork case mandating certain transaction orders will very likely cause problems in the future for future OP_CHECKSIG upgrades. For SIGHASH_ANYONECANPAY, it might be appropriate for nodes to enforce a certain ordering, but that can be a separate BIP. (actually implementing that in Bitcoin Core would be annoying and ugly right now; without replace-by-fee ANYONECANPAY has a silly DoS attack (adding low-fee inputs) so I can't recommend wallets use it in the general case yet) and a sequence number currently set to 0x. - Actually, this will be changed in Bitcoin Core as of v0.11.0, which implements anti-fee-sniping w/ nLockTime.(1) (I need to write up a full BIP describing it) Thanks for the heads-up; removed. Do you have a patch implementing deterministic tx ordering for Bitcoin Core yet? I'm not a frequent C programmer, so I'd prefer to let someone else take care of it, as a frequent committer of code would do a faster and more stylistically consistent job of it. If no one else will, however, I will. -Kristov -- ___ 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 blocksize limit
On Mon, Jun 8, 2015 at 11:01 PM, Raystonn . rayst...@hotmail.com wrote: No, with no blocksize limit, a spammer would would flood the network with transactions until they ran out of money. I think you are forgetting even if you remove the blocksize limit, there is still a hard message size limit imposed by the p2p protocol. Block would de-facto be limited to this size. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions
On Mon, Jun 08, 2015 at 02:25:40PM -0700, Danny Thorpe wrote: FWIW, The Open Assets colored coin protocol (CoinPrism) places special significance on the zeroth input and the position of the OP_RETURN colored coin marker output to distinguish colored coin issuance outputs from transfer outputs. Reordering the inputs or the outputs breaks the colored coin representation. Recommending sorting of the inputs and outputs as a best practice is fine (and better than random, IMO), but not as part of IsStandard() or consensus rules. There are cases where the order of the inputs and outputs is significant. Timestamping is another case where order matters: if you put the digest in the last vout you can use SHA256 midstate's to reduce the size of the timestamp proof. Anyway, there's no reason to rush re: changes to IsStandard() -- '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 blocksize limit
Bitcoin is a global consensus system - if you're (sic) bandwidth isn't sufficient to keep up you are not part of the consensus. Bandwidth can be purchased. Infrastructure to handled increasing transaction volume can be purchased. The very fees being paid by a spammer will be used to increase the miners' ability to absorb even more fees. The blocksize limit cannot respond in such a dynamic way to attacks. Miners cannot buy a greater blocksize limit in response to a spammer that is paying high fees to deny transaction confirmation to the rest of the planet in an attempt to destroy the network. The blocksize limit is creating an attack that can be maintained forever by any organization that can afford to fill the blocks. This attack would get incredibly cheaper once the BTCUSD market tanks in response to the lack of usability of the Bitcoin network, meaning it would be a self-reinforcing attack that would likely destroy Bitcoin for as long as an attacker wants to keep it up, or until you patch it to remove the limit after-the-fact, which might be too little too late. If this isn't fixed, I would expect to see it carried out at some point by someone with a large short position in BTCUSD. -Original Message- From: Peter Todd Sent: Monday, June 08, 2015 3:18 PM To: Raystonn . Cc: Patrick Mccorry (PGR) ; Bitcoin Dev Subject: Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit On Mon, Jun 08, 2015 at 03:01:34PM -0700, Raystonn . wrote: There will always be a blocksize limit based on technological considerations - the network has a finite bandwidth limit. A bandwidth limit is not the same as a blocksize limit. Bandwidth is unique to every individual. Miners in China have different bandwidth and connectivity than miners in the U.S., for example. But the block size limit is dictated for eveyone. They are not comparable. Bitcoin is a global consensus system - if you're bandwidth isn't sufficient to keep up you are not part of the consensus. The blocksize limit *is* what determines the minimum bandwidth required to stay in consensus. 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. No, with no blocksize limit, a spammer would would flood the network with transactions until they ran out of money. Meanwhile, everyone would jump on board trying to mine the blocks to collect the fees from the spammers. It could be one of the greatest transfers of wealth ever. Bitcoin infrastructure would build up to handle the required bandwidth, paid for by the very entity spamming the network. Bitcoin would flourish, growing wildly as long as the fees kept coming. This is antifragility at its best. Again, in your scenario if the bandwidth consumed by those transactions was sufficiently high, the network would collapse because consensus would fail. Why wouldn't that bandwidth be high enough to cause that collapse? Because of the blocksize limit! (combined with an intelligent mempool that increases the minimum fee/KB appropriately - we don't have that yet) The worst an attacker flooding the network with transactions with a blocksize limit can do is raise costs, without harming security. No, at attacker flooding the network with transactions with a blocksize limit can keep their fees high enough that perhaps 1% of transactions coming from real end-users go through. At this point everyone would give up on Bitcoin as it would become completely unusable. The BTCUSD market would tank, making it even easier to pay the transaction fees to keep real transactions out of blocks, as it would continue to become cheaper and eventually cost-free to obtain the bitcoin fees through market purchase. I already did the math for you on that: the maximum transaction fee you'd see in that kind of attack is around $2.5 USD/tx. That definitely is not high enough to make Bitcoin non-viable - I personally could easily afford fees like that for about 90% of my transactions this year by value, as I mainly use Bitcoin to get paid by my clients around the world. In fact, just today O'Reilly paid $15 USD to send me a wire transfer for expenses related to a conference I was invited too. A much more realistic transaction flood scenario - one that didn't raise serious questions about whether or not the attacker could afford to 51% attack Bitcoin - would raise tx fees to something more like $0.25/tx -- ___ 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 blocksize limit
Not forgetting, simply deferring discussion on that. We’ve a much smaller limit to deal with right now. But even that limit would have to go to remove this attack. From: Btc Drak Sent: Monday, June 08, 2015 3:07 PM To: Raystonn . Cc: Peter Todd ; Bitcoin Dev ; Patrick Mccorry (PGR) Subject: Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit On Mon, Jun 8, 2015 at 11:01 PM, Raystonn . rayst...@hotmail.com wrote: No, with no blocksize limit, a spammer would would flood the network with transactions until they ran out of money. I think you are forgetting even if you remove the blocksize limit, there is still a hard message size limit imposed by the p2p protocol. Block would de-facto be limited to this size.-- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Lexicographical Indexing of Transaction Inputs and Outputs
As for IsStandard() rules - let alone soft forks - better to leave discussion of them out for now. Removed that bit as well. Latest version: https://github.com/kristovatlas/rfc/blob/master/bips/bip-li01.mediawiki -Kristov -- ___ 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 blocksize limit
the only way a transaction can be removed from a Bitcoin Core mempool is through it getting mined, double-spent, or the node restarting. Right. And that results in some transactions with insufficient fees getting dropped today after many hours. The protection that we have against that attack is that you need access to a lot of bitcoins to pay enough fees. That's no protection against a well-funded private and/or public entity. Without the block size limit, this attack doesn't exist. It would simply result in a transfer of wealth from spammer to miners, which is a nicely antifragile response for the Bitcoin network. -Original Message- From: Peter Todd Sent: Monday, June 08, 2015 2:33 PM To: Raystonn . Cc: Patrick Mccorry (PGR) ; Bitcoin Dev Subject: Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit there is no memory pool cap currently Real hardware does not have an infinite amount of RAM. Memory pool sizes cannot grow unbounded. Some transactions with insufficient fees do get dropped today after many hours. Actually they don't, which is an unfortunate problem with the existing mempool implementation; the only way a transaction can be removed from a Bitcoin Core mempool is through it getting mined, double-spent, or the node restarting. The protection that we have against that attack is that you need access to a lot of bitcoins to pay enough fees. With the 0.01mBTC/KB minimum relay fee and $230 USD/BTC that works out to about $2.3kUSD/GB of ram consumed, and furthermore, actually getting that many transactions to propagate over the network is non-trivial. (no, I'm not going to tell you how) The obvious solution is to cap the size of the mempool and evict transactions lowest fee/KB first, but if you do that they you (further) break zeroconf security. On the other hand, if you don't break zeroconf security an attacker can prevent reasonable fee transactions from propagating. I probably should get around to fixing this... -- ___ 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 blocksize limit
On Mon, Jun 08, 2015 at 03:01:34PM -0700, Raystonn . wrote: There will always be a blocksize limit based on technological considerations - the network has a finite bandwidth limit. A bandwidth limit is not the same as a blocksize limit. Bandwidth is unique to every individual. Miners in China have different bandwidth and connectivity than miners in the U.S., for example. But the block size limit is dictated for eveyone. They are not comparable. Bitcoin is a global consensus system - if you're bandwidth isn't sufficient to keep up you are not part of the consensus. The blocksize limit *is* what determines the minimum bandwidth required to stay in consensus. 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. No, with no blocksize limit, a spammer would would flood the network with transactions until they ran out of money. Meanwhile, everyone would jump on board trying to mine the blocks to collect the fees from the spammers. It could be one of the greatest transfers of wealth ever. Bitcoin infrastructure would build up to handle the required bandwidth, paid for by the very entity spamming the network. Bitcoin would flourish, growing wildly as long as the fees kept coming. This is antifragility at its best. Again, in your scenario if the bandwidth consumed by those transactions was sufficiently high, the network would collapse because consensus would fail. Why wouldn't that bandwidth be high enough to cause that collapse? Because of the blocksize limit! (combined with an intelligent mempool that increases the minimum fee/KB appropriately - we don't have that yet) The worst an attacker flooding the network with transactions with a blocksize limit can do is raise costs, without harming security. No, at attacker flooding the network with transactions with a blocksize limit can keep their fees high enough that perhaps 1% of transactions coming from real end-users go through. At this point everyone would give up on Bitcoin as it would become completely unusable. The BTCUSD market would tank, making it even easier to pay the transaction fees to keep real transactions out of blocks, as it would continue to become cheaper and eventually cost-free to obtain the bitcoin fees through market purchase. I already did the math for you on that: the maximum transaction fee you'd see in that kind of attack is around $2.5 USD/tx. That definitely is not high enough to make Bitcoin non-viable - I personally could easily afford fees like that for about 90% of my transactions this year by value, as I mainly use Bitcoin to get paid by my clients around the world. In fact, just today O'Reilly paid $15 USD to send me a wire transfer for expenses related to a conference I was invited too. A much more realistic transaction flood scenario - one that didn't raise serious questions about whether or not the attacker could afford to 51% attack Bitcoin - would raise tx fees to something more like $0.25/tx -- '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 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 blocksize limit
There will always be a blocksize limit based on technological considerations - the network has a finite bandwidth limit. A bandwidth limit is not the same as a blocksize limit. Bandwidth is unique to every individual. Miners in China have different bandwidth and connectivity than miners in the U.S., for example. But the block size limit is dictated for eveyone. They are not comparable. 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. No, with no blocksize limit, a spammer would would flood the network with transactions until they ran out of money. Meanwhile, everyone would jump on board trying to mine the blocks to collect the fees from the spammers. It could be one of the greatest transfers of wealth ever. Bitcoin infrastructure would build up to handle the required bandwidth, paid for by the very entity spamming the network. Bitcoin would flourish, growing wildly as long as the fees kept coming. This is antifragility at its best. The worst an attacker flooding the network with transactions with a blocksize limit can do is raise costs, without harming security. No, at attacker flooding the network with transactions with a blocksize limit can keep their fees high enough that perhaps 1% of transactions coming from real end-users go through. At this point everyone would give up on Bitcoin as it would become completely unusable. The BTCUSD market would tank, making it even easier to pay the transaction fees to keep real transactions out of blocks, as it would continue to become cheaper and eventually cost-free to obtain the bitcoin fees through market purchase. -Original Message- From: Peter Todd Sent: Monday, June 08, 2015 2:44 PM To: Raystonn . Cc: Patrick Mccorry (PGR) ; Bitcoin Dev Subject: Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize 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. -- ___ 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