are you honestly adding more info.. or just trying to point out that your "pynode" is *so* ahead ??

I do not yet see how the signature cache actually helps, would you please elaborate?

A signature is a function of the hash of a modified version of the input transaction. The modification depends on which output of that transaction is to be spent. Aren't chances of seeing the same signature twice negligible?

If miners are already shrinking their blocks due to propagation time, maybe it's time to consider that protocol improvement suggestion in the scalability page, about not sending the entire block every time, just the portion your peer doesn't have.

I don't know what exactly could be send instead of the body, though. Even if my peer has all transactions in his cache, doesn't he need to know the exact order I put them in my block in order to rebuild the Merkle tree? So just sending the header is not enough. Is there a shorter way to identify a transaction than its hash? Perhaps just an ordinal of the hash... you assume your peer has the same transaction pool you had, then as the body of your block you send a series of numbers which represent the index a tx hash would have in a  sorted array with all of them? Not sure that would work frequently... plus, the hash is probably small enough, it shouldn't be a big deal to send all of them.

I think offering sufficient fee in the transaction is the incentive that will keep working as the network grows, since CPU spent for validation does not come for free.

Now you have the option to use LevelDB or any relational database, just by configuration.

Use the relational store if you are after data mining and ad-hoc queries and have more time.
Use LevelDB if you want raw power.

The bitsofproof supernode validates the chain with LevelDB at a speed only constrained by CPU.
EDIT: And I mean all processors you have

Nice proof of modularity isn't?

I am working to enable higher order search functions (via API) to LevelDB.

Whats the current timeframe for enforcing all of the script rules so that mining on this code isn't a forking risk? (if there is one?)

For caching, you may consider the open source "ehcache"
Which can be used with a disk backing store or in memory, complete with aging out to disk or removal.


HC

I am ready to take the challenge.

How would you rate the current coverage of rules after your review (100% being complete)?

May I have a pointer if the omission you found is in script, message format, protocol, block-chaining (reorg), caching or any other more specific area?

I made this open source for mutual benefit, that is the community gets my work for I get constructive feedback and not just hints on potential issues after a quick look.

Are you sure there is a bug?

I'm pretty sure there is a bug, yes. If I'm wrong then I will of course apologise and go back to update my previous post.

The point of being vague is that us finding bugs on random code reviews isn't reliable or scalable. With your new codebase you're not solving a problem any of the current core developers have, so there isn't much incentive for us to go finding bugs for you. But if people were to use or mine upon a new implementation with bugs, that would definitely cause problems.

So what's important to demonstrate is that your code can be used without presenting a danger to the network, and that means really solid processes and testing to ensure the behavior matches exactly. If we can find one or two issues, there could well be more, so a rigorous testing and protocol compliance regime is the only way to build confidence.