Proof of account ownership / SNT distribution

[rachelhamlin]

Problem

[DRAFT]

In order to facilitate:

• Return of chat commands to send/receive Txs
• Sending of funds to a list of contacts from the wallet

We need to establish proof of account ownership from user A to user B.

From notes on the issue by GL:

With multi-account, A whisper keypair is different than A account keypair, so when A sends to B funds from chat, and A sends a message over whisper to B to claim he has sent funds to B, B can’t verify if the funds that A claims he has sent were really sent by A.

So A should prove ownership of the account address through a whisper message containing a signature by this account.

Implementation

I believe we decided to do this

not systematically: only when A sends to B funds from chat then the proof opf ownership is systematically added, and B can show the message in chat only if this proof of ownserhsip is present

Acceptance Criteria

My understanding is that this is solely a technical task, but would like to understand if there are any implications for the user experience.

[3esmit]

Possible solutions I can see:

Interactive

1. On "friendship":

• similar to how users exchange given name & profile picture

2. On request:

• paying user send private system message to other user
• user sends payment to account sent by other user

3. Shared anonymous contract

• everyone uses the same contract
• proofs to withdraw are sent via message
• user can withdraw from any account
  e.g. https://github.com/HarryR/ethsnarks-miximus/

Non interactive

1. Shared transparent payment contract

• everyone uses the same contract, user send payment to user chat identity,
• chat identity can withdraw it at anytime.

2. Payment contract derived from chat key (CREATE2)

• create2 opcode can be used to generate/predict contract address
• chat identity can withdraw it at anytime

[oskarth]

This came up during Devcon drinks.

Sending of funds to a list of contacts from the wallet

@jacqueswww and @gravityblast had some thoughts on how this can easily be achieved, essentially it amounts to signing (in the general cryptographic sense, not with eth) the transaction (all cryptographic key requirements are already met). We can also easily default to the first "hot" wallet (and later extend to being able to rotate the use of this), which then leads to "tipping wallets" (kudos etc), where you don't need to sign transactions for small amounts, something that the multiaccounts spec enable AFAIK.

This is a primary use case of Status - to send funds to contacts - so if we can do this in a simple way for v1 that'd be very useful.

EDIT: To enable this a user can just include a hot tipping address in the contact request, for example

[3esmit]

Another option to solve the problem:

• Update SNTPlaceholder (SNT Controller) with special transaction method, using two ethereum signed messages, one from token sender with destination chat key, other signed by chat key defining destination wallet.

Not the best because it requires a non standard function and the change of a very sensitive smart contract, might be useful as last resort or to brainstorm.

[gravityblast]

I would be ok to send from and receive funds to the chat key when sending through chat, like a tipping account as we said in some discussions.

If instead we want to allow the sender to select any "from" account, he can just create a signature from that account and include it in the message body.

The message is signed by the chat key; the "sub-message" is signed by the tx "from" key, containing tx hash, chat from, chat to.

would that work?

[3esmit]

Just a breakout of the issue.

Proposed solution

Interactive, on request: Use protocol to inform wallet address on request.
Flow:

1. Sender requests wallet address by chat (protocol message)
2. Receiver chat-key signs message containing any address they want to receive payments into.
3. Receiver makes transaction from any wallet they control and sends transaction hash by chat
4. If transaction hash corresponds to a recent transaction to receiver signed wallet address, it would be shown in the chat.

Facts:

• Sender chat-key (EIP1581) does not control funds:
• Sender knows receiver chat-key;
• Sender don't knows receiver wallet address.

Relevant Scenarios:

• Sender is on Receiver contact list
• Sender is not on Receiver contact list (see tribute to talk/spam protection)

Major Problems:

• Receiver needs to be online to promptly answer wallet address request

Minor Problems:

• Sender can disclose receiver's wallet-address signed message.
• Sender can see receiver past and future transactions
• EV1L Sender can spam wallet requests at cost of identity generation + whisper PoW

[yenda]

