I requested a SEPA withdrawal (which unlike USD were not on hold) around mid June, but still nothing. I mean, it says "Status: confirmed", but no money on my bank account. I asked for an estimate when I will get the money, or at least how many people are before me in the queue. A guy from the customer support replied "I will keep you up to date" and I have not heard from him ever since...  |
|
|
|
But if you think that "DoS vulnerabilities" are not vulnerabilities, let's rename them to "DoS problems". I don't mind. He only said that calling them "vulnerabilities" implies some kind of expectation of strength, while no strength against DoS attacks was intended when the current protocol was being designed in the first place.. well, if it was, then somebody really screw it up badly, so let's better assume that it wasn't... Doing it the proper way, the architecture of the network protocol, as well as the architecture of client's core components (e.g. memory pool, peer trust management, signature verification engine), should be based on a DoS prevention design. Instead of being based on DoS proof-of-concepts with prevention patches that follow, which certainly seems to be the case now. |
|
|
|
I think we need (again) a reality check here. Bitcoin is nowhere near DoS proof today. It's not hard to find ways to overload nodes or cause problems, especially if you assume access to a botnet. Although you found some clever attacks, I am reluctant to even call these issues "vulnerabilities" because that implies some kind of expectation of strength. Well put. |
|
|
|
yeah, it was stupid to disable these commands. there is no way to turn them back, cause that would make even more trouble but at the other hand, who would need to use them anyway - bitcoin chain is not a calculator. nobody even uses ifs yet |
|
|
|
|
Don't you need to pay some kind of capital gain taxes, if your customers make profits?
|
|
|
|
I'd actually be OK with including a database copy in the downloads, it's a much simpler and easier thing to do than complicated shared UTXO commitment schemes. This would only improve the bootstrapping time, but it is nohow a "blockchain compression" solution. Calculating a reliable check-sum of UTXO snapshot might be a bit time consuming, but the process itself is not a rocket science and the algo should be very simple to implement. Even if you do the actual hash of all the records, the operation should take far below one minute, on a modern PC. But if you choose a smarter checksum calculation method, you can speed it up a lot by doing some kind of differential UTXO checksum adjustment while processing each block, which would only require fractions of seconds. A node would already have the expected checksum value, because a UTXO checksum in a block would actually refer to the UTXO state after the previous block. Moreover, if you still find calculating of UTXO checksum too much resource unfriendly, you may only allow such checksums to be mined (thus verified) each few thousands blocks. |
|
|
|
|
This is not an impossible problem to solve, buy rather beyond my math skills.
You'd definitely want to use some smart algo here - probably some flavor of finding the shortest route between two nodes in a graph.
Analyzing all possible paths is too complex.
|
|
|
|
In the meantime, is there something useful that can be created from this exploit?
I could think of at least one. Insider trading on buying stocks of companies that manufacture memory chips |
|
|
|
No, the nodes don't quite ignore them.
So your proposal is that tx's that a node doesn't relay shouldn't be added to the memory pool at all? This could cause issues where a node ends up verifying a tx over and over. At minimum, the hash of verified but not accepted transactions should be kept, so that a node can just discard the transaction if received later. My proposal is to better start thinking of it and try to find some long term solution, so an attack on nodes memory was not possible. Nor CPU, if possible. If you like complicated solutions, I recommend web of trust There are many measures that you can try against memory pool attacks, none of which is going to be implemented in a near future, at least from what I know. Unless I build and release some tool to make it an issue - but then I will have to suffer consequences of being an evil guy who releases tools that DoS the network. But either way, sooner or later, I will suffer the consequences - because someone will make such a tool, if I don't do anything to prevent it |
|
|
|
|
OK, agreed.
But since you already have checkpoints, why don't you get advantage of them?
|
|
|
|
No, the nodes don't quite ignore them. They just don't relay some of them. But there are no actual protection in the node from being flooded with bogus transactions. Not to mention the protocol. Really, it's terrible. My webpage has better protection, and nobody except me cares about it either |
|
|
|
Maybe actually it should be simpler. Each miner would have a possibility to mine in a hash of the current utxo db - of course it needs to be sorted, or something, but wrong hash means block is invalid. And then, by other means, not necessarily ones that need to be sponsored by bitcoin foundation, people would find a way to fetch these snapschot of utxo as long as you add to the protocol a possibility to mine in hash to utxo and make sure that all the miners get it... two years at least. ten since it's my idea |
|
|
|
Or since its still such a not an issue, allow me to ask this way: Will it help if I release a tool that is able to consume all the node's system memory (with lets say 50% success rate) within an hour? I think I can do it With the horse inputs I can generate many 99KB txs and using <5KB txs with no valid inputs at all, I can do the rest. This protocol has so many holes that one can exploit, that it just comes very hard for me to believe that nobody really gives a shit about it. |
|
|
|
Can I save my bitcoins on 2 separate computers simultaneously. If so, how? Preferably without using the terminal. Thanks.
Yes and no. If you only want to monitor your balance, no problem. But if you send from one PC, you should transfer your wallet to the other, after sending. Oh, and yeah; first you need to have the same wallet.dat on both PCs |
|
|
|
Maybe there should be something like a general solution, to compress it once and for all. Its all about the most recent content of UTXO - which is not so big, comparing to the so much faster growing blockchain size. Maybe there should be an automatic checkpoint (like a small-generic) each 2016 blocks or so (with a hash of the UTXO db content included inside the block) from which nodes would be able to start their existence, using the chosen hash as a trusted seed to quickly fetch entire UTXO, instead of re-doing the chain up to that point. If that works, there would be no more need to store, nor to share, the entire blockchain - it could be stored in a museum, though |
|
|
|
With checkpoints the client only skips validating transactions, it still builds the UTXO set. You've still shown that an vast amount of hashing power work has been spent towards the blocks leading to the checkpoint, and validating that work, as well as the work after the checkpoint, is pretty easy. More importantly if the checkpoint is invalid and the majority of hashing power isn't following it you'll soon notice because your client doesn't see as many blocks as it should. But if you are taking a piece of software where some devs have put a checkpoint, why would you trust them in a part of choosing a honest block hash, but not trust that they honestly verified the chain up to that point, difficulty check including? It just doesn't make any sense to use this software to verify from a scratch a chain that can only be valid if it reaches a block with a specific hash - value fixed inside the same software that is doing (again) the blocks' verification, to reach the same hash - because only then it can work. It's just a huge overhead. |
|
|
|
I agree. If there are these checkpoints anyway, you can as well distribute a new version of the client with the content of the last checkpoints' UTXO, instead of only a block's hash. This would make bootstrapping so much faster, but also require no storage for all the previous blocks, since any node would be able to download the last checkpoint's db content from the peers - with a checksum it would be equally "safe" as the checpoint values now, but so much more useful. It's a bold move, but in fact not bolder than the idea of checkpoints itself. And it would at least optimize something. Though, again, who am I talking to + the idea of checkpoints is stupid and goes totally against the main purpose of the solution |
|
|
|
Ha, I hadn't heard that was how they got it, I was under the impression it was just stupidity on the part of the Americans. Seems like something you would want to do: if you have a flying death robot you should make it so the people you are spying on/shooting at cannot take control of it.
They did not take a control over it, per se. But they jammed its communication with the base, so it couldn't receive orders - in which case it should automatically return to the home base. And then they were broadcasting a fake GPS signals that made the drone thinking that it was going towards the base in Afganistan, while it just landed politely on Iranian airfield. Because obviously US Army's top end GPS system does not use any reliable method of authentication whether a message comes from the actual satellite, and not from the enemy's radio. |
|
|
|
BTW, it was so funny, when Iran captured their drone by spoofing its GPS receiver.. As it turns out the most advanced military in the world doesn't even bother to use signatures on their military focused navigation system. What a bunch of lamers - no wonder that they see such a big thread to their national security in enemy having access to sha256 algo.. |
|
|
|
|
if you have a new satoshi client running, there is RPC command "gettxoutsetinfo" - it can tell you all you need.
|
|
|
|
|
Show Posts
