Re: [Bitcoin-development] Fee drop
On Tue, Feb 25, 2014 at 10:09:23AM -0800, Jeremy Spilman wrote: If I understand correctly, the risk here is this would open a historically large discrepancy between MIN_RELAY and the expected minimum fee to actually obtain block inclusion. I don't know if that's true, but I think that's what Peter is saying makes it different this time. That's exactly the problem. Of course every time we make a new transaction type standard we also run that risk, but at least it's a temporary situation and we can expect to get hashing power on-board fairly quickly. With such a low MIN_RELAY that's not true, and in an absolute sense, the funds required to DoS attack the network are fairly low. On Tue, 25 Feb 2014 08:55:58 -0800, Mike Hearn m...@plan99.net wrote: Nodes that are encountering memory pressure can increase their min relay fee locally until their usage fits inside their resources. It's annoying to do this by hand but by no means infeasible. Perhaps this is just another way to think of the floating fee problem. What does MIN_RELAY need to be so that my local resources stay within some reasonable limit (and 'reasonable' means different things to different nodes). We have an input gate on transactions entering mempool, we persist mempool, and I don't know the specifics but, I assume there's some expiration policy other than block inclusion to clear out a Tx from mempool. But are transactions prioritized in any way after they make it into mempool today? There's currently no expiration policy at all; that's the root of the DoS problem I was referring too. How closely should mempool selection align with the expected block inclusion? I think if they align perfectly in theory that means optimal mempool resource allocation. For example, a miner would push out cheaper transactions which they were previously hashing against to make room for higher fee transactions (bsaed on max block size or orphan rate projections), but do we do the same for mempool? E.g. - After hitting X number of transactions, the fee has to be larger than a transaction in mempool in order to get in, - That in turn that ejects a random transaction which paid less fees than the incoming Tx from mempool - We would have to consider how ejection would work with chains of unconfirmed transactions (cumulative average fee/kb?) but again in this case, you would want to 'do what miners would do' if you could Have you seen the mempool superblock design that keeps getting suggested? jgarzik has the most recent write-up here: https://github.com/bitcoin/bitcoin/issues/3723 I was working on a relatively ambitious version of it last summer that calculated the fee/KB for transactions, including depedencies, and then simply ordered the mempool with highest fee/KB first. The idea was you could then easily limit the total size of the mempool and drop transactions with the lowest fee/KB first. Transactions that paid less than the lowest fee/KB in a max-size mempool simply would not get relayed at all. Pity had to put it off for higher-priority work. What's interesting is how this makes zero-conf transactions even less safe: all you have to do to double-spend one (or more!) that pay X fee/KB is broadcast enough transactions paying X+e fee/KB to push out the unconfirmed tx from mepools around the network, then broadcast your double-spend. Obviously the economics of this are going to make attacks frequently profitable, especially if you can attack multiple targets at once. You can of course have schemes where you don't entirely drop transactions, saving, say, the inputs they spend and a transaction id, (so a rebroadcast can succeed) but that just reduces the effectiveness of the attack by a constant factor and makes it possible to get into complex situations where your funds are locked and unspendable. -- 'peter'[:-1]@petertodd.org 00011ffdfe2bfdf8f1f983bebfa160670b85afeebbd815fdf484 signature.asc Description: Digital signature -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fee drop
On Mon, Feb 24, 2014 at 11:41:16PM -0500, Peter Todd wrote: So, just to be clear, we're adding, say, a memory limited mempool or something prior to release so this fee drop doesn't open up an obvious low-risk DDoS exploit right? As we all know, the network bandwidth DoS attack mitigation strategy relies on transactions we accept to mempools getting mined, and the clearance rate of the new low-fee transactions is going to be pretty small; we've already had problems in the past with mempool growth in periods of high demand. Equally it should be obvious to people how you can create large groups of low-fee transactions, and then cheaply double-spend them with higher fee transactions to suck up network bandwidth - just like I raised for the equally foolish double-spend propagation pull-req. Of course, there's also the problem that we're basically lying to people about whether or not Bitcoin is a good medium for microtransactions. It's not. Saying otherwise by releasing software that has known and obvious DoS attack vulnerabilities that didn't exist in the previous version is irresponsible on multiple levels. Well, if your investors take money with market manipulating news stories, this is absolutely the responsible thing to do to increase shareholder value with a future opportunity to cause a crash-on-demand. Besides, if you really want microtransactions, you should be using an altcoin with faster block times, smaller market cap, and larger 'human' readable currency supply. That being said, I'd say include the change, we all know about it. What would be nice would be some exploits and attack signatures for what the DOS will look like when it hits so that those of us paying attention can make some money trading in anticipation of the market crash instead of just the guys paying for the attack. The real killer feature of Bitcoin is that we can learn from it's mistakes (and bitcoin can learn from the copycatcoins), instead of one-size-fits all fiat. -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fee drop
So, just to be clear, we're adding, say, a memory limited mempool or something prior to release so this fee drop doesn't open up an obvious low-risk DDoS exploit right? As we all know, the network bandwidth DoS attack mitigation strategy relies on transactions we accept to mempools getting mined, and the clearance rate of the new low-fee transactions is going to be pretty small; we've already had problems in the past with mempool growth in periods of high demand. Equally it should be obvious to people how you can create large groups of low-fee transactions, and then cheaply double-spend them with higher fee transactions to suck up network bandwidth - just like I raised for the equally foolish double-spend propagation pull-req. It's good that the core devs keep doing good work on these topics, thanks. Of course, there's also the problem that we're basically lying to people about whether or not Bitcoin is a good medium for microtransactions. I don't hear anyone lying. It's not. Actually, it is, and comparatively speaking, Bitcoin is better than the most common alternatives in use by people around the world. There are obvious issues (dust, how to handle fee issues moving forward, one could blather on forever about that), but again, I think core devs have done fairly well and will probably continue to do so along with many others. That's just my own 0.4 BTC though (my way of saying, at time of posting this, my own 2 cents). Saying otherwise by releasing software that has known and obvious DoS attack vulnerabilities that didn't exist in the previous version is irresponsible on multiple levels. That was not very specific. Could you be more specific? -- 'peter'[:-1]@petertodd.org b28e2818c4d8019fb71e33ec2d223f5e09394a89caccf4e2 -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fee drop
On Tue, Feb 25, 2014 at 06:25:18PM +0530, Mike Hearn wrote: Given that the fee drop puts fees in real (i.e. dollar) terms back to where they were some months ago, it seems odd to claim this is creating vulnerabilities that didn't exist in the previous version. The cost of an attack would be the same as before. No it's not. The cost is only incurred in the transactions actually get mined, and unlike before the drop appears to be well under the break-even orphan cost of transactions; we've got no reason to think the clearance rate of these low-fee transactions will be significant. But anyway, mostly I'm writing this to register my strong opposition knowing full well that I don't expect it to change your minds. -- 'peter'[:-1]@petertodd.org eb671d932a8d310e8ab963c53b2be8a27bd5de2a712c2f59 signature.asc Description: Digital signature -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fee drop
There are two possibilities. One is that the value of transactions with the new lower fee is outweighed by increased orphan costs and miners refuse to include them en-masse. Wallet authors lose the staring match and go back to setting higher fees until such a time as block propagation is optimised and the orphan costs go down. Nodes that are encountering memory pressure can increase their min relay fee locally until their usage fits inside their resources. It's annoying to do this by hand but by no means infeasible. The other is that the total value of transactions even with the lower fee is not outweighed by orphan costs. The value of a transaction is higher than its simple monetary value - the fact that Bitcoin is useful, growing and considered cheap also has a value which is impossible to calculate, but we know it's there (because Bitcoin does not exist in a vacuum and has competitors). In this case miners stop including lots of useful transactions that represent desired economic activity and are put under pressure by the community to change their policies. If all miners do this and making small blocks is considered errant behaviour, then we're back to the same situation we're in today. The possibility you're worried about - that someone does a DoS attack by flooding the network with small transactions - is only an issue in the first situation, and it is by no means the easiest or cheapest way to DoS Bitcoin. We all want to see more DoS resistance but basically any change to Bitcoin can be objected to on anti-DoS grounds at the moment, and this will remain the case until someone steps up to spend significant time on resource scheduling and code audits. -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fee drop
On Tue, Feb 25, 2014 at 10:25:58PM +0530, Mike Hearn wrote: Well, I've done my responsible disclosure, and I've got better things to do than argue with wishful thinking. There are two possibilities. One is that the value of transactions with the new lower fee is outweighed by increased orphan costs and miners refuse to include them en-masse. Wallet authors lose the staring match and go back to setting higher fees until such a time as block propagation is optimised and the orphan costs go down. Nodes that are encountering memory pressure can increase their min relay fee locally until their usage fits inside their resources. It's annoying to do this by hand but by no means infeasible. The other is that the total value of transactions even with the lower fee is not outweighed by orphan costs. The value of a transaction is higher than its simple monetary value - the fact that Bitcoin is useful, growing and considered cheap also has a value which is impossible to calculate, but we know it's there (because Bitcoin does not exist in a vacuum and has competitors). In this case miners stop including lots of useful transactions that represent desired economic activity and are put under pressure by the community to change their policies. If all miners do this and making small blocks is considered errant behaviour, then we're back to the same situation we're in today. The possibility you're worried about - that someone does a DoS attack by flooding the network with small transactions - is only an issue in the first situation, and it is by no means the easiest or cheapest way to DoS Bitcoin. We all want to see more DoS resistance but basically any change to Bitcoin can be objected to on anti-DoS grounds at the moment, and this will remain the case until someone steps up to spend significant time on resource scheduling and code audits. -- 'peter'[:-1]@petertodd.org 445db8e568846d542c86ab395137b32b2a05577afcc7c6a3 signature.asc Description: Digital signature -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fee drop
If I understand correctly, the risk here is this would open a historically large discrepancy between MIN_RELAY and the expected minimum fee to actually obtain block inclusion. I don't know if that's true, but I think that's what Peter is saying makes it different this time.The relay network does anti-spam with MIN_RELAY and MIN_DUST, but of course only transactions which hit the blockchain actually PAY the fee, so this allows lower-cost spam in the true dollar sense.I guess it comes down to how 'sharp' the edge is between staying above MIN_RELAY and staying OUT of the blockchain. In the worst case, there's a completely deterministic boundary, so an attacker can generate an infinite number of transactions which are guaranteed never to see the inside of a block, and so therefore completely free for the attacker, and all of which the network will relay (by default).On Tue, 25 Feb 2014 08:55:58 -0800, Mike Hearn m...@plan99.net wrote:Nodes that are encountering memory pressure can increase their min relay fee locally until their usage fits inside their resources. It's annoying to do this by hand but by no means infeasible. Perhaps this is just another way to think of the floating fee problem. What does MIN_RELAY need to be so that my local resources stay within some reasonable limit (and 'reasonable' means different things to different nodes).We have an input gate on transactions entering mempool, we persist mempool, and I don't know the specifics but, I assume there's some expiration policy other than block inclusion to clear out a Tx from mempool. But are transactions prioritized in any way after they make it into mempool today?How closely should mempool selection align with the expected block inclusion? I think if they align perfectly in theory that means optimal mempool resource allocation. For example, a miner would push out cheaper transactions which they were previously hashing against to make room for higher fee transactions (bsaed on max block size or orphan rate projections), but do we do the same for mempool? E.g. - After hitting X number of transactions, the fee has to be larger than a transaction in mempool in order to get in, - That in turn that ejects a random transaction which paid less fees than the incoming Tx from mempool - We would have to consider how ejection would work with chains of unconfirmed transactions (cumulative average fee/kb?) but again in this case, you would want to 'do what miners would do' if you couldThanks,Jeremy-- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fee drop
Am suggesting a (possible) mitigation of [possible flooding, etc], via some kind of discussion (potentially process BIP, related to bundling and / or randomization) not now, but down the road. However, needs more thought and analysis (you mentioned code audit?) before it could be floated around or acted on in any way shape or form. Thanks for this discussion, things to think about am watching, listening (...) There are two possibilities. One is that the value of transactions with the new lower fee is outweighed by increased orphan costs and miners refuse to include them en-masse. Wallet authors lose the staring match and go back to setting higher fees until such a time as block propagation is optimised and the orphan costs go down. Nodes that are encountering memory pressure can increase their min relay fee locally until their usage fits inside their resources. It's annoying to do this by hand but by no means infeasible. The other is that the total value of transactions even with the lower fee is not outweighed by orphan costs. The value of a transaction is higher than its simple monetary value - the fact that Bitcoin is useful, growing and considered cheap also has a value which is impossible to calculate, but we know it's there (because Bitcoin does not exist in a vacuum and has competitors). In this case miners stop including lots of useful transactions that represent desired economic activity and are put under pressure by the community to change their policies. If all miners do this and making small blocks is considered errant behaviour, then we're back to the same situation we're in today. The possibility you're worried about - that someone does a DoS attack by flooding the network with small transactions - is only an issue in the first situation, and it is by no means the easiest or cheapest way to DoS Bitcoin. We all want to see more DoS resistance but basically any change to Bitcoin can be objected to on anti-DoS grounds at the moment, and this will remain the case until someone steps up to spend significant time on resource scheduling and code audits. -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Fee drop
So, just to be clear, we're adding, say, a memory limited mempool or something prior to release so this fee drop doesn't open up an obvious low-risk DDoS exploit right? As we all know, the network bandwidth DoS attack mitigation strategy relies on transactions we accept to mempools getting mined, and the clearance rate of the new low-fee transactions is going to be pretty small; we've already had problems in the past with mempool growth in periods of high demand. Equally it should be obvious to people how you can create large groups of low-fee transactions, and then cheaply double-spend them with higher fee transactions to suck up network bandwidth - just like I raised for the equally foolish double-spend propagation pull-req. Of course, there's also the problem that we're basically lying to people about whether or not Bitcoin is a good medium for microtransactions. It's not. Saying otherwise by releasing software that has known and obvious DoS attack vulnerabilities that didn't exist in the previous version is irresponsible on multiple levels. -- 'peter'[:-1]@petertodd.org b28e2818c4d8019fb71e33ec2d223f5e09394a89caccf4e2 signature.asc Description: Digital signature -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fee drop
I quite agree with Peter, anything that can be exploited will be exploited, just like malleability was. On Tue, Feb 25, 2014 at 10:11 AM, Peter Todd p...@petertodd.org wrote: So, just to be clear, we're adding, say, a memory limited mempool or something prior to release so this fee drop doesn't open up an obvious low-risk DDoS exploit right? As we all know, the network bandwidth DoS attack mitigation strategy relies on transactions we accept to mempools getting mined, and the clearance rate of the new low-fee transactions is going to be pretty small; we've already had problems in the past with mempool growth in periods of high demand. Equally it should be obvious to people how you can create large groups of low-fee transactions, and then cheaply double-spend them with higher fee transactions to suck up network bandwidth - just like I raised for the equally foolish double-spend propagation pull-req. Of course, there's also the problem that we're basically lying to people about whether or not Bitcoin is a good medium for microtransactions. It's not. Saying otherwise by releasing software that has known and obvious DoS attack vulnerabilities that didn't exist in the previous version is irresponsible on multiple levels. -- 'peter'[:-1]@petertodd.org b28e2818c4d8019fb71e33ec2d223f5e09394a89caccf4e2 -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
