Feature request: EthClient support for SubscribePendingTransactions

[Sexual]

There is a comment with a "todo" for this. Any plans on implementing it?

[adamschmideg]

Referring to https://github.com/ethereum/go-ethereum/blob/master/ethclient/ethclient.go#L444

[holiman]

No, no plans on that. It's very unclear what the caller would expect. Transactions are internally shuffled between pending and queued quite a lot, and at any time a couple of hundred transactions may be moved from one to the other. and then back again a few seconds later.

Or is the caller interested in the transactions from the next pending block? Those are re-evaluated about every three seconds, and not really nice either.

So, no. Do you have a usecase that you want support for? If so, please elaborate.

[Sexual]

@holiman To simplify our use case, we want to detect when an address receives a transaction/payment before it has confirmed.

Currently, our JS implementation uses web3.eth.filter('pending'), but the new version utilizes Go. We've tried a "hacky" implementation using the below function, and whilst it seemed to work on the Ropsten network, on the main net it would be really delayed.

func (ec *Client) SubscribePendingTransactions(ctx context.Context, ch chan<- string) (ethereum.Subscription, error) {
    return ec.c.EthSubscribe(ctx, ch, "newPendingTransactions")
}

[karalabe]

There are a few interesting corner cases here that we'd need to consider:

• If you create a subscription to pending transactions, I guess that would be streaming individual transactions back to you. However, the pending block is continually assembled as transactions come, until it's full, so you won't know when a transaction belongs to a previous or next block. Should we also add inclusion block numbers?
• Some nodes (miners) may periodically (every 3 second) reconstruct blocks to better optimize gas earnings, what happens if the same pending block gets a new set of transactions, what should be streamed.
• The pending block is just a guess as to what transactions might be included in the next 15 seconds. Is that really so valuable? The transactions might disappear, they might get delayed arbitrarilly many blocks, and pending transactions might not even show up in the pendig block if they don't fit yet (e.g. if there are 1000 txs in the pool, but only 200 fits).
• If you want to detect received funds, you might run into interesting issues with contract senders, where the transaction recipient is actually a multi-sig that forwards funds to you. You have no way to detect that unless you have a contract account firing logs, in which case I think you can already subscribe to pending logs.

[no-response[bot]]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have more relevant information or answers to our questions so that we can investigate further.