[ANN] libcoin rebase attempt

[indolering]

I added a hook that gets called whenever the best chain's head changes, and using boost::condition_variable's waiting threads can get notified about this to process the change. I also implemented "asynchronous" RPC routines that spawn a new thread for their processing, so that they can block until the hook triggers and don't halt the whole RPC server (other RPC calls are possible in the mean time and also an arbitrary number of such waiting calls can co-exist).

I was planning on creating SQLite triggers, that sounded easier. However, this is much better, I <3 REST. I'm guessing you just pass a URI as part of the original call?

See my pull request at https://github.com/chronokings/huntercoin/pull/11. I also believe this could be a useful addition for Namecoin and Bitcoin in general, particularly for things like your CouchDB application or front-ends in general.

Seriously: scraping is a shitty hack that breaks easily and takes forever to get just right, esp. with JS. Bitcoin internally might not need more than very basic key->value store, but all of the applications have a need for it.

I poked around in the code and I saw references to LevelDB, is it using both SQLite and LevelDB? The reason I mentioned Pouch was because they maintain indexes on top of LevelDB and the PouchDB people thought it would be a fairly straight-forward port if I wanted to use it as LevelDB abstraction layer. However, there seems to be plenty of generic abstractions being created for LevelDB....

[domob]

I added a hook that gets called whenever the best chain's head changes, and using boost::condition_variable's waiting threads can get notified about this to process the change. I also implemented "asynchronous" RPC routines that spawn a new thread for their processing, so that they can block until the hook triggers and don't halt the whole RPC server (other RPC calls are possible in the mean time and also an arbitrary number of such waiting calls can co-exist).

I was planning on creating SQLite triggers, that sounded easier. However, this is much better, I <3 REST. I'm guessing you just pass a URI as part of the original call?

Not sure what you mean here. You perform a JSON-RPC method call to the server, and the call blocks until the game state changes and only then returns a result (the new game state). I've never played around with REST.

See my pull request at https://github.com/chronokings/huntercoin/pull/11. I also believe this could be a useful addition for Namecoin and Bitcoin in general, particularly for things like your CouchDB application or front-ends in general.

Seriously: scraping is a shitty hack that breaks easily and takes forever to get just right, esp. with JS. Bitcoin internally might not need more than very basic key->value store, but all of the applications have a need for it.

I poked around in the code and I saw references to LevelDB, is it using both SQLite and LevelDB? The reason I mentioned Pouch was because they maintain indexes on top of LevelDB and the PouchDB people thought it would be a fairly straight-forward port if I wanted to use it as LevelDB abstraction layer. However, there seems to be plenty of generic abstractions being created for LevelDB....

I'm not sure here. I definitely know that libcoin uses SQLite3 for its blockchain and also the name database, and I believe it uses Berkeley DB for the wallet (as does Bitcoin), although it seems to be planned to implement a new wallet based also on SQLite3. LevelDB is used in the "newer" Bitcoin code, but I'm not sure if libcoin also uses it (since it has its own blockchain storage, AFAIK).

With respect to Huntercoin/Namecoin, it only uses Berkeley DB as old Bitcoin versions did (at least I think so).

[virtual_master]

I appreciate very much your work on the rebase.
Unfortunately I cannot say very much helpful about this but I will test it when it is so far.

[khal]

Fix testnet POW ChainID check :
https://github.com/khalahan/libcoin/com ... ointestnet

Blocks after 22726 are now accepted.
I'm still download the remaining blockchain (on block 27500 for now).

[khal]

Full blocks (34714) are now downloaded !

Next steps are to test all this, mining included, which requires adding the testnet difficulty adjustment (I didn't see it in the bitcoin testnet code, strange).

Edit: code is there : https://github.com/khalahan/libcoin/com ... ointestnet

[biolizard89]

Full blocks (34714) are now downloaded !

Next steps are to test all this, mining included, which requires adding the testnet difficulty adjustment (I didn't see it in the bitcoin testnet code, strange).

Nice work, this is good progress.

[tosh0]

is multisig implemented or up to what btc version is this updated?

[indolering]

Any updates on this? Domob's repo was updated ~3 weeks ago.

Are any of the the name_* commands implemented yet? Searching for "name" in the repo doesn't turn up anything.

Is it possible to connect to the SQLite database directly? (I'm assuming it tracks names there?)

I'm going to guess that libcoin doesn't track names at the moment?

[domob]

Any updates on this? Domob's repo was updated ~3 weeks ago.

Are any of the the name_* commands implemented yet? Searching for "name" in the repo doesn't turn up anything.

I've been waiting on some answers from Michael, but now I have them and should hopefully finish off name_show soon. Note that the latest changes were mostly done in my Github fork of libcoin rather than the repository in the OP, since they need to modify libcoin internals. Thus you should look there for news. (There also "name" should show up already, as name_show already works for retrieving name/value/expires_in/expired. txid/address will be implemented now, and then I'll do name_history.)

Is it possible to connect to the SQLite database directly? (I'm assuming it tracks names there?)

I'm going to guess that libcoin doesn't track names at the moment?

It does, and yes, they are stored in the database. This is basically what my name_show does / will do, together with parsing the tx out scripts to retrieve addresses and other such things.

[phelix]

sounds good