Check this - it's a real signature from tx 67e758b27df26ad609f943b30e5bbb270d835b737c8b3df1a7944ba08df8b9a2:


Following the format, the hashtype should be 00, while in fact it is 01.

there is actually an issue that not everyone is aware of, though I don't know if it is the reason of your problem.

the hashtype byte is not taken using this format:

it is taken using this expression:

and you cannot fix it - it's buried deep inside the chain.
https://blockchain.info/tx/67e758b27df26ad609f943b30e5bbb270d835b737c8b3df1a7944ba08df8b9a2

well - then congratulations, man!
as the first person in the world, you have managed to write a bot that would be smarter than his creator.
that's indeed an achievement that one could be proud of - a breakthrough on the field of AI science, I would say.

but to not get this post deleted because of an OT (which it should), let me add something, on topic.
I've tried to analyze different approaches to calculating a reliable hash of any UTXO database, and it seem to be pretty straight forward.
obviously one would want to be able to calculate the checksum, while having only the UTXO db (without a need to re-parse the entire chain).
obviously one would also want to quickly apply differential changes to the checksum, that come after applying each block.
both can be achieved simple by serializing each UTXO record, then hashing it - and XOR-ing all the hashes together to get the ID of a UTXO snapshot.
extending the hash size to i.e. 512 bits might be a reasonable option as well, though it would be worth to have some numbers to support it.
when an output is being spent, its hash is XOR-ed with the checksum again - this way it gets "removed" from the UTXO db ID.
maybe you don't even need to serialize and hash the record - maybe it would be just equally safe to use (TxID ^ Vout) as the value - EDIT: sorry, what was I thinking

as always, feel welcome to slap me with a constructive criticism. just please make sure to double check first what "constructive" means.

Not quite.
First of all, "what checkpoints do", among all the bullshit that you've lectured us about, is making sure that a node will have an exact content of UTXO db, at a specific block height.
Second, all I suggested was extending a protocol with a possibility to automatically mine into block a hash that points to moving snapshots of UTXO db. I call such a hash a "checkpoint", but feel free to call it however you like.
There is no better chain compression (and bootstrapping time improvement) than this.

In my concept, it would be totally up to a user whether he wants to get a valid UTXOs by doing it the old fashion way (starting from the genesis block and verifying through all the 250k blocks), or if he prefers to enter a hash of a block that he knows is trusted and, using the reference mined into that block, to fetch the entire content of UTXO within a few minutes.

Your great achievement, so much advanced SPV clients that nobody wants to use, isn't anyhow more secured than the solution I proposed would have been.
The only difference is that the later would at least be useful - very useful, since we see all the time people complaining about bootstrapping times and blockchain size (aka pruning).


False history that ends up at the exactly same hash? Hmmm.. Do you even have an idea what a 256 bit number is?

Stop dreaming and get real. It would be easier to brute force the private keys, since there is much more of them, rather than to find a matching tx history leading to the same hash and tricking the entire network into distributing this copy, instead of the original one.

If you think 256-bit hash is not secured enough, I have no problems with you making it 512 bits, but bear in mind that if anyone manages to reverse SHA256^2 then you can as start looking for another job, because the entire bitcoin is totally broken then  - no matter compressed, or not.

