[Withdrewed] Request for Funding @davidtavarez: One-time use Slatepack addresses for Wallet (RFC and Grin++ Implementation)

vegycslol · April 27, 2021, 12:10pm

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!

Anynomous · April 27, 2021, 1:26pm

Visuals always make the discussion much better. I like how this would look to a user .

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.

davidtavarez · April 27, 2021, 1:28pm

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 SlatepackAddress of 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.

davidtavarez · April 27, 2021, 1:36pm

This isn’t a bad idea at all actually I could make things more clear. I will take this into consideration. Thanks!

vegycslol · April 27, 2021, 1:53pm

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

Anynomous · April 27, 2021, 2:15pm

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.

davidtavarez · April 27, 2021, 6:39pm

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.

Anynomous · April 27, 2021, 7:50pm

Mmm ok, pity. I should have been at that governance meeting. I will read the minutes.

davidtavarez · April 27, 2021, 10:36pm

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.

Anynomous · April 28, 2021, 8:41am

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.

FluxTape · May 12, 2021, 2:16pm

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.

Mactavish · June 10, 2021, 9:57am

TBO 10k worth was not a big deal for this feature also david is a good developer and did a lot for grin i dont like the way core manage founds

noobvie · June 10, 2021, 10:37am

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.

Grundkurs · June 10, 2021, 12:14pm

I have to agree. How the core council managed this request is disappointing.
Having a full node running on a phone without occupying all system resources and storage is awesome and let Grin genuinely shine in comparison to other projects. Instead of encourage this development it gets slowed down due to some odd requirements that the implementation must be in a specific language.

If it’s that important to u, just let David do its thing and let the implementation port by some enthusiast who think a Rust Version is crucial. If no one shows up willing to port it to rust, it may be a hint that nobody cares about the rust implementation, so why should it slow down the c+±version? I just don’t get it.

Oh wait, only the core council cares, of course, how could I forget. So it is the rust version or nothing.

Such mindset seems hurtful to the project in my opinion, especially against the background that the different implementations literally saved Grins Yellow Ass in the past (Inflation Bug in March)

oryhp · June 10, 2021, 1:42pm

There were 2 arguments which I recall from the meeting:

RFC owner should also implement Rust version - refuted by @tromp during the meeting and we mostly agreed this shouldn’t be the case.
Rust implementation should be the go to for RFCs and hence have them implemented, in other words, we really don’t want to have the Rust implementation not follow the RFCs.

I don’t think the RFC owner should implement it in all versions. But I also completely agree with 2 - having the rust implementation not follow RFCs would be even worse.

Tavarez withdrew the request and said he will think about it, which is why it is in stale mode right now. I do understand @davidtavarez about Rust implementation, he definitely shouldn’t feel the need to do it. In this case, we’d need to find another person to do the Rust side, which is what I hope happens. We don’t want to block things. Perhaps splitting things in 3 parts <RFC, Grin++, Rust> and funding each one separately would make sense.

vegycslol · June 10, 2021, 3:03pm

Like you’ve pointed out, not long ago we had a case where the second implementation saved grin, so having 2 implementations is extremely important, especially in projects where amounts are blinded. Therefore it would be horrible if they would not implement the same stuff and iirc tavarez understood the arguments for the need to implement the rust part too. Nobody is forcing him though, it’s very hard to predict the time it takes to do something in a language you’re not familiar with and i don’t think anyone would have anything against tavarez if he decides not to do it. People should stop blaming the core for everything, they’re among the people who’ve invested the most amount of time and effort to improve grin and we should all respect that

I’m not part of the core and i care about it

davidtavarez · June 10, 2021, 4:57pm

Thank you.

I agree with that.

Correct, I understood that argument and I agreed.

Yes. Since I’m not a Rust developer it was hard (and it is hard) for me to say how much time it will take me to implement this in Rust. I said it before, it was not ethical to make a commitment without having an estimation. I decided to rethink this funding request, while I fix some issues, specially with the Android app of Grin++, then retake the work on this.

Well, yes but I’m not completely sure. After starting to code a bit, also sharing my idea and having few conversations and comments here and there, my initial idea of how this should work changed. Now, by actually working on separated branches and letting some users (from the Community and the Core) to test this before even moving forward, we could find the best approach for this feature. And when I say test this I mean at least having some visual mockups with the user flow description, this will help us to have an agreement on how this should work, so I could write the RFC and from here anyone could write the implementation. With a RFC written I can work on the Rust implementation.

The little detail with this is that it means that someone is already investing time on this only to have the RFC written, in this case: myself. It isn’t clear how this is managed from a funding perspective.

And that’s a good question.

We should fight the Grin = Rust mentality and this has been my main critic. I think we are not taking full advantage of having 2 implementations right now.

I think the problem was (or is) that it is not clear how we should deal with contributors like me, for instance. Let me explain myself. I’m not contributing to the Rust repository yet, but I’ve proved myself contributing mainly with Grin++ and it is clear that I’m not going anywhere, with or without funding. I do this on my “free time” which means that I don’t need to get funded to pay my bills, but getting funded could be seen as a good investment in the long term. I’m sure there are many people in this situation.

Now, from a funding perspective: what should we do with cases like mine? Well, from an idealistic point of view and taking old comments directly from Core and Community members, get funded should be considered as a strong option, no doubt. From a pragmatic point of view, it is understandable to protect the Rust implementation.

I don’t blame the Core at all, on the contrary I appreciate the opportunity given to me to contribute on Grin so far; also, during the meeting when we discussed this Funding Request it was clear that they wanted to help.

True, we should stop the “core vs everybody” thing, it is not helping Grin. That idea is hurting the already shrinked community.

Would I like to get funded? of course yes.

Will I open another funding request? I don’t know.

I’m here because I like Grin, and I like the idea of what Grin can become in the future.

david · June 11, 2021, 3:30am

I disagree. The RFC process is to lay out standards for all implementations of Grin nodes, wallets, etc. Like BIPs, there should be no requirement that the rust version of Grin implement all RFCs. However, any implementation that does implement a feature for which an RFC exists, is expected to implement it in accordance with the specifications described in the RFC.

If RFCs must be implemented in rust, the rust version becomes a major bottleneck in supporting interoperability amongst the rest of the software in the grin ecosystem. For a concrete example, consider QR codes. I would love to see an RFC that defines the QR code format used by IronBelly & Grin++. But if an RFC is expected to be implemented by the rust code, then there can be no such RFC, and therefore no standardization, because the rust code doesn’t even have a GUI.

Anynomous · June 11, 2021, 7:59am

I miss one important point from the general assembly that is not mentioned here.
During general meeting it was also discussed that this this functionality and funding request would very much well fit with the objective of having a Community Council with funds to help grow the ecosystem.
As such the main idea was to delay the funding request till the community council was formed, polish the request and work towards a RFC and make a funding request to the Community Council budget. So there was no malice or negativity, the request was not even rejected, but withdrawn for these ‘strategic reasons’.
I for one would be very happy to work with @davidtavarez and others to polish the request so we can make it the first Community funded project, if the community agrees

noobvie · June 11, 2021, 8:49am

Good to know it was not rejected. From my viewpoint, currently we need more ecosystem to gain non-tech users in crypto community, and what davidtavarez did is really appreciated.