|
no. unless you gets the computer back, and the harddisk(s) is not touched/formatted/broken.
|
|
|
|
So anything that has an autoupdater is by default malicious? any closed source autoupdater can by default be malicious. do you disagree? What evidence do you have that Microsoft is installing spyware, viruses, or other forms of malware on customer operating systems that you so strongly insinuate? none! but they can do it. please see what words i use. i do not say that they do, only that they can. You certainly have the right to despise any operating system you choose - but that isn't a justification for spreading hearsay or other false information. i did not write any false information, please read my posts again. |
|
|
|
When you write 'will' - this means a new UI version? Because now I don't see such link at the withdrawals records in the account history (in USD).
It is not highest priority, but is still important as it'll reduce the number of emails we receive on the support. very important. your support is real slow! |
|
|
|
What i do think is that quantum computers are significantly faster than any piece of silicon will ever be. and of course quantum computers could just be defeated with stronger encryption, SHA-512 or better. you have now demonstrated that you don't know much about quantum computers. and SHA is not encryption, its hashing. will you continue to show us how big you fail? (sorry for being rude) they both require finding an unknown to reach a final result, i may have skimmed over the fine details in this post and said the wrong thing. but the idea is still valid. using a hash with a larger word size will yield a hash that is more difficult to crack. quantum computers can crack ECDSA, the PKC-algo involved with bitcoin. but can not crack SHA256, yes it would likely crack it faster them a classical computer. but it would first be finished with cracking it long after the heat dead of the universe, for which there will be no propose for cracking it. |
|
|
|
What i do think is that quantum computers are significantly faster than any piece of silicon will ever be. and of course quantum computers could just be defeated with stronger encryption, SHA-512 or better. you have now demonstrated that you don't know much about quantum computers. and SHA is not encryption, its hashing. will you continue to show us how big you fail? (sorry for being rude) |
|
|
|
Any chance of a improved version of this on Google Apps? I can't run the exe because I am on Linux  ever heard of wine? |
|
|
|
Best place to DL?
to DL what? |
|
|
|
Hi Hi! New member here. Sorry if this has been covered elsewhere, but I'm curious about one aspect of BitCoins.
good you are curious, always a good starting point  OK, I understand that the BC algorythm means no more than 21 Million BC can ever be produced. Once that number is reached, that's it. true! there is also an finite supply of gold. is far more easy to compare btc and gold, then compare btc and usd/fiat So if a PC's HDD goes down, and a wallet is lost, all those BC are gone, right? However the BC network doesn't know they're gone, because all the transactions that created them still exist. Is that correct? yes. make backups, or don't crash your HD. From that point onwards, there will always be 21 Million minus the amount that were lost, never more. Is this also correct?
yes. Now the real-world equivalent of this would be a fire in a bank in which loads of physical banknotes were destroyed (or a Central Bank deliberately destroying old bank notes that have been taken out of circulation). In both these cases, the same amount of physical notes would be printed to replace those that had been destroyed. and more gets printed. you can't compare btc to fiat. banks can print as much as they want and cause infaltion. My main question is this: If BitCoins can no longer be created once the 21 Million limit has been reached, and "lost" coins can not be replaced, what happens to the currency when a significant number of coins have been lost? The transaction history will still show that there is 21 Million in existance, but nobody will have all of them. all the other coins gain value, bit coin are divisible to 0.00000001 btc. this means even if there was only 10 mio. btc back, we would still have enough. Since all data is lost eventually, isn't there a possible scenario (many years in the future) when all those 21 Million BitCoins have been lost? How would the currency function after that? they will not be lost, it would require a collective agreement of all bitcoin holders to securely erase their harddrives. you can compare it to if al gold in the world was tossed in to the ocean. it just not gonna happen. and even if 50% of the coins are gone, the currency will still be able to function. |
|
|
|
|
BUMP! can a mod or staff please comment on this?
|
|
|
|
Is it the thread where ppl insult windows cause they think it's still windows 3.1?
First you call windows a trojan and now you say that you just want to know why ppl use closed source.
In page 3 you will again change the point of the thread?
possible trojans, i did not say it was. 3.1? no 7 3.1 has in fact less trojan-like attitude, beacuse there was no auto update feature(trojan downloader feature). you may say that most linux distros also have autoupdate features, but you can always read the source, and ensure there is no trojans. you can't read the source of windows, becuase its closed source. my points with the post was: a) to make windows users aware of what they are using and how much control they have over their computers. b) to learn how they justify being paranoid(many users here have 3 layered tinfoil hats) and use windows at the same time. maybe calling windows a trojan was a overkill, yes true. but i did it to show the contrast. microsoft can actually install whatever they want on your computer, again im not saying they does it, only that they can. |
|
|
|
Unless you're saying that the operating systems themselves are infected (I think someone would have noticed by this point), I always ended up reinstalling the system on the machines I purchased anyway, due the amount of bloatware many have on them. As a result, even if I were to suspect that, it wouldn't be a factor in the end.
But if you do find some sort of malware on a pre-assembled machine - I'm sure you'll have quite a few lawyers willing to take up the case for nothing, as you'll have quite a check waiting for you by the end of the proceedings!
windows is not infected, it is the possible malware! microsoft can gain access to any networked windows system, via the preinstalled trojan downloading system called windows update. and you would have no knowledge of it. let my simplify the question, why are people using closed source? |
|
|
|
[...]
How about this then: In SSL, the server's private key is not used for encryption, nor for hashing, nor for any other operation, cryptographic or otherwise, of anything that is released to any other party.
If not to perform cryptographic operations, what do you think it's the purpose of a cryptographic key?. hey! don't step on him! he said: client gets the server cert. the client encrypts a random key he/she choses, with the public key from the cert. and sends it to the server. the server decryptes the random key the server responses with an encrypted message, to proof that he/she knows the private key. |
|
|
|
the client can often force a DH key-agreement to happen. it requires the server to sign with the private key.
Reference? p. 91-92 F.1.1.3. Diffie-Hellman Key Exchange with Authentication When Diffie-Hellman key exchange is used, the server can either
supply a certificate containing fixed Diffie-Hellman parameters or
use the server key exchange message to send a set of temporary
Diffie-Hellman parameters signed with a DSA or RSA certificate. also every certificate is signed by an CA. I stand corrected. SSL implementations that ignore all the SHOULDs and warnings in that section do actually have the option to use their private keys directly. apache has it enabled by default. it only requiers the client to only allows DH in the ClientHello message, and the server supports DH. anyway it does not matter. signatures are useless for the propose of getting information about the private key. signatures only gives proof that the other party have access the the private key. |
|
|
|
the client can often force a DH key-agreement to happen. it requires the server to sign with the private key.
Reference? p. 91-92 F.1.1.3. Diffie-Hellman Key Exchange with Authentication When Diffie-Hellman key exchange is used, the server can either
supply a certificate containing fixed Diffie-Hellman parameters or
use the server key exchange message to send a set of temporary
Diffie-Hellman parameters signed with a DSA or RSA certificate. also every certificate is signed by an CA. |
|
|
|
on a busy SSL server, things gets signed and encrypted, 1000 times per second. with the same 1024/2048 bit key. they are not broken (yet).
Dude. SSL never encrypts anything with the server's private key. Never. partly true. but it is used(to sign) in the key-exchange protocol, to prevent a 3. party for modifying the protocol messages. No, it isn't. In SSL, the client encrypts the premaster secret (a number used to derive the symmetric session key) using the server's public key. The server decrypts it using the private key. At no time does the server ever emit anything directly derived from its private key. SSL uses symmetric encryption for the payload. PKC is only used to securely exchange that session key, and the entire exchange protocol was designed to protect the server's private key from re-use. the client can often force a DH key-agreement to happen. it requires the server to sign with the private key. |
|
|
|
How about this then: In SSL, the server's private key is not used for encryption, nor for hashing, nor for any other operation, cryptographic or otherwise, of anything that is released to any other party.
LOL! TROLL! then what is it used for, please enlighten us with your superior knowledge. |
|
|
|
on a busy SSL server, things gets signed and encrypted, 1000 times per second. with the same 1024/2048 bit key. they are not broken (yet).
Dude. SSL never encrypts anything with the server's private key. Never. partly true. but it is used(to sign) in the key-exchange protocol, to prevent a 3. party for modifying the protocol messages. |
|
|
|
+1 |
|
|
|
|
Show Posts
