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. |
|
|
|
|
I've read it, thanks.
You may want to flip through it again so that you can see how every other cryptosystem other than bitcoin takes great pains to minimize and obfuscate use of the private key, and how every PKI system in the world, again not counting bitcoin, insists on using expiration dates for keys.
Bitcoin private keys have no expiration date, and are used to sign plaintexts that are partially repetitive and predictable. If these factors don't make your sphincter tighten, you missed some big lessons from the history of cryptanalysis.
We can't expire keys, and we can't compress ( =randomize) scripts. The one thing that we do is discourage key re-use. We should not abandon the one good practice that we are capable of doing without a damn good reason, even though we are pretty confident that we are safe doing so.
|
|
|
|
What if we don't care about secrecy with transactions?
Secrecy isn't the issue. The issue is attackers gradually learning bits of your private key. |
|
|
|
Thanks for that, guys!
So you just concatenated all of those strings of text above theymos? In that order? Hashed them with sha256 and came up with that result?
Can I ask a question now..? WHY are we constantly changing endianness? Is it safer cryptographically or something?
Perhaps I did find the correct hash already, I just didn't think so because it didn't start with zeros :S
Because byte ordering in memory is different from byte order on the network. There are a lot of different multi-byte word storage schemes in use by different CPU families. The network byte order is the common standard, and each machine is responsible for converting to and from it. It gets trickier with hashing like this, since some parts of the header are bit strings, and other parts are machine words. So, in bitcoin, we have the network byte order, the local machine byte order, and the byte order that makes the hashes work out like everyone else's, and they are all potentially different. |
|
|
|
I already said that we don't think the our modern systems have this problem, but every other PK cryptosytem goes to great lengths to minimize usage of the actual private key, just in case.
Bitcoin only uses the actual private key when something has to be signed to prove it was generated by the owner of that private key. I can't imagine how you could minimize it further or why you would want to. You minimize it further by not needing to sign multiple transactions with the same key. Again, I'm not saying that an attack is likely from this direction, I'm just saying that key reuse is considered harmful in general, and should be minimized unless there is a very compelling reason. |
|
|
|
|
What exactly do you mean by wasted effort?
Also, you are doubling the amount of time an attacker has to find a superior block.
|
|
|
|
|
As much as I despise working with autoconf, it seriously rocks.
|
|
|
|
|
Also, after you format the drive in Windows, unmount and unplug it, then plug it back in before running unetbootin. And if you are going to edit the config file from Windows, do the unmount/unplug/replug cycle again after the unetbootin step.
You really shouldn't need to, but it can help if you get strange problems like this.
|
|
|
|
Pick up any book on cryptography, open it to any page, stab your finger into any paragraph, and you will find a warning about key re-use.
Such concerns are not relevant for the security of modern cryptosystems. In particular, public key cryptography relies on the public key being published and used multiple times. Please cite any modern technical publications which claim otherwise. Codemojo's scheme is simple, viable and secure. I already said that we don't think the our modern systems have this problem, but every other PK cryptosytem goes to great lengths to minimize usage of the actual private key, just in case. |
|
|
|
|
That depends on the exchange. I think that mtgox and tradehill both go with the price of the earlier order. Most real world exchanges have the same policy.
So, if there are three sell orders waiting: 1@10, 1@11, and 3@12, and a buy order comes in for 4@12, the total price would be 45 instead of 48.
|
|
|
|
|
Pick up any book on cryptography, open it to any page, stab your finger into any paragraph, and you will find a warning about key re-use. We don't think that our current systems have any serious weaknesses in this department, but virtually every cryptosystem in history has been weakened and then broken because keys were used multiple times.
Best practice for security: use each key once, and only once.
Not best practice, but still pretty good: allow multiple uses, but discourage.
Worst practice: design a system that keeps using one key over and over and over again.
|
|
|
|
|
Internet routing gets strange if you decouple BGP relationships from physical links on a large scale. I just don't see NANOG going for it.
|
|
|
|
The longest chain is defined as the one with the most proof-of-work.
I am not sure that that's true. It is how it should be done, but may not be how it is actually done. You could even define it as the sum of 1/<hash value> for all blocks in the chain. The difficulty value only changes every 2160 blocks, so in most cases 2 chains will have the same difficulty for the blocks after the split. If sum (1/<hash value>) was used, then it would be very unlikely that a tie would happen. Alternatively, the rule could be that if 2 valid blocks are received, then the one with the lowest hash value wins. B-C / GENESIS-A \ X-Y If B had a hash of 0000000123 and X had a hash of 0000000122, then everyone who had received the B hash first would switch to A as soon as they received the A block. C would likely never be found at all. This would short circuit the tie-break rule. It wouldn't even require a network rule change. Miners could just agree to do it that way. Yes, but they won't have the same difficulty after the next block is received. In your example, A-B-C and A-X-Y are equally valid and each node considers the one it saw first to be true. The matter will be settled across the entire network when either D or Z is found next. In practice, it almost never even gets this far. Most of the time, either C or Y would have decided the question between B and X. |
|
|
|
|
The odds of successfully switching the chain are quite low, even if you have a huge amount of hashing power. Unless there is a block with unusually high fees, it will never be profitable to try working on any block other than the current one.
|
|
|
|
|
In an exchange market, orders are placed with limits. A buy order includes the maximum that you are willing to pay for each coin. A sell order includes the minimum that you will accept.
All orders are stuffed into a database called the order book. The matcher looks at the order book, and any time it finds an overlap, it processes that order and updates the balances.
|
|
|
|
|
If you watch the debug.log, you should see a "REORGANIZE" message come across too.
|
|
|
|
|
I'm not the biggest miner around by any stretch of the imagination, but I've bumped up from 0.50% to 50.0% for a while.
I use the flex mining proxy, so I don't lose any work, but I'm always happy to wake up finding that my miners have been here all night instead of elsewhere.
|
|
|
|
|
How about the I have 5 posts and I'm the first person to notice that all of you are wrong about design decision X troll?
Or the No one will ever accept deflation (because I got here too late to get a pile of coins when it was still easy) troll. But this is really one type of known troll in disguise as a different type.
|
|
|
|
|
Show Posts
