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. |
|
|
|
Parsed in the transaction and it reads as below. The second input has wrong length for the first push therefore it takes up the first byte from the pub key. This will not validate in Satoshi and not in bitsofproof. {
"hash":"6b3a189c0e2ea87ceb878eb1efbc367d5338498a7c92f29e7afa26558524afcf",
"version":1,
"inputs":[
{
"sourceHash":"9f193e844622e4320521536945de6f52d1eb28caf3b8c714f280b94fe0f59b97",
"sourceIx":47,
"script":"304502210081eaa77b0dcef66c0d0e62dafe932503cd8ab8bd83e4d132c9b42fd5a5be904202204a281c9c320f60b4a11bd7f162d8296d8246a13a43bc9e5e6fe831e8587bd8d901 04c55f8edc724bc89b356bc1280f720b27e62839743e549d51bd9d537bd168b3b36f655b87f5aa492c15eec23120f87abe36693830608a0f91b325a4f76570daf1",
"sequence":4294967295
},
{
"sourceHash":"5fd4546883a5fcf7baf04051b911bd7264a9dd1f8ea431481f53b5347364d3b1",
"sourceIx":47,
"script":"304502210081eaa77b0dcef66c0d0e62dafe932503cd8ab8bd83e4d132c9b42fd5a5be904202204a281c9c320f60b4a11bd7f162d8296d8246a13a43bc9e5e6fe831e8587bd8d90104 c55f8edc724bc89b356bc1280f720b27e62839743e549d51bd9d537bd168b3b36f655b87f5aa492c15eec23120f87abe36693830608a0f91b325a4f76570daf1",
"sequence":4294967295
}
],
"outputs":[
{
"value":7370765,
"script":"OP_DUP OP_HASH160 fe9c3e50dd8a5263571764dfa9e80300d15f6121 OP_EQUALVERIFY OP_CHECKSIG"
}
],
"lockTime":0
}
|
|
|
|
regarding demurrage: miner could impose floor to transaction fee based on coin age. No code change needed for that just, their majority will to do so.
You could do this, but it is hard to get 51% to join a cartel. That applies to using a vhanged code too. |
|
|
|
A byproduct of your scrutiny is that I found that the scope of synchronization around the signature validation was wider than necessary, reduced it: https://github.com/bitsofproof/supernode/commit/b750ef94a7f00756fd4fa2afe9a532caa4cf76e0and it gives a real boost on my server. well, thats why i provided you with a clean equals + hashCode method for your pleasure This is nice, would you mind submitting a pull since copy from pastebin failed to patch for me? Thanks a lot to all of you, this is exactly the feedback I expected and opened the source for ! |
|
|
|
Ok, actually went and found the code in question. Yes it does appear that the hash is the same because it is generated from the tx to sign, not the full tx. So no the attack will not work as described, but it does seem that one could get it to accept an invalid transaction such that the first signature in the transaction was correct but a later input with the same key could have an invalid signature like the one described in the original post and still get accepted due to the cache.
The point is that signature is correct, if it is correct for the hash and public key combination. This is not violated by the code. If the hash would not contain information needed, then this would be a design problem for the bitcoin protocol itself, since the bitsofproof supernode implements that correctly (otherwise it would not validate the entire chain and testnet3). Let us think about this longer... |
|
|
|
IMHO, No.
The only difference between TxA and TxB is the signature and the public key, and both are removed before the hash is calculated.
So there is no change in value, that I assumed. Then hash is same. Still does not work, since the signature cache is only valid for the transaction in question, thereafter evicted, since there is no chance other transactions produce the same hash. The cache is only an optimization for several inputs using same key. The cache is transaction scope also since I do parallel validation of transactions of a block on a number of threads. |
|
|
|
is there any particular reason why you use edu.emory.mathcs.backport.java.util.Arrays ? the one from java.util works just fine imo.
That must have been a false auto import by eclipse. Thanks for pointing out, I delete it. |
|
|
|
Yes, but the value part of the TxOut structure would be different isn't it ? That is part of the hash. |
|
|
|
Regarding the attack: I think the attack would not work since the hash part of the key would be different with other than 0 out value. Nevertheless the point is fair, separators would be appropriate here to cast any doubt. I suggest to raise these issues on the github link below, so I can refer them in code/version as resolved. i would have proposed standard java object oriented notation. create a value object (all final values) of the key, provide efficient equal/hashcode implementations, build a Cache from that. that way the impl. is both correct and the fastest possible.
Object key would not work since the byte arrays are instantiated from the script, their content matches, not their identity. |
|
|
|
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 |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. 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. |
|
|
|
|
regarding demurrage: miner could impose floor to transaction fee based on coin age. No code change needed for that just, their majority will to do so.
|
|
|
|
This one is also neat: 00000000000addd111114dd2a982305a821a532ff77ddf658b9c468ef008033e its a vanity block |
|
|
|
I am looking for a tool that can read the blockchain and: - Runs on my own server using the blockchain/p2p network for input
- Quickly return the balance for any address
- Quickly send a payment from any private key
Your use case might be a fit for the modular server implementation you see in my footer. Lets discuss what you need, so I create support for. BTW: Running the bitsofproof server gives you a normalized relational dstabase of the blockchain, sobalances can be queried via SQL. I also consider to add pruned view of unspent output. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
|
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.
|
|
|
|
|
Show Posts
