Hans Schmidt :  August 2021

hans_schm1dt@protonmail.com


Evermore Support for 2-step On-Chain SIGHASH_SINGLE Atomic Swaps

2-Step On-Chain Atomic Swaps can be constructed on Ravencoin by making available half-transaction offers using 1 input and 1 output and SIGHASH_SINGLE|SIGHASH_ANYONECANPAY. The swaps guarantee atomicity due to the all-or-nothing nature of transactions in which all inputs and outputs are executed or none of them are.

The nice thing about this scheme is that there is no upfront negotiation needed. They are far simpler than traditional HTLC P2SH Cross-Chain Atomic Swaps, which require substantial off-chain communication between buyer and seller. In a 2-step swap, the seller posts an offer which is a partial transaction which basically says "I am willing to sell X and I don't care about any other inputs or outputs as long as I get Y". Any buyer who likes the terms can accept the offer by completing the transaction and submitting it.

See the following resource describing the use of SIGHASH_SINGLE|SIGHASH_ANYONECANPAY to achieve this functionality:
    https://raghavsood.com/blog/2018/06/10/bitcoin-signature-types-sighash

Note that there is really no difference between an "offer to sell" and an "offer to buy". An "offer to sell" uses an asset as the input with RVN as the ouput, while an "offer to buy" uses RVN is the input with an asset as the ouput.



Level-1 DEX Support:

Every UTXO can be an offer if new "desired swap" data fields are created and filled in by the offer creator during an asset transaction. Retracting or revising an offer is then simply done by creating another transaction which transfers the asset to a new UTXO with new data in the "desired swap" fields.

Note that this eliminates the need for a database or a broadcast channel for offer tracking and transmission since the blockchain itself serves those functions.

Chain Which chain holds the asset I want in exchange. Currently always RVN. This field in for cross-chain swaps
Asset_Name The name of what I want in exchange such as RVN or another asset.
Ask_Qty How many of them I want. Equivalent to the price times the input Qty.
Expire_Time The Unix epoch time at which the offer expires (+- one block interval)
Signature My signature needed by you to construct a full transaction using my SIGHASH_SINGLE|SIGHASH_ANYONECANPAY offer


These new data fields are only informational and unused in the transaction in which they are written into an output of that transaction. But they contain the information necessary for anyone to create a spending transaction which accepts the offer described by the new data fields.

Traders can wait for the new UTXOs to be mined before searching them and submitting matching acceptance transactions. But nothing prevents buyers from snooping the P2P node traffic, in which case an offer and its acceptance could be mined sequentially into the same block.

Of course a separate database and separate communication channel could still be used to track and broadcast offers in order to save on transaction fees.




Level-2 DEX Support:

One inefficiency of this scheme is that buyers must match the exact qty of the offer by creating a matching UTXO. In a competition amoung buyers, miners will insure that only one of the buyers will be allowed to take the offered UTXO and the other buyers' transactions will be rejected with no transaction fee. Nevertheless, the all-or-nothing requirement of the swapped quantity limits the number of possible buyers and complicates swap completion.

An even larger inefficiency is in price discovery. On-chain offers as described above are a useful mechanism to bootstrap a DEX since they eliminate the need for a database or a broadcast channel to track the offers. But on-chain atomic swaps are best viewed as settlement (delivery) rather than price discovery. 2-step offers can migrate off-chain using an out-of-band broadcast channel for better performance, but improving price discovery requires support for more complex order types such as Market, Stop, Limit, Stop_Limit, and Stop_Market.

Both quantity flexibility and improved price discovery can be improved by adding the following UTXO data field enhancements:       

Order_Type Precise(Legacy)/Market/Stop/Limit/Stop_Limit/Stop_Market (note: Trailing_Stop is not possible since it requires knowledge of the past)
Stop The Stop Qty (price) for Stop Orders (ratio assuming input Qty=1)
Limit The Limit Qty (price) for Limit Orders (ratio assuming input Qty=1)
Granularity Zero represents an All-or-None legacy UTXO. Non-zero values indicate the granularity under which an order may be partially filled.
Change_Address The ScriptPubKey to which a change output should be created if the order is only partially filled. If left blank, the change is sent back to the source address

Note that all of these new data fields are only informational and unused in the transaction in which they are written into an output of that transaction. However, during a future transaction which spends that output by using it as an input, the consensus rules read these new fields to determine whether the spending transaction satisfies the requirements set by these fields. The spending transaction may have a Vout value (final settlement quantity) which is different than Ask_Qty due to partial order fulfillment (based on Granularity) or price change (within the rules set by Order_Type, Stop, and Limit).



Level-3 DEX Support:

Price Discovery can be made even more efficient. Large liquid markets implementing full bid/ask order books will remain more efficient for many asset pairs than most other market implementations. In those cases, it is advantageous to support the use of an Oracle for price discovery.        

Oracle support can improve price discovery and provide vast flexibility by adding the following UTXO data field enhancements:

Written into the transaction output of the transaction making an offer
Oracle_Pubkey The pubkey of the Oracle trusted by the seller to dictate the exchange price for this UTXO


