Topic: ANN: Announcing code availability of the bitsofproof supernode - page 13. (Read 35169 times)
November 12, 2012, 03:29:57 PM
Is there plans to support BIP 23 Block Proposal? I could probably run a node on Eligius verifying its templates against bitsofproof with this
November 12, 2012, 03:27:38 PM
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.
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.
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.
November 12, 2012, 02:53:47 PM
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.
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.
November 06, 2012, 04:39:02 PM
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.
November 04, 2012, 12:24:25 PM
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. November 03, 2012, 10:16:38 PM
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:
Best regards, Sergio.
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.
November 02, 2012, 01:36:43 PM
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.
November 02, 2012, 01:16:48 PM
Does it run on the testnet blockchain?
November 02, 2012, 01:12:17 PM
Thanks a lot Sergio!
I released the code also to harden it through feedback.
There is lot to be done and there are surely quite few bugs in a new implementation. I hope people like you deem it promising enough to invest time into.
I released the code also to harden it through feedback.
There is lot to be done and there are surely quite few bugs in a new implementation. I hope people like you deem it promising enough to invest time into.
November 02, 2012, 12:40:50 PM
Congratulations Grau!
Please note that all DoS protections that the Shatoshi client has still haven't been implemented in bitsofproof supernode.
They are needed before putting nodes live on the p2p net.
I will review its security regarding DoS soon.
Please note that all DoS protections that the Shatoshi client has still haven't been implemented in bitsofproof supernode.
They are needed before putting nodes live on the p2p net.
I will review its security regarding DoS soon.
November 02, 2012, 11:28:22 AM
caveden, there have been several other full reimplementations. BitcoinJS is one, I think UfaSoft made one, and actually I just finished merging code from Matt that makes bitcoinj a fully verifying ultra-prune style implementation as well (of course, it can still run in SPV mode too).
I'm aware about the efforts to make BitcoinJ a full node, what I find quite good. I don't know about "UfaSoft", and didn't know BitcoinJS was a full node implementation either, I thought it depended on a bitcoind running on the server. Nice to know all this.
pynode is also a full node implementation (sans wallet!). It fully verifies mainnet and testnet3 chains, passing all available applicable conformance tests.
It's good to see another implementation though.
November 02, 2012, 11:21:41 AM
I believe that wallet metadata like balances need to be updated during re-orgs as well as any time an incoming transaction is received that affects this information...
With the normalized block database you can derive balances up-to the last node using sql even in an other process. Even build materialized views to cache if you have the database support for that.The client serving bean (once there will be one) could then only care to listen to recent transactions and query the balance after block update (and evtl. reorg) from the database, that maintains transactional consistency etc...
Key store is a matter of taste and paranoia. I hope people contribute different flavors.
November 02, 2012, 11:05:40 AM
Bear in mind that wallets need to be updated during re-orgs, so you need integration between the block chain handling code and the wallet code. Also if you want to implement optimizations like getheaders the peer to peer code, the block chain and the wallet all need to work together to achieve that.
It's easy to say "make it a loosely coupled module" but harder to actually do, assuming you want features.
It's easy to say "make it a loosely coupled module" but harder to actually do, assuming you want features.
I believe that wallet metadata like balances need to be updated during re-orgs as well as any time an incoming transaction is received that affects this information... but I believe that the base case of a wallet is a simple collection of addresses and private keys.
All of those features belong in "derived classes" (or equivalent functionality) that can safely implement those by listening to a stream of incoming events.
November 02, 2012, 10:40:35 AM
Bear in mind that wallets need to be updated during re-orgs, so you need integration between the block chain handling code and the wallet code. Also if you want to implement optimizations like getheaders the peer to peer code, the block chain and the wallet all need to work together to achieve that.
It's easy to say "make it a loosely coupled module" but harder to actually do, assuming you want features.
It's easy to say "make it a loosely coupled module" but harder to actually do, assuming you want features.
November 02, 2012, 10:03:42 AM
... Isn't this good?
Of course, this is awesome. In no way I meant otherwise!
LIMITATIONS
...and does not feature a wallet.
...and does not feature a wallet.
This is an excellent limitation to have, and it should stay this way.
It should have support for communicating with a wallet module or wallet service, but I think having an integrated wallet is a bad design decision that leads to more bad design with all kinds of horrible implications.
I tend to agree with this feeling. Managing a Bitcoin wallet and managing the Bitcoin p2p protocol are two different tasks, there's no need for them to be strongly coupled.
November 02, 2012, 09:49:07 AM
LIMITATIONS
...and does not feature a wallet.
...and does not feature a wallet.
This is an excellent limitation to have, and it should stay this way.
It should have support for communicating with a wallet module or wallet service, but I think having an integrated wallet is a bad design decision that causes all kinds of horrible consequences. (How often do you open a high-value document in Microsoft Word and be treated to a blinking cursor on a blank document as though you did "file - new"..., freak out, call for tech support, and be told "oh yeah, you are doing it wrong, you have to drop to the command line and type winword.exe -rescan")
+1
November 02, 2012, 09:47:39 AM
Nice.
While not a 'must-have-now' feature having a pluggable persistence layer/db is a nice option.
November 02, 2012, 09:43:57 AM
LIMITATIONS
...and does not feature a wallet.
...and does not feature a wallet.
This is an excellent limitation to have, and it should stay this way.
It should have support for communicating with a wallet module or wallet service, but I think having an integrated wallet is a bad design decision that leads to more bad design with all kinds of horrible implications. (How often do you open a high-value document in Microsoft Word and be treated to a blinking cursor on a blank document as though you did "file - new"..., freak out, call for tech support, and be told "oh yeah, you are doing it wrong, you have to drop to the command line and type winword.exe -rescan")
November 02, 2012, 09:39:45 AM
By the way, OP, why not reuse BitcoinJ code if it fits?
Because it does not. It was also an exercise of real understanding the protocol and uncovering its ambiguities.
The code I wrote is probably the easiest readable but precise existing documentation of
what is really going on under the hood, and I am sharing it with you. Isn't this good?
Wow, I'm really impressed! 
I haven't tested it yet, but if it works, this could become a really important alternative to the satoshi client.
There will be an out-of-the-box executable jar sometime down the road for demonstration purposes,I haven't tested it yet, but if it works, this could become a really important alternative to the satoshi client.
but the audience for this is not the end user but the tech savvy implementing new enterprises.
November 02, 2012, 09:25:41 AM
By the way, OP, why not reuse BitcoinJ code if it fits?
Because it does not. Ok then. I thought that you had done it on purpose, as if sharing code was something bad.
caveden, there have been several other full reimplementations. BitcoinJS is one, I think UfaSoft made one, and actually I just finished merging code from Matt that makes bitcoinj a fully verifying ultra-prune style implementation as well (of course, it can still run in SPV mode too).
I'm aware about the efforts to make BitcoinJ a full node, what I find quite good. I don't know about "UfaSoft", and didn't know BitcoinJS was a full node implementation either, I thought it depended on a bitcoind running on the server. Nice to know all this.
I'm glad to see Bitcoin evolving so fast.
Jump to: