ANN: Announcing code availability of the bitsofproof supernode

[grau]

Does it run on the testnet blockchain?

Only the bare minimum of testing is done until now, using the entire production chain and a few test cases.

It would be irresponsible to ship it with an installer ready to use by an end user, this is why I do not package,
but it is good enough convince developer to commit time to improve.

I promise to focus on testing and hardening from now on and as I said in a private e-mail will add some sort of peer testing feature.

[1715433054]

1715433054

[1715433054]

1715433054

[Sergio_Demian_Lerner]

Grau, I've updated the https://en.bitcoin.it/wiki/Weaknesses wiki to reflect current Satoshi client protections against DoS.

Be sure you include at least the most important ones in bitsofproof supernode before it goes to production.

These are the current Bitcoin Satoshi client protections to deter DoS attacks, as of version 0.7.0:

•    Does not forward orphan transactions/blocks
•    Does not forward double-spend transactions
•    Restrict the maximum number of signature checks a transaction input may request
•    Continuous rate-limit of free transactions to mitigate 'penny-flooding'
•    Keeping a DoS score of each connected peer and disconnects from a peer that send messages that fail to comply with the rules.
•    Permanently ban IP addresses that misbehave for a time lapse (24 hours default)
•    Limit the number of stored orphan transactions (10000 by default)
•     Use a signature cache to prevent attacks that try to continuously trigger the re-verification of stored orphan transactions
•    Limit the number of stored signature in the signature cache (50000 signatures by default)
•    Tries to catch errors in transactions before the time consuming signature verifications.
•    Penalize peers that send us lots of duplicate/expired/invalid-signature/whatever alerts, so they eventually get banned.
•    In orphan/signature caches: when removing an item, evict a random entry.
•    Data structures are specially chosen to avoid loops in which the number of iterations can be controller by an attacker that result in exponential complexity.
•    Ignore big orphan transactions, to avoid a send-big-orphans memory exhaustion attack.
•    In RPC: Only send a HTTP 403 response if it's not using SSL to prevent a DoS during the SSL handshake.
•    In RPC: Sleep some time if authorization fails to deter brute-forcing short passwords.
•    In GUI: Limit URI length to prevent a DoS against the QR-Code dialog

Best regards, Sergio.

[grau]

Be sure you include at least the most important ones in bitsofproof supernode before it goes to production.

Thanks Sergio, I will definitely verify against the list.

Does it run on the testnet blockchain?

Testing against testnet3 is in good progress.

[grau]

Does it run on the testnet blockchain?

I proudly announce that the bitsofproof supernode just validated all testnet3 transactions.

That means it now supports all sorts of sigs and scripts.

For those skeptical of the normalized database: The node running on my laptop validated and stored the 6200+ transactions block on the test chain within a few minutes. My server reloads the entire production chain in a couple of hours.

[Sergio_Demian_Lerner]

Minor (unconfirmed) DoS Security vulnerability: the "unconfirmed" table is implemented over a HashMap whose key is the hash of the transaction (as a string).

I'm unsure reading your code if the attacker can submit two unconfirmed transactions that spend the same inputs, but in that case it would be easy for an attacker to flood the unconfirmed HashMap with entries that map to the same hash bucket, degenerating to linear access complexity.

It would be better to switch to a TreeMap data structure.

[grau]

Hello Sergio,

great to see that you took a closer look.

I think that attack however would not work, as the attacker would have to create several otherwise valid spends with different hashes, since transaction validity is checked (and throws ValidationException exception if not) before caching the transaction.

Code:

			public Boolean doInTransaction (TransactionStatus status)
			{
				status.setRollbackOnly ();
				try
				{
					store.validateTransaction (txm.getTx ());
					cacheTransaction (txm.getTx ());
					return true;
				}
				catch ( ValidationException e )
				{
					log.trace ("Rejeting transaction " + txm.getTx ().getHash () + " from " + peer.getAddress (), e);
				}
				return false;
			}

I am currently working on BCCAPI implementation (at about 90%), thereafter I would want to go through systematically with a DoS hat on taking your criteria list.

Let me know if you would want to do a walk through via e.g. Skype.

[Luke-Jr]

