Investigate what is required to allow plugging in different coin types (UTXO based and non-UTXO based).

[gertjaap]

There's an idea to integrate CryptoKernel based assets into LIT. What would be required to integrate that? Also, investigate the possibility to integrate non-UTXO based assets like Ethereum. Break down what is required to achieve this.

[Varunram]

It is very difficult to integrate non-UTXO based coins (in this eg, taking Ethereum) into lit for multiple reasons but the foremost being that Ethereum requires smart contracts run on the EVM. Since bitcoin doesn't have anything remotely similar, we'd need our own contract deployed on Ethereum to do this. But by deploying a contract in Ethereum, we're plugging lit into Ethereum rather than the other way around, so the question really is "How do we plug lit into ethereum" rather than "how do we plug ethereum into lit".

[delbonis]

I'd imagine that we'd have to refactor all of the bitcoin-specific code out to work generically, and then have a "coin" package with all the different "breeds" of coin in there as different subpackages, which provide coinparams/chainhooks, and all the other coin-specific data generically so that the rest of Lit doesn't actually care what's going on under the hood.

If you look at the dependency graph I made the other day you can see that there's a lot of interconnectedness, especially on things in btcd and btcutil. I'm proposing on refactoring that into a "Bitcoin driver" that exists on its own and the rest of Lit interfaces with cleanly (of course, coins based on Bitcoin will be able to use the Bitcoin driver, but with slightly different parameters). Then the rest of Lit will just depend on that package that provides the interface (interface in the general sense, not the Go sense) to the coin drivers.

This will also help with reusability of Lit's components in other projects by making it less monolithic. Support for account-based coins (Ethereum) would be another project, but using a model like this is a necessary first step to supporting that as we need to abstract away the implementation details of how Lit gets its work done for each currency to just functions that say "set up an HTLC with these settings", "close this channel", etc.

[gertjaap]

I like your approach @delbonis . I think it makes sense to abstract the coin/chain management into a "driver" as you call it.

Given your arguments about tight coupling with btcd / btcutil - this would already be necessary if we would want lit to work on cryptokernel. By adding the Ethereum case to this investigation, the abstraction will be on such a level that we can support most assets, in stead of just the UTXO based ones.

What would the next step be? I think we should define the interface of the "driver"?

[delbonis]

After we have the HTLC code that @metalicjames is working on merged I'll start planning the refactor for all of that. Really, what it would mean is just moving a bunch of Bitcoin-specific code into one place and then replacing calls into that with virtual calls on an interface.

The most major changes I see happening are regarding OutPoint, setting up contracts, and the chainhook code. Some datastructures with hardcoded array lengths might need to be generalized a bit more, but that shouldn't be too much of an issue beyond changing internal representation and serialization code. This would avoid having to pass around coinType values in places and just pass around the coin object for doing coin-specific behavior.

[delbonis]

oops!

[robcohen]

Bump. Anyone make any progress on this front. I am particularly interested in seeing how this could work with UTXO coins, such as Cardano.