Multi-Signature is Here

The Paradigm Shifts Today

What are the differences between centralized and decentralized exchanges? We know at the heart of a centralized exchange is a central account controlled by one party. This usually gives way to convenience and speed of transactions. A decentralized exchange is a comparatively finicky exchange built with smart contracts that can have high transaction fees and the possibility of transaction failures.

What if there was a way to merge the best of both into a Decentralized Exchange? Well this would be a bad post if I wasn't about to explain how that works on Hive and what it will allow us to do.

DLUX is a decentralized layer 2 on Hive. What that means is several accounts run the same software to maintain the same database. Once a user told me his funds were missing, and sure enough his wallet said null. It turns out that every other node had his correct balance, and the consensus was that his tokens were there. The node automatically recovered from this condition after autonomously conferring with the other nodes and recovering the consensus database. In computing there will be errors if for no other reason than cosmic rays can flip bits. For this reason alone a centralized exchange has to run verification on it's own database.

By distributing this verification across multiple accounts we can also do something pretty clever. Control a central hive wallet with our nodes. Let me introduce @dlux-cc, the dlux community chest.
This account has been set up for testing our new multi-signature transactions.
Let's take a look at the aspects that make this account special:

active: {
    "account_auths":[
        ["disregardfiat",1],
        ["dlux-io",1],
        ["markegiles",1]
    ],
    "key_auths":[],
    "weight_threshold":2
}

Normally accounts on Hive have key_auths. They also normally have a weight_threshold of 1. This means that the single key can be used to make a single signature to authorize a transaction. But here, this account has a weight_threshold of 2, and account_auths. Which means it will take active signatures from 2 of the 3 listed accounts to authorize a transaction. These accounts currently run consensus nodes in the dlux layer 2, and part of establishing that consensus will be building transactions to complete exchanges.

They automatically consolidate multiple transactions to the same accounts, then sign the transactions. After which the transactions are stored with out signatures so they can be in consensus. Each node will send their signature of this transaction block along with their consensus report. As the nodes are tallying consensus hashes, they'll also query the HIVE API if each reported signature is valid. The valid signatures will be attached to the transactions and broadcast to the network. Well, this would be ideal, but as of now you have to verify signatures in a valid configuration. 3/3 is not valid in a 2/3 weight, and verification doesn't scale very well... but it works.

Once the nodes read these transactions on chain, they'll delete the transaction block from their collective database.

The next special thing about @dlux-cc is it's owner keys:

owner:{
    "account_auths":[],
    "key_auths":[
        ["STM5Rp1fWQMS7tAPVqatg8B22faeJGcKkfsez3mgUwGZPE9aqWd6X",1],
        ["STM7Hgi4pjf5e7u6oKLdhWfgForEVikzvpkK5ejdaMzAzH6dWAtAD",1],
        ["STM8TPTJXiCbGaEhAheXxQqbX4isq3UWiPuQBnHLmCKpmmNXhu31m",1]],
    "weight_threshold":2
}

Like discussed earlier there are multiple keys, each being a part required to get over the threshold. As new dlux nodes are run, or some go offline, the accounts will need to have a way to make sure only consensus accounts have a portion of the authority. In order to keep owner keys off of any servers, a new key is generated and put in the dlux nodes. Much like a witness key, it's only purpose is to update the community account as the consensus nodes come in and out of consensus, and change their levels of governance tokens.

Security that must be mentioned. The accounts that run this account have to put up collateral, and the lowest collateralized minority is the deciding factor as to how many resources can be controlled by this account at any one time. For instance, if the weight threshold is 3/5 and 3 accounts have $10k of collateral: those 3 accounts can take any amount in excess of $30k and profit from their collusion. Therefore if this is the case, the account should never be controlling more than $20k. If a confidence hack does happen, the accounts that signed the transaction can cover any losses with their collateral and transactions will look no different than a "failed" transaction on another DEX.

In action:

---

The first application of this is to have partial fills on our DEX orderbook. If you want 10 DLUX you'll be able to send ~10 Hive as either a market or limit order, and your Hive will be distributed to the accounts that had their orders filled.

We'll be able to accept Hive and HBD for NFT sales and auctions.

This will enables cross chain swaps and wrapped assets, and also means our account can distribute funds from the Hive DAO... and even pay them back.

This functionality will be rolling out to HoneyComb, our community token software.

---

This code is open source and as such we hope the community as a whole can use it to build bigger and better things on Hive. We're the smart contract platform that can scale right now.

If you find my work compelling please support my Hive Witness, run a dlux node, or build dlux dApps or NFTs.
You can find me on discord