0

I was reading this discussion on adding nLockTime to Monero, and the OP says that we can achieve this functionality by having a small amount of cryptocurrency transferred with an transaction-unlock-time and use this as a lock by having a multiple input transaction with this locked account to create a transaction that won't be valid until some time in the future.

The question is are these multiple real input transactions binding? Meaning I have money in a 2-of-2 multisig account A where I own one of the keys and money in account L, where L is locked using transaction-unlock-time, and I have transaction that will be valid using A and L as real inputs back to to an output I hold (will be valid after L unlocks).

If I was a bad actor, could I separate the transaction and just send the money from A back to me by separating the transaction? Or is this a hard problem?

EDIT: The paragraph talking about multiple input is as follows: "It is technically possible to implement nLockTime now (without protocol change), but it is a little clunky. You have to put a negligible amount of Monero in a time lock transaction, and then sign a transaction spending it and the funds you want to nLockTime. This won't be publishable until the other transaction is unlocked, but it is a little clunky, requiring a couple of transactions (and data must be published to the blockchain)." The bold section implies a multiple input transaction.

Improve this question
1

1 Answer 1

Reset to default
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 almost certainly will within 2 minutes, be mined. And as soon as it's mined/confirmed on the blockchain, it is final, even if it has an unlock time set (ref this answer). This means the output(s) of that tx cannot be spent (used as inputs) in another tx, until the unlock time has passed.

Therefore, if you set an unlock time on a tx destined for a multisig wallet, the outputs of that tx, which are now owned by the multisig wallet, need to both pass the unlock time and be signed by both wallet participants to be spent. The tx cannot be cancelled and it can only be refunded* (sent back) once it has passed its locked time and signed by all participants.

(*) I say refunded here, but this is actually just a normal, manual, spend. There is presently no such thing as a tx refund address in Monero which would allow a more automated refund.

Pulling this all together, dissecting your question(s):

The question is are these multiple real input transactions binding?

The moment a valid tx is sent to the network and mined/confirmed, it is binding. The input(s) must have been unlocked and you must have had the signing key(s) for them.

Meaning I have money in a 2-of-2 multisig account A where I own one of the keys and money in account L, where L is locked using transaction-unlock-time, and I have a valid transaction using A and L as real inputs back to to an output I hold.

You simply cannot have a situation like you have described here. It cannot be both "in a 2-of-2 multisig" wallet (locked or not) and in another wallet (locked or not). The moment you send (publish) the output to the multisig, it has to have been unlocked in your source wallet, and even if you specify it is to be locked when received in the multisig wallet, you cannot do anything with it after in the source wallet (it is now spent, regardless if it is now locked or not).

If I was a bad actor, could I separate the transaction and just send the money from A back to me by separating the transaction? Or is this a hard problem?

Given you have defined A as a 2-2 multisig, the only way you can send it back to yourself is by having both the other signer sign this new transaction sending it back to you and the funds not being locked in the multisig. There is no gaming this.

Improve this answer
11
  • Discussion of multiple inputs isn't explicit, but I believe it is there. I edited in the paragraph to the question and made the section I think talks about multiple inputs bold. Is that section not implying a multiple input transaction?
    – Zarquan
    May 28, 2019 at 22:56
  • It is saying that Monero doesn't support it, but you can get around it to get the functionality. The process they are describing is as follows: 1: Party one uses an unlock-transaction-time to put a small amount of money in account A. 2: Create a transaction that transfers money out of A and B back to party one. Account B is a multisig account between party one and two. Both parties sign the transaction. 3. Transfer money in to account B. Now if the protocol fails, the money can be returned once the transaction to A is unlocked.
    – Zarquan
    May 28, 2019 at 23:53
  • I read "sign a transaction spending it and the funds you want to nLockTime" as multiple inputs, seeing as the it they refer to is the negligible amount mentioned and the funds you want to nLockTime is another. Note that this is a workaround for the lack of nLockTime, not an actual implementation of nLockTime within Monero.
    – Zarquan
    May 29, 2019 at 0:04
  • To be clear, I know that a multisig account is an account that can not be spent from without the use of more than one key (or more than one part of a key), and that a multiple input transaction is a transaction that takes more than input (or spending account) in one transaction.
    – Zarquan
    May 29, 2019 at 0:07
  • Updated answer based on your edited question and comments/clarifications.
    – jtgrassie ♦
    May 29, 2019 at 3:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.