Don't look at a website to find the value of an unspent output.  Use listunspent, or getrawtransaction/decoderawtransaction.

Why do you think you can solve this now?  If people really have a hard time with milli, micro, nano, why don't you just wait to see what they actually do use?

OCR-A is indeed ugly.  But it was designed to enable OCR in the 60s.  It also has the advantage that all glyphs are distinct.

On my paper wallet sheets, I include several QR codes, barcodes, OCR-A and human-friendly printed versions of everything.  Just in case.

Maybe you'd be better off just explaining what you want to do.

No one anywhere is going to get confused about your hashing speed.  No one counts work requests as speed, they count work returned.

The getwork protocol doesn't care about IPs, but the tracking database might, so your work may or may not be accepted at all, depending on the server you are talking to.  Stratum uses a persistent connection, and I don't know the protocol in enough detail to know whether or not it will accept (on the protocol level) work on one connection that was given out on a different connection.

Sure.  And if you can find a pool that pays based on work requested rather than work completed, PM me.

Check dates before posting.  This thread has been dead since July 2011.

Personally, I think you would be better off making 5 new private keys and then making a P2SH multisig 3-of-5 address from them.

Close.

The output of the hash is 256 bits, not an ASCII string.  Basically, the hash is a number between 0 and 115792089237316195423570985008687907853269984665640564039457584007913129639936.

The leading zero part is just because the hash must be below the target.  The target is related to the difficulty in a way that target is roughly equal to 2²⁵⁶-(difficulty*2³²).  Right now, the target is 4026319404534786334009451711043898716884778820756489262596096.

See these two pages:

https://en.bitcoin.it/wiki/Difficulty
https://en.bitcoin.it/wiki/Target

Heh, this topic has plenty of threads, not just the one you found.

Basically, Satoshi needed to write the whole thing before he could be sure it worked.  And then we all started using it.  And now bitcoins are downright valuable.

Meanwhile, there is still no formal specification.  And the damn thing is complicated.  If you've been in the source much and followed the discussions here and in IRC, you can start to believe the devs when they say that your choices for a specification are either 1) wrong, or 2) nearly as complex as the source code itself.

Let me give you one odd example.  The coinbase from the genesis block is unspendable.  At first, it was a bug that kept the txid out of the index, but now, we have to explicitly flag that transaction as unspendable.  If we don't, then Satoshi has the power to fork the network at will by redeeming it.  Basically, that bug has to be part of the specification, when one is written.  And there are more and stranger things that any node has to faithfully reproduce to keep the network sane, and we have no way of knowing that we've found them all.

Cons:  OP didn't search hard enough to find any of the other threads about this idea...

This just uses a regular computer power supply.  All modern power supplies are built for a broad range of power inputs.  There is usually just a little red slider switch near where the plug connects.  I can't even remember how long it has been since I saw one without that switch.  If it says 115, slide it over to the 230 setting.  They can even adjust automatically for 50 Hz or 60 Hz operation.

Nice thing about using 230 is that it draws half as many amps for the same wattage.  This means you can run twice as many on the same circuit.

I keep saying 230 because that is what the switch and sticker will say.  It many parts of the world, it will really be 240.  Doesn't matter even a little because modern supplies are high frequency switching supplies and can take a very broad range of inputs.  You can usually even get away with 208 if your service is using high leg delta on three phase.

The problem you run into is that there are no wallets and no balances, not really.  What you spend is the output from a past transaction, and that spend is always complete.

What that means is that if you have 10 BTC, unless that is a single UTXO, no one knows that you have 10 BTC, they only see the transactions that you are redeeming at the moment.  And there is no way to put a "hold" on any others, nor a way to remove such a "hold".

Once you sign it, it is gone, all of it.

The only time this isn't true is when you are attempting to double spend by redeeming the same output twice in different transactions.  And the whole complicated bitcoin system is built for resolving that situation, but you can't tell which way the ambiguity went except with a decent amount of hindsight, which in this case means blocks and time in the past.

The only way around this is with a trusted third party.  Such entities already exist in the real world, and there is no reason to think they won't find a niche in the bitcoin future.

Google "bitcoin free transaction relay policy"

Keep in mind that the fees are pretty much not fees at this point, but are really anti-spam measures that use the fee mechanism.  I routinely send zero-fee transactions and get them relayed and mined in normal time.  It takes some awareness of the default client's priority mechanism, but if the 3 cents bothers you, you can avoid it right now, usually.