Sure, no problem - it's like an hour task.
But first see if gocoin suits you (i.e if you can build and run it at your machine) - then, if you still like it, just let me know and I will add it for you.
You can also play with the source code yourself - it's a new language, but pretty intuitive, especially if you come from C.
In fact if you build your stuff into the actual node, you can probably optimize the app pretty much (i.e. you don't need to pull for data then, but have your code called immediately when a balance changes).

By default it only binds to localhost, but yes - there is an IP access control already, if you'd want to connect from a different host.

Normally you get a list of all unspent outputs that belong to a given bitcoin address.
Each record contains txid+vout, block number and the BTC value (amount).
Note that after you spend some transaction, it will disappear from the list.
It's more like this one: http://blockchain.info/unspent?active=1MM5zVVBGxZ5F2hNoLvcerLdzfQAKFVFgY

No problem.

But this is just a different way of doing checkpoints - moving one (current height minus 5K blocks), instead of values fixed in the code.
You basically define a rule that your node does not accept any fork older than 5k blocks.
Which is of course a much better solution than the current checkpoints scheme.

Bitcoin would work, but the node's storage could easily get stuffed with bogus blocks that hook very early in the chain, thus are extremely cheap to be created.
And it's almost guaranteed that as soon as you'd switch them off, such attacks would appear.

Moreover, since we're talking about block purging.
Block purging implies that there must be some kind of judgement whether an orphaned block buried deep inside a chain is already old enough to purge it - you cannot have any purging without some sort of checkpoints that would tell you how old an orphan needs to be, to be considered too old.

ATM there is no API that you could use from php app. I haven't developed any, because I had no need.
If you think about something like JSON-RPC, to get list of unspent outputs (balance) for a given set of addresses, I can add it for you.
Since there is already a framework for WebUI, I believe the easiest solution would be to add a new page handler that would return you an XML or JSON file for a URL based query.

Anyway, when you get to a point where you have a client running, check the "unspent" command to see how quickly it can work with a random address. It takes about a second on my PC to go through all the unspent outputs and output the balance.
Though, if you could define an address pool (I call it a wallet) - it takes a second first, but then the balances are cached and updated as new blocks appear, in which case you get the values almost immediately when you need them. For this you can try "wallet <addresses.txt>" and "balance" commands.

Coming from this angle, when you want to start disabling things in the source code, then everything becomes optional.

But seriously, I'm not criticizing checkpoints here.
Checkpoints are needed - for the very reasons that they were put in, in the first place.
I mean, they should probably be replaced with some other mechanism, something that would not be a value fixed in a source code, something which does not require upgrading the client in order to move a checkpoint, but eventually we still need the protection that they add - no argument here.

Excuse me?
What I don't understand about writing bitcoin software, that you do?
You have this patronizing attitude all the time, but I don't think you are smarter than me, so I am not going to bend before you, just because you are here longer.
If I have an idea, I am always open for a criticism - as long as it is technical and specific (not like in your quote above).

Are you saying that I don't understand how the concept of checkpoints reduces bitcoin's security model?
Oh, trust me that I do. But I am not the one who invented them and put them into the code, in the first place - I am not the one who broke the security model already.
I am only a one who proposed getting a further advantage of checkpoints, in order to implement an ultimate purging solutions.

Maybe you just don't understand something here?
Maybe you don't understand that if the only way for a bitcoin software to work is by validating a chain up to a checkpoint that is fixed inside the very same code that validates the chain - then validating the chain up to that point is just a big waste of time, bandwidth, CPU and storage.

Indeed. https://bitcointalk.org/index.php?topic=247110.msg2683001#msg2683001
But you know, they are very busy now with "tackling the low lying fruit" - whatever useless feature it is

it does remove unspent outputs as they get spent
it doesn't remove the block data - because then it would not be able to serve blocks to clients that are fresh and need to download the chain.

Why the first 50 addresses with non-default port number are considered same as invalid?
To be honest, I have no idea. Just like I have no idea about a purpose of many things this s/w does, also spotted BTW.
But my personal experience advises me to not ask these kind of questions, because they don't like it.
It's a feature, not an issue - that's all you need to know.
The bitcoin elite is an actual elite, so if they made an effort to add a line of code - who are we to question it?

not a client per se, but I believe they have their own block parser and additional databases to trace all this info.

my gocoin client supports checking balance of any address, but it isn't anyhow compatible with bitcoind.
and even then, it takes like at least a second to browse through all the unspent outputs (assuming that you have them all in memory already).

OK - I know already.

Maybe indeed I should not had said that it did not work with other port numbers than 8333, since it's not entirely true.

But I was right that it was not an issue - it's obviously a feature:

Even if it was an issue for someone, he does not need to change the source code to solve it - not at all.
He only needs to convince everyone else to setup a non-default TCP port in their clients - and then he should finally get some incoming satoshi connections...

Because of its architecture.

Especially with a banscore of 90

As I said, I will re-check it and let you know again.

Hmm.. OK, sorry - let me retest then.. last time I checked it wasn't working.
Are you sure that these are connections from an actual satoshi nodes?
They shouldn't connect twice, you know...

If you encrypt your wallet in a secured environment, it should be safe to use in for reading balances in bitcoind run on a less secured server.
But sooner or later you will run into problems when your address pool goes down - unless you will be updating regularly, each time you need new addresses.

If you don't want to use 3rd party s/w, I think you could try to run bitcoind at a secured system of your choice (i.e. your home PC) and setup the web app to connect to it, using ssh tunneling or something like that. Then at least you know that nobody from the data center has an access to your wallet file.

No wonder that there was a lack of listening peers, since the satoshi client version 2013 still does not work with any TCP port except 8333.
It wont even connect to a different port, despite of the port number being an actual part of the protocol's addr structure - I guess it's to make the competition look equally bad

If you have a huge network behind NAT, only one PC is entitled to run a listening node, no matter how good you are in configuring your router, or how big was the upnp lib that you have liked it with.
Moreover, if you want to stop someone from using bitcoin, all you need to do is to block TCP port 8333 on your firewall and he won't be able to circumvent such a blockade, otherwise than by using Tor or VPN, which will be either slow or expensive.

But don't mind me - I'm always complaining about not an issues