@rachelhamlin @errorists is there designs for address request?

[errorists]

@yenda are we doing manual address requests? there are no designs for that, should I create them? i thought you're on notifications now :P

[yenda]

@rachelhamlin @errorists I suppose manual address requests make sense yes, or that could be included in the contact request but I think separated is better, so that it is not implicit for the user

[errorists]

@yenda ok, I mean I agree that contacts should be kept separate and exclusive from any address sharing. Take a look please at these designs here and tell me what you think. I'm pretty sure I'm missing something. I added it both ways there so you can choose to share your address yourself or the sender can choose to request one from you.

[hesterbruikman]

Question: What are the chances we would be able to update shared wallet info post request?

scenario

• @errorists requests my wallet address
• I select account x and send @errorists my wallet address for account x
• Later I decide to change the address I want to share with @errorists to z, for whatever reason. Worst case because the account was imported, stored on another tree and I lost it.
• I change the shared address on my client

Can we send another signed message to update the address on @errorists side?

Trying to understand if it's better to share addresses as a one off with the option for the recipient to save it to contact (more manual phonebook keeping) or share to contact automatically.In other words, can we carry responsibility over updates because it's easy to implement or are we better off leaving it the user.

[jacqueswww]

Question: What are the chances we would be able to update shared wallet info post request?

scenario

• @errorists requests my wallet address
• I select account x and send @errorists my wallet address for account x
• Later I decide to change the address I want to share with @errorists to z, for whatever reason. Worst case because the account was imported, stored on another tree and I lost it.
• I change the shared address on my client

Can we send another signed message to update the address on @errorists side?

Trying to understand if it's better to share addresses as a one off with the option for the recipient to save it to contact (more manual phonebook keeping) or share to contact automatically.In other words, can we carry responsibility over updates because it's easy to implement or are we better off leaving it the user.

@hesterbruikman This is a valid concern. I think I might have simple suggestion to solve this:

• The client (of the receiver) maintains the list of shared addresses already.
• Additionally the the client of the sender maintains a list of shared addresses for contacts, that was already received.
• Every sending of a transaction to contact should follow the request contact's shared address protocol, but as part of the protocol one adds "existing_address" which contains the address I have for contact being sent to.
• If the address differs follow normal approval process, as shown as the designs.
• If the address is the same one can just send an Acknowledgement, this can be automatic.

Having this flow, allows the requesting option to only occurs when the addresses you have for a contact differs.

[hesterbruikman]

Thanks @jacqueswww that makes sense! With

Every sending to contact should

Do you mean every transaction sending or every chat message sending? I ask because we use the contact list also as a selection option from the Wallet. So if I select a contact's address there it either must be up to date or follow the same "existing_address" check.

[jacqueswww]

Thanks @jacqueswww that makes sense! With

Every sending to contact should

Do you mean every transaction sending or every chat message sending? I ask because we use the contact list also as a selection option from the Wallet. So if I select a contact's address there it either must be up to date or follow the same "existing_address" check.

@hesterbruikman I mean with every transaction sending on the protocol level. I have updated my original message. The suggestion should work for both aspects of the UI, as it's just part of the sending process, if you just wanted the address you'd request and then just not proceed with the sending step.

There is the added benefit, that you could have a settings that auto shares the sharing address where the client would just auto respond an account if one wanted to (can be added later).

[hesterbruikman]

Kudos to whoever already replaced Contacts from the selection options in Wallet with Accounts. At least it's not a concern for now as there is no selecting contacts in the Wallet transaction flow, so no risk of selecting a contact with an old address.

This sounds good and means @errorists 's design would work as the account address displayed might be outdated, but can then be corrected and updated when a transaction is initiated. Open question is if it should be possible to copy the address from the other user's profile screen for use in another wallet.

@yenda any thoughts on the implementation effort of @jacqueswww solution?

There is the added benefit, that you could have a settings that auto shares the sharing address where the client would just auto respond an account if one wanted to (can be added later).

• Always use this account

I like it.