Is there plans to support BIP 23 Block Proposal? I could probably run a node on Eligius verifying its templates against bitsofproof with this

[apetersson]

looks like an interesting piece of work and so far the code looks very clean.

i somehow agree that implementing a wallet internally does not make a lot of sense.

my question is, since this is called a "supernode" are there plans to run such a node on a clustered environment, such as with Akka?

[grau]

Is there plans to support BIP 23 Block Proposal? I could probably run a node on Eligius verifying its templates against bitsofproof with this

Yes, I build this for the server, for enterprises and miner. Bribe or inspire me and you'll get BIP 23.

[Luke-Jr]

Is there plans to support BIP 23 Block Proposal? I could probably run a node on Eligius verifying its templates against bitsofproof with this

Yes, I build this for the server, for enterprises and miner. Bribe or inspire me and you'll get BIP 23.

Not enough "bribe" to get more real-world mining testing? Proposals wouldn't be for Eligius's benefit, but for your own: your code will be tested for checking numerous possible blocks every day, and any failures will be reported to you for analysis/bugfixing. After it's proven to be reasonably reliable, I'd even make Eligius refuse to produce blocks your code rejects as a security measure - this way someone can't get Eligius to mine a block attacking bitsofproof users

[grau]

looks like an interesting piece of work and so far the code looks very clean.

i somehow agree that implementing a wallet internally does not make a lot of sense.

my question is, since this is called a "supernode" are there plans to run such a node on a clustered environment, such as with Akka?

Thanks, I believe code that deals with money should be clean. It helps, that I am writing code for trading since decades.

I call it supernode since it is for the big server of near future, not for the kids, not for the mobiles. If we want the world, we need server that digests hundreds of transactions per second and deals with terabytes. To get there we need modularity and yes at some point clusters.

[grau]

Not enough "bribe" to get more real-world mining testing? Proposals wouldn't be for Eligius's benefit, but for your own: your code will be tested for checking numerous possible blocks every day, and any failures will be reported to you for analysis/bugfixing. After it's proven to be reasonably reliable, I'd even make Eligius refuse to produce blocks your code rejects as a security measure - this way someone can't get Eligius to mine a block attacking bitsofproof users

What you attempt is inspiration and are doing a good job. Let me read the proposal, in the meanwhile you think a bit longer about bribing

[grau]

Is there plans to support BIP 23 Block Proposal? I could probably run a node on Eligius verifying its templates against bitsofproof with this

Yes, I build this for the server, for enterprises and miner. Bribe or inspire me and you'll get BIP 23.

Not enough "bribe" to get more real-world mining testing? Proposals wouldn't be for Eligius's benefit, but for your own: your code will be tested for checking numerous possible blocks every day, and any failures will be reported to you for analysis/bugfixing. After it's proven to be reasonably reliable, I'd even make Eligius refuse to produce blocks your code rejects as a security measure - this way someone can't get Eligius to mine a block attacking bitsofproof users

Mining (just for fun and precise understanding), and BIP23 his is next on my list.

[xblitz]

great work grau! I like the way you code, and your attitude!  keep it up

[grau]

great work grau! I like the way you code, and your attitude!  keep it up

thanks! That's too much to handle

I invest most of my free time into this since months; comments like yours help to keep going.
It would however be canting not to admit that I do eye a profit at the end.

[Mike Hearn]

How do you plan to make a profit? Consulting?

[grau]

Consulting is an option.
I also have end user facing ideas I will build on this fundation.

[grau]

BCCAPI support is now implemented, that is an interface to lightweight clients (originally invented for BitcoinSpinner)

BCCAPI makes it easy to retrieve balances or account history for a public key. Create and send transactions whereby the server does not store private key.

The implementation is not tested enough for production use, but works for unit tests, so developer might want to look at it.

[grau]

New feature of the day: Collects and stores and uses peer statistics (version, agent, traffic, response time, ban reason... ) in the database.

[grau]

New feature of the day: Implemented pruning of the chain to unspent output.

The pruning is on a logical level, add option -p <hash> to the startup and it will calculate and store the unspent txout upto that hash into a separate snapshot table.

The resolution of inputs uses the most resent snapshot plus what comes thereafter. You can delete the snapshots also, the since full data remains, it keeps working...