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

0 Members and 1 Guest are viewing this topic.

tarantulaz

  • Guest
Re: My opinion on why Stealth, Backups and Sidechains should not be added
« Reply #15 on: June 09, 2016, 11:37:42 am »
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 [member=30868]kenCode[/member] about his Stealth plans. A few days ago he said that we should be expecting an announcement soon. [member=18133]arhag[/member] 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 [member=19864]BunkerChain Labs[/member] ?

Offline dannotestein

  • Hero Member
  • *****
  • Posts: 739
    • View Profile
    • BlockTrades International
  • BitShares: btsnow
Re: My opinion on why Stealth, Backups and Sidechains should not be added
« Reply #16 on: June 09, 2016, 01:51:21 pm »
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

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2240
    • View Profile
    • Agorise
Re: My opinion on why Stealth, Backups and Sidechains should not be added
« Reply #17 on: June 09, 2016, 02:37:13 pm »
I would also like to hear from [member=30868]kenCode[/member] about his Stealth plans. A few days ago he said that we should be expecting an announcement soon. [member=18133]arhag[/member] 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.
 
[member=18133]arhag[/member] 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
Telegram: https://t.me/Agorise - Github: https://github.com/Agorise

Offline dannotestein

  • Hero Member
  • *****
  • Posts: 739
    • View Profile
    • BlockTrades International
  • BitShares: btsnow
Re: My opinion on why Stealth, Backups and Sidechains should not be added
« Reply #18 on: June 09, 2016, 02:43:11 pm »
I would also like to hear from [member=30868]kenCode[/member] about his Stealth plans. A few days ago he said that we should be expecting an announcement soon. [member=18133]arhag[/member] 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.
 
[member=18133]arhag[/member] 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 xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12896
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Re: My opinion on why Stealth, Backups and Sidechains should not be added
« Reply #19 on: June 09, 2016, 03:26:36 pm »
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
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu powered by ChainSquad GmbH

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Re: My opinion on why Stealth, Backups and Sidechains should not be added
« Reply #20 on: June 09, 2016, 03:39:47 pm »
[member=30868]kenCode[/member], I agree with [member=11]dannotestein[/member] 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 »

tarantulaz

  • Guest
Re: My opinion on why Stealth, Backups and Sidechains should not be added
« Reply #21 on: June 09, 2016, 04:32:18 pm »
I would also like to hear from [member=30868]kenCode[/member] about his Stealth plans. A few days ago he said that we should be expecting an announcement soon. [member=18133]arhag[/member] 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.
 
[member=18133]arhag[/member] 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?

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12896
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Re: My opinion on why Stealth, Backups and Sidechains should not be added
« Reply #22 on: June 09, 2016, 04:39:49 pm »
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.
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.
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu powered by ChainSquad GmbH

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2240
    • View Profile
    • Agorise
Re: My opinion on why Stealth, Backups and Sidechains should not be added
« Reply #23 on: June 09, 2016, 04:41:34 pm »
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 [member=18133]arhag[/member] 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 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.
kenCode - Decentraliser @ Agorise
Telegram: https://t.me/Agorise - Github: https://github.com/Agorise

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Re: My opinion on why Stealth, Backups and Sidechains should not be added
« Reply #24 on: June 09, 2016, 05:00:38 pm »
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.
 
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.

Offline dannotestein

  • Hero Member
  • *****
  • Posts: 739
    • View Profile
    • BlockTrades International
  • BitShares: btsnow
Re: My opinion on why Stealth, Backups and Sidechains should not be added
« Reply #25 on: June 09, 2016, 05:13:39 pm »
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.
« Last Edit: June 09, 2016, 05:26:16 pm by dannotestein »
http://blocktrades.us Fast/Safe/High-Liquidity Crypto Coin Converter

Offline Stan

  • Hero Member
  • *****
  • Posts: 2905
  • You need to think BIGGER, Pinky...
    • View Profile
    • Cryptonomex
  • BitShares: Stan
Re: My opinion on why Stealth, Backups and Sidechains should not be added
« Reply #26 on: June 09, 2016, 05:19:29 pm »
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?

Anything said on these forums does not constitute an intent to create a legal obligation or contract of any kind.   These are merely my opinions which I reserve the right to change at any time.

Offline dannotestein

  • Hero Member
  • *****
  • Posts: 739
    • View Profile
    • BlockTrades International
  • BitShares: btsnow
Re: My opinion on why Stealth, Backups and Sidechains should not be added
« Reply #27 on: June 09, 2016, 05:27:17 pm »
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.
http://blocktrades.us Fast/Safe/High-Liquidity Crypto Coin Converter

Offline BunkerChainLabs-DataSecurityNode

Re: My opinion on why Stealth, Backups and Sidechains should not be added
« Reply #28 on: June 09, 2016, 05:41:57 pm »
Blinded transfers as [member=18133]arhag[/member] and [member=11]dannotestein[/member] have already outlined for the win.

[member=30868]kenCode[/member] 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. [member=18133]arhag[/member] backup to the blockchain solution is the elegant reliable and sellable choice.

Really excited about the prospects of blinded transfers!!!
+-+-+-+-+-+-+-+-+-+-+
www.Peerplays.com | Decentralized Gaming Built with Graphene - Now with BookiePro!
+-+-+-+-+-+-+-+-+-+-+

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Re: My opinion on why Stealth, Backups and Sidechains should not be added
« Reply #29 on: June 09, 2016, 05:43:12 pm »
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.
« Last Edit: June 09, 2016, 05:45:31 pm by arhag »