• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

GoDash - Dev logs and discussion

> GoDash.org provides tools and libraries to interact with the Dash network using the Go language.

## Intro

While core develops the main client for Dash most developers know that the code base used by most of the core clients in crypto currencies are ridged and heavy pieces of software to run and work with. To make sure Dash can benefit from improvements in some of the other clients this is a good thing, but this leaves the people that require more lightweight and flexible solutions in the dark. That is where alternative clients and tools like those build by GoDash.org come in to play.

The main goal of GoDash.org is to provide a backend tool set to build on, the tool set aims to offer fast and simple solutions too interact with the Dash network with the freedom required by third projects projects. Think of website integration, embedded systems to build pos networks or atm machines to buy and sell Dash. None of these require a full node but need to interact with the Dash network and all have different requirements.

## Goals

At the time of writing none of the goals below are met, it is obvious that the goals will move along as the project develops and Dash changes.

#### Long Term

> Full Node: The main use case for a full node implementation would be testing, a second implementation would not only test all the other parts in the GoDash.Org tool set but it would also test the core client. Hidden bugs in one implementation might become obvious in the second implementation, besides that it means an extra group of people that looked over the core protocol and all the rules without having to understand the core client.

> SPV Node: This one is a long shot, it is useful in some cases but Evolution and the DAPI that comes along with it might change the use fullness of this. Wait and see, without Evolution or DAPI it is a useful tool to have.

> OpenBazaar: Recently OpenBazaar added Shapeshift and that is nice but it is not as if this are real dash payments or that it benefit from InstaSend. OpenBazaar is developed in Go and uses the BtcSuite to interact with the Bitcoin network, sins GoDash is based of the BtcSuite it is needless to say that this will make a Dash intro to OpenBazaar a lot easier.

#### Short Term

> Block Explorer: One of the first steps, connect to the network and download the block chain, this extends to verifying the chain using the consensus rules. On it's own this is useless so to verify that it is doing things correctly the end result should be a explorer that can be used to query the chain.

> Point of Sales: A Point of Sales system does not require the block chain but it needs to read transactions form the network and verify them so that the POS can request a confirmation for a transaction to a specific address. The same logic can be setup for for Websites, ATM systems, Vending machines and several other systems that want to verify a payment. GoDash aims to provide a lightweight server to do just that.

## History

