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

Wrapper: optimize transaction pathing for common cases #235

Closed
sohkai opened this issue Jan 25, 2019 · 0 comments · Fixed by #285
Closed

Wrapper: optimize transaction pathing for common cases #235

sohkai opened this issue Jan 25, 2019 · 0 comments · Fixed by #285
Labels
bug Something isn't working enhancement New feature or request priority: high used to mark an issue as high priority in a way that is less likely to get lost in the shuffle of th

Comments

@sohkai
Copy link
Contributor

sohkai commented Jan 25, 2019

We will soon make it a default that only token holders can create votes (forcing more users to use transaction pathing for simple actions).

Right now the transaction pathing algorithm either gets stuck, or takes incredibly long to find these paths (or conclude no path exists) by its brute-force algorithm. We should use some of the permission information we receive through the ACL to make this quicker; if an action is only allowed by a particular subset of apps or addresses, we can simply check if the user's current address can forward through those apps and if not, conclude that no path exists.

@sohkai sohkai added enhancement New feature or request bug Something isn't working labels Jan 25, 2019
@sohkai sohkai added the priority: high used to mark an issue as high priority in a way that is less likely to get lost in the shuffle of th label Feb 15, 2019
@sohkai sohkai added this to the A1 Sprint: 4.2 milestone Feb 18, 2019
sohkai added a commit that referenced this issue Apr 17, 2019
…ransaction path (#285)

Fixes #235.

Turns out the transaction pathing algorithm is sufficiently smart, we just weren't handling the 0 case correctly (resulting in an infinite loop).

The reason we can't rely on permissions data once we start looking for forwarding path is because those aren't determined by permissions; we have to check `canForward()` for each step.

An additional optimization we could make is cache which forwarders can be linked together, but this seems premature since there's unlikely to be very large paths at this point.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request priority: high used to mark an issue as high priority in a way that is less likely to get lost in the shuffle of th
Projects
None yet
1 participant