Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should an address be restricted from sending unlimited XLM to itself? #1642

Closed
JonLister opened this issue Apr 2, 2018 · 8 comments

Comments

@JonLister
Copy link

commented Apr 2, 2018

While testing our wallets yesterday we noticed that an address is able to 'send' itself more XLM than the current total supply limit, ex: 105 Billion XLM. Although the net result is simply paying a transaction fee as the account is debited/credited at the same time, the transaction does appear on explorers.

Reference Address: GA2HB3PRIKRDHJPJE54MLC5MCSRSHUPIKF2XIAOD4UIXQWGTWTIPHFB7

https://stellar.expert/explorer/public/account/GA2HB3PRIKRDHJPJE54MLC5MCSRSHUPIKF2XIAOD4UIXQWGTWTIPHFB7

See the above transaction, showing 105 Billion XLM. Although the impact is low as the user is not creating anything new.. should this be allowed as it could potentially mislead services that track network statistics (average transaction size etc). Thoughts?

@MonsieurNicolas

This comment has been minimized.

Copy link
Contributor

commented Apr 2, 2018

Thanks for kicking off this discussion, I am not sure there is a "right answer" to this one so feedback from the community is important.

I think the trade-off we made here is that we are allowing people to send to themselves, not necessarily that we don't check the balance of the user. We picked the simplest (from core's point of view) implementation given that.

Rationale here is that the amount "transferred" is irrelevant:
as soon as we allow people to send to themselves, if reporting tools don't filter those out, the volume can get manipulated (ping pong bots, etc), so changing the amount only creates an imbalance in the system in that it gives an edge wrt market manipulation to the big holders.

Now we could try to block people from sending to self - but that doesn't seem tractable as people can create payment loops to "pump" volume.

Design principles that prevailed here are:

  • when in doubt, use the simplest implementation as a starting point
  • as much as possible, whales should not have an edge over the small fish
@JonLister

This comment has been minimized.

Copy link
Author

commented Apr 2, 2018

Thank you for responding MonsieurNicolas,

Could you explain how payment loops could be used to circumvent a restriction of an address from being able to send to self?

If there's no simple or effective way to restrict, explorers and services tracking network statistics could always screen or filter these types of transactions.

@MonsieurNicolas

This comment has been minimized.

Copy link
Contributor

commented Apr 2, 2018

Could you explain how payment loops could be used to circumvent a restriction of an address from being able to send to self?

The simplest version of a loop is this:

  1. tx1: account A ; payment n (anything) to B (not just XLM btw)
  2. tx2: account B ; payment n to A

This will show up as trade volume of 2*n of XLM.

More complex ways to do this involve more accounts (so multiplier is anything I want), and when you combine those loops together with different amounts, you can basically end up with any rational multiplier.

@JonLister

This comment has been minimized.

Copy link
Author

commented Apr 2, 2018

Ah that makes sense. Well our team can enable restrictions in the wallets we're developing to restrict users from sending themselves more than their own balance as a best practice.

Thank you,
Jon

@mfontanini

This comment has been minimized.

Copy link
Contributor

commented Apr 2, 2018

I think sending funds to yourself is fine. However, is there actually any reason to allow sending yourself more than you have? A transaction saying I sent more than I own to myself looks kind of broken.

@MonsieurNicolas

This comment has been minimized.

Copy link
Contributor

commented Apr 3, 2018

However, is there actually any reason to allow sending yourself more than you have?

yeah this is the simplest dumbest implementation that didn't require to duplicate a bunch of code (payments are really "path payment" under the cover) - this may not be the case after we've merged the data layer changes, so we may consider this change if it doesn't break existing contracts (it's used as no-op).

@JoelKatz

This comment has been minimized.

Copy link

commented Nov 30, 2018

@mfontanini It's not clear what you mean by "allow". You obviously can't stop people from forming such transactions. And if you mean that the network shouldn't relay and execute them, that's clearly an inferior option.

Consider if I form a transaction that sends an amount I have, but at about the same time someone takes an offer that I placed and my account can't cover the amount I sent to myself if that transaction executes first. Now, we've relayed the transaction but may not get paid for it (since it cannot claim a fee unless it executes). I never find out the status of my transaction. And that transaction is part of a stream of transactions, my stream is jammed. Huge minuses all around.

If we allow the transaction to execute, the network gets paid a fee, everyone can see the final disposition of the transaction, and we don't have the attack vector of defunding transactions before they get accepted and getting free relaying.

@MonsieurNicolas

This comment has been minimized.

Copy link
Contributor

commented Apr 22, 2019

closing this as an issue, if people want to continue discussing this, the mailing list is probably a better fit

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.