-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create BSIP9999 Distributed Bitcoin Cross Claim Gateway #287
Open
litepresence
wants to merge
1
commit into
bitshares:master
Choose a base branch
from
litepresence:patch-2
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,110 @@ | ||
|
|
||
|
|
||
| BSIP: 9999 | ||
| Title: Distributed Bitcoin Cross Claim Gateway | ||
| Authors: litepresence finitestate@tutamail.com | ||
| Status: Draft | ||
|
|
||
| BSIP: <BSIP number> | ||
| Title: <BSIP title> | ||
| Authors: <list of authors' real names and optionally, email addrs> | ||
| Status: [ Draft | Accepted | Installed | Voting | Deferred | Rejected | Superseded | Obsoleted ] | ||
|
|
||
| Type: Protocol | ||
|
|
||
| Created: 2020-09-09 | ||
|
|
||
| Discussion: <url> | ||
|
|
||
| Abstract | ||
| ---------------- | ||
|
|
||
| polkaBTC is a full reserve distributed gateway | ||
|
|
||
| polkaBTC "vault" is a contract that anyone can issue polkaBTC from - to any other party | ||
| witnesses run bitcoin spv nodes and post headers | ||
| the statistical mode of the headers are then a "BTC parachain" on the issuing chain | ||
| issuers post collateral much like borrowing an MPA | ||
| issuer must maintain collateral of core token on the issuing chain | ||
| or other token on issuing chain) at stochastic market rate | ||
| issuers can charge a fee to those who request or redeem polkaBTC | ||
| issuer collateral ratio, fees charged, and vault size is public rpc info | ||
| In practice, request and redeem work much like a gateway from the user level except: | ||
| instead of judging gateways based on perceived trustworthiness | ||
| you judge gateways based on fees charged | ||
| additionally polkaBTC is equivilent regardless of which user issued it | ||
|
|
||
| Motivation | ||
| ---------------- | ||
|
|
||
| Traditional IOU gateways require trusted third parties which have historically ended with "exit scams" | ||
|
|
||
| Rational | ||
| ---------------- | ||
|
|
||
| A smart contract XCLAIM style gateway ensures contractual performance through collateralization | ||
|
|
||
| Specifications | ||
| ---------------- | ||
|
|
||
| Witnesses upload bitcoin headers | ||
| Anyone can issue "polkaBTC" to anyone by locking BTC on Bitcoin Mainnet | ||
| Anyone with "polkaBTC" can redeem with any vault operator. | ||
| vault operators must maintain collateral or be penalized. | ||
|
|
||
|
|
||
| Discussion | ||
| ---------------- | ||
|
|
||
| see POLKABTC SPECIFICATION DOCS for details. Of course we can debate what we'll name the token. | ||
|
|
||
|
|
||
| Summary for Shareholders | ||
| ---------------- | ||
|
|
||
| BitShares gateway technology is a relic of the past that is a marginal improvement on CEX technology. | ||
| In both cases you are trusting a third party to issue tokens. | ||
| XCLAIM tech can allow BitShares a means to interact securely with Bitcoin | ||
|
|
||
|
|
||
| Copyright | ||
| ---------------- | ||
|
|
||
| WTFPL 1765 | ||
|
|
||
| See Also | ||
| ---------------- | ||
|
|
||
|
|
||
| XCLAIM LIGHT PAPER | ||
|
|
||
| https://www.ieee-security.org/TC/SP2019/SP19-Slides-pdfs/Alexei_Zamyatin_-_02-Alexei_Zamyatin-XCLAIM_Trustless_Interoperable_Cryptocurrency-Backed_Assets.pdf | ||
|
|
||
| XCLAIM WHITE PAPER | ||
|
|
||
| https://eprint.iacr.org/2018/643.pdf | ||
|
|
||
| ANN POLKADOT BRIDGE | ||
|
|
||
| https://medium.com/interlay/interlay-receives-w3f-grant-to-build-trustless-btc-polkadot-bridge-c4bdb40173a3 | ||
|
|
||
| POLKABTC SPECIFICATION DOCS | ||
|
|
||
| https://interlay.gitlab.io/polkabtc-spec/ | ||
| https://gitlab.com/interlay/polkabtc-spec | ||
|
|
||
|
|
||
| contact@interlay.io | ||
|
|
||
| GIT | ||
|
|
||
| https://gitlab.com/interlay/btc-parachain | ||
|
|
||
| WEBSITE | ||
|
|
||
| https://www.interlay.io/ | ||
|
|
||
| BLOG | ||
|
|
||
| https://medium.com/interlay | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically, how to achieve "locking BTC on Bitcoin Mainnet"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
locking - in this sense - means Alice (vault client) has given Bob (vault operator) full possession of her BTC.
Bob is now contractually obliged to maintain (BTS) collateral on the issuing chain of vaultBTC.
As a precondition... Bob had set aside an amount of collateral that "could be locked" by a vault client.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
further reading:
https://interlay.gitlab.io/polkabtc-spec/spec/issue.html#requestissue
https://interlay.gitlab.io/polkabtc-spec/spec/issue.html#executeissue
I'm working on a full Alice/Bob thought experiment write up of the issue/redeem functionality.
I've probably made some misstatements, as my time is currently limited; hence "Draft".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My reading is Bob can only issue vaultBTC by locking up enough BTS so it's sort of like creating bitBTC and then selling it for BTC.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This hasn't worked out well for bitAssets in (BTS-)bear marekts in the past. Why would it work better for collateralizing off-chain assets? If you want to make it "secure" you need a high collateral ratio which makes this thing super capital in-efficient. The more volatile your collateral is, the worse this becomes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in theory - you could back a "polkaBTC" vault construct with honest.btc as easily as you could with core token.
now bob wants to be a vault operator; he buys honest.btc on the open market - he's not a borrower at all
now he puts up his - owned - honest.btc as collateral 1:1 and that rate stays pegged so long as honest.btc retains 1:1 value with real btc; his loan would never require any maintenance. the oracle of the peg could simply be the dex market price of honest.btc:bts vs the feed price of honest.btc:bts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
except that there is no way to sell bitBTC for BTC without an htlc arrangement or cex
here with polkaBTC bob has real BTC in hand after the tx and all accounting has been handled by the issuing chain (Bitshares) with awareness of bitcoin headers via a network of spv witness oracles.