[jacqueswww]

Open question is if it should be possible to copy the address from the other user's profile screen for use in another wallet.

My 2c on the matter is yes, why not - as long as the latest address is always requested before allowing the copying all should be fine. And I think it's ok that some people might want to send funds to an address outside status (for example an 'anonymous' tip).

[hesterbruikman]

as long as the latest address is always requested before allowing the copying all should be fine

This would be the ideal! Hope that's an option and would love to understand any requirements and implications to make that happen (e.g. delays, the other user having to be 'online').

I'd also be happy to let users copy the address with the risk of sending funds into the void if it's no longer used #learnfrommistakes. However, as the current design proposal does imply that the address shown in the Profile is the system's source of truth, we would need to either or both:

• Point out the risks of using a potentially outdated address
• Offer the date on which the address was last verified (cc @errorists ).

[rachelhamlin]

I absolutely love the designs @errorists.

@yenda if you're content to own this one, I'd like to hear your reaction to the UI.

This is a bigger item than I realized - and thus I want to recommend considering a leaner MVP for v1. Per @oskarth's suggestion, we could simply use the main hot wallet (the default) and leave the choice to select one to a future version.

I would certainly suggest we leave out the option to change the shared address, for now. You might want the option to revoke, but once an address is known, it's known.

These are the stories we have in the designs, as I can see:

PROFILE

• User A elects to share wallet with User B. User A chooses which wallet to share.
• User A requests User B to share wallet with User A.
• User A awaits wallet sharing from User B (pending state).

CHAT

• User B receives a request to share wallet from User A.
• User B approves and chooses which wallet to share. User A is notified.
• User B declines. User A is notified.

That's a pretty decent scope..!

For a simpler alternative: could we use the command UI to enable User A to send their default wallet info, or to request User B's default wallet info, and contain the whole interaction there @errorists ? It might even be trivial to include the option to select a wallet at that point, using this bottom sheet + logic we implemented for DApps.

We want to bring back the command UI for SNT distribution in the #welcome chat anyway, so just thinking about what's most efficient and how we can optimize for time/effort from here to v1 :)

[errorists]

my 0.02c, I can't say I agree with this approach, commands are broken as is, their discoverability is low thanks to the super confusing icon and we're placing additional functionality inside that may sit there for months to come because it already 'kinda' works.
I don't enjoy shipping half assed features, certainly not while we're supposed to make the move out of beta. i would move this entire scope to post v1 when we can do it properly.

[rachelhamlin]

So what if instead of building out this UI to this extent, we put more love into the command UI? I know you have improvements waiting there as well.

The only reason I'm pushing proof of ownership for v1 is so we can allow for quick and easy transferring of SNT to new users who will onboard en masse for the first time as a result of our v1 marketing push. Thoughts on how to better do that, if not chat commands?

Edit - I also want to note, even if chat commands are imperfect, the main use case at v1 is to support our team sending to others, and our team will know how to use them.

Agree on not shipping half assed features, of course, but I'd rather put the love there + simplify this sharing flow as much as possible.

[errorists]

command UX would need a lot of love, it's basically awaiting a redesign from CLI to a GUI, we'd have to ask Andrey but I believe it's larger in scope than this work here.
So let's assume we move requests to commands, it would cut the profile portion of scope as messages still need to get shown. Is it really that much more effort to include the buttons in profile vs placing the /request in the list of commands? If so then, yeah I guess, let's do it via commands for now.

Thoughts on how to better do that, if not chat commands?

SNT reactions :P

[rachelhamlin]

@hesterbruikman did we have data on the low discoverability of chat commands previously?

@errorists is there not an MVP 'low-hanging fruit' improvement for chat commands as well? You mention the icon, that's one simple thing we could fix.

Alternative 1:

• Make minor improvements to chat command UI, reenable them
• Wallet sharing request happens through chat command UI

Alternative 2:

• Make minor improvements to chat command UI, reenable them
• Wallet sharing request happens through profile + chat

