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

Enforce Tx unlock_time is Zero by Relay Rule [RELEASE] #9311

Merged

Conversation

jeffro256
Copy link
Contributor

Related to monero-project/research-lab#78

Added a relay rule that enforces the `unlock_time` field is equal to 0 for non-coinbase transactions.

UIs changed:
* Removed `locked_transfer` and `locked_sweep_all` commands from `monero-wallet-cli`

APIs changed:
* Removed `unlock_time` parameters from `wallet2` transfer methods
* Wallet RPC transfer endpoints send error codes when requested unlock time is not 0
* Removed `unlock_time` parameters from `construct_tx*` cryptonote core functions

@tobtoht: undo rebase changes tx.dsts -> tx_dsts
Copy link
Contributor

@rbrunner7 rbrunner7 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went through all the code again, after the review of the master branch PR. Again, saw no problems.

Encouraged by @selsta , beyond that code review I actually tested daemon and CLI wallet running this PR on testnet.

I tested the following:

  • The daemon still accepts blocks with locked transactions in them, which is correct, as this PR does not yet change consensus rules
  • The daemon ignores locked transactions sent to it from another daemon i.e. does not let them enter its pool
  • The daemon rejects a locked transaction submitted by a wallet without this PR
  • The CLI wallet without this PR correctly displays an error message when trying to submit a locked transaction that gets rejected by the daemon
  • The CLI wallet with this PR does not know commands like locked_transfer anymore which makes it impossible to ask for locked transactions

Unfortunately the rejection message of a CLI wallet without this PR does not mention the reason for rejection because obviously it does not know it:

Error: transaction <75aa75f2adb89290b9d79590d2a511b3390c9ffc37aaff5dc59c18de60a36bf1> was rejected by daemon

I checked the responsible code wallet2::get_text_reason: Seems to me there is no way for a "new" daemon to give back error info in a way to make an "old" CLI wallet showing the reason. I don't think that this really matters however.

@luigi1111 luigi1111 merged commit 1ec7eae into monero-project:release-v0.18 May 21, 2024
16 of 17 checks passed
@xmrrmxntom
Copy link

@rbrunner7 @Cactii1

A Plea to Restore a Crucial Feature in XMR

As a computer science student and a long-time follower of XMR & Dr. Daniel Kim (sweetwater.consulting), I'm compelled to share my thoughts on a feature that I believe is important to the value proposition of XMR. I've created an account specifically to express my disappointment and frustration with the removal of the locked_transfers and locked_sweep_all feature.

A Personal Journey with XMR

I've been following the XMR project since 2018, and its value proposition was evident to me even back then. However, I wasn't technical enough to fully appreciate its features. This year, I became proficient enough to run a full node and use the CLI, which is when I discovered the locked_transfers and locked_sweep_all features. I immediately utilized them, and they have been invaluable to me.

As someone who has impulsively sold assets like NVIDIA, BTC, and TSLA before they reached their full potential, I've come to realize that XMR is a long-term play that will appreciate in value over the next 5-20 years. The ability to lock transactions for an extended period has been a game-changer for me, allowing me to make sacrifices that my future self will appreciate.

The Value of Locked Transactions

The locked_transfers and locked_sweep_all feature was a unique selling point for XMR, offering me the ability to make long-term commitments to the blockchain. By removing this feature, we're depriving users of a valuable tool that would help them appreciate the embedded on-chain hodl properties of the XMR blockchain.

A Call to Action

I urge the XMR community to reconsider the removal of this feature and to implement safeguards to prevent similar decisions in the future. Specifically, I request:

  1. Reinstatement of the feature: Bring back the locked_transfers and locked_sweep_all feature to allow users to make long-term commitments to the blockchain.
  2. Safeguards for feature deprecation: Establish a formal, non-trivial process or procedure to determine whether a feature should be deprecated, ensuring that user feedback and concerns are taken into account and valued.
  3. Improvement or alternative: If the feature cannot be reinstated, explore alternative solutions that would provide similar functionality and benefits to users.

Conclusion

As more users join the XMR community, they will come to appreciate the unique properties of the blockchain. I firmly believe that the locked_transfers and locked_sweep_all feature helps users HODL with the long-term success of XMR. I hope that my plea will be heard, and we can work together to restore this important feature.

A Final Appeal

I've gone from hearing about XMR as the real privacy-focused vision of BTC, to buying some XMR on an exchange, to self-custodying on Exodus wallet, and finally to downloading and running the CLI. XMR is beautiful, and it's idealistic. Please keep or reimplement this feature.

https://reddit.com/r/Monero/comments/mwrm6g/how_to_lock_send_future_monero_to_yourself_with/

This was the post and feature that motivated me to dedicate a weekend last semester to read the documentation, compile from source, and use the CLI.

…Please keep this feature…

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants