Here's what I would suggest. Create a new key pair in your code. Hash and sign something like 'abc'. Then see if you can verify the signature. If it works, publish the key and signature here. I can try to verify the sig with OpenSSL. I was successful at verifying a Bitcoin signature, so this might reveal differences in the two libraries.

I was able to verify the signature using the openssl command line and a bunch of cutting and pasting of hex dumps. The data input to the hash is

and the hash is

e8a875b4a6b23e507cdad56d1d74285f22fec05bfd6be2f737923c43fcc23987

If you have this value, it is correct, and you can look elsewhere.

The sum of the IN values has to be greater than or equal to the sum of the OUT values. If it is greater, the difference is a transaction fee, collectable by whoever generates the block that includes this transaction.

Okay, I did that too, and the secret is that the scriptSig is entirely removed and replaced with the scriptPubKey from the source (old) transaction. I'm still a little confused about how this works in the source.

VerifyScript() doesn't actually concatenate the two scripts. It runs scriptSig, and that leaves stuff on the stack, then it runs the old scriptPubKey with the stack left by scriptSig. The only connection is the stack. So when we run the scriptPubKey, which holds the OP_CHECKSIG, the "current script" is just that, the old scriptPubKey. This is the script which gets OP_CODESEPARATOR stripped and then put in place of the scriptSig, for hashing.

What I don't understand is this line from the OP_CHECKSIG code:

                    // Drop the signature, since there's no way for a signature to sign itself
                    scriptCode.FindAndDelete(CScript(vchSig));

This is apparently the basis for the advice to "remove the signature" for hashing. But it doesn't make sense, because there is no signature in scriptPubKey, which is where this opcode is found. This line doesn't seem to do anything, and advice to remove a nonexistent signature is misleading.

What you are doing looks pretty good to me now that I understand it better. I tried hashing your data and got 90377525e05bd71ce8ba413a84fdaea299766732f165fab28a69d30c83337f9b, don't know if that matches yours. The only other thing I can think of would be to try reversing the hash on input to the ECDSA functions.

Okay, I've confirmed that hashes OK using sha256sum and gets your value, 0f898c5494eaa468d12cf0630a0c0b238cc1149c1c53bbc592d16497094e95ff. So the question remains to verify the sig.

You will have to add 01 00 00 00 to the end before you hash, for the hashtype.

I'm not sure about your scriptsig shortening. You removed the sig ok, but there seems to be more stuff added at the end, after the pubkey.

Wow, that's bizarre that the byte order of the hashes is reversed on the wire like that. Have you tried reproducing the published transaction hash by hashing the raw transaction? Does that work? What do you get, 0f89... as it is on the wire, or the reverse, ff95... as blockexplorer has it? And do you need to byte reverse the embedded hashes in the tx in order to get the right answer?

I don't see how that hex dump corresponds to the transaction. You have outpoint hashes starting with 30 f3, 72 14, and d2 81, none of which are in the transaction.

Ah, okay,  I didn't know that miners worked that way,  thanks.   

Interesting analysis! Don't forget that in several years, if Bitcoin succeeds, there will be orders of magnitude more transactions. And some of these will be able to pay substantial fees. So there will be a strategy to start generating right away, beat the miners who are waiting, and collect these high value tx fees.

Also, currently miners don't update the block they're working on with new transactions as they come in. I think that makes the hash search more efficient. So by the time a block is generated, there's already a substantial pool of new transactions to start working on. This too may change in the future though.

I'd add speed, you shouldn't have to wait too long for a transaction to go through. Bitcoin gets a B-, it's fast enough for a lot of things but too slow for some.

Scalability, could it be used for every transaction, everywhere in the world? In its current form I'd say no, but possibly with the addition of lightweight clients. So I'll say C, has potential but not there yet.

Bitcoin aims to produce blocks every ten minutes. But the actual time between blocks is quite variable, being governed by the Poisson distribution. I listen to block formation, and this variability is apparent. It's not unusual for blocks to be formed just a few seconds apart, while sometimes an hour goes by without one.

This variability is intrinsic to the hash solutions used by Bitcoin, and will not change even as the network grows. It may be a problem particularly for transactions that want a single confirmation. An application where a ten minute delay is acceptable might be in trouble if the delay becomes an hour.

A way to reduce the variability while maintaining the average solution time is to split the hash problem up into several sub-problems. Instead of solving a hash puzzle with difficulty 16,000, solve 4 puzzles with difficulty 4,000. The total difficulty and average time to find a solution is the same, but the variability is much less. Splitting into even more sub-problems will further reduce variability.

A downside to reducing variability is that we would have more block collisions, where more than one node solved the same block at about the same time. This would reduce the efficiency of the network, as nodes work on blocks doomed to be superseded, and blocks get reshuffled in and out of the longest chain. Also, it would give more advantage to the fastest node; in the extreme, if we eliminated all variability, it would win every time.

So we wouldn't want to go too far with this. But splitting into a modest number of sub-problems could substantially reduce the odds of hour+ inter-block intervals, hopefully without causing too many problems.

I was scared to upgrade since I had a fair amount of vintage bitcoins in there. But everything seemed ok. I'll play with it some more and see if I can get a key pool.

I was wrong about the wkey, it would mostly add creation and expiration dates, maybe a future feature.

I made some edits. It might be nice to explain what the various SIGHASH values are intended to be used for, and whether they will work at this time.

I modified the bc_key program originally by dirtyfilthy, to dump out info on everything in the wallet.dat file.

https://github.com/halfinney/bc_key

It prints out keys (as addresses), transaction hashes, key pool addresses, address book names, etc.

Run it as:

./bc_key EVERYTHING ~/.bitcoin/wallet.dat

or wherever your wallet.dat might be. I like to pipe the output through sort.

I've noticed two oddities in the couple of wallets I've looked at:

There are no wkey entries, only keys. wkeys would hold extra stuff with Merkle branches and all that. Is this not yet (or no longer) supported, present in the code for the hypothetical "lightweight client"?

I have a very old wallet, created by the first version of bitcoin. Recently I upgraded to a modern version. However, the wallet has no pool entries. I thought the upgrade would create 100 keypool entries?

Here's where grondilu describes his scripts to sign arbitrary data with wallet keys using openssl. Very impressive.

http://bitcointalk.org/index.php?topic=2694.msg39658#msg39658

See also the program referenced in post 15 of this thread:

http://bitcointalk.org/index.php?topic=2507.0;all

I think grondilu has some code samples showing how to sign with these openssl keys.

I don't think it works that way. The banker can't get a shoe shine with the new money, because it does not belong to him. It belongs to the bank. And what the bank does with the new money is lend it out.

Now, when you connect to the port, the client spews out a version message, which reveals its identity. With the shy patch, there's no response. It could be ssh, could be torrent, could be bitcoin, could be http, could be anything. The scanner would have to try to send crafted packets for each of dozens or hundreds of known protocols, to try to elicit a response.

Of course while we're all on 8333, it's pretty obvious what's what. But presumably that will change eventually.

Maybe we should fix this duplicate-transaction problem. We could embed the block number in the generation transaction so they would all be unique. Right now the txin has hash = all zeroes, n = UINT_MAX. We could change to n = block number and still identify it as coinbase by the zero hash.