0

I am a developer at a company that operates crypto-currency ATMs, and I passionately want to add Monero to our service. Until recently, there were legal and technical barriers that made this impossible. But those obstacles no longer exist, and I want to get XMR on our machines as soon as possible.

The normal way we (and all other operators) sell cryptocurrency is by sending funds from our hot wallet to a customer's address. This means that we need to be able to send a transaction from our hot wallet every time a customer makes a purchase. This might (and probably will) be much more frequently than once per ten Monero blocks. But if our balance is locked, then transactions will fail.

I know it is possible to lower the waiting period to one block, but I have not seen a way to lower it to zero. Further, that explanation gives the following warning:

One could ask, but why isn't it set to 1 then?

Problem is, the input one-time keys are referenced using an offset. If a re-org would swap the order of transactions, then the transaction referencing any one-time key at the wrong offset would become invalid and would never confirm.

I don't understand fully what this means. Is it possible to manage a Monero wallet carefully enough that a "re-org" never happens? I don't know what a "re-org" is.

You can see that some operators already offer Monero, so it must be possible. The most obvious solution I can think of would be to keep track of transactions and send them in batches, rather than immediately. For several reasons, I would like to avoid delaying transactions if I can. I am also concerned that batching would also run into problems because we still would not have enough unused inputs.

1 Answer 1

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 after it is mined into a block, then further dissipates the more blocks deeper down the chain it goes. In terms of "automatically", you will have to write something that sends the Monero when you have received whatever currency you are accepting. From the Monero side of things, you will use the wallet RPC, monero-wallet-rpc.

What about the balance locking?

This can mean a few things, but in the context of the rest of your question I assume you are referring to the situation where you want to make lots of transactions in succession but cannot because you have no unlocked balance. This situation is one whereby you are unable to send a tx until your change has confirmed on the blockchain.

If you have 10 XMR in only one output and send 1 XMR to someone, two outputs are created, one for 1 XMR to your recipient and 9 XMR in change back to you. Your 9 XMR is locked until confirmed on the blockchain. Another way of thinking about this is with bank notes in a wallet. If you have a single $100 note and buy something for $10, you are giving the merchant $100 and then have to wait for your change ($90) before you can go buy a coffee for $2.

The simplest way to mitigate this is keep your wallet fragmented with small outputs. One way of helping achieve this is via a couple of wallet options, found with help set:

min-outputs-count [n]
 Try to keep at least that many outputs of value at least min-outputs-value.
min-outputs-value [n]
 Try to keep at least min-outputs-count outputs of at least that value.

Another thing you can do is make sure to send lots of small transactions from your cold-wallet to your hot-wallet regularly.

Is it possible to manage a Monero wallet carefully enough that a "re-org" never happens? I don't know what a "re-org" is.

A re-org is a network level consensus thing (chain with most work wins) and as such there is nothing you can do at the wallet level to prevent a re-org. A re-org can in theory happen at any time/depth, though it's not that common and usually only small. By default, Monero transactions are deemed fully confirmed after 10 blocks (~20 mins) depth in the blockchain, which is a safe depth to deem the tx as final. Circling back to your first question, you can deem a tx final at any depth you like (i.e. when you release goods), and many merchants are happy to take on the risk of a zero or single block confirmation. The level of risk and semantics are different depending on which currency you are accepting of course.

6
  • To, be clear, my question is all about sending Monero. I understand how min-outputs-count would help with rapid transactions, but I don't understand how min-outputs-value would help. Also, are "outputs" in this context the same as unused inputs? Commented Feb 13, 2020 at 1:13
  • Also, is there a danger to lowering CRYPTONOTE_DEFAULT_TX_SPENDABLE_AGE for sending transactions, assuming the company itself doesn't care about its own anonymity? Commented Feb 13, 2020 at 1:15
  • Also, is there any benefit to using subaddresses and multiple accounts? I feel our strategy might need to be multi-tiered. Commented Feb 13, 2020 at 1:17
  • "but I don't understand how min-outputs-value would help" <- It is directly related to min-outputs-count. E.g. keep X count of Y value outputs.
    – jtgrassie
    Commented Feb 13, 2020 at 1:30
  • "Were your recommendations about zero-conf not about receiving Monero?" <- Yes. Because you also asked about re-orgs, which are only really a concern for a receiver.
    – jtgrassie
    Commented Feb 13, 2020 at 1:32

Your Answer

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

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