Enforce Tx unlock_time is Zero by Relay Rule [RELEASE]#9311
Enforce Tx unlock_time is Zero by Relay Rule [RELEASE]#9311luigi1111 merged 1 commit intomonero-project:release-v0.18from
Conversation
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
There was a problem hiding this comment.
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_transferanymore 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.
A Plea to Restore a Crucial Feature in XMRAs 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 A Personal Journey with XMRI'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 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 TransactionsThe A Call to ActionI 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:
ConclusionAs more users join the XMR community, they will come to appreciate the unique properties of the blockchain. I firmly believe that the A Final AppealI'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… |
Version increased in monero-project/monero#9311
#9151