Re: [Bitcoin-development] Anti DoS for tx replacement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Apr 17, 2013 at 9:48 AM, Mike Hearn m...@plan99.net wrote: So it'd be nice if this ended up not being necessary. Experience indicates that rational miners typically don't pursue a short-termist profit-at-any-cost agenda - free transactions have always been included in blocks, miners include transactions even though you could avoid a lot of complexity by just not including any at all, etc. Some miners like BTC Guild have actually sacrificed significant amounts of money for the good of the system. You can see this in terms of rational self interest - miners earn Bitcoins thus it's in their interest for Bitcoins to be as useful as possible, as that is what gives them value. Or you can see it in terms of ideologically-driven altruism. Or both. Please don't say Gavin agrees with you. This reminds me of discussing security in the early days of the internet when the general assumption that everyone played nice was still correct. We're seeing huge, expensive, DoS attacks against mining pools, exchanges, information sites, stores etc. Bitcoin has enemies. Peter Todd is 100% correct, tx replacement is another form of zero confirmation transaction and all that has to happen is some subset of mining power start doing replace by tx fee for it to have no security while with your proposed implementation opening up a DoS attack vector. You also see the DoS attack vector as unimportant and suggest to handle it as a prioritization problem. real world experience indicates that people don't pointlessly mount attacks over and over again if there's nothing to be gained by doing so. - of course there is something to be gained, shutting down a service dependent on tx replacement, as seen by all the DoS attacks we are seeing. If I were deciding if my service should use tx replacement and I understood that it could be trivially shut down, I sure wouldn't be happy I could just warn users not to take advantage of the feature whilst the flood is in progress Gavin do you actually agree with Mike on this stuff like he implies? Because if you do, I think people should know. Myself I wouldn't want to be contributing to your salary as a foundation member if you don't take Bitcoin security seriously. The rapidly-adjusted payments stuff on the Contracts page of the wiki is broken in multiple ways: 1. (known) Requires DoS vulnerable infrastructure. 2. (known) TX mutability 3. (unknown?) Just doesn't work. Step 5 is to check that T2 is signed correctly by the access point, and if so, sign T1 and T2. But the signature of T2 includes the txid of T1 and that isn't known until T1 is fully signed. That #3 has not been noticed before shows that for all this hot air no-one has ever bothered making an implementation of the idea. So Mike, why are you happy to make testnet vulnerable to an unusually easy DoS attack for an idea you haven't even tried on your own private testnet with replacement enabled? Anyway, with Peter Todd's much saner tx-replacement-by-fee the following can be done: 1. Create a new public key PK1 2. Request a public key PK2 from the access point. 2. Create TX1 with two inputs and two outputs. Both parties sign it and broadcast it. access point input - 2 PK1 PK2 checkmultisig, value = input #1 - fee you input - 2 PK1 PK2 checkmultisig, value == input #2 - fee 3. Create TX2. TX1 #1 - pay to access point PK2 TX1 #2 - pay to yourself PK1 (change) Set TX2 nLockTime to some time in the future. 4. Set the initial value's of TX2 out #1 and out #2 to the value the access point and you committed in TX1. Both parties sign with SIGHASH_SINGLE. (which means both parties are signing for both inputs) 5. Update TX2 as required and sign both inputs. The access point doesn't need to sign TX2 or give the updated copy of TX2 to the other party. The TX is not broadcast when updated (like the earlier contract proposal) although doing so harms no-one. When the session ends with both parties online, do the following: 1. You sign a version of TX2 with the final output values and nLockTime=0 2. If the final output values are acceptable to the access point, they sign the other half of the 2-of-2 inputs and broadcast. (with whatever fees required) If the buyer quits the session abruptly: 1. Access point signs the last (most funds) version of TX2 given to them, waits until the nLockTime expires, and broadcasts. This also gets their TX1 input back. If the access point quits abruptly they can do the above when they go back online. The buyer has the first, signed, version of TX2 and at worst can broadcast it eventually to get their deposit back. Attacks: After TX1 is signed and broadcast both parties are in on the contract together, so the funds can't move without the consent of the other. Both parties can block the movement of the other's deposit, but they lose their deposit too. With tx mutability there is a small window of time for a technical mistake, but that
Re: [Bitcoin-development] Anti DoS for tx replacement
When did I say DoS was unimportant? I just wrote a giant email explaining how it can be resolved. I think it's worth pointing out that Bitcoin was launched with no DoS protection at all, and it's still here. There are still obvious DoS bugs being fixed with every release. So yes, it's important to robustify the code, but not to the extent of not having any features. If Satoshi had taken that perspective Bitcoin might not exist at all. We can have our cake and eat it. RE: shutting down services dependent on replacement. No, good users of replacement would still end up taking priority over the constantly churning DoS replacements. The most you can shut down is one contract. Obviously, if there's no form of tx replacement at all then the tried and doesn't work state is the same as never tried, which doesn't seem like a win. The testnet is trivially DoSable today by anyone who cares to do so, there are hardly any nodes and most people get coins from the faucet. Look at how quickly people got upset when somebody drained it. As Jeff has pointed out, there could theoretically be a nextnet but the overhead of setting one up doesn't seem worth it. If somebody wanted to troll developers they could easily DoS testnet and nextnet simultaneously with bandwidth to spare. That #3 has not been noticed before shows that for all this hot air no-one has ever bothered making an implementation of the idea. Yes, I noticed it a few days ago when making some notes, but figured I would indeed make an prototype implementation and then just put all the details and latest protocols on the wiki at once. As nobody indeed noticed the bug for years apparently nobody else is working on this so it didn't seem urgent to update. Your proposed alternative doesn't seem any different DoS wise. Someone can still broadcast a long series of incrementally different transactions and have miners replace them. So you still need prioritisation of work. It's useful anyway for other reasons. And as you point out yourself, it's still susceptible to the problem that you end up running out of money because it's all been spent on fees. BTW $500 is rather low for the amount of work required. If you added a zero onto that there might be more takers. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Anti DoS for tx replacement
On Thu, Apr 18, 2013 at 10:32:24AM +0200, Mike Hearn wrote: RE: shutting down services dependent on replacement. No, good users of replacement would still end up taking priority over the constantly churning DoS replacements. The most you can shut down is one contract. Obviously, if there's no form of tx replacement at all then the tried and doesn't work state is the same as never tried, which doesn't seem like a win. Yeah, an attack is a bit more subtle than perhaps John Dillon realizes. Assuming that nodes prioritize the transactions with the fewest total replacements first it becomes a multiplier on the standard attack of just broadcasting transactions. So for non-replacement users it's probably not that bad. An attack still shuts down useful tx replacement though. For instance in the adjusting payments example an attacker sets up a legit adjusting payment channel, does a bunch of adjustments, and then launches their attack. They broadcast enough adjustments that their adjustment session looks like part of an attack, and then don't have to pay for the full adjusted amount. What's worse, the attack itself can be just a large number of these micropayment sessions, IE, no bogus sessions at all. The testnet is trivially DoSable today by anyone who cares to do so, there are hardly any nodes and most people get coins from the faucet. Look at how It's *easily* DoSable, not trivially. Testnet has all the same fee/priority rules that Bitcoin has, so any attack still costs some amount of coins. For instance I did the math once on what it would cost to flood testnet with 1MB blocks, and it came out to IIRC $100/month or so in terms of lost mining revenue. Small, but still not trivial. non-final nLockTime floods and timewarp assisted can be easily done mind you, but the former is easy to fix and the latter is relatively tricky to pull off and still requires some mining expenditure. Your proposed alternative doesn't seem any different DoS wise. Someone can still broadcast a long series of incrementally different transactions and have miners replace them. So you still need prioritisation of work. It's useful anyway for other reasons. And as you point out yourself, it's still susceptible to the problem that you end up running out of money because it's all been spent on fees. John's proposing something that would work in conjunction with fees, so it's no different than the MIN_RELAY_FEE that has quite successfully prevented flooding on mainnet. For that matter, what he proposed can be used even with non-final == non-standard, which means the replacement transactions can't be broadcast onto the network at all until they can be mined. Actually, that's an interesting point: one way to do replacement anti-DoS would be to only allow each input a given number of chances to do a replacement. Provided your design is asymmetric in who the attacker would be, and the inputs controlled by the defender outnumber the attacker, the defender can always count on doing the last replacement. You would need some way of determining which input was responsible for a replacement though - I can't think of an obvious way to within the current transaction format, but I haven't thought hard about it yet. How exactly do you envision replacement working with non-final == non-standard anyway? BTW $500 is rather low for the amount of work required. If you added a zero onto that there might be more takers. If he's reasonable about the scope, IE just a initial implementation for further evaluation, I figure it's about two days work. $250/day is enough that I'd give it a go - I already looked into how to implement it anyway. -- 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Anti DoS for tx replacement
On Thu, Apr 18, 2013 at 05:04:44AM -0400, Peter Todd wrote: An attack still shuts down useful tx replacement though. For instance in the adjusting payments example an attacker sets up a legit adjusting payment channel, does a bunch of adjustments, and then launches their attack. They broadcast enough adjustments that their adjustment session looks like part of an attack, and then don't have to pay for the full adjusted amount. ...and actually, that's not a problem if the defender is online, because they can just broadcast the highest sequence numbered tx, which blocks further broadcasts by the attacker. You still need some way of distinguishing the two acts, by time is probably fine, but it'd make a real attack difficult. Of course, regardless you are still asking nodes to set aside however many KB/second to tx replacement transactions, and they're all going to use different settings, which makes overall network convergence impossible to guarantee as legit replacement transactions outnumber non-legit ones. Any protocol requiring the broadcast of more than one or two replacements, either normally or against an attacker, just isn't going to be reliable. But many don't, so they're probably doable. But lets see some working code first... -- 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Anti DoS for tx replacement
An attack still shuts down useful tx replacement though. For instance in the adjusting payments example an attacker sets up a legit adjusting payment channel, does a bunch of adjustments, and then launches their attack. They broadcast enough adjustments that their adjustment session looks like part of an attack, and then don't have to pay for the full adjusted amount. It's possible, but let's do some back of the envelope calculations to look at how quickly such an attack can exhaust itself. Consider a contract that has a time window of 12 hours and is adjusted once per second for that duration. That's 43,200 adjustments. It sounds sort of ballpark-ish for micropayments. If you end up losing 1 seconds worth of service, well, probably that's no big deal. As the contract reaches its nLockTime, the attacker starts broadcasting all of the adjustments in sequence in the hope that an earlier version will be being processed as the lock time expires and a block is solved, so the latest version (the one that gives him the least money) ends up not being included in the chain. The input is a multi-signature transaction, so to process every single adjustment created would take 86,400 signature verifications. With the sipaspeed patches it seems ECDSA can be processed on modern cores at something like 20,000 signatures per second. So it'd take a bit over 4 seconds to process all of them (cpu time). That gives the attacker a less than 4 second window in which to try and roll back the contract to an earlier time before he reaches the last version and things are as they should be. Given that a block is solved on average every 10 minutes, you'd have to get very lucky indeed to succeed with such an attack. It's probably easier to try and find a corrupt miner who is willing to bend the rules for you. Let's include bandwidth. Say the contract (multi-sig input + the outputs) is about 700 bytes. 43,200 transactions is then about 29 megabytes of data. On a fairly normal 10mbit connection that would take about 23 seconds to transfer. Of course the real number is a bit higher because of latency introduced by the inv/tx round-tripping. So the time window of the attack is dominated by bandwidth but it's still quite small compared to the block solving window. It's *easily* DoSable, not trivially. What I meant is - find some open DNS resolvers, start firing packets at testnet nodes, done. You don't have to do protocol level attacks to just render nodes useless. You would need some way of determining which input was responsible for a replacement though - I can't think of an obvious way to within the current transaction format, but I haven't thought hard about it yet. Ah, I think it actually is possible and this is an intriguing idea. Each input has its own sequence number. Look at the definition of IsNewerThan() - to make a newer version you increment your inputs sequence number in a particular manner whilst leaving the others alone. Having a single multi-sig input means you can't do that because both parties co-operate to update the single input, but schemes that use multiple inputs do seem posible. How exactly do you envision replacement working with non-final == non-standard anyway? As I said at the bottom of my second mail, it means making non-final transactions relayable again, but only to nodes that advertise a high enough version number. Those nodes are expected to do something intelligent with them, like just not put them in the wallet (unless the user has opted in and ticked the i know what i'm doing box, perhaps). If he's reasonable about the scope, IE just a initial implementation for further evaluation, I figure it's about two days work. Well, it depends on your use case - you need to cast the (fixed) algorithm into a network protocol, manage the interactions between the parties, monitor the network for malicious broadcasts so you can replace them, fix the code so the wallets don't accept non-final transactions except when taking part in your contract, etc. If you do it all with Bitcoin-Qt it's easier but then your app can't easily run in places that can't afford a few hundred megs of ram (like wifi hotspots). The devil is in the details. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Anti DoS for tx replacement
On Thu, Apr 18, 2013 at 11:28 AM, Mike Hearn m...@plan99.net wrote: With the sipaspeed patches it seems ECDSA can be processed on modern cores at something like 20,000 signatures per second. So it'd take a bit over 4 seconds to process all of them (cpu time). Sorry brainfart, s/cores/cpus/. I think the 20k/sec was with full usage of a hyperthreaded quad core CPU. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Anti DoS for tx replacement
...and actually, that's not a problem if the defender is online, because they can just broadcast the highest sequence numbered tx, which blocks further broadcasts by the attacker. Good point - transactions can be ordered by highest version seen before they're signature checked. Even without that improvement it's still rather tricky to win the race though. I'm intending on making a prototype for myself at some point soon, probably in bitcoinj. I've been making notes and writing some initial code - I did successfully replace a transation on my own little testnet, then I figured I'd submit the patch so it's easier for others to play with it. But I haven't got the whole thing working end to end yet. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Anti DoS for tx replacement
On Thu, Apr 18, 2013 at 11:28:48AM +0200, Mike Hearn wrote: Let's include bandwidth. Say the contract (multi-sig input + the outputs) is about 700 bytes. 43,200 transactions is then about 29 megabytes of data. On a fairly normal 10mbit connection that would take about 23 seconds to transfer. Of course the real number is a bit higher because of latency introduced by the inv/tx round-tripping. So the time window of the attack is dominated by bandwidth but it's still quite small compared to the block solving window. Mike, for the love of god, it's not acceptable to require Bitcoin validating and mining nodes to buy unlimited bandwidth. The attacker just has to spend more outgoing bandwidth than some fraction of the network hashing power has incoming bandwidth (individually speaking) for convergence to fail. But anyway, as I said in my follow up email, with correct prioritization it's probably a tractable problem. It's *easily* DoSable, not trivially. What I meant is - find some open DNS resolvers, start firing packets at testnet nodes, done. You don't have to do protocol level attacks to just render nodes useless. Testnet has 40 nodes online right now that can be seen by my seeder. To shut down all those nodes with a standard DoS attack would take at least 40 times more bandwidth than required by a tx-replacement DoS attack. Having a single multi-sig input means you can't do that because both parties co-operate to update the single input, but schemes that use multiple inputs do seem posible. You can always add dummy inputs. How exactly do you envision replacement working with non-final == non-standard anyway? As I said at the bottom of my second mail, it means making non-final transactions relayable again, but only to nodes that advertise a high enough version number. Those nodes are expected to do something intelligent with them, like just not put them in the wallet (unless the user has opted in and ticked the i know what i'm doing box, perhaps). Well, all that making them relayable enables is letting all parties to a transaction be offline when the nLockTime expires, so I'm not really sure it's worth doing, at least immediately. Weakening the non-final == non-standard test to give a window of, say, 3 blocks, would be fine I think. Well, it depends on your use case - you need to cast the (fixed) algorithm into a network protocol, manage the interactions between the parties, monitor the network for malicious broadcasts so you can replace them, fix the code so the wallets don't accept non-final transactions except when taking part in your contract, etc. If you do it all with Bitcoin-Qt it's easier but then your app can't easily run in places that can't afford a few hundred megs of ram (like wifi hotspots). The devil is in the details. The whole point of tx-replacement by fee is that the algorithm doesn't need to be fixed. It makes it very clear that unconfirmed transactions aren't trustworthy, and levels the playing field between you and people posessing lots of hashing power. Nodes can independently choose their replacement policy and the system still works. It also makes adjusting fees after the fact easy, again, functionality that we really need right now. John's adjusting micropayments proposal would work best in conjuction with some reputation stuff, like buying a fidelity bond promising you will play nice with tx replacement. Implementing such bonds is a bit subtle, because random chance can cause an earlier tx to be mined rather than a latter, but you can, for instance, rebut accusations of fraud in that case by simply creating an additional tx that pays the full amount if a partial tx accidentally gets mined. Come to think of it, such a system could be useful for inter-bank settlement, providing a security guarantee somewhere between a standard transaction and a fully off-chain transaction, at the cost of a single transaction fee. More importantly, it's not subject to sudden oh shit, slush's pool got hacked and is doing double spends! disasters. People should not be trusting multiple mining pools run by individuals as hobbies on insecure VPS services with the security of their payments, and zero-conf transactions do exactly that. Not to mention the ~25% of hashing power controlled by parties of unknown origin. -- 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net
Re: [Bitcoin-development] Anti DoS for tx replacement
Indeed, as I mentioned in my first mail, nodes can be told how much bandwidth they're allowed to use and then prioritize within that, so I don't see any way convergence can fail. And regardless, I used 10mbit for the calculations, that isn't exactly unlimited. My home internet connection is better than that. It's just an arbitrary choice that lets us get a feel for the numbers. We can see that even with a lot of replacements, an attacker would have a hard time matching up his flood with when a block is actually solved. On the wider point - how many people DoS things with their own bandwidth? The point of DNS reflection and/or botnets is you use other peoples bandwidth. The attacks on Mt Gox are supposedly 80 gigabit+, which is enough to take out all of the main network simultaneously. We can't do anything about that. So I agree we should work to avoid opening up new DoS attacks, but we should also be realistic about what can be accomplished. The kind of people trying to manipulate Mt Gox could nuke the entire P2P network off the face of the internet with the flick of a switch, presumably the reason they aren't doing that it would to use Satoshi's phrasing undermine the validity of their own wealth. sure it's worth doing, at least immediately. Weakening the non-final == non-standard test to give a window of, say, 3 blocks, would be fine I think. Sure. I think Gavin wants some kind of wider memory pool limiter policy which would encompass such a thing already. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Anti DoS for tx replacement
sure it's worth doing, at least immediately. Weakening the non-final == non-standard test to give a window of, say, 3 blocks, would be fine I think. Sure. I think Gavin wants some kind of wider memory pool limiter policy which would encompass such a thing already. Yes. I don't want to spend any time thinking about memory pool transaction replacement until after we pay some technical debt: + Memory-limited memory pool, with relay policy matching block-creation policy + Child-pays-for-parent fees + Auto-computed fees, based on transactions moving from the memory pool into blocks -- -- Gavin Andresen -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Anti DoS for tx replacement
I understand that Gavin has spent effort on security efforts against small-scale attackers. It's the fact that he is so dismissive of the threat that large attackers play that is what bothers me. But if I am being divisive I understand. I posted a clarification of what the reward is for exactly on the forums: https://bitcointalk.org/index.php?topic=179612.msg1881800#msg1881800 On Thu, Apr 18, 2013 at 8:14 AM, Peter Todd p...@petertodd.org wrote: On Thu, Apr 18, 2013 at 06:07:23AM +, John Dillon wrote: Gavin do you actually agree with Mike on this stuff like he implies? Because if you do, I think people should know. Myself I wouldn't want to be contributing to your salary as a foundation member if you don't take Bitcoin security seriously. FWIW Gavin has spent quite a bit of time and effort ensuring that Bitcoin is resistent to DoS attacks, as well as spearheading a move towards better testing. The latter in particular is helpful against chain-forking bugs, so better testing is very much a security issue. He also spearheaded P2SH, and the current efforts to get a payment protocol implemented. I'm less convinced about his stance against attackers that pose a threat to the system as a whole, but it's not fair to accuse him of not taking security seriously. Strict replacement by fee should be written so it can be tested properly and people in the Bitcoin ecosystem use proper security practices with regard to unconfirmed transactions. I'm willing to pledge $500USD to anyone who implements it. That is write the core functionality that does replacement by fee, and a simple 'undo' RPC command. I would do it myself but my programming is rusty. You should clarify if you want this patch to compute fees recursively or not, IE, should the patch include fees paid by child transactions in how it computes the total fee the transaction pays. Doing this is non-trivial, although Luke-Jr has written a patch to do this without replacement: https://github.com/bitcoin/bitcoin/pull/1647 Also, clarify if you want unit-tests and similar things included in the implementation. -- 'peter'[:-1]@petertodd.org -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Anti DoS for tx replacement
On Fri, Apr 19, 2013 at 12:38 AM, John Dillon john.dillon...@googlemail.com wrote: I understand that Gavin has spent effort on security efforts against small-scale attackers. It's the fact that he is so dismissive of the threat that large attackers play that is what bothers me. But if I am being divisive I understand. I cannot speak for Gavin, but speaking more generally, large attackers tend to belong in a thought-class all their own. Example 1: if some super-ASIC miner arises with 90% of hash power, and he starts behaving in a way contrary to the useful functioning of bitcoin, the community might decide to change the PoW algorithm at block height N. Example 2: If someone large DDoS's the entire P2P network, which is possible, manual intervention would be required to straighten out the mess. In each case, it's more about the community's mutual defense actions than any prepared defense. Speaking even more generally, bitcoin may be a billion-dollar invention, but that doesn't mean it has any funding for network defense! Unless cost structures and user attitudes change, development and deployment of major defense strategies seems unlikely. Which implies the community will simply wait for a [attack | explosion | crisis], and then hope we can unwind/repair the damage afterwards. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