Included along with Vout in the spending transaction which accepts an offer
Oracle_Quote Time-stampled Oracle Response which was used to set the price when the order was filled


Note that the Oracle is chosen by the owner of the UTXO making the offer. It is up to the other party to decide whether to accept that Oracle by taking the deal.

Note also that it would not be practical in any case for the Oracle to simply be an asset metadata field chosen by the asset issuer because there will likely be different Oracles based on the other asset in the trading pair.

Note that neither nodes nor miners are responsible for creating transactions from offers, though they may choose to do so. They are not required to determine whether completed transactions can be assembled from matching broadcasted half-transactions nor from previous transactions containing offers. They are also not responsible for connecting to Oracles and determining prices which fulfill the order requirements. Any party can execute those functions to build and submit full transactions in the hope that they will be mined and they can make a profit on the bid/ask spread. That will be true of fixed price offers as well as for the complex order types. Full nodes (including miners) will have modified concensus rules which implement the new rules regarding partial order fulfillment, complex orders, and/or Oracle-guided pricing to insure that the submitted transactions satisfy those new rules.




Oracle-guided trading:

  • Normal UTXO trading uses traditional price discovery negotiated between buyers and sellers. But such trading requires high-speed order books and cannot be done on-chain. While such legacy trades should always be an available option, a more efficient on-chain market can be implemented if Oracles are used to set the price of trades. Fairly simple changes to Ravencoin can be implemented which use Oracle price setting and 2-step On-Chain Atomic Swaps to implement much more efficient and flexible trade types including Precise(Legacy)/Market/Stop/Limit/Stop_Limit/Stop_Market.
  • Note that if the token being traded represents an off-chain asset, then even with Oracle price setting, the token requires a stable coin mechanism to bind the token to the off-chain asset, or it must trade in a pair with a stable-coin asset. This is needed to provide an arbitrage mechanism to anchor the on-chain price to its off-chain value. Otherwise, Oracle inaccuracies and computational round-off errors will accumulate to create growing token price inaccuracy.   
  • Note, however, that no off-chain anchor is needed if the value is fully on-chain. A token containing a predictions market contract which accepts RVN from bet participants and pays out based on Oracle information needs no off-chain anchor.



Implementing the Price Oracles:

Remember that the goal of RavencoinPlus is to implement low-level plumbing support for defi in a bitcoin-like architecture without committing to specific defi implementations when there are choices. Price discovery, for instance, can be done in a number of ways. Many of the newest defi projects use Automated Market Makers (AMMs) using a variety of experimental formulas. Using an Oracle in the low-level protocol is implementation agnostic because the Oracle could be an on-chain AMM, an AMM on another chain, or a price feed from a Centralized Exchange. Or, just leave the Oracle field blank and Ravencoin will work just like it does now with you deciding the price- it is forward flexible and backward compatible.

The simplest and most flexible solution is to allow selection of the Oracle to be made by the party making the offer, and it is up to the other party to decide whether to accept that Oracle by taking the deal.
  • Note that the Oracle cannot simply be an asset metadata field chosen by the asset issuer because there will likely be different Oracles based on the other asset in the trading pair.
       
The use of Oracles is best suited for trade between tokens who's prices are pegged to well-known assets since a reliable Oracle is needed which "knows" the price with high confidence. But since the party making the offer selects the Oracle and the party accepting the offer is also accepting the Oracle choice, this is not a problem.

For well-known common crytpo assets, price discovery is already done well on many centralized exchanges. Those will remain the best sources of price information for the foreseeable future and an Oracle should be chosen which uses a data feed from one or more centralized exchanges.

Oracles are available from some distributed exchanges, but they are less reliable because distributed exchanges have insufficient capacity or speed to implement Limit Order Books like centralized exchanges which handle by far most of the volume. Those limitation imply that there is a greater risk of manipulation of a DEX-derived price Oracle 
       
It would be possible to implement the Oracle by letting miners "vote" on the best source (as in Pegnet), but that is complex, and it is subject to manipulation by miners and attackers.

Note that when trading tokens on Ravencoin when the tokens represent off-chain assets, the token trade can be viewed as the close of price agreement between the parties, but without settlement. Settlement is the act of delivery of the off-chain asset in exchange for the Ravencoin token. Settlement can happen at a later time, or be replaced by anoter token trade, or can be settled in RVN rather than in the underlying asset. This also means that if settlement is implemented using a cross-chain atomic swap technology, then there need be no concern about the possible existence of free options in the atomic swap protocol because the price has already been fixed and the sale committed.
       
Some well known sources of Oracles are already available:
  • Chainlink Price Reference Data contract
  • Compound's Open Price Feed
  • Okcoin Oracle signed price feed
           
New technologies such as "Gravity Protocol" are expected to make Oracles much more common, not only for price discovery, but also for a variety of inter-blockchain data communications
       
Developing and providing Oracles as a for-profit business is expected to be a good opportunity for independent vendors





Copyright 2021 by Hans Schmidt