This is a request for a 3 months period from February to April 2022. During this period I would like to facilitate Payment proof for Grin++ users, simplify the process of enabling Tor bridges and retake the work left for One-time use slatepack addresses.
Rate: €5,000/month .
What do I want to achieve?
Bisq did reactivate the BTC/GRIN pair again, therefore I think that it is important to prioritize facilitating this via the user interface.
Now, Tor is officially blocked in Russia, and the request for support around this topic has increased recently. I want to find a way of simplifying this to Grin++ users, I have some ideas in my mind on how to do it that I would like to test.
In most cases we don’t want to reuse the same address in order to improve our privacy. I started to test this feature on Grin++ before and I would like to complete the work. I believe this is a fundamental feature and needs to be added as soon as possible.
Disclaimer
I want to keep being vocal with my thoughts, if this funding request will somehow be used to silence me, please, do not support this. Also, I’m part of the Community Council and of course, I will inhibit myself of voting that day.
Are we sure that one-time addresses are better than per-user addresses? I feel like having a userbook is important ux-wise, but if u have one-time address then you can’t really have that, unless i’m missing something. I’ve thought a little about the slatepack step1 spamming problem and the idea i’ve come up with was having address per user, not sure if it helps in any way but i’ll still leave my notes from that time here (NOTE: grin hello message = grin address, that’s just how i called it back then since it includes transport info):
important to solve (to prevent spam):
you can ban user A
you can remove user A’s open step 1 transactions (maybe even step 2/3?)
information of how to reach me (tor pubkey + version, signal, whatever else, maybe ordered, but probably the other party should be the one picking the transfer method)
signature done with pubkey A over all this data to prove that I (the owner of this pubkey A) generated all of the above data
Scenario 1: you have a single hello message (address) for everyone
Pros:
you don’t need to send your hello message to each person separately
Cons:
you can’t ban a single user, you would have to change your global hello message (they can spam you with slatepack step 1)
you can only delete all existing open transactions and not from a single user (this doesn’t help though since they can spam you nonstop)
Scenario 2: you have a different hello message for each user, each hello message contains userID (random nonce) which is generated for this specific user who receives your address
Pros:
you can ban a single user by banning their userID
you can delete/cancel single user’s open transactions (if they spam you)
Cons:
you have to send hello message to each user, either as your “address” for the other party to create slatepack step1 or, if you’re the one who received hello message and need to create slatepack step1,
you include your hello message in slatepack step1 that you send to the other party
I meant to replicate these commands through the GUIs of Grin++.
Or you can have an one to many relationship between user and addresses, and a list of blocked addresses, combine that with the ability of generating a new address on demand (+ manual confirmation and/or a minimum of amount to auto sign incoming transactions) and the risk of spam is mitigated. Simpler and cleaner, and a better because these features could be use in different kind of scenarios separately and for several reasons.
At first sight it seems to me like that’s more complicated since:
user needs to generate new address for each tx and link it to the user in the userbook (assuming there is a userbook), the simplest option here seems like right-click on the user in userbook and click generate new address
user needs to always share his new address with the other party before each transaction, so the flow kind of becomes 4 step
I am not sure if ‘one-time use adresses is the best term’. I think we need per account level adresses. So you can have a trusted address with auto confirm, and one that requires manual confimation. Would this also be possible as a 'hello address" @vegycslol ? As long as that information can be shared as part of thr address it is fine.
Would be best if both could be combined, e.g. multiple tor alliases if something like that exists. The main advantage of per account level addresses is that it automatically allows to organize outputs from trusted and less trusted parties. Everything is needly categorized on the account level.
I would say yes. If you are able to tell from which user the incoming slatepack is from then you should be able to specify wanted settings for this user (eg. manual confirmation, who pays for the fees by default, use payjoin with this user or not etc)
Then it might be even better than one-time use adresses since it does not require additional tor instances. Do you have a link to your idea/proposal?
As long as the wallet has a way to seperate incomming transactions, it is fine.
Is your idea like adding additional information in the slatepack, such as ‘trustedID123’, or something. As long as you can share that information like an address, or wrapped around it. It should be fine.
All i have is written above under “scenario 2”. It shouldn’t require an additional data in the slatepack to find out which user is sending it since you know which one of your addresses he used (the one you gave him). But again i haven’t thought that much about it, i suggest we take it to keybase if there are any other questions to not pollute this thread
Just a thought, but should some preliminary work on [PIBD (parallel initial block download) be added to the task list?
Not sure if it is something you can already work on, but it would be nice if Grin++ would support PIBD not to far after the release of PIBD for the grin rust node. Overall that should hugely boost initial syncing stability and speed and as such the user experience of running a full node should be better.
.