"insert 25cents to play" account rather than in-your-face signature at each move

[dckc]

As in earlier work: support a nearly throw-away account (key kept in localStorage) where the user puts some small-ish amount of rev (say 0.25 REV) once to cover many deploys. Like putting 25 cents into a videogame to play for a few minutes.

Right now, the rgov UI acts like you have to do a full credit card transaction every time you want your videogame character to take some small action.

[dckc]

in another app: rchain-community/RChain-Status@d6ecd92

[jimscarver]

There are discussion in governance on handling pre-paid data.
from log
Rchip needed for prepaid transaction fees; like near.org
https://docs.near.org/docs/concepts/gas#what-about-prepaid-gas
https://epicenter.tv/episodes/390
https://www.publish0x.com/my-own/near-protocol-an-answer-to-high-gas-fees-xjmvgwy

I think this is out of scope for rgov and this issue can be closed.

[dckc]

I disagree that it's out of scope. I think having to go through the whole digital signature dance for every interaction is onerous and distracts heavily from the experience; makes it borderline unacceptable.

I know for a fact that adding this feature is feasible; as noted above, I've done it before. If made a PR for this feature, would you decline to accept it on the basis that it's out of scope?

[Bill-Kunj]

This may be out of scope for the development interface (although I hate having to sign every move I make).
For the overall rgov interface, this seems relevant.

What I don't know is whether our not it's part of our October deliverable.

[dckc]

I don't see it as critical for October.

[jimscarver]

This seems out of scope for rgov as I believe prepaid contracts should be a layer one capability.

The "Internet Computer one" jumper to 35B evaluation https://dfinity.org
All transactions are prepaid, the user never pays. That could catch on.
@TheoXD has been campaigning for prepaid contracts. Perhaps that could be a layer under DAASL.

I think we need an rchip

[TheoXD]

@jimscarver Near.org also has it https://docs.near.org/docs/concepts/gas#what-about-prepaid-gas

[Bill-Kunj]

This seems out of scope for rgov as I believe prepaid contracts should be a layer one capability.

RGOV certainly is about something besides prepaid contracts, so in that sense it is out of scope. However, someone has to do it eventually. Why not us and make RGOV an example with a usable interface?

[dckc]

@TheoXD writes:

@jimscarver Near.org also has it https://docs.near.org/docs/concepts/gas#what-about-prepaid-gas

No, that's about the developer paying the users' gas. I'm not talking about that.

I'm just talking about a nearly throw-away account (key kept in localStorage) where the user puts some small-ish amount of rev (say 0.25 REV) once to cover many deploys. Like putting 25 cents into a videogame to play for a few minutes. Right now, the rgov UI acts like you have to do a full credit card transaction every time you want your videogame character to take some small action.

[jimscarver]

throw-away account (key kept in localStorage) where the user puts some small-ish amount of rev (say 0.25 REV) once to cover many deploys

Ok, that is useful and not necessarily related to prepaid deploys. My only concern is wasting much of the rev, taking it out of circulation. A prepaid amount might persist for an account and not require a separate user authentication on top of a signed deploy.

[w2vy]

I was reviewing the Power Box features and it mentions a MultiSigRevVault

It sounds like you can authorize transfers with either the Private Key or a deployerAuthKey

https://github.com/rchain/rchain/blob/dev/casper/src/main/resources/MultiSigRevVault.rho

If that deployerAuthKey can be changed (not sure what seal and unseal are) then I could have a (few) MultiSigRevVaults that I give third parties access to and they could collect gas (or other) fees from me as the needed. This makes the RevVault reusable so no worry of leaving lost of dust behind in discarded RevVaults

If the application is an ongoing relationship they could deduct funds monthly, if short termed then more often

It would be nice when creating the deployerAuthKey if a withdrawal limit could be set, needing a new authorization to get more

[dckc]

Please move discussion of fees paid by someone other to the user to a separate issue.

[TheoXD]

Please move discussion of fees paid by someone other to the user to a separate issue.

I think those two ideas are still related. If you insert 25c of your own money into a slot machine on rchain, let's assume it goes into a purse that gets drained by the network to cover for tx costs + possibly profits to the developer. If developer decides to give people who happened to walk by a free try, developer shouldn't have to send them 25c worth of REV so that they can put it right back into a machine, so why not let developer put it directly into the slot machine in the first place?

[dckc]

Because it looks like a research project, to me. I have no idea how to do it.

[dckc]

It doesn't get drained by the network. It gets drained in the normal way, by signing deploys with phlo price and phlo limit set. The main difference from the full in-your-face metamask signing experience is that the page ui can do it for you because it know the private key with which to sign deploys.

This is risky... Anyone who has access to your browser might discover the key and take the funds. But it's a small, bounded risk.

It would be like putting a quarter into a Galaga machine, taking a break, and returning to find that someone else had used up your remaining ships. Oh well. No big deal. Put in another quarter if you want to play some more.

[dckc]

The page ui generates a random key and hence rev address and displays an "insert 0.25 REV to avoid annoying dialogs" button. You press the button and transfer 0.25 REV to this generated account using metamask as usual.

Then the page can make several deploys without nagging you.

The key is kept in localStorage, so if you navigate away and come back (using the same browser) you can continue to have deploys paid from the generated account.

[w2vy]

I think that is a good short-term solution. Later we can push for a better way, it may take a new transfer type in rchain Tom

…

On May 28, 2021 2:10:10 AM EDT, Dan Connolly ***@***.***> wrote: The page ui generates a random key and hence rev address and displays an "insert 0.25 REV to avoid annoying dialogs" button. You press the button and transfer 0.25 REV to this generated account using metamask as usual. Then the page can make several deploys without nagging you. The key is kept in localStorage, so if you navigate away and come back (using the same browser) you can continue to have deploys paid from the generated account. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #85 (comment)

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Bill-Kunj]

It doesn't get drained by the network. It gets drained in the normal way, by signing deploys with phlo price and phlo limit set. The main difference from the full in-your-face metamask signing experience is that the page ui can do it for you because it know the private key with which to sign deploys.

This is risky... Anyone who has access to your browser might discover the key and take the funds. But it's a small, bounded risk.

It would be like putting a quarter into a Galaga machine, taking a break, and returning to find that someone else had used up your remaining ships. Oh well. No big deal. Put in another quarter if you want to play some more.

@dckc Ugh. I would never play Galaga. But, Defender.... :)

[Bill-Kunj]

For a longer term solution, don't we need to address the loss of prepaid coin when a browser is closed?

[w2vy]

That may be best solved with changes in rchain like receiver pays gas or prepaid gas... Well beyond the scope of what an application can do

…

On May 30, 2021 10:46:40 AM EDT, Bill-Keuntje ***@***.***> wrote: For a longer term solution, don't we need to address the loss of prepaid coin when a browser is closed? -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #85 (comment)

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[dckc]

For a longer term solution, don't we need to address the loss of prepaid coin when a browser is closed?

localStorage persists in that case.

[jimscarver]

localStorage persists in that case

yes, that answers sufficiently for me. I like it. prepaid doing it may be better but is a long way down the read.

[Bill-Kunj]

For a longer term solution, don't we need to address the loss of prepaid coin when a browser is closed?

localStorage persists in that case.

Agreed.Shall we covert this into a separate issue for implementation?

[dckc]

No, I don't see any reason for a separate issue. This issue is about the feature, which includes implementation, testing, documentation, and whatever else it takes to get it done, just like any other feature/enhancement issue.