Ask Evil-Knievel. It was his term. That's why ryanc put it in quotes when he used it:
Whatever - it's just silly joking. But you are wrong @Danny, because backup is a very weak and very fragile point of a wallet's security. That's mostly why I choose a brain wallet. Another is convenience - why would I have to carry a file with me if all I need is my brain. And no, I do not have my passwords written anywhere. However I do have some hints written down. But they are designed in a way that only I can understand their meaning. Actually, only I can understand that these are the hints. Start using your brains - that's all I have to say. Don't buy into the bullshit that your brain is not smart enough to make a password that other people's brains can't hack. |
|
|
|
Also, if you would not mind sharing what does it actually take to become a "crypto guy"? I am not asking because I want to become one. I am asking because I do not want to be associated with a "crypto science" like yours.. I prefer a "crypto practice" - so whatever else you do not do, will likely also work for me  |
|
|
|
your motivation here is highly suspect.
[...]
What motivation do you think us "crypto guys" have for trying to prevent people from using brainwallets, other than to save people from themselves? Your motivation is pretty obvious and I think I already said that. You are trying to say that the "people" are too stupid to make a password that you "crypto guys" cannot crack. And what other reason for that if not to indulge one's poor ego? Well, you are wrong. And we are here to help them proving that you are wrong - that is our motivation. Maybe not because we care about them, but because wy love proving arrogant people to be wrong. Crack my password, mr crypto guy, if you are as smart as you are pretending to be. It holds thousands of bitcoins - that should be enough of the motivation. |
|
|
|
I mean, seriously? What kind of idiot do you think would chose any of the above passwords to protect his life's savings? Clearly multiple people chose those passwords to protect some amount of Bitcoin. Or for a different reason. E. g. to research brain wallets. This "research" paper does not say how many bitcoins they have collected as the result of cracking brain wallets. The logical assumption is: because they haven't collected any significant amount, even though they "have been able to crack thousands of passwords including some quite difficult ones". Because (most likely) they only cracked the passwords that nobody really cared about in the first place. Proving only how silly the conclusion from their paper is. The point is that people think those passwords are strong passwords because online password checkers say that those passwords are strong. If you are recommending people to use brainwallets, they are likely to use those types of passwords thinking that they are strong passwords when in actuality they are not.
Your claim would be true, if you had found at least one person who thinks that "those passwords are strong". Otherwise it's just what you believe. I will tell you what. If you want to prove your point, all you need to do is take any password from the list (e.g. " say hello to my little friend"), find the address it came down to and see how many coins this address ever carried, for a longer period of time. If it was a significant amount, then you are right and I am wrong. It's all in the blockchain - be my guest. Alternatively, you can contact the authors of this paper and just ask them how many bitcoins they found on the addresses they cracked. Tell them that there is a guy on bitcointalk.org who claims that they are a fraud and you are trying to clear their names... |
|
|
|
Cracking programs: Research: Sorry mate, but I've gone through these programs and "research" papers and I must say that if they have any value then it's rather entertaining than scientific. Let me just refer to the last one from the list - this is their "conclusion" sections: As an example application of this research, we have been able to crack thousands of passwords including some quite difficult ones. Our research demonstrates again that brain wallets are not secure and no one should use them.
And this is the list of the "quite difficult ones" that they are so proud of cracking: 1. say hello to my little friend
2. to be or not to be
3. Walk Into This Room
4. party like it’s 1999
5. yohohoandabottleofrum
6. dudewheresmycar
7. dajiahao
8. hankou
9. {1summer2leo3phoebe
10. 0racle9i
11. andreas antonopoulos
12. Arnold Schwarzenegger
13. blablablablablablabla
14. for the longest time
15. captain spaulding I mean, seriously? What kind of idiot do you think would chose any of the above passwords to protect his life's savings? |
|
|
|
No thanks, I have my own. I don't trust other people with their wallet software - no matter if it would be a brain wallet, a core wallet or a hardware wallet. |
|
|
|
|
I actually read it quite often and I always ignore it, but it was always upsetting me.
People saying basically "I know what I am talking about, don't us a brain wallet and if you do don't come to me crying after you loose your bitcoins".
I just wonder whether in such case people can come to you crying when they used a non-brain wallet and then either lost it because they had no backup or because someone stole their (backup) wallet file.
Can they?
|
|
|
|
Please don't use words like "horribly" or "probably" trying to discuss technical issues.
Why? I understand not using probably (I thought this was in beginners and help so it was primarily as a warning to noobs) but what is wrong with "horribly insecure"? Because how can anyone objectively disagree (or agree) with a complexity of a technical challenge described by such words? Do you even understand that cracking a brain-wallet's seed password is a serious technical challenge? Which tool/approach would you have chosen to crack my brain wallet? It is possible to securely use brainwallets, but it should not be something that is recommended to newbies and those who do not understand technical aspects of Bitcoin IMO. Which is exactly why guides like this can be very useful. Unlike dogmatic statements based on someone's beliefs, basically coming down to: don't use a brain wallet, because you are too stupid to make a proper password. IMHO, there is nothing more stupid (or arrogant) than assuming that all the other people are stupid, except greg and theymos |
|
|
|
There are multiple research papers and programs that show that brainwallets are horribly insecure and easily cracked as what you think is a strong password probably is not a strong password.
Please don't use words like "horribly" or "probably" trying to discuss technical issues. Please refer me to the multiple research papers (and programs) you've mentioned. I am able to discuss technical aspects (numbers, codes, algorithms) and science behind them. I am not however willing to argue with your emotions or believes. I use brain wallets myself, have been for years. For me they are more secure, reliable and convenient than wallets which require to be stored and backed up. |
|
|
|
All fine, but which part of this guide is actually making it "strong"? Perhaps I can link to my other post from this forum: https://bitcointalk.org/index.php?topic=1690812.msg17129122#msg17129122Personally I prefer brain wallets, because I'm paranoid about having a physical backup of my keys. But a strong password is the key to the security here - and there are many attack vectors on passwords. Plus obviously a way to never forget it, while not having it written anywhere. |
|
|
|
My code rejects the message since it is too short (message decode fails)
Yes, mine too. But maybe it shouldn't? |
|
|
|
|
It is not about the language/API of the queries, but about the speed of accessing the records.
In SQL database just parsing the SQL query takes too much time.
But modern NoSQL databases (like MongoDB) are also not good here, because they are designed for complex queries and fancy data structures.
This all comes at a cost of performance and memory usage.
What you need for bitcoin is a simple [binary_key] -> [binary_record] database.
LevelDB is the most common one I know that can be used for that.
But IMHO even LevelDB is far away from optimal for bitcoin's UTXO set.
I'd say that if you want your bitcoin node to perform really well, you ought to make your own DB engine.
Depending how much RAM you can spare, I'd lean towards keeping all the data inside the memory.
Write data to the disk only to make the memory changes persistent and read from the disk only when loading the DB data while booting your node.
This requires more than 2 GB of RAM for the current UTXO-set, but gives the optimal performance.
That's for UTXO database - which is the tricky one here.
As for the blocks, you might just as well use a pure file system - no additional database engine is really necessary here.
|
|
|
|
Recently I see more and more nodes, introducing themselves as "/Satoshi:0.13.1/" but sending me sendcmpct message that is only 5 bytes long. Can anyone say if they are legitimate bitcoin core nodes, or just some other stuff pretending to be the latest release of core? What shall I do with sendcmpct message that carry only 5 bytes of data? Some example logs below 42314 139.59.208.241:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
42314 139.59.208.241:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
42453 46.101.99.121:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
42453 46.101.99.121:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
42454 46.101.99.121:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
42454 46.101.99.121:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
42698 138.68.66.47:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
42698 138.68.66.47:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
42866 139.59.209.199:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
42866 139.59.209.199:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
42923 46.101.109.46:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
42923 46.101.109.46:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
43048 139.59.157.246:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
43048 139.59.157.246:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
43513 138.68.64.28:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
43513 138.68.64.28:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
43788 46.101.228.246:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
43788 46.101.228.246:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
43997 139.59.208.241:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
43997 139.59.208.241:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
44088 188.166.161.228:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
44088 188.166.161.228:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
|
|
|
|
|
You guys have no idea what you are talking about.
At this moment UTXO database holds over 45 millions records, from over 16 millions transactions.
What you need is an instant access to any of these records - otherwise verifying of blocks and transactions will be too slow.
No SQL database (or mongodb) can give you such a performance.
These kind of DBs are meant for complex queries, but they would have killed your bitcoin node had you tried to use them for handling the UTXO set.
|
|
|
|
|
Yeah, it always wondered me as well.
What would be an example application?
|
|
|
|
|
It is not necessary.
But would surely be more useful than e.g. the payment protocol.
|
|
|
|
Would something like this be a strong password?
darrenisgoing2theshopuntilldinner
not after you've just posted it but in general, I'd say it is strong. you have 8 words - that's very complex to brute-force using a dictionary method, as the attacker would need to use a very big dictionary. still, I'd advise to use at least twice that many words. and throw some "mistakes" into a couple of the words. the method I use: make a short original poem and remember it. poems are easy to remember. never post it anywhere online! you don't need to type the whole words - depending on the length of your poem, it might be just the first and last letter of each word, or something like that. just make sure the password is long enough after all - 34 "random" low-case characters should do as they'd give about the same entropy (brute-force resistance) as the 160 bits of a bitcoin address. also mind that some letters are more common in the language than others - try to make sure your 34-character password does not follow these statistics. |
|
|
|
- snip -
The bits field must have the exact expected value, otherwise the block gets rejected (ignored) by the nodes.
Harder or lighter - doesn't matter, it would be still invalid.
That's what I assumed, but I hadn't taken the time to go find the lines of code in Core that make that comparison. Since you seem to have found it, can you link to it here please, and save me the time of searching for it? I saw it long ago, needing to know how to implement it inside my shit. It's moved all around the code base ever since, but look for the place where GetNextWorkRequired() is called from. ATM it's in file validation.cpp: bool ContextualCheckBlockHeader(const CBlockHeader& block, CValidationState& state, const Consensus::Params& consensusParams, const CBlockIndex* pindexPrev, int64_t nAdjustedTime)
{
const int nHeight = pindexPrev == NULL ? 0 : pindexPrev->nHeight + 1;
// Check proof of work
if (block.nBits != GetNextWorkRequired(pindexPrev, &block, consensusParams))
return state.DoS(100, false, REJECT_INVALID, "bad-diffbits", false, "incorrect proof of work");
|
|
|
|
Andresen is back on the team? No worries. Considering his coding performance and how much miners don't seem to desire bigger blocks, my SSD should last for another couple of years. |
|
|
|
Suppose that a bad miner (who intends to attack the network) sucessfully mines a block for which the found hash has several zeros more than the current required POW effort. If this miner sets the nBits field on the mined block header to a value much higher than the current POW target, but compatible with hash it has found for that block AND that block is the 2016th at a given target level, what will the other nodes do? The bits field must have the exact expected value, otherwise the block gets rejected (ignored) by the nodes. Harder or lighter - doesn't matter, it would be still invalid. |
|
|
|
|
Show Posts
