The problem with "inventing" an algorithm with the purpose of generating a private key is that it is difficult to measure how much entropy (security) your private key really has.
Well, i think the chances of someone writing down a random private key that matched my private key would be higher than them being able to design an algorithm that generated my private key given some input. Much higher. It is not. In base 10, the number 2^256 is 77 digits long. It is well documented that the average person can memorize 7 pieces of information at once. You are not going to be able to reasonably memorize a function that is one out of 2^256 possibilities. If you can think of an algorithm, there is no reason why someone else couldn't think of a similar algorithm.
Not necessarily. There's no reason to think that is the case in general. People tend to have a bias towards their own experiences. If a function is something you thought of on your own, it is probably not random. If the function is partially the output of a random generator (for example if at one point you multiply your starting number by 5, and "5" is the output of a random generator), your function will be more difficult to memorize. Although my recommendation is to create a seed that has 256 bits of entropy, if you insist on creating a brain wallet with low amounts of entropy, I would suggest using an algorithm that is computationally inefficient.
That certainly is one possible feature such an algorithm could have. Obviously, this assumes that new technology will not be invented that can go from 'brain wallet' phrase to private key more efficiently in the future.
yeah that's not an issue when the algorithm being used to "go from 'brain wallet' phrase to private key" is not known. they will have to find some other way to crack the bitcoin address. and that's something that all bitcoin addresses would be susceptible to no matter how they were created. [moderator's note: consecutive posts merged]I was referring to the algorithm that you may invent that would be computationally expensive. IMO, the only excuse for having a low entropy input to generate a private key is that it is expensive to go from input to private key. |
|
|
|
It is important to make sure that your computer is capable of generating random numbers. In 2013, for example a flaw in Android devices prevented them from generating cryptographically random numbers, which resulted in the risk of malicious actors being able to steal any coin stored on Android devices. The above did not ever affect electrum. But how would people know their computer OS is capable of generating secure random number? Most people simply assume the OS is secure and some of them only know about it after such vulnerability is disclosed. I was hinting at things such as malware that would prevent the OS from generating a secure random number. Today, most computers and mobile devices can generate cryptographically random numbers. However, if your device is infected with malware, the malware may cause your computer to generate numbers in a predictable manner, which could lead to a hacker stealing your money, even if you generated the seed on an offline computer (that was infected with malware).
While it's possible, it's not practical when the malware could simply copy wallet file, steal password using keylogger or read private key from RAM when the wallet opened by user. Are there any known malware which specifically mess with system cryptographic secure PRNG? If the malware is targeting users who are going to be generating private keys on offline computers that will never touch the internet in the future, stealing information is not going to do very much because it would have no way of transmitting the stolen information. My guess is that any malware that targets PRNG is going to be state-sponsored whose targets are embassy employees and spies, so their communications can be intercepted and decrypted. |
|
|
|
The 12 words are 128 bits of entropy, which is considered more then enough.
Obviously more words would make it more secure.
The difference between the chance of a single 12-word seed being made twice and the chance of a single 24-word seed being made twice is approximately ~2.93 * 10^-39. Although technically about a bitcoin private key, and not an electrum seed, the image that bitmover posted nicely illustrates the risk of a collusion.
It is important to make sure that your computer is capable of generating random numbers. In 2013, for example a flaw in Android devices prevented them from generating cryptographically random numbers, which resulted in the risk of malicious actors being able to steal any coin stored on Android devices. The above did not ever affect electrum. Today, most computers and mobile devices can generate cryptographically random numbers. However, if your device is infected with malware, the malware may cause your computer to generate numbers in a predictable manner, which could lead to a hacker stealing your money, even if you generated the seed on an offline computer (that was infected with malware). |
|
|
|
Maybe no one thinks to try the above procedure for a long time, but one day, someone learns that the above person has a lot of coin, their favorite number is 420, and they like to generate their private keys via non-standard methods. This might lead someone to try to generate private keys via psudo-random methods in various ways using '420' as the seed up to a certain level of entropy that can be easily cracked.
What I'm thinking is if I designed some super secret but easy for me to remember branwallet algorithm, it wouldn't even help you to know my starting brainwallet passphrase simply because the main source of entropy is the algorithm itself. And you could spend an eternity going through those before you hit on the correct one. some people might argue that it's impossible to degisn such an algorithm thats easy to remember. for me, it's the opposite way. i could remember an algorithm but i would have more trouble memorizing a 30 character phrase that had 120 bits of entropy. because a human doesn't have the capability to truly generate such a thing i dont think. unless they roll dice but then that would make it impossible to memorize... In my example, most of the entropy is from the pseudo-randomness, and very little from the "brain wallet" portion of generating the key. Does calling a pseudo-random function while using a particular seed really create 90 bits of entropy? It does create a set of numbers that would take 2^90 guesses in order to be guaranteed to guess that particular set of numbers. If you know that the random function of numpy is being used, the amount of entropy is reduced to ~8.75 bits. The problem with "inventing" an algorithm with the purpose of generating a private key is that it is difficult to measure how much entropy (security) your private key really has. If you can think of an algorithm, there is no reason why someone else couldn't think of a similar algorithm. Although my recommendation is to create a seed that has 256 bits of entropy, if you insist on creating a brain wallet with low amounts of entropy, I would suggest using an algorithm that is computationally inefficient. If it is difficult to calculate the private key from the 'brain wallet' phrase, then each bit of entropy is "worth" more. Obviously, this assumes that new technology will not be invented that can go from 'brain wallet' phrase to private key more efficiently in the future. But the standard SH256 brainwallets are very safe, if the password is safe. And I don't see a problem with forgetting it. Just write it down on paper and deposit it at a safe place. There are many ways to disguise it as well, like use the first sentence in a diary. If it is personal and not found somewhere else, it would be very safe. Like "This is the diary of the very knowledgeable programmer Frank, born on x, in the city y.". No way this could be discovered with a brute-force program. It would be much more safe than a random 30 character password.
My understanding is that most scripts/programs that try to find/steal brain wallets are not doing what most would describe as "brute forcing". I believe they will look at literature to find phrases, and use those phrases against bitcoin addresses that are known to have ever received any transactions. They likely also append things such as birthdays, popular vacation locations, and various punctuation to these phrases. This is somewhat similar to trying 'password1' when someone's known password is 'password!' There are around 171k words in the English dictionary, and randomly using 7 words as a brain wallet would generate about 121 bits of entropy. The risk of using your method is that if anyone has ever said the phrase you use in a book, movie or TV show, (or something similar), or has ever appeared in a news article, blog post or forum post, there is a high probability that someone will try your phrase against bitcoin addresses that have ever received coin. If your brain wallet is not generated randomly, it will not have anywhere near the amount of entropy you think it has. |
|
|
|
You should deserialize each transaction (this will take a long initial time), and place transaction data in one NoSQL table (minus vin and vout arrays), harvest the vin and vout data to make a utxo table, and take the addresses and values out of each vout to construct an addresses table.
And of course you can fetch each block, deserialize the data and create a blocks table while you're at it.
SQL databases are horribly inefficient. NoSQLs like MongoDB are better.
You are describing a relational database structure (such as SQL) in a convoluted way. A NoSQL collection of blocks might break down as follows: record for block x --> transactions --> list of vIns, each of which references a previously confirmed transaction and index to that transaction and list of vOuts, each of which reference an address and amount. If a particular vOut is spent, it would be very difficult to lookup that transaction in a NoSQL database. If you are using a relational database (such as SQL), you can create an index on any column you are using a WHERE clause on (or are aggregating data on). So if you ever will filter by txid, you can create an index on the txid column in your transactions table. Querying a SQL database when filtering by data in a column that is indexed will be very fast, while querying when filtering by data in a column that is not indexed will be slow (or maybe very slow if your database has many records). If you need to frequently access data, you can also create a temporary table. Bitcoin core already does this (or something very similar) by keeping the UTXO set in RAM. |
|
|
|
Well, it is only 0.00000000000000000000000000000000000000000000000000000014% of all possible SHA26 hashes (assuming a bijective mapping, so probably a bit higher, if there are collisions).
True, but in the context of a brainwallet we aren't talking about a 256-bit entropy. We are talking about user provided passwords and in this context even a big 8 character passphrase consisting of random alphanumerical characters (eg. _Cf}u$b0) needs computing 6 quadrillion hashes (0.006 quintillion) in total, the "165 quintillion hashes per second" rate is huge. I do see what you're saying and it caused me to reconsider exactly what is a brainwallet. At first I didn't think it would be something someone has to "remember". But you are taking that to be a requirement. What if I or someone else came up with some super-secretive procedure for taking a phrase and turned it into a 256-bit private key. Since the method is not published and only exists in their head, although they would have certainly tested it on a computer at some point, as long as they remember the procedure and the passphrase, I don't see how someone woudl be able to crack that. And the phrases could be very simple and yet since no one has the secret method, they don't even know where to start even if they know the phrase itself. yes the sample space has lower entropy but the problem is that you can't just check all 8 character passphrases because you don't even know the algorithm for converting them into a private key. So maybe a particular method of generating a private key has 30 (for example) bits of entropy, but the fact that an adversary does not know the first step in creating the private key, it would appear the private key actually has 120 bits of entropy. For example, someone might call numpy.random.choice([0, 1], size=90), but only after calling numpy.random.seed(420), and prior to doing something that creates 30 bits of actual entropy. The private key would probably remain "private" for a long time, but once an adversary figures out the procedure, any private key created via the above procedure would be quickly learned by adversaries. Maybe no one thinks to try the above procedure for a long time, but one day, someone learns that the above person has a lot of coin, their favorite number is 420, and they like to generate their private keys via non-standard methods. This might lead someone to try to generate private keys via psudo-random methods in various ways using '420' as the seed up to a certain level of entropy that can be easily cracked. |
|
|
|
Let's say (conservatively) that a more modern quad core CPU can do 500,000 and use that as the reference. That means it can check 43.2 billion keys per day.
Brute forcing the "correct horse battery staple" space
Most "brain wallets" are not brute-forced. Hackers will use various literature as a starting point for passphraises, and will use permutations of said phrases to check for a brain wallet with coin unspent. The reason for the above is that, although the English language is vast, and it would be difficult to brute force a random 4-word brain wallet, most people are not going to select words for a brain wallet at random. Most people will select words that are easy to remember because they coincide with a meaningful event, or are otherwise meaningful to the person. This is not random, and as such can be easily be "guessed" by hackers. If you were to create a brain wallet of 4 words randomly selected from 171k English words, it would be one possibility out of ~855 million trillion possible combinations. However, if the brain wallet is created from some set of words in a book or bible verse, the possible combinations is reduced by multiple magnitudes. |
|
|
|
What do you think wackers bonkers (Contributing forum member that is beneficial to the community). Kill him (Make him a hero member). Oh, you naughty wackers bonkers. |
|
|
|
There's an admin note on his account so he might have already been banned/unbanned at one point:
Admin investigation required for any plagiarism report before November 03, 2020, 10:25:02 AM If that would have happened, shouldn't he have received a 1 or 2 year signature ban? It is possible that he made some argument supporting that his posts were not plagiarism. He seems to have a long history of posting articles, along with their links. I don't know if he forgot to include a citation in those two posts if he somehow owns the rights to that content if he was being employed to specifically promote those articles, or if there was something else that made his posts acceptable, or at least forgivable. |
|
|
|
If your transaction involves bitcoin, the bitcoin marketplace section would be appropriate. If your transaction does not involve bitcoin, the thread needs to be located in the altcoin marketplace. If you are hiring someone to develop something, and are paying in bitcoin, the appropriate section is services |
|
|
|
|
It is interesting to see how buthurt some people get when they cannot do whatever they want, even when these actions are clearly against the rules. It is also telling to see some people repeatedly break the rules after clearly being told they are breaking the rules (via moderators moving his thread out of currency exchange).
Probably more telling, and more indicative of one's integrity is, based on the evidence I have observed, is one's willingness to take advantage of the moderators' inability to see posts edit history to lie about the timing of when a thread was changed in order to falsely make it appear a moderator made an error. I am curious if anyone encouraged anyone to be dishonest in this thread or elsewhere about this situation.
|
|
|
|
This is something that just came out, I think the MSM will pick it up in due time. The images of the journal that allegedly belonged to Ashley Biden, President Biden's daughter, were published by a right-wing website not long before the election. The website in question nationalfile.com is not very well known, and most people likely were not aware of the leaked journal images before today. The images of the journal were released by nationalfile after project veritas declined to publish the images of the journal because it was unable to verify the authenticity of the journal. The images of the alleged journal are of journal entries from when Ashley Biden was in some kind of rehab/treatment facility, apparently in or around January 2019. Some of the entries detail now President Biden showing his daughter, molesting his daughter, including touching her vagina. Around the 2020 election, Ashley Biden had reported a burglary to law enforcement. Yesterday, on November 4, the FBI raided the apartments of two Project Veritas journalists attempting to find information about the alleged theft of Ashley Biden's property, including her journal. If the journal was not authentic, it would be illogical for any law enforcement agency to raid Project Vertias journalists' apartments. There would need to be evidence both that Ashley Biden's journal was stolen, and that the journalists at Project Veritas at one point had possession of the journal.
There are multiple issues here. The most obvious and glaring issue is that President Biden may have committed sex crimes against his at-the-time underage daughter. This has the potential to end Biden's Presidency and very well may end his presidency. There is no statute of limitations for most sexual assault crimes in Delaware, where the crimes would likely have taken place. The second issue is that the Biden FBI was used as goons to raid journalists to investigate a theft from his family member. It is unclear if anything else was stolen from Ashely Biden, and if so, the value of what else was stolen. I think it is unlikely anything else that was stolen had a large monetary value. Project Veritas reported that whoever was in possession of the alleged journal was trying to sell the journal, and if this person(s) had stolen items of great value, it would be unlikely they would go through the trouble of selling the journal, and risk exposing their identity in the process. If somehow the journal is not authentic, or Biden is otherwise not guilty of sexually assaulting his daughter, this alone should be grounds for impeachment and removal from office. |
|
|
|
It appears that DdmrDdmr is getting so efficient at sending merit that he doesn't even have to visit the send merit page.
Ever heard about the Internet Of Things? Looks like it finally was able to connect itself to the bitcointalk source code I have a pretty good idea how DdmrDdmr was able to bypass the send merit page, but I don't want to ruin the fun. As a hint, I will say that DdmrDdmr made a lot of posts in his merit spree  |
|
|
|
I detected a spree of 489 merit sent in 284 transactions in 4 minutes 35 seconds (240 seconds), or 2.0375 merit/second 1.183 transactions/second.
You guys are making me nervous: Here are my findings:  EDIT: had to manually check that 4 minutes and 35 seconds are actually 275 seconds. Yea, that is my bad. I forgot to add in the number of seconds to the total. It appears that DdmrDdmr is getting so efficient at sending merit that he doesn't even have to visit the send merit page. According to my calculations, the spree lasted about 4 minutes and I can only say that @DdmrDdmr is definitely one of the most effective merit sources, of course along with all the other deserving members of the forum. Thanks for the merit rain  IIRC, the merit DdmrDdmr sends in these bursts is not even his merit source sMerit, it is his personal merit that he sends when he runs out of source sMerit. |
|
|
|
|
I detected a spree of 489 merit sent in 284 transactions in 4 minutes 35 seconds (275 seconds), or 1.032 merit/second 1.183 transactions/second.
|
|
|
|
If it's not a self moderated then you could probably just reply while quoting the bump(s) and then report it.
Technically speaking, even quoted posts can be faked. It appears there is at least one mod who really does not care about excessive bumps. Yesterday (November 3, UTC TZ), I had 8 reports of excessive bumps marked as bad. The posts in 7 of these reported posts have already been deleted and replaced with another excessive bump. I also had 12 reports of multi-posting marked as bad, even though as of now, the post in question, and the prior post were both written by the same person (I had one additional multi-posting report marked as bad after the person deleted his prior post sometime between when I reported his post and now). |
|
|
|
If you are going to accept transactions with n confirmations, you can improve your workflow by doing the following: sudo code
latest_block = 0
time.sleep(CHECKFREQUENCY) # CHECKFREQUENCY = the amount of time you will wait to check for a new block
current_block = RPC command getblockcount
if current_block > latest_block:
block_to_check = RPC command getblockhash(current_block - REQUIREDCONFIRMATIONS) #REQUIREDCONFIRMATIONS = confirmations needed to accept transaction
block_data = RPC command getblock(block_to_check, verbosity=2)
block_transactions = block_data['tx']
for transaction in block_transactions:
decoded_tx = RPC command decoderawtransaction(transaction)
for vout in decoded_tx['vout']:
#get output address and amount
latest_block = current_block
The above assumes that any orphans will not result in your transactions going from confirmed to unconfirmed (while this is rare, this is something you will want to address). It will also make it so you do not have to keep all unconfirmed transactions in RAM. Today, most transactions that make it into the mempool will get quickly confirmed, but the small number of never-confirmed transactions will pile up over time, and when the mempool is more full, many more transactions that make it to your mempool will never confirm. |
|
|
|
Good point. But i doubt his test is meaningful since SMF (Simple Machines Forum) is written in PHP while he posted C code.
What is also interesting that I have seen in discussions now, is how many people code in the cloud. I always as does just about everyone I know do everything locally and then push it up to github or wherever. I never knew how many people are doing it all online and then pull and compile it locally. Guess I'm old. -Dave Completely agree. I have seen some of these cloud IDE's such as Cloud9 (which is amazon now I think) and their interface cant offer half the functionality of what something like PyCharm, PHPStorm or VSCode can. Especially with the Git integration. I might be willing to use a cloud IDE that saves my work-in-progress to the cloud but still has the capability to perform GIT functions to the applicable branch of the repo I am working on. This might cut back on commits to my branch if I am pulled away from working on something unexpectedly, for example. I would not be particularly comfortable with an IDE that saves in real-time without the ability to commit my changes. This would make it difficult to undue changes that break something, or that is later decided against implementing. |
|
|
|
|
Everyone has boundaries for their various relationships. Ideally, you should communicate these boundaries with those you are in various relationship types with, so the other person knows what is and is not acceptable to you. If you set boundaries and your relationship partner violates these boundaries, you should not be surprised when they are upset.
if your boundaries are not something your relationship partner finds reasonable, or are what your relationship partner finds illogical and/or unfair, your relationship partner can discuss these concerns with you, and you can decide if you want the boundaries adjusted.
This scenario is a good example of many people violating boundaries. Unfortunately, IRL, it is very common for people to disrespect boundaries. I am not sure why this is so common. I guess some people are just assholes.
|
|
|
|
|
Show Posts