This project is based of [btcsuite](https://github.com/btcsuite/) that was developed by [conformal](https://blog.conformal.com/) under the ISC License. With a clean rewrite of the suite the goal is to reorganize the project structure and implement more memory pooling on shared data. So is BtcSuite bad ? No it is not, in go terms it is old and that is why the rewrite makes sens. BtcSuite as a project started in 2013, Go was just hitting puberty, over the last three year a lot of the Go standards and best practices formed, it grew up. The age is visible in the code base, for the most part these are style guidelines but it also involves memory guides for the new garbage collector and in a few cases it touches on some of the new compiler optimizations.

And that is why this is a rewrite and not a fork, a clean start for a project that deserves it while targeting a coin that has the potential move.

## Donations

This project accepts donation and/or payed work. Anny income out of this project will be subtracted from the budget proposals made to the Dash network so that the network can use those funds on other projects. Feel free to contact Nitya Sattva for info and/or to donate to the address below.

GoDash.org - Donations: "Xvd4v5eGq7sQU9ZZRWkjouQKLVCjyXCsTh"

> Ref.
> [Go History](https://golang.org/doc/devel/release.html),
> [Btcd History](https://blog.conformal.com/btcd-not-your-moms-bitcoin-daemon/)
Last edited:
The x11 hash is now working in go without c bindings, these is room for performance improvements but with the initial commit I wanted to keep a balance between readability and performance.

The original code in the dash client is using the Sphlib from http://www.saphir2.com/sphlib, they include some nice tests that I ended up borrowing.

Initially I tried to go from the c template code to golang but that was a bad idea. So I ended up unrolling the c templates in c++ testing the results along the way and with golang compatibility in the back of my mind. The test results and there timings are below, Original (Sphlib) is the fastest then the c++ rewrite (Hash) that is a bit slower. the go version sits close to the original on all but cubed (need to unroll some nasty loops there).

|   Name          |    Time    |   Sate           |
| go-x11/blake    | 0.017 sec  | coverage: 100.0% |
| go-x11/bmw      | 0.014 sec  | coverage: 100.0% |
| go-x11/cubed    | 0.111 sec  | coverage: 100.0% |
| go-x11/echo     | 0.045 sec  | coverage:  93.6% |
| go-x11/groes    | 0.078 sec  | coverage: 100.0% |
| go-x11/jhash    | 0.077 sec  | coverage: 100.0% |
| go-x11/kecca    | 0.036 sec  | coverage: 100.0% |
| go-x11/luffa    | 0.021 sec  | coverage: 100.0% |
| go-x11/shavi    | 0.027 sec  | coverage:  97.9% |
| go-x11/simd     | 0.087 sec  | coverage:  99.9% |
| go-x11/skein    | 0.010 sec  | coverage: 100.0% |
| Hash::Blake     | 0.01  sec  |                  |
| Hash::Bmw       | 0.01  sec  |                  |
| Hash::Cubed     | 0.07  sec  |                  |
| Hash::Echo      | 0.04  sec  |                  |
| Hash::Groest    | 0.06  sec  |                  |
| Hash::JHash     | 0.05  sec  |                  |
| Hash::Keccak    | 0.03  sec  |                  |
| Hash::Luffa     | 0.03  sec  |                  |
| Hash::Shavite   | 0.03  sec  |                  |
| Hash::Simd      | 0.08  sec  |                  |
| Hash::Skein     | 0.01  sec  |                  |
| Sphlib::Blake   | 0.01  sec  |                  |
| Sphlib::Bmw     | 0.02  sec  |                  |
| Sphlib::Cubed   | 0.04  sec  |                  |
| Sphlib::Echo    | 0.03  sec  |                  |
| Sphlib::Groestl | 0.02  sec  |                  |
| Sphlib::Jh      | 0.03  sec  |                  |
| Sphlib::Keccak  | 0.02  sec  |                  |
| Sphlib::Luffa   | 0.03  sec  |                  |
| Sphlib::shavite | 0.02  sec  |                  |
| Sphlib::Simd    | 0.06  sec  |                  |
| Sphlib::Skein   | 0.01  sec  |                  |

* Go version perform some extra checks inside the test functions. (Need to add proper benchmarks)
* Tests that are not 100% need to hash a file that is several gigabytes large to hit all code paths, this is not feasible in a automated continuous integration test.

Finally the code can be found here:

Feedback is always welcome, my English is not the best so feel free to be a spelling nazi in the docs. (I do not care about my posts, but the docs yes plz ;))

Docs can be found here:

And then there is the dependency graph:
Last edited:
It has been a while sins I posted anything here so, but I have been busy working on a payment gateway for dash. This was far down the line in my original planning but with the "point of sale" proposal done by @kodaxx it became my main focus.

The initial prototype was simple to build, just listen for events from dashd (using zmq) and match those to addresses that the "point of sale" terminal was expecting payments on. This functionality is nothing new and is available for most coins and with dash we simply add one more check to detect "InstaSend" conformations. The added zmq events in Dash 12.1 make this very easy, trough long term I would still prefer to swap this part out with a simple spv node.

With that done, @kodaxx was able to mock up his prototype terminal and the slots game that was used as a demo in the ICE conference. This is a new field for me so it was time to look over the exiting "point of sale" options out there, not just in crypto space but also beyond that as well. There it became obvious that besides the payment processing, that was build in to the prototype, these systems hook in to a lot of other systems. On the back side of a "point of sale" there is accounting, stock management, employer tracking, store tracking, all sorts of funny things.

So not just payment processing ? Yes and no, all the server I'm building for the "point of sale" does is payment processing (verification) and like most existing payment processing tools for these systems I'm building in the option to send out events when terminals create tickets (payment requests) and update events on those tickets when they are payed, canceled, removed and so on. These events are send to "watchers" that are setup to listen for events of specific terminal so that it becomes possible to split these up based on regions, store type, ... and so on.

The question is why ? Can't the pos terminal send these events ? It can and it should but what if the terminal losses connection half way trough a payment ? The server events create redundancy, usable fallback mechanics to recover and makes it harder for bad actors to cheat the system.


With all that in mind, I started to redesign the original prototype and play around with ideas and different options to handle the new requirements (12 different verions as it stands). The original code was split in to more defined modules and inside those modules there is an other split. On the front-end (tx-serve) different api's (rest, socket.io, ...) can be implemented and on the back-end (tx-watch) other payment options can be added (dash, bitcoin, litecoin, ... or zmq, spv, ...).

At the time of writing:
* socket.io is implemented; a rest full api is in the pipeline.
* Dashd using zmq is implemented, bitcoin using zmq is in the pipeline.

The architecture to achieve this has some overhead but in my opinion it is well worth it. Besides making the stack very flexible it also makes it possible to pull the monolithic server apart and run the separated modules as services to create redundancy, scalability and/or add-on modules. (The work required to do this is also in the pipeline)


As you can tell there are meany things left do to both with a mid and long term time frame. For the short term my main focus is on getting what we have stable and packaged up in a usable form so that @kodaxx has a simple setup guide for his initial "point of sale" devices. After that who knows, I'm down to working 1/3 of my time on this so it all depends or where the funds take me.

Wip dev client:

Wip final server:

Original prototype server:

Description of the terminal api as planned for v0.1.0:
Last edited:
@Nitya Sattva This is great work!! Sorry to see your godash.org site is down, but your your X11 hash lib in Go is solid.

I have plans to start producing Dash software also in Go, and will use this as a base. Hope to see you are still around. I will share soon, first release is a x11sum utility based on this library you wrote.

P.S. Nice code coverage too BTW! These NIST test vectors are the real deal.
Hey there, these look like great projects. Were either of you ever able to get any traction on them? Would love to see a Dash library in Go.

Also asking b/c we're starting to get interest from other parties as well. Thanks!