minus the 3 temp addrs, basically you are saying we keep the current flow (rotating addrs) with an additional button to set expiration time. what do you think about just fixing the expiration time to a high value (e.g., 72 hours)? require setting an additional value is just more confusing Iâm afraid.
Yes also a fixed longer expiration time it could work⌠I was thinking about these situations (for example):
- I ask money to a friend and create a new shielding address. I donât know when my friend will send the money, maybe today, maybe tomorrow, maybe in a couple of days. So I set a longer expiration time for that address (even paying a fee if necessary)
- I have to send to my wallet a big amount of money and I want maximum privacy, I want to do it quickly so I use a shielding address with default expiration time
I think adding a setting is not confusing if you add it in the correct way. For example, with a wallet you donât need to know about gas fee amount, usually the wallet use a normal fee amount (or you can choose between slow, normal fastâŚ), but there is always a way to click âadvancedâ and set your own gas fee. This is just an example. The meaning is: keep it simple but give the possibility to more advanced users to select more advanced/interesting options. You can for example set expiration to low (2h), normal (12h), high (72h) and also add an advanced panel (metamask styleâŚ)
Personally I like the rotating address structure (with an addresses pool) because if the addresses are used by a big amount of different people, the system is acting like a mixer, and itâs more difficult to associate a ânameâ to a particular TX. Like I wrote before, even if you use one-time addresses, if you use the same source address you still can determine how much money is going into incognito system.
sounds like a good idea. but this feature is separated and it can be implemented outside the scope of this discussion
and about the 3 addrs, in your scheme I think we only need 2: one rotating (otherwise thereâd be too many temp addrs) and one fixed (for tipping)
Itâs not really separated. You will use the same system. Simply set âno expirationâ for that address. The 3 addresses itâs only a number⌠You potentially can have more expiring addresses. I will try to explain⌠If I initiate a shield operation, a new temp address will be created, with default expiration time and one-time use (it expires when funds are received OR when exp time is reached). If you create N shielding requests, N shielding temp addresses will be generated. But if I change the expiration time or something (customization) I could generate N addresses with longer expiration time (or even infinite) or reserve the addresses: this will reduce the number of address available in the addresses pool and some users could generate infinite no-expire addresses just for fun⌠So you limit the seats when you use the customized addresses and the â3â I used in the example was the allowed number of personalized shielding addressesâŚ
I used 3 because maybe I need more than 1 temp address with longer expiration (eg. 2 friends need to send me money, they have a week to do so, I give a different address to eachâŚ). it could be also 5 for example⌠In this way you could, in case, also pay for the seats⌠Do you want another custom-expiration address, or a reserved one? Pay for the seat to keep it in use.
can you elaborate why and when a temp address must be âreservedâ? what if someone indefinitely reserving an address? the pool of temp addrs will run out pretty quick
I think âreservationâ is redundant probably. You are right. I was talking about reservation because the flow 2 proposed in the first post was talking about âa fixed address with manual retryâ. Letâs remove the feature.
So:
- You can shield with default settings, like how you do currently
- You can shield creating a custom-expiration address, but you have limited seats for these addresses (eg. 3, 5, NâŚ), with the possibility to pay for the seat (and use time, in case).
- The custom-expiration address can be set to âno-epireâ (used eg. for tipping) and can be configured to expire automatically after the first TX or not (use for multiple incoming TX)
- You can always expire the address manually
There can be also other options/variants, like those described in the @Revolve message. For example adding a âspeedâ option to the seat. And paying for the use (especially for long expiration times)
Reading @elvis.p message, also this is an interesting idea for advanced users. For example you can remove the âno-expirationâ option of my proposal, but add the create/import/delete wallet option for this purpose. However, this should be available to every bridged blockchain⌠I think the rotating address with customized expiration time is still better.
I have also an idea for paying the fees. Maybe too complicated, I donât know. Now Iâm thinking aloudâŚ
For paying the fees (interaction with incognito smart contract), for example, you could pay/lock an amount of PRV used to cover the TX costs. After the expiration, the unused amount will be returned to the user. For example:
- Pay/Lock 5 PRV when creating the shielding address
- If TX is received, PRV are converted (for example) to ETH and used to cover operational costs (gas). Letâsay these costs are equivalent to 3PRV. Then 2 PRV will be sent back (minus incognito network internal fees)
- If no TX is received and address expires, 5PRV will be sent back.
For multi TX addresses there could be problems because you donât know how many TX you can receive. In this case I see 2 options:
- Using a personal fees pool associated to the user. You deposit PRV there to cover for operational costs when shielding. If you run out of money the shielding process will be paused (new incoming TXs put in queue but not processed) until you recharge your pool. Also expiration will be paused if there are pending operations. When you recharge, the paused address will be processed sending all the remaining TX (and grouping them). The fees pool could be used also for unshielding and other incognito features, for example.
- You send the coins to the incognito smart contract only every N hours (T.B.D) and ask the user to pay for at least expiration_time_hours/N TXs returning the unused amount
The amount to ask must be also associated to the selected âspeedâ for the TXâŚ
I think the fees pool feature could be interesting, since if you are shielding/unshielding a lot, or maybe you are using pKyber/pUniswap a lot, you need only to keep topped up you fees pool.
The personal pool system could be like the Provide feature. You provide PRV for paying fees not associated to incognito network itself.
What do you think?
Maybe you can ask the user to send some ETH/BTC/Something supported with a âspecial shieldingâ operation used only to generate some PRV used for covering fees, when the PRV balance of the account is not sufficient to cover shielding/unshielding costs. So the user will send the minimum required amount that will be converted directly to PRV, enabling the user to do all the operations. If the balance is no sufficient you lock the shield/unshield buttons, enabling only this âspecial shieldingâ (e.g. âtop-up fees pool with shieldingâ).
It could be a barrier, because you need to send some coins to generate PRV used for fees before starting to use the account. But the alternative is to introduce more advanced (less user friendly) options or to give some shielding operations for free (this is dangerous, you could create infinite accounts just to have free shielding).
End of my aloud thinkingâŚ
âŚand therefore alot of reading for the rest of usâŚbut hey it was good that you posted so many thoughts and that can be said for all who have posted their ideasâŚthank youâŚmy thoughts is I wanna go strangle ETH and itâs stranglehold it has on so much at the moment especially with gas pricesâŚlolâŚentire crypto verse is getting raked over the coals at the gas prices being chargedâŚugghh