Alternative 3:

• Forget chat commands
• Wallet sharing request happens through profile + chat
• We send SNT to new users through the wallet (need to ensure that shared wallets appear in the list of Accounts - speaking of which, this label in the wallet is currently super confusing to me)

Alternative 3 would be an okay solution for transferring SNT to new users as well. Not the best, imo, but it works.

[errorists]

@rachelhamlin we did user testing of commands back in September 2018, right around ETHBerlin. I'm sure @hesterbruikman can point you to results. The key take away I vividly recall was that even when asked, people had trouble making the association it's the icon to transfer assets, it was often literally the last place they looked.

If we ever were to expand the list to something more than send - receive, I was thinking of a regular 'plus' icon as a catch-all for adding any kind of content other than a written message or a sticker.

In the current context of commands housing only the send - receive transaction, I'd go a step further and design an icon that suggests just that.

I like Alternative 3 out of those the most.

[rachelhamlin]

I'm sure that's true. I also love the + and bucket of options, and see it limits the number of fixed default commands we'd want to support. You'd rather have everything be an extension and leave the user to choose their top N commands.

Looking forward to @yenda's feedback on this one. My goal is still to minimize the amount of work involved, while making it as easy as possible to transfer SNT to new users.

[hesterbruikman]

Edit - I also want to note, even if chat commands are imperfect, the main use case at v1 is to support our team sending to others, and our team will know how to use them.

Anecdotally, I would say sending transactions in chat is perceived as key feature by our userbase inside the Ethereum community. At Devcon someone demoed it with much excitement and I didn't dare tell him that he'd better not update if he wants to keep that feature.

As I also supported leaving it out of V1 in favor of having the basics of Onboarding, Keycard and multiple key management in place (next to the many issues we found with the CLI), I totally understand the low priority, but I think we need to be prepared for some fallout as people might be caught by surprise of no longer having their favorite feature.

[UPDATE: this would still require sharing a default wallet address, probably not the best idea]
An alternative (not sure if we already have it) is to forego proof of ownership for V1 altogether and bring back the CLI in development mode only. Marking it as experimental, un-audited feature.

Findings from testing the GUI commands variation (Aug 2018)

6.1 People can successfully complete transactions using the new chat command design
All participants were able to complete a transaction using the Command designs. Two participants needed multiple attempts.
In contrast to observations from prior testing with the current command implementation.

Note from testing CLI variation (Feb 2018)

Request assets | 5 | Console interface is unconventional and not suitable for mobile | Usability |   |  

[rachelhamlin]

Silly question, but if we supported the CLI in development mode only—would users without it enabled be able to receive chat transactions?

@yenda @andremedeiros

[j-zerah]

Jumping in here to give my 0.02c

From a marketing and community perspective, removing chat commands and any sort of ability to send tokens via chat is a pretty big issue. To Hesters point, this is one of the favorite features of many people. Not only does it provide a really cool way to onborad new users into Status, it also depicts the power of Status and the cohesive ecosystem we have created inside of a single app.

It is kind of the "magic of Status" if you will, while we build out other features.

Also - marketing and community teams have plans to incentivize new people into Status with some SNT sent directly in chat. Once again, it provides such an "aha" moment for new users. We are running paid campaigns with partners in which we will invite them to join a public channel, introduce themselves, and then someone from our team will send them some tokens via the command.

Even if it is not a great UX (I agree with that), it is more important for us to be able to onboard new people seamlessly with some SNT than it is for them to be able to navigate this feature for their own use with friends (selfishly speaking)

Finally, we really need to get SNT into the users wallet so they can explore the app further (stickers, ENS name, Dapp curation, etc). Sending direct via chat command is a sure fire way for the marketing team to do this.

Please, please, pretty please, do not remove chat command for v1

[oskarth]

Please, please, pretty please, do not remove chat command for v1

100% agree, and same from several people in here Ethereum community I have talked to. This is one of the few killer features we actually have right now.

[rachelhamlin]

So let's do this:

