0 Members and 1 Guest are viewing this topic.
I always feel it will be better to be able to set proxy separately for witness
Quote from: Chronos on June 07, 2016, 05:28:54 pmQuote from: crypto4ever on June 07, 2016, 05:17:43 pmSo my question is, does a comprehensive and up to date video like this exist? If not, why not?Ironically, you have to vote to make it happen. Which is a real problem. More than it being a ironic situation, it's a real sick situation.
Quote from: crypto4ever on June 07, 2016, 05:17:43 pmSo my question is, does a comprehensive and up to date video like this exist? If not, why not?Ironically, you have to vote to make it happen.
So my question is, does a comprehensive and up to date video like this exist? If not, why not?
Quote from: Chronos on June 07, 2016, 05:28:54 pmQuote from: crypto4ever on June 07, 2016, 05:17:43 pmSo my question is, does a comprehensive and up to date video like this exist? If not, why not?Ironically, you have to vote to make it happen. Which is a real problem. More than it being a ironic situation, it's a real sick situation.These are key elements of the Bitshares system, and part of the launch, these needed to be already prepared before letting this system into the wild.You don't build a system, and hope that people will figure out how to use it.
Quote from: bitcrab on June 06, 2016, 12:46:38 pmis it possible to add some economic incentive for voting? for example is it possible to give voters some reward when the voted witness generate a new block? even a little reward can encourage voting.Thought experiment:Suppose every account had a knob we could turn increasing their pay until they were incentivized to take the time to vote.One would assume that at that price they are still not incentivized to take the time to become suitably informed to vote.
is it possible to add some economic incentive for voting? for example is it possible to give voters some reward when the voted witness generate a new block? even a little reward can encourage voting.
Quote from: Stan on January 06, 2016, 03:42:03 pmQuote from: CoinHoarder on January 06, 2016, 02:51:51 pmdPoS will continue to be broken as long as there is no incentive to vote or penalty for not voting. At this point, I think the only way to fix it is by providing a penalty if you don't vote every so often, then your stake should be confiscated by the blockchain and burned. Kind of off topic from OP.. my bad.So, to avoid penalty or earn incentives, former non-voters would just vote randomly without thinking."Too lazy to vote, too lazy to think about a coerced vote."Result: there are now a bunch of random votes blocking new decisions and making it hard for dedicated thinkers to respond quickly when issues do arise. Therefore the project wanders adrift at sea without a rudder.How would that do anything but harm?BTS shareholders (or shareholders in any company) have made a capital investment in the future of that company. Unlike centralized companies that require a vote as little as once per year, A decentralized company requires shareholders to engage in frequent voting which requires additional 'work' & as Bytemaster correctly states in his latest blog imo... QuoteMany people vote once and then forget to change their vote or they vote for a proxy and then forget to follow up. The usual end result is that it becomes difficult to vote out incumbents or vote in new individuals. The presence of voter apathy is a sign that incentives are not properly aligned in the system.http://bytemaster.github.io/article/2016/01/04/The-Benefits-of-Proof-of-Work/By incentivising voting and penalising non voting you are aligning incentives so that the small BTS shareholders are now paid for the additional 'work' and as they are BTS shareholders who have made a capital commitment to the success of the project, it is likely the majority of votes will not be random but considered.Imo, either the majority of small BTS shareholders will vote responsibly if given an incentive & if not, then it means BTS is the most insecure blockchain on the planet and can be attacked with 0.05% of BTS.https://bitsharestalk.org/index.php/topic,20724.msg267990.html#msg267990
Quote from: CoinHoarder on January 06, 2016, 02:51:51 pmdPoS will continue to be broken as long as there is no incentive to vote or penalty for not voting. At this point, I think the only way to fix it is by providing a penalty if you don't vote every so often, then your stake should be confiscated by the blockchain and burned. Kind of off topic from OP.. my bad.So, to avoid penalty or earn incentives, former non-voters would just vote randomly without thinking."Too lazy to vote, too lazy to think about a coerced vote."Result: there are now a bunch of random votes blocking new decisions and making it hard for dedicated thinkers to respond quickly when issues do arise. Therefore the project wanders adrift at sea without a rudder.How would that do anything but harm?
dPoS will continue to be broken as long as there is no incentive to vote or penalty for not voting. At this point, I think the only way to fix it is by providing a penalty if you don't vote every so often, then your stake should be confiscated by the blockchain and burned. Kind of off topic from OP.. my bad.
Many people vote once and then forget to change their vote or they vote for a proxy and then forget to follow up. The usual end result is that it becomes difficult to vote out incumbents or vote in new individuals. The presence of voter apathy is a sign that incentives are not properly aligned in the system.
Quote from: bitcrab on June 06, 2016, 12:46:38 pmis it possible to add some economic incentive for voting? for example is it possible to give voters some reward when the voted witness generate a new block? even a little reward can encourage voting.Thought experiment:Suppose every account had a knob we could turn increasing their pay until they were incentivized to take the time to vote.One would assume that at that price they are still not incentivized to take the time to become suitably informed to vote.So at this point, their vote is just a random variable reflecting lack of information or, worse, just the easily available disinformation. We could generate such uninformed, random votes automatically at much lower cost.Why would we pay to inject their human generated equivalent into the system?How much higher would you have to turn the dial to get them to study everything they need to know to vote wisely?How would you prove they had actually done that work to earn the higher pay rate?
TL;DR Don't know whether this be considered in the thread yet: If we want to automatically have top 15 witnesses multi-sig the BTC wallet, we need to improve voting participation first, otherwise for example btc38 would be able to steal the fund easily.
Becoming bitcoin or ethereum sidechain, bitshares could be used for Augur application. That could improve liquidity very much. Any news on starting a sidechain project?
Would being a bitcoin / ethereum sidechain reduce bitshares security?If the value of btc held in multisig by witnesses becomes significant compared to their stake in bitshares, wouldn't they have the incentive to collude and take the btc and other possible coins like eth.
Quote from: BunkerChain Labs on February 13, 2016, 12:20:55 amQuote from: tbone on February 12, 2016, 11:40:39 pmQuote from: BunkerChain Labs on February 12, 2016, 08:49:56 pmQuote from: tbone on February 12, 2016, 05:58:47 pmQuote from: bytemaster on February 12, 2016, 05:50:00 pmQuote from: tbone on February 12, 2016, 05:42:21 pm@bytemaster:Just wanted to resurrect the sidechain thread with an idea/question. Since there's risk (perhaps intolerable risk) of collusion associated with witnesses signing off on transfers to a multi-sig BTC wallet, would it be possible for the BTS blockchain to hold the private key for such a BTC wallet and automatically make transfers out of it (and into a user's individual BTC wallet) whenever a user sells their SIDE.BTC on the DEX? It is possible to do secure multi-party computation among the witnesses. Doesn't prevent collusion of witnesses though.https://en.wikipedia.org/wiki/Secure_multi-party_computationSo is it not possible for the Bitshares blockchain to hold the private key for the common wallet and automate the transfers so witnesses don't need to be involved?You want to do it with witnesses since they are elected by shareholders.There are ways that collusion could be minimized. I'm trying to get at a way to do this without human involvement, otherwise I think it just won't be trusted. Plus how would it work, witnesses would have to manually approve each transaction? I don't see that as a viable solution. And I think there's a better way.@bytemaster: Couldn't you write some code into graphene that would utilize, for example, the blockchain.info API to create a Bitcoin wallet for the DEX, and store the returned private key on the blockchain? So first the straightforward part: when someone wants to transfer BTC to the DEX, they send BTC to a designated BTC address and then the blockchain automatically issues them the corresponding amount of SIDE.BTC on the DEX. Then the trickier part, when they are ready to withdraw, they surrender their SIDE.BTC and the blockchain uses the private key it stored previously in order to send the appropriate sum of BTC to the user's designated external BTC wallet. Is this not possible? @abit, do you have any thoughts about this?It's trusted just fine with how other networks do this.. only they are using a handful of bitcoin exchanges .. far less secure that what we are proposing: http://www.coindesk.com/blockstream-commercial-sidechain-bitcoin-exchanges/This is the only practical means to executing... that's what they came up with with $21 million to work with. You think we can do better? What you described is essentially what the witnesses would be done.. but your recommendation introduces more threats.It would not be manual it would all be automatic and would have witnesses ensuring that the nodes are operating as optimal as possible for Bitshares vs. other networks that wouldn't care, and might not have any redundancy like we would have with the witnesses. DPOS means trusting humans to maintain and keep things working right. If they don't, they get voted out. Multi-sig for bitcoin wallets is limited to a maximum of 15 I believe. If we had all witnesses participating but had an algo that changed the multi-sig assignments in some type of interval configuration it would require basically all witnesses to agree to steel all the bitcoin. Note that this would be far more secure than Liquid.. they got $21m for that.. we should at least get that in added valuation for Bitshares if not more. I have said this all before, maybe it was in Telegram.I'm sorry, but you can't compare this to Liquid. Liquid is a federated sidechain of centralized services (BitFinex, Kraken, BTCC, Xapo, Unocoin). To begin with, the users of these services have to trust those companies. On top of that, the Liquid sidechain depends on the participating companies trusting each other. So you really can't compare that to what we're trying to accomplish here.By the way, it looks like you modified your post before I got a chance to respond. But since you were wondering why I wasn't taking your explanation at face value, it's because you're not the expert. So I continue to address @bytemaster with my questions since he IS the expert. And I asked for @abit's opinion since he is a developer and, for all we know, he could be the one to code this up ultimately. Surely you can understand where I'm coming from. In any event, I'm really not sure, but something tells me that what I'm proposing is very much doable. It would be great if @bytemaster would speak to it specifically. If it can't be done, please explain why. Thanks!
Quote from: tbone on February 12, 2016, 11:40:39 pmQuote from: BunkerChain Labs on February 12, 2016, 08:49:56 pmQuote from: tbone on February 12, 2016, 05:58:47 pmQuote from: bytemaster on February 12, 2016, 05:50:00 pmQuote from: tbone on February 12, 2016, 05:42:21 pm@bytemaster:Just wanted to resurrect the sidechain thread with an idea/question. Since there's risk (perhaps intolerable risk) of collusion associated with witnesses signing off on transfers to a multi-sig BTC wallet, would it be possible for the BTS blockchain to hold the private key for such a BTC wallet and automatically make transfers out of it (and into a user's individual BTC wallet) whenever a user sells their SIDE.BTC on the DEX? It is possible to do secure multi-party computation among the witnesses. Doesn't prevent collusion of witnesses though.https://en.wikipedia.org/wiki/Secure_multi-party_computationSo is it not possible for the Bitshares blockchain to hold the private key for the common wallet and automate the transfers so witnesses don't need to be involved?You want to do it with witnesses since they are elected by shareholders.There are ways that collusion could be minimized. I'm trying to get at a way to do this without human involvement, otherwise I think it just won't be trusted. Plus how would it work, witnesses would have to manually approve each transaction? I don't see that as a viable solution. And I think there's a better way.@bytemaster: Couldn't you write some code into graphene that would utilize, for example, the blockchain.info API to create a Bitcoin wallet for the DEX, and store the returned private key on the blockchain? So first the straightforward part: when someone wants to transfer BTC to the DEX, they send BTC to a designated BTC address and then the blockchain automatically issues them the corresponding amount of SIDE.BTC on the DEX. Then the trickier part, when they are ready to withdraw, they surrender their SIDE.BTC and the blockchain uses the private key it stored previously in order to send the appropriate sum of BTC to the user's designated external BTC wallet. Is this not possible? @abit, do you have any thoughts about this?It's trusted just fine with how other networks do this.. only they are using a handful of bitcoin exchanges .. far less secure that what we are proposing: http://www.coindesk.com/blockstream-commercial-sidechain-bitcoin-exchanges/This is the only practical means to executing... that's what they came up with with $21 million to work with. You think we can do better? What you described is essentially what the witnesses would be done.. but your recommendation introduces more threats.It would not be manual it would all be automatic and would have witnesses ensuring that the nodes are operating as optimal as possible for Bitshares vs. other networks that wouldn't care, and might not have any redundancy like we would have with the witnesses. DPOS means trusting humans to maintain and keep things working right. If they don't, they get voted out. Multi-sig for bitcoin wallets is limited to a maximum of 15 I believe. If we had all witnesses participating but had an algo that changed the multi-sig assignments in some type of interval configuration it would require basically all witnesses to agree to steel all the bitcoin. Note that this would be far more secure than Liquid.. they got $21m for that.. we should at least get that in added valuation for Bitshares if not more. I have said this all before, maybe it was in Telegram.
Quote from: BunkerChain Labs on February 12, 2016, 08:49:56 pmQuote from: tbone on February 12, 2016, 05:58:47 pmQuote from: bytemaster on February 12, 2016, 05:50:00 pmQuote from: tbone on February 12, 2016, 05:42:21 pm@bytemaster:Just wanted to resurrect the sidechain thread with an idea/question. Since there's risk (perhaps intolerable risk) of collusion associated with witnesses signing off on transfers to a multi-sig BTC wallet, would it be possible for the BTS blockchain to hold the private key for such a BTC wallet and automatically make transfers out of it (and into a user's individual BTC wallet) whenever a user sells their SIDE.BTC on the DEX? It is possible to do secure multi-party computation among the witnesses. Doesn't prevent collusion of witnesses though.https://en.wikipedia.org/wiki/Secure_multi-party_computationSo is it not possible for the Bitshares blockchain to hold the private key for the common wallet and automate the transfers so witnesses don't need to be involved?You want to do it with witnesses since they are elected by shareholders.There are ways that collusion could be minimized. I'm trying to get at a way to do this without human involvement, otherwise I think it just won't be trusted. Plus how would it work, witnesses would have to manually approve each transaction? I don't see that as a viable solution. And I think there's a better way.@bytemaster: Couldn't you write some code into graphene that would utilize, for example, the blockchain.info API to create a Bitcoin wallet for the DEX, and store the returned private key on the blockchain? So first the straightforward part: when someone wants to transfer BTC to the DEX, they send BTC to a designated BTC address and then the blockchain automatically issues them the corresponding amount of SIDE.BTC on the DEX. Then the trickier part, when they are ready to withdraw, they surrender their SIDE.BTC and the blockchain uses the private key it stored previously in order to send the appropriate sum of BTC to the user's designated external BTC wallet. Is this not possible? @abit, do you have any thoughts about this?
Quote from: tbone on February 12, 2016, 05:58:47 pmQuote from: bytemaster on February 12, 2016, 05:50:00 pmQuote from: tbone on February 12, 2016, 05:42:21 pm@bytemaster:Just wanted to resurrect the sidechain thread with an idea/question. Since there's risk (perhaps intolerable risk) of collusion associated with witnesses signing off on transfers to a multi-sig BTC wallet, would it be possible for the BTS blockchain to hold the private key for such a BTC wallet and automatically make transfers out of it (and into a user's individual BTC wallet) whenever a user sells their SIDE.BTC on the DEX? It is possible to do secure multi-party computation among the witnesses. Doesn't prevent collusion of witnesses though.https://en.wikipedia.org/wiki/Secure_multi-party_computationSo is it not possible for the Bitshares blockchain to hold the private key for the common wallet and automate the transfers so witnesses don't need to be involved?You want to do it with witnesses since they are elected by shareholders.There are ways that collusion could be minimized.
Quote from: bytemaster on February 12, 2016, 05:50:00 pmQuote from: tbone on February 12, 2016, 05:42:21 pm@bytemaster:Just wanted to resurrect the sidechain thread with an idea/question. Since there's risk (perhaps intolerable risk) of collusion associated with witnesses signing off on transfers to a multi-sig BTC wallet, would it be possible for the BTS blockchain to hold the private key for such a BTC wallet and automatically make transfers out of it (and into a user's individual BTC wallet) whenever a user sells their SIDE.BTC on the DEX? It is possible to do secure multi-party computation among the witnesses. Doesn't prevent collusion of witnesses though.https://en.wikipedia.org/wiki/Secure_multi-party_computationSo is it not possible for the Bitshares blockchain to hold the private key for the common wallet and automate the transfers so witnesses don't need to be involved?
Quote from: tbone on February 12, 2016, 05:42:21 pm@bytemaster:Just wanted to resurrect the sidechain thread with an idea/question. Since there's risk (perhaps intolerable risk) of collusion associated with witnesses signing off on transfers to a multi-sig BTC wallet, would it be possible for the BTS blockchain to hold the private key for such a BTC wallet and automatically make transfers out of it (and into a user's individual BTC wallet) whenever a user sells their SIDE.BTC on the DEX? It is possible to do secure multi-party computation among the witnesses. Doesn't prevent collusion of witnesses though.https://en.wikipedia.org/wiki/Secure_multi-party_computation
@bytemaster:Just wanted to resurrect the sidechain thread with an idea/question. Since there's risk (perhaps intolerable risk) of collusion associated with witnesses signing off on transfers to a multi-sig BTC wallet, would it be possible for the BTS blockchain to hold the private key for such a BTC wallet and automatically make transfers out of it (and into a user's individual BTC wallet) whenever a user sells their SIDE.BTC on the DEX?
Would like to see a blog post from @bytemaster on this!
Quote from: TravelsAsia on February 18, 2016, 04:01:21 pmQuote from: noisy on February 18, 2016, 02:31:48 pmAs far as I know, wallets are mostly opensource. That means, that we should provide such feature in a pull request.Thank you for the reply, let me phrase it slightly differently. Could the wallets profit from BitShares transactions if they add it to their wallet? With such as small user base, I was trying to figure out if wallet developers would have any incentive to support it. Also, how would that support directly benefit BitShares?As support of another blockchain in wallet require additional effort from wallet developer I would not be surprised if they will add some additional transaction fee to it. I would not be agains it, as long as they will be relatively low. Additional source of income is a very good reason to develop a support for that
Quote from: noisy on February 18, 2016, 02:31:48 pmAs far as I know, wallets are mostly opensource. That means, that we should provide such feature in a pull request.Thank you for the reply, let me phrase it slightly differently. Could the wallets profit from BitShares transactions if they add it to their wallet? With such as small user base, I was trying to figure out if wallet developers would have any incentive to support it. Also, how would that support directly benefit BitShares?
As far as I know, wallets are mostly opensource. That means, that we should provide such feature in a pull request.
I'd be excited to have a conversation with Daniel or someone else from the BitShares team if they express any interest at all in pursuing this idea.
Hey guys, Eric Martindale with Blockstream here.
Quote from: Akado on February 18, 2016, 07:38:59 am@fuzzy this is a cool idea for a hangout!would love to. @martindale would you be interested in joining us in a community hangout at some point?
@fuzzy this is a cool idea for a hangout!
Quote from: complexring on February 14, 2016, 05:35:09 pmQuote from: tbone on February 14, 2016, 09:37:26 amQuote from: cube on February 14, 2016, 03:58:44 amQuote from: tbone on February 13, 2016, 07:02:52 pmQuote from: abit on February 13, 2016, 05:19:45 pmQuote from: tbone on February 13, 2016, 03:56:18 pmBy the way, it looks like you modified your post before I got a chance to respond. But since you were wondering why I wasn't taking your explanation at face value, it's because you're not the expert. So I continue to address @bytemaster with my questions since he IS the expert. And I asked for @abit's opinion since he is a developer and, for all we know, he could be the one to code this up ultimately. Surely you can understand where I'm coming from. Thanks for trusting me, but sorry, I'm not a bitcoin expert, I don't know how to deal with the bitcoin multi-sig thing at all.@abit: This is a Bitshares question, not a bitcoin question. It's also not a multi-sig question. Let me ask in a different way. Could you write code in Bitshares that calls an external API which returns a value that could then be stored securely (i.e. not accessible to any human) on the Bitshares blockchain to be used by the code at a later time? I would imagine this is possible, but could you confirm?Yes, it is possible and doable. There is a way to make RPC call to bitcoin to monitor the blockchain for incoming fund for example. Once there is a value returned, it needs to be stored encrypted in the blockchain. I think pc is thinking of a new function to store data securely in bts blockchain.Great. So we can make remote procedure calls to the blockchain.info API, for example, to programatically create a bitcoin wallet, correct? Calling the create_wallet method of that API returns the new wallet's private key, which could then be stored encrypted on the Bitshares blockchain. So now we have a wallet that is controlled by the Bitshares blockchain and can hold BTC deposits for DEX users. When a user deposits BTC to this wallet, they are issued a corresponding amount of SIDE.BTC which can be used on the DEX. Later, when a user is ready to withdraw, any remaining SIDE.BTC is wiped from their account and BTC in an amount equal to the quantity of SIDE.BTC the user had remaining can be sent to a bitcoin wallet of their choice. If I'm not mistaken about the feasability, this solution would serve our purpose, it's trustless, and it shouldn't be very difficult to implement not only for BTC, but for any cryptocurrency that has an api with a create wallet method. Thoughts? Am I missing something?@bytemaster @cube @abitSo, if the private key is stored encrypted on the blockain, who controls the private key to decrypt the private key that's stored?Indeed. I don't think this is actually possible. Data stored on the blockchain is accessible to everyone either in plaintext or encrypted. If it's encrypted it's useless unless someone has the decryption key stored somewhere. You cannot store a private key on a public blockchain that is usable by the chain but not by any set of individuals without the chain, because the blockchain itself isn't a real actor; it's a virtual entity composed of participants following its rules.
Quote from: tbone on February 14, 2016, 09:37:26 amQuote from: cube on February 14, 2016, 03:58:44 amQuote from: tbone on February 13, 2016, 07:02:52 pmQuote from: abit on February 13, 2016, 05:19:45 pmQuote from: tbone on February 13, 2016, 03:56:18 pmBy the way, it looks like you modified your post before I got a chance to respond. But since you were wondering why I wasn't taking your explanation at face value, it's because you're not the expert. So I continue to address @bytemaster with my questions since he IS the expert. And I asked for @abit's opinion since he is a developer and, for all we know, he could be the one to code this up ultimately. Surely you can understand where I'm coming from. Thanks for trusting me, but sorry, I'm not a bitcoin expert, I don't know how to deal with the bitcoin multi-sig thing at all.@abit: This is a Bitshares question, not a bitcoin question. It's also not a multi-sig question. Let me ask in a different way. Could you write code in Bitshares that calls an external API which returns a value that could then be stored securely (i.e. not accessible to any human) on the Bitshares blockchain to be used by the code at a later time? I would imagine this is possible, but could you confirm?Yes, it is possible and doable. There is a way to make RPC call to bitcoin to monitor the blockchain for incoming fund for example. Once there is a value returned, it needs to be stored encrypted in the blockchain. I think pc is thinking of a new function to store data securely in bts blockchain.Great. So we can make remote procedure calls to the blockchain.info API, for example, to programatically create a bitcoin wallet, correct? Calling the create_wallet method of that API returns the new wallet's private key, which could then be stored encrypted on the Bitshares blockchain. So now we have a wallet that is controlled by the Bitshares blockchain and can hold BTC deposits for DEX users. When a user deposits BTC to this wallet, they are issued a corresponding amount of SIDE.BTC which can be used on the DEX. Later, when a user is ready to withdraw, any remaining SIDE.BTC is wiped from their account and BTC in an amount equal to the quantity of SIDE.BTC the user had remaining can be sent to a bitcoin wallet of their choice. If I'm not mistaken about the feasability, this solution would serve our purpose, it's trustless, and it shouldn't be very difficult to implement not only for BTC, but for any cryptocurrency that has an api with a create wallet method. Thoughts? Am I missing something?@bytemaster @cube @abitSo, if the private key is stored encrypted on the blockain, who controls the private key to decrypt the private key that's stored?
Quote from: cube on February 14, 2016, 03:58:44 amQuote from: tbone on February 13, 2016, 07:02:52 pmQuote from: abit on February 13, 2016, 05:19:45 pmQuote from: tbone on February 13, 2016, 03:56:18 pmBy the way, it looks like you modified your post before I got a chance to respond. But since you were wondering why I wasn't taking your explanation at face value, it's because you're not the expert. So I continue to address @bytemaster with my questions since he IS the expert. And I asked for @abit's opinion since he is a developer and, for all we know, he could be the one to code this up ultimately. Surely you can understand where I'm coming from. Thanks for trusting me, but sorry, I'm not a bitcoin expert, I don't know how to deal with the bitcoin multi-sig thing at all.@abit: This is a Bitshares question, not a bitcoin question. It's also not a multi-sig question. Let me ask in a different way. Could you write code in Bitshares that calls an external API which returns a value that could then be stored securely (i.e. not accessible to any human) on the Bitshares blockchain to be used by the code at a later time? I would imagine this is possible, but could you confirm?Yes, it is possible and doable. There is a way to make RPC call to bitcoin to monitor the blockchain for incoming fund for example. Once there is a value returned, it needs to be stored encrypted in the blockchain. I think pc is thinking of a new function to store data securely in bts blockchain.Great. So we can make remote procedure calls to the blockchain.info API, for example, to programatically create a bitcoin wallet, correct? Calling the create_wallet method of that API returns the new wallet's private key, which could then be stored encrypted on the Bitshares blockchain. So now we have a wallet that is controlled by the Bitshares blockchain and can hold BTC deposits for DEX users. When a user deposits BTC to this wallet, they are issued a corresponding amount of SIDE.BTC which can be used on the DEX. Later, when a user is ready to withdraw, any remaining SIDE.BTC is wiped from their account and BTC in an amount equal to the quantity of SIDE.BTC the user had remaining can be sent to a bitcoin wallet of their choice. If I'm not mistaken about the feasability, this solution would serve our purpose, it's trustless, and it shouldn't be very difficult to implement not only for BTC, but for any cryptocurrency that has an api with a create wallet method. Thoughts? Am I missing something?@bytemaster @cube @abit
Quote from: tbone on February 13, 2016, 07:02:52 pmQuote from: abit on February 13, 2016, 05:19:45 pmQuote from: tbone on February 13, 2016, 03:56:18 pmBy the way, it looks like you modified your post before I got a chance to respond. But since you were wondering why I wasn't taking your explanation at face value, it's because you're not the expert. So I continue to address @bytemaster with my questions since he IS the expert. And I asked for @abit's opinion since he is a developer and, for all we know, he could be the one to code this up ultimately. Surely you can understand where I'm coming from. Thanks for trusting me, but sorry, I'm not a bitcoin expert, I don't know how to deal with the bitcoin multi-sig thing at all.@abit: This is a Bitshares question, not a bitcoin question. It's also not a multi-sig question. Let me ask in a different way. Could you write code in Bitshares that calls an external API which returns a value that could then be stored securely (i.e. not accessible to any human) on the Bitshares blockchain to be used by the code at a later time? I would imagine this is possible, but could you confirm?Yes, it is possible and doable. There is a way to make RPC call to bitcoin to monitor the blockchain for incoming fund for example. Once there is a value returned, it needs to be stored encrypted in the blockchain. I think pc is thinking of a new function to store data securely in bts blockchain.
Quote from: abit on February 13, 2016, 05:19:45 pmQuote from: tbone on February 13, 2016, 03:56:18 pmBy the way, it looks like you modified your post before I got a chance to respond. But since you were wondering why I wasn't taking your explanation at face value, it's because you're not the expert. So I continue to address @bytemaster with my questions since he IS the expert. And I asked for @abit's opinion since he is a developer and, for all we know, he could be the one to code this up ultimately. Surely you can understand where I'm coming from. Thanks for trusting me, but sorry, I'm not a bitcoin expert, I don't know how to deal with the bitcoin multi-sig thing at all.@abit: This is a Bitshares question, not a bitcoin question. It's also not a multi-sig question. Let me ask in a different way. Could you write code in Bitshares that calls an external API which returns a value that could then be stored securely (i.e. not accessible to any human) on the Bitshares blockchain to be used by the code at a later time? I would imagine this is possible, but could you confirm?
Quote from: tbone on February 13, 2016, 03:56:18 pmBy the way, it looks like you modified your post before I got a chance to respond. But since you were wondering why I wasn't taking your explanation at face value, it's because you're not the expert. So I continue to address @bytemaster with my questions since he IS the expert. And I asked for @abit's opinion since he is a developer and, for all we know, he could be the one to code this up ultimately. Surely you can understand where I'm coming from. Thanks for trusting me, but sorry, I'm not a bitcoin expert, I don't know how to deal with the bitcoin multi-sig thing at all.
By the way, it looks like you modified your post before I got a chance to respond. But since you were wondering why I wasn't taking your explanation at face value, it's because you're not the expert. So I continue to address @bytemaster with my questions since he IS the expert. And I asked for @abit's opinion since he is a developer and, for all we know, he could be the one to code this up ultimately. Surely you can understand where I'm coming from.
Quote from: martindale on February 18, 2016, 04:57:54 amHey guys, Eric Martindale with Blockstream here. The answer to your question is absolutely, yes! It is definitely possible, and it would be very exciting to see BitShares as a sidechain. If I recall correctly, there are many other related projects that would make equal sense as sidechains, too.However, choosing to migrate from the existing model to a bonded sidechain is a different question. While sidechains already exist in the wild (see the alpha sidechain if you're looking for something to prototype on top of), creating and configuring one isn't trivial (yet). As part of the Elements Project, we're hoping to make this easier, but migrating any existing project to a sidechain will incur some amount of technical work. In the case of BitShares, I would expect it to be significant – you'll want to make sure the benefits are worth the effort.I'd be excited to have a conversation with Daniel or someone else from the BitShares team if they express any interest at all in pursuing this idea. Obviously, I'm excited about it, because I think there is very clear value in doing so, but I'd want to make sure that sentiment is shared among those responsible for BitShares.I, for one, think a world full of many interoperable blockchains is an exciting one!@fuzzy this is a cool idea for a hangout!
Hey guys, Eric Martindale with Blockstream here. The answer to your question is absolutely, yes! It is definitely possible, and it would be very exciting to see BitShares as a sidechain. If I recall correctly, there are many other related projects that would make equal sense as sidechains, too.However, choosing to migrate from the existing model to a bonded sidechain is a different question. While sidechains already exist in the wild (see the alpha sidechain if you're looking for something to prototype on top of), creating and configuring one isn't trivial (yet). As part of the Elements Project, we're hoping to make this easier, but migrating any existing project to a sidechain will incur some amount of technical work. In the case of BitShares, I would expect it to be significant – you'll want to make sure the benefits are worth the effort.I'd be excited to have a conversation with Daniel or someone else from the BitShares team if they express any interest at all in pursuing this idea. Obviously, I'm excited about it, because I think there is very clear value in doing so, but I'd want to make sure that sentiment is shared among those responsible for BitShares.I, for one, think a world full of many interoperable blockchains is an exciting one!
If it's possible, what I'm talking about would not be difficult at all. Probably far simpler than what you're talking about. Besides, I'm just asking a question. And you're not the best person to determine whether it's possible or what the cost would be. So please dispense with the sweeping proclamations.
Quote from: tbone on February 13, 2016, 03:56:18 pmI'm sorry, but you can't compare this to Liquid. Liquid is a federated sidechain of centralized services (BitFinex, Kraken, BTCC, Xapo, Unocoin). To begin with, the users of these services have to trust those companies. On top of that, the Liquid sidechain depends on the participating companies trusting each other. So you really can't compare that to what we're trying to accomplish here.By the way, it looks like you modified your post before I got a chance to respond. But since you were wondering why I wasn't taking your explanation at face value, it's because you're not the expert. So I continue to address @bytemaster with my questions since he IS the expert. And I asked for @abit's opinion since he is a developer and, for all we know, he could be the one to code this up ultimately. Surely you can understand where I'm coming from. In any event, I'm really not sure, but something tells me that what I'm proposing is very much doable. It would be great if @bytemaster would speak to it specifically. If it can't be done, please explain why. Thanks!What you are talking about is going to be costly on several fronts.It doesn't matter if it's possible or not.. sure it's possible.. you don't need bytemasters validation on that.. anything is possible with enough money put into it.. the question is if it is practical.Can you drive a tank from home to work every day? Sure.. is it practical.. no.Given the costs involved what we need is a lean and simply implementation that is going to cost the least amount while accomplishing the essential functions.Having our own Liquid with 5X the security and decentralization of what they have done is plenty of assurance for the target audience that would want to use this.If you want to spend a lot of money on anti-trust this current market simply won't support it. All too often simple solutions are pushed aside in favor of complex ones that are designed to suit strawman issues. I rather have a quick to execute and elegant simple solutions that accomplishes the task.Anyways.... keep plugging away at it.. the more difficult we make it the less likely it is to be done due to costs that stakeholders will be unwilling to shoulder because of diminished returns. Lower cost means greater returns.
I'm sorry, but you can't compare this to Liquid. Liquid is a federated sidechain of centralized services (BitFinex, Kraken, BTCC, Xapo, Unocoin). To begin with, the users of these services have to trust those companies. On top of that, the Liquid sidechain depends on the participating companies trusting each other. So you really can't compare that to what we're trying to accomplish here.By the way, it looks like you modified your post before I got a chance to respond. But since you were wondering why I wasn't taking your explanation at face value, it's because you're not the expert. So I continue to address @bytemaster with my questions since he IS the expert. And I asked for @abit's opinion since he is a developer and, for all we know, he could be the one to code this up ultimately. Surely you can understand where I'm coming from. In any event, I'm really not sure, but something tells me that what I'm proposing is very much doable. It would be great if @bytemaster would speak to it specifically. If it can't be done, please explain why. Thanks!
I meant a 2 out of 2 .. where one of the keys is actually not a key but a flag derived from the blockchain. Not sure how that helps
Quote from: complexring on February 13, 2016, 04:20:59 pmQuote from: tbone on February 12, 2016, 11:40:39 pmI'm trying to get at a way to do this without human involvement, otherwise I think it just won't be trusted. Plus how would it work, witnesses would have to manually approve each transaction? I don't see that as a viable solution. And I think there's a better way.I agree that not having human involvement would be ideal and cracking the trustless sidechain problem will greatly enhance the BitShares platform.So far, we have two solutions for the trustless problem that have been posed and a third if we allow for trusted parties:1) Enigma-like implementation (and / or integration) -- in which we have another thread already2) Dynamic addresses akin to smart contracts, with the ability to seamlessly to turn on and off 'spendability' of an address, depending on whether or not certain conditions are met.3) Multisig solution with witnesses1 and 3 have the same issues of collusion of k parties. 1) suggests a penalty for such a collusion attack by requiring a deposit to perform the calculations.3) there is no penalty for witnesses who collude, in so far as I can tell.We haven't really discussed the possibility of 2. Can someone explain if this is possible with smart contracts or can we have 'dynamic addresses' like this? Would that solution essentially be the same as either 1 or 3 ?For 2. We can probably have an account with a pubkey (or another account) together with the "flag" as another authority in a 2-1 multisig account.Then you can only spend from that account, it the flag has a certain condition .. not sure about what such a flag would actually do.
Quote from: tbone on February 12, 2016, 11:40:39 pmI'm trying to get at a way to do this without human involvement, otherwise I think it just won't be trusted. Plus how would it work, witnesses would have to manually approve each transaction? I don't see that as a viable solution. And I think there's a better way.I agree that not having human involvement would be ideal and cracking the trustless sidechain problem will greatly enhance the BitShares platform.So far, we have two solutions for the trustless problem that have been posed and a third if we allow for trusted parties:1) Enigma-like implementation (and / or integration) -- in which we have another thread already2) Dynamic addresses akin to smart contracts, with the ability to seamlessly to turn on and off 'spendability' of an address, depending on whether or not certain conditions are met.3) Multisig solution with witnesses1 and 3 have the same issues of collusion of k parties. 1) suggests a penalty for such a collusion attack by requiring a deposit to perform the calculations.3) there is no penalty for witnesses who collude, in so far as I can tell.We haven't really discussed the possibility of 2. Can someone explain if this is possible with smart contracts or can we have 'dynamic addresses' like this? Would that solution essentially be the same as either 1 or 3 ?
I'm trying to get at a way to do this without human involvement, otherwise I think it just won't be trusted. Plus how would it work, witnesses would have to manually approve each transaction? I don't see that as a viable solution. And I think there's a better way.
Quote from: complexring on February 13, 2016, 12:33:27 ampotentially. it's some pretty awesome math (and computer science) backing it up. it is essentially based on secret sharing and is well known from "shamir secret sharing" .. cool thing is that you can do calculations either with the full secret .. or with the individual parts of the secret ..
potentially. it's some pretty awesome math (and computer science) backing it up.
@tbone @complexring @abit @JonnyBitcoin @brainbug @Shentist @Akado @TravelsAsia @BunkerChain Labs @merivercap @btswildpig @fuzzy a solution?https://bitsharestalk.org/index.php/topic,21438.msg278789.html
Quote from: complexring on February 04, 2016, 04:01:06 pmQuote from: abit on February 04, 2016, 08:33:01 amTL;DR Don't know whether this be considered in the thread yet: If we want to automatically have top 15 witnesses multi-sig the BTC wallet, we need to improve voting participation first, otherwise for example btc38 would be able to steal the fund easily.Please look up and read my solution regarding choosing a random 15 of the delegates to be holders of a multisignature address. I think there's the possibility of 'revolution' type events where the top 15 could be voted out, and with them, the associated keys to the multisignature addresses.I feel that we don't need "active" witnesses to sign btc and/or in-bts-btc transactions, actually any witness_node can do that, they just need to broadcast transactions, active witnesses will then get them into blocks. So some random algorithm makes sense. //Update:With my "heart-beat" proposal, it's possible to identify which witness is alive.However, with randomly selected witnesses, we can't not prevent an attacker from running thousands of witness_nodes so that increasing chance of having all keys. I think some kind of PoW based witness selecting may work.
Quote from: abit on February 04, 2016, 08:33:01 amTL;DR Don't know whether this be considered in the thread yet: If we want to automatically have top 15 witnesses multi-sig the BTC wallet, we need to improve voting participation first, otherwise for example btc38 would be able to steal the fund easily.Please look up and read my solution regarding choosing a random 15 of the delegates to be holders of a multisignature address. I think there's the possibility of 'revolution' type events where the top 15 could be voted out, and with them, the associated keys to the multisignature addresses.
Instead of witnesses cannot be done in a public way (specialised witnesses) by businesses. In a similar way I would like an easy way to adjust the asset issue balance between Bitshares and Ethereum, so assets can be transferred back and forth at a minimal cost for the end user.
Quote from: bytemaster on February 02, 2016, 10:10:12 pm1. Have all of the witnesses monitor the BTC network for transfers to a designated multi-sig address which is defined by the BTS consensus to be the top 15 witness signatures (max MSIG allowed by BTC). All of these UNSPENT OUTPUTS get included as part of BTS consensus state.Ok, I have few questions:1. how those 15 signatures will be distributed among witnesses? What will happen if some witness lose their key? (I doubt that mine understanding of this is correct... )Or...2. those 15 signatures will be somehow encrypted in the bitshares blockchain? Is that correct that then most of the witnesses (by voting power) will need to agree to use those 15 signatures to make a transaction?Assuming, that this above is correct, why we need to use 15 signature if those signatures can be used only if witnesses will have consensus? We we cannot use 10, 2 or 1?Is that means, that bitshares network itself will have to prove, that we have all signatures needed to make a transaction? How does it work? Is those multiple signatures has to be combined into one? (I doubt it.. because that will mean, that single request from some computer will have to be made, and that computer can intercept this precious key).Is that mean, that bitshares network will have to prove that we have all 15 signatures? One witness will "authenticate" one signature? How network will assure, that after some time some witness will not collect all signatures? Is that mean, that network will have to prevent that one specific witness will never authenticate more than one signature? What if over time someone will gather 15 signatures by 15 different witnesses?Disclaimer: my questions probably are silly and I guess I made quite few completely wrong assumptions, nevertheless, it would be great if someone could share more details about possible implementations of that.
1. Have all of the witnesses monitor the BTC network for transfers to a designated multi-sig address which is defined by the BTS consensus to be the top 15 witness signatures (max MSIG allowed by BTC). All of these UNSPENT OUTPUTS get included as part of BTS consensus state.
Quote from: bytemaster on February 02, 2016, 10:10:12 pmIt is possible to do the following:1. Have all of the witnesses monitor the BTC network for transfers to a designated multi-sig address which is defined by the BTS consensus to be the top 15 witness signatures (max MSIG allowed by BTC). All of these UNSPENT OUTPUTS get included as part of BTS consensus state.2. Every time a BTC transaction gets 6 confirmations, the blockchain transfers SIDE-BTC asset to a balance controlled by the first input address (assuming the address is a simple 1 sig input).3. Allow this SIDE-BTC asset to be converted back to BTC with an operation that makes a request. For witnesses to produce a block they must also sign off on the MSIG transfer authorizing BTC to be sent to the proper address.This is something that could probably be implemented in about a month of dev time on the back end.In theory the witnesses could collude to steal all deposited BTC funds.without multisig, this is already working on metaexchange.we recieving BTC -->creating METAEX.BTC if you send METAEX.BTC back we send you BTC and burn METAEX.BTCyou can see the operations in realtime here http://cryptofresh.com/u/dev-metaexchange.monstererwhat is the value of doing it? would it not be better if we can setup some mulitsig for (blocktrades, opernledger and metaexchange) so we can use the same UIA?gives this really more value?
It is possible to do the following:1. Have all of the witnesses monitor the BTC network for transfers to a designated multi-sig address which is defined by the BTS consensus to be the top 15 witness signatures (max MSIG allowed by BTC). All of these UNSPENT OUTPUTS get included as part of BTS consensus state.2. Every time a BTC transaction gets 6 confirmations, the blockchain transfers SIDE-BTC asset to a balance controlled by the first input address (assuming the address is a simple 1 sig input).3. Allow this SIDE-BTC asset to be converted back to BTC with an operation that makes a request. For witnesses to produce a block they must also sign off on the MSIG transfer authorizing BTC to be sent to the proper address.This is something that could probably be implemented in about a month of dev time on the back end.In theory the witnesses could collude to steal all deposited BTC funds.
Quote from: complexring on February 02, 2016, 09:55:57 pmA potential solution to allow is to somehow have multisignature wallets associated to the balances that are held in collateral. If we can figure out a viable way of 'swapping' the associated private keys as different committee members are voted in and out, then there's no reason why we couldn't use something like that in order to achieve a pseudo-sidechain with BTC or any other alt.That we can do today with a .. say 5 of 13 multisig account
A potential solution to allow is to somehow have multisignature wallets associated to the balances that are held in collateral. If we can figure out a viable way of 'swapping' the associated private keys as different committee members are voted in and out, then there's no reason why we couldn't use something like that in order to achieve a pseudo-sidechain with BTC or any other alt.
It's possible . But our ears would be laughed out by the bitcoin miners seeing how we were bashing them
I am not an expert, but I guess a lot of people here are... so the question: Is it possible for bitshares to become a sidechain of bitcoin?I watched a 28th Jan Daily Decrypt, where Andreas Antonopoulos said that sidechains can allow sending assets from one blockchain to another... like from BTC to ETHhttps://youtu.be/kSq-58ElBzk?t=20m6sMore is said in the beginning of this episode, so for some of you I recommend to watch whole episode.CC: @bytemaster It would be great if bitcoin and bitshares could merge into some kind of one co-existing network, where bitcoin could benefit from already implemented great decentralized exchange.