Author Topic: My opinion on why Stealth, Backups and Sidechains should not be added  (Read 10092 times)

0 Members and 1 Guest are viewing this topic.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
@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 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.
« Last Edit: June 09, 2016, 03:47:14 pm by arhag »

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12919
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
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

Offline dannotestein

  • Hero Member
  • *****
  • Posts: 760
    • View Profile
    • BlockTrades International
  • BitShares: btsnow
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.
http://blocktrades.us Fast/Safe/High-Liquidity Crypto Coin Converter

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
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.
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline dannotestein

  • Hero Member
  • *****
  • Posts: 760
    • View Profile
    • BlockTrades International
  • BitShares: btsnow
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.
« Last Edit: June 09, 2016, 02:02:39 pm by dannotestein »
http://blocktrades.us Fast/Safe/High-Liquidity Crypto Coin Converter

tarantulaz

  • Guest
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 ?

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4570
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
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..
« Last Edit: June 09, 2016, 01:35:07 pm by abit »
BitShares committee member: abit
BitShares witness: in.abit

Offline bitsharesbrazil

  • Sr. Member
  • ****
  • Posts: 243
    • View Profile
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
bitcointalk ANN https://bitcointalk.org/index.php?topic=1084460.0
chat, post, promote it!!!!!!!! Stan help to improve OP!

Offline dannotestein

  • Hero Member
  • *****
  • Posts: 760
    • View Profile
    • BlockTrades International
  • BitShares: btsnow
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.
http://blocktrades.us Fast/Safe/High-Liquidity Crypto Coin Converter

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
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.

Offline dannotestein

  • Hero Member
  • *****
  • Posts: 760
    • View Profile
    • BlockTrades International
  • BitShares: btsnow
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.
http://blocktrades.us Fast/Safe/High-Liquidity Crypto Coin Converter

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
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.

tarantulaz

  • Guest
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?

Offline karnal

  • Hero Member
  • *****
  • Posts: 1068
    • View Profile
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)

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
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.