5

I'd like to create a script which handles incoming payments to my wallet and once a payment has been confirmed 10 times it saves the payment id to a file.

I've read the RPC documentation, specifically get_bulk_payments. I just want to make sure I understand some key concepts and fill in some gaps in the documentation. Feel free to answer if you know any of the following points:

  1. The results from a get_bulk_payments call includes a block_height value, is this the first mined block this transaction appears in?

  2. Assume that calling get_bulk_payments with a min_block_height of 1010 returns a payment with block_height 1000. This means there have been 10 confirmations?

  3. If a payment returned from get_bulk_payments has an unlock_time != 0 does this mean I can't spend this amount immediately? If so, someone could (say maliciously) put an unlock_time for a year or more. I don't want to record this payment just yet if that's the case.

  4. I'm guessing that payments can have an unlock_time not equal to zero, but the time or blockheight value is in the past so it is spendable immediately.

  5. If there are 2 or more payments with the same tx_hash is it possible they have different unlock_time values?

Thank you!

Miles P
  • 620
  • 3
  • 4

1 Answers1

2

The results from a get_bulk_payments call includes a block_height value, is this the first mined block this transaction appears in?

Correct.

Assume that calling get_bulk_payments with a min_block_height of 1010 returns a payment with block_height 1000. This means there have been 10 confirmations?

If you specify 1010 as min_block_height it will only begin scanning blocks from block 1010. Thus, if a transaction was mined in block 1000 it won't be picked up by this specific command. You'd need to set min_block_height to 1000. As the documentation states:

The block height at which to start looking for payments

However, you are correct that a transaction mined in block 1000 will have 10 confirmations at block 1010. In other words, confirmations is the current block height minus the block height the transaction was mined in.

If a payment returned from get_bulk_payments has an unlock_time != 0 does this mean I can't spend this amount immediately?

Correct.

If so, someone could (say maliciously) put an unlock_time for a year or more.

Correct. If I recall correctly, the maximum lock time currently is 4 years.

I'm guessing that payments can have an unlock_time not equal to zero, but the time or blockheight value is in the past so it is spendable immediately.

Not sure if I understand this question correctly, but the unlock time is, as far as I know, set from the block the transaction is mined in. Note that by default all transactions are locked for 10 blocks. However, if an unlock time is included in the transactions they could be locked for a longer amount of time.

If there are 2 or more payments with the same tx_hash is it possible they have different unlock_time values?

Transactions cannot have the same tx hash. In addition, multiple transactions also cannot have the same outputs as that would indicate someone would've successfully performed a double spend.

dEBRUYNE
  • 15,227
  • 17
  • 57
  • 114
  • 1
    Great information, this helps a lot! Just to clarify on your last point, you mean that every payment returned by get_bulk_payments has a unique tx_hash? I think I'm getting confused with incoming_transfers which can have duplicate tx_hash. It seems then that incoming_transfers refer to outputs, so a payment is one or more outputs that make up the payments amount. – Miles P Feb 14 '17 at 22:56
  • 1
    That is correct. In a "conventional" transaction outputs were split up in denominations to the power of ten. For example, a transaction with an output total of 125 would've been split up in outputs of 100, 20, and 5. By contrast, a typical RingCT transaction only has 2 outputs, where 1 output goes to the recipient and one output goes back to the sender as change. More specifically, due to values being hidden RingCT transactions don't have to use denominations. [1/2] – dEBRUYNE Feb 15 '17 at 13:27
  • 1
    As you can see from the incoming_transfers screenshot the example transaction has multiple outputs of 10000000000000, 300000000000, and 50000000000. Note that Monero uses 12 decimal places. Thus, the actual amounts are 10, 0.3, and 0.05 XMR. These outputs belong to the same transaction and thus have the same transaction hash. Lastly, note that the example transaction is a "conventional" transaction. Hope this is sufficiently clear now. [2/2] – dEBRUYNE Feb 15 '17 at 13:31
  • 1
    Very clear, I appreciate the detailed answers. Thank you – Miles P Feb 15 '17 at 18:40