Topic: btcd: a bitcoind alternative written in Go - page 6. (Read 20982 times)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is awesome. Keep up the great work!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQIcBAEBAgAGBQJR647tAAoJENpjtAbv5/sY080P/2wJbztJ5iLHQujloFiH4vZh
dLV3lJ8mU8xZXhJ7qfUL59LdRD7Id3O91hyn6WpkKaWsUXHRl7P1/ZAnXkkMrHIP
EZgIKeybxGgHxEV/lfIj5vlw3hBEOMcBjCGzWDA5budnbAYmUJoSFDNQQSgiHjVc
QMwPK9viaUbv35gtPrYbpuuPzSPxX+cvxcly8xwehqx5Uu994WmPmXBJj9sJvCM8
EWi3jtTR6o527hwJECaYHuGMvUsP7DbDMT6OyzD1xgWvr8XcR3qrOfl4wSnJx5PU
4jMlCF4v56P4DLtVyHiki7Zr2fpnChYh/rxYMlCoDi3K9bzTidNkrm7Xd4GZ/W5X
q/LsyupEVFeFwDdIlyyekV8HYDtc3IRLC8HjlEwc2zwjT3jKRGPZeoXVDLAZ4KQN
o8hjDaEdIT5qtRL2VXalbfpauaStj+GZL5vdhf6zshX0ZyQOHh4H58OuUN3OLFqh
CdJUtL3YU+DHQSrX5m8H2bgK6Hy/8waTLRsVfoMTF8jewjZRl+F4HH/UfMJTp5Qa
ZaSCrrmYidjj94e1Ww0/bYkYFUUneUrq7vdHQi6NwoTA86BS8C5PFpIkVTb+BzSo
O5PF7RY9N7ybvw/oyzzSJBygvhYgAsRqg3AWMem+sEPA0Vcrhj2N9hVbu8+Vz4Ma
vsUR5/PoKcO2Qql+WU9/
=+tO/
-----END PGP SIGNATURE-----

We've just released the chain selection/block handling code from btcd.

Here is the link to btcchain:

https://blog.conformal.com/btcchain-the-bitcoin-chain-package-from-bctd/

The plan is for btcd itself to come out next.  Just like before, any comments or questions on the code or documentation are always welcome.

We've tried very hard to match the rules as implemented by bitcoind exactly, but as this is very important, we'd appreciate any reviews or comments on the code.

Enjoy.

Awesome clean, documented code.

Keep up the awesome work!

Just to update folks on this, we've released our next component, btcscript, the script package for btcd:

https://blog.conformal.com/btcscript-the-script-package-from-btcd/

As always, comments, idea, and complaints are always welcome.

If you mean a full release of btcd, I can't really say (that's more behindtext's place).

But, we do have two functioning packages on github (btcwire and btcjson) which you might want to checkout.  Hopefully those can help you get started on something in Go a bit faster.  We've really tried to be good with both documenting and adding tests to both of them (of course any comments or bugs you have with them are very welcome).  There is also a third component that will be out soon.

How long will it take for a functional release?

I myself am learning go and this will go a long way helping me. Thanks!

We are actually putting things in an sqlite database, but we've been evaluating all sorts of other things, including leveldb.  The ideal case of course would be a native go implementation of something so we wouldn't need cgo, but we haven't had much luck finding something like that (although I have not done any of the database work, so I can't say what problems we've seen or what missing features any of the other packages had).

"Package" is the word I meant, not "Port".  Sorry about that.

Hang on - why are you trying to put the blockchain in a leveldb database?

What do you mean by port? Aren't the bindings sufficient?

https://github.com/jmhodges/levigo#readme

The README makes that sound reasonably complete.

"Port" to me implies "rewrite". Why would anyone do that?

Yep, I know exactly what you mean

And it's even more disappointing when you know that both; Go and LevelDB are products developed by Google.

We've definitely looked at LevelDB and seem to alternate between being excited about it and disappointed that the Go ports aren't done enough yet.  Those will be pretty interesting once they get a little more mature though.

That's fair enough - thanks for explaining.

I wish you all the best with the project guys, though if you do not have tx verification fully implemented yet, I think your dates might be a bit too optimistic.
Also, from my own experience, I think sqlite might not be the best choice, as for a DB backend for bitcoin. I would rather advise you to look into Go ports of LevelDB. Unfortunately none of them is quite finished yet.
Myself, I was trying everything; from mysql to each available port of leveldb - but at the end I decided that they all suck and created my own database engine.
You're welcome to use it, if you want, though I should warn you that it has about 0% of test coverage, and a great appetite for system memory. You can order it to free the mem, but then it will be much slower when you need the data. And that's why I recently bought 8 more gigs of RAM, just so I would not need to free the mem... at least for the next couple of months

Just to build on behindtext's answer, by releasing btcd in pieces, we can get the code out there much faster as parts that are more mature don't have to wait for other parts to come out.

Doing it this way also forces us to keep the code in distinct, reusable pieces rather than us building one monolithic thing, which we think will help the overall quality.  And it means that if someone else had a project where they want some of the code, they only have to understand the component that they need and not worry about the others at all since they are all separate Go packages.

Congrats and also, best of luck with taking btcd to the finish line.

we chose not to release all the code at once because it was put together rather quickly. one of the main goals with btcd is to have easy-to-understand code along with full test coverage. having full test coverage runs directly in the face of the "making it work", so we made it work first, and are now polishing the individual pieces and releasing them. i'm not sure if you have checked out the test coverage on btcwire but it exercises every single line of code in the package in the tests. this includes negative testing in order to give all the code a run-through. the btcjson package is similar in quality: 88% of the code has test coverage and that should improve to 100% in the next several days.

per my earlier posts in this thread, btcd is up and running against a single local bitcoind node. it can pull the whole blockchain down but you may have noticed that it cannot handle chain forking properly yet. we expect this to be working well and release it soon. full tx verification is under development, a number of experiments are being done to determine how to make it run faster. since these experiments involve changing (sqlite) db schema, it doesn't make sense to release in such a half-baked form, especially when it means users would have to rebuild/restructure their whole db.

we expect to have btcd interoperating nicely with bitcoind before June 1st. note that this will not include wallet functionality, we expect that to be ready before July 1st and likely before June 15th. since you're a developer yourself you know how timelines can slip, so be aware these are estimates.

May I ask, why don't you just release the whole client at once?
Do you have it already and testing - or not yet finished, but you think it will be finished soon?

Unless it's not 'ask a question' type of topic, in which case: sorry, it will probably pop up my ignore digit

Welcome to the club!

Having a choice of implementations unlocks innovation and will benefit all of us. Good Luck.

I cant wait to reveal you all features of the BOP Enterprise Bitcoin Server (formerly known as the bits of proof supernode)
and related offers of my company at the conference.

We've just released the second btcd component, btcjson, the JSON-RPC library.

Here is the blog post about it.

https://blog.conformal.com/btcjson-the-bitcoin-json-rpc-package-from-btcd/

Or if you want the code directly, it is on github:

https://github.com/conformal/btcjson

thank you, jeff. appreciate your hard work! :-) and the hard work of the other Bitcoin developers too, of course.