not directly related to Bitcoin but to the US Dollar:  |
|
|
|
Probability is funny like that. I still find that it is counter-intuitive.
Then something must be wrong with your intuition. |
|
|
|
This discussion gets to the heart of why I never understood the evil booga-booga about controlling more than 50% of the hashing power:
- There's nothing magical about 50% which would ensure a series of blocks found in a row when you want to perform your double-spend
- The double-spend would get noticed by all clients who have the full block chain (which right now is all of them)
Am I missing something, or is the "50%" risk overblown?
You can go some blocks backwards an regenerate all of them faster than the rest of the network gets the regular blocks generated. By this, you can revert transactions in the past, and then reuse the coins. Of course for a practical high success probability you need more than 50 %. But you can say with less than 50 % it is improbable enough to be unattractive. |
|
|
|
|
You could always create the longest blockchain with an old computer by ignoring the difficulty rules. But that does not help you, nobody will accept it.
The rules are not made by the miners. The rules are made by all clients. One rule is that the longest valid blockchain is valid, another is the required difficulty. Anything else would not make sense, because creating an invalid blockchain does not require you to obey difficulty rules.
|
|
|
|
|
I drank raw milk all my life, I grew up on a dairy farm.
|
|
|
|
More information from the whistleblower. He claims it is possible to transfer btc while having unsufficient funds.
"I'm not the most knowledgeable person about it, but the way I understand that it works is that when you send a payment you are sending the solved hash containing the transaction information to other clients, those clients verify that you have the funds available to make the transaction. When there have been enough confirmations the transaction goes live.
btcguild is working with another pool plus the non-pooled machines; they make every single machine confirm every single transaction for the brief window that they send a payment that doesn't really have enough funds. Because they control a majority of the network the payment is seen as valid and sent across, even though the funds to do so didn't really exist.
Again, I haven't worked directly on this so it's likely a bit different than that, but this is my understanding of the matter."
They could do that, but regular clients would not accept the new block. They control most of block generators, but not most of the clients. |
|
|
|
|
How could they do false transactions? Even if they completely domintate block generating, it is impossible without breaking ECDSA.
They could use their power to send themselves more mind coins than the 50, but that cannot be hidden.
The only thing they really could do is delete transactions.
This sounds like somebody spreading FUD to me, not because it's impossible, but it's not reasonable.
|
|
|
|
For low value items like that you would normally accept the transaction without any confirmations. If the bitcoin node that the vending machine is talking to accepted the transaction then it's probably valid. I think the only danger in that is if it was somehow double spent in a short time window - then it may never get into any blocks. I'm not sure if that's really possible, maybe it is, but it seems like it would be hard to pull it off reliably.
It should be quite easy: 1. Pick an address with enough coins, send all the coins to another address you own. 2. Send the amount to the vending machine also. |
|
|
|
A lot of people don't know how to handle .xz though, so you'd still have to offer both choices in that case.
I'm not sure how much bandwidth of the download site is a problem at the moment.
On every linux distribution not older than 5 years there should be no difference for the user at all. |
|
|
|
Knew it was a good idea.  Thanks Will. It is a good idea depending on your goal. It is a good idea, because you can copy wallet files without fear. It does not protect against stealing from an infected computer where bitcoin is running. |
|
|
|
|
Just consider a trojan that does not steal wallet files, but waits until you make a transaction and changes the destination address and amount of coins just before signing.
You can't do anything against that with encryption - in principle.
|
|
|
|
Alice sends cash to Bob and the letter gets delayed in the mail and doesn't arrive at Bob's.
Alice writes another letter to Bob with more cash and Bob takes it. First letter then arrives (the mailman finds it in his van) and Bob takes it to.
Bitcoins are like cash. In this case Alice should have probably never sent the second letter, our Bob could send the second lot of cash back. This is not an issue with the cash system.
Will
Yes, you should never send cash via mail. But that doesn't happen with the usual use of cash: face to face. |
|
|
|
A transaction will only ever appear in one valid block so it will only ever happen once. This is exactly what the sender wanted when he made the transaction. It's like writing a check but the recipient doesn't cash it out immediately. This is not a security flaw in the check system as long as the recipient can only cash it out once.
I've never seen a transaction take more than a day to verify, even when I've put a 0 fee on it.
Will
But consider the following attack: 1. A draws a transaction X to B, this means there is a transaction signed with A's private key. 2. The transaction does not get included for a long time. 3. A draws a new transaction Y to B, which gets included. 4. Now, B can use X to steal money from A. |
|
|
|
(Note: VM guests don't work at all, because VMs were never meant to protect guests against hosts, only the other direction makes sense.)[/li][/list]
You could use an encrypted file container within your guest VM, which will then be inaccessible as long as the VM is switched off. Of course, a keylogger will get your password unless your VM can also use a mouse & gui to select a key-file. But that doesn't protect you any more than a regular encrypted volume. But its way more a waste of ressources. |
|
|
|
|
It will push archive size of 0.3.23 (for linux) from 11 M to 6.5 M. This results in 41 % smaller size (and thus traffic).
It still decompress faster, only compressing takes a little longer.
|
|
|
|
People are asking all the time for encryption of their wallets and using TrueCrypt etc. And they think that it protects against certain attacks like Trojans, which it doesn't. This discussion shall result in a summary that explains noobs what encryption can do and what it can't. What is encryption?Encryption is a tool to protect data. With an encryption scheme you can encrypt a file with a key. The desired result is that nobody is able to read that file without the key. Misconceptions that make encryption worthlessIf you want to protect data via encryption, you have to make sure that this data does not exist anywhere outside the encrypted file. This is the hardest task of all and the error most people don't seem to see. Cases associated with bitcoin where this is the case: - If you encrypt an existing wallet, your old version may still be on disk. The only way to avoid that is wiping out the whole disk, or creating a new wallet inside the cryptographic container that never hits a disk unencrypted in its lifetime.
- Even if you avoided the first case: As long as your encrypted device or file is mounted, the data is not protected by encryption. The only protection is now policy enforcement (e.g. operating system prohibiting other users to access your files). There is no way around that, you have to decrypt the wallet to work with it. The only solution is a seperate wallet that is decrypted less often. There are many ways to enforce policies like installing a isolated machine or creating a seperate user account that does not run untrusted software. You can do it as secure as you want by investing the effort of using it. (Note: VM guests don't work at all, because VMs were never meant to protect guests against hosts, only the other direction makes sense.)
- Always assume: Malware can do anything you can do. The only thing that protects you is your decryption secret, but only as long as you don't decrypt the file. If you can use the wallet, why should a trojan not be able? In fact it always is. That's the problem the policy enforcement aims at: It makes sure that a trojan in your working space cannot access a wallet that is in an isolated space. There can still be flaws that could open a door for attackers around those policies, that's why there are those different methods proposed.
ConclusionIf you really want security, you have to accept the following principle: Always assume that it does not protect you unless you can really argue with certainty and in detail why it does prevent certain attacks. |
|
|
|
My final proposal involves "allinvain" growing a pair and shutting the fuck up.
Of course, assuming that transaction belonged to him in the first place, which we have to accept on 'faith'.
It's all a dogs breakfast, no matter how you look at it. Goddamn drama queens.
He can proof that he is the owner, because he has the private keys. But he cannot proof that he didn't send the money himself. |
|
|
|
Any good alice & bob jokes?
Bruce Schneier knows their shared secret. |
|
|
|
|
Show Posts
