You forgot #4, technically correct, about something pointless and intentionally ignoring the distinction to give the illusion of superiority.  Odd that you'd forget it, since your post was a perfect example.

Your memory pool won't help you during the initial download, which is the time when people care about traffic.  No one gives a shit about 8 gigs over 4 years.  Everyone cares about 8 gigs today.  Using a piecewise downloading system will save some traffic* for people that don't give a shit about traffic, and save not even a single byte for people that do.

*  "close to 50%" savings needs a lot of assumptions to be true at the same time, when some of them are never true at all.  A partial list:  bitcoin traffic is evenly divided between block bodies and transactions, the list of transactions in a block can be transmitted for free, every node knows about every transaction.

Yup, you have it right, at least functionally.

The pubkey is structured data with a eight bit header followed by one or two fields of 256 bits each.  The first field is X and is always present.  The second field is Y, and is only present when the header is 0x04.  Stripping off the 0x04 and taking the first half is the same operation as unpacking the X value, so what you are doing is exactly right.  I just like to explain it in detail so that other people reading this thread will understand what that operation represents logically.

You just need to keep track of whether you are compressing or not.  If you are using the compressed form, you must use the compression flag in the WIF.  Even though they represent the exact same idea, the compressed WIF won't work with the uncompressed pubkey, nor the reverse.

Your numbers are a bit off.  You are ~ 500 MB, not ~ 4 GB.

Most likely, you didn't shut down cleanly and your databases got broken.

My understanding is that it is a privately owned corporation, but their corporate charter is a federal statute rather than an ordinary corporate charter.  The member banks are the shareholders, but being a shareholder doesn't confer the usual control that a normally chartered corporation would have.  As in, the "owners" can't change the bylaws, etc.

Coins are not stored on your computer, or in your wallet.  If the transaction actually happened in the public block chain, it doesn't matter what software you are using to see it.

You just need to make sure that you still have the wallet.dat that contains the key to the address you sent to.

All of the other threads on this, including the one from yesterday, say no.

These are all pretty common topics in IRC.  I recall some of them from the mailing list too, but I don't read that daily any more.  People are working on various parts.  For one example, see here.  The bootstrap torrent is another example.

Pitch in and help if you can.

On the server I used for testing, in my bitcoin.conf:

The %s in the command line gets replaced with the (ASCII) hex string of the transaction hash, just like -blocknotify replaces it with the block hash.

And the program can be as simple or as complicated as you like.  Here is a simple shell script:


which gives lines like:


You aren't limited to shell scripts, of course.

A pipe would have been better, but they aren't portable.  Even if we had been willing to limit it to just UNIX-ish systems, there would have been horrible locking problems, and these notices simply weren't worth the effort to work around them*.  If you want similar behavior, you can fake a pipe with netcat, so that you could have a long running service that accepts TCP connections from localhost, and just call netcat to dump the txid to that socket.

*  Did you know that named pipes can stall in both directions, potentially DOSing one of the client threads?  There are ways around it, of course, but you have to throw out a lot of the abstractions, so there would have been a very un-C++ chunk of code in the bitcoin client, just for dealing with the pipes.  At least that was how it looked to me when I was researching it.  I don't do much with C++, so I'm hoping that someone in the audience is more skilled than I am, and will read this and say "You dumbass, why didn't you just do X?", or even better, rewrite it for me. 

If only there was some way to find all of the other threads on dwave, like this one from two days ago, or this one from two years ago...

I've read this four times now, and I still don't know what you are trying to say.

It is even worse than that.  If the private key is in WIF form, the last 32 bits are a check code.  So, divide your answer by 2^32 and you get about 10 possible keys that need to be checked

The quirks of the encoding make key recovery a bit harder than that, but it is still WAY less than the 38 billion quoted.

If you are talking about the -walletnotify config option in 0.8.2rc1, it works exactly like -blocknotify.  You specify the path to a program to be run.

The program will be run with a single argument (the transaction hash) when a new transaction hits your wallet.  Actually, it will run once or twice per transaction.  First time will be if you receive that transaction as a transaction, and the second time when you receive it as part of a block.

That program can be a script that uses some other tool (curl, wget, whatever) to issue a call out to an external webservice, or it can do whatever you need directly (update a database, logfile, etc).

If you are a high volume site that gets lots of transactions, you may need to be careful with it.  It can spawn a lot of new processes, so you should make your script fast and simple.  Just dump the txhash to a journal file (or table) and exit, for example, with a cron job to come around later to collect and process them in batches.

People were looking for a simple way to track incoming transactions, and this was the easiest way to do it.  It has some quirks, but it is still vastly superior to the hacks people were having to use before.

I've actually read all of the stupid posts in this stupid thread.

One last time just to be clear:  You are still free to create whatever transactions you want.  You are NOT FREE to force other people to relay or mine them.

You are not being censored.  Grow up.

There is no censorship here.  You are still free to create and broadcast any transactions you want.  This patch just makes it easier for other people to decide whether to relay your garbage or not.

First number is current difficulty, second number is projected next difficulty, third number is % change.

Keep in mind that the new current difficulty is like 50 blocks old at this point.  Predictions for the next difficulty based on such a short window are, erm, "speculative" at best.

I'm all for this.  But, it is harder than it looks.  The tricky part is that you have a bunch of competing pressures that you need to balance against the needs of the user.  It gets hard to quantify some of the decisions you have to make.

I wrote my own script to do a little bit of collections and consolidation.  But my script is not a general solution, it would be worthless, or worse than worthless, to people with different needs.

The private key is a random 256 bit number.  Every 256 bit number is a private key, but some are safer than others.  You should use the strongest entropy source that you can get your hands on to generate them.

The public key is then simply pubkey = G * PrivKey.  The catch is that * is EC multiplication in the appropriate modular elliptic curve field and G is the base point of that curve.

From there, it is just a matter of hashing and encoding to generate the address.

All of this is well published.  Would you like some tips on searching?

No, really.  As far as bitcoin is concerned, all of the transactions in a block happen at the exact same moment, in the order listed in the block.  They may have been created years ago and published days ago, but that doesn't matter.  They are deemed to have happened at the time listed in the block header's timestamp field.  For extra amusement, keep in mind that the block's timestamp can be in the future or the past.  It is a rare block indeed that actually happened exactly when it claims it happened.

Your belief in this is not required.  I'm telling you how it really is.

I hope that the other posts in this thread have led you to do some research into what exactly a cryptocurrency is, and how it differs from a bank ledger.  Bitcoin is not just the same money that you know about under a different name.  It is something new.  Well, new-ish.

You can send transactions to yourself.  If you just do sendtoaddress, you won't necessarily collect the small transactions that you are hoping to collect, unless you send your entire balance to yourself.  Which isn't necessarily a good idea, by the way.

Or, you can use the raw transaction API to collect the small transactions and send them to yourself, manually.  This is a hassle, but works well, particularly once you have it scripted.

Holy shit!  John McCain is a time traveller!  After learning that Iran was no longer exporting oil for dollars in December 2007, he travelled back in time to April 2007 to make a joke using a 27 year old song to warn them of the dire consequences of their decision.