In light of the extreme crappyness of the mtgox passwords I think the hardening in the encrypted wallet branch is woefully insufficient. EVP_BytesToKey's 1000 rounds of sha256 is similar in computational complexity to the freebsd MD5 used for mtgox when run without special code on cpus and such tools slice through the mtgox password file like butter. We already know that GPUs can do hundreds of millions of 2xSHA256 per second.... Having to do 1000 SHA256 to test a password is no big deal. The salt also appears to be _constant_ unless I'm misreading the patch. Instead it should be per-user and saved in the wallet. Otherwise someone can simply pre-compute a ton of possible wallet keys for use against thousands of stolen wallets. They could even make a nice wallet rainbow table using the same gpu cluster they originally bought for mining. I think this is a CERT announcement level weakness and must be urgently fixed regardless of the other points I'm raising here. I'd suggest instead that it be changed to use A = scrypt(salt||password, 4 seconds) key = scrypt(A||password, 10ms) and simply save A in mlocked memory so that the high delay only happens the first send during a bitcoin session. (the second step could just as easily be BytesToKey if you want... it's just there to make searching memory of long running daemons unprofitable) (see http://www.tarsnap.com/scrypt/scrypt.pdf and the implementation at http://www.tarsnap.com/scrypt.html) Considering the mtgox passwords if this isn't done then it will still be _highly_ profitable to write wallet stealing worms unless the strengthening is made very strong. |
|
|
|
The purpose is clear and definitely appealing.
Type-2 might indeed be a good implementation, but I don't think I understand Type-1.
You would use H(n|S|type) to seed a keypair generation? Isn't the data too small for that purpose?
Or H would not be the usual kind of hash function, maybe a symmetric cypher?
ECC != RSA. You only need as much data is in a private key to create one. |
|
|
|
|
I've discussed this enough on IRC that I thought I ought to put it someplace more lasting.
Bitcoin really ought to offer and default to using deterministic wallets. The additional security of the current pre-generated ones is fairly small considering how most people use bitcoin and the liability of harm due to insufficient backups and increased pressure to keep a single wallet online is enormous.
What is a deterministic wallet? It's a wallet which you can backup once and it stays backed up forever because all future addresses are determined in advance. It can also be stripped down to a very small size which could be easily backed up on paper (e.g. with a QR code). This is in contrast to the current non-determinstic wallets where the keys are random but are precomputed ahead so that you're safe only if you backup at least every 100 get addresses or sends, and which grow large and harder to backup on paper over time.
I've found the backup behavior of the current wallets fairly difficulty to get even moderately technical people to understand. The current system provides enough safety to encourage complacency but not enough to make complacency acceptable. The positive side of a non-determistic wallet is that it becomes "unstolen" over time but people are frequently reusing addresses and attackers will not act slowly regardless.
There are two types of deterministic wallet I'd like to discuss. I'll call them type-1 and type-2.
Type-1 is the most obvious kind:
The wallet stores a large random seed S (which can be encrypted if the user uses wallet encryption)
Privatekey(type,n) is then simply set to H(n|S|type) where H is an acceptable secure hash function and type can be set to different values for change addresses vs displayed addresses (so this distinction is preserved even if new wallet metadata is lost).
The system would generate some (maybe 1000 of each type) addresses ahead of the furthest it has observed on the network but only bother to store the addresses. The keys can be regenerated as needed.
Type-2 is a bit less obvious and understanding it requires you to know about a property of ECC keys, roughly:
A_public_key = A_private_key*point
Which means you can do:
B_public_key = A_public_key+B_secret*point
and have a new key which has a private key:
B_private_key = A_private_key+B_secret
So a type2 wallet stores:
Master_private_key
A large Random_seed S.
and keys are given by
Privatekey(type,n) = Master_private_key + H(n|S|type)
which works just like a type-1, the advantage of the type-2 is that you can separately secure the Master_private_key, but still generate new addresses with
Publickey(type,n) = Master_public_key + H(n|S|type)*point
This means that a e-commerce site could have the front end webserver with access to the public key and S, and someone who hacked the server could violate the confidentiality of the addresses in use (because he could enumerate all past and future addresses based on an infrequently changed public key) but couldn't actually steal any of they money sent to the addresses because he would have no access to the private keys.
This could also be used to allow getaddress to work in the client without having to provide a key (access to the TXN data in the wallet means that access to the wallet, even with private key encryption, screws your confidentiality) which would avoid the problem of backups being endangered due to address depletion from hitting getaddress a lot between entering in the key.
|
|
|
|
allinvillain you have not responded to my question.
what kind of mega-farm did u own in order to produce 25k btc from your start date you mentioned?
has anyone done the math on if this is feasible or not with the difficulty jumps?
Look at the inputs to that transaction. The blocks are quite old. No megafarm was required. |
|
|
|
My sell order was shown as having 81NMC in the sell order list.
The order book isn't a list of individual orders. It's a list of all coins available at a given price. If you and I put orders at the same price we'll be summed. Notice that there are no duplicate prices in the orderbook? |
|
|
|
06/18/11 10:52:31 buy 0.06500000 81.42000000 5.29230000
Someone bought stuff form me which I didn't have, my order was shown as selling for 81, which I thouhgt was a reporting glithc, yet, someone bought 81. I only bot the 64 I sold worth, however, the other person spent 5.29BTC and got 81.
So, do bitparking, in total, have less NMC than shown in people's balances?
Nah, you're mistaking something completely boring for something interesting. Someone put in a buy for 81.42NMC, You had a sell of 64. All of yours, plus 17.42 of someone elses order were sold in order to satisfy the buyer. This is how a normal market works. If you buy X at Y price they it will buy all available up to amount X and price Y starting at the cheapest available. |
|
|
|
Hey,
the Win Client should be able to give an error indicating he has no irc communications.
Not just crash and leave the user with no clue
(MCaffee was blocking outgoing irc)
The client can now run without irc. -noirc -dnsseed as options, FWIW. Crashing is surprising and unexpected though. Is it possible that mcaffee was crashing it because it tripped some mcaffee rule? |
|
|
|
As far as I see, the basic idea of mining, is that we get piece of data, where we need to try all variants of 4 specific bytes = 2^32 variants, we hash this data using SHA256 and if we get value meeting our difficulty requirements we "win"(?)
I wonder how does this work on lower level:
1) How it's made that different clients does not work on the same variants?
2) How it is prevented that client who found solution would "steal" 50BTC, instead of submitting solution to the pool server?
3) How does pool software process this solution to get 50BTC and notify whole system that everyone (including other pools & individuals) need to work on next block?
4) Is that correct that all fees associated with newly generated solution are "payed" to the owner of this solution in the nearest minutes after it's generation?
Sorry for dumb questions, and thanks :-)
(1) There are 640 bits of input— the whole block header. It includes a version number, a timestamp, the hash of the prior block, the hash of the hashes of the the transactions, and the 32bit part you sweep (the nonce). Most work doesn't have any solutions at all. You can think of the whole process as throwing dice. (yes, the hash is deterministic, but no two throws will ever be the same). Inside the coinbase txn there is an extra nonce value where the creator of the block header can increment some more (e.g. if it needs more candidate blocks than the timestamp resolution * nonce space would allow for). (this is, e.g. why mining isn't a race, everyone is working on something completely different and someone else solving a block doesn't throw out the work you did, or prevent you from solving one) (2) The solution is bound to the identity of the key that gets paid the 50btc via the included hash. Change the payment address and you'd invalidate your solution. (3) Imagine you are throwing dice the pool has given you. The dice have the pools name written on them. You throw and throw. A throw of 1 solves the block. The pool asks you to report any throws you get <=3, you do this and it proves you are working. Sometimes your <=3 throw is a 1 and the pool announces it to the world. Everyone else can trivially see that the "throw" is the required value, so they treat that solution as good (by running the hash once) and continue building the next block in the chain after it. They simply announce it to all the bitcoin nodes they're talking to, who announce it to all their peers, and so on. (4) No. It's not award minutes after, it's 'awarded' either "instantly" or "after several hours" depending on how you want to look at it. When the block is formed all the transactions are groomed up, any time the inputs to a TXN are greater than their outputs in value the excess is the fee. The miner adds this fee to the 50BTC the network rules allow them to create out of thin air, and specify it in the coinbase transaction (called 'generated' in most software) that transaction specifies that the funds be paid to a key they hold. So it's an instant thing. Alternatively, the network won't let you spend from a generated txn until it is at least 100 blocks old— this is to avoid massive drama should their be a long chain split an the block not end up as part of the longest chain. If block ends up being excluded from the longest chain all spends originating in the coin made in that block would be invalidated. So the fees (and the reward) are only paid, or at least only available to be spent, until many hours later. |
|
|
|
But what if nobody find a block on 2 hours? Network goes to s**t?
No. You should read the code. It's much easier to read it than it is to come up with a legit attack... The constraint isn't 2 hours since the last block, it's two hours ahead of the the current network time, not the last block time. |
|
|
|
I know, it is much more critical the scenario where elliptic curve (EC) fails, but EC is somehow safe. The insecurity of EC does not depend on smart cryptanalysis, but in advances on mathematics and/or quantum computing.
Cryptanalysis _is_ advances on mathematics. It's also worth noting that EC based hashes were rejected as part of SHA3 (e.g. ECOH). |
|
|
|
The keyfile is mostly a file to help make your password more secure. A lot of people use crappy passwords. If they used the keyfile it would add lot's of random info to the password so if just the wallet is stolen they won't be able to brute force the password unless they also know the keyfile and have a copy. It's what truecrypt can use.
Strengthening probably addresses this better by making the bruteforce too slow to be effective against all but the dumbest passwords. Its important to keep in mind that, recent hysteria notwithstanding, the greater risk to most bitcoin users is coin _loss_ not coin theft. Security measures are important, but if they make you more likely to lose your coins or suffer data corruption then they are probably a net harm to the users overall. Basic wallet encryption is probably a net gain— widely used it should immunize the whole community against the creation of collection worms somewhat though it will cause some people to lose coins that wouldn't otherwise be lost. I doubt this is true for keyfile boosted encryption. Moreover, if you want that you can have it externally to bitcoin. |
|
|
|
So I hear a lot of talk about how Bcrypt is so much better in terms of it making it longer to crack each hashed password from a compromised database. So Is there really a huge difference in how long it will take to crack a SHA(256/512) in comparison to Bcrypt. and I know the answer is bcrypt but How much of a difference? are we talking years or just a couple of weeks difference? Please cite your sources if you have any, if not at least speak from your own experience and not other peoples experience's to sound all smart. Thanks  If you're interested in this area: scrypt is obviously superior to bcrypt for this purpose. In addition to being simply harder its design prevents someone with specialized hardware from getting an enormous attack cost advantage vs the user. http://www.tarsnap.com/scrypt/scrypt.pdf |
|
|
|
But the goal isn't to manipulate the transactions, the goal is to manipulate the difficulty so that more blocks could get mined so more rewards are available. Doesn't every miner have an incentive to set their clock slightly ahead, so that difficulty is slightly less, at least for the one difficulty adjustment period that they start doing this for? (And once they do, they need to keep on doing it to keep it from making up the adjustment later.)
I doubt there's a real "attack" here, but it should be understood by everyone that the timestamp in blocks is really only accurate to within whatever the acceptable window is.
No, but this is one of the reasons difficulty is adjusted only every 2016 blocks instead of e.g. every block. https://en.bitcoin.it/wiki/Protocol_rules block messages #5 "Block timestamp must not be more than two hours in the future" (compared to network time) So the most miners can advance the clock is two hours in a window of 2016 blocks... giving a maximum improvement of about half a percent when hashrate is stationary. Doing so will also bring about the reward halving earlier, so its even less attractive if you expect to have a greater share of hash power in the future. Network time ought to be hard to manipulate, though it isn't currently. But the most you can manipulate network time is -/+70 minutes of the nodes local clocks. |
|
|
|
Where is the source? This is very clearly a derivative of AMDOverdriveCtrl which is licensed under the GPLv2. |
|
|
|
We need nodes so payments can get processed!
Mining isn't everything. The more people have the Bitcoin client open, the easier it is to send/receive payments -- and that benefits EVERYONE, including YOU. You send/receive payments, don't you? (to cash in your Bitcoins, if nothing else)
It's important to forward the port (8333) if you do this. Nodes which don't listen can't connect to each other and contribute much less to the health of the network— especially with the influx of new users. Also make sure you're running .22 or (better) .23-rc1: the newer versions are more permissive about relaying low/no fee transactions. |
|
|
|
Votes aren't a good way to decide these issues. I suggest Matt just submit a pull req to enable it by default and let Gavin decide.
UPnP is a de-facto standard that's used by virtually all p2p software. The fact that it's even an option puts Bitcoin behind apps like Skype in terms of UI simplicity. It's definitely worth enabling it by default, at minimum.
Instead of talking about how great UPNP is it would be much more useful to tell everyone if you've tried it and if it worked. It's not a feature developers are likely to use — other than to test it. It would be pretty terrible if it turned out that it had a bug which occasionally crashed bitcoin and it got enabled by default. Also, looking at the implementation it appears that it tries to use UPNP even when its not required to get the port open. Thats probably somewhat less than optimal, since the upnp traffic might make network operators mistake bitcoin for filetrading applications in the same way IRC seed makes people mistake bitcoin for a botnet. |
|
|
|
100 blocks to mature eh? Everywhere I've read says it's 120. Has it always been that way? Do you have a reference I could refer to for more reading up on this?
It has always been that way. Everywhere says 120 because that's what the client says. The actual network limit is 100, though. Check the code: static const int COINBASE_MATURITY = 100; Use the -printblock switch to dump all blocks (including orphans) to debug.log, and then post the last few thousand blocks to pastebin or something so I can examine your block. I'm using a limit of 103 on namcoin. I was using just 100 for a while but had some weird behavior with getting a rejection notice when I did sends of coin right at 100 (thought it got sent and mined ::shrugs: I assume this was due to neighboring nodes not having the latest block yet then rejecting my txn. 20 is kinda nuts (especially on bitcoin) but I think having a buffer of a few is good. I haven't bothered making the same change for bitcoin because I'm not using new generations quickly there. |
|
|
|
At the moment addresses are used as fairly ephemeral things and the recommendation is to use a new receiving address for each payment. This limits the utility of vanity addresses and so I don't believe it's worth implementing. This may change in future however as new bitcoin services arise.
It can be implemented securely but the method touches on some issues I should currently keep confidential. However it's an elementary problem for any half-way decent cryptographer.
Indeed. I spent a while thinking about it and realized I was being stupid. The number of times the point was added initially (the private key) is unknown but you can keep adding it more without difficulty and get additional keys, then just add that value to the private key. |
|
|
|
Anyone else got this shit?
No, but I looked inside the binaries provided and two things are obvious: (1) The code has been through a java obfuscator (ProGuard), so it's hard to tell what it's doing. (2) The CL code, however, is unchanged from the normal diablominer. _Hopefully_ this just connects you to some other pool. But I am not even that optimistic. If you have run this on a computer with a wallet.dat I think you should treat that wallet as compromised. |
|
|
|
We may easily add other conditions to being a supernode, besides uptime and working incoming connections.
I would strongly recommend adding a blockheight check as well. Right now you can _easily_ form cliques of empty-headed nodes that talk only among themselves and have never seen the rest of the network. I'm not actually concerned with being able to provide the chain itself, but rather having the chain is evidence that you've been connected to the rest of the network before and therefore know some addresses that may get someone connected to it again. I'd personally use the highest checkpoint coded into the software, but really— it should probably be fine to use the earliest and thus allow nodes to begin seeding a bit faster. This measure also proxies for another thing: systems which are too overloaded or poorly connected to successfully download the blockchain should probably not get a bunch of leaf nodes connecting to them. Also, jrmithdobbs has a pull request someplace with some reasonable RFC1918/private IP detection logic. Separately, on IRC nodes which decide that they are successfully listening ought to join multiple random IRC channels. Two would be sufficient for making partitioning unlikely, but three might be better. (Not that this general proposal should depend on IRC— this should just be one part of its effect) |
|
|
|
|
Show Posts
