My opinion on why Stealth, Backups and Sidechains should not be added

[bitsharesbrazil]

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?

[tarantulaz]

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.

[bitsharesbrazil]

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.

[tarantulaz]

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).

[BunkerChainLabs-DataSecurityNode]

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.

[tarantulaz]

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.

[arhag]

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.

 

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.

[BunkerChainLabs-DataSecurityNode]

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!!!

[dannotestein]

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.

[Stan]

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?

[dannotestein]

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.

[arhag]

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.

[kenCode]

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 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.

[xeroc]

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.

[tarantulaz]

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?