Implement Atomic Swap / Side Chain between BTC (Bitcoin) and BTS (Bitshares tokens)

testlump commented 7 years ago

Description

A feature request to allow a side chain / atomic swap between Bitcoin and BTS in a trustless manner, removing the need for 3rd party gateways like openledger.

The Bitshares DEX currently enables trading of many tokens (except Smartcoins) through third party created assets.

OPEN.BTC (the defacto representation of Bitcoin within the Bitshares ecosystem) has been created and is backed by the third party Openledger as a UIA (User Issued Asset). This scenario leads to the following problems:

It is not trustless. It requires that Openledger is always in existence in order for Bitcoins (BTC) that have been exchanged for OPEN.BTC, to be redeemable for Bitcoin (BTC). If Openledger fails (or denies redemption) for whatever reason, any OPEN.BTC becomes essentially worthless since it can no longer be redeemed against the underlying asset.
The third party earns fees on the trading of their UIA's. This means that users who trade OPEN.BTC essentially pay 0.2% to Openledger per trade for the privilege.
The third party may enable (or disable) features on the asset that may not be to the benefit of all holders (for example 'Confidential Transactions', 'Whitelisting', 'Asset transfer approvals'). These flags are unidirectional (once enabled they cannot be disabled), but they can be enabled at any point in the assets lifetime.

In order to remove this third party dependency, it would be necessary to implement functionality to allow Bitcoins (BTC) to be deposited and withdrawn to/from the Bitshares system without the need for any third party gateways. The system will automatically generate a UIA of equivalent value (E.g. BIT.BTC) that the user can trade on the DEX. Any user that holds the UIA can exchange the asset automatically for the underlying asset at the point of withdrawal (BIT.BTC->BTC).

This has the following benefits:

Is completely trustless (Anyone can deposit and withdraw from the system with no requirements for third party oversight)
Market fees for trading the asset can be set to 0 since fees are generated by the act of transacting the asset (network fees) and those are credited to the system (reserve pool), which can be used to fund further enhancements to the Bitshares system as well as undercut centralized exchanges.
Allows users to transfer between Bitshares accounts, effectively providing an extremely fast way to move Bitcoin between individuals in a trustless manner. This would negate the need for solutions like Bitcoin United.
Can be extended to other coins that are based on the same architecture as Bitcoin such as Bitcoin Cash and Litecoin.
The proposed feature is would also negate many of the benefits touted by the Bitcoin Lightning network as well as adding the ability for users to trade the side-chain/atomic swap assets through the existing Bitshares DEX.

No other network (to the authors knowledge) has yet enabled Side chains though they have been discussed at length in the context of Bitcoin. This may speak to the complexity of such an undertaking, but the rewards are potentially huge.

Proposed High Level Solution

One potential solution for enabling side-chains (in the context of Bitcoin) is described at a high level in the Bitcoin wiki here: https://en.bitcoin.it/wiki/Atomic_cross-chain_trading

pmconrad commented 7 years ago

Good writeup. I agree we need this. Two remarks:

This is a big project and needs to be laid out in the form of a proposal. See https://github.com/bitshares/bsips .
You describe a trustless gateway / sidechain, but you propose ACCT as a solution. I believe these are two different things. ACCT is comparatively low-hanging fruit.

cptn-solo commented 7 years ago

Couldn't it be possible to add a Gold Atom Price to this proposal? I mean, a 1Au can be just priced by the core. One can buy a mass-spectrometer and just measure an Au atoms in a sample - and Bitshares could trace the price for the handful of atoms. It's just math. No third parties. No trust. Just. Math.

testlump commented 7 years ago

@kkrupovich are you not describing the bitGOLD system issued smartcoin which already exists on the Bitshares platform? It's not priced per atom but per troy ounce and divisible to eight decimal places. Or do you mean something else?

cptn-solo commented 7 years ago

@testlump the only difference is an atomic approach. bitGold isn't atomic. and IS trusted. while sensor's logic could be cryptographically proven and even legitimately certified.

alexpmorris commented 7 years ago

I've thought about the need for this for a long time. But it seems, to properly implement it would require the chain, perhaps in the form of a smart contract of some sort, to be the sole master key holder of a bitcoin address (or other coin address) holding that value.

So, it would seem what really needs to be solved is:

making sure the contract always interacts with a reputable node (less likely target vector, since no keys exchanged)
is it possible to create a smart contract where a witness node couldn't simply step through the code and reverse-engineer access to the key in memory (any crypto magic out there that can solve this one?)

cptn-solo commented 7 years ago

@alexpmorris suppose it should be wrapped as a custom transaction type with steps: 1/ create a "proposal" transaction with associated coin master key, known only to this "proposal" and generated inside this step; 2/ "supplier" transfer funds (coins) to the public address, provided by the 1st step; 3/ transaction committed to the chain and coins locked under master key;

