BitShares Forum
Main => General Discussion => Topic started by: tarantulaz on June 08, 2016, 03:57:09 pm
-
https://steemit.com/bitshares/@tarantulaz/why-i-think-stealth-backups-and-sidechains-shouldnt-be-added-in-bitshares
-
https://steemit.com/bitshares/@tarantulaz/why-i-think-stealth-backups-and-sidechains-shouldnt-be-added-in-bitshares
I don't do clickbait. Could you copy and paste the content?
-
Unclickable clickbait. Welcome to the future! 8)
I clicked it anyway. Here's the contents.
I created this post in order to express my opinion, about the additions of some features in BitShares. I know that a lot of people won’t like what I’ll say, but I think that adding the stealth feature on BitShares is a very bad idea. Same goes for the on ‘’chain backups’’ and sidechains.
As some well-known community members pointed out, stealth has a few problems. The main one is the metadata. Shadowcash’s chain was denonymized because they hadn’t applied something appropriately. Dash and Shadowcash sold and are still selling fake promises that their finances are private. However in the near future even a small adversary will be able to analyse their chain. Is this a thing that the BitShares community wants to do? Sell fake promises to raise the market cap? NXT added CoinShuffle many months ago and nothing really changed. It isn’t just the damage that will be done by all the imminent problems, but also in terms of labor costs etc.
There are so many more things that will have to be done to the GUI and the chances of people losing funds is huge. Think of the efforts svk will have to put in making everything bug free. Also the backup feature as good as it might seem, it sounds very dangerous to me. New users will be storing online backups with poor passwords which will be easily cracked.
Want anonymity? Wash your coins appropriately before buying BitShares and spread them into random accounts and use TOR to stay anonymous.
Want a secure backup of your files? Try Sia or Storj after their full release, or another encrypted provider. The whole point of the blockchain is that you hold your private keys and not anybody else.
Also don’t forget about the fact that if you hide your balance you won’t be able to vote afterwards. That is quite worrying especially if you wanna hide a big amount. At least Yunbi won’t be hiding it’s balance, so it will be a big blow to how people receive funding.
Finally I wanted to add a side note on sidechains. Honestly that would be even worse than adding stealth. Doom scenario for sidechains : Bitcoins worth 2M USD are held by the Bitshares Blockchain.
All witnesses collude to steal all coins or all witnesses are hacked and have no control, 2. Someone takes control over big proxies or stakes and votes witnesses his/her own (Hacking proxies or exchanges) 3. Big proxies/holders/exchanges collude to steal funds
Bytemaster said that it wouldn’t make sense for someone do so. But did he consider the fact that BitShares are a lot less liquid that Bitcoin? Even if Bitshares were worth 20M USD the fact that they are illiquid makes them worth a lot less than they actually are.
For example if someone controls a big stake, he can then open a big short position on Bitshares, take all Bitcoins and then sell the rest of the shares if he managed to steal any. After the hack there will be a panic sell of BitShares, not of Bitcoins though. 2M USD worth of Bitcoin’s can be hacked and nobody cares. If 2M USD of BitShares were hacked, the panic would be over the roof and the price of BitShares below the floor. His short position would make him huge profits, plus he could make the price go down even more by selling his shares. Currently someone needs to either control all the voting shares (about ¼ of the total supply) or 1/3 to ½ of the non voting BitShares.
In conclusion I would like to point that all these features as good as might seem, are very dangerous. The BitShares community should focus on more practical stuff, especially in the following :
Rate limited fees, Autobridging, Maker/Taker, Negative Fees, Smartcoin Park rates, Bond Market, MetaTrader Integration, Trading Bots. All these would add a lot of potential and value to BitShares, they don’t have any hidden dangers for the BitShares platform and their cost is relatively low. At current rates they could be done in 1 year.
PS I do want privacy, but stealth isn’t the answer. I know a lot of time has been spent on this feature, but we need to move forward without it.
-
Unclickable clickbait. Welcome to the future! 8)
I clicked it anyway. Here's the contents.
Thanks :D
In conclusion I would like to point that all these features as good as might seem, are very dangerous. The BitShares community should focus on more practical stuff, especially in the following :
Rate limited fees, Autobridging, Maker/Taker, Negative Fees, Smartcoin Park rates, Bond Market, MetaTrader Integration, Trading Bots. All these would add a lot of potential and value to BitShares, they don’t have any hidden dangers for the BitShares platform and their cost is relatively low. At current rates they could be done in 1 year.
I'd rather focus a lot on those features too. I don't know enough about Stealth/Privacy solutions to comment so I have to take it from others I trust on the forum that Stealth has a lot of issues. The complete openness of BTS is an issue though (especially in the BTS 2.0 transition, a lot of people had used their forum names for their accounts not realising everybody would be able to openly view their balances.) So even some level of privacy could be a positive.
Finally I wanted to add a side note on sidechains. Honestly that would be even worse than adding stealth. Doom scenario for sidechains : Bitcoins worth 2M USD are held by the Bitshares Blockchain.
All witnesses collude to steal all coins or all witnesses are hacked and have no control, 2. Someone takes control over big proxies or stakes and votes witnesses his/her own (Hacking proxies or exchanges) 3. Big proxies/holders/exchanges collude to steal funds
Bytemaster said that it wouldn’t make sense for someone do so. But did he consider the fact that BitShares are a lot less liquid that Bitcoin? Even if Bitshares were worth 20M USD the fact that they are illiquid makes them worth a lot less than they actually are.
I agree, I don't like the idea of witnesses controlling millions in Bitcoin either,
What? You're trusting your coins to the owner of a single exchange company with no supervision by other independent cosigners? Really?
They're trusting registered & highly regulated companies in countries with relatively strong & effective legal systems. Their owners are also making millions of dollars and so have a financial incentive to keep making money and not go to jail.
DPOS currently has neither the same legal fallback & delegates who make only a few hundred bucks a month. While the delegates ability to damage and profit from harming BTS is limited. They could get full value from other blockchain tokens.
By increasing the incentive for delegates to misbehave and therefore the trust required in them you increase the fragility of BTS. Blockchain competition is also reducing fees to near zero so the value centre of BTS is BTS collateralised SmartCoins, UIA tokens not collateralised with BTS are much less attractive, see MaidSafe, Synereo & Agoras, collectively worth >$50 million on an Omni blockchain worth <$1.4 million...
So I don't see the value in there myself. For me the way to make BTS useful and popular now & massively grow the value of BTS is by focusing on market maker & yield subsidies to create useful liquidity & demand around the peg so that bridges can convert fairly close to 1-1.
-
I don't do clickbait. Could you copy and paste the content?
Man, you really hate Steem don't you? :P
Unclickable clickbait.
I wish someone would fix the buggy @ mention implementation on these forums.
Edit: I finally found a workaround:
Original post on Steemit (https://steemit.com/bitshares/@tarantula%7A/why-i-think-stealth-backups-and-sidechains-shouldnt-be-added-in-bitshares)
-
Instead of witnesses, any group of trusted personalities or companies could form a similar decentralized escrow business that would be better than a lone exchange if not quite as good as an unmanned service...
In fact, if all the businesses that are building on BitShares were to agree to add their reputations to the mix, it might be ideal.
Better yet, if we elected the Top 15 Most Trusted Businesses in the ecosystem to each run a sidechain interface node wouldn't that solve all issues?
-
Instead of witnesses, any group of trusted personalities or companies could form a similar decentralized escrow business that would be better than a lone exchange if not quite as good as an unmanned service...
In fact, if all the businesses that are building on BitShares were to agree to add their reputations to the mix, it might be ideal.
Better yet, if we elected the Top 15 Most Trusted Businesses in the ecosystem to each run a sidechain interface node wouldn't that solve all issues?
Probably a better idea than top 15 witnesses given the temptation for thieves to exploit the current voter apathy and low market cap of BitShares in order to steal potentially large BTC or ETH reserves.
It is worth noting that from a technology perspective, the code that would need to be written to allow that approach of a sidechain (where I assume changes to the multisig group would be a manual process) is probably roughly 80% of the effort needed to build a sidechain system run by the dynamic set of witnesses.
-
I maintain that having no privacy on the blockchain at this stage is a massive blunder.
If stealth is fundamentally broken, then that's an ever bigger blunder.
Almost nobody interested in crypto will want a completely transparent blockchain. At least based on my experience around such communities.
Also, for 99.999% of our potential users, Tor is a no-go: the light client has no proxying support, and the default Tor browser configuration runs in private/incognito mode, so localstorage isn't available, so the wallet throws an error while starting up.
Besides, as discussed in another thread some days ago, the wss endpoint can correlate accounts to a wallet, even worse to all your wallets, since the connection the client establishes to the server isn't closed when switching wallet.
Mind elaborating on the issues with Dash? What is wrong with DarkSend (or whatever they've rebranded it to these days)
-
https://steemit.com/bitshares/@tarantulaz/why-i-think-stealth-backups-and-sidechains-shouldnt-be-added-in-bitshares
I don't do clickbait. Could you copy and paste the content?
Apologies for that. It wasn't my intention to make people click there in order to gain something. I just wanted to give my opinion.
Instead of witnesses, any group of trusted personalities or companies could form a similar decentralized escrow business that would be better than a lone exchange if not quite as good as an unmanned service...
In fact, if all the businesses that are building on BitShares were to agree to add their reputations to the mix, it might be ideal.
Better yet, if we elected the Top 15 Most Trusted Businesses in the ecosystem to each run a sidechain interface node wouldn't that solve all issues?
Yeah sure, but those businesses could make it themselves or a side project could do it with their funds. It should be 100% Fee backed and BitShares should hold no responsibility. And in the unluckily scenario where BitShares fails, it has to be up to the companies to help their customers. I want sidechains. I was really into them for a while and I was blindly listening to BM in the hangouts saying that DPoS is the best for this. But then I realized that the potential dangers are quite high in the initial way they were proposed. If we wanted to fund them through the blockchain, it would take more than 6 months to fund the project, without guaranteed results.
I maintain that having no privacy on the blockchain at this stage is a massive blunder.
If stealth is fundamentally broken, then that's an ever bigger blunder.
Almost nobody interested in crypto will want a completely transparent blockchain. At least based on my experience around such communities.
Also, for 99.999% of our potential users, Tor is a no-go: the light client has no proxying support, and the default Tor browser configuration runs in private/incognito mode, so localstorage isn't available, so the wallet throws an error while starting up.
Besides, as discussed in another thread some days ago, the wss endpoint can correlate accounts to a wallet, even worse to all your wallets, since the connection the client establishes to the server isn't closed when switching wallet.
Mind elaborating on the issues with Dash? What is wrong with DarkSend (or whatever they've rebranded it to these days)
Sure. I agree that TOR is hard, but people who want to protect their finances should learn how to use it well regardless and we have to make it easier with BitShares. Having Stealth but no support for TOR is a joke...
Even people within Dash know that Darksend isn't 100% secure. It is a new technology and you never know when someone will be able to break into it. Imagine thinking that you are anonymous and then one day waking up, 5 years later and you realize that all your transactions have been denonymized. Not all people need temporary privacy or anonymity. This is serious stuff where lives might be in danger after such 'revelations'. It isn't just investors trying to hide money like it probably will be in BitShares. Again, there is little privacy, privacy and total privacy-anonymity. If I had to chose the first one, I'd rather not have it at all.
So far there has been nobody within the Dash community trying to break Darksend and that is very worrying. What if someone outside the community manages to do it first? They are trying to improve it though, however that means that there might currently be something wrong with it.
Also at the moment they offer no good obfuscation of IP and many people, including myself, were complaining about this. Mixing was taking hours first and then they added people who get paid to offer liquidity. What are the problems with this :
Let's say CoinJoin offers quite good privacy. There are the following problems :
1) Only the destinations are mixed up, not the amounts. So someone can track back who sent what with some good analysis.
2) By not protecting your IP, especially when your mixes take hours, someone could easily find out who you are.
3) We don't know how many Masternodes are not compromised/control/owned by adversaries. It is currently assumed that only a small portions of the nodes is malicious.
4) When people offer just liquidity, an attacker can easily see who they are as their funds are probably going from CoinJoin to CoinJoin, while the rest of the participants might spend their coins somewhere.
https://www.dash.org/forum/threads/interesting-criticisms-of-dash-thoughts.8358/page-2
https://www.reddit.com/r/Bitcoin/comments/2zufu1/a_great_podcast_by_lets_talk_bitcoin_discussing/
Probably a better idea than top 15 witnesses given the temptation for thieves to exploit the current voter apathy and low market cap of BitShares in order to steal potentially large BTC or ETH reserves.
It is worth noting that from a technology perspective, the code that would need to be written to allow that approach of a sidechain (where I assume changes to the multisig group would be a manual process) is probably roughly 80% of the effort needed to build a sidechain system run by the dynamic set of witnesses.
It is hard indeed and that's why I think there is no need for this. Great feature, but some exchanges could see our potential and do the sidechains when we have managed to establish our DEX. By the way @arhag what do you think of the witnesses being able to do CoinJoins like Dash's masternodes?
-
By the way @arhag what do you think of the witnesses being able to do CoinJoins like Dash's masternodes?
There is a better way.
-
I haven't had time to read this whole thread, but Eric and I worked out a way earlier today to do a fully-decentralized version of sidechains that doesn't require multi-sig authorities, which from my limited reading would overcome the major objection originally expressed about sidechains in the OP. It wasn't prompted by this post, but by interest in linking graphene-based chains to ethereum (the original impetus being to link to ethereum as part of a move to get DAO support for peerplays). There's a fair amount of work involved in the implementation, but not an insurmountable amount by any means. So if peerplays is successful in getting DAO funding, it looks like we'll make this happen.
-
I haven't had time to read this whole thread, but Eric and I worked out a way earlier today to do a fully-decentralized version of sidechains that doesn't require multi-sig authorities, which from my limited reading would overcome the major objection originally expressed about sidechains in the OP. It wasn't prompted by this post, but by interest in linking graphene-based chains to ethereum (the original impetus being to link to ethereum as part of a move to get DAO support for peerplays). There's a fair amount of work involved in the implementation, but not an insurmountable amount by any means. So if peerplays is successful in getting DAO funding, it looks like we'll make this happen.
I find that very hard to believe, because I had convinced myself this is fundamentally impossible. Very interested to see what your solution is, what its limitations are, and whether it actually addresses any of the concerns of the OP.
-
I haven't had time to read this whole thread, but Eric and I worked out a way earlier today to do a fully-decentralized version of sidechains that doesn't require multi-sig authorities, which from my limited reading would overcome the major objection originally expressed about sidechains in the OP. It wasn't prompted by this post, but by interest in linking graphene-based chains to ethereum (the original impetus being to link to ethereum as part of a move to get DAO support for peerplays). There's a fair amount of work involved in the implementation, but not an insurmountable amount by any means. So if peerplays is successful in getting DAO funding, it looks like we'll make this happen.
I find that very hard to believe, because I had convinced myself this is fundamentally impossible. Very interested to see what your solution is, what its limitations are, and whether it actually addresses any of the concerns of the OP.
There's lots of details I don't have time to go into now, but the essence of the technique is to extract sufficient data from one blockchain to create a proof-of-burn (or proof-of-lock) that the other blockchain will accept if published to that blockchain. On etherium, a smart contract would serve as the arbiter for that proof. On a graphene blockchain, the validation would be built into the blockchain protocol. Most of the details lie in how to efficiently construct such proofs. Part of the proof is information that indicates the owner on the blockchain accepting the proof.
-
An automatic sidechain is pretty cool...but if we could improve just a little bit faster trading volume on dex I would be delighted......
A sidechain is a great project, bts price will have to apreciate probably to.fund this with huge buys wall.....so we.can.fund it with confidence
If we.could sort simple things n make it more useful n gain traction a little bit faster would be great while we shift on the long term big things, just my 2bts
-
I haven't had time to read this whole thread, but Eric and I worked out a way earlier today to do a fully-decentralized version of sidechains that doesn't require multi-sig authorities, which from my limited reading would overcome the major objection originally expressed about sidechains in the OP. It wasn't prompted by this post, but by interest in linking graphene-based chains to ethereum (the original impetus being to link to ethereum as part of a move to get DAO support for peerplays). There's a fair amount of work involved in the implementation, but not an insurmountable amount by any means. So if peerplays is successful in getting DAO funding, it looks like we'll make this happen.
I find that very hard to believe, because I had convinced myself this is fundamentally impossible. Very interested to see what your solution is, what its limitations are, and whether it actually addresses any of the concerns of the OP.
There's lots of details I don't have time to go into now, but the essence of the technique is to extract sufficient data from one blockchain to create a proof-of-burn (or proof-of-lock) that the other blockchain will accept if published to that blockchain. On etherium, a smart contract would serve as the arbiter for that proof. On a graphene blockchain, the validation would be built into the blockchain protocol. Most of the details lie in how to efficiently construct such proofs. Part of the proof is information that indicates the owner on the blockchain accepting the proof.
It's hard if not impossible for one chain to trust something happened on another chain. Even if every node validates every block of both chains, it still doesn't make much sense to trust a non-trustless chain.
Bitcoin has the most potentiality to be considered as trustless;
Eth is perhaps trustless, but I doubt smart contracts are (there is always an image in my head that most of if not all smart contracts aren't trustless);
Graphene based chains are definitely not trustless.
Am I missing something?
//Update: I must be drunk..
-
I haven't had time to read this whole thread, but Eric and I worked out a way earlier today to do a fully-decentralized version of sidechains that doesn't require multi-sig authorities, which from my limited reading would overcome the major objection originally expressed about sidechains in the OP. It wasn't prompted by this post, but by interest in linking graphene-based chains to ethereum (the original impetus being to link to ethereum as part of a move to get DAO support for peerplays). There's a fair amount of work involved in the implementation, but not an insurmountable amount by any means. So if peerplays is successful in getting DAO funding, it looks like we'll make this happen.
As I mentioned earlier, I want all the features I mentioned that we shouldn't add. What I mean is that they are cool features but...
1) BitShares isn't ready for them. We need the smaller features first, not the big ones.
2) Most of them have dangers and I guess even your version will have certain vulnerabilities.
3) They would cost a lot both in development, would take too much time and then they would need a lot time to integrate in the GUI
4) If someone has external funding like PeerPlays and wants to add sidechains I would be more than happy to see them as an FBA, but not spent a single BTS from the reserve pool.
We've been all over the place constantly. I was a stealth and sidechains advocate without thinking about the implications, as I was thinking only about things that would add value to the market cap. But now that I've realized that we are a young start up that won't be making profits for a while. Our DEX is growing constantly and we need to be user friendly, in order to attract more users. The features I mentioned could create a lot of unnecessary problems and even damage our reputation.
Anyways, I would still like to hear your version of the implementation. I would also like to hear from @kenCode about his Stealth plans. A few days ago he said that we should be expecting an announcement soon. @arhag just said that there is a good way to add privacy via another way. Have there been discussions between the two of you?
Also what sort of implementation of sidechains is PeerPlays thinking of implementing @BunkerChain Labs ?
-
I haven't had time to read this whole thread, but Eric and I worked out a way earlier today to do a fully-decentralized version of sidechains that doesn't require multi-sig authorities, which from my limited reading would overcome the major objection originally expressed about sidechains in the OP. It wasn't prompted by this post, but by interest in linking graphene-based chains to ethereum (the original impetus being to link to ethereum as part of a move to get DAO support for peerplays). There's a fair amount of work involved in the implementation, but not an insurmountable amount by any means. So if peerplays is successful in getting DAO funding, it looks like we'll make this happen.
I find that very hard to believe, because I had convinced myself this is fundamentally impossible. Very interested to see what your solution is, what its limitations are, and whether it actually addresses any of the concerns of the OP.
There's lots of details I don't have time to go into now, but the essence of the technique is to extract sufficient data from one blockchain to create a proof-of-burn (or proof-of-lock) that the other blockchain will accept if published to that blockchain. On etherium, a smart contract would serve as the arbiter for that proof. On a graphene blockchain, the validation would be built into the blockchain protocol. Most of the details lie in how to efficiently construct such proofs. Part of the proof is information that indicates the owner on the blockchain accepting the proof.
It's hard if not impossible for one chain to trust something happened on another chain. Even if every node validates every block of both chains, it still doesn't make much sense to trust a non-trustless chain.
Bitcoin has the most potentiality to be considered as trustless;
Eth is perhaps trustless, but I doubt smart contracts are (there is always an image in my head that most of if not all smart contracts aren't trustless);
Graphene based chains are definitely not trustless.
Am I missing something?
//Update: I must be drunk..
You may not be missing anything, but I thinking you are starting with too strong an initial assumption. You are correct when you say the two chains involved in a sidechain do have trust each other, although the limits of this trust can be established such that "lies told by one chain" can only have but so much effect on the other one (the affect can be limited to fraudulent transactions for the total value passed to a sidechain, for example).
But your initial assumption that "graphene-base chains are definitely not trustless" is, in my opinion, wrong. Maybe we just have a different opinion on what level of reliability is required to be "trustless". All chains are ultimately a form of consensus among the users and in the case of rapid hardforks, trustlessness can be significantly impaired by potential rogue code inserted into the blockchain software.
But with a reasonably diverse set of users and a slow rate of change, I think it's reasonable to call them trustless. Etherium's approach to trustlessness in the face of potentially rapid change (new smart contracts being rapidly introduced) is to limit the impact of a contract performing fraudulent operations to it's own domain of users, which seems pretty reasonable to me.
-
I would also like to hear from @kenCode about his Stealth plans. A few days ago he said that we should be expecting an announcement soon. @arhag just said that there is a good way to add privacy via another way. Have there been discussions between the two of you?
We are still working on the job description so that we know what's done, what's not, what I want to add to Stealth (ring sigs, possibly CN/CT or a combo of both), ipfs/ipns and who my confirmed network of consultants will be. I have an experienced cryptographer on my side but he's not cheap (even for Turkish labor) as well as a nice sized crew savvy enough with graphene-ui, graphene and ipfs/ipns.
@arhag I am interested in seeing every possible way we could do this. Stealth can whip monero, dash, zcash and the lot of them if we do this right. Leaving nothing for the competition to point at.
Even with Tor and I2P support (please Lord give us global meshnet soon!), you have to think about the NSA and what sort of crypto tools they might be able to employ to crack Stealth. Whales want privacy so Stealth has got to set the new standard.
-
I would also like to hear from @kenCode about his Stealth plans. A few days ago he said that we should be expecting an announcement soon. @arhag just said that there is a good way to add privacy via another way. Have there been discussions between the two of you?
We are still working on the job description so that we know what's done, what's not, what I want to add to Stealth (ring sigs, possibly CN/CT or a combo of both), ipfs/ipns and who my confirmed network of consultants will be. I have an experienced cryptographer on my side but he's not cheap (even for Turkish labor) as well as a nice sized crew savvy enough with graphene-ui, graphene and ipfs/ipns.
@arhag I am interested in seeing every possible way we could do this. Stealth can whip monero, dash, zcash and the lot of them if we do this right. Leaving nothing for the competition to point at.
Even with Tor and I2P support (please Lord give us global meshnet soon!), you have to think about the NSA and what sort of crypto tools they might be able to employ to crack Stealth. Whales want privacy so Stealth has got to set the new standard.
Just my 2 cents: based on discussions I had with BM after he decided that the current GUI implementation of stealth was too problematic, I came to the conclusion that what we really need at the moment is simply "blinded transactions" and I think this should be the immediate focus.
-
Just my 2 cents: based on discussions I had with BM after he decided that the current GUI implementation of stealth was too problematic, I came to the conclusion that what we really need at the moment is simply "blinded transactions" and I think this should be the immediate focus.
^^ this
-
@kenCode, I agree with @dannotestein that if you are going to be working on privacy features the first thing to work on is the GUI implementation for blinded transfers (not other stealth features). This should also include changes to the GUI to automatically backup the old memo key onto the blockchain (not IPFS, don't worry it's not a lot of data to backup) any time the memo key is changed. It should be backed up in a way such that the new memo key can retrieve the old memo key (at least the last known one at the time of the change), so some with the latest memo key can follow the chain of backups on the blockchain and recover all memo keys that had been active for the account. It should also be possible to retrieve the latest memo key using the current owner key (at least for scenarios where there is a single owner key that can have owner authority) so that someone can recover full access to their account using just the owner key (or actually brain key).
I think spending resources on some stealth that goes beyond simple blinded transfers may be a misallocation of resources (depending on what the particular design of stealth you implement is).
I need to continue thinking about and working on my ideas for the stealth design and I will post a write up when I can. But I will give a basic overview. First, it requires Monero's RingCT (https://github.com/ShenNoether/RingCT) cryptography by Shen Noether. This cryptography allows linkable ring signatures that work with blinded values (Pedersen commitments). But instead of using this cryptography to just pay a stealth balance to a recipient directly, the cryptography is used only for decentralized on-blockchain coin-mixing. The main reason is to reduce the risk of lost funds due to no recent backup. In my system, the amount and sender are hidden, but the recipient is not. This means there is no out-of-band communication necessary for someone to know they have received funds. They also don't need to do any backups after receiving funds to be able to get access to their received funds from only a brain key. The amount is hidden in the same manner that Confidential Transactions already do. The sender is hidden by making the payment from an active stealth balance that has not already been used to pay any other recipient. A new stealth balance can be created from an old stealth balance using the decentralized on-blockchain coin mixing process. Holding multiple active stealth balances at a time allows a sender to, with high likelihood, have enough funds available to send without needing to wait for the coin-mixing process. The nature of the coin mixing process means that someone can follow the chain of coin mixing steps in an efficient way and retrieve all of their active stealth balances starting from a root set originating from their public account (i.e bandwidth-efficient restore from only a brain key for a light client is possible even if the user has active stealth balances), and yet the public cannot do the same thus keeping the identity of the owner of each stealth balance private.
-
I would also like to hear from @kenCode about his Stealth plans. A few days ago he said that we should be expecting an announcement soon. @arhag just said that there is a good way to add privacy via another way. Have there been discussions between the two of you?
We are still working on the job description so that we know what's done, what's not, what I want to add to Stealth (ring sigs, possibly CN/CT or a combo of both), ipfs/ipns and who my confirmed network of consultants will be. I have an experienced cryptographer on my side but he's not cheap (even for Turkish labor) as well as a nice sized crew savvy enough with graphene-ui, graphene and ipfs/ipns.
@arhag I am interested in seeing every possible way we could do this. Stealth can whip monero, dash, zcash and the lot of them if we do this right. Leaving nothing for the competition to point at.
Even with Tor and I2P support (please Lord give us global meshnet soon!), you have to think about the NSA and what sort of crypto tools they might be able to employ to crack Stealth. Whales want privacy so Stealth has got to set the new standard.
That's was quite unexpected... Great privacy is needed if we are going to become a big trading platform, but I don't think this is the best time to do so...
Also claiming that we are going to beat monero sounds possible, but zcash? That's an overstatement...
But I'll have to wait to see the proposal and the expected timeline+cost in order to express my final opinion.
I am also very interested to hear about the sidechains. Has anyone studied Multigateway of NXT or been in contact with any of its Devs?
-
I need to continue thinking about and working on my ideas for the stealth design and I will post a write up when I can. But I will give a basic overview. First, it requires Monero's RingCT (https://github.com/ShenNoether/RingCT) cryptography by Shen Noether. This cryptography allows linkable ring signatures that work with blinded values (Pedersen commitments). But instead of using this cryptography to just pay a stealth balance to a recipient directly, the cryptography is used only for decentralized on-blockchain coin-mixing. The main reason is to reduce the risk of lost funds due to no recent backup. In my system, the amount and sender are hidden, but the recipient is not. This means there is no out-of-band communication necessary for someone to know they have received funds. They also don't need to do any backups after receiving funds to be able to get access to their received funds from only a brain key. The amount is hidden in the same manner that Confidential Transactions already do. The sender is hidden by making the payment from an active stealth balance that has not already been used to pay any other recipient. A new stealth balance can be created from an old stealth balance using the decentralized on-blockchain coin mixing process. Holding multiple active stealth balances at a time allows a sender to, with high likelihood, have enough funds available to send without needing to wait for the coin-mixing process. The nature of the coin mixing process means that someone can follow the chain of coin mixing steps in an efficient way and retrieve all of their active stealth balances starting from a root set originating from their public account (i.e bandwidth-efficient restore from only a brain key for a light client is possible even if the user has active stealth balances), and yet the public cannot do the same thus keeping the identity of the owner of each stealth balance private.
That would be a genius approach as it fixed the biggest issue we have had with TITAN: How to proof to the recipient that you have actually send the funds. With your approach, anyone can clearly see the incoming transaction at the recipient's side.
-
BM after he decided that the current GUI implementation of stealth was too problematic, I came to the conclusion that what we really need at the moment is simply "blinded transactions" and I think this should be the immediate focus.
I think the problem was money and time. He is way too focused on Steem right now guys to work on Stealth which is why BitShares Munich team is going to finish that project. Chris and Rodrigo are bringing whales, and whales want privacy. Marketing such an important product like Stealth however will need to include all the things that the competition, media and trolls in the comments would fire at us saying "hahaha look they are releasing a half assed product!" Instead, I'm choosing to take a bit more time and do it right the first time.
First Mover Advantage. Give the world something that it so sorely desires, do it right the first time, and market the hell out of it so that when the world sees it, they shut the f*ck up and say "ok, now this is cool". Total anonymity, total untraceability, ring sig, automated backups via ipfs/ipns, super tight integration with graphene-ui and ease of use, so easy in fact that Savers and Whales actually WANT to use it. I will not settle for anything less. I can take us a long way with this even with a little bit of funding so it only makes sense to spend the funds on the proper path instead of a "just do it this way for now" approach.
This should also include changes to the GUI to automatically backup the old memo key onto the blockchain (not IPFS, don't worry it's not a lot of data to backup) any time the memo key is changed. It should be backed up in a way such that the new memo key can retrieve the old memo key (at least the last known one at the time of the change), so some with the latest memo key can follow the chain of backups on the blockchain and recover all memo keys that had been active for the account. It should also be possible to retrieve the latest memo key using the current owner key (at least for scenarios where there is a single owner key that can have owner authority) so that someone can recover full access to their account using just the owner key (or actually brain key).
I prefer not to store data on our blockchain, hence my IPFS preference.
I need to continue thinking about and working on my ideas for the stealth design and I will post a write up when I can.
We plan to start the fundraiser in the next week or two, but if you could help us @arhag it would be greatly appreciated, the bigger my network on this one the better.
But I will give a basic overview. First, it requires Monero's RingCT (https://github.com/ShenNoether/RingCT) cryptography by Shen Noether. This cryptography allows linkable ring signatures that work with blinded values (Pedersen commitments). But instead of using this cryptography to just pay a stealth balance to a recipient directly, the cryptography is used only for decentralized on-blockchain coin-mixing. The main reason is to reduce the risk of lost funds due to no recent backup. In my system, the amount and sender are hidden, but the recipient is not.
I am probably not going to ultimately use RingCT. I think we can combine CN and CCT (one timers and compact conf tx (h/t Blockstream)), radically reducing the space that is needed and then dump proof of square this way. We are still working this out, but this just might be the ticket.
Holding multiple active stealth balances at a time allows a sender to, with high likelihood, have enough funds available to send without needing to wait for the coin-mixing process. The nature of the coin mixing process means that someone can follow the chain of coin mixing steps in an efficient way and retrieve all of their active stealth balances starting from a root set originating from their public account (i.e bandwidth-efficient restore from only a brain key for a light client is possible even if the user has active stealth balances), and yet the public cannot do the same thus keeping the identity of the owner of each stealth balance private.
Have you looked at Zerocash (https://z.cash)? Hiding who you are, where you are connected etc might be a lot easier if we can somehow use their method for the mixing stage.
-
I prefer not to store data on our blockchain, hence my IPFS preference.
For the small amount of data we are talking about in my design (likely less than 100 bytes added to the blockchain each time you change your account keys, which is not very frequent), I highly prefer the blockchain. There is no current mechanism to incentivize many people (for sufficient decentralization) to store IPFS blocks long-term. For something as critical as access to my account and all my funds, I don't trust its availability enough as it stands.
I am probably not going to ultimately use RingCT. I think we can combine CN and CCT (one timers and compact conf tx (h/t Blockstream)), radically reducing the space that is needed and then dump proof of square this way. We are still working this out, but this just might be the ticket.
What is CN? And I believe Compact Confidential Transactions were broken (https://steemit.com/technology/@dantheman/compact-confidential-transactions#@steemrollin/re-dantheman-compact-confidential-transactions-20160504t180837286z).
Have you looked at Zerocash (https://z.cash)? Hiding who you are, where you are connected etc might be a lot easier if we can somehow use their method for the mixing stage.
From my limited understanding of Zerocash (zk-SNARKs wtf?) it doesn't have very good performance, and does it still require a trusted setup? If so, that is a non-starter to me.
-
BM after he decided that the current GUI implementation of stealth was too problematic, I came to the conclusion that what we really need at the moment is simply "blinded transactions" and I think this should be the immediate focus.
I think the problem was money and time. He is way too focused on Steem right now guys to work on Stealth which is why BitShares Munich team is going to finish that project. Chris and Rodrigo are bringing whales, and whales want privacy. Marketing such an important product like Stealth however will need to include all the things that the competition, media and trolls in the comments would fire at us saying "hahaha look they are releasing a half assed product!" Instead, I'm choosing to take a bit more time and do it right the first time.
First Mover Advantage. Give the world something that it so sorely desires, do it right the first time, and market the hell out of it so that when the world sees it, they shut the f*ck up and say "ok, now this is cool". Total anonymity, total untraceability, ring sig, automated backups via ipfs/ipns, super tight integration with graphene-ui and ease of use, so easy in fact that Savers and Whales actually WANT to use it. I will not settle for anything less. I can take us a long way with this even with a little bit of funding so it only makes sense to spend the funds on the proper path instead of a "just do it this way for now" approach.
It's not a matter of "just do it this way for now". There's practical usability issues that make blinded transactions the "right approach" for many transactions, so blinded transactions are not just a detour or even a "half-way" towards stealth transactions. We ultimately want to support both methods, IMO, but blinded transactions are 1) easier to use, 2) not prone to losses, and 3) easier to implement. It would be difficult for me to support a worker that favors supporting stealth before supporting blind transactions. I would like to see a lower cost worker created for blinded transactions first, then a higher cost worker created to support stealth after blinded transactions have been successfully implemented.
-
I'd like to see the discussion separate the affordability/priority issues from the underlying best approach.
If Ken has a whale sponsor with deep, um, blubber, what is the best thing to build for the ecosystem?
-
I'd like to see the discussion separate the affordability/priority issues from the underlying best approach.
If Ken has a whale sponsor with deep, um, blubber, what is the best thing to build for the ecosystem?
Please read my post above, my concern is not just affordability. Assuming one approach is the "best" is itself an error, IMO.
-
Blinded transfers as @arhag and @dannotestein have already outlined for the win.
@kenCode I know IPFS is cool, but there is no chance in hell anybody should trust it with their financial data. Further, it is extremely dangerous to have elements of our blockchain/user accounts relying on another to work. @arhag backup to the blockchain solution is the elegant reliable and sellable choice.
Really excited about the prospects of blinded transfers!!!
-
I'd like to see the discussion separate the affordability/priority issues from the underlying best approach.
If Ken has a whale sponsor with deep, um, blubber, what is the best thing to build for the ecosystem?
Please read my post above, my concern is not just affordability. Assuming one approach is the "best" is itself an error, IMO.
+5%
We need both simple blinded transfers (with no hiding of metadata) and also a great stealth system (there is a lot of room for debate about which stealth design is superior). The two different approaches come with their own trade-offs in user-experience and costs (to the user).
Simple blinded transfers should be the priority and come first. If there really are whales willing to throw lots of money at the problem, then both solution can proceed in parallel. But building a GUI for simple blinded transfers is a much easier problem, so I expect it to be completed first.
-
Well, if KenCode has his whales behind him and they are going to fund the development then I guess it should be up to him and his team. As long as the solution is working and they commit in doing everything right with the GUI as well, then I can't see a reason to argue.
However I still think that little privacy = no privacy for me and untested-new-high privacy technology is both too risky and time consuming.
On the funding side, would anyone consider doing an ICO-type funding? I know it might sound crazy, but this discussion has been within the NXT community as well.
With the current liquidity pool workers, market cap, the existing dilution from the merger and the Chinese community voting against most projects, we should try and raise some money for a specific number of projects and sell BTS to whales OTC. If that happens via a hard fork, that would be the quickest way. Create an account managed by an elected committee that will handle the funds and get Ronny to assist us with the escrow.
This would have many benefits :
1) No immediate drop in the market cap
2) Immediate access to funds and we don't have to worry about the votes, so mini projects like Chronos' videos, as well as svk can keep being funded.
3) No more arguments about funding workers
4) More whales would get in the ecosystem that could invest more if everything goes well both in terms of development and privacy
5) ICOs seem to attract a lot of attention recently and raising 500.000 especially for an established project wouldn't be that hard. With the right promotion BitShares could attract more people to get involved.
For this one we need some people to lead the way. We need a good plan first and then a strong committee to implement the things the majority of stakeholders and CO participants has agreed on.
-
Well, if KenCode has his whales behind him and they are going to fund the development then I guess it should be up to him and his team. As long as the solution is working and they commit in doing everything right with the GUI as well, then I can't see a reason to argue.
However I still think that little privacy = no privacy for me and untested-new-high privacy technology is both too risky and time consuming.
On the funding side, would anyone consider doing an ICO-type funding? I know it might sound crazy, but this discussion has been within the NXT community as well.
With the current liquidity pool workers, market cap, the existing dilution from the merger and the Chinese community voting against most projects, we should try and raise some money for a specific number of projects and sell BTS to whales OTC. If that happens via a hard fork, that would be the quickest way. Create an account managed by an elected committee that will handle the funds and get Ronny to assist us with the escrow.
This would have many benefits :
1) No immediate drop in the market cap
2) Immediate access to funds and we don't have to worry about the votes, so mini projects like Chronos' videos, as well as svk can keep being funded.
3) No more arguments about funding workers
4) More whales would get in the ecosystem that could invest more if everything goes well both in terms of development and privacy
5) ICOs seem to attract a lot of attention recently and raising 500.000 especially for an established project wouldn't be that hard. With the right promotion BitShares could attract more people to get involved.
For this one we need some people to lead the way. We need a good plan first and then a strong committee to implement the things the majority of stakeholders and CO participants has agreed on.
For new networks yes... why would an investor want to come in and make a bunch of existing holders more rich with their money?
This is the position I have gotten numerous times when talking to investors about bitshares.. there is no clear ROI... and the politics that have divided the direction of Bitshares (anti-dilusion vs. etc) only heightened the risk profile.
I understand that this is an FBA though... which investors understand.
-
For new networks yes... why would an investor want to come in and make a bunch of existing holders more rich with their money?
This is the position I have gotten numerous times when talking to investors about bitshares.. there is no clear ROI... and the politics that have divided the direction of Bitshares (anti-dilusion vs. etc) only heightened the risk profile.
I understand that this is an FBA though... which investors understand.
That's why a clear plan is needed, with the majority agreeing on it. It doesn't have to be only big investors even if that would be more preferable. Let's say a whale wants to enter BitShares, but doesn't want to move the price too much. We could sell the shares in a discounted rate. That would be ideal for him/her. Give them a 10-15% discount as well and bingo.
I am not talking about investors waiting to make ROI, but people who see that these features could make BitShares' price go up. People join ICOs nowadays without thinking much. It could even be people from this community who want to see the money that they put in buying shares do something useful and not just move onto a previous holder.
I am pretty sure than many community members would actually like this. More shares, for less and with money going into actual development.
As an FBA it wouldn't make much sense. Who would like to have an asset that only pays for some features or what are those features? Which ones should be included and which ones shouldn't?
Finally I don't want to be too pushy, but I still haven't gotten an answer about how you plan to implement sidechains? When I made a post about doing an ICO for an FBA for sidechains you said Peerplays would do it (you might have talked/wrote about it and I haven't heard/read it yet).
-
You can fork any time, but who is going to follow you? Bitshares holders will not, big guys will not, the market will not, brwnd recongnition will not, awareness will not, community will not,
But if you can find BiG new money for it fork it make an ico, dump early at no cost, develop n let community judge if you have either.
-
You can fork any time, but who is going to follow you? Bitshares holders will not, big guys will not, the market will not, brwnd recongnition will not, awareness will not, community will not,
But if you can find BiG new money for it fork it make an ico, dump early at no cost, develop n let community judge if you have either.
Who said that they will not? Are you a representative of all big holders? I am just setting a question that has MANY pros and a few cons. If the community says no, we don't want this fork, but we are still up for going through the slow way of not spending then fine. Getting paid by the blockchain at current rates and with the current split in the community, is painful, slow and many times you don't even get paid. Who wants to get paid by a blockchain who can revoke the contract anytime or whose token value is dropping day by day?
Lisk got 6M, Waves 16$ and there are more to come. We need about 500.000$ and we'll become huge. Otherwise, we can wait for developers to get some pennies, so that they can fix a few bugs and the documentation then we are done.
We are so much smaller than bitcoin, that the holders can offer less than 500.000$/y, but Bitshares needs a lot more in order to grow, otherwise it is going to die slowly. Many people already say that BitShares is dead and they are not that wrong. If people keep thinking that way, then BitShares will die, because hey, that's the word on the street, so it must be true.
-
You can fork any time, but who is going to follow you? Bitshares holders will not, big guys will not, the market will not, brwnd recongnition will not, awareness will not, community will not,
But if you can find BiG new money for it fork it make an ico, dump early at no cost, develop n let community judge if you have either.
Who said that they will not? Are you a representative of all big holders? I am just setting a question that has MANY pros and a few cons. If the community says no, we don't want this fork, but we are still up for going through the slow way of not spending then fine. Getting paid by the blockchain at current rates and with the current split in the community, is painful, slow and many times you don't even get paid. Who wants to get paid by a blockchain who can revoke the contract anytime or whose token value is dropping day by day?
Lisk got 6M, Waves 16$ and there are more to come. We need about 500.000$ and we'll become huge. Otherwise, we can wait for developers to get some pennies, so that they can fix a few bugs and the documentation then we are done.
We are so much smaller than bitcoin, that the holders can offer less than 500.000$/y, but Bitshares needs a lot more in order to grow, otherwise it is going to die slowly. Many people already say that BitShares is dead and they are not that wrong. If people keep thinking that way, then BitShares will die, because hey, that's the word on the street, so it must be true.
Bitshares dead? A lot of data dont say that, for me it is stronger n much stronger than before....do your research again.
Average people does not make a diference in lisk ico, lisk ico was small targeting average investor. The only diffent thing is ethereum. ico party will be over soon n.we will start mining party again.
Is it fud because the price has to go up now?
-
I'd like to see the discussion separate the affordability/priority issues from the underlying best approach.
If Ken has a whale sponsor with deep, um, blubber, what is the best thing to build for the ecosystem?
Please read my post above, my concern is not just affordability. Assuming one approach is the "best" is itself an error, IMO.
Yeah, you slipped in your answer while I was still typing my question. Great service!
-
You can fork any time, but who is going to follow you? Bitshares holders will not, big guys will not, the market will not, brwnd recongnition will not, awareness will not, community will not,
But if you can find BiG new money for it fork it make an ico, dump early at no cost, develop n let community judge if you have either.
Who said that they will not? Are you a representative of all big holders? I am just setting a question that has MANY pros and a few cons. If the community says no, we don't want this fork, but we are still up for going through the slow way of not spending then fine. Getting paid by the blockchain at current rates and with the current split in the community, is painful, slow and many times you don't even get paid. Who wants to get paid by a blockchain who can revoke the contract anytime or whose token value is dropping day by day?
Lisk got 6M, Waves 16$ and there are more to come. We need about 500.000$ and we'll become huge. Otherwise, we can wait for developers to get some pennies, so that they can fix a few bugs and the documentation then we are done.
We are so much smaller than bitcoin, that the holders can offer less than 500.000$/y, but Bitshares needs a lot more in order to grow, otherwise it is going to die slowly. Many people already say that BitShares is dead and they are not that wrong. If people keep thinking that way, then BitShares will die, because hey, that's the word on the street, so it must be true.
Bitshares dead? A lot of data dont say that, for me it is stronger n much stronger than before....do your research again.
Average people does not make a diference in lisk ico, lisk ico was small targeting average investor. The only diffent thing is ethereum. ico party will be over soon n.we will start mining party again.
Is it fud because the price has to go up now?
I didn't get the last point some of your points to be honest.
There are many people who have left the community claiming BTS is dead, BM has left for another project and to many, that might seems very bad. I was on some forums where people were making fun of BTS. The same thing came up when I was watching a crypto livestream. We are so closed up in our community and think so highly of ourselves and we don't see the same things as others. We see that BitShares is alive, but other people see it as dead.
We have 0 marketing. We've been talking about Rate limited fees, Stealth, sidechains and other features for months and we have done nothing, in a space that moves so fast, that is either evolve or die...
You have to be realistic. If people think you are dead and forget about you, then does it matter that you are alive? We aren't building this platform just for ourselves. We have to try more and we need money or we die.
-
I am probably not going to ultimately use RingCT. I think we can combine CN and CCT (one timers and compact conf tx (h/t Blockstream)), radically reducing the space that is needed and then dump proof of square this way. We are still working this out, but this just might be the ticket.
What is CN?
One time rings which mix the senders identities for untraceability
And I believe Compact Confidential Transactions were broken (https://steemit.com/technology/@dantheman/compact-confidential-transactions#@steemrollin/re-dantheman-compact-confidential-transactions-20160504t180837286z).
Right now I think that is just hearsay by btctalk "Poloniex Matthew" (a btctalk newbie)
Have you looked at Zerocash (https://z.cash)? Hiding who you are, where you are connected etc might be a lot easier if we can somehow use their method for the mixing stage.
From my limited understanding of Zerocash (zk-SNARKs wtf?) it doesn't have very good performance, and does it still require a trusted setup? If so, that is a non-starter to me.
True, speed is a major issue with me. It's one of the many reasons I chose Bitshares (even when we had 10 second blocks). Their mixing technology though looks so far to be the most superior, so I would like to dig deeper into this and just use what we need. There have been some ideas brought to me that may solve all of the speed issues.
blinded transactions are not just a detour or even a "half-way" towards stealth transactions. We ultimately want to support both methods, IMO, but blinded transactions are 1) easier to use, 2) not prone to losses, and 3) easier to implement. It would be difficult for me to support a worker that favors supporting stealth before supporting blind transactions. I would like to see a lower cost worker created for blinded transactions first, then a higher cost worker created to support stealth after blinded transactions have been successfully implemented.
Interesting, but you guys know a Worker is not cheap and for me it is very risky to start some of my guys on this and have the funding get yanked out because of the non-dilute guys. $45K was no small amount, but at least all the core code is done, now we just need the GUI. Hiding the sender/receiver stage 1. Hiding the amounts stage 2. Mixing and masking stage 3. Rudimentary, but would you vote for something like that? My guys don't cost as much and of course I would try to get CNX and others to do the audits on all of our code too (plus I will put it on my github as usual).
We need both simple blinded transfers (with no hiding of metadata) and also a great stealth system
...
building a GUI for simple blinded transfers is a much easier problem, so I expect it to be completed first.
Ok, so if we break this up in stages, milestones if you will, could we get this Worker funded? If so, I will get on the job description and milestones asap and present it to the community for a vote. I just worry about the anti-dilute crowd, I do not want to waste time or money on a project that just gets stalled again.
On the funding side, would anyone consider doing an ICO-type funding?
Yes, BitShares Munich
ICOs seem to attract a lot of attention recently and raising 500.000 especially for an established project wouldn't be that hard.
Jeez well you wouldn't believe how far I can stretch even 10K.
-
Relax man, let bts do his ride alone.....if it need sink, let it sink n increase your stake.....so in the future you can help funding at little cost, is not easy funding in this situation, but things gonna change, n we should focus on simple, priorities,n affordable.things that our service can be more widespread for now....when bts reach a considerable apreciation in price everything will be easier.....even bitcoin found hard time in bear market
-
On the funding side, would anyone consider doing an ICO-type funding?
Yes, BitShares Munich
ICOs seem to attract a lot of attention recently and raising 500.000 especially for an established project wouldn't be that hard.
Jeez well you wouldn't believe how far I can stretch even 10K.
That sounds really good to me, but I was talking about development in general. I wanted bigger ICO so that we can develop all the features we want to and we need to.
Let's admit it, DPoS isn't ideal to fund development. At least not as good as Dash's masternodes and with the ongoing merger dilution, we need another way to fund development. A quick fix would be to create OPENStealth as an FBA and have Openledger as escrow or something like that.
I know you 'inherited' that code from BM, but why not something else and you desperately want that feature? Again I am gonna wait and see your plan about adding Ring Signatures to the game.
Blinded Transfers and CoinJoin would be very easy to add to BitShares, and would add great privacy if combined. Imagine the blockchain bloat if we add Ring Signature in BitShares, even if they are optional. What are your thoughts on this?
@bitsharesbrazil I am relaxed, the situation is serious though. Even if the community doesn't agree on stealth at the moment, a solution will be found. But without money we can't do anything. No money, no honey.
-
I am probably not going to ultimately use RingCT. I think we can combine CN and CCT (one timers and compact conf tx (h/t Blockstream)), radically reducing the space that is needed and then dump proof of square this way. We are still working this out, but this just might be the ticket.
What is CN?
One time rings which mix the senders identities for untraceability
Are you talking about the linkable ring signatures used in CryptoNote (https://cryptonote.org/inside), which are based on the "Traceable ring signature" by Fujisaki and Suzuki?
Apparently according to this Monero paper (https://lab.getmonero.org/pubs/MRL-0005.pdf) (warning PDF), the LWW ring signatures (Linkable Spontaneous Anonymous Group (LSAG) signatures by Liu, Wei, and Wong) are more space efficient than the FS ring signatures.
And I believe Compact Confidential Transactions were broken (https://steemit.com/technology/@dantheman/compact-confidential-transactions#@steemrollin/re-dantheman-compact-confidential-transactions-20160504t180837286z).
Right now I think that is just hearsay by btctalk "Poloniex Matthew" (a btctalk newbie)
After looking into it more carefully, it seems it was broken last year but was fixed. Here (https://bitcointalk.org/index.php?topic=1085436.msg11713970#msg11713970) is a better link explaining the original problem. Gregory Maxwell reported on June 24, 2015 that Andrew Poelstra was able to break the cryptosystem. A day later, Mixles (Denis Lukianov), the creator of CCT, commented that he updated the paper to fix the issue but because of it the proof was slightly less compact (but still much better than CT). The thread is really long and detailed so I just skimmed it, but it seems some other minor issues came up and were addressed, and then there was a bigger issue (https://bitcointalk.org/index.php?topic=1085436.msg13204259#msg13204259) and it seems that was eventually addressed (https://bitcointalk.org/index.php?topic=1085436.msg13328122#msg13328122). However, of the four variants of CCT available as of that last update, 1 and 2 are non-starters because they require trust, 3 seems to not be interesting for our purposes either, and 4, which is the interesting one to consider, now has much larger proofs that are close to but I suppose still half the size of a CT proof that hides all 64-bits of the amount (but if only hiding 32 bits of the balance with CT is enough from a privacy perspective, then there doesn't seem to currently be any significant proof size advantage).
Given all of the above, I feel more comfortable sticking with regular CT for now. Especially considering that LSAG signatures have been adapted to work with CT by Monero devs (see the Monero paper I linked above) and an implementation (https://github.com/ShenNoether/RingCT) for it already exists.
-
Let's admit it, DPoS isn't ideal to fund development. At least not as good as Dash's masternodes
How is Dash's governance and proposal funding system better? I'm actually curious, because I haven't had time to look into it yet. On a very quick inspection I didn't see anything novel or that stood out to me (when I compare to what BitShares already has). Keep in mind, I am talking technicals here. Maybe Dash stakeholders are blessed without an anti-dilution camp holding them hostage. But that has nothing to do with the technology.
That doesn't mean BitShares governance systems are great. I have issues with it which I have talked about here (https://steemit.com/bitshares/@help-yourself/why-has-bitshares-failed#@arha%67/re-help-yourself-why-has-bitshares-failed-20160605t135359549z) and here (https://steemit.com/bitshares/@xero%63/improvment-bitshares-workers-proposal-thedao#@arha%67/re-xeroc-improvment-bitshares-workers-proposal-thedao-20160520t015315090z). And I have some additional ideas (in drafts or even still in my head) for how I would like to see the worker system change to provide greater certainty to those getting paid who got elected. It's not great to get your worker elected only to worry everyday whether your worker is being paid or not because of vote fluctuations.
But the bigger issue is, could we get stakeholder consensus to implement such a large change. Probably not. :(
-
Let's admit it, DPoS isn't ideal to fund development. At least not as good as Dash's masternodes
How is Dash's governance and proposal funding system better? I'm actually curious, because I haven't had time to look into it yet. On a very quick inspection I didn't see anything novel or that stood out to me (when I compare to what BitShares already has). Keep in mind, I am talking technicals here. Maybe Dash stakeholders are blessed without an anti-dilution camp holding them hostage. But that has nothing to do with the technology.
That doesn't mean BitShares governance systems are great. I have issues with it which I have talked about here (https://steemit.com/bitshares/@help-yourself/why-has-bitshares-failed#@arha%67/re-help-yourself-why-has-bitshares-failed-20160605t135359549z) and here (https://steemit.com/bitshares/@xero%63/improvment-bitshares-workers-proposal-thedao#@arha%67/re-xeroc-improvment-bitshares-workers-proposal-thedao-20160520t015315090z). And I have some additional ideas (in drafts or even still in my head) for how I would like to see the worker system change to provide greater certainty to those getting paid who got elected. It's not great to get your worker elected only to worry everyday whether your worker is being paid or not because of vote fluctuations.
But the bigger issue is, could we get stakeholder consensus to implement such a large change. Probably not. :(
Dash doesn't have any anti-dilution camp and that is why they are doing a lot better at the moment. I made a post a few months ago explaining how different crypto DAO/DAC work, and despite the fact they have a 13% inflation, the main problem they have, is how to fund all the awesome projects they have... If they could fund more proposals trust me, they would. At the moment they are about implement contracts on the blockchain, so that people don't run into the same problems as we've run into, like one day you are paid, the other you are not.
But let me be more clear as to why Dash's model is better :
1) You must have 1000 Dash in order to vote and run a masternode, which gets about 9-10% APR. So it is people with a relatively good stake and people that are more interested in seeing Dash grow.
If you could get 10% APR and you were risking that much money, would you not try to make things work? Because there are no proxies, wouldn't you be more interested to find out about the developments? If you have bothered to create a masternode, wouldn't that mean that you are already a bit more technical and willing to get involved? It isn't the speculator or the average Joe that vote via the masternode mechanism.
2) Less voter apathy because of the incentives. Apart from the apathy, it doesn't make much sense for people to sell their Dash and leave the project after they get such good returns. In BitShares, the voting shares don't get any reward for their contributions.
3) Because your collateral is hard-locked (doesn't move), it is hard for people to can't manipulate your vote, by using your stake.
4) The voting is more anonymous as all masternodes have the same collateral, as well as due to the inbuilt privacy it has.
5) It would be very hard for exchanges to vote, as they would have to create many masternodes and vote with them, something that wouldn't go unnoticed.
Obviously many of the problems are not exactly problems of DPoS, but of the existing implementation in BitShares. I agree with your first commend on steemit, but I can't open the second one.
Without voting incentives, proper contracts, the current merger dilution, ability of exchanges to vote etc, our worker voting mechanism is useless. That's why I strongly suggest to do a Coin Offering via a hard fork. We are really stuck and we can't move.
-
I agree with your first commend on steemit, but I can't open the second one.
The second link is the same link as the "differentiated" link in the first post. Let me try reposting the raw link (I really hate this forum's buggy @ mention implementation >:():
https://steemit.com/bitshares/@xeroc/improvment-bitshares-workers-proposal-thedao#@arhag/re-xeroc-improvment-bitshares-workers-proposal-thedao-20160520t015315090z
Actually, many of the items in your list I think would be addressed in BitShares simply by providing voting rights to only vested BTS (which is what the link above discusses mostly). But it is a huge (social) change, because it requires printing BTS to pay interest to vested BTS.
-
When arhag talks I just listen, always great....I only disagree that I really like the way workers are put on the table, is there uncertainty over it? Yes, if you dont delivery you have to improve your game,
Is it fair? Depends, for someone it is for other maybe not....call me.crazy, but I really like it
What I miss is an automatic way to follow up, see expenses, details of what have been doing, but the way it is right now I really.like.....
Nothing will be perfect in dac, we have to adapt ourselves to it let the ruler rules....
I of Ico, fork, dilution....talk about it when you have a guy that want to put big money into it....dont speculate
If it, if that..... You think if waves, lisk got that money you are going to get the same or more the same way...just delusion, you probably will no get 50btc if 90% of coins stay in a few pair of hands........n if it does not work? New dilution? Merger? New ico? Rebranding?
You have to believe in bitshares n do your share instead waiting for some magical money pay yours bills or print new money from reserves....money dont come from magic.....money doesnt come from nowhere....
To give some credibility to bitshares stop give uncertainty lets do it, lets do that with supply, lets merge, lets dilute......make something in what you believe because what I see here is that people want money for everything they do........why do not share risk of the new feature? Partnership if in the future it works both gains......you need be creative because beg for money all the time just paint a portrait of a deep troat sucker.
-
I was talking about development in general. I wanted bigger ICO so that we can develop all the features we want to and we need to.
Me too. We will reveal more about this in the coming weeks.
A quick fix would be to create OPENStealth as an FBA and have Openledger as escrow or something like that.
We already have a STEALTH FBA that we will be using.
Again I am gonna wait and see your plan about adding Ring Signatures to the game.
Every contact, competing product, available technology for this is still on the table. I am following every lead and doing serious R&D on each so that when we finally have the path paved properly we can get down it much faster and easier.
Imagine the blockchain bloat if we add Ring Signature in BitShares
...
But without money we can't do anything. No money, no honey.
+5% +5%
-
Maybe it's over simplistic but ...
What if Bts Munich (or anyone wanting to step up) set up a worker of 3-5k (tiny sum, would be voted for sure) to pay for expenses to set up a ICO campain to sell a global FBA that would support development for blinded Tx, Stealth, bond market, rate limitex fee ... ).
We would have the funds to finish what BitShares needs to get back on the scene with the big guys. FBA would split a decent amount to the network so we keep our long terme profitability goals. The higher market cap after having attention from crypto public would provide more funds to keep evolving (to the m...)
Bitshares Munich seem to be able to do A LOT with small funds. We don't need to gather millions.
We would have an ICO with goals, a simple list of features by money gathered.
ICO : 50k > blinded Tx and rate limited Tx
ICO : 100k > + stealth
ICO : 150k > + bond market
... and so on.
With the right campain, it would be easy to collect 500k. Ppl nowadays jumps on any ICO that looks promising. Besides the FBA token would be tradable right after the ICO, it's a fast way to make money if the FBA token increase in value after the ICO (for a investor perspective)
The other benefit is this campain would get the attention on BitShares, on FBA (very good thing) and finally ppl would expect the market cap to grow in response of amazing features added (this expetation would increase the market cap).
Sent from my SM-G900F using Tapatalk
-
Maybe it's over simplistic but ...
What if Bts Munich (or anyone wanting to step up) set up a worker of 3-5k (tiny sum, would be voted for sure) to pay for expenses to set up a ICO campain to sell a global FBA that would support development for blinded Tx, Stealth, bond market, rate limitex fee ... ).
We would have the funds to finish what BitShares needs to get back on the scene with the big guys. FBA would split a decent amount to the network so we keep our long terme profitability goals. The higher market cap after having attention from crypto public would provide more funds to keep evolving (to the m...)
Bitshares Munich seem to be able to do A LOT with small funds. We don't need to gather millions.
We would have an ICO with goals, a simple list of features by money gathered.
ICO : 50k > blinded Tx and rate limited Tx
ICO : 100k > + stealth
ICO : 150k > + bond market
... and so on.
With the right campain, it would be easy to collect 500k. Ppl nowadays jumps on any ICO that looks promising. Besides the FBA token would be tradable right after the ICO, it's a fast way to make money if the FBA token increase in value after the ICO (for a investor perspective)
The other benefit is this campain would get the attention on BitShares, on FBA (very good thing) and finally ppl would expect the market cap to grow in response of amazing features added (this expetation would increase the market cap).
Sent from my SM-G900F using Tapatalk
I want to see Bitshares Munich do stuff, especially in co-operation with other community members/companies.
However I doubt that someone would join an ICO, apart from community members for features that won't make them profit. For example, why would someone join an ICO for the Maker/Taker, Autobridging or Rate limited fees etc, if he is not going to make money out of it. I think that that token should at least be backed by BTS tokens or be BTS themselves.
A solution could be a worker paying BTS to that Fee-Backed Asset which would stop receiving payments after a certain amount of BTS is reached.
Would anyone consider monthly contracts for workers? Having just daily payments is ridiculous without a contract is ridiculous...
Again, I would like to know what people think of the Multigateway, where people deposit coins with the Supernet client and then trade them as NXT assets.
-
Maybe I missunderstood how FBA works. I had in mind that when you own an FBA you have a % of each Tx fee from the feature you paid for.
As an example, if someone would fund stealth, he would benefit from each Tx fee on stealth transfer (ex : 20% for BTS / 80% for him )Besides having his FBA worth its speculative value from the market and beeing able to sell it anytime.
Sent from my SM-G900F using Tapatalk
-
Maybe I missunderstood how FBA works. I had in mind that when you own an FBA you have a % of each Tx fee from the feature you paid for.
As an example, if someone would fund stealth, he would benefit from each Tx fee on stealth transfer (ex : 20% for BTS / 80% for him )Besides having his FBA worth its speculative value from the market and beeing able to sell it anytime.
Sent from my SM-G900F using Tapatalk
I don't think that you misunderstood. You are right. All I am saying is that we would need to do many ICOs, as each feature would require its own FBA. That doesn't make a lot of sense as these assets will end up being illiquid and might be unprofitable in the long run, as the BitShares tokens will be the ones getting most of the value anyways.
Also, if we want to do an ICO for many features, where some of them are not fee related, then we won't be able to get money for those, except if we sell BitShares or some form of BitShares to investors. For example BitShares backed assets, where they will be able to redeem their shares after an x number of months or something like that, which I don't think is a great idea.
After the peerplays crowdsale is over and Waves have launced, it would be great to see an ICO for BitShares.
-
My idea was to try to have the funds to develop all features included in on only FBA.
As we can't know how much funds we would collect, I was thinking of doing it with milestone. Every X thousands $ we add one feature that have fees with one that don't but increase the overall value of BitShares anyway.
I keep thinking if it's well done, we could easily collect what we need to allow BitShares to take off soon. We will be have all these features one day but the big question is ... will it be too late ?
Sent from my SM-G900F using Tapatalk
-
My idea was to try to have the funds to develop all features included in on only FBA.
As we can't know how much funds we would collect, I was thinking of doing it with milestone. Every X thousands $ we add one feature that have fees with one that don't but increase the overall value of BitShares anyway.
I keep thinking if it's well done, we could easily collect what we need to allow BitShares to take off soon. We will be have all these features one day but the big question is ... will it be too late ?
Sent from my SM-G900F using Tapatalk
I see. I think the milestones can be added via BlockTrades and Openledger, in the form of escrow. As I said earlier, we needed a detailed roadmap + timeline, with fund allocation (how much we are going to spent, on what, for how long and who is going to work on these things). We also need to have some excess funds and set some time breathing room i.e 2-3 extra months.
For example : We publish our roadmap and start the ICO. Openledger, Blocktrades + a few more people do the escrow for us. We hardfork after the ICO is over and we transfer the shares to that committee account.
We could either give BitShares to the participants straight away or a BitShares IOU. Why an IOU? Because not all funds are going to be spent and the escrow will still exist, people will be able to exchange their IOUs for BitShares gradually. For example if the roadmap states that the developement is going to last for a year, then people will be receiving BTS over that period. So even if the development stops (I hope it doesn't), for any reason, then at least people can get their BTC back.
This is just an idea. I bet there are many things that we could improve to make it work and get people to join. The CO has to happen and I guess it will happen one way or another. We might have to do stealth first, implement it successfully and then people might be more willing to get in a bigger CO (even if I wouldn't prefer a smaller and then a bigger CO).
I would like to see Rate limited fees, Autobridging, Maker/Taker, Negative Fees, Smartcoin Park rates, Bond Market, MetaTrader Integration, Trading Bots first and then Stealth and possibly sidechains. I made this post to say why I don't want them, but if the community thinks it is fine to add them and everyone agrees then I will step back and I will still join the coin offering. I would also like to see improvements on the voting mechanisms based on the Dash voting model and I definitely want to see contracts being implemented.
We need to act soon. Waves are a direct competitors, of unknown quality, however they have 16MUSD and they can definitely learn from the past mistakes of each crypto... For the features I mentioned we need about 300.000$ to 500.000$, if we consider the work needed to be done on the GUI.
If we haven't done all this in the next 1 to 1.5 years, then I am afraid we are done...
-
What if Bts Munich (or anyone wanting to step up) set up a worker of 3-5k (tiny sum, would be voted for sure) to pay for expenses to set up a ICO campain to sell a global FBA that would support development for blinded Tx, Stealth, bond market, rate limitex fee ... ).
Now this idea I like. I could use the worker to set everything up rather quickly too, I can get quite a bit done with just minimal capital.
Bitshares Munich seem to be able to do A LOT with small funds. We don't need to gather millions.
You just made my day with that comment, thank you Estefan :)
We would have an ICO with goals, a simple list of features by money gathered.
ICO : 50k > blinded Tx and rate limited Tx
ICO : 100k > + stealth
ICO : 150k > + bond market
... and so on.
As you guys already know, I milestone every job I undertake so this is a given. We would not need that much money though, but I see how we could break all of this up into an ongoing milestones-project. Don't forget recurring/scheduled payments, margin trading and lots of tools for pro-traders, enough to snag them away from the likes of polo, thinkorswim, etc.
With the right campain, it would be easy to collect 500k. Ppl nowadays jumps on any ICO that looks promising. Besides the FBA token would be tradable right after the ICO, it's a fast way to make money if the FBA token increase in value after the ICO (for a investor perspective)
The other benefit is this campain would get the attention on BitShares, on FBA (very good thing) and finally ppl would expect the market cap to grow in response of amazing features added (this expetation would increase the market cap).
+5% +5% chris and rodrigo are handling all of the financials and legal stuff. we're on it.
-
Maybe I missunderstood how FBA works. I had in mind that when you own an FBA you have a % of each Tx fee from the feature you paid for.
As an example, if someone would fund stealth, he would benefit from each Tx fee on stealth transfer (ex : 20% for BTS / 80% for him )Besides having his FBA worth its speculative value from the market and beeing able to sell it anytime.
Exactly, if we sell off some of the STEALTH FBA, then those Stealth holders will get rewarded for every token they hold, for every stealth transaction that is processed, by everyone interacting with our chain.
-
I would like to see Rate limited fees, Autobridging, Maker/Taker, Negative Fees, Smartcoin Park rates, Bond Market, MetaTrader Integration, Trading Bots first and then Stealth and possibly sidechains. I made this post to say why I don't want them, but if the community thinks it is fine to add them and everyone agrees then I will step back and I will still join the coin offering. I would also like to see improvements on the voting mechanisms based on the Dash voting model and I definitely want to see contracts being implemented.
We need to act soon. Waves are a direct competitors, of unknown quality, however they have 16MUSD and they can definitely learn from the past mistakes of each crypto... For the features I mentioned we need about 300.000$ to 500.000$, if we consider the work needed to be done on the GUI.
+5% +5% +5%
First STEALTH FBA offering, then Worker to fund the ICO offering, then milestone-projects for all of our top requests. Once that third step is reached we will run a Poll to find out which features to knock out first. I'll put the Poll on steemit.com too of course.
-
We would just have to create a long list of everything we dream of and decide by priority to arrange them in the list. Then, the more money we have the more features we can add.
Metatrader API, new GUI and other cool thing we don't expect until a long time.
The main thing is find a way to explain how the FBA can be very valuable for someone buying in the ICO. The % of fees ... forever unless someone want to sell their FBA and probably get their money back (or more). Explain that with all theses new features, BitShares will compete with the big players and the FBA is a way to invest in this very crucial step and have a income from several features on BitShares and bla bla bla ...
I think the effect would be double. People finding this ICO would invest not only in the ICO but also in BTS. It makes more sense. So BTS should rise if the ICO is a success.
So the ICO should also describe how far we are at the moment and the capabilities of BTS as it is now.
FBA have been created exactely for that purpose, let's get the more of it !
Sent from my SM-G900F using Tapatalk
-
+5% +5%
BitShares Munich is definitely consider this.
It's too bad an FBA reqiuires a hard fork though, can't we soften that? I foresee many companies wanting to "go public" in this way. We are building so many products now that it only makes sense.
-
I like this idea...wont be easy......but I believe is a pretty rasonable path.
-
@arhag Would Stealth benefit from the use of Schnorr Signatures in any way?
Anyone think this route would be better than going with CN, CT, CCT, ZKT, etc?
Remember, if Stealth is totally anonymous and untraceable, choosing the right path now (and for the next 5+ years) is imperative.
edit: https://en.wikipedia.org/wiki/Schnorr_signature
-
@arhag Would Stealth benefit from the use of Schnorr Signatures in any way?
Anyone think this route would be better than going with CN, CT, CCT, ZKT, etc?
A Schnorr signature by itself doesn't get you any privacy benefits that a ring signature (or Zerocash's complicated zkSNARKs) would give you. It is just another way to do signatures as an alternative to the ECDSA that is currently used in BitShares (and Bitcoin and most other altcoins). Now I do think a Schnorr signature is better (for example it very nicely allows for arbitrarily large efficient threshold signatures). And I would very much love to see BitShares eventually use EdDSA (https://en.wikipedia.org/wiki/EdDSA). But that is sort of unrelated to the topic at hand.
Did you say you had a cryptography guy helping you with this process? Because if you want to build something that goes beyond simply implementing a GUI for the existing blinded transfer feature, then that is really important.
-
regarding sidechain, I feel what you said is that we haven't found a secure solution for that, but not "we should not add".
sidechain will help a lot, assuming it is robust/secure enough, it can make the inter chain value transfer more convenient. and then will be no need to have various kind of BTCs and ETHs in DEX.
Ethereum now have the BTCrelay, we also need similar feature.
we do not have to set BTC and ETH also collateral, if it is not risk free.
maybe we haven't got an acceptable solution for this, but we need to find such a solution
-
@arhag Would Stealth benefit from the use of Schnorr Signatures in any way?
Anyone think this route would be better than going with CN, CT, CCT, ZKT, etc?
A Schnorr signature by itself doesn't get you any privacy benefits that a ring signature (or Zerocash's complicated zkSNARKs) would give you. It is just another way to do signatures as an alternative to the ECDSA that is currently used in BitShares (and Bitcoin and most other altcoins). Now I do think a Schnorr signature is better (for example it very nicely allows for arbitrarily large efficient threshold signatures). And I would very much love to see BitShares eventually use EdDSA (https://en.wikipedia.org/wiki/EdDSA). But that is sort of unrelated to the topic at hand.
Did you say you had a cryptography guy helping you with this process? Because if you want to build something that goes beyond simply implementing a GUI for the existing blinded transfer feature, then that is really important.
Yes, and yes.
For Stealth to be the "killer app" for anon and untrace tho we have to choose the right components here, think about the nsa and other orgs that may hate this kind of technology, those are the things I want to solve, or at least as close as what avail tech has to offer.
-
regarding sidechain, I feel what you said is that we haven't found a secure solution for that, but not "we should not add".
sidechain will help a lot, assuming it is robust/secure enough, it can make the inter chain value transfer more convenient. and then will be no need to have various kind of BTCs and ETHs in DEX.
Ethereum now have the BTCrelay, we also need similar feature.
we do not have to set BTC and ETH also collateral, if it is not risk free.
maybe we haven't got an acceptable solution for this, but we need to find such a solution
I mentioned that in some of my recent comments in this post. I agree that there might be a secure implementation and I made clear that I disagreed with the one currently proposed by BM. However... Regardless of how secure that implementation is, one vulnurability, one bug, and we are done...
I mentioned many times the Multigateway of NXT/SuperNET, but nobody seems to have approached them.
Also, if we build our DEX appropriately and add all the good trading features, think of how many more startups and blockchain companies would like to use BitShares. It doesn't have to be us that will build this really expensive and potentially dangerous feature. You go from the bottom to the top, not the other way round. In the end, Ronny might be able to do the sidechain with his 'DC' or some other company/individual, and earn fees from the FBA.
@arhag Would Stealth benefit from the use of Schnorr Signatures in any way?
Anyone think this route would be better than going with CN, CT, CCT, ZKT, etc?
A Schnorr signature by itself doesn't get you any privacy benefits that a ring signature (or Zerocash's complicated zkSNARKs) would give you. It is just another way to do signatures as an alternative to the ECDSA that is currently used in BitShares (and Bitcoin and most other altcoins). Now I do think a Schnorr signature is better (for example it very nicely allows for arbitrarily large efficient threshold signatures). And I would very much love to see BitShares eventually use EdDSA (https://en.wikipedia.org/wiki/EdDSA). But that is sort of unrelated to the topic at hand.
Did you say you had a cryptography guy helping you with this process? Because if you want to build something that goes beyond simply implementing a GUI for the existing blinded transfer feature, then that is really important.
Yes, and yes.
For Stealth to be the "killer app" for anon and untrace tho we have to choose the right components here, think about the nsa and other orgs that may hate this kind of technology, those are the things I want to solve, or at least as close as what avail tech has to offer.
I am still anxiously waiting for the final announcement. I would like some of this things to be included in your announcement.
What will happen in case that the community is against that proposal?
Do you have just one variation or have you got different potential implementations that could be added?
How big is your team of cryptographers and what are some of their previous projects that they were involved in and why did you chose them?
How much is the total cost?
How do you plan to cover the GUI costs?
Why do you think that optional privacy is any good at all? It has been pointed out many times by many, that not having the whole chain private is really bad for the privacy of those who try to stay private. http://weuse.cash/2016/06/09/btc-xmr-zcash/ this is a very good article that explains everything.
Will on chain backups be necessary in order to make sure?
Who is going to be the escrow in the asset sale?
How will ensure that nothing is going to go wrong and in case something does go wrong what are you going to do? What are you going to do if the chain is denonymised? Who is going to fund the development to fix it?
By the way what is the IPFS that you keep mentioning?
-
Great questions, those and many more will be answered in time once we get the details hammered down, job descrip and milestones defined.
-
That is an inspiring discussion and many great idears are poping up! Short note from my side.
We are talking with a couple of retails chains (+40,000 supermarkets) and they are very concert about the data security, ownership and transparency. The are looking for a cheaper and faster payment rail network. BitShares with their DEX could be a good option for them. However lets say we have MC Donalds and BurgerKing on the Platform, both companies want to keep their daily transactions cloacked. Nobody wants to be analyized by their direct competitors! One option would be permission and permission less ledgers, but since BitShares is a open payment network stealth transactions are elematary for our future growth.
With stealth in place we can do both. Show all transaction in public or hide certain transactions.
Talking about the future roadmap:
In my effort to desing the new BitShares.org website I also saved most of the future features that we would like to see at BitShares. Please check here. I am talking with some graphic guys to get the design for the site down.
https://docs.google.com/document/d/1Xw4o-99EXCPg301mzE6CCm6XOOHGqVVfpeQiWilZkXM/edit
Roadmap items on the bottom. I plan to add them all on the new website.