⭐ Merited by Vlad2Vlad (21)
Hey @bstr156, thank you for bringing some healthy dev speech to this thread. Btw, we are aware that our codebase has aged, so we need all help available! I wish to see more dev talk here!
- develCuy
You can contact markm and he will take your DVC tokens at his stellar address and send you blockchain devcoins into your DVC wallet. 1:1 ration of Stellar DVC tokens/DVC. I coordinated with him on the keybase.io chat by direct messaging him at "knotwork" because keybase has a built in wallet for Stellar and its tokens.
Dan, is it too difficult to implement that automatically in the system? Not a criticism, just genuinely asking.
That's very good!! I like that!
Last few times I looked for free open-source code for giving people tokens in return for coins there were two problems:
One, they claimed the code was not for production-use, that is, not actually hardened for real use;
Two, the code minted tokens on the fly to represent the supposedly-received coins, instead of only letting folks "buy" existing tokens already previously minted; that violates my only issue tokens for half my coins policy and also implies issuing tokens representing coins that are probably still in a "hot" wallet no yet actually frozen or buried safely away somewhere.
-MarkM-
No need to serve as a reserve custodian if it's a coin<->token two-way peg using a burn/mint process based on SPV. The proofs are the reserve. If you haven't already, check out Jag's work on Syscoin and how SYS<->SYSX operates between the native coin and the Syscoin Token Platform. Beyond that, from there you can do the same w/ SYSX (Syscoin Token) and get the SYSX (ERC-20). Then you can play in Ethereum's DeFi land if you want, or do whatever Ethereum people do.
It's live on the Syscoin mainnet.
For actual decentralized "DEX" you might also consider BlockNet's BlockDX. They are introducing a lot of improvements recently.
And what guarantees the peg will ALWAYS be 1:1?
It's network enforced that the quantity of the coins burned with `syscoinburntoassetallocation` is the quantity of the specific token to be minted (SYSX Asset: https://sys1.bcfn.ca/asset/1045909988). The SYSX token was provisioned as such, in part by having its entire max supply minted then immediately burned. None of that token is or could float around without having its 1:1 peg as the only way to mint those tokens in the first place (post-provisioning) is out of the token supply that has been burned (again, max supply burned) and that minting can only occur via `syscoinburntoassetallocation` accompanied by a burn of the native coin SYS.
oh, and token spec attribute "max supply" cannot be changed.
Works the same way going the other direction via `assetallocationburn`. The qty of SYSX burned is then re-minted as SYS out of that burned SYS supply pool. Only it isn't necessary to burn the entire supply of the native coin of course... burning the max supply is only necessary for provisioning on the token side.
Ok, so then whats the redundant need for a token for all these coins? Why not just use DVC, BSV, etc. why are they all adding a token which you have to swap the coin for the token? It doesnt seem necessary since you can just as easily spend the coin itself.
It's part of giving sovereign owners means that are permissionless and trust-minimized to enable their existing value with new use cases, services, and immediately-ideal characteristics (in areas like transactionality, security, programmability) - options that aren't available when the value is stuck on its original platform. In a word, Interoperability - without using trading mechanisms nor depending on liquidity providers.
Token platforms are conducive to cross-chain integrations like this, especially those that offer programmability like Ethereum in which case a clear path to mutual chain awareness is established. We've accomplished this between Ethereum ERC-20 and Syscoin Platform Tokens using a notion of superblocks... similar to the early Dogethereum idea, but expanded and fleshed-out quite a bit more to the point of actually being production ready and live on a mainnet. ERC-20s can cross to a Syscoin (learn about Syscoin Bridge: https://syscoin.readme.io/docs/what-is-sysethereum-bridge-how-does-it-work) after which they exist as a token on a platform that provides improved means-of-exchange (fast, low-cost microtransactions and scalability - Learn about Z-DAG: https://syscoin.org/news/what-is-z-dag.) - and proven store-of-value which might be particularly important if Ethereum shifts to proof-of-stake. The other side of the coin is that all existing Syscoin Platform Tokens, including SYSX value which is pegged to the native coin SYS, can access Ethereum and all it has to offer ERC-20s.
For interop w/ platforms that don't offer programmability we are exploring ZKP as a way of generalizing the functionality of our bridge.
A shorter way of answering would just be "The reason is the same general idea in what MarkM is doing w/ Stellar, but our path is trust-minimized, permissionless and doesn't involve a token swap where there are reserve tokens in another human's wallet however good their intentions might be"
MarkM, you could integrate assets quite easily for Galactic Milieu. Check out our github when you have time.
- develCuy
You can contact markm and he will take your DVC tokens at his stellar address and send you blockchain devcoins into your DVC wallet. 1:1 ration of Stellar DVC tokens/DVC. I coordinated with him on the keybase.io chat by direct messaging him at "knotwork" because keybase has a built in wallet for Stellar and its tokens.
Dan, is it too difficult to implement that automatically in the system? Not a criticism, just genuinely asking.
Also Stellar is an open network, good place for DVC to move in and out of as it builds up value per each unit. Not about dollars anymore.
That's very good!! I like that!
Last few times I looked for free open-source code for giving people tokens in return for coins there were two problems:
One, they claimed the code was not for production-use, that is, not actually hardened for real use;
Two, the code minted tokens on the fly to represent the supposedly-received coins, instead of only letting folks "buy" existing tokens already previously minted; that violates my only issue tokens for half my coins policy and also implies issuing tokens representing coins that are probably still in a "hot" wallet no yet actually frozen or buried safely away somewhere.
-MarkM-
No need to serve as a reserve custodian if it's a coin<->token two-way peg using a burn/mint process based on SPV. The proofs are the reserve. If you haven't already, check out Jag's work on Syscoin and how SYS<->SYSX operates between the native coin and the Syscoin Token Platform. Beyond that, from there you can do the same w/ SYSX (Syscoin Token) and get the SYSX (ERC-20). Then you can play in Ethereum's DeFi land if you want, or do whatever Ethereum people do.
It's live on the Syscoin mainnet.
For actual decentralized "DEX" you might also consider BlockNet's BlockDX. They are introducing a lot of improvements recently.
And what guarantees the peg will ALWAYS be 1:1?
It's network enforced that the quantity of the coins burned with `syscoinburntoassetallocation` is the quantity of the specific token to be minted (SYSX Asset: https://sys1.bcfn.ca/asset/1045909988). The SYSX token was provisioned as such, in part by having its entire max supply minted then immediately burned. None of that token is or could float around without having its 1:1 peg as the only way to mint those tokens in the first place (post-provisioning) is out of the token supply that has been burned (again, max supply burned) and that minting can only occur via `syscoinburntoassetallocation` accompanied by a burn of the native coin SYS.
oh, and token spec attribute "max supply" cannot be changed.
Works the same way going the other direction via `assetallocationburn`. The qty of SYSX burned is then re-minted as SYS out of that burned SYS supply pool. Only it isn't necessary to burn the entire supply of the native coin of course... burning the max supply is only necessary for provisioning on the token side.
Ok, so then whats the redundant need for a token for all these coins? Why not just use DVC, BSV, etc. why are they all adding a token which you have to swap the coin for the token? It doesnt seem necessary since you can just as easily spend the coin itself.
It's part of giving sovereign owners means that are permissionless and trust-minimized to enable their existing value with new use cases, services, and immediately-ideal characteristics (in areas like transactionality, security, programmability) - options that aren't available when the value is stuck on its original platform. In a word, Interoperability - without using trading mechanisms nor depending on liquidity providers.
Token platforms are conducive to cross-chain integrations like this, especially those that offer programmability like Ethereum in which case a clear path to mutual chain awareness is established. We've accomplished this between Ethereum ERC-20 and Syscoin Platform Tokens using a notion of superblocks... similar to the early Dogethereum idea, but expanded and fleshed-out quite a bit more to the point of actually being production ready and live on a mainnet. ERC-20s can cross to a Syscoin (learn about Syscoin Bridge: https://syscoin.readme.io/docs/what-is-sysethereum-bridge-how-does-it-work) after which they exist as a token on a platform that provides improved means-of-exchange (fast, low-cost microtransactions and scalability - Learn about Z-DAG: https://syscoin.org/news/what-is-z-dag.) - and proven store-of-value which might be particularly important if Ethereum shifts to proof-of-stake. The other side of the coin is that all existing Syscoin Platform Tokens, including SYSX value which is pegged to the native coin SYS, can access Ethereum and all it has to offer ERC-20s.
For interop w/ platforms that don't offer programmability we are exploring ZKP as a way of generalizing the functionality of our bridge.
A shorter way of answering would just be "The reason is the same general idea in what MarkM is doing w/ Stellar, but our path is trust-minimized, permissionless and doesn't involve a token swap where there are reserve tokens in another human's wallet however good their intentions might be"
MarkM, you could integrate assets quite easily for Galactic Milieu. Check out our github when you have time.
Not just that, the CEO and founder of Blockchain Foundry and lead of Syscoin is former devcoin developer sidhujag
He seems to have bookmarked a place for us to come back to the future and evolve as we've planned for some time https://github.com/devcoin/core/commit/cf3e03bad10368d96294769b740841919b636810
Quote
Fix conflicting bitcoin counterparty conflict merge
Bitcoin reduced the tx return data bytes by half effectively cutting off
counterparty compatibility with 0.9.x see:
http://www.coindesk.com/developers-battle-bitcoin-block-chain/
This is to revert the bitcoin change so that we may one day support
counterparty, blockchain services and smart contracts
devcoin0.9.2
@sidhujag
sidhujag committed on Aug 7, 2014
Bitcoin reduced the tx return data bytes by half effectively cutting off
counterparty compatibility with 0.9.x see:
http://www.coindesk.com/developers-battle-bitcoin-block-chain/
This is to revert the bitcoin change so that we may one day support
counterparty, blockchain services and smart contracts
devcoin0.9.2
@sidhujag
sidhujag committed on Aug 7, 2014
Let's go for it