it is very similar to the process of private key creation in the key chain - container+request, then new key placed to a container. TX is playing for container in this scenario.

The only thing to do is to get one's funds back now ;) coz transaction locking coins is buried in the blockchain starting from step 3 ...

alexpmorris commented 7 years ago

But that's the problem. Sure you can encode the private key onto the blockchain with the "owner's" public key, but then let's say you have a sitting limit order, and someone comes along and matches you. You must be online and available to "authorize" the exchange, or else the trade will not be able to complete. And also, since it's the contract that has to decode it, you still have to send your key to the contract, which again becomes a potential attack vector.

cptn-solo commented 7 years ago

But I assume the key is not outside the contract ever. Transaction produces key internally. And the DEX itself operates all keys on engine level. Let's name it "Engine as a wallet" concept.

alexpmorris commented 7 years ago

Right, but at some point, the contract itself has to access the key, and if the contract can access it, that means the machine the contract is running on can access it as well, either through a compromised version of the witness node, or by directly analyzing the memory of the process itself (if process memory is encrypted, since it's all open source anyway, the decryption method would be trivial).

It's basically the same problem faced by all "key protected" software, and why they can inevitably all be cracked with enough time and effort, regardless of how sophisticated the "anti-hacking" methods used.

cptn-solo commented 7 years ago

Lets focus on encryption than. "Sophisticated anti-hacking challenge" bounty? My 1st bet was "Share the secret over the witnesses somehow". But I don't know much to be sure.

pmconrad commented 7 years ago

BitShares can do multi-sig. BitCoin can do multisig. Easy, eh?

Only that a fixed group of people would probably not be seen as "trustless".

With an elected group of people (like the BTS witnesses for example) you run into the problem that the group can and will change. Which means you have to "update" the multisig accounts (in BTS) and addresses (in BTC). The latter means you have to move funds around, which will cost fees. Which in turn means that you have less BTC backing their BTS counter-tokens than you need.

cptn-solo commented 7 years ago

@pmconrad, thanks for your input, i have another idea (sorry). I'm not arguing for sharing bitcoin balance among witnesses. Now I'm arguing for sharing keys only. But let's call it "smart sharing". Imagine a puzzle of items for which only holder of the atomically swappable asset (ASA) can get the remaining item to solve it. And once the puzzle solved you get your side coins. A transaction with ASA when processed could be used as an input (amount of withdrew).

This is an abstract idea. Just trying to guess the possible approach. And may be more informed dev could get ahead. Don't want to give up easy :) Nothing against OL, but we are not decentralised until we get atomic swaps or another trustless way of asset interchange.

alexpmorris commented 7 years ago

You're really back to the original problem I described. And even multisig would be susceptible to the same problems. As @pmconrad described, multisig is a variation of the same underlying problem. You're still trusting ever-changing witnesses to hold those keys. At that point, we're back to CCEDK with the open contracts, since that may be more or less what they're doing already.

You may find these links of interest on this topic as well: https://www.reddit.com/r/ethereum/comments/2c5fo0/private_keys_in_contracts/ https://forum.ethereum.org/discussion/1742/can-a-contract-keep-a-secret

Just to clarify the main difference again between guaranteeing balances and protecting foreign keys, if one witness becomes corrupted or compromised, all the other witnesses are there to "set the record straight".

As for protecting foreign private keys, if anyone sets up a witness and steps through the contract's code, they will be able to extract all the relevant keys required to access that bitcoin account and no one else can do a thing about it before all the funds are long gone.

flux627 commented 7 years ago

Food for thought: https://eprint.iacr.org/2011/241.pdf

This could allow witnesses to be the multi-sig entities for the various blockchain balances, all while being able to "hand-off" access to new witnesses as they come in and "lock out" old witnesses.

o5j5vg55bv5hv5j5f8799f9 commented 7 years ago

If that algorithm works, that's the best big solution I've seen so far but will require witnesses to run full nodes - or will light clients work with each witness selecting light client source of their choice. This can be done on longer time frame to be careful. Have to be careful about redundancy if several nodes go offline at same moment - can lose access to the BTC. As for changing multisig method, witnesses could technically put up small collateral for replacement fees that are consumed if they are replaced (users ofc pay for fees to deposit/withdraw).
Short term ACCT is low hanging fruit for p2p trades. Problem is no one can guarantee the value of an issued asset will be worth 1 BTC on p2p market due to BTC fees, concerns about different chain, handling of various forks of each chain. It can be done by using bitBTC for the pair. However, creating liquidity for bitBTC:BTC atomic market would require a whole system of nodes, and if expanded, for each chain. The simple approach here is to teach platforms specializing in slow atomic swaps to add bitBTC (and bitUSD, bitCNY, BTS) to their already formed networks. If at any time they fail, bitBTC is still redeemable for BTS. All you would have to do is contact http://barterdex.supernet.org/ or https://blocknet.co/ and teach them how to mimic atomic swapping commands for bitshares operations. They can handle onramp to bts chain with slower atomic swaps, and once on bts chain it can handle fast trading it does best (including trustless fiat pairs, margin, other markets) - each group focuses on their specialization independently. It's more like a bridge than a gateway in this manner but with similar value on both sides, no fork necessary if bts can mimic atomic swap steps. (might have to generate new account for each multisig with hashes of 2 keys and a secret, use propose to use the expiration/review to time out, and w/e else necessary - devs here would know best)

grctest commented 7 years ago

@testlump wrote: Allows users to transfer between Bitshares accounts, effectively providing an extremely fast way to move Bitcoin between individuals in a trustless manner. This would negate the need for solutions like Bitcoin United.

I disagree that this negates the need for assets such as Bitcoin United.

Whilst your proposal potentially makes it possible to move Bitcoin onto Bitshares for trade without a gateway, it still involved Bitcoin's archaic and bloated network & blockchain. By snapshotting Bitcoin and sharedropping their entire userbase and coin distribution onto the BTS DEX in the form of the FBTC UIA, their worries regarding centralized development or network consensus are negated and the death count caused by their enourmous electricity consumption is proven entirely unneccessary.

I think that your proposal will be great, however I still believe that Bitcoin United and other sharedropped UIA are worthwhile projects.

Any update on a BSIP?

xh3 commented 7 years ago

At the moment, I don't think it's possible to have trustless cross-chain trading, someone or something would have to wield the keys. I don't know that it will ever become possible given what would need to be true for it to work. A good value proposition for us would be to build a clearinghouse for lightning network cross-chain transactions on the dex and implement lightning net functionality on the native BTS chain. That would create a myriad of use cases without tying up brainpower in intractable computer science problems.

testlump commented 7 years ago

@grctest wrote: it still involved Bitcoin's archaic and bloated network & blockchain. By snapshotting Bitcoin and sharedropping their entire userbase and coin distribution onto the BTS DEX in the form of the FBTC UIA

Bitcoin United is not Bitcoin. It's just a vanilla Bitshares User Issued Asset with the Bitcoin name. Any hope of even limited success rests on the fact that holders of Bitcoin can obtain an allocation of Bitcoin United equal to the size of their Bitcoin holding at the time of the snapshot, for free, and so may be sufficiently motivated to at least try and claim their free stuff.

their worries regarding centralized development or network consensus are negated and the death count caused by their enourmous electricity consumption is proven entirely unneccessary.

This argument holds true for any comparison between the Bitshares and Bitcoin networks. Its truth is not predicated on the existence of Bitcoin United.

The technology proposed here is radically different. An asset issued through a side chain allows users to benefit directly from the speed, security and usability of the Bitshares network while also having the full confidence that they can redeem the asset at face value against the underlying token at any time and on/off ramp onto the other coin's network. It's equivalent to using PayPal to send cash about rather than stuffing it in an envelope and posting it.

Any update on a BSIP?

I hope to submit a draft PULL this Friday (1st September)

grctest commented 7 years ago

Bitcoin United is not Bitcoin. It's just a vanilla Bitshares User Issued Asset with the Bitcoin name.

All Bitcoin is to me is purely the distribution & its user base, which we can fully replicate through sharedropping an UIA. The core chain has significantly moved away from satoshi's original vision laid out in the bitcoin whitepaper & the precedent was set for hard forking on Aug 1st (likely in Nov too when 2x fails). BCH has successfully forked and their faults are not present with an UIA thus FBTC is a serious alternative to bitcoin-core&cash.

That said, it doesn't mean your research should be abandoned - having both (and future alt currency sidechains through your proposal) would be most advantageous.

I hope to submit a draft PULL this Friday (1st September)

Cool, great to hear - I look forwards to reading your proposal.

oxarbitrage commented 6 years ago

https://github.com/bitshares/bsips/issues/49

cogutvalera commented 6 years ago

BSIP44: Hashed Time-Lock Contract

pmconrad commented 6 years ago

Obsoleted by BSIP-44 / #1370 - closing

Victor118 commented 5 years ago

Why this issue was closed ? ACCT is a great feature but, here subject is also side chain between BTC and BTS ? Without that DEX is not a real DEX, IMHO it's very important

pmconrad commented 5 years ago

The OP wasn't very clear about his goals, so discussion went in many directions without reaching conclusion. Title mentions Atomic Swaps, which have been implemented, so this was closed.

Feel free to open a new, more specific, issue perhaps in the BSIPs repo: https://github.com/bitshares/bsips/

bitshares / bitshares-core