Re: [Bitcoin-development] LevelDB benchmarking

2012-06-19 Thread Stefan Thomas
Here are my 2 cents after using LevelDB as the default backend for BitcoinJS for about a year. LevelDB was written to power IndexedDB in Chrome which is a JavaScript API. That means that LevelDB doesn't really give you a lot of options, because they assume that on the C++ layer you don't know any

Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients

2012-06-19 Thread Matt Corallo
On Sat, 2012-06-16 at 10:27 +0200, Mike Hearn wrote: > > I'd much rather have an overloaded node respond with 50% fp rate filters > > as an option if there aren't many full nodes available than simply > > disconnect SPV clients. > > I don't think the bloom filter settings have any impact on server

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

2012-06-19 Thread Alan Reiner
On 06/19/2012 02:18 PM, Mark Friedenbach wrote: On Tue, Jun 19, 2012 at 10:33 AM, Alan Reiner > wrote: If we were to use a raw trie structure, then we'd have all the above issues solved: a trie has the same configuration no matter how elements are ins

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 looke

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 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 must replay the ent

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 Reiner 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 th

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 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 be a disaster to

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 ord

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] 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] 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

Re: [Bitcoin-development] LevelDB benchmarking

2012-06-19 Thread Pieter Wuille
On Tue, Jun 19, 2012 at 11:05:20AM +0200, Mike Hearn wrote: > OK, to make progress on this work I need a few decisions (Gavin?) > > 1) Shall we do it? I'm all for moving away from BDB. It's a very good system for what it is intended for, but that is not how we use it. The fact that it is tied to

Re: [Bitcoin-development] LevelDB benchmarking

2012-06-19 Thread Mike Hearn
+list On Mon, Jun 18, 2012 at 9:07 PM, Gregory Maxwell 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 being the bottlen