200603-01 - blind balance / privacy by default
There have been chat-discussions about privacy by default and removing the blind balances.
Please share your opinion on that.
For a more intuitive and private by default marketplace I propose following approach:
make the anon balance to the standard in- and outgoing balance
rename the balances to:
- buy / sell account (formerly anon balances)
- listings account (formerly public balances)
- escrow account (formerly blind balances)
restrict the receive options:
- only allowed are anon-transactions directly onto the buy/sell account
restrict the options for convert:
- allow tx from escrow to buy/sell account
- allow tx from listings to buy/sell account
- allow tx from buy/sell to listings account
restrict the options for send:
- only allowed are outgoing anon-transactions from the buy/sell account
rename “particl desktop app” into “particl marketplace” and make the marketplace the upper top item on the left selection bar (the desktop app rather becomes a marketplace with included wallet instead of a fully functional wallet app)
For voting and governance purposes I would rather create a separate “voting account” instead to “reuse” the “listings account”. I think for most newbies this should be easier to understand.
Pancake last edited by Pancake
While I understand the direction this proposal is aimed at, I’d like to clarify some things first that maybe be relevant to this, and other, proposals.
Firstly, its important to consider whether the perception is that Particl is an e-commerce only type of project, or whether it can be used for general purpose use cases as well. This is important, because if the viewpoint is that it provides for broader, general purpose functionality satisfying a number of different use-cases, then we need to consider that the marketplace is a single implementation. Its the first such implementation, and the one most marketed and pushed at the moment, but the general idea with this viewpoint is that other application for Particl will follow in the future. This is the viewpoint that I’m following for the Particl Desktop currently, and so the remainder of the discussion below is based on this perspective. If however, we’re taking the approach of Particl being an e-commerce only project/coin, then sure, that narrows the focus of the conversation, but it probably becomes more important to discuss how best to adapt/modify the blockchain itself to serve this single purpose.
The 2nd thing thats important to consider is the structure of how the current ecosystem fits together. In very simple terms:
- Particl core consists of the blockchain network (note that this is where wallet’s, peers, blocks, etc are managed), and the smsg network. The smsg processing in core acts like a mailbox at a post office: the node receives all messages distributed to it, it tries to see if any are addressed to it (ie: if it can decrypt the messages), and stores for some period of time the messages actually designated for it. 3rd party systems/applications can then ask the core smsg “mailbox” for unread/all/etc messages, and then handle those by processing them, and then instructing core to mark them as read, or to delete them. There’s more detail involved, but I think that’s all thats relevant for now.
- Particl marketplace, which I’ll refer to as the “MP engine”, interacts with core to send/receive smsg messages, process those messages meaningfully (extracting the info sent in them for listings, orders, etc), and then also provides an API in order to query this extracted and processed information. It also interacts with the blockchain side of core in order to create escrow related transactions. Again, keep in mind that the MP engine is not the only “software” that send/receives smsg (eg: the exchange bots do as well) or interacts with core for blockchain functionality: in the case of any 3rd party application, they too would be able to perform any of this functionality as needed.
- Particl Desktop (PD) is basically a nice user interface that sits between core and the user. We’re currently bundling the MP engine as well, and providing a nice interface for that. Other applications or use-cases can follow (for example, the exchange/swop bot implementation is technically one of these as well), and then there’s a whole separate discussion to be had here on getting other 3rd party engines/UI’s included and whether thats something that should be done or not. But for now, its helpful to know that every action the user takes in PD simply calls one or multiple API endpoints on either core or the MP engine (or the exchange bot).
Now, given the above information, and remembering that a wallet has no semantic meaning (theres no special meaning to any particular wallet), here are my thoughts on the above proposal.
Building a standalone marketplace application can definitely be done, but this should likely be completed by a community effort. I don’t see much of a point in providing and maintaining 2 separate applications officially. It might make sense to do officially if each catered to a different, distinct user type/market segment, AND there were sufficient resources to dedicate to this, but we’re a really small team at the moment and I don’t think its feasible to do so.
With that in mind, and considering that “multi-app” interface is being catered to, it doesn’t make sense to rename the desktop to “particl marketplace”. We’re already adding in other functionality that is not included in the marketplace (the exchange bot for starters), so this is hardly just a marketplace application anymore.
This “multi-app” mode means that the approach that’s been taken in the next desktop version is to separate out the different “app” functionality. Wallet functionality deals directly with managing your wallet and ‘finances’. Marketplace is where you buy/sell items. If we introduced a chat application, that then would be a separate “app”. It doesn’t help positioning marketplace related content in the wallet app section, because the wallet app is about interacting specifically with the wallets available, and not about what those wallet mean to different “app” use cases, eg: its not managing funds for any app specific functionality. As such, each “app” has a clear purpose, and there’s no problem with intended purpose of the app itself. Think of your cellphone: your camera app doesn’t contain information about the barcode reader app, despite the barcode reader app using the camera. To this extent, it should be noted that, in the previous released screenshots of the next PD version, none of the wallet functionality is actually included in the market “app”, and vice versa. And similarly, none of the exchange specific stuff is shared with the other apps. What I can say is that the balances shown in the marketplace “app” reflect their use case better, and can be considered to have been “renamed” appropriately for its intended purpose in this “app”, but their is no transfer/converting/sending/receviving funds in the marketplace “app”.
But lets temporarily ignore all of the above, and discuss the restrictions proposed: these don’t appear to be practically possible to be implemented. To be very clear, these are not restrictions that should be applied in some 3rd party application to core (eg: MP engine or PD), and I’m skeptical at the likeliness of its addition/inclusion in core.
Consider that some 3rd party application that is built and released to the community (Example: some community member’s standalone MP application). Using that application (or any other Particl application), with any particular wallet, the developer of that application would also need to be restricted to only allowing funds to be sent to anon addresses. Since nobody has control over that (we can’t force any developer to build in certain restrictions of their own free will), you inevitably end up with the possiblility that users end up with funds in their public balance on a wallet used in the marketplace. Moreso, a user currently needs funds in their public balance for voting on flagged items, etc, and such funds may be sent from another, an exchange, etc.
Its also not possible to know what the user’s intentions are when converting funds, or what the destination wallet’s usage is in terms of ‘sending’ funds. Which allows users to send funds to their public balance on a market related wallet, for use in some other application, and then switch over to the marketplace “app” and use them there (or even open another standalone MP application and use the funds there). The basic point here is: its not possible to know whether the target address, when sending funds, belongs to a wallet controlled by an exchange, or another wallet the same user controls, or someone else’s wallet, etc. Hence, until each wallet has a single intention, and each and every application is only able to use that wallet for the specified intention , the restriction of sending funds to a particular type for any wallet seems pointless. And such restrictions on wallet intentions are a core implementation, and not very practical at that (unless maybe during discussions about modifications to the blockchain to function solely and purely as an e-commerce coin).
There’s also no way to restrict funds being received by a particular wallet for a particular transaction type. Which goes back to blockchain basics: if funds are sent to an address, then they can be spent if the corresponding private key is used to sign the transaction. Since anybody can send funds to any valid address, the way to restrict receiving funds on public addresses would be to prevent their generation and distribution (thus ensuring that nobody has a public address from the current wallet to provide for the sending of funds to). This prevention of public address generation can’t be restricted on the 3rd party side, since any other 3rd party application developed by anyone would not be adhering to the same restrictions. I can’t speak about core, but I can imagine that its not feasible to do this there either. Besides, consider that not having public address balances would slow down confirmations, and in the marketplace would then remove the whole functionality around flagging/voting of items. There’s a lot more issues to this… but I’ll stop for now as its getting a little too long now.
But yeah, I can appreciate the effort in putting this proposal together and attempting to provide a solution. Hopefully there’s still a discussion around this to be had… I’ve said this already before but these are not easy problems to solve. Its helpful to lets consider or keep in mind that the devil is in the details, and any solution needs to be technically feasible, sound, and possible before we can consider the usability or practicality of using it. It doesn’t help providing some nice UI implementation in PD, but its all smoke-and-mirrors and the moment that some other application comes along then the smoke clears and the mirrors crack and it becomes pretty clear that there’s no real solution underpinning the implementation.
I agree with you and it’s great to hear that there’s much more in the pipeline for which the basic development is becoming ready as well. But maybe one standalone temporary product with limited applications (e.g. as not being a fully functional PART-wallet for supporting all the three coin status) would make it easier for newbies to familiarize with the app.
When first using the mp, it really took me a long time to understand what’s going on with my orders and all the different coin status. Basically I never needed blind balances except for the escrow releases. Since many crypto user appreciate privacy by default, it would be nice if we could protect them from accidentally disclosing their privacy. That’s why I came up with the proposal for only displaying anon-addresses as receiving addresses, and also only allowing anon-coins to send out by the GUI.
This would better preserve privacy and maybe also reducing complexity for newbies because anon coins are basically the only coins they would need to handle with.
I also agree there are open questions on the voting, or the possibility to use the console to “mess things up”, but we are still in Beta-status. Thus wouldn’t it be possible to release maybe a “standalone” Particl Marketplace Basic Version, only to gather already some more user feedback. Meanwhile the team can further develop the PD with all its integrated functionality. So maybe this Basic Version would only be some kind of snapshot without becoming further supported, maybe only running on the testnet, but I think it might be good for gathering further user feedback. So there wouldn’t be any incentive to provide any 3rd party application on this not further developped Basic Version.
So this shouldn’t stopp the current integrated PD development with all it’s feature rich possibilities and benefits by Bots and 3rd party app-providers.
Thanks a lot for your reply and also for answering the AMA questions. I personally stopped ordering anything from the marketplace because I am waiting since January for the new release with private markets. So it would be really great if we could have at least a testnet version soon available. I’m not a developer, but I know software is complex and as you mentioned, the devil is in the details.
Um, so yeah, where to start?
Let me start by saying that I don’t think doing a standalone, throwaway type application is the best use of our resources at the moment. We’re a really small team currently working directly on/around Particl Desktop at the moment: Allien is busy with getting the layouts and flows working in the desktop, I’m wiring the stuff up to the different backends, and ludx is busy with the MP engine. Thats basically the extent of the team working directly with/around Particl-Desktop. Just to note: I don’t want to suggest in any way anything about anybody else’s role: everybody else is busy as well, doing what they do. But in terms of dev’s working on/around this, well then its basically the 3 of us at the moment.
Now, stopping work and doing a separate product as a once-off thing that never gets updated: I’m not sure I can personally justify spending time on something that needs to be production ready, is a replica of the functionality that we’re currently working on, and is a once-off that we never work on again after this. I’m not sure others would be happy if I did the same.
There’s also no such thing really as a once-off: once you release something you have to assume that somebody is using it and potentially depending on it (for some definition of “depending”). There’s the implicit expectation that any product put out there is, and will, need to be updated or re-used at some point in the future, or bug fixed… If we put something like that out there, people don’t care what you intended it to be used for, they will use it for what they want to use it for. And thats typically followed by some form of expectation of maintenance.
Which is not to say that it can’t happen. Just not within the current constraints.
I also don’t want to put something out that is still being worked on, just so people can start playing around with it. No matter how much you tell people that its a work in progress, a list of everything that is still work in progress then needs to be compiled and distributed. And most people don’t seem to read that anyway, leaving us spending time dealing with bug reports for things that are still being worked on or are not yet implemented, taking time away from actual development.
We can maybe do something like putting out the current working without the marketplace included, so that at least people get to test the wallet functionality so long (since that is generally considered complete already). Not sure if that would be helpful at all, since I suspect that you’re after the marketplace functionality already
Also, the blind balance in the marketplace doesn’t actually feature in the new version. If you refer to the more recent screenshot from the “Market’s Overview Page” in the recent developer update, you can see how the overview page of the marketplace is looking: no blind balance in sight, and actually, I just noticed that there’s no public balance value either. Which might be perfectly fine, because a public balance only applies when voting or creating listings, so can be displayed in the more appropriate place (wherever its used), for example. Keep in mind that this is the Overview page for the Market app (the market icon in the sidebar is highlighted).
Does that maybe go a little way towards helping remove confusion around the different coin situation when used from within the marketplace?
letsparty last edited by
I have little to add other than that I appreciate what smilingidiot taking the time out of his day to answer these questions so thoroughly and thoughtfully.
I am on the side of steering users towards using RingCT rather than public tx in the wallet GUI. Imo privacy should be opt-out, not opt-in.
whiterussians last edited by
I find it incredibly disturbing to read all this from the core dev of the project. I must say, I really do respect all the work you do, you seem to be incredibly good at what you do, your deductive abilities and knowing how to code.
However, why is it just the dev responding here but not the project manager, leader, the guy that is responsible for communicating where the project is heading and responsible for making important descisions like these? Why are these incredibly important, smart and obvious suggestions from pancake addressed by a developer but not our lead communicator/project manager? You wouldn’t want to suggest that these key suggestions are up to the dev to decide? That would literally turn my world upside down.
Why is it still up in the air (aparently) whether particl represents private e-commerce or broader blockchain functionality? Lets be honoust, there are other smart contract blockchains that have won that battle and particl is in dire need of a unique identity to gain use and further traction.
The fact of the matter is, all of these other, so called apps, which are or may be added in the future are mainly there to facilitate the already existing core functionality, which is the anonymous buying and selling of services and goods. These apps are not really something you should promote as a standalone, simply because they are not as interesting as a standalone. They are important and surely may add a whole nother realm in the future, but are mainly there to, again, facilitate particl’s anonymous e-commerce functionality. It seems it’s stil unclear what the core vision of this project is, which is worrysome. Someone needs to take the lead here and make a “snap call” when suggestions such as the ones from pancake are made.
Yes, of course the marketplace should be the first app and in fact the first thing you ‘experience’ when opening particl desktop. This is what the application is all about… Why I also agree with renaming the application to “Particl Marketplace”. As long as nothing unique or world revolutionary is introduced that may become your new core product, why wouldn’t you want the marketplace to be your core feature and be the most conspicuous? Just sell your product accordingly guys, it really doesn’t have to be that difficult and you’re only causing more confusion and dissonance, in and outside your community. You can’t stay in the middle, but have to choose in order to represent something. If you don’t youre just a nothing.
Why the hell would you want ‘wallet’ to be the first item? As if somebody needs to confront you with your personal finances every time you walk into a clothing store. Can’t I just look for some leather kinky pants first before I check if I have enough money on me?
Surely you may provide the user some feedback about its finances on the initial screen, but it should be clear from the get go that the application is all about the marketplace, not just another wallet to store cryptocurrencies into.
Don’t be afraid to make changes to your baby and get rid of things that have been for a while, this product is in dire need of a core identity and key improvements in order to gain traction.
Ohh, and I fully agree with improvement in terms of anonimity. If not technically feasible, it should be looked at as you want to cause as less confusion as possible. Get rid of the “blind” termination completely for example, at least in the GUI. This is a people application, the simpler the better. Not everything needs to be described in full depth or accuracy, as long as the user is able to buy and sell without friction while retaining full anonimity.
Firstly, I am not, and have never claimed to be, a core dev. Definitively not in the sense of particl-core development, nor in having been around “since the beginning”, etc. Nevertheless, I am currently on the team, and my primary focus is on particl-desktop.
Secondly, this is a community forum, run by the community for the community. At least as far as I understand it to be. I hardly expect that this is any sort of official mechanism for team communications, well, at least not that I’m aware of. So there’s validity to there not being someone more senior to my position lurking here and providing some higher level of official insight.
My contributions here are merely as a way for me to engage more with the community, as a member of that community: while I may be on the team I am also a community member, and feel its helpful trying to engage a little more with some insight into what we as a team are looking at, etc. Please dont interpret my commentary as official perspective, but more as insight from someone working on the product each day.
Now for the real topic at hand: the marketplace transactions are private by default. The issue with releasing to blind couldnt be fixed in the current v2 releases without changing some functionality which may have broken some transactional state, but it has already been addressed in the next release. This doesnt seem to be the main issue at hand though: the basic issue here, going back to the beginning, is that of using public funds in the marketplace, at least the way I’m interpreting it.
The concern being that if someone sends or spends funds directly to or from their public balance in a marlet wallet, then that leaks information. Suggestions so far have included the use of anon funds for smsg message fees, and changing the user interface (notably, just the particl-desktop one) to force users to only, or possibly at least initially during a send funds action), to only use private addresses. The latter seems to be trending, so I’ll go with that for now.
Now how would this work… Forget about all the other functionality I’ ve previously mentioned, and lets assume only the wallet functionality and marketplace functionality exist. Also that you can use any wallet X on the marketplace (we’re not dealing with a single wallet named “market” anymore here, so we have multiple possible marketplace enabled wallets).
So, in the gui, lets assume we now hide any means of generating a public address. How do you now send funds to some wallet Y that you own, that may or may not be a market enabled wallet? Do exchanges etc support sending funds only to a private address? If not, how do new users get their funds from an exchange into a MP enabled wallet? If they do, how do we force them to do so? How does someone who just wants to do “hot staking” get their funds there? Please consider that there are a lot more scenarios and options that need to be catered for here… And that we cant assume that a wallet is going to be a MP enabled wallet or that the user doesnt have need for a public address. In fact, the better option here is a full protocol change, and if/when that occurs then the gui will be updated accordingly.
So now lets assume that we try the route of forcing all sending of funds to be done only by anon. How do you now get funds to copay, to exchanges, etc. Whether on a market enabled wallet or not. Maybe the thought here is rather to limit sending of funds to a MP enabled wallet to force those to anon. But how can one wallet, when sending funds, know whether the ‘to’ address of another wallet is some MP enabled wallet or not? Its a different wallet… Could be owned by anybody. So not exactly feasible.
Keep in mind that a wallet, like the process that owns/manages it, particl-core, is not marketplace aware… The marketplace engine (separate process) makes use of core functionality, but core is independent and unaware of the marketplace specifically. If the call is for that to change, then so be it… But thats a separate discussion to trying to force behaviour into the gui to simulate that.
Plus, lets assume that somehow we managed to force/simulate this behaviour in the gui somehow. So now we need to force the user to wait for the sending to anon to clear, and then they need to convert some funds to public after that. That now becomes a UX complaint because the process isnt as simple or easy to use. Why not do it automatically, etc. But fhis all complicates the matter further when considering more use cases beyond just the one. For example, how much should go to public automatically? What if that is 0 for most such conversions? Can we have the user stay online for this entire process, with the wallet unlocked if encrypted (which we shouldnt be encouraging either)? Isnt that a big ask, if things are already too complicated as it is (looking at all the resident UX experts here): imagine trying to explain to users the need for these steps needed to set up conversion of funds, just so they can post a listing.
Other possibilities? Sure, I can go on and cover the options suggested so far, but I think this is getting a little long-winded right now. So heres the point: I’m going to say very clearly that I understand what the suggestion is attempting to achieve. But no, I dont see it practically being implemented in the gui alone, or at least not in a way thats been meaningfully discussed yet. As with everything there are various tradeoffs, and I dont believe that doing this in the GUI achieves the intended goal without overly sacrificing functionality in other very real and very impactful ways. The alternative for now, until a better solution is found, is simply education. Which makes sense by way of finding a proper solution and doing that instead of jumping the gun and pushing ourselves into a corner, and then dealing with unrelated fallout as a byproduct of decisions taken too rapidly without thought for the consequences thereof. And thats why I’m not jumping at the solutions presented.
whiterussians last edited by
I have confidence that the level of anonimity will only increase over time as the team will logically look for ways to increase it. Preferably making this protocol anonymous by default.
I was very specifically referring to some other changes/suggestions which seem more important short term and can be adopted instantly. Such as prioritizing marketplace functionality over wallet functionality, making the app more about buying, selling, shopping instead of a dashboard with transactions, coin counts and such when you open the application.