what is the difference between a permanent and reusable address? Here I mean as an example of when a reusable address would be used
if you can only have 2 addresses active (permanent + extra), does that mean you have 2 tor listeners? If yes then I see a problem with using one-time addresses since if you’re not doing it synchronously (eg. manual confirmations) then when you will be doing multiple transactions your tor address will expire before the user manually confirms. So maybe having the same tor address for one-time addresses is preferable (eg. you include some nonce in this new one-time grin address and the wallet drops requests whose nonce was already used in the past)?
If someone opposes your vision, that doesn’t mean he’s the villain. I just see things differently than you (and many others), no need to overreact. It’s important that people say what they think, what their vision is etc since that opens up new research branches which can then be explored
Yeah I concur on the portion regarding open voicing of opinions, unfortunately history proves that that is not reciprocated especially when it comes to inclusion in protocol.
I’m not overreacting, sorry if you feel that way though. The key as I have expressed is optionality. If you would like a different path then please produce one, (for the wallet of your choice) and I hope it can be received and discussed better than most of the NITX baselayer protocols that have been presented.
On a personality level, I would also advise if you are interested in producing a more copacetic and mutually respectful dialogue then it starts with yourself.
In addition, it seems that you just like to play obstructionist; if you are so interested then why have you not committed to an RFC? Only when David T has presented an optional path forward for non-interactive transactions, is there then this reflexive response.
It would also serve you well to be more inquisitive and less adversarial overall. I find it mind-blowing that you cannot grasp the struggles with interactive transactions, or at least don’t care to
My view is that majority of people (you included) don’t understand how proper GUI for itx looks like (to me it seems like you guys think you need to deal with slatepacks, which is partially true - the same way that it’s true for your beloved nitx), so it’s normal that they dislike it. Let’s not derail this useful conversation with such useless stuff, we can talk about that on keybase if you wish
RFC requires a more detailed solution and it’s preferable if things are debated first (pros/cons etc)
Again, without even an attempt to actually understand the grievances of so many (the majority) of users. This is the core of the problem; and then, during “community council” application, you try to exclude others from the process and take glee in being the villain. You really can’t have it both ways.
I wish you well, I really do, but you have just proven my point.
Since extra addresses can be an optional feature, users can opt-in and opt-out at any moment. I said above: Permanent or Default; it is permanent because this address does not change at least you manually pick another address to be your permanent one. Default, because this address is the one that it will be listening whether you have the feature enabled or not. Since you can disable the feature, the last permanent address will be your default address.
What is the difference between one-time address and reusable then?
Disposable means that I can not use that address after completing the receiving process because it is a one-time use address. Reusable means that I can use this address at any moment. For example, If I am mining in two different pools, I can create two address, one for one pool and one for another pool.
Let’s say I don’t want to share my default address and I’m not mining, in this case I can create disposable addresses for each transaction. Or maybe I’m currently receiving payments on my default address (m/0/0/0) but I want to start using disposable addresses, I just need to enable the feature and that’s all.
Also, I could change my default address without using extra addresses.
I asked explicitly about the flow of a manual confirmation just to make sure I’m not missing any step. For a manual confirmation, the transaction is not “received” until you accept it. In this case, a disposable address won’t expire until you accept the transaction.
Now… if you want to go only with a manual confirmation flow, maybe you will need to be able of having multiple extra addresses listening at the same time in order to receive multiple transaction using different address which are not your default one. In other words: you may want to enable different addresses at the same time besides the default one.
Then fix our GUI or stop insulting those of us that have tried. All you seem to want to do is waste our time talking about your precious manual ITX without any meaningful suggestions for improvement. GTFO
I even remember @davidtavarez trying to reinvent the encrypted wallet.seed file several months ago… So I think that @vegycslol is doing a good job vocalizing these possible issues as soon as possible.
I lack knowledge to fix gui (would need to invest a lot of time to be able to do anything on that front and i currently don’t have it), so i can only debate about different possibilities. He insulted me for giving an idea of how things could work without understanding it. In that case yes, sometimes i insult back (i know it’s not smart, but that’s how i react sometimes). Where did i insult you? When i say that gui could be improved or that it hasn’t been yet explored enough, that’s not an insult (sorry if you think it is, it’s not meant as one). I just believe we could further explore these things and tavares is doing an excellent job here. To me you’re the only one complaining about manual confirmations who actually made an effort and thought about it (i don’t count tavares here because I’m not sure if he’s against it). Same as me, your behavior is not exemplary when it comes to insults
I don’t want to waste anyone’s time, so you can stop repeating this nonsense. Whether a suggestion is meaningful or not is subjective in this case (and most other cases, some pros and cons)
Yeah i think i mostly get it now, i thought you can’t change the permanent address. The things i still don’t understand are:
how would multiple disposable addresses work through tor
Can you have no default address - example: i might use one-time addresses for regular txs, but i also mine so i use some permanent default one. Then i decide to stop mining and would not want to listen on the permanent default one. The solution in this case is to just change the permanent address right?
Thanks for the pictures, they really make things easier to understand to me!
Visuals always make the discussion much better. I like how this would look to a user .
One suggestion though, maybe make all one time use addresses fixed to a certain derivation path, e.g.
bet1 Address m/0/0/1/1 | bet | disposable
bet2 Address m/0/0/1/2 | bet | disposable
grinmint Address m/0/0/2 | permanent
Not sure if this makes sense, but it would be nice to make sure that all disposable addresses are in one branch of the derivation by going one extra leveland as such can never get mixed with permanent addresses.
Just another brain-fart. Maybe it would be possible to store the information about used one time use on chain by sending to the main address via small transactions containing this information, e.g. like a dust transaction with the label converted to digits. e.g. t1 for temp transaction 1 would be 0.0000116 49 Grin in digits. Of course someone could mess with this by sending you on purpose transactions marking your temporary addresses in the main wallet.
I said it once, and I’ll say it again: I don’t like, no… I hate to be introducing word by word my Mnemonic Seed in a proper order to restore my wallet; specially at 2, 4, 5 am while I’m coding a GUI (Desktop/Mobile) to make things easier for users. I’m sorry if this bothers you, but after hours and hours testing over and over again, I realized that I hate that process and I found that it is so much easier if I could just “import” a file to restore my wallet. I’m not afraid of saying it
Multiple disposable addresses listening/enabled you mean? The basic process is very simple. We can add multiple tor listeners for the same foreign server (RPC API). From an encrypted slatepack we can get the SlatepackAddressof the recipients, and since the wallet is managing the addresses list locally we can then remove the listener and update the local database to set some kind of flag to avoid using that address again. Sure, this is a raw idea, I would need to put this in practice, if someone has a better idea, please let me know.
Yes, the solution in this case is just generate a new permanent address. I don’t think we should change the current behavior, therefore I think we should avoid impacting it. Removing the default listener could confuse the user imo. Even if we can it doesn’t mean that we must.
Now, what would it happen with the addresses list if I restore my wallet somewhere else? Well, the process starts over again; we could just determine the last address used and I don’t find a practical use to exporting and importing the addresses.
Did you understand my idea for using only 1 tor listener for all one-time addresses (the other topic where i mention a random number in an address)? I’m not sure if that’s viable or not (or even smart), it’s just an idea
Yes and yes
Maybe one such case would be if people have multiple wallets and want to use the same permanent address
Just as a more polished version of this brain-fairt idea above of doing on-chain bookkeeping. Just like you can put all one-time use addresses in a seperate branch for derivation, you could have another ‘special’ branch where you do book keeping. E.g.
The idea of the special bookkeep address is that the user can click a button, to make an on-chain backup.
Once the user presses the button, all one time use addresses that were used and possibly even permanent addresses that were used are send to the special bookkeeping adress as dust transactions containing the information of each derivation path used. In case of one time use addresses this means these addresses are burned, e.g. m/0/0/1/1 and m/0/0/1/2 should not be used again. In the case of permanent addresses, this would store the information only readable to the user that these permanent addresses were used, but the description would be lost. This should be done very minimally, e.g. only the last two digits of the address are send to the bookkeeping address.
E.g. m/0/0/1/1 = “11” = dust transaction 0.000000011 (not sure how many digits after the comma Grin uses, I assumed 9).
By no means to I say the above idea is worth the costs, but it is just an interesting idea to allow users occasionally backup information online in case of losing the wallet file, since the mnemonic seed will regenerate the bookkeeping address and find all associated bookkeeping outputs. The address is only meant for bookkeeping from the main address, outputs should never be spend in order to retain the data. Since only a few transactions are involved, the costs of this on-chain bookkeeping are minimal. Alternatively, information could be stored as a range, e.g. temporary address 1 to 100 would be t100 = 0.116 49 48 48 Grin to be send to the Bookkeeping address. Since the timing of these backups is not associated to the time the addresses are used, and since they only link to the main address, no privacy should be lost to the user, just a dust amount of Grin to facilitate the bookkeeping.grinning:
For future research, using multiple transactions using the last digit to indicate the following transaction should be read for full information could be used to further “compress” how information is stored in the dust part of transactions. It could even be used for any other arbitrary type of information to be stored on chain, e.g. a text message. This however serves less function since such a message could also be included in the transaction information, I think there even is or used to be a field for this in the transaction protocol. The only added benefit is that the information could be stored permanently similar to how OP_RETURN is used to store information encrypted on chain. In the case of Grin the information is however much stronger protected since it is indistinguishable from normal transaction since it is a normal transaction with the only difference that the value is used to encode information.
I’m withdrawing this request for now, the request was not approved as it is in today’s Governance meeting. I would like to take some time to reflect, adjust the proposal and reopen it later.
I want to clarify some things to avoid any kind of misunderstanding. First, let me create a common ground:
It doesn’t makes sense to have a RFC without an implementation.
There are two implementations of Grin, one written in Rust (grin-wallet) and another one written in C++ (Grin++).
Grin++ can be considered as much as official as grin-wallet.
I can understand that it could be a bit risky for the Core to fund this request as it is, because there was not a commitment from me to write this feature in grin-wallet. Right now, I can’t properly estimate the effort of writing this feature for grin-wallet and it is not ethical for me to make a commitment without even be able of giving a potential deadline while I’m receiving funds.
I thought that with a RFC and the Grin++ implementation anyone else could write the Rust code. Am I capable of writing the Rust code for this feature? Well, yes, but first, with a RFC available, second, having implemented the RFC in Grin++, and, third, investing an undefined amount of time.
Because of this undefined amount of time in one hand, and, in the other hand, a bunch of stuff to do for the Grin++ UI, and for Grin Android, I need to rethink this funding request as it was written. Also, my initial idea changed after collecting feedback from different people.
I need to reconsider the scope of the request, but more important, I would like to evaluate the priority of me working on this feature for grin-wallet instead of delivering more value for the Grin++ users. Does this mean that I will never work on the implementation for grin-wallet? No, in fact I’m more than open to do it, so when then? I don’t know right now. Will I open another Funding Request related to this? I don’t know.
If you need help or feedback to further polish this as a RFC or something similar to BIP, lets call it GIP (Grin Improvement Proposal) now or in the future, let me know.
Any updates on this? One-time use addresses would be a great feature to have (even if it’s just in grin++) and imo a privacy focused coin just isn’t complete without it. It would be a real shame if this doesn’t get implemented.
If we check grinnode.live stats, we could see user agent from Grin++ dominated. I recommend the app should be funded to develop more, we now use mobile app for everything.
.
I could make things more clear. I will take this into consideration. Thanks! 