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.

[dagurval]

This sounds like a good feature to me.

What would the notifications look like? I can think of the following transaction states that may or may not be interesting:

• Transaction enters the mempool
• Transaction leaves the mempool (bumped out due to fee?)
• Transaction is confirmed in a block
• Transaction gets additional confirmation
• Transactions get unconfired (reorg)
• Transaction gets a double spend conflict
• Transaction leaves the mempool due to a conflicting transaction getting confirmed
• Transaction has a unconfirmed parent, and the parent transaction has a conflicting transaction.
• Transaction gets a new decendent transaction

[dagurval]

What response do we can when subscribing?

I guess, if transaction has not been seen, "Null"

If it's in the mempool, you'd get the same response as when it enters the mempool.

[monsterbitar]

I think the direct response on subscription should either be identical to the notifications (same structure), or boolean indicating that the subscription is active.

I submitted the same on fulcrum and there's some discussion there to consider as well: cculianu/Fulcrum#32

I like the clear list of events that can change the transaction status you have up here. I hadn't thought about the "enters mempool" as an event before since I assumed that knowing about a transaction would mean it's already out there, but for off-chain services that might be really importan (like, for payment channels to keep track of possible settlements).

[monsterbitar]

One more "event" that could be impacting a transactions status is it becomes relayable / non-relayable. I don't know who that would be implemented on the backside of things, and it feels like it would be relatively costly, but I'll bring it up here just in case.

[cculianu]

Heh, yeah. relayable/non-relayable would be costly. You'd have to poll bitcoind on the server side. This is a DoS vector handgrenade waiting to go off.

[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

[monsterbitar]

Some update over at fulcrum issue: cculianu/Fulcrum#32

[cculianu]

Yeah I'm thinking of just implemented a simple one of these that has 3 possible states you can get notified on: null, "mempool", and "confirmed" and any subscription can switch between any of the 3 states depending on blockchain conditions.