BitShares Forum
Main => General Discussion => Topic started by: bytemaster on April 04, 2016, 05:33:54 pm
-
I want to take a moment to give everyone an update on where we are with STEALTH.
The hardfork today will allow us to transfer the STEALTH asset to @onceuponatime and the blockchain will be fully functional from that perspective.
The GUI release here: https://github.com/bitshares/bitshares-2/releases/tag/2.0.160323-stealth-beta implements an interface and set of functionality that we outlined in the proposal.
The server-side wallet storage was not part of the proposal, but something we felt was necessary to backup/secure user funds. We do not yet have confidence in the reliability of server-side storage to enable this feature. There is a significant about of liability associated in offering to host/backup user wallets. We don't want to be responsible for the loss of funds.
With todays hardfork and enabling of the fee-backed-asset along with the windows binaries we will release the STEALTH worker will technically be completed to spec. We were late and over budget so have actually lost money on this worker.
That said, I am not happy with the resulting product and user experience. It is still too hard to use for most people and therefore, it is reasonable to expect few will use it.
In an effort to make things right for everyone, especially @onceuponatime, we intend to implement an alternative in the months ahead:
Blind Transfers with Public Accounts
In this mode everyone will be able to tell which accounts are transacting with each other, but be unable to know the amounts involved. The impact is that you would be able to tell if someone sent money to an exchange, but would be unable to know how much. Furthemore, your
account balance would be completely private.
With this mode of operation it is possible to make blind transfers the default mode of operation while maintaining the same interface we have for normal transactions. A simple checkbox can be used to enable public/free transfers.
This interface will generate many more STEALTH transfers and improve everyone's privacy while at the same time enabling the holders of the STEALTH asset to make more revenue.
We cannot promise a particular schedule for this enhancement, but will state that we intend to work toward it. We want to make sure that people can actually use privacy enhancing features and that @onceuponatime has a reasonable chance to recoup his investment.
-
Making transactions default blinded sounds like a great idea, IMO. Currently I think transactions are a little "too public".
-
Perhaps @onceuponatime will consider immediately selling some of the stealth asset in order to not only recoup a chunk of his investment, but also to raise some funds to speed up implementation of stealth transfers / private balances. This is a critical feature. The sooner it gets implemented, the faster the Bitshares adoption rate will increase, and the sooner @onceuponatime will be in the black on his investment.
-
I think that's a good approach BM
+5%
-
Perhaps @onceuponatime will consider immediately selling some of the stealth asset in order to not only recoup a chunk of his investment, but also to raise some funds to speed up implementation of stealth transfers / private balances. This is a critical feature. The sooner it gets implemented, the faster the Bitshares adoption rate will increase, and the sooner @onceuponatime will be in the black on his investment.
Yes, let's do the stealth token sale. If I was onceuponatime i'd give 5% to someone for organizing and outlining properly what needs to be done, including a crowd-sale and an independent stealth wallet with unique branding and marketing. This project needs more than some devs and an investor, it needs a savvy entrepreneur who can take it to the next level. Now that you have the basic tech in place and a token to represent the value of the project, there's nothing stopping you from making this project as big as you want. /2 cents
-
Making transactions default blinded sounds like a great idea, IMO. Currently I think transactions are a little "too public".
+5%
-
Different voices here:
Who decided that one can add whatever feature to BitShares at will, even it's "for free"?
Why should any new feature split 80% to Mr. Once or the STEALTH asset holder, and let them decide the fee rate beyond the committee (read: stake holders)?
-
Different voices here:
Who decided that one can add whatever feature to BitShares at will, even it's "for free"?
Why should any new feature split 80% to Mr. Once or the STEALTH asset holder, and let them decide the fee rate beyond the committee (read: stake holders)?
That has been approved by shareholders by means of a voted worker for the corresponding BSIP ... IIRC
-
Different voices here:
Who decided that one can add whatever feature to BitShares at will, even it's "for free"?
Why should any new feature split 80% to Mr. Once or the STEALTH asset holder, and let them decide the fee rate beyond the committee (read: stake holders)?
That has been approved by shareholders by means of a voted worker for the corresponding BSIP ... IIRC
1. Details of the approval? it includes adding any new feature?
2. BSIP10 hasn't been approved? Apparently this feature will reduce the value of BSIP10, which is designed to feed the referral program.
3. All balances hidden? So how will it affect the "rate limited free transaction" feature?
4. This feature is one of the "stable core features of BitShares" mentioned in last week?
-
Different voices here:
Who decided that one can add whatever feature to BitShares at will, even it's "for free"?
Why should any new feature split 80% to Mr. Once or the STEALTH asset holder, and let them decide the fee rate beyond the committee (read: stake holders)?
That has been approved by shareholders by means of a voted worker for the corresponding BSIP ... IIRC
1. Details of the approval? it includes adding any new feature?
2. BSIP10 hasn't been approved? Apparently this feature will reduce the value of BSIP10, which is designed to feed the referral program.
3. All balances hidden? So how will it affect the "rate limited free transaction" feature?
4. This feature is one of the "stable core features of BitShares" mentioned in last week?
Doing STEALTH or not is a client side decision and thus depends on the wallet implementation. Not on the backend code.
Also, not all assets allow blinded transfers for legal and technical reasons .. there are plenty of usecases that cant makt use of stealth.
That said, i understand your frustration that BM again again takes the lead and makes decisions without prior discussion.
-
Different voices here:
Who decided that one can add whatever feature to BitShares at will, even it's "for free"?
Why should any new feature split 80% to Mr. Once or the STEALTH asset holder, and let them decide the fee rate beyond the committee (read: stake holders)?
That has been approved by shareholders by means of a voted worker for the corresponding BSIP ... IIRC
1. Details of the approval? it includes adding any new feature?
2. BSIP10 hasn't been approved? Apparently this feature will reduce the value of BSIP10, which is designed to feed the referral program.
3. All balances hidden? So how will it affect the "rate limited free transaction" feature?
4. This feature is one of the "stable core features of BitShares" mentioned in last week?
Doing STEALTH or not is a client side decision and thus depends on the wallet implementation. Not on the backend code.
Also, not all assets allow blinded transfers for legal and technical reasons .. there are plenty of usecases that cant makt use of stealth.
That said, i understand your frustration that BM again again takes the lead and makes decisions without prior discussion.
As long as changes are not made on the back end, I'm fine.
-
@bytemaster
You mention our account balance can be hidden, how so? If Account A has 100 bts and blind transfers to account B 100bts with the blind feature, we can still see Account A HAD 100bts and now has 0? We can easily assume Account B now has 100bts. What am I missing here? Is the only way to gain true stealth still through a mixing service? This appears to be similar to 0.93?
Once a balance is hidden, how will it effect voting?
Can additional features be added to hide things like who we are voting for? Our white/black lists? Assets? Permissions?
Another example is when we browse a user's ID, why does the membership option even appear? Perhaps removing things like this could minimize data usage and lower latency?
-
How disappointing. I was hoping stealth would be approached more carefully than previous UI dev efforts but it appears that wasn't to be. I contributed my perspective, tho limited, early on but it was not considered or discussed. Ultimately it was Once's call to decide if he accepted the design spec. He pushed back at several points, but mostly on the business aspects not much on the UI design.
I wished there were more design discussions before the work began, however as usual there is always pressure to finalize the design and get on with implementation.
Just today I was using the wallet and thinking to myself it is finally (6 months after initial release) looking very good now. There is always room for improvement and unless you have set specific design goals development will never end. Its setting the goals / milestones that provide a way to measure progress and know when objectives are complete. There is a definite lack of such planning by CNX. What is the right balance between agility to react to market forces and the stability of establishing a plan to guide the trajectory of progress? I don't know but I know they haven't found it yet!
Good UI design takes a great deal of planning. Cut that short and the results will not be optimal.
I also agree with abit's comments. CNX can implement a blind transfer feature, but it should not be up to CNX if that feature is deployed into the BitShares. Expectations have already been set and blind transfers were not among them. Rather than giving up and implementing some other privacy feature (and why should we expect that will be implemented any better than the attempt to implement stealth?), why not take some time to see what went wrong and make an attempt to correct those things and go at it again with a better approach? Why divert resources in another direction?
@bytemaster - what is it about the UI / UX you don't like? What is so bad it can't be fixed with less effort than implementing a blind transaction feature? I don't see how blind transfers could be done without changes to both frontend AND backend.
-
oh, F**K -5%-5%
-
What if Stealth cause more issues (bugs , other negative impact like performance, scalability even user safety ) , some may even been realized after one year , who will pay for fixing the bugs ?
Will that be one of those things where "if you don't pay , the blockchain will suck , so the reality is ...."
So is this really a total private funded project in this aspect ?
Will there be a fund paid by the private money dedicated to maintain all related bug fixes now and in the future if any bug were introduced on the blockchain because of this feature ?
-
What if Stealth cause more issues (bugs , other negative impact like performance, scalability even user safety ) , some may even been realized after one year , who will pay for fixing the bugs ?
Will that be one of those things where "if you don't pay , the blockchain will suck , so the reality is ...."
So is this really a total private funded project in this aspect ?
Will there be a fund paid by the private money dedicated to maintain all related bug fixes now and in the future if any bug were introduced on the blockchain because of this feature ?
That was planned for from the inception:
4. Fees shall be automatically distributed by the blockchain to the following accounts:
o 20% to the BitShares network.
o 20% to a Maintenance Account.
o 60% to holder(s) of the Privacy Mode Fees accumulation account
-
o 20% to a Maintenance Account.
The problem is that if there are too many bugs, not so many STEALTH transactions will happen, so 20% taken from about nothing will not be enough to pay for maintenance...no?
From the other side 20% is a steal when it gets... bug free... so I see some motivation for CNX to work on this further... (seems that STEEM has more priority now)
-
Let's kick stealth into overdrive now, we will do whatever we can to pitch in here!
-
Let's kick stealth into overdrive now, we will do whatever we can to pitch in here!
So is stealth going to ever be usable or is it being replaced with blind transactions? Blind transactions feel like more of a band aid than anything else.
-
Let's kick stealth into overdrive now, we will do whatever we can to pitch in here!
So is stealth going to ever be usable or is it being replaced with blind transactions? Blind transactions feel like more of a band aid than anything else.
Blinded transactions are a sub-unit of STEALTH which consists also of stealth addresses
-
I don't like private profits being made from something that should be a core feature of bitshares.
I understand and appreciate that @onceuponatime has taken on risk and reduced sell pressure on BTS get Stealth asset implemented but I think this feature would be better as just a standard feature .
I'd like to see @onceuponatime to sell this feature to bitshares and delete the Stealth asset.
He could sell it for whatever he paid +25% to cover costs and make a profit. This could be done as a worker proposal.
I've never thought Fee Backed Assets for core bitshares functions made any sense whatsoever.
-
I don't like private profits being made from something that should be a core feature of bitshares.
I understand and appreciate that @onceuponatime has taken on risk and reduced sell pressure on BTS get Stealth asset implemented but I think this feature would be better as just a standard feature .
I'd like to see @onceuponatime to sell this feature to bitshares and delete the Stealth asset.
He could sell it for whatever he paid +25% to cover costs and make a profit. This could be done as a worker proposal.
I've never thought Fee Backed Assets for core bitshares functions made any sense whatsoever.
Well, the community had a chance to fund it and would up relying on private investment. To lobby after the fact to change the rules is very damaging to the possibility of further such investment. It's really the same bad rep we get when someone starts a worker project and then gets voted out before they can finish it. I, for one, will have no part in trying to pressure Onceup to give up what he took the ultimate personal risk to make possible.
-
So, the important question is:
Can I use stealth transactions or not?.. I dont see any options at the GUI and all the Tokens still belong to BM..
-
I, for one, will have no part in trying to pressure Onceup to give up what he took the ultimate personal risk to make possible.
Was he aware of the fact that the dev leader would put all his energy to a new project called STEEM?
One of the reason you call it ultimate risk ... is this fact?
-
So, the important question is:
Can I use stealth transactions or not?.. I dont see any options at the GUI and all the Tokens still belong to BM..
Yes, you can use them via the dedicated wallet.
Onceuponatime will have his STEALTH asset today.
Our developers made STEALTH #1 priority over STEEM. Ben, James, and Val have been dedicated to STEALTH this whole time (hence, no Steem UI).
In any event, onceuponatime and I have been talking about the project and I believe he is very happy with how we have taken care of him.
-
as for how to actually use this -- if anyone on the network does one of the stealth ops, the fees will be accumulated in an object and then sent to stealth-buyback account at the next maintenance interval. a v-op will be produced at that time (so you only get one v-op per maint interval instead of spamming the stealth-buyback history every time someone does a stealth tx). during each maintenance interval stealth-buyback account automatically attempts to use its BTS balance to buy as much STEALTH as possible on the market, generating a market order v-op (immediately followed by a cancel v-op if it can't be fully matched). you can basically monitor the stealth-buyback account history if you're interested in the finance. (ok, i guess technically that's up to three v-ops per maint interval total)
Onceuponatime now has 1M stealth and can distribute them to his partners and/or sell them on the internal market.
-
Jeepers! Well done DEVS for getting this far with the stealth functionality! It's really ok if there's a bit more work (assuming Onceuponatime is happy.) Thank you for putting additional work in because it was actually more difficult or time-consuming than originally planned for. Onceuponatime, thank you so much for putting up your capital to make sure this happened. I for one appreciate any reasonable attempts to add functionality to BitShares......i hope you are amply rewarded for the risks you took!!
-
Personally don't care much for stealth (I do recognize the strategic value) but blinded amounts is kinda cool. My concern would be impacted GUI performance like we had with TITAN.
The server-side wallet storage was not part of the proposal, but something we felt was necessary to backup/secure user funds. We do not yet have confidence in the reliability of server-side storage to enable this feature. There is a significant about of liability associated in offering to host/backup user wallets. We don't want to be responsible for the loss of funds.
Why not backup wallets directly on the blockchain? Along with a hash of the owner's email for easy lookups later. And maybe some random noise.
-
I don't like private profits being made from something that should be a core feature of bitshares.
I understand and appreciate that @onceuponatime has taken on risk and reduced sell pressure on BTS get Stealth asset implemented but I think this feature would be better as just a standard feature .
I'd like to see @onceuponatime to sell this feature to bitshares and delete the Stealth asset.
He could sell it for whatever he paid +25% to cover costs and make a profit. This could be done as a worker proposal.
I've never thought Fee Backed Assets for core bitshares functions made any sense whatsoever.
Well, the community had a chance to fund it and would up relying on private investment. To lobby after the fact to change the rules is very damaging to the possibility of further such investment. It's really the same bad rep we get when someone starts a worker project and then gets voted out before they can finish it. I, for one, will have no part in trying to pressure Onceup to give up what he took the ultimate personal risk to make possible.
I think we need to figure out some community rules for how FBA features could potentially be given back to BTS holders in the future for any new FBA we wish to approve.
For example, perhaps if more than 90% of a FBA holders vote to hand back control of their feature to BTS, that gives the community permission to:
1) choose some "fair" price of the FBA based on the recent market price history of the FBA trading on the DEX; and,
2) with the permission of the majority of BTS holders, hard fork the DAC to pay all FBA holders (other than the committee account) at the previously mentioned price (using sufficient funds accumulated in the committee account), destroy the FBA, and allow control of the FBA's feature to be given fully to the DAC.
If all FBA investors know these rules ahead of time, it becomes appropriate for BTS holders to optionally support the following procedure to gain control over the FBA feature:
1) BTS holders vote for workers that pay the committee account for the sole purpose of using those funds to buy the FBA over time at "reasonable" prices.
The worker would have to include some kind of information of what maximum price the committee would be authorized to pay for the FBA, although the committee would try to be smart about the orders they place to try to get good deals even if that delays acquiring the FBA. BTS holders could always stop voting for existing workers and vote new workers to change the price limits on the orders they are willing to authorize the committee to make.
2) As the committee accumulates the FBA they buy, they would also be accumulating the fees from the usage of the FBA's feature. It would be the committee's responsibility to either use these fees to buy more of the FBA or instead send those fees to the BTS reserve pool depending on what the currently active worker authorized them to do.
3) If the committee ends up accumulate more than 90% of the FBA supply, they would lock in the "fair" settling price at that time. They would then move onto the second stage which is to continue raising enough funds from workers to pay off the remaining less than 10% of holders at the "fair" price. The worker voted by BTS holders to pay them would also act as support from BTS stakeholders to do the hard fork later when possible.
4) Finally, when enough funds have been accumulated for this purpose in the committee account, everyone would update to a new client which would trigger the hard forking mechanism described above to pay the remaining less than 10% the "fair" price using the funds in the committee account, and then destroy the FBA so that the feature ends up fully in the control of BTS holders.
If everyone investing in new FBA assets understands these rules (that more than 90%, or whatever threshold we think is appropriate, of FBA holders can, with the agreement of the majority of BTS holders, force them out of their position at a price that is not determined by them but is nevertheless hopefully not too unreasonable) then BTS holders get a fair mechanism to potentially take control over features that they weren't able/willing to fund back when the feature was considered necessary to have. In fact, if we could get @onceuponatime to agree to a rule like this prior to selling any STEALTH, then we have a mechanism to potentially allow BTS holders to get back control over stealth features.
I think this is very important because I agree with @JonnyBitcoin that stealth is a core feature of BitShares and I very much dislike the idea of BTS holders not having sovereignty over their core features. I preferred funding stealth GUI features with workers rather than the FBA for this reason. Now if we ever want to change the way stealth operations work or interact with the rest of system (the rate-limited free transaction feature or funding the referral program are perfect examples) it is no longer just the decision of BTS holders. It now requires complicated (and less likely to succeed) negotiations between BTS holders and STEALTH holders. This rigidity can prevent us from making the smart decisions to most effectively grow BitShares.
At the same time, not having a way to practically use stealth features could likely have also hindered BitShares adoption. And the fact is that due to the anti-dilution camp, if it wasn't for @onceuponatime we likely wouldn't have a practical way to use stealth for the foreseeable future. So I am thankful for that. I just want to make sure we have some mechanism that is fair to all parties involved which allows us to go back to the better way of managing these features (controlled solely by the BTS holders) in the future when hopefully BTS holders are more willing to dilute.
-
I don't like private profits being made from something that should be a core feature of bitshares.
I understand and appreciate that @onceuponatime has taken on risk and reduced sell pressure on BTS get Stealth asset implemented but I think this feature would be better as just a standard feature .
I'd like to see @onceuponatime to sell this feature to bitshares and delete the Stealth asset.
He could sell it for whatever he paid +25% to cover costs and make a profit. This could be done as a worker proposal.
I've never thought Fee Backed Assets for core bitshares functions made any sense whatsoever.
+5% +5%
-
I don't like private profits being made from something that should be a core feature of bitshares.
I understand and appreciate that @onceuponatime has taken on risk and reduced sell pressure on BTS get Stealth asset implemented but I think this feature would be better as just a standard feature .
I'd like to see @onceuponatime to sell this feature to bitshares and delete the Stealth asset.
He could sell it for whatever he paid +25% to cover costs and make a profit. This could be done as a worker proposal.
I've never thought Fee Backed Assets for core bitshares functions made any sense whatsoever.
+5% +5%
I would support this move as well. The easiest way to do so is to create a worker, get it voted in, and refund once upon a time his money. That would require about 7.5 million BTS. Maximum dilution for about 3 weeks should do the trick if my math is right.
Who thinks we can get that approved by shareholders?
-
I don't like private profits being made from something that should be a core feature of bitshares.
I understand and appreciate that @onceuponatime has taken on risk and reduced sell pressure on BTS get Stealth asset implemented but I think this feature would be better as just a standard feature .
I'd like to see @onceuponatime to sell this feature to bitshares and delete the Stealth asset.
He could sell it for whatever he paid +25% to cover costs and make a profit. This could be done as a worker proposal.
I've never thought Fee Backed Assets for core bitshares functions made any sense whatsoever.
+5% +5%
I would support this move as well. The easiest way to do so is to create a worker, get it voted in, and refund once upon a time his money. That would require about 7.5 million BTS. Maximum dilution for about 3 weeks should do the trick if my math is right.
Who thinks we can get that approved by shareholders?
Have you asked onceuponatime ?
-
I don't like private profits being made from something that should be a core feature of bitshares.
I understand and appreciate that @onceuponatime has taken on risk and reduced sell pressure on BTS get Stealth asset implemented but I think this feature would be better as just a standard feature .
I'd like to see @onceuponatime to sell this feature to bitshares and delete the Stealth asset.
He could sell it for whatever he paid +25% to cover costs and make a profit. This could be done as a worker proposal.
I've never thought Fee Backed Assets for core bitshares functions made any sense whatsoever.
+5% +5%
I would support this move as well. The easiest way to do so is to create a worker, get it voted in, and refund once upon a time his money. That would require about 7.5 million BTS. Maximum dilution for about 3 weeks should do the trick if my math is right.
Who thinks we can get that approved by shareholders?
Have you asked onceuponatime ?
Bytemaster and I have discussed the situation. There are some issues that I am still mulling over in my mind. For instance I had promised a distribution of 20,000 STEALTH each to the 5 accounts that agreed to share responsibility of the 3 of 5 signatory power over the Maintenance Account, and to act as an advisory board. I intend to keep my word on that matter by making that distribution.
-
I don't like private profits being made from something that should be a core feature of bitshares.
I understand and appreciate that @onceuponatime has taken on risk and reduced sell pressure on BTS get Stealth asset implemented but I think this feature would be better as just a standard feature .
I'd like to see @onceuponatime to sell this feature to bitshares and delete the Stealth asset.
He could sell it for whatever he paid +25% to cover costs and make a profit. This could be done as a worker proposal.
I've never thought Fee Backed Assets for core bitshares functions made any sense whatsoever.
+5% +5%
I would support this move as well. The easiest way to do so is to create a worker, get it voted in, and refund once upon a time his money. That would require about 7.5 million BTS. Maximum dilution for about 3 weeks should do the trick if my math is right.
Who thinks we can get that approved by shareholders?
Have you asked onceuponatime ?
Bytemaster and I have discussed the situation. There are some issues that I am still mulling over in my mind. For instance I had promised a distribution of 20,000 STEALTH each to the 5 accounts that agreed to share responsibility of the 3 of 5 signatory power over the Maintenance Account, and to act as an advisory board. I intend to keep my word on that matter by making that distribution.
Absolutely. Compromise for the community/network is great onceuponatime, but you must make sure you feel no pressure. You took a significant risk for us.
-
for real though.
You are the Satoshi Onceuponatimeamoto of Bitshares. The last thing we want to do is piss u off!
You took the risk while others are strangling our ability to develop so logically, you deserve the reward
-
I don't like private profits being made from something that should be a core feature of bitshares.
I understand and appreciate that @onceuponatime has taken on risk and reduced sell pressure on BTS get Stealth asset implemented but I think this feature would be better as just a standard feature .
I'd like to see @onceuponatime to sell this feature to bitshares and delete the Stealth asset.
He could sell it for whatever he paid +25% to cover costs and make a profit. This could be done as a worker proposal.
I've never thought Fee Backed Assets for core bitshares functions made any sense whatsoever.
@JonnyBitcoin I agree with you and Bytemaster that it's best if STEALTH becomes a core feature of the BitShares blockchain under the control of the Committee for setting fees which will then go to all shareholders.
I now own 920,000 of the 1,000,000 STEALTH. I have distributed 20,000 to each of the 4 accounts who, along with myself, are the signatories to the Maintenance Account and are my advisors on the project.
I am willing to sell to you, @JonnyBitcoin, all of my shares at 8.34 BTS each in order for you to be able to accomplish what you say you would like to see.
I think the other 4 accounts would almost certainly sell you their shares at the same rate provided that your plan is to take STEALTH out of existence as a FBA and return the feature to the control of the Committee.
So for my rather significant risk undertaken I am asking for only a virtual break even. This is because I want immediate funds for a couple of projects which require market liquidity in key BitShares markets. I hope to help provide such liquidity.
And I would hope that your offer to sell the shares to the blockchain via Worker Proposal would also be reasonable and no more than at a, say, 10% profit?
(This proposal is good until Friday April 8th at 11:59 UTC after which, if not accepted, it will be withdrawn)
-
I don't like private profits being made from something that should be a core feature of bitshares.
I understand and appreciate that @onceuponatime has taken on risk and reduced sell pressure on BTS get Stealth asset implemented but I think this feature would be better as just a standard feature .
I'd like to see @onceuponatime to sell this feature to bitshares and delete the Stealth asset.
He could sell it for whatever he paid +25% to cover costs and make a profit. This could be done as a worker proposal.
I've never thought Fee Backed Assets for core bitshares functions made any sense whatsoever.
@JonnyBitcoin I agree with you and Bytemaster that it's best if STEALTH becomes a core feature of the BitShares blockchain under the control of the Committee for setting fees which will then go to all shareholders.
I now own 920,000 of the 1,000,000 STEALTH. I have distributed 20,000 to each of the 4 accounts who, along with myself, are the signatories to the Maintenance Account and are my advisors on the project.
I am willing to sell to you, @JonnyBitcoin, all of my shares at 8.34 BTS each in order for you to be able to accomplish what you say you would like to see.
I think the other 4 accounts would almost certainly sell you their shares at the same rate provided that your plan is to take STEALTH out of existence as a FBA and return the feature to the control of the Committee.
So for my rather significant risk undertaken I am asking for only a virtual break even. This is because I want immediate funds for a couple of projects which require market liquidity in key BitShares markets. I hope to help provide such liquidity.
And I would hope that your offer to sell the shares to the blockchain via Worker Proposal would also be reasonable and no more than at a, say, 10% profit?
(This proposal is good until Friday April 8th at 11:59 UTC after which, if not accepted, it will be withdrawn)
I would not take this risk on, sorry.
I think you should ask someone to create a worker proposal for you.
-
The server-side wallet storage was not part of the proposal, but something we felt was necessary to backup/secure user funds. We do not yet have confidence in the reliability of server-side storage to enable this feature. There is a significant about of liability associated in offering to host/backup user wallets. We don't want to be responsible for the loss of funds.
Why not backup wallets directly on the blockchain? Along with a hash of the owner's email for easy lookups later. And maybe some random noise.
+5% +5% +5% +5% +5% +5% +5% +5%
Forget servers, we have a blockchain!
How about this...
Throw a bunch of different random numbers and other noise (maybe even the brainkey too?) into a json file, then compress it, encrypt it, base58 encode it, and throw that single text string into a memo. then, there is your backup. just call it up via wif, throw your key at it, and voila'... would that work? It would only cost a few BTS to store it as a transaction in a block too (for LTM's of course). For extra security, make a second backup. Yes? No? Horrible idea?
Hiring (and having to constantly trust) a backup server company is a huge expense and risk that Bitshares' name does not need. I think we should leverage the tools that we already have as much as possible. We have the most scalable chain on earth, let's really show it off!
-
The server-side wallet storage was not part of the proposal, but something we felt was necessary to backup/secure user funds. We do not yet have confidence in the reliability of server-side storage to enable this feature. There is a significant about of liability associated in offering to host/backup user wallets. We don't want to be responsible for the loss of funds.
Why not backup wallets directly on the blockchain? Along with a hash of the owner's email for easy lookups later. And maybe some random noise.
+5% +5% +5% +5% +5% +5% +5% +5%
Forget servers, we have a blockchain!
How about this...
Throw a bunch of different random numbers and other noise (maybe even the brainkey too?) into a json file, then compress it, encrypt it, base58 encode it, and throw that single text string into a memo. then, there is your backup. just call it up via wif, throw your key at it, and voila'... would that work? It would only cost a few BTS to store it as a transaction in a block too (for LTM's of course). For extra security, make a second backup. Yes? No? Horrible idea?
Hiring (and having to constantly trust) a backup server company is a huge expense and risk that Bitshares' name does not need. I think we should leverage the tools that we already have as much as possible. We have the most scalable chain on earth, let's really show it off!
this would be awsome!
how likely is it, that someone could entcode my password?
-
I am willing to sell to you, @JonnyBitcoin, all of my shares at 8.34 BTS each in order for you to be able to accomplish what you say you would like to see.
Sell STEALTHS openly on OL and give the opportunity to our community to participate !
sell them in parallel with 5 different prices and give as 2 weeks.... (like a crowd-sale)
1. 20% at 8.0 BTS / STEALTH
2. 20% at 8.5 BTS / STEALTH
3. 20% at 9.0 BTS / STEALTH
4. 20% at 9.5 BTS / STEALTH
5. 20% at 10 BTS / STEALTH
I am sure it will be successful!
PS just throwing ideas
-
I am willing to sell to you, @JonnyBitcoin, all of my shares at 8.34 BTS each in order for you to be able to accomplish what you say you would like to see.
Sell STEALTHS openly on OL and give the opportunity to our community to participate !
sell them in parallel with 5 different prices and give as 2 weeks.... (like a crowd-sale)
1. 20% at 8.0 BTS / STEALTH
2. 20% at 8.5 BTS / STEALTH
3. 20% at 9.0 BTS / STEALTH
4. 20% at 9.5 BTS / STEALTH
5. 20% at 10 BTS / STEALTH
I am sure it will be successful!
PS just throwing ideas
Selling to public is different from selling back to the DAC (all stake holders). Arhag posted a solution in last page.
-
The server-side wallet storage was not part of the proposal, but something we felt was necessary to backup/secure user funds. We do not yet have confidence in the reliability of server-side storage to enable this feature. There is a significant about of liability associated in offering to host/backup user wallets. We don't want to be responsible for the loss of funds.
Why not backup wallets directly on the blockchain? Along with a hash of the owner's email for easy lookups later. And maybe some random noise.
+5% +5% +5% +5% +5% +5% +5% +5%
Forget servers, we have a blockchain!
How about this...
Throw a bunch of different random numbers and other noise (maybe even the brainkey too?) into a json file, then compress it, encrypt it, base58 encode it, and throw that single text string into a memo. then, there is your backup. just call it up via wif, throw your key at it, and voila'... would that work? It would only cost a few BTS to store it as a transaction in a block too (for LTM's of course). For extra security, make a second backup. Yes? No? Horrible idea?
Hiring (and having to constantly trust) a backup server company is a huge expense and risk that Bitshares' name does not need. I think we should leverage the tools that we already have as much as possible. We have the most scalable chain on earth, let's really show it off!
this would be awsome!
how likely is it, that someone could entcode my password?
We would have to use very secure passwords.. maybe encrypt the wallet using its own brain key. That would make it easy to recover and hard to hack.. isn't this effectively a brain wallet?
-
I've never thought Fee Backed Assets for core bitshares functions made any sense whatsoever.
I think they are mainly a hack to get around the anti-dilution crowd.
IMO it just adds complexity that isn't needed. Complexity that can bring in more bugs.
Complexity is something you fight against in software development, just like libertarian types fight against more laws.
I'd still like to see this explained somewhere so I can know it isn't another TITAN.
-
I am willing to sell to you, @JonnyBitcoin, all of my shares at 8.34 BTS each in order for you to be able to accomplish what you say you would like to see.
Sell STEALTHS openly on OL and give the opportunity to our community to participate !
sell them in parallel with 5 different prices and give as 2 weeks.... (like a crowd-sale)
1. 20% at 8.0 BTS / STEALTH
2. 20% at 8.5 BTS / STEALTH
3. 20% at 9.0 BTS / STEALTH
4. 20% at 9.5 BTS / STEALTH
5. 20% at 10 BTS / STEALTH
I am sure it will be successful!
PS just throwing ideas
Selling to public is different from selling back to the DAC (all stake holders). Arhag posted a solution in last page.
What? Unless arhag changed his username there is no post by him in this thread.
I am surprised nobody has responded to kencode's brilliant idea of using the blockchain as a backup medium. Essentially all you need to do is securely encrypt the account owner keys to provide a solid backup solution. I don't know what the size limitation is on the memo field but surely the storage details for such a small quantity of data isn't beyond our capabilities to easily implement. Require a 10 or 20 word brainkey of the users choosing to encrypt the owner keys of the accounts held in the wallet. People who use stealth are surely going to be more careful, and having a backup of your wallet stored in the immutable blockchain is about as safe as it gets. Give the user options concerning the brain key. They provide or wallet generates it. Validate strength of any the user provides and give them feedback on the quality.
Of course the had part is how to make it easy to use. I like the "Backup Required" prompt in the bottom right corner, perhaps it needs to be more obnoxious, like blinking to catch the users attention and give them an incentive to make a backup and stop that damned blinking! Maybe lightbox the whole app until it's done before the wallet can even be used again after operations involving stealth are performed. However it's done it's GOT TO BE INTUITIVE AND SIMPLE.
I disagree with @roadscape on blinded transactions. I think that is riskier than polishing the stealth feature, especially if it's only a matter of implementing a solid backup approach, and I fully agree with Ken that any server side approach has risks.
-
What? Unless arhag changed his username there is no post by him in this thread.
There sure is: https://bitsharestalk.org/index.php/topic,22138.msg288637.html#msg288637
It's a quality suggestion too imo.
-
I am willing to sell to you, @JonnyBitcoin, all of my shares at 8.34 BTS each in order for you to be able to accomplish what you say you would like to see.
Sell STEALTHS openly on OL and give the opportunity to our community to participate !
sell them in parallel with 5 different prices and give as 2 weeks.... (like a crowd-sale)
1. 20% at 8.0 BTS / STEALTH
2. 20% at 8.5 BTS / STEALTH
3. 20% at 9.0 BTS / STEALTH
4. 20% at 9.5 BTS / STEALTH
5. 20% at 10 BTS / STEALTH
I am sure it will be successful!
PS just throwing ideas
Selling to public is different from selling back to the DAC (all stake holders). Arhag posted a solution in last page.
What? Unless arhag changed his username there is no post by him in this thread.
I am surprised nobody has responded to kencode's brilliant idea of using the blockchain as a backup medium. Essentially all you need to do is securely encrypt the account owner keys to provide a solid backup solution. I don't know what the size limitation is on the memo field but surely the storage details for such a small quantity of data isn't beyond our capabilities to easily implement. Require a 10 or 20 word brainkey of the users choosing to encrypt the owner keys of the accounts held in the wallet. People who use stealth are surely going to be more careful, and having a backup of your wallet stored in the immutable blockchain is about as safe as it gets. Give the user options concerning the brain key. They provide or wallet generates it. Validate strength of any the user provides and give them feedback on the quality.
Of course the had part is how to make it easy to use. I like the "Backup Required" prompt in the bottom right corner, perhaps it needs to be more obnoxious, like blinking to catch the users attention and give them an incentive to make a backup and stop that damned blinking! Maybe lightbox the whole app until it's done before the wallet can even be used again after operations involving stealth are performed. However it's done it's GOT TO BE INTUITIVE AND SIMPLE.
I disagree with @roadscape on blinded transactions. I think that is riskier than polishing the stealth feature, especially if it's only a matter of implementing a solid backup approach, and I fully agree with Ken that any server side approach has risks.
@Thom, I think you may be losing it. @arhag most certainly did post on this thread. Scroll up! Also, storing the account keys on the blockchain was actually @roadscape's idea. @kenCode gave him major kudos for that....and I do too because yes, it would be awesome!
By the way, if the keys are stored on the blockchain, why would the user need a reminder to back up their keys? Wouldn't it just be done automatically?
-
I am surprised nobody has responded to kencode's brilliant idea of using the blockchain as a backup medium. Essentially all you need to do is securely encrypt the account owner keys to provide a solid backup solution.
It is not enough to just backup owner keys to the blockchain when it comes to stealth. Stealth transfers (unlike simply blinded transfers) don't publicly signal to the receiver that the transaction is meant for them. This is why with TITAN in pre-1.0 BitShares you needed to scan the entire blockchain with your private keys. In BitShares 2.0, forcing users to scan the entire blockchain is not expected. So a stealth transfer sender needs to communicate some information out-of-band. If I am not mistaken, the minimal amount of information that needs to be communicated out-of-band is a (block number, transaction number) tuple, i.e. a pointer to the transaction in the blockchain that contains the stealth transfer. With this information, I believe the receiver could easily request the transaction in question from the server (which should be small in size), and using their stealth-related private key quickly verify if in fact it contains a stealth transfer to them (and also decrypt the blinded amounts). But without this information, the receiver would not even be made aware of the transfer and thus would not have access to the funds to spend.
I believe that it should in theory be possible to follow the chain of stealth transfers (as in inputs to one stealth transfer consuming outputs of a previous one in the chain) to minimize the number of "transaction pointers" a client needs to keep to be able to fully restore all stealth transfers and thus all of their balances from scratch (assuming they also have their private keys). I think it would only be necessary to keep "transaction pointers" to transactions with the property of containing stealth transfer operation(s) that have output balances accessible by the user (with the exception of ones that would be redundant because the transaction they point to can already be accessed by going backwards along the stealth transfer transaction chain from a newer transaction with the aforementioned property). It could then be possible to take the set of all necessary "transaction pointers" grouped by each account in the wallet to be backed up, subtract that set by the corresponding set computed as of the last backup operation to the blockchain (empty set if this is the first time), encode the contents of the resulting set into a compact string, encrypt it using a private memo key of one of the accounts (the one designated as the account to do backups on), and then publish that string as a custom transaction under the backup account. A client starting from nothing more than a brain key (from which all the other relevant private keys can be deterministically derived), could then follow a procedure to use the data published to the blockchain to quickly (and with reasonable network bandwidth) recover all balances and all relevant transactions (including stealth ones).
Despite the above optimizations, there might still be a moderate amount of data to publish in the custom transaction to backup all the balances and stealth transfers. And each time a backup would be published, it would cost the user some transaction fee. Furthermore, for privacy reasons it would make sense to not publish a custom transaction backup immediately after each time the user receives a stealth transfer as that could potentially link the receiver of the stealth transfer to the backup account (though the link wouldn't necessarily be obvious). So, I would imagine backups like these would be used with less frequency. Instead, backing up the encrypted wallet to the host that provides the client software would be a more convenient solution. However, having a blockchain based backup as I described above would still be a nice addition as a further backup in the unusual case where the host disappears (and the user also makes a mistake and loses the wallet data stored locally with the client at the same time). Even if the blockchain backup isn't very recent, it might still help recover some partial funds in this worst case scenario. And best of all, assuming my understanding of the existing blockchain protocol is correct, the procedure I described above can be implemented by the client alone and doesn't require any changes to the blockchain protocol or the witness_nodes.
-
Can someone please point me in the direction of the best description of how this works?
-
I am surprised nobody has responded to kencode's brilliant idea of using the blockchain as a backup medium. Essentially all you need to do is securely encrypt the account owner keys to provide a solid backup solution.
It is not enough to just backup owner keys to the blockchain when it comes to stealth.
Doh! You're absolutely right, how silly of me. That's what I get for posting without pausing to think.
To backup a standard wallet the owner keys would suffice to recover balances, but definitely not for stealth addresses, as you point out.
-
The server-side wallet storage was not part of the proposal, but something we felt was necessary to backup/secure user funds. We do not yet have confidence in the reliability of server-side storage to enable this feature. There is a significant about of liability associated in offering to host/backup user wallets. We don't want to be responsible for the loss of funds.
Why not backup wallets directly on the blockchain? Along with a hash of the owner's email for easy lookups later. And maybe some random noise.
+5% +5% +5% +5% +5% +5% +5% +5%
Forget servers, we have a blockchain!
How about this...
Throw a bunch of different random numbers and other noise (maybe even the brainkey too?) into a json file, then compress it, encrypt it, base58 encode it, and throw that single text string into a memo. then, there is your backup. just call it up via wif, throw your key at it, and voila'... would that work? It would only cost a few BTS to store it as a transaction in a block too (for LTM's of course). For extra security, make a second backup. Yes? No? Horrible idea?
Hiring (and having to constantly trust) a backup server company is a huge expense and risk that Bitshares' name does not need. I think we should leverage the tools that we already have as much as possible. We have the most scalable chain on earth, let's really show it off!
this would be awsome!
how likely is it, that someone could entcode my password?
We would have to use very secure passwords.. maybe encrypt the wallet using its own brain key. That would make it easy to recover and hard to hack.. isn't this effectively a brain wallet?
Right, the backups of your stealth can go to the blockchain (the noisy json file compressed, encrypted and base58 encoded as a simple text string into the memo field).
Reference that transaction when needed via its transaction id.
Use a brainkey to access those individual stealth transaction backups, and another brainkey to access the wallet itself.
Almost all of this is existing code, we just need to tie it together and display the backup brainkey to the user upon/via a transaction confirmation modal.
I know my architecture here is missing some specifics, but this can be the general gist of it, and keep it so the user never even has to think about it. Sending and receiving via stealth will become as easy to use as sending an email IMO..
-
The server-side wallet storage was not part of the proposal, but something we felt was necessary to backup/secure user funds. We do not yet have confidence in the reliability of server-side storage to enable this feature. There is a significant about of liability associated in offering to host/backup user wallets. We don't want to be responsible for the loss of funds.
Why not backup wallets directly on the blockchain? Along with a hash of the owner's email for easy lookups later. And maybe some random noise.
+5% +5% +5% +5% +5% +5% +5% +5%
Forget servers, we have a blockchain!
How about this...
Throw a bunch of different random numbers and other noise (maybe even the brainkey too?) into a json file, then compress it, encrypt it, base58 encode it, and throw that single text string into a memo. then, there is your backup. just call it up via wif, throw your key at it, and voila'... would that work? It would only cost a few BTS to store it as a transaction in a block too (for LTM's of course). For extra security, make a second backup. Yes? No? Horrible idea?
Hiring (and having to constantly trust) a backup server company is a huge expense and risk that Bitshares' name does not need. I think we should leverage the tools that we already have as much as possible. We have the most scalable chain on earth, let's really show it off!
this would be awsome!
how likely is it, that someone could entcode my password?
We would have to use very secure passwords.. maybe encrypt the wallet using its own brain key. That would make it easy to recover and hard to hack.. isn't this effectively a brain wallet?
Right, the backups of your stealth can go to the blockchain (the noisy json file compressed, encrypted and base58 encoded as a simple text string into the memo field).
Reference that transaction when needed via its transaction id.
Use a brainkey to access those individual stealth transaction backups, and another brainkey to access the wallet itself.
Almost all of this is existing code, we just need to tie it together and display the backup brainkey to the user upon/via a transaction confirmation modal.
I know my architecture here is missing some specifics, but this can be the general gist of it, and keep it so the user never even has to think about it. Sending and receiving via stealth will become as easy to use as sending an email IMO..
As per BM's statements (https://soundcloud.com/beyond-bitcoin-hangouts/e147#t=10:45) storing the stealth backups in a memo field as per our discussion above will require the user to have a very strong password. Ok, that may be true, but storing my backups on someone's server seems like an even bigger risk (and expense).
At this time we are at an impasse, so.. Go back to the old risky expensive centralized server model, OR require users to have a really strong passphrase and stick the backup into a cost-effective secure block transaction?
Is it time for a poll? Stealth is pretty much on hold until we resolve this.
-
we need both options. one for the pro (us) and the other for the novice (our market)
-
The server-side wallet storage was not part of the proposal, but something we felt was necessary to backup/secure user funds. We do not yet have confidence in the reliability of server-side storage to enable this feature. There is a significant about of liability associated in offering to host/backup user wallets. We don't want to be responsible for the loss of funds.
Why not backup wallets directly on the blockchain? Along with a hash of the owner's email for easy lookups later. And maybe some random noise.
+5% +5% +5% +5% +5% +5% +5% +5%
Forget servers, we have a blockchain!
How about this...
Throw a bunch of different random numbers and other noise (maybe even the brainkey too?) into a json file, then compress it, encrypt it, base58 encode it, and throw that single text string into a memo. then, there is your backup. just call it up via wif, throw your key at it, and voila'... would that work? It would only cost a few BTS to store it as a transaction in a block too (for LTM's of course). For extra security, make a second backup. Yes? No? Horrible idea?
Hiring (and having to constantly trust) a backup server company is a huge expense and risk that Bitshares' name does not need. I think we should leverage the tools that we already have as much as possible. We have the most scalable chain on earth, let's really show it off!
this would be awsome!
how likely is it, that someone could entcode my password?
We would have to use very secure passwords.. maybe encrypt the wallet using its own brain key. That would make it easy to recover and hard to hack.. isn't this effectively a brain wallet?
Right, the backups of your stealth can go to the blockchain (the noisy json file compressed, encrypted and base58 encoded as a simple text string into the memo field).
Reference that transaction when needed via its transaction id.
Use a brainkey to access those individual stealth transaction backups, and another brainkey to access the wallet itself.
Almost all of this is existing code, we just need to tie it together and display the backup brainkey to the user upon/via a transaction confirmation modal.
I know my architecture here is missing some specifics, but this can be the general gist of it, and keep it so the user never even has to think about it. Sending and receiving via stealth will become as easy to use as sending an email IMO..
As per BM's statements (https://soundcloud.com/beyond-bitcoin-hangouts/e147#t=10:45) storing the stealth backups in a memo field as per our discussion above will require the user to have a very strong password. Ok, that may be true, but storing my backups on someone's server seems like an even bigger risk (and expense).
At this time we are at an impasse, so.. Go back to the old risky expensive centralized server model, OR require users to have a really strong passphrase and stick the backup into a cost-effective secure block transaction?
Is it time for a poll? Stealth is pretty much on hold until we resolve this.
If I'm not mistaken, the conversation about needing a strong passphrase had to do with storing keys on the blockchain period (i.e. regardless of stealth). I thought the stealth-specific issue was that, if you're planning to store keys on the blockchain, the data storage requirements with stealth would be a challenge. Can someone please correct me if I'm wrong?
The other question about stealth, as I recall it, is whether we want to go with a solution that is more user friendly than the current version implemented for @onceuponatime but isn't as private (i.e. you can see who is transferring but not the transaction amounts or account balances)? Again, someone please correct me if I'm wrong.
-
You are correct on both counts tbone. @Erlich Bachman - allowing short or insecure keys isn't an option for anyone. The last thing BitShares needs is someone loosing their life savings b/c they failed to provide a good brain key.
I got a lot out of BM's discussion on last Friday's mumble. Two important points:
1) There are higher risks for putting wallets on the blockchain, significantly b/c attackers can hammer their target trying to crack the password without any delays between each attempt. They could employ many computers in parallel in the attempt also.You might be surprised at how quickly a password can be guessed via brute force means like that.
2) It's not sufficient to only save private keys. That could work if you're saving a BitShares wallet with only standard accounts, but not if the wallet contains stealth addresses. And, unless a limit is put on how many accounts and stealth accounts a wallet may contain the size of the backup could get prohibitively large to store on the blockchain, even without transaction history.
Regarding the use of blinded transfers as a replacement, I'm not a big fan of that approach. I would want to see more details about the viability of that, focused on the time required to implement it, what the exposure it has on existing code to new bugs, both front end and backend, not to mention who will implement it with this no-dilution cloud hanging overhead.
-
You are correct on both counts tbone. @Erlich Bachman - allowing short or insecure keys isn't an option for anyone. The last thing BitShares needs is someone loosing their life savings b/c they failed to provide a good brain key.
I got a lot out of BM's discussion on last Friday's mumble. Two important points:
1) There are higher risks for putting wallets on the blockchain, significantly b/c attackers can hammer their target trying to crack the password without any delays between each attempt. They could employ many computers in parallel in the attempt also.You might be surprised at how quickly a password can be guessed via brute force means like that.
2) It's not sufficient to only save private keys. That could work if you're saving a BitShares wallet with only standard accounts, but not if the wallet contains stealth addresses. And, unless a limit is put on how many accounts and stealth accounts a wallet may contain the size of the backup could get prohibitively large to store on the blockchain, even without transaction history.
Regarding the use of blinded transfers as a replacement, I'm not a big fan of that approach. I would want to see more details about the viability of that, focused on the time required to implement it, what the exposure it has on existing code to new bugs, both front end and backend, not to mention who will implement it with this no-dilution cloud hanging overhead.
It is worse than #1. They can store the hashes and then clear out any account that goes forward and uses that hash. With 5 TB drives costing so cheap, you can create really really big hash stores . So as soon as any transaction hits the network, this actor looks up their list of hashes and sees if it is crackable.
-
You are correct on both counts tbone. @Erlich Bachman - allowing short or insecure keys isn't an option for anyone. The last thing BitShares needs is someone loosing their life savings b/c they failed to provide a good brain key.
I got a lot out of BM's discussion on last Friday's mumble. Two important points:
1) There are higher risks for putting wallets on the blockchain, significantly b/c attackers can hammer their target trying to crack the password without any delays between each attempt. They could employ many computers in parallel in the attempt also.You might be surprised at how quickly a password can be guessed via brute force means like that.
2) It's not sufficient to only save private keys. That could work if you're saving a BitShares wallet with only standard accounts, but not if the wallet contains stealth addresses. And, unless a limit is put on how many accounts and stealth accounts a wallet may contain the size of the backup could get prohibitively large to store on the blockchain, even without transaction history.
Regarding the use of blinded transfers as a replacement, I'm not a big fan of that approach. I would want to see more details about the viability of that, focused on the time required to implement it, what the exposure it has on existing code to new bugs, both front end and backend, not to mention who will implement it with this no-dilution cloud hanging overhead.
It is worse than #1. They can store the hashes and then clear out any account that goes forward and uses that hash. With 5 TB drives costing so cheap, you can create really really big hash stores . So as soon as any transaction hits the network, this actor looks up their list of hashes and sees if it is crackable.
If there's a server containing a bunch of crypto wallets the only safe assumption to make is that it will be hacked. So they better be very resistant to brute forcing either way imo. If you're describing rainbow tables, salting helps prevent those types of lookups.
-
1) There are higher risks for putting wallets on the blockchain, significantly b/c attackers can hammer their target trying to crack the password without any delays between each attempt. They could employ many computers in parallel in the attempt also.You might be surprised at how quickly a password can be guessed via brute force means like that.
It is worse than #1. They can store the hashes and then clear out any account that goes forward and uses that hash. With 5 TB drives costing so cheap, you can create really really big hash stores . So as soon as any transaction hits the network, this actor looks up their list of hashes and sees if it is crackable.
Not really. That "rainbow table" attack is simple enough to defeat using a random plain-text 256-bit salt attached to the wallet backup submitted to the blockchain. That specific attack is only an issue for private keys derived solely from a passphrase.
Nevertheless, an attacker can still focus their computational power on a particular user and bruteforce their password in a reasonable amount of time if they used a weak password. Therefore, I don't agree with allowing a publicly available backup to be encrypted by a user-defined passphrase (except perhaps if they really know what they are doing and have to use the CLI to generate it). The computer should generate the 256 bits of entropy used to encrypt the backups that are submitted online (or used to deterministically derived the private keys), and the user should be forced to write down the "brain key" and keep it somewhere safe. They only have to do that once so it isn't much of a burden. It's not like they would have to write down a new brain key each time they need to backup their wallet.
-
The above attack happened to me on a NXT blockchain when I decided to ignore the security recommendation while testing something. It is quite epic to see your account hacked within seconds. Literally. Thinking about it, it seems like perhaps that was bad programming on their part. (I'm not suggesting NXT still has this issue. I have no clue.)
I was aware of salting, but didn't realize it could be stored publicly along with the hash. +5% for teaching me stuff.
-
So does stealth actually work? Can anyone give an example on how to do a stealth transaction?
-
So does stealth actually work? Can anyone give an example on how to do a stealth transaction?
My guess is not really unless your are some kind of super user, but instead we are getting the half as good version that conveniently was being developed as one of the specs for Steem.
-
So does stealth actually work? Can anyone give an example on how to do a stealth transaction?
My guess is not really unless your are some kind of super user, but instead we are getting the half as good version that conveniently was being developed as one of the specs for Steem.
Half as effective?
Or half as user friendly?
-
So does stealth actually work? Can anyone give an example on how to do a stealth transaction?
My guess is not really unless your are some kind of super user, but instead we are getting the half as good version that conveniently was being developed as one of the specs for Steem.
Half as effective?
Or half as user friendly?
I'm not sure if any actual data has been released on the scope of the implementation of blinded transfers.
While "stealth, ""confidential," "secret" transactions bring hype among communities, the blockchain itself is a transparent ledger. No matter the implementation it appears there will always be a way to track funds eventually to user with a high degree of probability.
Am I missing something with the following questions/thoughts?
BM mentioned our account balance can be hidden, how so? If Account A has 100 bts and blind transfers to account B 100bts with the blind feature, we can still see Account A HAD 100bts and now has 0? We can easily assume Account B now has 100bts. Is the only way to gain true stealth still through a mixing service? This appears to be similar to 0.93?
Once a balance is hidden, how will it effect voting?
Can additional features be added to hide things like who we are voting for? Our white/black lists? Assets? Permissions?
Another example is when we browse a user's ID, why does the membership option even appear? Perhaps removing things like this could minimize data usage and lower latency?
-
BM mentioned our account balance can be hidden, how so? If Account A has 100 bts and blind transfers to account B 100bts with the blind feature, we can still see Account A HAD 100bts and now has 0? We can easily assume Account B now has 100bts. Is the only way to gain true stealth still through a mixing service? This appears to be similar to 0.93?
But the public wouldn't be able to tell that A sent B 100 BTS nor would they be able to tell that A is left with 0 BTS. Let me make it more clear with the following example. Let's say Alice originally has 500 BTS in a public balance and decides to blind that value and send 100 BTS of it to Bob. She creates a transaction that consumes the 500 BTS as input and creates two blinded balance outputs: one is 100 BTS for Bob and the other is 400 BTS change for herself. Now the public knows that the sum of her remaining balance and the amount she sent Bob needs to equal 500 BTS, but they have no idea how much each are individually.
Once a balance is hidden, how will it effect voting?
If a balance is completely blinded it cannot be used for voting. The most we could do is allow the user to expose a minimum value for the blinded balance and only that minimum value will contribute towards voting (and contribute towards rate-limited free transactions). The remainder of the blinded balance beyond the exposed minimum value would not count however. Obviously in that case the user has a trade-off to make between how much voting power (or rate-limited free transaction bandwidth) they want and how much of their privacy they wish to give up.
Can additional features be added to hide things like who we are voting for? Our white/black lists? Assets? Permissions?
Short of some fancy new amazing cryptography innovations... no.
-
Can additional features be added to hide things like who we are voting for? Our white/black lists? Assets? Permissions?
Another example is when we browse a user's ID, why does the membership option even appear? Perhaps removing things like this could minimize data usage and lower latency?
Some data needs to be publicly known (i.e. interpretable by the blockchain and thus publicly known) .. such as whitelists and votes. Hence they can't be hidden.
Stuff like the balances are a little more relexed because the blockchain only needs to know that the sum of balance in inputs equals the sum of balances in outputs. So the ACTUAL amounts are of no interest to the blockchain and can be hidden ..
-
So from what I am getting, stealth doesn't work...
-
Can smartcoin balances be blinded and sent (bitGOLD? bitUSD? etc?)
-
Can smartcoin balances be blinded and sent (bitGOLD? bitUSD? etc?)
yes
-
So from what I am getting, stealth doesn't work...
Stealth does work. Its just not user friendly, and is thus dangerous.
-
Dangerous as, not very stealthy?
-
Dangerous as, not very stealthy?
The security of something like stealth increases when more people use it. When only a few people use it then it's not very stealthy or private.
-
Ok, so storing the backups on the blockchain is a bad idea, at least in the sense that it would become risky for the user if they ever forgot their password.
I have been looking at IPFS quite a bit lately for distributed data storage and sharing. We could use our keys with this protocol i think and never have to worry about storing our backups or other data and referencing it on our blockchain since the hash itself is used for the lookup of the file(s). Would this solve the stealth backup issue if we integrate with IPFS?
Intro: https://youtu.be/HUVmypx9HGI
Demo: https://youtu.be/8CMxDNuuAiQ
-
Been out for awhile. Last I heard, stealth was coming out around March.
That clearly didn't happen. What is the plan with the GUI these days? Is it still being actively developed?
-
Been out for awhile. Last I heard, stealth was coming out around March.
That clearly didn't happen. What is the plan with the GUI these days? Is it still being actively developed?
@karnal
Yes, BitShares Munich is getting up to speed now on blinded transactions at the very least, so for the next two weeks, that team (our team is growing due to this increased demand) is going to be working on this. See my comments regarding IPFS, as we may be working on a side project soon (funded separately) that will pay for a bts blockchain and IPFS utility. The IPNS naming scheme will be used as well, this can solve the DNS issues that I was tackling over a year ago (see the DDNS threads). Stealth is not dead, I assure you.
-
@kenCode is that regarding the light client or the mobile app?
-
@kenCode is that regarding the light client or the mobile app?
stealth is not in the mobile apps.
-
great!
good idea!
i like this!
just do it!
+5% +5% +5%
-
The primary reason BM believes backups on the blockchain are problematic is it allows direct access to a wallet for the purpose of brute force password cracking. Unless the wallet backup is disassociated from the account it is for hackers will be able to locate wallet backups of interest on the blockchain (the wallets associated with large account balances), obtain a copy of it and hammer it with concentrated, distributed CPU power to brute force hack the key / password to unlock it. That's what I took away from BM's discussion about stealth in the mumble the other day. The lessor point he raised is using Storj or IPFS will cost something, it won't be free, which will have a negative impact on the adoption of stealth. External storage also opens up a dependency outside the control of the BitShares ecosystem, and may well incur significant development costs to integrate with our stealth code, at least it's a possibility.
The association between the account and the backup is what needs to be obfuscated, and it seems like there ought to be a way to do that. The wallet backup could be split into small pieces and distributed as chunks in encrypted memo fields as Ken originally suggested, but with additional security as I'll explain. Also, as the number of these wallet backup chunks increase the harder it is to assemble all the right pieces back together for a specific wallet.
The encryption for each chunk would be separate so cracking one doesn't allow you to crack them all, and even after all the backup segments are reassembled, the wallet backup itself requires another separate key to unlock it. If each of these levels is like sha256 or sha512 encryption, each of which must be cracked to get to the next, doesn't that multiply the effort required to gain access to the wallet? Each chunk could contain the location (but not the key's to decrypt) the next chunk on the blockchain, in a kind of inner nested blockchain comprised of these encrypted memo fields. The advantage to this approach is it avoids the cost and risk of using external storage. The downside is the additional space and storage overhead it imposes on the BitShares blockchain.
The devil is in the details of a scheme like this, particularly in how the association is managed in a way that only the wallet owner can know. Ultimately it comes down to a secret the wallet owner must create strong enough, or, if created by algorithm and provided to the wallet owner they must remember and keep secure. So does that not bring us back full circle to the initial problem? If so I don't think any implementation can get around that.
Thoughts anyone?
-
Making transactions default blinded sounds like a great idea, IMO. Currently I think transactions are a little "too public".
Oh what, you mean how every time a whale transfers any BTS to poloniex, it gets posted about in these forums?
I didnt notice that. :P
-
Thoughts anyone?
I think you over-complicating it for little benefit. You can backup whatever you want to the blockchain (if it is cost effective that is) with encryption that cannot be brute forced (anymore than they can brute force the private key of your public keys). The client just needs to make sure that the key used for the encryption is derived from a 256-bit randomly generated seed. I would have an IDENTITY_SEED which is a randomly generated 256-bit number represented in the form of a sequence of dictionary words that you backup and keep somewhere safe (paper backup and flash drive stored in multiple safe locations). The IDENTITY_SEED plus an optional passphrase (that you must be able to remember if you choose to use it) is used to ultimately derive all the relevant keys (owner keys, active keys, blockchain backup keys, etc.). Most keys would ideally be deterministically derived using simple incrementing indices so that recovery is trivial and doesn't bloat the blockchain with many backups of new keys. For those keys that are non-deterministic, the client would back it up to the blockchain after encrypting the payload using locally stored private keys that have full 256 bits of entropy (and are deterministically derived from IDENTITY_SEED). Then restoring from scratch becomes possible as long as the user can retrieve their IDENTITY_SEED.
-
Thoughts anyone?
I think you over-complicating it for little benefit. You can backup whatever you want to the blockchain (if it is cost effective that is) with encryption that cannot be brute forced (anymore than they can brute force the private key of your public keys). The client just needs to make sure that the key used for the encryption is derived from a 256-bit randomly generated seed. I would have an IDENTITY_SEED which is a randomly generated 256-bit number represented in the form of a sequence of dictionary words that you backup and keep somewhere safe (paper backup and flash drive stored in multiple safe locations). The IDENTITY_SEED plus an optional passphrase (that you must be able to remember if you choose to use it) is used to ultimately derive all the relevant keys (owner keys, active keys, blockchain backup keys, etc.). Most keys would ideally be deterministically derived using simple incrementing indices so that recovery is trivial and doesn't bloat the blockchain with many backups of new keys. For those keys that are non-deterministic, the client would back it up to the blockchain after encrypting the payload using locally stored private keys that have full 256 bits of entropy (and are deterministically derived from IDENTITY_SEED). Then restoring from scratch becomes possible as long as the user can retrieve their IDENTITY_SEED.
Thanks for taking the time to comment arhag. I'm no expert on cryptography, but it sounds like you and @bytemaster disagree about the viability and security of using the blockchain as the wallet backup medium. My perspective was similar to what you said in your first few sentences above, until BM came along the other week and said the encryption wasn't that safe against brute force methods. That was very surprising to hear actually. He explained an important difference was the delays imposed between each guess attempt by front door time outs and other measures which wouldn't exist in a blockchain backup scenario. It makes sense on the surface, but if such measures are so important in the security of the encryption which is the core security mechanism of the entire blockchain, it's far weaker than I thought. Frankly that seems highly unlikely.
Perhaps I misunderstood the weakness BM was concerned with. Perhaps it primarily rests on the identity_seed. No encryption is worth its LSBit if the encryption key used to generate the pub / priv pairs is weak. That is ALWAYS an issue, that can never be avoided. It's a fundamental concern, however decentralized wallets on computers everywhere are not readily accessible and thus are not subject to direct, repeated trials of potential key guesses to unlock the wallet. That changes when the wallet is on a public blockchain, thus my "elaborate" scheme to A) obfuscate the account owner of the wallet with the backup and B) to decentralize the backup data to prevent direct access to it.
-
Thanks for taking the time to comment arhag. I'm no expert on cryptography, but it sounds like you and @bytemaster disagree about the viability and security of using the blockchain as the wallet backup medium. My perspective was similar to what you said in your first few sentences above, until BM came along the other week and said the encryption wasn't that safe against brute force methods.
When bytemaster says encryption isn't safe against brute force methods, he is talking about encrypting using a user-chosen password and publishing the (poorly encrypted) data to the public. If you do not allow the user to set the password but force them to use a key with 256 bits of computer generated entropy that they keep safe locally, then there is no brute force issue. It just means recovery is slightly more annoying than typing in your password in a new client. You are forced to get out your paper backup and type in a longer sequence of random dictionary words into the new client.
He explained an important difference was the delays imposed between each guess attempt by front door time outs and other measures which wouldn't exist in a blockchain backup scenario. It makes sense on the surface, but if such measures are so important in the security of the encryption which is the core security mechanism of the entire blockchain, it's far weaker than I thought. Frankly that seems highly unlikely.
So that is in the context where you trust a third-party server with your (poorly encrypted) backups. The server can then enforce rate limits on guessing passwords so that your weak password is good enough to prevent attackers from getting your (poorly encrypted) backup under their local control in the first place to then brute force. The problem with relying on third parties is that the third party may then be liable (at least morally if not legally) if their security is not good enough to prevent others from getting access to your (poorly encrypted) backups. And that isn't the only problem with third-party server backups. You need to trust that the third party won't brute force your poorly encrypted backup themselves. And what is even more of an issue is that if you are solely relying on the third-party server backups to not lose stealth funds (for example), what happens if the third-party company goes under (or loses all their data somehow) and does not or cannot offer you to download your backup even one last time? Unless you had other recent manual backups you might lose some of your funds in that scenario.
-
Thanks for taking the time to comment arhag. I'm no expert on cryptography, but it sounds like you and @bytemaster disagree about the viability and security of using the blockchain as the wallet backup medium. My perspective was similar to what you said in your first few sentences above, until BM came along the other week and said the encryption wasn't that safe against brute force methods.
When bytemaster says encryption isn't safe against brute force methods, he is talking about encrypting using a user-chosen password and publishing the (poorly encrypted) data to the public. If you do not allow the user to set the password but force them to use a key with 256 bits of computer generated entropy that they keep safe locally, then there is no brute force issue. It just means recovery is slightly more annoying than typing in your password in a new client. You are forced to get out your paper backup and type in a longer sequence of random dictionary words into the new client.
He explained an important difference was the delays imposed between each guess attempt by front door time outs and other measures which wouldn't exist in a blockchain backup scenario. It makes sense on the surface, but if such measures are so important in the security of the encryption which is the core security mechanism of the entire blockchain, it's far weaker than I thought. Frankly that seems highly unlikely.
So that is in the context where you trust a third-party server with your (poorly encrypted) backups. The server can then enforce rate limits on guessing passwords so that your weak password is good enough to prevent attackers from getting your (poorly encrypted) backup under their local control in the first place to then brute force. The problem with relying on third parties is that the third party may then be liable (at least morally if not legally) if their security is not good enough to prevent others from getting access to your (poorly encrypted) backups. And that isn't the only problem with third-party server backups. You need to trust that the third party won't brute force your poorly encrypted backup themselves. And what is even more of an issue is that if you are solely relying on the third-party server backups to not lose stealth funds (for example), what happens if the third-party company goes under (or loses all their data somehow) and does not or cannot offer you to download your backup even one last time? Unless you had other recent manual backups you might lose some of your funds in that scenario.
arhag
Do you have the technical coding ability to push this to a test network? If not perhaps someone such as Abit could push this to test? This would make a very worthwhile worker proposal.
-
If you do not allow the user to set the password but force them to use a key with 256 bits of computer generated entropy that they keep safe locally, then there is no brute force issue.
So why is generating such a key, i.e. an algorithm produced brain key, seen as either inadequate or prohibitively inconvenient?
Seems like a small price to insure the security of one's assets, and why incur the extra cost and ANY extra steps to use stealth if unwilling to accept a safe, secure brain key instead of their own? If using the wallet generated brain key sequence is the ONLY way provided to use stealth, the user has no choice in picking a password. If that insures security what's wrong with that? If the user then ignores the warnings and admonitions about keeping that brain key safe how is that any more a liability than poor practices with the wallet password?
Apparently I just don't get BM's primary concern about using the blockchain as a storage vault for wallet backups. I know he's now of the belief fees are bad, but stealth has never been a feature designed with "no fees" as a requirement. If backups are essential for making stealth usable safely, then a charging a backup fee proportional to the amount of storage required for it is not unreasonable, just like charging a fee to use stealth was not seen as a bad thing.
-
arhag
Do you have the technical coding ability to push this to a test network? If not perhaps someone such as Abit could push this to test? This would make a very worthwhile worker proposal.
I have ideas for how stealth (and also key management and offline signing with cold keys) should be done that I am willing to freely share. Much is what I have already talked about previously. In fact, I will just go ahead and post the beginning part of a draft that I have recently been working on of my thoughts on how to do stealth:
We need to rethink the way stealth is done so that the UX is better while remaining safe to use.
First, I think the default method of transferring should be with blinded amounts (but not stealth). You could do a public transfer with a click of checkbox if you wanted. Bytemaster has already talked about this. So you can see who is transacting with whom and at what time with which asset, but not the amount. With this method, there are no issues with signaling/communicating receipts and the backup strategy to not lose funds is much simpler. Also, as long as you expose some minimum of your blinded BTS balance, you can still use that minimum towards rate-limited free transactions authored by your account as well as to voting.
Second, stealth needs to be redone. I think the main change needed is to get around the signaling/communication and backup issues while still preserving some privacy of metadata. The idea is to allow the blockchain to know which asset is being transferred to which account, but not from which account. If the blockchain knows the recipient of the transfer of some asset, the user can be assured that they will have access to those funds (assuming the sender put the unblinded values in the encrypted memo properly of course) as long as they can still get access to their account and they have the private key of the memo key published to their account at the time of transfer. To rest user concerns on these requirements, the client could have a limited form of backup anytime the memo key was changed. In the same transaction that changes the memo key, the client would include an custom operation that includes one encrypted payload and an optional second encrypted payload.
The first payload would include the private key of the old memo key. In almost all cases, the client creating a transaction to change the memo key would also have access to the old memo private key. In rare cases where it does not have that information, it would warn the user of that fact and the risk of losing blinded funds. If the user cannot find a way to import that old memo private key and agrees to change the memo key despite the risk of lost funds, the client would instead include the private key of the most recent published memo key it does have. In that case any active balances with blinded values whose blind factor and unblinded amount are stored in a memo encrypted with the memo key that was lost would be inaccessible to the user. This should be a very rare situation. One case might be if an attacker compromised the active authority of the account, changed the memo key, and afterward someone else send a legitimate transfer to the account. Even though the rightful owner of the account could get back control of the account using the offline owner key, they would still lose access to those legitimate transfers that were sent during the time the attacker's unknown memo key was published on the user's account. This first payload would be encrypted using the new memo private key.
The second optional payload would include the private key of the new memo key. If the new memo key was deterministically derived from a seed that was accessible to the hot client in which the seed itself was deterministically derived from a brain key in cold storage, then the second payload would not be included. If the previous conditional is not true, then the second payload would be required to guarantee that the user can recover their funds. If the second payload is required to guaranee fund recovery, then it is important that there exists a single owner key in the owner authority that has a weight greater than or equal to the owner authority threshold. If that is the case, then the second payload would be encrypted using a shared secret derived as follows. The shared secret would be the elliptic curve multiplication of the new memo private key and aforementioned single owner public key. This means the same shared secret could be derived through elliptic curve multiplication of the new memo public key and the private key of the aforementioned single owner key. Thus if the user can somehow generate the private key of that single owner key to take back control of the account, the user's client can also use the information in the blockchain to get the private key of the latest published memo key. And from that, it can use the public blockchain information to get the private keys of all previous memo keys published on that account. These memo keys allow the client to restore the encrypted memos of all transactions from/to that account as well as get access to all blinded balances in transfers from/to that account.
With the backup strategy for both regular blinded transfers and receipts of this new stealth transfer mechanism that I will shortly talk about taken care of, I can now discuss how the new stealth transfer mechanism could work and how it preserves privacy of metadata even though the public always knows the recipient of a stealth transfer which must be an account.
This part of the draft doesn't have much that is new. Ignoring the stealth balance stuff I hint at above which I still haven't thought through fully, the above with a sensible key generation and management solution is basically a design outline for a UX for blinded transfers that allows users to comfortably use the feature without worrying about backups. This is what we should be focused on when we talk about privacy. The extra stealth stuff (hiding metadata) is not as important and if we want to really do it right I believe we need to have services that provide coin mixing (some hard forking blockchain support may or may not be required for that). This approach requires exposing the input to output mapping of the coins you are mixing to the coin mixing host which compromises metadata privacy to the coin mixer only, but even this could be mitigated by using multiple coin mixing hosts who are unlikely to collude. So the privacy isn't perfect there either, but hopefully it could be a good enough solution that is easier to use.
But what I wrote in the quote above should be possible to do all in the client end with no hard forking changes to the blockchain. As for implementation, it is probably better for someone more familiar with the client code and more willing to dedicate time to implement it, like svk, to do. For later innovations that may require some minor hard forking changes to the blockchain, abit would probably be a good candidate alongside svk for the client side GUI changes. In theory I could spend some time learning the codebase enough to work on it myself, but that would require a serious time investment that I don't think I can give. Unless I get a lot of free time soon (unlikely) to get more familiar with the codebase for fun, I wouldn't be willing to do it unless the cost covered my time to get intimately familiar with the codebase in addition to implementing the features as well. So it makes more economic sense for BitShares stakeholders to pay people who have already put in the effort getting familiar with the codebase like abit, svk, or of course CNX.
And that leads us to the main problem. Funding. People don't work for free. Or if they do, they won't work for free for very long. If we are having trouble keeping workers like basic blockchain and GUI maintenance and documentation in, what chance do we have to pay for a new feature or improving the UX of existing features? That is the general problem. In the specific case of stealth, since STEALTH asset holders get the fees of stealth usage, they should be the ones who try to raise additional funds to fund some of these features/improvements. Although, it isn't that simple either. The UX innovations in the quote above are for blinded transfers. My opinion is that blinded transfers (not stealth) should be the default and use rate-limited free transactions for optimal user experience just like other BitShares transactions hopefully eventually will. In that case, STEALTH holders wouldn't get revenue for blinded transaction usage. So BitShares workers should probably be used to fund the UX improvements/integration for that. It is the other more advanced stealth features (the ones that by their requirement for privacy must use fees because they cannot use rate-limited free transactions without compromising privacy) that can pay fees to the STEALTH asset. And so I think those more advanced stealth features (which would be the more costly one to implement properly) are the ones that STEALTH holders should raise funds to implement. Of course my ideal preference would be for BitShares to just buy out STEALTH so we don't have to deal with this FBA management nonsense. Then BitShares workers would fund all these improvements and BTS would get all the revenue. But again, the problem is funding. The anti-dilution camp is suffocating us.
-
If @abit and @svk would be willing to implement this, I will get the funding. I need a realistic timeframe, bid, and at least 3 milestones so that we can monitor the progress, but other than that, I think we all agree that those guys (maybe @arhag could help consult too) are definitely among the best candidates out there for this.
Worker proposals are not even an option right now, but if you guys are up for it, I would like to get this rolling asap and get true Stealth finished for Bitshares.
Please advise, thank you! :)
-
So why is generating such a key, i.e. an algorithm produced brain key, seen as either inadequate or prohibitively inconvenient?
I don't think it is. I'm not sure anyone really thinks it is either. I think people are mostly just confused about the actual issue.
Apparently I just don't get BM's primary concern about using the blockchain as a storage vault for wallet backups. I know he's now of the belief fees are bad, but stealth has never been a feature designed with "no fees" as a requirement. If backups are essential for making stealth usable safely, then a charging a backup fee proportional to the amount of storage required for it is not unreasonable, just like charging a fee to use stealth was not seen as a bad thing.
I'm not sure what bytemaster's primary concern about using the blockchain for backups is. I'm concerned about poor user experience if keeping your funds secure required backing up a lot of data to the blockchain that you had to pay fees for. There are ways to get around this. First, we distinguish between blinded transfers (hide balances but not metadata) and stealth transfers (hide balances and also to some extent hide metadata). As I outlined in the above post, it is possible to design the client and user experience in such a way that blinded transfers do not require any wallet backups to the blockchain explicitly requested by the user nor does it require unexpected costs. The cost of updating your account private keys may be a tiny bit larger than now in order to upload the encrypted payloads with custom operations as I described in the post above. Even this small cost could be totally transparent to the user with rate-limited free transactions.
Stealth transfers on the other hand may (depending on how they were done) require far more data to be backed up to the blockchain. If we require the user to explicitly back up data to the blockchain and pay a fee to do so after every new stealth transfer receipt, this will lead to very poor user experience. The UX will be much better if the cost of the blockchain upload backup can be accommodated using rate-limited free transactions, but there is a concern of blockchain bloat in that case. That issue can likely be mitigated to a large degree by only uploading necessary deltas to the blockchain and being smart about encoding to reduce the size of the transactions. There would still be concerns that the user may not have enough BTS funds to afford the bandwidth to backup frequently enough to keep up with the stealth transfer receipts, and there are other issues regarding compromising stealth privacy if the client makes backup delta uploads immediately after each time it receives a stealth transfer. These issues all hurt UX and/or privacy and/or risk of losing funds, which makes me think it is best to not spend effort on stealth transfer as they exist now and instead focus on just blinded transfer. If we come up with a metadata privacy protecting stealth transfer mechanism that doesn't have these UX problems and privacy or fund loss risks (that is what I am currently spending some time thinking about), then we could discuss spending money to implement that in the future in addition to blinded transfers (which would likely still remain the default).
If @abit and @svk would be willing to implement this, I will get the funding. I need a realistic timeframe, bid, and at least 3 milestones so that we can monitor the progress, but other than that, I think we all agree that those guys (maybe @arhag could help consult too) are definitely among the best candidates out there for this.
Worker proposals are not even an option right now, but if you guys are up for it, I would like to get this rolling asap and get true Stealth finished for Bitshares.
Please advise, thank you! :)
Now we are talking! But read what I wrote above for why I think getting true stealth finished for BitShares shouldn't be the initial goal. I think we should get it done as follows (further granularity for milestones is something to be discussed later):
- First, we build the user interface to get blinded transfers (not stealth) to work. Devs are paid for delivering this. At this point keeping private keys backed up to not lose funds is the job of the user.
- Second, we build the automatic key backup strategy (mostly what I discussed in the post above) in the client and likely some other offline tools to manage key derivation and account recovery in a secure manner. I can describe this in more detail later. After achieving this milestone, a regular user that uses the GUI client would not have to worry about doing manual backups (other than an initial one) to be able to fully recover all of their funds (and memos). This strategy would also not require third-party servers to manage backups nor would it be cost prohibitive. Devs are paid for delivering this milestone as well.
- Third, we can then work out the design of a proper stealth transfer feature that doesn't suck in UX or risk user's funds. We can plan out the costs and discuss potentially funding the implementation of the feature.
Also, if you have funds to spare, I think getting rate-limited free transactions to be better integrated into BitShares is way more of a priority than step 3 above if we want good UX.
-
I have doubts about the amount of time @svk or @abit (and even you arhag) are willing to invest for work on BitShares, when steem is attracting all the attention of the devs. Arhag, you say "Devs are paid for this..." but Kens approach to funding development would probably exclude those people due to their higher pay rate to get them interested, especially considering the opportunity costs associated with not working on steem.
Is it feasible to split true stealth implementation into 2 parts:
part 1: hiding the balance of transactions (i.e. blinded transactions)
part 2: hiding the metadata
If true stealth is the combo of parts 1 & 2, then working on part 1 first is working toward true stealth. Part 1 could be free / paid for by rate limited xanctions, part 2 for those that want / require it is optional and requires additional fees, perhaps to pay for backup storage.
Just thinking out loud here...
-
What is the present status of this, and is there an ETA for completion?
-
What is the present status of this, and is there an ETA for completion?
Did the stealth feature ever get finished?
-
What is the present status of this, and is there an ETA for completion?
Did the stealth feature ever get finished?
I guess not.
-
BitShares Munich has been working on it. Keep an eye here for updates: https://steemit.com/@kenCode
-
Thanks. Is this forum losing to steem? Do most BTS users post there now?
-
Thanks. Is this forum losing to steem? Do most BTS users post there now?
[/quote
Not to steeam but most of the discussions happen on Bitshare Telegram now.
-
can follow on https://steemit.com/@kenCode
I think also now working on Agorise
-
Testnet is running, UI is mostly done (for Normal/Blinded/Stealth options), so I will open the testnet up to the public in a week or two. The accounts and contacts screen is coming along this week. The UI that facilitates the backups will come in a few weeks, for now I want to get the public to our testnet asap so the testing/auditing/hacking/wiresharking can begin. I dumped the slow, unscalable zcash/libsnark stuff in favor of Blockstream's slightly faster CA code, but we might even be able to dump that and do our own math. Looking into that some more right now.
Thom brought up some really important legal points about using their CA code, you never know what that company may do in the future, so it's best if we can avoid use of their CA code if possible. Hiding the asset that was sent is not really that big of a deal, it's just math. ;) Same thing goes for the balances and metadata. We're also doing our own coin tumbling and extra layer of coin/address mixing and if all goes as planned, we should be able to keep almost all of it on-chain.
C-IPFS is mostly ready now for the automated backups too:
https://github.com/Agorise?tab=repositories
I don't use this forum much anymore, so to follow the Stealth status, and the additional products I'm launching, it's best to hook up with us in the telegram group:
http://t.me/Agorise
or steemit:
http://steemit.com/@kenCode
Hope to see you guys there! :)
Peace, Love, and Agorism.
-
@kenCode, I come out of my slumber after having filled about 30 captchas to train some google AI against my will (cloudfart still going strong here on the forum it seems) to express my concern about the latest update.
It appears to me that having considered libsnark at all, given it's need for a trusted setup a la zcash (endless source of rumors, contention and distrust, wasn't the idea trusting less parties, not more?) was a grave mistake. Unless something has changed in the last few months, libsnark is horribly slow too.
But perhaps even more concerning is that so late in the game your team is still, if I got the gist right, wondering which cryptographic fundamentals to use for the system.
Cryptography isn't "just math", it's some of the most complex maths around, very hard to get right, and few who attempt to "do their own math" ever get it right.
This uncertainty about at least 3 cryptographic options leads me to believe that the architecture of this feature has not been very well thought at all. Contrast with Monero for instance, where there has always been a clear roadmap, an understanding of the limitations of the present evolution of the system, and a precise and targeted plan to address them.
So that's one aspect of it where I would like your clarifications if possible.
Something else I'd like to bring us, is clarification on the following points:
We're also doing our own coin tumbling and extra layer of coin/address mixing and if all goes as planned (...)
1. Why is any extra tumbling necessary?
2. How would it work?
(...) we should be able to keep almost all of it on-chain.
Who is "we", what is "it", and why and how some of "it" would have to go off-chain ?
C-IPFS is mostly ready now for the automated backups too:
1. Can C-IPFS be made to work with a tor transparent proxy?
2. Why is there a necessity to backup extra information? No other coin that I know of has this requirement (most notably, Monero).
3. Cryptographically, how is the backup protected?
4. Does a compromise of the backup result in compromise of funds without the wallet password?
As usual, forgive my bluntness, I don't mean to devalue the ongoing work that you & your team put into bitshares, nor do I question your dedication. Perhaps I should have said something earlier (months ago) when I first read about libsnark and c-ipfs, but as they say, better late than never.
-
I'll show you what the scammers manipulate.
id 1.11.70875024
kencode sent 304,129 BTS to indominon
2 days ago
id 1.11.70926108
indominon sent 103,000 BTS to disperse
yesterday
id 1.11.71352574
indominon sent 104,490 BTS to disperse
16 minutes ago
id 1.11.71352992
disperse bought 89.82 STEALTH at 250.00 BTS/STEALTH
12 minutes ago
onceuponatime bought 22,500 BTS at 250.00 BTS/STEALTH
12 minutes ago
indominon = onceuponatime = disperse
Get out of the world in Bitshares !!!
-
what's your point?
-
total scam:
https://github.com/kenCode-de?tab=repositories
Most repositories have nothing to do with Blockpay, and no contribution from Blockpay "devs". At some time they were talking about c-ipfs being developed and needed (Christoph in the podcast).
https://github.com/Agorise/c-ipfs/graphs/contributors
c-ipfs is from developers totally unrelated to Blockpay...
Ken's only commit for the smartcoin-wallet:
https://github.com/kenCode-de/smartcoins-wallet/commit/5c6976d3c20a34879820b3ebffff9f7d0960d64e
...it is as well from real devs unrelated to Blockpay.
Blockpay "s" is more or less the same as the smartcoin-wallet, and only one commit from Ken
https://github.com/kenCode-de/blockpay-s/graphs/contributors
there appears an unidentifiable bogus dev from Peru:
https://github.com/bilthon
...Christoph was presenting all this crap
-
I don't get it...
Can you please elaborate it?
-
@diablo4 as far as i know the blockpay repos were and are private so i don't think you will be able to see them in ken public github. as far as i know ken is/was a project manager so the number of commits he did or do are actually of no interest. in regards to @bilthon he haves an account here, i have his skype, he is probably dedicating to other projects after bitshares munich issues but i don't think he is an unidentifiable bogus or scammer.
scammers or not this is a thread to discuss STEALTH, not blockpay so i will be definitely more interested on @karnal concerns to some technical and planning issues than on this.
-
If someone is in contact with @kenCode through other channels, I believe his input to the points I raised a couple of weeks ago would be very relevant.
-
@kenCode, I come out of my slumber after having filled about 30 captchas to train some google AI against my will (cloudfart still going strong here on the forum it seems) to express my concern about the latest update.
Hey karnal, sorry for my belated reply here, I don't use this forum anymore, but today I popped in because we have a security related announcement. As you know, we do constant security audits on the code that we produce, as well as code that others have produced. We have a telegram group where we keep everyone updated almost daily, here: https://t.me/Agorise We have 7 products being released this year and next, including Stealth, so it would be wise to at least follow the pinned items in that group to stay up to date with everything that we produce. There are hundreds of knowledgeable folks in our group chat there.
=====
Update on existing Blinded Tx; Security
As mentioned a couple days ago (in telegram: https://t.me/Agorise), we discovered somewhat of a glaring oversight in the way Range Proofs are handled in the existing Bitshares CLI WALLET.
It turns out the CLI WALLET’s choice of RP parameters results in proofs that reveal the ORDER OF MAGNITUDE of a transaction amount. In other words: give me ANY "Blinded" balance on the blockchain right now, and if it was put there by the CLI WALLET, I can tell you within a factor of 2 how much is in their balance.
NOTE: Before any panic sets in, we're 99% sure this is a result of mis-use of the ZK library, and NOT an inherent problem with the range-proof algorithm currently implemented on the blockchain.
This means that the new version of the Bitshares-UI that Agorise has produced can fix this, and produce Blinded Transactions that are really Blinded. (or at minimum, produce uncertainty of amount far greater than a factor of two).
The problem: One of the header fields in the range proof is a count of bits used to represent the mantissa, or the precision part of the blinded value. The cli_wallet uses a "default" value for the "min_bits" parameter, which, instead of specifying how many bits of data we wish to hide, allows the RP code to select the value automatically. The "automatic" value selected is the minimum number of bits needed to represent the value, which gives us immediately the order of magnitude of the value.
We will need to add some logic to choose this parameter a bit more carefully. We’ll need to understand the trade-offs and implications of the parameter choices a bit more thoroughly. The current ZK library is a very flexible one that does allow you to shoot yourself in the foot, apparently.
(https://i.imgur.com/p9wqnvc.png)
So, we need to use max bits because the range proof format uses a sort of custom floating-point. But we don't have to necessarily choose the number of bits as a *minimum* needed. We can add a random amount MORE bits, so that the uncertainty becomes a factor of 2^n where n is the max number of bits the client might add to the minimum needed.
We think it's still possible to use a sliding scale, but need to look at what happens to the low-order precision bits when we start using them to create uncertainty in the upper range.
There presumably exist people who have used the CLI wallet to create and transact in Blinded balances. They may be under the impression that their balances are MUCH more private than they actually are. Those people deserve to be made aware of this, hence my post here, and in our telegram group (https://t.me/Agorise).
BTW, I don't know that this shortcoming isn't already publicly known. It's just the first I've seen it, having not spent infinite hours delving into the forums. In searching the forums, github issue tracker, and google at large, I could find no mention of the range-parameter privacy reveal. To my knowledge, it is not discussed anywhere, and perhaps not known to be a problem.
So, on the bright side, we @ Agorise have discovered another way to make Bitshares an even more secure platform, allowing us to deliver even higher quality products.
We have submitted the technical details to the Bitshares Core Developers, and will hopefully get our fix merged in asap:
https://github.com/bitshares/bitshares-core/issues/480
There is a potential flaw with this algorithm. At the moment that the user stores their balance on the blockchain...
Also, we found a forum post from @arhag describing a potential vulnerability in which a transaction, should it be rejected by the network for missing an expiration window and need to be re-signed and rebroadcast, could enable determination of the signing keys by a method similar to what was used to break the encryption keys on the PlayStation 3. We're not sure if this has been remedied or not, so we'll try to get to this as well this coming week. It's a very real potential attack vector if it's not addressed.
Ok, back to work now. Feel free to chat with us in our telegram group:
https://t.me/Agorise