Build the wallet share flow proposed by @errorists. Are you on board with that @yenda?

And re-enable chat commands in production. Either exactly as they are, or perhaps with an MVP improvement, such as an icon update to increase discoverability. Do you want to suggest something for that @errorists?

The scope of this issue is then 1) the technical task for proof of ownership; 2) UI for proof of ownership. Dev team please let me know if you think we should split it.

[yenda]

Lgtm, @errorists I might just update the copy in the chat message about sharing your account, sounds a bit scary, the message should be clearer about the fact that you are sharing the address so that the other user can send you funds?

[yenda]

also maybe as a first quick step I could enable commands when the user has a username? because in that case the proof of ownership is already there

[hesterbruikman]

also maybe as a first quick step I could enable commands when the user has a username? because in that case the proof of ownership is already there

This means the account address you share is the address used to purchase ENS, correct? So it leaves out the account selection part of the flow, but would work as long as you have ENS?

Not great from a privacy perspective yet, but makes sense to me. You chat identity and that address are already connected anyway.

[errorists]

such as an icon update to increase discoverability

yeah, I'd like that. I would go with the ↓↑ icon since it more closely suggests users intent rather than the interface to use it [/]

[rachelhamlin]

Okay, I'm thrown for a loop by the feedback here.

As I understand - a simpler first step for wallet sharing would be to enable it only for people with ENS names.

But that doesn't solve our distribution issue, which is what I'm actually trying to prioritize here.

Eric's suggestion for that problem is the revival of a hot wallet derived from the chat key, like we used to have. That's no small change and I don't want v1 scope to spiral, so I've set up a call to discuss with @yenda @errorists @hesterbruikman and @andremedeiros later today.

[rachelhamlin]

Raw notes from our call

I'm going to sit down tomorrow morning and map out the pros & cons of each option as I understood them, and Maciej is thinking on designs.

[rachelhamlin]

Okay, here's an excellent summary of the tradeoffs written by Eric:

