4

Recently I sent several transactions in a short period of time but my available balance was always more than enough for each transaction, so I did not think that chained payments should have been a problem. Because I use the set always-confirm-transfers 1 command I am able to see the fee information before each transaction.

I thought I remembered a message telling me I was about to send xxxx Monero with a fee of xxxx Monero of which xxxx Monero contains unconfirmed outputs. However because of the log level I was using, I cannot confirm (from my log file) this message as fact. If my memory is wrong, the correct message was likely:

The transaction fee is 0.02xxxxxxxxxx, of which 0.00xxxxxxxxxx is dust from change. Is this okay? (Y/Yes/N/No)

My available balance was far greater than the amount I was sending and the message seemed to be talking about the tiny quantity of unconfirmed outputs being used in the transaction fee itself. Out of curiosity, I selected Y to confirm the transaction and received the following error message:

Error: transaction < xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > was rejected by daemon with status: Failed

Error: Reason: fee too low

My logs provide additional details:

date,time ERROR /DISTRIBUTION-BUILD/src/wallet/wallet2.cpp:2506 daemon_send_resp.status != CORE_RPC_STATUS_OK. THROW EXCEPTION: error::tx_rejected

date,time /DISTRIBUTION-BUILD/src/wallet/wallet2.cpp:2506:N5tools5error11tx_rejectedE: transaction was rejected by daemon, status = Failed, tx:

key offets, key images, etc xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

signatures xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Error: transaction < xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > was rejected by daemon with status: Failed

Error: Reason: fee too low

I tried sending the same transaction less than 10 seconds later (no block confirmations in between) and it went through with no error. It appears as if the second time random outputs were chosen again for transaction fees and based on the always-confirm-transfers option, this time no unconfirmed outputs were being used for the tx fee.

I am certain that I had plenty of available outputs for each transaction I sent.

Are outputs used for transaction fees selected at random (including from unconfirmed outputs) so occasionally a transaction can be rejected for the reason above even when there are plenty of available Monero outputs for the transaction itself?

3
  • 1
    Please include the exact message saying anything about sending unconfirmed outputs. Replacing any address with a placeholder is OK.
    – user36303
    Commented Nov 28, 2016 at 8:30
  • @user36303 updated based on my memory and available log files. Thank you. Commented Nov 28, 2016 at 16:51
  • 1
    Thanks. This has nothing to do with unconfirmed outputs. What likely happened is that, due to varint encoding, a slight post creation change to the tx caused it to jump to a high size threshold, and since the fee is per kB, the fee was suddenly not enough. This is a bug in transaction creation. This is pretty rare, since it needs the change to cause a size increase, and the original size to be just a byte (or two, if unlucky) from the next kB limit.
    – user36303
    Commented Nov 28, 2016 at 18:39

1 Answer 1

3

This has nothing to do with unconfirmed outputs. What likely happened is that, due to varint encoding, a slight post creation change to the tx caused it to jump to a high size threshold, and since the fee is per kB, the fee was suddenly not enough. This is a bug in transaction creation. This is pretty rare, since it needs the change to cause a size increase, and the original size to be just a byte (or two, if unlucky) from the next kB limit.

There was a bug about this which got fixed a while ago, but there apparently is another one still, assuming you're using a recent master. The good news is that it is transient and doesn't break anything apart from needing to send again.

Chained payments do not exist in Monero. Since any output on the chain may be used by others as fake outputs, the owner is not allowed to use them either, for privacy reasons.

2
  • "the owner is not allowed to use them either, for privacy reasons." could you elaborate on this statement? Commented Oct 10, 2018 at 6:22
  • 1
    If only the owner of an output is allowed to spend that output when it is less than 10 blocks old, but such outputs are not allowed to be used as fake outs, then any use of that output when it is less than 10 blocks old means that output is the one being spent, thus wrecking the ring signature's point.
    – user36303
    Commented Oct 10, 2018 at 15:24

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.