Weekly Dev Update #39

2020-04-21 — 6 min read

THORChain Weekly Dev Update for Week 14–20 Apr 2020

Summary

Bitcoin Integration

THORNode has integrated BTC as a chain type, as well as Bitcoin address validation supporting P2WSH, P2WPKH (segwit) and P2SH, P2PKH (non-segwit). This means users will be able to send BTC.BTC to new addresses (starting with bc1 ) as well as legacy addresses, starting with 3 or 1.

https://gitlab.com/thorchain/thornode/-/blob/master/common/address.go#L53

Bifröst now observes incoming Bitcoin transactions, with the following required structure:

Structure of valid inbound Bitcoin transaction. https://gitlab.com/thorchain/thornode/-/blob/master/bifrost/pkg/chainclients/bitcoin/bitcoin.go#L255

Any transaction that does not have this structure will be ignored. This is because Bitcoin has an extremely flexible transaction structure and allowing a wider range of transactions was going to cause too much complexity for THORNode. Any wallet or exchange that wishes to integrate THORChain will have to follow this structure. ASGARDEX will provide a reference implementation.

Bitcoin has also been integrated into Smoke tests, and all aspects have been validated in the single-node environment. The next aspect will be to integrate it into a multi-node environment in order to test out THORChain TSS batch signing of UTXOs.

Ethereum Integration

Ethereum has also been integrated in Bifröst, with the following code-chunk showing how a transaction is decoded and used to create a valid txIn :

Creating a txIn with Sender, To, Coins, Memo and Gas

Ethereum is a bit simpler in decoding a transaction, however only ETH.ETH is supported currently. The issue is that the MEMO can easily be parsed from tx.Data() in an eth transaction, but in a ERC-20 transaction the tx.Data() object is completely filled with the ERC-20 transfer call. The solution is to use a smart contract to allow the MEMO to be added as a string, however this creates UX problems among other things. ERC-20 can be solved, it will just require concessions.

Errata Transactions

Proof-of-Work is leaderless because it uses the power of probability and a huge number space to create entropy for leader selection. However, a leaderless blockchain (while excellent at being live and censorship-resistant), necessarily requires users to accept that the chain-tip may not be correct at any given time. Chain re-organisations are a natural event and happen all the time. Malicious re-organisations happen when a network user uses this natural occurence to their advantage and fools another network user in accepting their transaction. In either case (natural or malicious), the network user accepting the transaction is THORChain and it has not ability to seek retribution for loss of funds. All it can (and should) do is maintain eventual consistency with solvency — that the funds it thinks it has in its vaults matches what it actually has.

As such, THORChain adds the concept of an errataTx — a mechanism for accepting that a transaction it previously observed and took action on no longer exists (re-orged out) and the balances associated with that transaction has to be removed from its system. The transaction is quite simple and it submitted by nodes who, upon receiving a new chain-tip candidate, re-scan previously reported transactions to find those that no longer exist:type errataTx struct {
ID TxID `json:"id"`
Chain Chain `json:"chain"`
}

Once THORChain reaches consensus on it, it will then go ahead with the following logic:

Swap: Deduct pool balance
Stake: Deduct pool balance and remove stakeUnits for associated staker.

Since it cannot undo the event, it is simply trying return the system to solvency, and in doing so, socialise the loss of funds to all pool stakers.

Importantly, loss of funds is limited to just the amount of the re-orged funds. It is imagined if this occurs, then THORNodes will release an update to increase the acceptance criteria of new transactions for that chain to prevent re-occurence.

Acceptance Criteria

Since THORChain has an excellent view of connected networks (all THORNodes run associated nodes for each chain), then accepting 1-confirmation is relatively safe. THORChain’s team has previously argued that any transaction that is less than the block reward for a chain can be safely accepted, and it is not likely that large (10+Bitcoin, 100+ Ether) transactions will occur on the network for a while (due to low starting liquidity). Confirmation-counting will be added at a future point in time, and since it is not consensus-related, it can be released as a network patch easily.

THORNode

Bitcoin

Ethereum

Other

Midgard

Maintenance

Clients

BEPSwap

Tweaks, bugfixes and improvements to Byzantine.

Asgard Wallet

Preparing for release.

Community

Arb Bots

Two open-source trading bots are being developed by the community and will be unveiled soon.

THORNode Notification Service

Block42 is leading the charge on the TNS and it will be unveiled soon.

Bounty Program

Enquire with the team about bounties for THORChain development.

Audit

Code Review: Complete

Economic Review: Completed most of THORChain's economic architecture

TSS Audit: kickoff

Next Milestones

The updated testnet is in the final stages of testing. Chaosnet is expected once testnet has been fully-validated in several environments. There currently isn’t any known blockers to Chaosnet release.