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

Pay by time on mempool #427

Closed
igormcoelho opened this issue Oct 25, 2018 · 7 comments · Fixed by #500
Closed

Pay by time on mempool #427

igormcoelho opened this issue Oct 25, 2018 · 7 comments · Fixed by #500
Labels
Discussion Initial issue state - proposed but not yet accepted

Comments

@igormcoelho
Copy link
Contributor

igormcoelho commented Oct 25, 2018

Talking to @vncoelho, one idea came to mind... I think we could establish (network gas) prices for transactions to apply for mempool for a given time. This time can be calculated on timestamp or block height, and can be implemented with or without this feature here: #414 (because we can simply use scripts to validate transaction expiration times).

Example: Block Height is 1000 now. If I submit a free transaction, it should include an expiration script for at most 3 or 5 blocks (after that, it expires). If I pay 0.00001 GAS, then my transaction can last 10 blocks... 0.00002 for 20 blocks... price increases if I want it to be valid for more time. Long time-to-live pays more, shorter pays less (or zero). It's very easy to implement, what does the community think of it?

Another possibility for nodes is to give priority to tx near expiration, so long term spam tx will be double punished.

@igormcoelho
Copy link
Contributor Author

igormcoelho commented Oct 25, 2018

I think this NEP (neo-project/proposals#67) would help a lot to easily create such transaction detection, but it's also not mandatory, we can do it anyway!

@saltyskip
Copy link

Can it not just include an expiration script, and then the wallet provider is the one that determines the appropriate fee give the expiration script?

EG
In wallet user sets 50 blocks time to live, wallet generates the included expiration script, and displays the recommended fee of 0.XXX. This fee is attached, and not extra work is required by the nodes themselves?

Do you have example of such an expiration script btw

@erikzhang erikzhang added the Discussion Initial issue state - proposed but not yet accepted label Oct 26, 2018
@igormcoelho
Copy link
Contributor Author

In fact, the wallet will be responsible for attaching Gas, but P2P nodes will need to verify it anyway. So, the rule must be public. Waiting for advances here: #443

@ThomasLobker
Copy link

I like the idea that a transaction has a setting that defines the time to live. But to charge more GAS for a longer time to live goes against the idea that high priority transactions should already be charged more. So if you pay more and you can choose between high priority or high time to live, then anyone would go for high priority.

How about allowing a time to live to be set by the user, without charging him extra fees? Default is 10 blocks, but a user can change this to any number between 1 and 100 for example.

@belane
Copy link
Member

belane commented Nov 2, 2018

Agree with @ThomasLobker, it doesn't make much sense to pay for time in the mempool when you have already paid for a priority.

@igormcoelho
Copy link
Contributor Author

igormcoelho commented Nov 2, 2018

Yes @ThomasLobker we can do that easily, without extra paying or changing anything else on Neo... I have an open issue at neon-js to propose that, it's just a matter of attaching the expiration script, which is also mentioned there... I just need some time to study their coding, to propose something correct for them.

@jsolman
Copy link
Contributor

jsolman commented Dec 5, 2018

With my latest mempool changes I think this discussion is not important; the mempool will be able to be full all the time with negligible performance impact to nodes and lower fee transactions will drop off naturally

Thacryba pushed a commit to simplitech/neo that referenced this issue Feb 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion Initial issue state - proposed but not yet accepted
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants