add cordova ios pending transaction functions

[ecioppettini]

There are currently no users of this things, but at least to keep all the platforms up-to-date

PENDING_TRANSACTIONS_GET
PENDING_TRANSACTIONS_SIZE
PENDING_TRANSACTIONS_DELETE
WALLET_CONFIRM_TRANSACTION
WALLET_PENDING_TRANSACTIONS

PD: Or maybe this API's can be reworked if there is a nicer way to handle transaction confirmation/rejection

[ecioppettini]

I'm wondering if finishing this API's is worth it or not... For utxo wallets this can be really useful, but for accounts not so much...

Or maybe we should just remove them, because no one is using them, and I'm not sure how helpful they are.

Currently only iOS implementation is missing, but I'm not sure how worth is it to maintain them in the future.

[eugene-babichenko]

Supporting iOS binding is relatively cheap, they are just a thing layer on top of wallet-c.

Where can I check the docs for these APIs though? I cannot see them in https://github.com/input-output-hk/chain-wallet-libs/blob/master/bindings/wallet-c/wallet.h.

Also, what is their specific relation to UTXOs?

[ecioppettini]

Where can I check the docs for these APIs though? I cannot see them in https://github.com/input-output-hk/chain-wallet-libs/blob/master/bindings/wallet-c/wallet.h

Hmmm, I never added them to the C crate, but it's just wrapping over these things

chain-wallet-libs/bindings/wallet-core/src/c/mod.rs

Line 354 in f31d891

pub unsafe fn wallet_confirm_transaction(wallet: WalletPtr, fragment_id: *const u8) -> Result {

Also, what is their specific relation to UTXOs?

First I'd like to clarify that to be actually useful we would also need to add a method to cancel a transaction and probably a method to add a pending transaction (which we already have the logic implemented for) to the state.

They are not specific to utxo. The thing with utxo's is that they are more complex to handle with multiple transactions, because you need to keep track of a whole set of things instead of just a number (nonce), and transactions can be independently cancelled/rejected in the middle.

Right now, the library internally stores a snapshot of the state for each transaction in a linked hashmap (the utxo set | counter+funds) for each transaction created.

For utxo, you could get more details (the inputs of the transaction you cancelled), and return the utxos to the pool to use them again or something if a transaction in the middle is rejected.

For accounts, I don't know. This is because you can just override the counter and the total funds if you need it, and that just throws away all the history, which is kinda the same as cancelling everything (which you probably want to).

In theory, I think these things could provide some value if we expose a function to read a pending transaction, so plugins users won't have to handle that logic. But that would require that we can get from the network the set of pending transactions.

That way, users could do something like this

let (funds, spending_counter) = account_status_from_network()

wallet.set_state(funds, spending_counter);

// the actual transactions, not the id's, so we could read the inputs (and outputs? I guess)
// for the general case, at least
let pending_transactions = fetch_pending_transactions_from_network(wallet.account_id())

for tx in pending_transactions {
    wallet.check_fragment(tx); // this is already implemented, just not exposed in cordova
}

wallet.vote(...); // this would use the spending counter after the pending ones
wallet.confirm_transaction(tx_id); // when you receive a notification, or just polling...
// OR
let cancelled_txs = wallet.cancel_transaction(tx_id); 
// this would need to cancel everything after that, and probably return it so it can be used again

But the logic is so simple that I'm not sure if it is something that we really want to handle in the plugin. I think that's the big question here.

OTOH, it would be more account/utxo agnostic.