In-chat "request" option (#1 in notes)

• less convenient (need to request funds or share/request sharing address first)
• medium privacy (can't infer wallet from address, wallet address is revealed to users when the user decides to in order to transact)
• high security (the wallet accounts are not in memory unlike chat key)

Hot wallet option (#3 in notes)

• absolute convenience
• lower security for funds (key is in memory because it is the chat key)
• no privacy (address can be infered from public-key, other user wallets can be infered by the transactions he makes to and from that wallet)

Snarks (discussed on call)

• not yet available
• high privacy (anonymous payments and withdrawal)
• high security

Proof of ownership (as designed above)
This is like request except that additionally the user provides cryptographical proof that he owns a particular wallet. I don't recommend because without snarks, the recipient can share the proof and you can't deny it. the tradeoff is imo not worth it. I thought about it a lot, and I would univokably choose plausible deniability over the slight risk of a user falsy claiming a wallet that isn't his.

---

It now seems to me in reviewing these tradeoffs that option #1—which offers the simplest possible exchange of wallet details—is the best due to its relatively higher security and lower cost to privacy.

We've explored the hot wallet option in design, and although I appreciate how seamless it is from a user perspective, I feel that communicating good 'hot wallet hygiene' to the user—or otherwise enforcing it, e.g. through an SNT-specific smart contract or a cap on the funds one can hold—represents a can of worms not worth currently addressing, given the higher privacy cost + lower security.

Here is how I imagine the user stories for option #1:

Scenario 1 - Requesting
User A wants to request funds from User B. User A sees the following options in chat:

• /request (token)
• /send (token)

User A selects /request SNT. User A is then allowed to choose the wallet he is requesting on.
User B receives the request in chat and can honor the transaction. User A's wallet address is prefilled for him.

Scenario 2 - Sending
User A wants to send funds to User B. He does not have User B's wallet address.

User A selects /send SNT. A system message indicates that he is awaiting a wallet address from User B.
User B, meanwhile, receives a system message asking him to share a wallet with User A. User B chooses a wallet to share with User A.
User A is now able to send funds to User B. User A selects a wallet to send funds from.

---

We'll be working on an RFC for this concept together tomorrow, to ensure that all the pros & cons are covered in depth. But in the meantime @errorists are you keen to explore the UI for option #1?

[errorists]

@rachelhamlin for sending, would the user need to first invoke /send -> this pings the other dude with a request to obtain his address -> and then once that is given, he needs to invoke the /send command the second time, this time typing in the asset and amount?

[errorists]

in the meantime, designs are 👉 here 👈
I assumed yes to the question above

[rachelhamlin]

The user needs a means to follow through on the transaction, but it doesn’t have to mean invoking ‘/send’ again, unless we want it to.

…

On Tue, Oct 29, 2019 at 2:32 PM Maciej Zadykowicz ***@***.***> wrote: @rachelhamlin <https://github.com/rachelhamlin> for sending, would the user need to first invoke /send -> this pings the other dude with a request to obtain his address -> and then once that is given, he needs to invoke the /send command the second time, this time typing in the asset and amount? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9108>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADWA6Y5PFDNTJBR4ADG3DNLQRBCPHANCNFSM4I5SIBLQ> .

[oskarth]

What's the issue with sharing basic hot wallet when you add someone as contact? This can be swappable in later editions, and also be toggled as something to enable or not.

This to me would be the KISS user story, where a new user can add e.g. ambassador as contact and then ambassador can surprise them with some amount of funds.

the recipient can share the proof and you can't deny it. [..] I thought about it a lot, and I would univokably choose plausible deniability over the slight risk of a user falsy claiming a wallet that isn't his.

How would this work exactly? Then the public keys wouldn't match so obvious the signature would be fake.

Is the concern that a public key (which represents a pseudonym) is tied to a hot wallet? What's the threat model here?

You also don't have to sign it, it can be option depending on your threat model.

[yenda]

What's the issue with sharing basic hot wallet when you add someone as contact? This can be swappable in later editions, and also be toggled as something to enable or not.

What are you calling a hot wallet here? so far in this discussion when we talk about hot wallet we are talking about the wallet address that can be derived from the public key of the chat account, the same wallet you had in pre-v1, whose private key is loaded in memory.

the recipient can share the proof and you can't deny it. [..] I thought about it a lot, and I would univokably choose plausible deniability over the slight risk of a user falsy claiming a wallet that isn't his.

How would this work exactly? Then the public keys wouldn't match so obvious the signature would be fake.

How does what work? "the recipient can share the proof and you can' deny it" means the recipient can reveal to someone else that you own a particular wallet because you gave him the proof, and you can't deny it because you signed the proof.

Is the concern that a public key (which represents a pseudonym) is tied to a hot wallet? What's the threat model here?

You also don't have to sign it, it can be option depending on your threat model.
that is what is suggested here. it is also simpler to implement.

in terms of threat model it is "someone being able to do you harm by proving a wallet is yours" against "some can tell you wallet X is his".
Regarding this second scenario the only thing we were worried about was if you have received a transaction from wallet X and Bob pretends he his the one that sent it. It's not clear how Bob gains something from there.

[yenda]

Also regarding sharing the address in the contact request that is definitely another option. It definitely simplifies the flow. It was initially discarded for privacy reasons but as discussed yesterday since there is trade-offs to be made anyway I would be fine with it. The information should be conveyed to the user that this is shared with the contact, it could be a label in the account screen.

…

On Tue, Oct 29, 2019, 16:18 Oskar Thorén ***@***.***> wrote: What's the issue with sharing basic hot wallet when you add someone as contact? This can be swappable in later editions, and also be toggled as something to enable or not. This to me would be the KISS user story, where a new user can add e.g. ambassador as contact and then ambassador can surprise them with some amount of funds. the recipient can share the proof and you can't deny it. How would this work exactly? Then the public keys wouldn't match so obvious the signature would be fake. Is the concern that a public key (which represents a pseudonym) is tied to a hot wallet? What's the threat model here exactly? You also don't *have* to sign it, it can be option depending on your threat model. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9108>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJAMKKS4Q3VFVYQ32MOUR3QRBH6DANCNFSM4I5SIBLQ> .

[rachelhamlin]

@oskarth you don't have a problem with the privacy/security of a hot wallet for chat contacts? e.g. that users will probably transfer funds from that wallet into one other, blowing the privacy benefits? Or perhaps even leave funds there interminably?

[oskarth]

What are you calling a hot wallet here? so far in this discussion when we talk about hot wallet we are talking about the wallet address that can be derived from the public key of the chat account, the same wallet you had in pre-v1, whose private key is loaded in memory.

Either that or just any arbitrary hot wallet supported by multiaccount key structure. Ideally these can be rotated/compartmentalized to make funds fungible in a certain context (e.g. kudos hot wallet vs other wallets), but that's a later iteration.

How does what work? "the recipient can share the proof and you can' deny it" means the recipient can reveal to someone else that you own a particular wallet because you gave him the proof, and you can't deny it because you signed the proof.

I'm not convinced by this threat model, given that (a) It is with a trusted contact (b) you can choose to send it with your profile or not (share hot key) (c) you can swap this hot wallet key out (d) you can choose to sign the wallet key or not and finally (e) if you are going to transact with a person anyway, that also ties that person to that key.

The information should be conveyed to the user that this is shared with the contact, it could be a label in the account screen.

Agree, and it should be optional.

@oskarth you don't have a problem with the privacy/security of a hot wallet for chat contacts? e.g. that users will probably transfer funds from that wallet into one other, blowing the privacy benefits? Or perhaps even leave funds there interminably?

That will always be the case whenever you link two address together. It doesn't matter if you share hot key via profile or if you only do it on request, once way or another you leak that information. You can have a dialogue when adding someone as contact ("also share hot wallet key with this person")?

As stated above, the only way to get around linking of two addresses is to use ZK like technology. E.g. AZTEC is something we can reasonably implement soon ish if it is a priority. Another UI metaphor that Wasabi wallet (Coinjoin+Tor) for Bitcoin uses is to mark "private" coins from spoiled coins (though it is an UXTO based model so somewhat difference). E.g.

[yenda]

I like the idea of marking the coins, in the account model wouldn't it be every easier as you'd mark addresses from anonymous to spoiled?

…

On Wed, Oct 30, 2019, 07:15 Oskar Thorén ***@***.***> wrote: What are you calling a hot wallet here? so far in this discussion when we talk about hot wallet we are talking about the wallet address that can be derived from the public key of the chat account, the same wallet you had in pre-v1, whose private key is loaded in memory. Either that or just any arbitrary hot wallet supported by multiaccount key structure. Ideally these can be rotated. How does what work? "the recipient can share the proof and you can' deny it" means the recipient can reveal to someone else that you own a particular wallet because you gave him the proof, and you can't deny it because you signed the proof. I'm not convinced by this threat model, given that (a) It is with a trusted contact (b) you can choose to send it with your profile or not (share hot key) (c) you can swap this hot wallet key out (d) you can choose to sign the wallet key or not and finally (e) if you are going to transact with a person anyway, that also ties that person to that key. The information should be conveyed to the user that this is shared with the contact, it could be a label in the account screen. Agree, and it should be optional. @oskarth <https://github.com/oskarth> you don't have a problem with the privacy/security of a hot wallet for chat contacts? e.g. that users will probably transfer funds from that wallet into one other, blowing the privacy benefits? Or perhaps even leave funds there interminably? That will always be the case whenever you link two address together. It doesn't matter if you share hot key via profile or if you only do it on request, once way or another you leak that information. You can have a dialogue when adding someone as contact ("also share hot wallet key with this person")? As stated above, the only way to get around linking of two addresses is to use ZK like technology. E.g. AZTEC is something we can reasonably implement soon ish if it is a priority. Another UI metaphor that Wasabi wallet (Coinjoin+Tor) for Bitcoin uses is to mark "private" coins from spoiled coins (though it is an UXTO based model so somewhat difference). E.g. [image: image] <https://user-images.githubusercontent.com/1552237/67833465-ac9c6780-fb1f-11e9-96b6-b007ed9dc36a.png> [image: image] <https://user-images.githubusercontent.com/1552237/67833468-af975800-fb1f-11e9-9e9b-ae0b49c8dbb6.png> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9108>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJAMKKRWG7ZD6P7X726SKLQREQ7LANCNFSM4I5SIBLQ> .

[errorists]

I don't like this contacts approach that much If I'm honest, it adds another layer of complexity for users to keep track of, with which contacts you shared what, also further muddling the meaning of a contact.
What if I don't want to be contacts with someone but plan on transacting in chat? Once you add someone as a contact, how can you share or change your address, should you remove them from contacts and add again? Multiple times for each contact? What about users who want the benefits of private, secure messaging but don't care about crypto, managing contacts will come with a cypher they can't understand.
How would that work with features like SNT reactions, would receiving those be limited to contacts with whom you shared your address?

I believe the far better choice here is to have swappable hot wallets and work on snarks / mixers - you guys know better - that would give anonymity to linked accounts.
In the meantime, if that's too much scope for v1, do requests.

[oskarth]

It doesn't have to be tightly coupled with contacts, just as a standard user expectation (If I know you I can give money to you).

What if I don't want to be contacts with someone but plan on transacting in chat?

You can still share wallet with them, either with request or specific share-wallet command.

Once you add someone as a contact, how can you share or change your address, should you remove them from contacts and add again? Multiple times for each contact?

You do an update action, it can happen automatically. Just like with profile pics.

What about users who want the benefits of private, secure messaging but don't care about crypto, managing contacts will come with a cypher they can't understand.

The can be given a popup "allow contact to send money to my " where they can select no.

How would that work with features like SNT reactions, would receiving those be limited to contacts with whom you shared your address?

No, either request or specific share wallet without necesarilly adding as a contact

[rachelhamlin]

It doesn't have to be tightly coupled with contacts, just as a standard user expectation (If I know you I can give money to you).

What if I don't want to be contacts with someone but plan on transacting in chat?

You can still share wallet with them, either with request or specific share-wallet command.

Once you add someone as a contact, how can you share or change your address, should you remove them from contacts and add again? Multiple times for each contact?

You do an update action, it can happen automatically. Just like with profile pics.

What about users who want the benefits of private, secure messaging but don't care about crypto, managing contacts will come with a cypher they can't understand.

The can be given a popup "allow contact to send money to my " where they can select no.

How would that work with features like SNT reactions, would receiving those be limited to contacts with whom you shared your address?

No, either request or specific share wallet without necesarilly adding as a contact

So I'm not convinced this idea is simpler than the request flow.

• Users need to have proper expectations set around what it means to add a contact. The send/request flows make the exposure explicit.
• It may include an additional step in the contact flow anyway (e.g. "Share hot wallet with this person?") - how is it better to do this out of context? It makes more sense to share my wallet with someone when I actually want to transact.
• It's also less intuitive to discover. We couldn't enable /send or /request in chat for two users who aren't contacts. How will they figure out what they need to do?
• The hot wallet is less private/secure than a contextual share. I can select a different wallet to share with each person, if I wish. Hot wallet is global.

Now if we get into the idea of making the pubic wallet a setting, with options to change or stop sharing your wallet with various people..? That makes it a much better feature, but not a leaner MVP.

[andremedeiros]

We've written up an RFC here.

[oskarth]

Thanks! Right now this issue is quite muddled and I think we have strayed off the initial problem description quite a lot. The linked RFC body text has a lot more clarity on the actual problem, trade-offs and proposed solution. I suggest we close this issue and re-open with somethig more targeted towards the proposal (assuming there's consensus on it).