Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
The original suggestion of using 15 witnesses to be holders of the private key of a multisig address seems simplest and best.Best block producers of BitShares are probably not the best signers of BTC address. Imo we need another voting algorithm for the BTC multi-signers, for better security, for example one stake can only vote for one signer, so BTC38 can't control all signers. We can probably ask the signers to put some collateral in BitShares, for example to an account under the control of the committee (the voting algorithm of committee should also be revised), to make sure they won't steal customers' funds.
Although, I am still unconvinced that bytemaster's suggestion of the top 15 is the best option. bytemaster seems to think that it's not an issue, due to historical data, that a voting-out event could occur. That's fine; however, we should always recall that past results are not indicative of future results.
The better solution (and I refuse to call any possible solution the best) is to randomly select 15 of the witnesses to be private key holders, with possibly a slightly weighted distribution towards the top ones. This way, even if there is a switch between the 15th and 16th witness, we wouldn't have to constantly move to a new multi-sig address for the collateral.
Randomness is evil. Stake talks.
This is good will. But I don't think BitShares is powerful enough to let other chains adapt BitShares's protocol.
I'm glad to see a BTC expert came in.@abitRe 2): How does the software prevent someone with both bitcoin private keys from signing a "bitcoin" transaction? They would sign it on the bitcoin network, which doesn't care about the rules of the sidechain.
* The witness who hold the second key could be killed, so the key lost, and the locked BTC become non-redeemable, hence no value.
* The witness who hold the second key could be the same person who deposited the BTC which is supposed to be locked, but actually the person have both keys, she can just unlock the fund without destroy the issued bitBTC.
1 all witnesses would hold the second key
2 the software will only allow a witness to sign the bitcoin transaction once the corresponding SIDEBTC has been destroyed. Remember SIDEBTC is not transferable only BITBTC is.
In general, I think this scheme is overly complicated and prone to some basic pitfalls. First and foremost, with potentially locked up BTC forever, all the BitBTC isn't redeemable for BTC, so it shouldn't trade as 1-1 for BTC.
I think BM's solution is much simpler, easier to understand, and therefore easier to trust. It's pretty safe except in the case of large scale collusion by the custodians of the SBA keys. To reduce this chance for collusion, the custodians could be compensated by some stream of income that goes away if they do collude.
Obviously there's political decisions involved in determining how to balance the amount of income to the custodians, the number of custodians, etc as the balance held increases. The biggest problem is this regard is probably the limited size of Bitcoin's multisig.
Imo what we need is a reputation system which will provide trusts. "Reputed signers hold the keys".
By the way multi-sig feature of BTC is too expensive, perhaps we can't afford the operating cost if eventually implemented the side chain thing.
I'm always astounded by people's inability to use basic GPG services. For being in the cryptocurrency scene, you'd think you might know a bit more about it.
Anyway, a quick verification of the message signed by Dan indicates that it is a valid signature, i.e. signed with the private key associated to the public key he posted.
You can also see that the public key is the same one that is on MIT's public key server, and you can also note that the key was generated on 02-02-2016.
Unless you believe that BM's account was compromised, and prior to the gaining control of the account, had already generated a public / private key pair on 02-02-16 and then, waiting all that time, the attacker then uploaded the key to MIT's public key server and then posted it on the forum, while at the same time knowing full well that MIT doesn't have a field for 'uploaded to server', you can take off your makeshift tinfoil hat.
If you want to wear that tinfoil hat on that theory, I'll sell you a professionally made one, and not a DIY created one. 10k BTS. If you need hats for the whole family, I do discounts, too. Buy 4 get 1 free.
Obviously *you* haven't understood how the GPG web of trust works. The fact that the given public key matches the signature doesn't prove anything, and the fact that the key is also available on a public key server doesn't prove anything either.
That the key is only 4 weeks old makes it more suspicious IMO (or perhaps less, because an attacker might want to fiddle with that...).
The only thing that *would* prove the authenticity of the key is a signature from a known-good key on it, or possibly a different kind of signature (like authenticated information in a blockchain).
If Bytemaster account is compromised how can we trust Stan's confirmation or anyone's ?
You can't trust me ....
This. It would be nice to know more details on what happened.
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.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
So, 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.
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.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
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!
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 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
@complexring @BunkerChain Labs
Your question is: when SIDEBTC is transferred the previous owner will still have the public key so its not secure.
This is how it works, there a 3 types of BTC
1. real BTC
2. SIDEBTC
3. BITBTC (like current bitbtc but collatralised 1:1 with side btc)
So SIDEBTC cannot be transfered ever. The owner of it uses it as collateral to create BITBTC which can be transfered.
So SIDE.BTC (or SIDEBTC, or whatever) will be non-transferrable and will be the underlying collateral for BITBTC. But then, there could be instances of the original depositor not logging in and not being able to approve a transaction, or just choosing not to do that (for whatever nefarious reason). Sure, this attack causes them to lose out on the btc that was originally deposited, but they sold for some other asset, say maybe bitEURO, bitCNY, or bitUSD, and are able to withdraw out of the DEX in this manner. The person who now owns BITBTC will be out if that user ever wants to withdraw bitcoin and hold in their own long-term wallet.
`Transferring` of the private keys must be done in some manner. Either by moving the bitcoin to a new multisig address each time for each new holder of the underlying asset (inefficient) or, better yet, a(n improved notion of a) smart contract, that is like a dynamic multisig and can be turned on or off when certain conditions are met, i.e. think of it as approving or revoking the signing of a transaction in a regular multisig transaction, but that is done in a trustless manner via the code. Essentially, program in 'dynamic' addresses where they are spendable if a certain condition is met even if you have the 1 private key that can be used to unlock it, you can't transfer out since you haven't met the appropriate conditions.
This latter solution, if possible, would be great! I'm not entirely sure how the implementation of smart contracts or the design of them is actually done. But if this type of dynamic solution isn't already considered, this is a huge improvement!
The bitbtc can move freely and doesn't need the original depositors signature. just like bitbtc currently works.
The new holder of bitbtc will not be able to force settle the bitbtc for real btc but they will be able to sell to someone else 1:1
i see what you mean though. You could discourage this by demanding collateral of 105% instead of 100%
Sure. I understand bitbtc can be freely moveable and sidebtc is not. However, the issue still remains if a user who owns bitbtc (or bit(altnamehere)) wants to move out of the system and have the actual cryptotoken in their possession. We can't rely on the original depositor to always be online to approve a transaction and or to always be honest.
Even if they have an extra 5% collateral that would be needed, I still don't think that this solves the problem.
I concede that the scenario of a dishonest depositor seems unlikely due to the additional 5% penalty and I wouldn't expect a 'rational agent' to behave in that manner. People are rarely rational, unfortunately, and (most) game theory assumes agents will act in a manner that promotes their own self-interest.
Even in the case of an honest depositor, what happens when the original depositor is dead and / or loses their private key ? That collateral is locked up forever and there is no way of removing it from the system. In addition, since the collateral can't actually move, can it really be seen as collateral anymore? I would think not.
Your question asks will the collateral be worthless due to the original depositor losing or purposefully discarding the keys to their account.
Yes this could be an issue. How about you add a condition that all SIDEBTC will expire and be sent back to a BTC address automatically after 5 years of creation date. Same as now how all order cancel after 5 years.
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.
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.
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 already
2) 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 witnesses
1 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 ?
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.
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.
potentially. 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 ..
A new thread should be made for the sidechain stuff I guess.
I know people trust a single entity (exchanges) to hold their bitcoins, but what if the witnesses get to manage huge volumes, like in the millions? Would witnesses accept doing this job? What if this was done, instead of witnesses, with many exchanges? Would that be riskier? What about other coins, imagine in the future we have 10 coins, each one with big volumes, can witnesses even handle that? Should we have a new account type for that? That's why I asked if exchanges should do that since they're more into that stuff, but I think it's more risky if you can't vote them out of their position. Maybe we could have an account type "Exchange" that could be voted in/out like witnesses and the top ones could be responsible for this process?
Imagine, for the sake of BitShares a large Bitcoin holder decides to do this with many Bitcoins, would there be a way for him to get dividends out of this? As an incentive to lock up Bitcoins? Like getting a percentage of the fees of those new SideChain Backed Bitcoins or whatever they are called? Not saying this is necessary because if this would work out, assuming it's a 1:1 ratio it should be enough by itself but it's always better if we can provide more incentives for other people to park their Bitcoins here and increase liquidity even more. Assume that new account type "exchange" is created, they could be the ones getting these dividends to get paid for their job instead of diluting?
I like this idea, the 1:1 ration sounds awesome and I expect it would increase the amount of assets we have.
The only thing I don't like is having dozens of different asset types. Too confusing. We have UIAs, MPAs now these SBAs (sidechain backed assets)... I'd say stick with either MPAs or SBAs, not both, it's always good to have a choice and versatility but I believe in this case it will only confuse people more. Unless services built on top of BitShares would make their users see only their SBAs for example to avoid all of this complexity.
