Re: [Bitcoin-development] LevelDB benchmarking

2012-06-19 Thread Mike Hearn
+list On Mon, Jun 18, 2012 at 9:07 PM, Gregory Maxwell gmaxw...@gmail.com wrote: In addition to the ECDSA caching,  ECDSA can can easily be run on multiple cores for basically a linear speedup.. so even with the checking in place once ECDSA was using multiple threads we'd be back to the DB

Re: [Bitcoin-development] LevelDB benchmarking

2012-06-19 Thread Gavin Andresen
OK, to make progress on this work I need a few decisions (Gavin?) 1) Shall we do it? What problem does it solve? If the problem it will solve is it will only take 4 hours to download the entire blockchain next year instead of taking 16 hours then no, I don't think we should do it, both 4 and

Re: [Bitcoin-development] LevelDB benchmarking

2012-06-19 Thread Mike Hearn
What problem does it solve? Primarily that block verification and therefore propagation is too slow because it's very CPU and IO intensive. The CPU work can be multi-threaded. The IO work, not as much. As Bitcoin grows we need to scale the nodes. Eventually there may be multi-machine nodes, but

Re: [Bitcoin-development] Ultimate Blockchain Compression w/ trust-free lite node

2012-06-19 Thread Andrew Miller
Peter Todd wrote: My solution was to simply state that vertexes that happened to cause the tree to be unbalanced would be discarded, and set the depth of inbalance such that this would be extremely unlikely to happen by accident. I'd rather see someone come up with something better though.

Re: [Bitcoin-development] Ultimate Blockchain Compression w/ trust-free lite node

2012-06-19 Thread Alan Reiner
I hope that someone else here would chime in on the issue raised in the thread, about using a tree-structure that has multiple valid configurations for the same set of unspent-TxOuts. If you use any binary tree, you must replay the entire history of insertions and deletions in the correct

Re: [Bitcoin-development] Ultimate Blockchain Compression w/ trust-free lite node

2012-06-19 Thread Gregory Maxwell
On Tue, Jun 19, 2012 at 1:33 PM, Alan Reiner etothe...@gmail.com wrote:  One app developer updates their RB tree code which updated the RB-tree optimizations/rebalancing, and now a significant portion of the network can't agree on the correct root.  Not only would that be disruptive, it would

Re: [Bitcoin-development] Ultimate Blockchain Compression w/ trust-free lite node

2012-06-19 Thread Alan Reiner
On 06/19/2012 01:59 PM, Gregory Maxwell wrote: On Tue, Jun 19, 2012 at 1:33 PM, Alan Reineretothe...@gmail.com wrote: One app developer updates their RB tree code which updated the RB-tree optimizations/rebalancing, and now a significant portion of the network can't agree on the correct

Re: [Bitcoin-development] Ultimate Blockchain Compression w/ trust-free lite node

2012-06-19 Thread Mark Friedenbach
On Tue, Jun 19, 2012 at 10:33 AM, Alan Reiner etothe...@gmail.com wrote: I hope that someone else here would chime in on the issue raised in the thread, about using a tree-structure that has multiple valid configurations for the same set of unspent-TxOuts. If you use any binary tree, you

Re: [Bitcoin-development] Ultimate Blockchain Compression w/ trust-free lite node

2012-06-19 Thread Andrew Miller
Alan Reiner wrote: A PATRICIA tree/trie would be ideal, in my mind, as it also has a completely deterministic structure, and is an order-of-magnitude more space-efficient.  Insert, delete and query times are still O(1). However, it is not a trivial implementation.  I have occasionally looked