Also keep in mind that the fee system is constantly evolving and improving.  The day when fees will be set by market forces is coming soon.

There was a mystery miner a while back that a bunch of us were almost certain was actually a botnet doing mass CPU mining.  It included no transactions in blocks, except the coinbase.  We figured the real reason to not include transactions was to minimize network traffic and simplify the software.

The real solution is to make CPU mining the least profitable use of stolen CPU time, and GPUs and ASICs seem to be doing pretty well at that.

I have a 32 bit box running with less than 1 GB of ram.  It has two instances of bitcoind running, one with 1 connection, and one with 60 (nearly or all incoming).

I think the real problem is running into some artificial limitation in lousy VPS software.

Yes, the reference client still checks for standardness of transactions before mining or relaying.  Look for the IsStandard() function in main.cpp.

I believe that there are still some pools and nodes that are willing to bypass those checks too.

When you set an encryption key for your wallet, all unused keys in it get marked as used, so they won't be handed out to satisfy requests for new addresses.  This is to keep you from getting money sent to potentially unsafe keys.  However, the keys are not marked invalid or discarded, so if you do manage to get one (using pywallet or db_dump or something), you can still use money sent to it.

Now, with all of the keys marked as used, your node needs to generate a bunch of new keys for the keypool, so that it can give you addresses without asking for the encryption key again*.  This means that your wallet now has a bunch of keys in it that are not in the backup you made before encrypting.  If you ask for a new key, and then restore from your backup, any money sent to that key will be lost and gone forever.  So, right about now is a very good time to try to scare you into making a new backup.

The reason the message says that your wallet won't work any more is because people don't want to read a detailed essay on wallet key and backup management.  The message just needs to convince people to make new backups, not necessarily go into all of the gory details about how and why.

If you can think of a concise message (that is also easily translatable) that is likely to get people to make new backups, without technically being a lie, please suggest one.

*  Yes, it needs the encryption key to encrypt your new keys.  It uses AES which is symmetric.  Once your wallet is encrypted, the client is no longer able to generate keys without your help.  Fortunately, the keypool is big enough that for most people, they will provide the encryption key (giving the client an opportunity to safely store the encrypted keys) during normal usage long before the pool of unused keys is depleted.  And yes, there are reasons why the keys aren't stored with public key crypto, which would allow unattended write-only access to the key storage.

No formal requirements, no formal process (that I've seen).

Make the pull request, people will see it, comment, etc.  If there are no big objections and at least a couple of ACKs, it'll get pulled.  Most of the discussion happens on the github page and in IRC.  Try to make sure your branch is correct and complete before you make the request.  If your patch is not totally trivial, you'll need to make some changes before it'll be accepted, but it looks bad when the build tester bot reports that your pullreq can't compile.

As for the two specific examples in this thread, I like the -purgetransaction option.  Personally, I'd prefer an RPC call that selectively removes one transaction without needing a restart, but this would still come in handy at times.  As for the source for sendmany, can't you just specify the default account with an empty string "" ?

Good to see that multicast is still widely misunderstood.  While it is true that a message needs to be received the same number of times in multicast (that number being the number of nodes), what changes is how many times it needs to be sent.  It also reduces latency, since the distance across the network becomes n routing hops + 0 verifications, rather than the current n routing hops + (n-1) verifications.

People have a hard time with big numbers.  Bitcoin addresses are 160 bit hashes, meaning that there are 2¹⁶⁰ or 1461501637330902918203684832716283019655932542976 possible addresses.  Your chance of finding a private key that generates a public key that hashes to the address in my signature is about 1 in 1461501637330902918203684832716283019655932542976.

If you don't care about matching an exact key, but just any other key, the birthday problem says that you need a lot fewer attempts.  The approximate number is sqrt(2*H*ln(1/(1-p))) where H is the number of possible addresses and p is the probability you are willing to live with.

If you are willing to take a 1% probability, then you need to try roughly 171464281994822466873809 different keys.  That number is 24 digits long, or a bit over 2⁷⁷.  For comparison, at block # 227663, the amount of work embedded in the hash chain was 899359750187287492752, which is a bit less than 2⁷⁰.

So, if you had the enough computing power to do in one year what the entire global bitcoin network did in 4+ years, it would take you about 2⁷=128 years to have a 1% chance to find a single address collision.  And the odds are really good that you'd find one of your own addresses a second time, not one with money in it.

I'm not checking my numbers very carefully, so I might be somewhat off along the way, but even if I'm off by a lot, you still don't need to worry about it.