Hi all,
I've been coping with reliably receive transactions which have a confirmation counter of at least 2 for a couple of days.
After different failings, I found out about the listtransactionsofblock RPC method which gives all transactions after a given block hash. It also gives the last block hash back which can be used in the next iteration.
The problem is that it gives me back unconfirmed transactions which were received after the last block which are worthless because they are unconfirmed. Moreover, it gives me these unconfirmed transactions over and over again when passing the 'lastblock"-hash to the method when there is no newer block. The main problem is that the output of the method is not constant although using the same hash, so one can't be sure there aren't more transactions coming ...
My proposal would be to implement a RPC-method which is named "listtransactionsofblock"giving me all transactions for which my wallet has got addresses.
Naturally, this method would only return transactions with at least one confirmation. The number of confirmations can be counted easily by subtracting the block-number from the total number of blocks.
It also should give back the next block-hash in the blockchain for iterating through the chain when a new block appears.
Perhaps, the 'nextblock'-hash could be dependend from the number of confirmations. So, the loop processing the transactions would constantly stay 2 or 3 or 6 blocks behind the block-chain head.
I would love this feature because doing it this way would assure you to only watch every transaction within a block once.
What do you think about it?
All the best, shufps