anybody know a way to load a huge wordlist into vanitygen and still use the -i function? currently the max i can do while using -i is around 4000 but i want to be able to do a lot more than that  The case-insensitive option unrolls the word into every possibility, so a word like 1siik would become 1siik 1Siik 1siiK 1SiiK A normal four-letter (without special characters like "i" which don't have an uppercase in Base58) would become sixteen possibilities; a six-letter would become 64 possibilities. If you have 512 eight-character words, it is actually a list of 128k words after all permutations, which becomes 1 megabyte. The final list is also pre-processed to remove redundant matches (like your list has 1siik and 1siikfo) and invalid/too long strings. CPU vanitygen uses 2GB on my system while just processing a huge list of 8-14 character words, and dies about line 82K before it even starts generating, probably from running out of 32-bit process memory. Even if you were to compile in 64 bit, you will likely hit GPU RAM limits, if that's not already your limiting factor. |
|
|
|
quick question i cant find the answer in the post is the command "-1" working? whenever i found the privatekey, the terminal keeps looking for more and more... i want to just recive the solution in the "-o" file i create, and the terminal to stop... or close in better case thanks I don't know what option that would be. If you use the -k option (keep looking), it will keep looking. |
|
|
|
He wouldn't be able to sell a million coins at the market price as the market for bitcoin is not liquid enough to handle a sale of a million coins like that.
Not quite true, there was a time when there were book orders on MtGox looking to buy more BTC that will ever exist; you could have sold 21M BTC and there would still have been more orders yet to be fulfilled without the price dropping below $0.20 or so. Instantly executing 1M BTC would not have even cut the price in half. Interesting to read, I didn't know about all the binaries in the blockchain that the second post's link article describes. but why is it so unlikely that people don't have the private keys for these strange addresses?
Perhaps see vanitygen software, where it takes days to months to search for an address like in my sig, where just the first eight characters are specified. Trying to find the private key for an address like where the whole address is user text, would be equivalent in difficulty to cracking and stealing bitcoins from any address. It would be as hard to find the private key for that address as to find the private key for the address that has Silk Road's seized 100,000 BTC. |
|
|
|
Paper wallet better than cold storage.
Why is that the case? Can anyone share their opinions on that? I always consider paper wallet is as safe as cold wallet, as long as they are both created in a safe way. That's just a post count spammer posting mindless junk. The reason why this forum is becoming useless. I already reported yesterday but they aren't modded to hell yet. They are in most cases the same thing. what the meaning of a good random number??? i don't understand, and it's a nice info to know that the printer can store the file printed...
Bitcoin addresses are based on keys that are and must be completely random numbers. Flaws deliberately introduced into or bugs in the implementation of operating system random number generators can reduce your security. Making your own key, i.e. with a brainwallet generator, is a surefire way to generate a nonrandom key weak enough that others can steal your bitcoins. |
|
|
|
Private keys are not compressed, public keys are what are compressed. The wallet-import-format merely has a flag as to whether the private key is for a compressed or uncompressed public key and address. From the same private key data, a compressed public key makes a different address. You cannot spend bitcoins sent to a compressed address/public key with an uncompressed version. You will need to use a wallet that supports compressed keys if you want to export addresses. Better yet, just send Bitcoins to your new wallet address over the network. If you merely want to see the two addresses that a single private key can make, you can do that on the "wallet details" tab of http://bitaddress.org |
|
|
|
|
Instead of running it on an OS that may already be infected, backdoored, keylogged or screenshotted by a virus or trojan horse you've already got, I would recommend running a liveCD and generating the key there. That way there is no chance of an eavesdropper intercepting the key, and it will not be written to the hard drive accidentally even as memory page file. See the last link in my signature.
|
|
|
|
I saw this potential problem a while ago: A feature of testnet could be used as a difficulty-amplification attack. I've just done it for fun and profit.
"In addition, if no block has been found in 20 minutes, the difficulty automatically resets back to the minimum for a single block, after which it returns to its previous value."
while the last block was full difficulty:
while the local time isn't more than two hours ahead of network time
Set local clock forward 20 minutes from last block,
mine difficulty 1 block,
This could drive difficulty seven times higher than actual hashrate.
On the plus side, easy 50 BTC if you can't ASIC mine. I made the same 300 testBTC in 5 minutes as I did in two days of GPU.
One for the bug pile: getmininginfo displays the last block's difficulty, not the targeted difficulty. On testnet it will often display "difficulty: 1" from this keep-blocks-a-rollin' feature.
Well, now someone has scripted a time-playing attack and is using it to 7x the difficulty and monopolize non-PoW mining:  The problem is that this basically warps testnet coinmaking. The miner not only makes all the timewarp difficulty 1s allowed, they also sit on the highest time allowed and publish a block find the second the network time allows it. This can DoS any developers looking to test specific mining features. The simple way to combat this is if miners also move their clocks ahead two hours to prevent the mining of the extra blocks allowed by the time margin. If miners just set their computer time ahead though (which is published P2P), we will have a testnet that drifts into the future. Miners could also ignore difficulty 1 and build a higher difficulty chain using real PoW, orphaning & doublespending etc. This has pushed testnet up to difficulty 700+. As there is one block find every 20 minutes + 7 block finds for every proof-of-work, the difficulty will continue to increase, with the upper bound approaching around one block actually mined per difficulty evaluation period. Also the bug below. Looks like the "keep testnet mining" difficulty 1 code needs to be revisited: I reset the testnet difficulty to 1 using a bug with the testnet-specific difficulty code. The prior difficulty was ridiculous and testnet doesn't reduce in difficulty when hashrate drops the way we would expect it to reflect actual full-difficulty hashrate. Enjoy the coin bonanza. The difficulty is currently up to 1024 and will be increasing at 400% per retarget for quite a while.
|
|
|
|
|
A quote from my signature site: "Transactions fees may supplement, and must eventually replace, the diminishing block reward paid to miners."
It is economically uncertain if purely profit-motivated mining would maintain a sufficient difficulty against attack, however there will be holders of 20+M BTC at that time that will have an economic interest in the operation and stability of the network and may mine as part of their business interests.
|
|
|
|
Not at all what he is looking for. Bitcoin Core-based wallets have a communication mechanism, where commands can be issued to the running client over the network, called RPC (remote procedure call). You first must turn on the server component of Bitcoin by using server=1 in the config file or as a command line option, and also must set an rpcuser/password. Then in the config file you must allow the correct IP address netmasks for only local machines and networks that are allowed to connect. An example config file with these options individually documented is here: http://we.lovebitco.in/bitcoin-qt/configuration-file/Once that is on, you can test communications locally by running a second bitcoind to issue commands (which also functions as a simple RPC client), commands like "bitcoind help". For programmatic access, you can take a look at documents like: https://en.bitcoin.it/wiki/API_reference_%28JSON-RPC%29http://upcoder.com/7/bitcoin-rpc-from-python/ |
|
|
|
|
I've lost zero bitcoins. Every bitcoin is right where it should be.
|
|
|
|
The "good encryption" is encryption that is located on your computer. You also need to obtain the public encryption key of the recipient in a way that you can confirm that it has been unaltered. Encryption is not hard to do, but finding other parties that also can send and receive encrypted email is the harder part. You also must communicate with people who have the sense to decrypt and read the message where it can't be intercepted. You can send and receive encrypted email with any provider, but it is much easier if they have POP/IMAP access so you can run your own client software instead of cutting and pasting the message to decrypt. Also note that the "metadata" of email transit and the sender/receiver info that spy agencies claim to have the warrantless right to intercept cannot be masked. https://securityinabox.org/thuderbird_encryption |
|
|
|
Examine the q=0.1 table at the bottom. q=0.1 means 10% probability the attacker finds the next block, and can be interpreted as the attacker having 10% of the network hashrate. The chance they will EVER be able to catch up from their one-block deficit and replace a previous block is P=0.2045873.
My understanding is that the P=0.2045873 figure from the table represents the probability that the attacker is on the same level as the honest network at some point in the future given that the honest network found z = 1 block since the attacker began attacking.  For the same parameters, the probability that the attacker is on the same level as the honest network at some point in the future given that the network is z = 1 block ahead of the attacker is 0.1111111 (7.d.p), given by  A z=1 attack scenario would be an attack that begins after 1 confirmation. The attacker's starting point is one block behind everyone else. We will use our imagination to conjure a high-value service vulnerable to this attack: - an exchange that trusts 1 confirmation payments - once the 1 confirmation is achieved, the attacker's scripts then immediately purchase and withdraw irrevocable currency and begin a double-spend attack z=1 means to immediately start mining a double-spend chain of the payment after 1 confirmation. Interestingly, the formulas don't compute "to win", they only compute the probability of "to catch up", that both the honest network and the attacker both have the same block height. This is a head-scratching anomaly. Let's say the attacker "caught up" by immediately mining an attack block of the same height as the one confirming the transaction, meeting the statistical goal - the network still trusts and is building on the honest block of the same height; the attacker didn't win. That just leaves more math, because actually winning and the "first to publish" rules of Bitcoin aren't considered. I think the implications are that the probability for winning a 1 confirmation race is actually z=2. |
|
|
|
what is the cost to replace a z=1 block if we continue our attempt for 10 blocks depth Not too much for a pool owner who does not have its own hardware, but a lot of connected miners. Let us say that this attack will cost zero for such dishonest person. I think we will see it in the nearest future  It has a direct cost. The only way that it would be free is if the large pool operator is willing to discard their reputation as an end-game. Current mining software lets an individual miner know when they find a block, and the previous block hash being worked on is part of the information that miners are given to hash. Diverting pool hashrate into a likely long set of orphans or ignoring block finds would be discoverable, as well as the publication of a multi-block-replacing withheld attack chain by the pool. When miners are paid by hashrate and are insulated from the actual block finding profit (PPS payment), then the pool owner might see fit to do what they want with the hashes. In this case though they are paying for the hashrate at the expected block reward rate. It's not free. Failure to succeed in making an alternate block chain means that all block find earnings are discarded. If a 30% miner abandons their attack chain against a transaction after 10 real confirmations, then their average cost of failure will be 107BTC. This weird amount is because the 70% remaining honest hashrate takes longer to do 10 blocks - the attack miner would have made on average 4.3 blocks in that time. Their chance of success is not large, and it is even lower than calculations would show, because they can only begin their attack after taking irreversible delivery of the asset paid for in the transaction, and then also must switch the pool software to "attack mode" and craft a replacement block pushing a double-spend transaction to the miners. |
|
|
|
What's the average cost to mine a coin now, kindly tell me, guys.
On average it costs around 1 BTC to mine a bitcoin -- less for some, more for others. It should never cost more then 1 BTC for someone to mine 1 BTC. If it does then the miner is essentially giving away money to the electric company. This miner would be better off buying bitcoin on an exchange if they wanted to acquire additional bitcoin What is the profit of folding@home, mersenne prime number search, or other distributed computing projects that people participate in? Even if merely donating your computing, you are supporting Bitcoin's transaction processing and defending the network against attack in a way that just buying Bitcoin does not. Regarding profit, there is a certain "turn off the miner you already bought" point. This has already happened for CPUs, GPUs, FPGAs and a lot of ASIC miners. It doesn't make sense to pay the power company for BTC when you could just buy them for less. Some miners have contracts or operations with "free" electricity that allow them to operate older equipment, and still others continue to operate their equipment even after they are past break-even. Bitcoin miners turn electricity into heat, so if you were running a space heater under your desk to keep your feet warm, you might as well have a miner plugged in instead to make heat + Bitcoins. |
|
|
|
Just so people don't have to go looking for it... We consider the scenario of an attacker trying to generate an alternate chain faster than the honest chain. Even if this is accomplished, it does not throw the system open to arbitrary changes, such as creating value out of thin air or taking money that never belonged to the attacker. Nodes are not going to accept an invalid transaction as payment, and honest nodes will never accept a block containing them. An attacker can only try to change one of his own transactions to take back money he recently spent. The race between the honest chain and an attacker chain can be characterized as a Binomial Random Walk. The success event is the honest chain being extended by one block, increasing its lead by +1, and the failure event is the attacker’s chain being extended by one block, reducing the gap by -1. The probability of an attacker catching up from a given deficit is analogous to a Gambler’s Ruin problem. Suppose a gambler with unlimited credit starts at a deficit and plays potentially an infinite number of trials to try to reach breakeven. We can calculate the probability he ever reaches breakeven, or that an attacker ever catches up with the honest chain, as follows [8]: p = probability an honest node finds the next block q = probability the attacker finds the next block qz = probability the attacker will ever catch up from z blocks behind Given our assumption that p > q, the probability drops exponentially as the number of blocks the attacker has to catch up with increases. With the odds against him, if he doesn’t make a lucky lunge forward early on, his chances become vanishingly small as he falls further behind. We now consider how long the recipient of a new transaction needs to wait before being sufficiently certain the sender can’t change the transaction. We assume the sender is an attacker who wants to make the recipient believe he paid him for a while, then switch it to pay back to himself after some time has passed. The receiver will be alerted when that happens, but the sender hopes it will be too late. The receiver generates a new key pair and gives the public key to the sender shortly before signing. This prevents the sender from preparing a chain of blocks ahead of time by working on it continuously until he is lucky enough to get far enough ahead, then executing the transaction at that moment. Once the transaction is sent, the dishonest sender starts working in secret on a parallel chain containing an alternate version of his transaction. The recipient waits until the transaction has been added to a block and z blocks have been linked after it. He doesn’t know the exact amount of progress the attacker has made, but assuming the honest blocks took the average expected time per block, the attacker’s potential progress will be a Poisson distribution with expected value:  To get the probability the attacker could still catch up now, we multiply the Poisson density for each amount of progress he could have made by the probability he could catch up from that point:  Rearranging to avoid summing the infinite tail of the distribution… Converting to C code… #include <math.h>
double AttackerSuccessProbability(double q, int z)
{
double p = 1.0 - q;
double lambda = z * (q / p);
double sum = 1.0;
int i, k;
for (k = 0; k <= z; k++)
{
double poisson = exp(-lambda);
for (i = 1; i <= k; i++)
poisson *= lambda / i;
sum -= poisson * (1 - pow(q / p, z - k));
}
return sum;
}
Running some results, we can see the probability drop off exponentially with z.
q=0.1
z=0 P=1.0000000
z=1 P=0.2045873
z=2 P=0.0509779
z=3 P=0.0131722
z=4 P=0.0034552
z=5 P=0.0009137
z=6 P=0.0002428
z=7 P=0.0000647
z=8 P=0.0000173
z=9 P=0.0000046
z=10 P=0.0000012
q=0.3
z=0 P=1.0000000
z=5 P=0.1773523
z=10 P=0.0416605
z=15 P=0.0101008
z=20 P=0.0024804
z=25 P=0.0006132
z=30 P=0.0001522
z=35 P=0.0000379
z=40 P=0.0000095
z=45 P=0.0000024
z=50 P=0.0000006Solving for P less than 0.1…
P < 0.001
q=0.10 z=5
q=0.15 z=8
q=0.20 z=11
q=0.25 z=15
q=0.30 z=24
q=0.35 z=41
q=0.40 z=89
q=0.45 z=340
It takes a careful reading of the paper. It doesn't say "the chance that a malicious miner will win within z blocks" What it does say, is that if the attacker is z blocks behind the current height, qz is probability the attacker will ever catch up from z blocks behind. "Ever", as in "given an infinite amount of time, what is the probability that there ever be a single point in time where the bad miner has caught up and is at the same block height as the rest of the network. This is not really a practical measurement, as a malicious miner won't mine until the heat death of the universe to reverse a particular block, potentially throwing away every block reward they could ever make. The cost of performing this attack is infinite, since it would take an infinite amount of electricity to mine forever, let alone the lost block rewards that have a high probability of being discarded and the cost of mining equipment to maintain the ratio. It is ultimate highest chance that there will ever be a block replacement. The inputs to the formulas given are p = probability an honest node finds the next block and q = probability the attacker finds the next block. One of these is easily replaced - since the probability that anyone finds the next block is 1, the probability an honest node finds the next block is 1-q. What does "probability an honest node finds the next block" mean though? It really means "given both miners starting mining at the same time, the probability that one miner will find any given block. This is related to hashrate, but the clear explanation that it is a direct and equivalent relationship is not given in the paper. At a given difficulty a 90% miner has a mean block rate of about 11.1 minutes, whereas a 10% miner has a mean block rate of 100 minutes. Miners are racing against each other though, not the difficulty, so difficulty cancels out. Ultimately we would need to show our math: using Poisson races (down to the individual hash probability level) and how that translates to a mining regime, prove that a 10% hashrate miner truly has a 10% chance of finding the next block. z is also a starting input. z=1 means the bad miner is behind by one block. This also could mean "a transaction has z confirmations from the good network, a bad miner would need to mine z blocks to replace the block holding it". If z=0, that means the bad miner is currently at the same height as the rest of the network, so the goal has already been achieved. z=0 doesn't make sense as a starting point. So now let's look at the tables and see what they actually mean. Examine the q=0.1 table at the bottom. q=0.1 means 10% probability the attacker finds the next block, and can be interpreted as the attacker having 10% of the network hashrate. The chance they will EVER be able to catch up from their one-block deficit and replace a previous block is P=0.2045873. We need to answer better questions for particular scenarios. For attackers: what is the cost to replace a z=1 block if we continue our attempt for 10 blocks depth, and the probability of success? When does an attempt to replace a particular transaction become profitable (how large a transaction), and after how long should we abandon our attempt? For users: When is it safe to trust a X BTC transaction with a profit-motivated attacker of Q% hashrate attempting to reverse it. |
|
|
|
|
How about use an exchange's option to send you an email when a trade happens. Make your email program go "bong".
|
|
|
|
|
It is going to be very slow using an external drive. The update procedure uses a lot of disk I/O. I would recommend that you download and update using your fastest hard drive (with 20GB free), and then move the whole directory to the alternate storage media and use the new datadir option after the blockchain download is caught up.
|
|
|
|
|
You should describe exactly what you mean by "update" and "recovered my wallet.dat". Did you install windows updates? Did you put in a new hard drive and reinstall windows? Did you format your drive? It is hard to prescribe a course of action without knowing what you did, what wallet software you are using, what windows you are using, etc.
|
|
|
|
2FA is really not good for wallet security as all that 2FA does is rely on a 'trusted' third party to only give someone access when they can enter a code that is delivered to a device. This essentially means that you must give up access to the private keys to a third party, which in itself is a bad security practice.
This is a very good summation of the issue. If you use a wallet that is not completely and solely under your control, you're gonna have a bad time. If your Bitcoin keys are on another service - if signing transactions happens anywhere else but on your computer - then you are vulnerable to attack. Internet two-factor authentication schemes prevent simple password-stealing attacks, but assume a secure unalterable communication channel, which is a bad assumption. SMS codes, challenge-response, time-based one-time passwords, yubikey, all can be proxied by an attacker and instantly replayed to the actual service. Secure communications require encrypted and signed channels, such as done through a Java smart card provided by the internet service, which relies on the device also not being security-degraded by secret arrangement with a three-letter agency. Look at blockchain.info wallets - in theory secure, but in practice any man-in-the-middle (such as a Tor exit node, your VPN company, hacked service home page with injection, or government tapping/redirecting the connection) or even man-on-the-side (with the poor security of https encryption) can intercept your communication with the service and steal your credentials, secrets, and Bitcoins. Since the something-you-have also goes over the wire, this provides very little security to an attacker in these positions. With Bitcoin, you must be your own bank. You cannot ask for a refund when you are defrauded. Real personal two-factor relies on something you have along with something you know. Something you know is your password to the encrypted wallet. Something you have is your local computer with the Bitcoin wallet. If someone else doesn't have both of these, they can't send Bitcoins. Another layer of something-you-have/something-you-know can be a two-layered encryption scheme for accessing the local device. An example would be a smart card OS drive encryption in combination with a password-based hardware drive encryption. A further layer would be to use a TPM module for OS full disk encryption, this requires something you know (password to unlock TPM) and something you have (motherboard/system TPM) to access the drive. The drive separated from the security device is also useless. If you want another layer of security, lock every Bitcoin wallet storage device or computer in a safe. Then to access it you need something you have (a safe, a key) and something you know (a combination). |
|
|
|
|
Show Posts
