He'll get all of them in less than an hour.
What about difficulty adjustments though? Difficulty will increase by a factor of 4 every 2016 blocks. Current difficulty is > 32000 or 2^15, plus the implied 32 bits for an actual value of 2^47, ie 47 bits of zeroes at the front of the hash. We add 2 more zeroes every 2016 blocks, so after 105 such adjustments, the target will be all zeroes! However, I peeked at the code, and even an all-zero target can be met with an all-zero hash. So theymos is right, Mr Lucky (who I think has an infinitely fast computer in his pocket) can go all the way, as fast as the net can broadcast blocks. |
|
|
|
|
Yes, I can read it now with the darker background.
|
|
|
|
|
Frankly I find it illegible.
|
|
|
|
I'm kind of surprised that Mike's transactions didn't show up in my wallet. Instead it still counts that address as having a positive balance. Granted it is non-standard for payments from my wallet keys to originate elsewhere, but there are other ways it could happen, involving restoring from backup.
Well I just looked at the code, and it does only watch for transactions that pay me. However it looks like the new release will rescan the block chain on startup; that will probably fix it. I wonder how costly it would be to watch for outgoing transactions all the time.
I just upgraded to 0.3.20, and while it didn't find Mike's transaction automatically, I ran with the new -rescan switch and that picked it up. Only took 10 or 15 seconds on my Macbook Air. |
|
|
|
1. In the FAQ it says, "You need to make a backup of the wallet after every transaction, as the old backup file will be partially or fully invalid." Sounds like that FAQ entry is obsolete and should be updated. |
|
|
|
Did you ever get this? Here's some minimal code that might work. Add to rpc.cpp after getwork: Value broadcasttransactions(const Array& params, bool fHelp)
{
if (fHelp || params.size() < 1)
throw runtime_error(
"broadcasttransactions <hexencodedtransaction> ...\n"
"Broadcasts specified transaction(s) out onto the network.");
for(int param=0; param<params.size(); param++)
{
string strTx = params[param].get_str();
CDataStream vMsg(ParseHex(strTx));
CTransaction tx;
vMsg >> tx;
CInv inv(MSG_TX, tx.GetHash());
RelayMessage(inv, tx);
}
return Value::null;
}
Then add at the end of pCallTable (the next code block): make_pair("broadcasttransactions", &broadcasttransactions),
Maybe add "broadcasttransactions" to that next table, pAllowInSafeMode, otherwise I guess you have to start the server with -disablesafemode. This is untested, I only spent about half an hour on it, so you don't have to pay if you use it. |
|
|
|
I was an early participant on Less Wrong as well as its progenitor Overcoming Bias. One principle of rationality is not to choose goals blindly, but to think about what you ultimately want to accomplish, and decide what projects make the most sense. That's why I asked, why Bitcoin? Much discussion on those sites is on cognitive bias, and IMO the most important bias is overconfidence. Study after study has shown that people vastly overestimate the accuracy of their predictions and estimates. The hard step is taking this to heart, and accepting that it applies to you, not just to people who disagree with you. Just to give you a taste of how far you are from rationality, there is actually a mathematical proof that two sufficiently rational people cannot disagree. According to these communities, one of the best ways to get unbiased estimates of future events is the prediction market. They have strong track records and good theory behind them. A Bitcoin based prediction market would be a great asset and contribution to the world. |
|
|
|
|
Now all we need is a proposal to overload the block chain to hold email, and the circle will be complete.
|
|
|
|
|
Is it rational to try to achieve Bitcoin dominance? How confidant are you in forecasting the consequences if you succeed?
|
|
|
|
|
sha256sum produces hex output, you need to convert to binary with xxd:
sha256sum -b manual.txt | colrm 65 99 | xxd -r -p | sha256sum -b
d1e802bfb7a086bb37e3e3f395e990e2663354ffaf948b9dde71020000000000
|
|
|
|
|
I'm kind of surprised that Mike's transactions didn't show up in my wallet. Instead it still counts that address as having a positive balance. Granted it is non-standard for payments from my wallet keys to originate elsewhere, but there are other ways it could happen, involving restoring from backup.
Well I just looked at the code, and it does only watch for transactions that pay me. However it looks like the new release will rescan the block chain on startup; that will probably fix it. I wonder how costly it would be to watch for outgoing transactions all the time.
|
|
|
|
|
Congratulations Mike! That was fast, you got the bitcoins only two blocks later. Not only that, you had to create a transaction with 5 inputs, corresponding to the 5 payments into the address. Do you mind telling how you did it?
As far as use cases, you could email someone some bitcoins without knowing their address, or even if they hadn't tried Bitcoin yet. Some people want to print bitcoins on paper and put them in a safe for long term security. If you could pay bitcoins to a newly created key, and export the private key, it would be a backup that would be safe against wallet theft. Lots of people have asked for this.
|
|
|
|
|
Sorry! I did screw up the encoding. Here is the 256-bit private key in big-endian hex:
C85AFBACCF3E1EE40BDCD721A9AD1341344775D51840EFC0511E0182AE92F78E
My new attempt to base58 encode this is:
EV71KQfoePBeWT79sV1VE7fWRgv1KNUxTNapH6ZbaRfB
That's custom code, maybe somebody could check it.
To apologize, I've added 30 BTC to the address. We're now at block 109352.
The reason I did it this way is that it would be a good format for passing around or backing up bitcoins.
BTW the new version of Bitcoin has a -rescan switch to find all txns that are for wallet keys. Only takes a couple minutes.
|
|
|
|
|
Checking the amount on an address would be very fast. Just scan the block chain to determine the balance for every address, and store as a hash table. Lookups would be in the nanoseconds, inconsequential compared to EC math.
None of this would create network activity.
|
|
|
|
|
This is a base58 encoded plain private key (256 bit value from a "key" entry in my wallet) worth 20 BTC. We're now at block 109180. Let's see how long it takes for someone to input the key and collect the bitcoins.
2qy6pGXd5yCo9qy3vxnN7rALgsXXcdboReZ9NZx5aExy
ETA: this is wrong, the correct value is later in the thread
|
|
|
|
|
Right now I'd estimate there are 300,000-400,000 funded addresses. Let's round up to a million, 2^20. When you generate a new address the chances are 2^20/2^160 or 1 in 2^140 that you will collide with a funded address. You need to generate 2^139 addresses for a 50-50 chance of success. With my estimate of about 2^17 tries/sec, that is 2^122 seconds. That is over 10^29 (1000000000000000000000000000000) years. Not a problem.
|
|
|
|
|
Bitcoin addresses are 160-bit hashes of keys which have 256 bits of uniqueness. We could switch to a 256-bit hash pretty easily (or even not use a hash, just use the 256-bit x coordinate of the public key). The scriptPubkey could use OP_HASH256 instead of OP_HASH160 to reduce the risk of collisions. Addresses would be a few characters longer.
|
|
|
|
|
Show Posts
