Why not wait for N blocks instead of using the delayed node?

[bytemaster]

just monitor the dynamic_global_properties (object 1.2.0)  for last_irreversible_block_num and then verify that any operations you process have a block number that is less than that.   If you do that you should be good.

Just beware that if you shutdown the last irreversible block number may move back a few places, so don't use last irreversible block number as the placeholder for the blocks you have already processed.

[xeroc]

I am currently in china and can't really work a lot (due to fu*** up internet) .. I will try to figure this out ASAP .. in the meantime I would recommend you play around with object ids and stuff .. maybe the objects "1.11.*" contain an indicator on how often the operation has been confirmed already

[monsterer]

you can use both .. can't you? not sure but I think the transaction details contain a parameter that indicates how many blocks need to be waited till irreversibility .. if not .. if could CERTAINLY be added ..

I really don't want to maintain multiple executables just to support one coin type, if possible.

[xeroc]

The benefit of the delayed node is that you never even see the unconfirmed transactions and thus never have the opportunity to make a mistake.   

Also there is some chain state that is not contained fully in the transaction, so if you wanted to know information such as your confirmed cash-back rewards then you would need a delayed node to tell you.

Metaexchange will need show pending transactions for responsiveness, so we will need to use the full node, rather than the delayed node, I think.

you can use both .. can't you? not sure but I think the transaction details contain a parameter that indicates how many blocks need to be waited till irreversibility .. if not .. if could CERTAINLY be added ..

[monsterer]

The benefit of the delayed node is that you never even see the unconfirmed transactions and thus never have the opportunity to make a mistake.   

Also there is some chain state that is not contained fully in the transaction, so if you wanted to know information such as your confirmed cash-back rewards then you would need a delayed node to tell you.

Metaexchange will need show pending transactions for responsiveness, so we will need to use the full node, rather than the delayed node, I think.

[bytemaster]

I think it's possible but it will require more work on your side.

You will need to keep track of every transfer operation to know if they are "confirmed" or not.

You are correct.  In the GUI we indicate which operations have been irreversibly confirmed and you could use such a system.

The benefit of the delayed node is that you never even see the unconfirmed transactions and thus never have the opportunity to make a mistake.   

Also there is some chain state that is not contained fully in the transaction, so if you wanted to know information such as your confirmed cash-back rewards then you would need a delayed node to tell you.   

[ElMato]

I think it's possible but it will require more work on your side.

You will need to keep track of every transfer operation to know if they are "confirmed" or not.

[monsterer]

Is there another advantage to using a delayed node that wouldn't be afforded by waiting N blocks on a trusted node?

I'd like to be able to minimise the number of executables I need to maintain because it's easier that way.