Allow other accounts to pay your reserve about stellar-protocol

[jedmccaleb]

hmm I don't think #52 solves stronghold's issue. Since the min reserve varies as people create trustlines etc. So just not being able to merge isn't enough. stronghold would fund the account to create a bunch of offers and then the account could sell those lumens

[MonsieurNicolas]

Giving arbitrary control on the account seems like a different use case indeed. The reason I wrote up "issuer" earlier is that it's the only type of account where it's reasonable to imagine them having control over trust lines (they get to "verify" them right now) and offers (ie: with this proposal an issuer may decide to delete offers that they sponsored). If you are worried about some users running away with the sponsored XLMs, you should also be worried about some users abandoning their account (they don't care or they lost their keys) and you have no way to recover the reserve if you don't have the rights to do so.

In your particular scenario, I think a much cleaner approach would be to:

• have sponsored accounts be limited, in that the sponsor's signature is required to perform transactions. This is actually quite simple to implement, and only requires transactions to be submitted to your web site instead of being submitted to the network directly.
• if a user wants to remove this limitation, they can pay you back whatever amount you deem is fair (maybe it's the original XLM amount that was used to create the account + trust lines, maybe it's less - it's a business decision)

It allows a lot more flexibility on how and what is being sponsored. If we were supporting this at the protocol layer, we would have to increase the complexity wrt "who gets to mess with your stuff" (right now it's only the account's signers and the issuers), and we would have to make arbitrary decisions when certain things happen like, for example, when the base reserve is lowered that probably won't work for everybody (or keep track of actual amounts per {sponsor, account} pairs which is quite ugly).

[MonsieurNicolas]

If this is in the context of a centralized application, it sounds like all you need is a way to enforce a policy: do not generate or sign transactions that violate your policy, and that should probably be implemented client side (on your servers in this case). I can see this useful in general for a lot more than this use case: enforcing daily transfer limits on certain assets, blackouts, etc.

Specifically for this case, it's the same problem that wallets have (for a single account) if they want to enforce a limit on the total amount of a given asset up for sale: when creating an offer or an outgoing payment ensure that sum(offers for sale) + payment <= limit . For wallets, they may want to pop up a warning with limit = balance; in your XLM case, limit = current_balance - sponsored_amount (where sponsored_amount is probably just the amount that was used to create the account in the first place.

[bartekn]

Isn't is something like #52?

[orbitlens]

That's a really great idea! In case if parent account holds base reserve + reserve for all trustlines and open orders, services may create child accounts without any restrictions. In conjunction with assets it makes modelling real-world scenarios much easier. The same concept works well for banks and other financial institutions – they create an account on customer's behalf and provide operations liquidity.

At present time any Stellar-based service design implies that the company behind it "sponsors" all child accounts. In most cases it's at least 30 XLM (20 for base reserve + 10 XLM for trustline/order), and say 1 XLM for transactions.

Consider the case where parent account holds required reserve and pays all transactions fees on behalf of the child account. The parent account can specify (and update) transactions limit and allowed operations for a child account. Just imagine how it can simplify things for developers. It makes possible implementing services fully transparent for end users, because dependent accounts operate in the controlled environment.

Many blockchains offer on-chain assets feature, but all of them require child account funding, which makes things too complicated for regular users. It's one of the main problems that prevent prevents mass blockchain systems adoption.

Such feature by itself would attract a lot of developers that are trying to implement their systems on Ethereum, NEM, Lisk etc.

Of course, it's a complex concept. There are a lot of things to consider. For example, the possibility to "freeze" (or delete) an unused dependent account in order to reclaim reserved XLMs on the parent account. Otherwise, some services may experience problems with too large frozen reserves. But it definitely worth the hassle.

Bring this concept to the public discussion with services that already operate on Stellar. I'm sure that most of them will support the idea.

[tammycamp]

Hey Stellar Dev team,

Happy New Year!

Just checking in on this. We would really like to move to native XLM to streamline everything. I know things are busy on your end, but do we have a timeline for this?

Folks are asking about it in /r/Stellar - https://www.reddit.com/r/Stellar/comments/7o9mhs/why_has_stronghold_issued_their_own_asset_called/

Looking forward to it.

[MonsieurNicolas]

Hey @tammycamp , we've been discussing some ways to solve this, we do not have a good solution yet.

Some more thinking is needed: some of the proposals we got so far allow for issuers to spam arbitrary users on the network, and as you can imagine spam is not something we want to carry over from the email analogy :)

One of the front runners that may work is to allow for issuers to have a property N (integer) that allows the issuer to cover/sponsor for the first N ledger entries related to that issuer for any account (trustlines or offers).

What I do not like about this (that maybe people in the community here can help with):

1. the issuer cannot reduce N and may not be able to recover its reserve (how to deal with a dead account that has such "sponsored" trust lines) - the solution to that may involve some way to mark explicitly the ledger entries covered by the issuer (with a flag?), such ledger entries can be deleted by the issuer which gives the issuer additional control (which can be a problem in itself). This may not be enough as the issuer would have to drop all sponsored accounts in order to drop N. We can also make N the "desired" number (only enforced when creating new entries) to solve that last part of the problem.
2. it doesn't work for non authorized accounts (if we were allowing it, it would allow an arbitrary set of people to lock an arbitrary amount of XLMs from the issuer)
3. if both assets in an offer have an issuer that can cover the reserve, which one covers it? (I imagine that we do not want to discriminate between buyers and sellers)

(1) is the big one - if we're willing to give additional power to the issuer to solve this problem, the solution may actually look completely different.

[itsseanbennett]

@MonsieurNicolas thanks for the response!

Can you please elaborate on what you mean when you say "some of the proposals we got so far allow for issuers to spam arbitrary users on the network"?

While I like the idea of issuers paying for their user's trustlines, that's not the use case I'm hoping gets solved: instead, our problem as a service creating and managing accounts for our users is for all their XLM reserve requirements regardless of the issuer. Actually providing the XLM to the user currently is fine, and stopping them from sending it out can be done at the application layer, but it is impossible to interact with XLM for trading safely as XLM intended for reserve requirements may get sold in a trade.

What I would like as a managed service provider is to send my user Y XLM that could be used only for the purposes of satisfying reserve requirements i.e. those XLM would not be sold off in a trade or available for payments - almost as if the XLM was a different asset on my wallet => 'reserve pool'. Any XLM in my reserve pool would be associated with the funding account that send to them the account and the funder could remove them at any time (provided they are not actively held as reserve) - performing a merge would return the reserve pool to the funder also. Multiple reserve funders may be valid.

I don't feel that an account need authorize another to fund their reserves but that may be something that needs considering.

[itsseanbennett]

We don't even give the users access to their secret keys and all their actions are performed through their intent being passed to our application.

The problem is the dynamic reserve requirement when users place/cross/cancel trade offers for trades involving XLM.native. Unless we 'locked' funds in active trades there is no way for us to ensure that XLM provided to a user for trade reserves could not be sold in a trade (or at least, I don't know how to stop this). Our problem is mixing of funds considered the 'customers' and funds which we want to consider as on loan for reserve purposes only.

[bartekn]

Solved by CAP-33?

[MonsieurNicolas]

yes. Thanks @bartekn