Feature request: `blockchain.transaction.subscribe` and `blockchain.transaction.unsubscribe`

[monsterbitar]

Currently, in order to get notified when a transaction is confirmed, you have to subscribe to all changes to the recipient address, then look for changes to the specific transaction itself. This is problematic, because when done, if you unsubscribe from the address you might unintentionally unsubscribe from address changes you previously subscribed to elsewhere.

A proper solution is to add transaction subscribe/unsubscribe methods similar to the address subscriptions, that return the status of the transaction (some hash of the transaction metadata). This would be safe(r) to subscribe and unsubscribe to, and also easier to understand and would keep code cleaner in both design and legibility.

[monsterbitar]

Correction, the blockchain.headers.subscribe is a better call to get a notification on change, and makes more sense than the address.

My bad, this is signficantly less important than I initially assumed.

[cculianu]

Hmm yeah. I see what you mean. Yeah I guess getting notified of a header (e.g. a block) is probably the fastest thing right now with the current API -- then you can query the address's balance, history, list_unspent, etc.

As for tx sub/unsub. Hmm. I'll think about it. That's not a bad idea -- I just think it would be some work to implement and test, so there's a resource challenge there. I do this as a volunteer for free and all, so it's a passion project.

I'll leave this issue open and maybe if others chime in that they need this feature for their application -- it's an idea on the table and can maybe happen some day.

I would hate to spend a week implementing it then nobody uses it or very few people use it... :/

[monsterbitar]

One benefit of a tx sub/unsub over block headers, is that if the tx gets dropped from the mempool, or if it gets double-spent, or if there's some CPFP metadata available, those could get exposed while waiting for a block header would not provide that data.

You're right in that this is neither urgent or very important, but over time as small issues keep stacking up I feel it might end up holding back new developers from joining the space - it's not very inspiring to see some of these "unclean" solutions.

For now, I'll work around it, and we'll see if others chime in later.

[cculianu]

CPFP metadata available,

You'd like to get notified on descendant tx's too? Or?

(Just trying to get an idea for how this thing would work)

[monsterbitar]

The core requirement would be to know if the transaction gets confirmed, and if it is dropped from the mempool.

Being able to get notification when anything that may impact the transactions likelihood of being confirmed or dropped is beneficial (allows building better payment processing tools / risk estimation tools), but once a transaction is confirmed I think it makes more sense to track the individual UTXO's, rather than continuing to track the transaction.

With regards to descendants / CPFP - since the total accumulated fee for the transaction chain might impact a miners behaviour, it would be nice if that indeed triggered a status updated (and there was some way to get that information).

[cculianu]

The core requirement would be to know if the transaction gets confirmed, and if it is dropped from the mempool.

👍

nice if that indeed triggered a status updated

Interesting. It might also be possible calculate an avg fee total for all tx's in the "package". I could see the API offering a status update when descendent count changes and the status info would include some information like that so client code can "tell" if a TX looks like it is very generously rewarding miners versus not, etc.

Of course right now everything pretty much confirms if it made it to the miner within the last 10 seconds or so.. so long as it can get relayed.

But that may always not be the case.

Interesting feature. Will definitely keep it on the table as something that would be nice to have.

[monsterbitar]

Dagur made a nice list in the corresponding issue in electrscash, that might be good to be aware of: BitcoinUnlimited/ElectrsCash#86

[monsterbitar]

I'd like to point out that readcash is currently asking BCHD to implement a similar feature to learn when/if transactions are evicted frm the mempool and why (as part of a much larger issue):

gcash/bchd#404

[cculianu]

Ah thanks for that link. So.. the "competition" is already threatening to beat us! But seriously thanks for the link.

[cculianu]

Hey Jonathan this might be related:

spesmilo/electrumx#80

ElectrumX guys want to add blockchain.outpoint.subscribe (see the PR for the actual specification). It's not exactly blockchain.transaction.subscribe -- but it's.. sort of in the same ballpark, but not exactly what you asked for here. Let me know your thoughts on that. They need it for lightning.

[monsterbitar]

I wouldn't mind being able to subscribe to TXOs. If I can create a TX locally, subscribe to the TXO and then broadcast it, would I get similar behaviour to an address status? (that is, would I get notifcation for block inclusion as well as for when it gets spent? Could this be a reasonable entry-point to get notified of DS-proofs?)

[cculianu]

So it would be useful to you?

Ok, just to answer your question(s) (I hope) -- so the full "life cycle" for an outpoint.subscribe would be:

1. If it doesn't exist, you get notified with: {}
2. If it then later exists as an outpoint but is unspent, you get notified with: { "height" : xxxx } (where height may be 0 or a confirmed height for the txo that now exists in a tx).
3. If it is later spent, you get notified: {"height": xxxx, "spender_hash" : "xyz", "spender_height": confirmed_height_0_for_mempool }
4. (Unlikely) If its spending tx is reorged later out of existence, you get back the same notification as in (2) above.
5. (Unlikely) If its spending tx ends up as a different tx due to a double-spend, you get an updated (3) again with the correct info.
6. (Unlikely) If it, the txo itself, gets reorged out of existence, you get notified with (1) again.

Note that we can "extend" this facility, potentially to also include dsproof information if available from the node... (for mempool-only tx's obviously). Perhaps offer an additional key as an extension, "double-spends", or something.

---

Unrelated: I do want to add the original method you asked for, transaction.subscribe ! It does require a new index but is something we may want anyway regardless of this outpoint.subscribe business...