21

There is a command to lock coins when you make a transaction by RPC in simplewallet. I don't think it's implemented in the command line interface. It's the unlock_time parameter in the JSON RPC transfer, described in the source code here: https://github.com/monero-project/bitmonero/blob/eb1b87d2393f34caa9698bec23a4b78fa57da752/src/cryptonote_core/...


14

One way to do this is to use a very large unlock time. An unlock time value is either a block number (you can select one as large as ~1900 years from now, which is arguably not burned forever, especially if block time changes) or a UNIX time (you can then lock it for about 292 billion years, which should be enough for most purposes). Another way would be to ...


11

Setting an unlock time has many possible uses such as but not limited to: Scheduling annuity payments Providing a child with spending money for an upcoming vacation while ensuring it cannot be spent before the vacation is scheduled. Paying a developer a significant amount of Monero for work being performed now without the fear that the Monero will ...


9

If orphan levels increased or were above some tolerable threshold, an increase in block time would help alleviate the situation. This answer to a question about unlocked balances explains Monero's greater sensitivity to reorganizations.


8

What would be good reasons to further increase block time in the future? A couple good reasons would include if pools were experiencing a lot of orphaned blocks or if blocks were routinely empty. An orphan block is when a pool mines a block, but then realizes another pool beat them to that block and it gets ignored by the other pools. This usually only ...


8

Yes. You need overwrite the transaction with another transaction sans unlock_time. If the transaction in question is already in a block, then you'll need to reorganize the blockchain to the depth where this transaction was first added, removing it and adding your replacement. The short version: "no". This is part of the immutability property of blockchains (...


7

A transaction with a non default unlock_time will be mined as normal. However, its outputs will not be able to be used as inputs in another transaction before that time (which can be either a blockchain height, or a UNIX time in seconds). Your second question is confusing. You can't override a tx (except with a double spend attack sending conflicting txes ...


7

Yes, it will be locked for the same amount of time. This is because the wallet had split some of the inputs into 2 amounts: one which it sent to the destination, and one which it sent back to yourself as change. The amount which will be locked on the sending wallet will depend on what input was chosen by the wallet when sending, and duration will be the ...


7

You can do this by using the transfer_original command. The default transfer command will not split, but seems to be aggregating all the amounts going to the same address in a single denomination. This is based on a few tests I did just now. So, to split 100XMR to 10 denominations of 10XMR, you'd do: transfer_original <youraddress> 10 <youraddress&...


6

There's no direct way, but there could be a workaround. The protocol doesn't limit the number of inputs/outputs. So, you could split the first transaction into many outputs where some (or all) of them are going back to yourself. This way, you'd do all your payments at once, and get more than one change output. Yes, you'd pay more fees but you'd then ...


5

Question: is the unlock block height the first block that an output is spendable, or the last block it is unspendable? ... can the coinbase be spent in block 61 or must it be at least block 62? 61.


5

This isn't available in the wallet software yet, but it is technically possible to set an "unlock_time" on a transaction: How to use unlock_time? The idea being that you could pass a future date in UNIX time into this RPC call which would cause funds to be locked until that time has passed. You could then use this to send all of your funds back to your own ...


5

The main use is as Commitment Devices; that is when you (or someone else) don't trust yourself with your own short term decisions and impulsiveness. For example: 1) Compulsory savings plan: you, or your employer, puts (perhaps automatically) part of your income in an output that is locked for some time, maybe for your retirement or other similar goal; 2) ...


5

A. Is this a wallet rule or a protocol/daemon rule? It's a wallet / daemon rule. The number of blocks is defined as a pre-compiler constant CRYPTONOTE_DEFAULT_TX_SPENDABLE_AGE. B. Does the rule only apply to spending one's own output, or are new/locked outputs also excludable from a ring signature even as decoys/mixins? Generally, it applies to all ...


5

As far as I understand, this is to make sure that the coins were mined on the longest blockchain, and thus the longer "delay" of 60 blocks is meant as a safeguard against transactions becoming invalid because of blockchain reorganizations. These might change several dozens of blocks sometimes. While 60 blocks should typically be enough, I have seen some ...


4

It's a field in the rpc call to send a transaction, see here: https://github.com/monero-project/monero/blob/0edcbf6716cdfd2ea5439a7788cca0041b40a2e2/src/wallet/wallet_rpc_server_commands_defs.h#L124 I think the way it works is if you pass that field a number that is less than the start of UNIX time in seconds, then it is interpreted as a block height that ...


3

The Coinbase can be spent after 60 blocks. See CRYPTONOTE_MINED_MONEY_UNLOCK_WINDOW


3

Take a look at a response to issue #2351: You can send 50 monero 20 times in one tx to yourself (make sure you have set merge-destinations to 0 first). This will break up the 1000 output. Also set min-outputs-count and min-outputs-value to, say, 20 and 10, see the commit message for 0ad87db for an explantion of how they work. Last, you can pay several ...


3

There is no danger. The answer you quoted states that the transaction would be mined and confirmed like any other transaction. The sender can prove this with the same methods (payment IDs, etc) as any other transaction The recipient would have the exact same ability to spend outputs from a 2 year unlock_time transaction as a recipient of a non unlock_time ...


2

If the rules are the same as on the main network, you need to wait 60 blocks (ca. 2 hours) to see the balance unlocked for coins that you mine. For normal transactions, the balance is locked for 10 blocks only (ca. 20 minutes).


2

How can I automatically sell Monero? This is a little vague. What are you selling Monero for? Assuming you are selling Monero for some other cryptocurrency, you can still sell with zero-conf if you so wish. Zero-conf being the moment your wallet sees the tx (i.e. the tx is in the tx pool). Of course, there is a level of risk in doing so, which dissipates ...


2

The amount which remains unlocked after a transaction depends on the number of unspent outputs (UTXO) you have in the wallet. Consider those scenarios: A: One UTXO You have filled the wallet with one transaction of 10 XMR. That means your wallet has only one UTXO containing entire balance. You spend 1 XMR. The transaction you create has one input of 10 ...


1

You can prove a) that a tx has locked coins by providing the tx hash of the tx which has the locked funds and b) prove you created the tx. To prove a tx has locked funds, simply give the user the txid so they can inspect it on the blockchain (using either their own local daemon or a blockchain explorer). E.g. $ monerod print_tx 6cd029...bf8c34 +json Found ...


1

The OP workaround does not actually mimic a Bitcoin nLockTime tx, because the second tx (with the actual funds), is not published - it cannot be, the network would reject it. An nLockTime tx is actually published to the network but cannot be mined (included in a block) until the specified time has passed. The moment a Monero tx is published, it can, and ...


1

In monero-wallet-cli you can use the locked_transfer command to send money to yourself and lock it for a number of blocks.


1

Normally, transfers are locked for 10 blocks. If yours were still locked, it means either node node was failing to sync to the chain, or the wallet failed to refresh from the node. You'd see that if the wallet was claiming the same height for a few days, though I'm not sure if it displays that promoinently. Of course, it could also be a bug in the GUI or ...


1

Waiting 10 more mins until it reached ~60 block maturity allowed me to access my coins. The problem wasn't to do with the server, but to do with the fact that the mined coins must wait much longer than normal transactions before they can be unlocked and spent.


Only top voted, non community-wiki answers of a minimum length are eligible