Bitshares and Hashed Time Lock Contracts (HTLC)

It was certainly a privilege to participate in Bitfest Amsterdam (22-September-2018). Here are the slides of the presentation I gave there.

Bitshares will soon support Hashed Time-Lock Contracts (HTLC). The idea of HTLCs has its basis in a secret (called a “preimage”) and an algorithm that creates a message digest (often called a hash algorithm). There are a variety of hash algorithms available. The most common are SHA256, SHA1, and RIPEMD160. Bitshares will support those three.

A hash algorithm takes a preimage and turns it into a binary string of a certain length. For instance, if you ran the words “My Secret” through the algorithm SHA256, you would get:

If you change just one small thing in your preimage, the hash changes entirely. Another property of these algorithms is that the length of the hash does not change. The hash length of “My Secret” will be the same as the hash length of the bytes of an image, or a PDF document that contains the text of the book War and Peace.

Such algorithms are key to many interesting possibilities, including Hashed Time-Lock Contracts. The most popular use of HTLCs are atomic swaps. If two chains support HTLC, and share at least one hash algorithm, you can do cross-chain atomic swaps.

This means that if you can find someone to trade with, you can exchange one coin on one chain for another coin on another chain. Lets walk through this together with an example:

Here we have Alice and Bob. Alice has 1 bitBTC on the Bitshares blockchain. But she needs to pay her rent. Her landlord is old-school, and only accepts Bitcoin. But Bob is willing to receive her 1 bitBTC in exchange for 1 BTC. Alice and Bob agree to swap. Alice creates an HTLC on the Bitshares blockchain which will transfer 1 bitBTC to Bob’s account if he presents the preimage that matches this hash before a certain time. 24 hours for instance.

If Bob presents the preimage, he gets 1 bitBTC in his Bitshares wallet. If he does not, Alice gets her 1 bitBTC back in her account. But how does he get Alice’s secret preimage? Hold on, it is coming.

Alice shares the identifier of her contract with Bob. Bob can examine it to see if it matches the terms of the deal. He also can see the hash, and will use the same hash to create another HTLC on the Bitcoin blockchain.

Bob’s HTLC is very similar to Alice’s contract. He is agreeing to put 1 BTC in Alice’s Bitcoin account, if she can present a preimage that can be run through the hashing algorithm and return the correct hash. There is also a timeout. If she does not do this with say 12 hours, the 1 BTC again belongs to Bob.

Bob then shares the Bitcoin hash for this contract with Alice. She can inspect it, and if she likes, she can present her preimage and the 1 BTC is in her Bitcoin wallet. She can now pay her rent. At the same time, her preimage is now exposed on the blockchain. Bob can see it, and can use it to “unlock” the 1 bitBTC on the Bitshares blockchain. Both contracts are satisfied, and the cross-chain atomic swap is complete.

Here are some things you can do with HTLCs:

They may be used for regular purchases. It is not necessary that they be used for only cross-chain atomic swaps. It could be used to prove that Alice has the funds, and is willing to set the funds aside for a certain amount of time.

HTLCs could also be used to swap assets without using order books and online exchanges. Perhaps Alice and Bob agree to swap a large quantity of assets at a certain rate, but do not want to use the exchanges available to them. This is similar to “dark pools” that some US securities brokers have.

But of course, the most popular use-case is the scenario we just walked through, cross-chain atomic swaps.

Which foreign chains support HTLCs? The website keeps track of them. Here is an image of that website as of today:

As you can see, HTLC support has been implemented across many blockchains. Red ones are not quite there, orange ones can be used but are missing some features, and green ones have fully implemented it.

So what is left to do to make HTLCs available in Bitshares? Wallets that support creation and review of these contracts would certainly be useful. Communities of “mini-gateways” are needed so that users can find others that are willing to swap with them. And note that these “gateways” do not need to issue their own coins, as is often done today.

The ability to create these contracts in Bitshares Core is actively being worked on, and it is my hope that it is included in the next hardfork release. The BSIP is almost complete, and should be available for public review in a few days. After that, the community can build on top of it.

This is an important feature that will soon be included in Bitshares. Learn about it. Build on top of it. There are several opportunities here that you can capitalize on. I am excited to see different ways this feature can be used to help you and your business. If I can help, or if you have questions, contact me.

Bloom Filter Types

In the implementation I am working with, a bloom filter allows us to determine if a particular item has been selected from a set. Both the set and subset can be large.

While speed is a benefit, the real benefit for us is the memory footprint. We can quickly determine if the item is (probably) selected, without maintaining a list of (large) keys.

I am researching various types of bloom filters that must fit within the following parameters:

  • Low false positive
  • Memory efficient
  • Deletable
  • No false negative

The last two pose the challenge. A standard implementation of a bloom filter does not have false negatives, but items cannot be deleted. Deletions without knowing if an item was previously inserted can cause false negatives in the following implementations:

  • counting bloom filter
  • cuckoo filter
  • dlbf (possibly, not tested)

Research links:

Git Tricks

Here are some tricks that I use. They’re here because I need a place to quickly refer to them.

  • Updating a fork with upstream changes:
  • Interactive rebasing:
    • git rebase -i <branch>
  • To avoid messing up a PR, you can do things like:
    • git reset –hard HEAD-1 # or HEAD-2, etc, or directly to a commit hash
    • git push –force origin branch_name
  • Always do a backup before reset or rebase

C++ Publish Subscribe

I had the need to make a publish-subscribe mechanism in C++. So as is common, I looked around at other examples to see how others have done it and found a simple example courtesy of GitHubGist user makomweb.

His didn’t include comments, so I’m commenting it on my own copy here.

As programmers, we learn from each other. Each piece of code we write or see helps us to reason, adjust, and form opinions.

Getting our hands dirty and coding is a great learning experience. But reviewing the code of others helps us to build skills.

Why did makomweb not just have the Subscriber class conform to an interface? The entire class could have been passed to the Producer instead of just saving off the method. Think about it.

Look at the Publisher.Publish method. Elegant. One line of code to call Event(). The magic happens in Event.operator(). It calls the method that was registered in the Event.Subscribe call.

Had we stored an object that complies to an interface, we could do the same thing. We store the object in a map. When a “Publish” happens, we iterate the map, calling the method from the interface.