BitShares Forum
Main => General Discussion => Topic started by: bitmarley on January 14, 2015, 05:10:22 am
-
OK I admit to not fully understanding bitshares so this post could be way off. If so sorry in advance! :/
OR this is crazzzzzy awesome man!! So... I think bitshares can do direct BTC exchanges.
Just like with Price Feeds, delegates can "price feed" a public bitcoin address.
So a BTS:BTC market could be managed trustlessly in the bitshares client like this:
1. The bitshares wallet is updated to include bitcoin wallet features.
2. A standard BTS market is created but BTC bids include the target bitcoin public address as meta-data.
3. Using the bitshares client a BTC holder can accept BTC bids and so the bitshares client broadcasts a bitcoin transaction encoded with their bitshares public address (and maybe the bid ID).
4. Since delegates have a "price feed" mechanism they can monitor the bitcoin public address and after 6 confirmations the delegates can safely process the BTC bidders side of the deal by releasing the BTS tied up by the bid to the bitshares public address encoded in the bitcoin transaction.
5. If the BTC bidder wants to cancel they would need to wait like 2 hours so delegates can make sure no bitcoin transaction is processing.
6. For BTC offers only the BTC holder can trigger the market transaction so BTC holders would need to be logged in to the bitshares client otherwise their offer would be grayed/suspended.
Sounds too good to be true. But I thought I should at least share the idea. :)
-
OK I admit to not fully understanding bitshares so this post could be way off. If so sorry in advance! :/
OR this is crazzzzzy awesome man!! So... I think bitshares can do direct BTC exchanges.
Just like with Price Feeds, delegates can "price feed" a public bitcoin address.
So a BTS:BTC market could be managed trustlessly in the bitshares client like this:
1. The bitshares wallet is updated to include bitcoin wallet features.
2. A standard BTS market is created but BTC bids include the target bitcoin public address as meta-data.
3. Using the bitshares client a BTC holder can accept BTC bids and so the bitshares client broadcasts a bitcoin transaction encoded with their bitshares public address (and maybe the bid ID).
4. Since delegates have a "price feed" mechanism they can monitor the bitcoin public address and after 6 confirmations the delegates can safely process the BTC bidders side of the deal by releasing the BTS tied up by the bid to the bitshares public address encoded in the bitcoin transaction.
5. If the BTC bidder wants to cancel they would need to wait like 2 hours so delegates can make sure no bitcoin transaction is processing.
6. For BTC offers only the BTC holder can trigger the market transaction so BTC holders would need to be logged in to the bitshares client otherwise their offer would be grayed/suspended.
Sounds too good to be true. But I thought I should at least share the idea. :)
Not exactly sure what you are describing but let me give you some more insights:
1) The crypto (ECC) of btc and bts are the same. So every private key in bts can also be calculated to represent a btc address. If you run wallet_account_list_public_keys on any of your bts accounts you will see this:
{
"hex": "0211e5700aea578ac8c8e2e5e0d6f484a21781ae20db431fc9150a6ca64903e36e",
"native_pubkey": "BTS52NVKZncXTQwm6gWsLXDvQ8WoG2TewBiiAJy4QUNkj7S4UWFQQ",
"native_address": "BTSVH3sgU3zb37D7fyrq4p9FYss3ySvxkzz",
"pts_normal_address": "Pm22jR1KKC2CSgjp5uWJbXymdr1y9CQEdS",
"pts_compressed_address": "Pt1Z7bF1xptsSxeYBKwXuHXaaSaVxGX1on",
"btc_normal_address": "1E6FbLKBZ658eQvxiQrTSWjiPbb9LM44kq",
"btc_compressed_address": "1M5myWYtCiwoegqgoqHgkGHXLC9gAhdR21"
}
those pts,bts, and btc addresses can all be access by the private key of ""BTS52NVKZncXTQwm6gWsLXDvQ8WoG2TewBiiAJy4QUNkj7S4UWFQQ".
2) forum member monsterer is currently building a BTC<->bitBTC gateway (read: bridge)
http://xchain.info/
That way you can send BTC to an address of the gateway and will receive bitBTC in the BTS-address that corresponds to your btc-sender address (at least that's what I think it does)
-
xchain isn't monsterers gateway, it's an independent project.
-
xchain isn't monsterers gateway, it's an independent project.
Oh ... thx for pointing it out ... too much happening lately ;)
-
Not exactly sure what you are describing but let me give you some more insights:
1) The crypto (ECC) of btc and bts are the same. So every private key in bts can also be calculated to represent a btc address. If you run wallet_account_list_public_keys on any of your bts accounts you will see this:
{
"hex": "0211e5700aea578ac8c8e2e5e0d6f484a21781ae20db431fc9150a6ca64903e36e",
"native_pubkey": "BTS52NVKZncXTQwm6gWsLXDvQ8WoG2TewBiiAJy4QUNkj7S4UWFQQ",
"native_address": "BTSVH3sgU3zb37D7fyrq4p9FYss3ySvxkzz",
"pts_normal_address": "Pm22jR1KKC2CSgjp5uWJbXymdr1y9CQEdS",
"pts_compressed_address": "Pt1Z7bF1xptsSxeYBKwXuHXaaSaVxGX1on",
"btc_normal_address": "1E6FbLKBZ658eQvxiQrTSWjiPbb9LM44kq",
"btc_compressed_address": "1M5myWYtCiwoegqgoqHgkGHXLC9gAhdR21"
}
those pts,bts, and btc addresses can all be access by the private key of ""BTS52NVKZncXTQwm6gWsLXDvQ8WoG2TewBiiAJy4QUNkj7S4UWFQQ".
2) forum member monsterer is currently building a BTC<->bitBTC gateway (read: bridge)
http://xchain.info/
That way you can send BTC to an address of the gateway and will receive bitBTC in the BTS-address that corresponds to your btc-sender address (at least that's what I think it does)
great. so it sounds like #1 #2 #3 #5 & #6 are possible in bitshares.
So what about #4, can delegates run code to verify that the bitshares created bitcoin transactions have been confirmed on the bitcoin blockchain?
-
Not exactly sure what you are describing but let me give you some more insights:
1) The crypto (ECC) of btc and bts are the same. So every private key in bts can also be calculated to represent a btc address. If you run wallet_account_list_public_keys on any of your bts accounts you will see this:
{
"hex": "0211e5700aea578ac8c8e2e5e0d6f484a21781ae20db431fc9150a6ca64903e36e",
"native_pubkey": "BTS52NVKZncXTQwm6gWsLXDvQ8WoG2TewBiiAJy4QUNkj7S4UWFQQ",
"native_address": "BTSVH3sgU3zb37D7fyrq4p9FYss3ySvxkzz",
"pts_normal_address": "Pm22jR1KKC2CSgjp5uWJbXymdr1y9CQEdS",
"pts_compressed_address": "Pt1Z7bF1xptsSxeYBKwXuHXaaSaVxGX1on",
"btc_normal_address": "1E6FbLKBZ658eQvxiQrTSWjiPbb9LM44kq",
"btc_compressed_address": "1M5myWYtCiwoegqgoqHgkGHXLC9gAhdR21"
}
those pts,bts, and btc addresses can all be access by the private key of ""BTS52NVKZncXTQwm6gWsLXDvQ8WoG2TewBiiAJy4QUNkj7S4UWFQQ".
2) forum member monsterer is currently building a BTC<->bitBTC gateway (read: bridge)
http://xchain.info/
That way you can send BTC to an address of the gateway and will receive bitBTC in the BTS-address that corresponds to your btc-sender address (at least that's what I think it does)
great. so it sounds like #1 #2 #3 #5 & #6 are possible in bitshares.
So what about #4, can delegates run code to verify that the bitshares created bitcoin transactions have been confirmed on the bitcoin blockchain?
With the upcoming multisig features no4 can also be done
-
Not exactly sure what you are describing but let me give you some more insights:
1) The crypto (ECC) of btc and bts are the same. So every private key in bts can also be calculated to represent a btc address. If you run wallet_account_list_public_keys on any of your bts accounts you will see this:
{
"hex": "0211e5700aea578ac8c8e2e5e0d6f484a21781ae20db431fc9150a6ca64903e36e",
"native_pubkey": "BTS52NVKZncXTQwm6gWsLXDvQ8WoG2TewBiiAJy4QUNkj7S4UWFQQ",
"native_address": "BTSVH3sgU3zb37D7fyrq4p9FYss3ySvxkzz",
"pts_normal_address": "Pm22jR1KKC2CSgjp5uWJbXymdr1y9CQEdS",
"pts_compressed_address": "Pt1Z7bF1xptsSxeYBKwXuHXaaSaVxGX1on",
"btc_normal_address": "1E6FbLKBZ658eQvxiQrTSWjiPbb9LM44kq",
"btc_compressed_address": "1M5myWYtCiwoegqgoqHgkGHXLC9gAhdR21"
}
those pts,bts, and btc addresses can all be access by the private key of ""BTS52NVKZncXTQwm6gWsLXDvQ8WoG2TewBiiAJy4QUNkj7S4UWFQQ".
2) forum member monsterer is currently building a BTC<->bitBTC gateway (read: bridge)
http://xchain.info/
That way you can send BTC to an address of the gateway and will receive bitBTC in the BTS-address that corresponds to your btc-sender address (at least that's what I think it does)
great. so it sounds like #1 #2 #3 #5 & #6 are possible in bitshares.
So what about #4, can delegates run code to verify that the bitshares created bitcoin transactions have been confirmed on the bitcoin blockchain?
With the upcoming multisig features no4 can also be done
How? Can you explain further, please.
-
I don't quite understand why multisig is useful here. I am thinking that Delegates can simply scan the bitcoin blockchain and find bitcoin transactions created by the bitshares client in step #3. When many(all?) delegates all verify the bitcoin transaction then they can release the corresponding BTS (or bitBTC or whatever).
-
I don't quite understand why multisig is useful here. I am thinking that Delegates can simply scan the bitcoin blockchain and find bitcoin transactions created by the bitshares client in step #3. When many(all?) delegates all verify the bitcoin transaction then they can release the corresponding BTS (or bitBTC or whatever).
Yes we could build bitcoin "state" into the assumed "known" state by all delegates. But why tie ourself to that baggage?
-
Yes we could build bitcoin "state" into the assumed "known" state by all delegates. But why tie ourself to that baggage?
So we don't need to trust BTC gateway operators. Bitshares could operate trustless bitcoin:bitBTC or bitcoin:BTS markets built right into the client. Indeed bitshares could do the same for any crypto. Is that worth the baggage?
-
I don't quite understand why multisig is useful here. I am thinking that Delegates can simply scan the bitcoin blockchain and find bitcoin transactions created by the bitshares client in step #3. When many(all?) delegates all verify the bitcoin transaction then they can release the corresponding BTS (or bitBTC or whatever).
Yes we could build bitcoin "state" into the assumed "known" state by all delegates. But why tie ourself to that baggage?
Sounds like you have a better plan to accomplish this, aren't you?