Will's Blog

We left off with an immutable data structure storing arbitrary data, you can read about that in part one , or you can view the introduction to this series here . As always,  the companion code for this post can be found on GitHub. In this post, we'll introduce transactions which are the primary feature needed to convert that data into a currency. Although a transaction simply needs to subtract coins from one account and add them to another, the way this is implemented in a blockchain is a little unusual. We'll cover all these details and more during this article before implementing them in the LynxCoin project. This is what we'll be working towards today. The first thing you need to understand about currencies stored on a blockchain is that there is no concept of a balance. Instead, you hold rights to transactions. Specifically, if you received a transaction for 50 LynxCoins, you now have the right to spend them. Our updated block looks like this. ...

This is the first post in a series building a cryptocurrency from scratch, the series introduction can be found here . Every day new developers are learning just how simple blockchain technologies are. One of the first things you may notice is that the collection of algorithms are profoundly clever , but the mechanics of creating a verifiably immutable chain of data is borderline trivial. If you need proof, take a look at how many introductory  blog posts are building a toy blockchain . These all include working implementations of a blockchain. One good reason to implement your own is to prove to yourself just how trivial the data structure is. Certainly, my first reaction to reading up on bitcoins block header was: is this all? Of course, the answer is no. Creating a blockchain is table-stakes, and from there a series of clever algorithms allow transactions to occur without a central authority. But this structure is the heart of all that follows, so building a bloc...

In this series of blog posts, the concepts needed to understand and implement the fundamentals of blockchain and cryptocurrency technologies will be introduced. During each post a new cryptocurrency concept will be introduced, then the technical details will be implemented as a practical demonstration of how they work. The currency will be implemented with Kotlin, which I've found to be expressive while maintaining readability. Future iterations of this project may include alternate implementations in other languages. This series will be broken into several parts: Data Structure Currency and Transactions Decentralization and Mining Optimization: Merkle Trees Data Structure An introduction to the mechanisms that allow us to verify that data in the chain has not been tampered with. We'll begin with a high-level explanation of how it works and move onto a succinct implementation which will serve as a stepping stone for the following posts. Currency and Transacti...

If you regularly work with REST endpoints you're probably used to a lot of tedium. Between carefully constructing the parameters, encoding data in just the right format, efficiently sending the requests, parsing the results and handling errors at every step along the way; there is a lot of room to make mistakes. For simple APIs, it often makes sense to manually format the request and send it out. Checking a status code, and maybe mapping results to an object aren't that big a deal for a simple API. But what if there are 20 different endpoints? Or you need to manage authorization headers? Eventually, it makes sense to start looking for a wrapper library, or maybe making your own wrapper layer. That's what this post is about. For JVM developers, pairing Kotlin, Retrofit2 and Gson make it easy to bang out a type-safe client wrapper. Let us jump right into the code: // Create data classes for serializing inputs and outputs. data class Results ...