2017-11-13 22:55:22 +03:00
|
|
|
package chainntnfs
|
|
|
|
|
|
|
|
import (
|
2018-12-07 08:13:35 +03:00
|
|
|
"bytes"
|
2018-03-19 22:22:44 +03:00
|
|
|
"errors"
|
2017-11-13 22:55:22 +03:00
|
|
|
"fmt"
|
2018-07-27 07:31:32 +03:00
|
|
|
"sync"
|
2017-11-13 22:55:22 +03:00
|
|
|
|
2018-06-05 04:34:16 +03:00
|
|
|
"github.com/btcsuite/btcd/chaincfg/chainhash"
|
2018-12-07 08:13:44 +03:00
|
|
|
"github.com/btcsuite/btcd/txscript"
|
2018-10-05 12:07:55 +03:00
|
|
|
"github.com/btcsuite/btcd/wire"
|
2018-06-05 04:34:16 +03:00
|
|
|
"github.com/btcsuite/btcutil"
|
2018-12-07 08:13:35 +03:00
|
|
|
"github.com/lightningnetwork/lnd/channeldb"
|
2017-11-13 22:55:22 +03:00
|
|
|
)
|
|
|
|
|
2018-12-05 03:57:37 +03:00
|
|
|
const (
|
|
|
|
// ReorgSafetyLimit is the chain depth beyond which it is assumed a
|
|
|
|
// block will not be reorganized out of the chain. This is used to
|
|
|
|
// determine when to prune old confirmation requests so that reorgs are
|
|
|
|
// handled correctly. The average number of blocks in a day is a
|
|
|
|
// reasonable value to use.
|
|
|
|
ReorgSafetyLimit = 144
|
2018-12-05 03:59:20 +03:00
|
|
|
|
|
|
|
// MaxNumConfs is the maximum number of confirmations that can be
|
|
|
|
// requested on a transaction.
|
|
|
|
MaxNumConfs = ReorgSafetyLimit
|
2018-12-05 03:57:37 +03:00
|
|
|
)
|
|
|
|
|
2018-12-07 08:13:32 +03:00
|
|
|
var (
|
|
|
|
// ZeroHash is the value that should be used as the txid when
|
|
|
|
// registering for the confirmation of a script on-chain. This allows
|
|
|
|
// the notifier to match _and_ dispatch upon the inclusion of the script
|
|
|
|
// on-chain, rather than the txid.
|
|
|
|
ZeroHash chainhash.Hash
|
|
|
|
|
|
|
|
// ZeroOutPoint is the value that should be used as the outpoint when
|
|
|
|
// registering for the spend of a script on-chain. This allows the
|
|
|
|
// notifier to match _and_ dispatch upon detecting the spend of the
|
|
|
|
// script on-chain, rather than the outpoint.
|
|
|
|
ZeroOutPoint wire.OutPoint
|
|
|
|
)
|
|
|
|
|
2018-07-27 07:27:27 +03:00
|
|
|
var (
|
2018-10-05 12:07:55 +03:00
|
|
|
// ErrTxNotifierExiting is an error returned when attempting to interact
|
|
|
|
// with the TxNotifier but it been shut down.
|
|
|
|
ErrTxNotifierExiting = errors.New("TxNotifier is exiting")
|
2018-10-18 04:10:08 +03:00
|
|
|
|
|
|
|
// ErrTxMaxConfs signals that the user requested a number of
|
|
|
|
// confirmations beyond the reorg safety limit.
|
2018-12-05 03:58:54 +03:00
|
|
|
ErrTxMaxConfs = fmt.Errorf("too many confirmations requested, max is %d",
|
|
|
|
MaxNumConfs)
|
2018-07-27 07:27:27 +03:00
|
|
|
)
|
|
|
|
|
2018-10-10 02:24:30 +03:00
|
|
|
// rescanState indicates the progression of a registration before the notifier
|
|
|
|
// can begin dispatching confirmations at tip.
|
|
|
|
type rescanState byte
|
|
|
|
|
|
|
|
const (
|
|
|
|
// rescanNotStarted is the initial state, denoting that a historical
|
|
|
|
// dispatch may be required.
|
|
|
|
rescanNotStarted rescanState = iota
|
|
|
|
|
|
|
|
// rescanPending indicates that a dispatch has already been made, and we
|
|
|
|
// are waiting for its completion. No other rescans should be dispatched
|
|
|
|
// while in this state.
|
|
|
|
rescanPending
|
|
|
|
|
|
|
|
// rescanComplete signals either that a rescan was dispatched and has
|
|
|
|
// completed, or that we began watching at tip immediately. In either
|
|
|
|
// case, the notifier can only dispatch notifications from tip when in
|
|
|
|
// this state.
|
|
|
|
rescanComplete
|
|
|
|
)
|
|
|
|
|
|
|
|
// confNtfnSet holds all known, registered confirmation notifications for a
|
2018-12-07 08:13:38 +03:00
|
|
|
// txid/output script. If duplicates notifications are requested, only one
|
|
|
|
// historical dispatch will be spawned to ensure redundant scans are not
|
|
|
|
// permitted. A single conf detail will be constructed and dispatched to all
|
|
|
|
// interested
|
2018-10-10 02:24:30 +03:00
|
|
|
// clients.
|
|
|
|
type confNtfnSet struct {
|
|
|
|
// ntfns keeps tracks of all the active client notification requests for
|
2018-12-07 08:13:38 +03:00
|
|
|
// a transaction/output script
|
2018-10-10 02:24:30 +03:00
|
|
|
ntfns map[uint64]*ConfNtfn
|
|
|
|
|
2018-12-07 08:13:38 +03:00
|
|
|
// rescanStatus represents the current rescan state for the
|
|
|
|
// transaction/output script.
|
2018-10-10 02:24:30 +03:00
|
|
|
rescanStatus rescanState
|
|
|
|
|
|
|
|
// details serves as a cache of the confirmation details of a
|
2018-12-07 08:13:38 +03:00
|
|
|
// transaction that we'll use to determine if a transaction/output
|
|
|
|
// script has already confirmed at the time of registration.
|
2018-10-10 02:24:30 +03:00
|
|
|
details *TxConfirmation
|
|
|
|
}
|
|
|
|
|
|
|
|
// newConfNtfnSet constructs a fresh confNtfnSet for a group of clients
|
|
|
|
// interested in a notification for a particular txid.
|
|
|
|
func newConfNtfnSet() *confNtfnSet {
|
|
|
|
return &confNtfnSet{
|
|
|
|
ntfns: make(map[uint64]*ConfNtfn),
|
|
|
|
rescanStatus: rescanNotStarted,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:41 +03:00
|
|
|
// spendNtfnSet holds all known, registered spend notifications for a spend
|
|
|
|
// request (outpoint/output script). If duplicate notifications are requested,
|
|
|
|
// only one historical dispatch will be spawned to ensure redundant scans are
|
|
|
|
// not permitted.
|
2018-10-05 12:07:55 +03:00
|
|
|
type spendNtfnSet struct {
|
|
|
|
// ntfns keeps tracks of all the active client notification requests for
|
2018-12-07 08:13:41 +03:00
|
|
|
// an outpoint/output script.
|
2018-10-05 12:07:55 +03:00
|
|
|
ntfns map[uint64]*SpendNtfn
|
|
|
|
|
2018-12-07 08:13:41 +03:00
|
|
|
// rescanStatus represents the current rescan state for the spend
|
|
|
|
// request (outpoint/output script).
|
2018-10-05 12:07:55 +03:00
|
|
|
rescanStatus rescanState
|
|
|
|
|
2018-12-07 08:13:41 +03:00
|
|
|
// details serves as a cache of the spend details for an outpoint/output
|
|
|
|
// script that we'll use to determine if it has already been spent at
|
|
|
|
// the time of registration.
|
2018-10-05 12:07:55 +03:00
|
|
|
details *SpendDetail
|
|
|
|
}
|
|
|
|
|
|
|
|
// newSpendNtfnSet constructs a new spend notification set.
|
|
|
|
func newSpendNtfnSet() *spendNtfnSet {
|
|
|
|
return &spendNtfnSet{
|
|
|
|
ntfns: make(map[uint64]*SpendNtfn),
|
|
|
|
rescanStatus: rescanNotStarted,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:32 +03:00
|
|
|
// ConfRequest encapsulates a request for a confirmation notification of either
|
|
|
|
// a txid or output script.
|
|
|
|
type ConfRequest struct {
|
|
|
|
// TxID is the hash of the transaction for which confirmation
|
|
|
|
// notifications are requested. If set to a zero hash, then a
|
|
|
|
// confirmation notification will be dispatched upon inclusion of the
|
|
|
|
// _script_, rather than the txid.
|
|
|
|
TxID chainhash.Hash
|
|
|
|
|
|
|
|
// PkScript is the public key script of an outpoint created in this
|
|
|
|
// transaction.
|
|
|
|
PkScript txscript.PkScript
|
|
|
|
}
|
|
|
|
|
|
|
|
// NewConfRequest creates a request for a confirmation notification of either a
|
|
|
|
// txid or output script. A nil txid or an allocated ZeroHash can be used to
|
|
|
|
// dispatch the confirmation notification on the script.
|
|
|
|
func NewConfRequest(txid *chainhash.Hash, pkScript []byte) (ConfRequest, error) {
|
|
|
|
var r ConfRequest
|
|
|
|
outputScript, err := txscript.ParsePkScript(pkScript)
|
|
|
|
if err != nil {
|
|
|
|
return r, err
|
|
|
|
}
|
|
|
|
|
|
|
|
// We'll only set a txid for which we'll dispatch a confirmation
|
|
|
|
// notification on this request if one was provided. Otherwise, we'll
|
|
|
|
// default to dispatching on the confirmation of the script instead.
|
|
|
|
if txid != nil {
|
|
|
|
r.TxID = *txid
|
|
|
|
}
|
|
|
|
r.PkScript = outputScript
|
|
|
|
|
|
|
|
return r, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// String returns the string representation of the ConfRequest.
|
|
|
|
func (r ConfRequest) String() string {
|
|
|
|
if r.TxID != ZeroHash {
|
|
|
|
return fmt.Sprintf("txid=%v", r.TxID)
|
|
|
|
}
|
|
|
|
return fmt.Sprintf("script=%v", r.PkScript)
|
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:35 +03:00
|
|
|
// ConfHintKey returns the key that will be used to index the confirmation
|
|
|
|
// request's hint within the height hint cache.
|
|
|
|
func (r ConfRequest) ConfHintKey() ([]byte, error) {
|
|
|
|
if r.TxID == ZeroHash {
|
|
|
|
return r.PkScript.Script(), nil
|
|
|
|
}
|
|
|
|
|
|
|
|
var txid bytes.Buffer
|
|
|
|
if err := channeldb.WriteElement(&txid, r.TxID); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
return txid.Bytes(), nil
|
|
|
|
}
|
|
|
|
|
2018-12-07 08:14:16 +03:00
|
|
|
// MatchesTx determines whether the given transaction satisfies the confirmation
|
|
|
|
// request. If the confirmation request is for a script, then we'll check all of
|
|
|
|
// the outputs of the transaction to determine if it matches. Otherwise, we'll
|
|
|
|
// match on the txid.
|
|
|
|
func (r ConfRequest) MatchesTx(tx *wire.MsgTx) bool {
|
2019-06-28 05:10:58 +03:00
|
|
|
scriptMatches := func() bool {
|
|
|
|
pkScript := r.PkScript.Script()
|
|
|
|
for _, txOut := range tx.TxOut {
|
|
|
|
if bytes.Equal(txOut.PkScript, pkScript) {
|
|
|
|
return true
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return false
|
2018-12-07 08:14:16 +03:00
|
|
|
}
|
|
|
|
|
2019-06-28 05:10:58 +03:00
|
|
|
if r.TxID != ZeroHash {
|
|
|
|
return r.TxID == tx.TxHash() && scriptMatches()
|
2018-12-07 08:14:16 +03:00
|
|
|
}
|
|
|
|
|
2019-06-28 05:10:58 +03:00
|
|
|
return scriptMatches()
|
2018-12-07 08:14:16 +03:00
|
|
|
}
|
|
|
|
|
2017-11-13 22:55:22 +03:00
|
|
|
// ConfNtfn represents a notifier client's request to receive a notification
|
2019-05-05 01:35:37 +03:00
|
|
|
// once the target transaction/output script gets sufficient confirmations. The
|
2018-12-07 08:13:38 +03:00
|
|
|
// client is asynchronously notified via the ConfirmationEvent channels.
|
2017-11-13 22:55:22 +03:00
|
|
|
type ConfNtfn struct {
|
2018-07-27 07:30:15 +03:00
|
|
|
// ConfID uniquely identifies the confirmation notification request for
|
2018-12-07 08:13:38 +03:00
|
|
|
// the specified transaction/output script.
|
2018-07-27 07:30:15 +03:00
|
|
|
ConfID uint64
|
|
|
|
|
2018-12-07 08:13:38 +03:00
|
|
|
// ConfRequest represents either the txid or script we should detect
|
|
|
|
// inclusion of within the chain.
|
|
|
|
ConfRequest
|
2018-09-29 02:32:53 +03:00
|
|
|
|
2017-11-13 22:55:22 +03:00
|
|
|
// NumConfirmations is the number of confirmations after which the
|
|
|
|
// notification is to be sent.
|
|
|
|
NumConfirmations uint32
|
|
|
|
|
|
|
|
// Event contains references to the channels that the notifications are to
|
|
|
|
// be sent over.
|
|
|
|
Event *ConfirmationEvent
|
|
|
|
|
2018-08-25 06:09:11 +03:00
|
|
|
// HeightHint is the minimum height in the chain that we expect to find
|
2018-09-29 02:36:47 +03:00
|
|
|
// this txid.
|
2018-08-25 06:09:11 +03:00
|
|
|
HeightHint uint32
|
|
|
|
|
2017-11-13 22:55:22 +03:00
|
|
|
// dispatched is false if the confirmed notification has not been sent yet.
|
|
|
|
dispatched bool
|
|
|
|
}
|
|
|
|
|
2018-09-29 02:24:19 +03:00
|
|
|
// HistoricalConfDispatch parameterizes a manual rescan for a particular
|
2018-12-07 08:13:38 +03:00
|
|
|
// transaction/output script. The parameters include the start and end block
|
2018-09-29 02:24:19 +03:00
|
|
|
// heights specifying the range of blocks to scan.
|
|
|
|
type HistoricalConfDispatch struct {
|
2018-12-07 08:13:38 +03:00
|
|
|
// ConfRequest represents either the txid or script we should detect
|
|
|
|
// inclusion of within the chain.
|
|
|
|
ConfRequest
|
2018-09-29 02:24:19 +03:00
|
|
|
|
|
|
|
// StartHeight specifies the block height at which to being the
|
|
|
|
// historical rescan.
|
|
|
|
StartHeight uint32
|
|
|
|
|
|
|
|
// EndHeight specifies the last block height (inclusive) that the
|
|
|
|
// historical scan should consider.
|
|
|
|
EndHeight uint32
|
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:32 +03:00
|
|
|
// SpendRequest encapsulates a request for a spend notification of either an
|
|
|
|
// outpoint or output script.
|
|
|
|
type SpendRequest struct {
|
|
|
|
// OutPoint is the outpoint for which a client has requested a spend
|
|
|
|
// notification for. If set to a zero outpoint, then a spend
|
|
|
|
// notification will be dispatched upon detecting the spend of the
|
|
|
|
// _script_, rather than the outpoint.
|
|
|
|
OutPoint wire.OutPoint
|
|
|
|
|
2018-12-07 08:13:41 +03:00
|
|
|
// PkScript is the script of the outpoint. If a zero outpoint is set,
|
|
|
|
// then this can be an arbitrary script.
|
2018-12-07 08:13:32 +03:00
|
|
|
PkScript txscript.PkScript
|
|
|
|
}
|
|
|
|
|
|
|
|
// NewSpendRequest creates a request for a spend notification of either an
|
|
|
|
// outpoint or output script. A nil outpoint or an allocated ZeroOutPoint can be
|
|
|
|
// used to dispatch the confirmation notification on the script.
|
|
|
|
func NewSpendRequest(op *wire.OutPoint, pkScript []byte) (SpendRequest, error) {
|
|
|
|
var r SpendRequest
|
|
|
|
outputScript, err := txscript.ParsePkScript(pkScript)
|
|
|
|
if err != nil {
|
|
|
|
return r, err
|
|
|
|
}
|
|
|
|
|
|
|
|
// We'll only set an outpoint for which we'll dispatch a spend
|
|
|
|
// notification on this request if one was provided. Otherwise, we'll
|
|
|
|
// default to dispatching on the spend of the script instead.
|
|
|
|
if op != nil {
|
|
|
|
r.OutPoint = *op
|
|
|
|
}
|
|
|
|
r.PkScript = outputScript
|
|
|
|
|
|
|
|
return r, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// String returns the string representation of the SpendRequest.
|
|
|
|
func (r SpendRequest) String() string {
|
|
|
|
if r.OutPoint != ZeroOutPoint {
|
|
|
|
return fmt.Sprintf("outpoint=%v", r.OutPoint)
|
|
|
|
}
|
|
|
|
return fmt.Sprintf("script=%v", r.PkScript)
|
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:35 +03:00
|
|
|
// SpendHintKey returns the key that will be used to index the spend request's
|
|
|
|
// hint within the height hint cache.
|
|
|
|
func (r SpendRequest) SpendHintKey() ([]byte, error) {
|
|
|
|
if r.OutPoint == ZeroOutPoint {
|
|
|
|
return r.PkScript.Script(), nil
|
|
|
|
}
|
|
|
|
|
|
|
|
var outpoint bytes.Buffer
|
|
|
|
err := channeldb.WriteElement(&outpoint, r.OutPoint)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
return outpoint.Bytes(), nil
|
|
|
|
}
|
|
|
|
|
2018-12-07 08:14:28 +03:00
|
|
|
// MatchesTx determines whether the given transaction satisfies the spend
|
|
|
|
// request. If the spend request is for an outpoint, then we'll check all of
|
|
|
|
// the outputs being spent by the inputs of the transaction to determine if it
|
|
|
|
// matches. Otherwise, we'll need to match on the output script being spent, so
|
|
|
|
// we'll recompute it for each input of the transaction to determine if it
|
|
|
|
// matches.
|
|
|
|
func (r SpendRequest) MatchesTx(tx *wire.MsgTx) (bool, uint32, error) {
|
|
|
|
if r.OutPoint != ZeroOutPoint {
|
|
|
|
for i, txIn := range tx.TxIn {
|
|
|
|
if txIn.PreviousOutPoint == r.OutPoint {
|
|
|
|
return true, uint32(i), nil
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return false, 0, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
for i, txIn := range tx.TxIn {
|
|
|
|
pkScript, err := txscript.ComputePkScript(
|
|
|
|
txIn.SignatureScript, txIn.Witness,
|
|
|
|
)
|
|
|
|
if err == txscript.ErrUnsupportedScriptType {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
if err != nil {
|
|
|
|
return false, 0, err
|
|
|
|
}
|
|
|
|
|
|
|
|
if bytes.Equal(pkScript.Script(), r.PkScript.Script()) {
|
|
|
|
return true, uint32(i), nil
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return false, 0, nil
|
|
|
|
}
|
|
|
|
|
2018-10-05 12:07:55 +03:00
|
|
|
// SpendNtfn represents a client's request to receive a notification once an
|
2018-12-07 08:13:41 +03:00
|
|
|
// outpoint/output script has been spent on-chain. The client is asynchronously
|
|
|
|
// notified via the SpendEvent channels.
|
2018-10-05 12:07:55 +03:00
|
|
|
type SpendNtfn struct {
|
|
|
|
// SpendID uniquely identies the spend notification request for the
|
2018-12-07 08:13:41 +03:00
|
|
|
// specified outpoint/output script.
|
2018-10-05 12:07:55 +03:00
|
|
|
SpendID uint64
|
|
|
|
|
2018-12-07 08:13:41 +03:00
|
|
|
// SpendRequest represents either the outpoint or script we should
|
|
|
|
// detect the spend of.
|
|
|
|
SpendRequest
|
2018-10-05 12:07:55 +03:00
|
|
|
|
|
|
|
// Event contains references to the channels that the notifications are
|
|
|
|
// to be sent over.
|
|
|
|
Event *SpendEvent
|
|
|
|
|
|
|
|
// HeightHint is the earliest height in the chain that we expect to find
|
2018-12-07 08:13:41 +03:00
|
|
|
// the spending transaction of the specified outpoint/output script.
|
|
|
|
// This value will be overridden by the spend hint cache if it contains
|
|
|
|
// an entry for it.
|
2018-10-05 12:07:55 +03:00
|
|
|
HeightHint uint32
|
|
|
|
|
|
|
|
// dispatched signals whether a spend notification has been disptached
|
|
|
|
// to the client.
|
|
|
|
dispatched bool
|
|
|
|
}
|
|
|
|
|
|
|
|
// HistoricalSpendDispatch parameterizes a manual rescan to determine the
|
2018-12-07 08:13:41 +03:00
|
|
|
// spending details (if any) of an outpoint/output script. The parameters
|
|
|
|
// include the start and end block heights specifying the range of blocks to
|
|
|
|
// scan.
|
2018-10-05 12:07:55 +03:00
|
|
|
type HistoricalSpendDispatch struct {
|
2018-12-07 08:13:41 +03:00
|
|
|
// SpendRequest represents either the outpoint or script we should
|
|
|
|
// detect the spend of.
|
|
|
|
SpendRequest
|
2018-10-05 12:07:55 +03:00
|
|
|
|
|
|
|
// StartHeight specified the block height at which to begin the
|
|
|
|
// historical rescan.
|
|
|
|
StartHeight uint32
|
|
|
|
|
|
|
|
// EndHeight specifies the last block height (inclusive) that the
|
|
|
|
// historical rescan should consider.
|
|
|
|
EndHeight uint32
|
2017-11-13 22:55:22 +03:00
|
|
|
}
|
|
|
|
|
2018-10-05 12:07:55 +03:00
|
|
|
// TxNotifier is a struct responsible for delivering transaction notifications
|
|
|
|
// to subscribers. These notifications can be of two different types:
|
2018-12-07 08:13:38 +03:00
|
|
|
// transaction/output script confirmations and/or outpoint/output script spends.
|
|
|
|
// The TxNotifier will watch the blockchain as new blocks come in, in order to
|
|
|
|
// satisfy its client requests.
|
2018-10-05 12:07:55 +03:00
|
|
|
type TxNotifier struct {
|
2017-11-13 22:55:22 +03:00
|
|
|
// currentHeight is the height of the tracked blockchain. It is used to
|
|
|
|
// determine the number of confirmations a tx has and ensure blocks are
|
|
|
|
// connected and disconnected in order.
|
|
|
|
currentHeight uint32
|
|
|
|
|
2018-10-05 12:07:55 +03:00
|
|
|
// reorgSafetyLimit is the chain depth beyond which it is assumed a
|
|
|
|
// block will not be reorganized out of the chain. This is used to
|
|
|
|
// determine when to prune old notification requests so that reorgs are
|
|
|
|
// handled correctly. The coinbase maturity period is a reasonable value
|
|
|
|
// to use.
|
2017-11-13 22:55:22 +03:00
|
|
|
reorgSafetyLimit uint32
|
|
|
|
|
2018-10-05 12:07:55 +03:00
|
|
|
// reorgDepth is the depth of a chain organization that this system is
|
|
|
|
// being informed of. This is incremented as long as a sequence of
|
|
|
|
// blocks are disconnected without being interrupted by a new block.
|
2017-11-14 04:32:11 +03:00
|
|
|
reorgDepth uint32
|
|
|
|
|
2018-12-07 08:13:38 +03:00
|
|
|
// confNotifications is an index of confirmation notification requests
|
|
|
|
// by transaction hash/output script.
|
|
|
|
confNotifications map[ConfRequest]*confNtfnSet
|
2017-11-13 22:55:22 +03:00
|
|
|
|
2018-12-07 08:13:38 +03:00
|
|
|
// confsByInitialHeight is an index of watched transactions/output
|
|
|
|
// scripts by the height that they are included at in the chain. This
|
|
|
|
// is tracked so that incorrect notifications are not sent if a
|
|
|
|
// transaction/output script is reorged out of the chain and so that
|
|
|
|
// negative confirmations can be recognized.
|
|
|
|
confsByInitialHeight map[uint32]map[ConfRequest]struct{}
|
2017-11-13 22:55:22 +03:00
|
|
|
|
2018-10-05 12:07:55 +03:00
|
|
|
// ntfnsByConfirmHeight is an index of notification requests by the
|
2018-12-07 08:13:38 +03:00
|
|
|
// height at which the transaction/output script will have sufficient
|
|
|
|
// confirmations.
|
2017-11-13 22:55:22 +03:00
|
|
|
ntfnsByConfirmHeight map[uint32]map[*ConfNtfn]struct{}
|
2017-12-05 00:30:33 +03:00
|
|
|
|
2018-10-05 12:07:55 +03:00
|
|
|
// spendNotifications is an index of all active notification requests
|
2018-12-07 08:13:41 +03:00
|
|
|
// per outpoint/output script.
|
|
|
|
spendNotifications map[SpendRequest]*spendNtfnSet
|
2018-10-05 12:07:55 +03:00
|
|
|
|
2018-12-07 08:13:41 +03:00
|
|
|
// spendsByHeight is an index that keeps tracks of the spending height
|
|
|
|
// of outpoints/output scripts we are currently tracking notifications
|
|
|
|
// for. This is used in order to recover from spending transactions
|
2018-10-05 12:07:55 +03:00
|
|
|
// being reorged out of the chain.
|
2018-12-07 08:13:41 +03:00
|
|
|
spendsByHeight map[uint32]map[SpendRequest]struct{}
|
2018-10-05 12:07:55 +03:00
|
|
|
|
|
|
|
// confirmHintCache is a cache used to maintain the latest height hints
|
2018-12-07 08:13:38 +03:00
|
|
|
// for transactions/output scripts. Each height hint represents the
|
|
|
|
// earliest height at which they scripts could have been confirmed
|
|
|
|
// within the chain.
|
2018-10-05 12:07:55 +03:00
|
|
|
confirmHintCache ConfirmHintCache
|
2018-05-22 22:55:32 +03:00
|
|
|
|
2018-10-05 12:07:55 +03:00
|
|
|
// spendHintCache is a cache used to maintain the latest height hints
|
2018-12-07 08:13:41 +03:00
|
|
|
// for outpoints/output scripts. Each height hint represents the
|
|
|
|
// earliest height at which they could have been spent within the chain.
|
2018-10-05 12:07:55 +03:00
|
|
|
spendHintCache SpendHintCache
|
|
|
|
|
2017-12-05 00:30:33 +03:00
|
|
|
// quit is closed in order to signal that the notifier is gracefully
|
|
|
|
// exiting.
|
|
|
|
quit chan struct{}
|
2018-07-27 07:31:32 +03:00
|
|
|
|
|
|
|
sync.Mutex
|
2017-11-13 22:55:22 +03:00
|
|
|
}
|
|
|
|
|
2018-10-05 12:07:55 +03:00
|
|
|
// NewTxNotifier creates a TxNotifier. The current height of the blockchain is
|
2018-10-05 12:07:55 +03:00
|
|
|
// accepted as a parameter. The different hint caches (confirm and spend) are
|
|
|
|
// used as an optimization in order to retrieve a better starting point when
|
|
|
|
// dispatching a recan for a historical event in the chain.
|
2018-10-05 12:07:55 +03:00
|
|
|
func NewTxNotifier(startHeight uint32, reorgSafetyLimit uint32,
|
2018-10-05 12:07:55 +03:00
|
|
|
confirmHintCache ConfirmHintCache,
|
|
|
|
spendHintCache SpendHintCache) *TxNotifier {
|
2018-05-22 22:55:32 +03:00
|
|
|
|
2018-10-05 12:07:55 +03:00
|
|
|
return &TxNotifier{
|
2018-03-19 22:04:19 +03:00
|
|
|
currentHeight: startHeight,
|
|
|
|
reorgSafetyLimit: reorgSafetyLimit,
|
2018-12-07 08:13:38 +03:00
|
|
|
confNotifications: make(map[ConfRequest]*confNtfnSet),
|
|
|
|
confsByInitialHeight: make(map[uint32]map[ConfRequest]struct{}),
|
2018-03-19 22:04:19 +03:00
|
|
|
ntfnsByConfirmHeight: make(map[uint32]map[*ConfNtfn]struct{}),
|
2018-12-07 08:13:41 +03:00
|
|
|
spendNotifications: make(map[SpendRequest]*spendNtfnSet),
|
|
|
|
spendsByHeight: make(map[uint32]map[SpendRequest]struct{}),
|
2018-10-05 12:07:55 +03:00
|
|
|
confirmHintCache: confirmHintCache,
|
2018-10-05 12:07:55 +03:00
|
|
|
spendHintCache: spendHintCache,
|
2018-03-19 22:04:19 +03:00
|
|
|
quit: make(chan struct{}),
|
2017-11-13 22:55:22 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:38 +03:00
|
|
|
// RegisterConf handles a new confirmation notification request. The client will
|
|
|
|
// be notified when the transaction/output script gets a sufficient number of
|
|
|
|
// confirmations in the blockchain. The registration succeeds if no error is
|
|
|
|
// returned. If the returned HistoricalConfDispatch is non-nil, the caller is
|
|
|
|
// responsible for attempting to manually rescan blocks for the txid/output
|
|
|
|
// script between the start and end heights. The notifier's current height is
|
|
|
|
// also returned so that backends can request to be notified of confirmations
|
|
|
|
// from this point forwards.
|
2018-07-27 07:31:32 +03:00
|
|
|
//
|
2018-12-07 08:13:38 +03:00
|
|
|
// NOTE: If the transaction/output script has already been included in a block
|
|
|
|
// on the chain, the confirmation details must be provided with the
|
|
|
|
// UpdateConfDetails method, otherwise we will wait for the transaction/output
|
|
|
|
// script to confirm even though it already has.
|
|
|
|
func (n *TxNotifier) RegisterConf(ntfn *ConfNtfn) (*HistoricalConfDispatch,
|
|
|
|
uint32, error) {
|
|
|
|
|
2017-12-05 00:30:33 +03:00
|
|
|
select {
|
2018-10-05 12:07:55 +03:00
|
|
|
case <-n.quit:
|
2018-12-07 08:13:38 +03:00
|
|
|
return nil, 0, ErrTxNotifierExiting
|
2017-12-05 00:30:33 +03:00
|
|
|
default:
|
|
|
|
}
|
|
|
|
|
2018-10-18 04:10:08 +03:00
|
|
|
// Enforce that we will not dispatch confirmations beyond the reorg
|
|
|
|
// safety limit.
|
2018-10-05 12:07:55 +03:00
|
|
|
if ntfn.NumConfirmations > n.reorgSafetyLimit {
|
2018-12-07 08:13:38 +03:00
|
|
|
return nil, 0, ErrTxMaxConfs
|
2018-10-18 04:10:08 +03:00
|
|
|
}
|
|
|
|
|
2018-08-25 06:09:11 +03:00
|
|
|
// Before proceeding to register the notification, we'll query our
|
|
|
|
// height hint cache to determine whether a better one exists.
|
2018-09-29 02:36:47 +03:00
|
|
|
//
|
|
|
|
// TODO(conner): verify that all submitted height hints are identical.
|
2018-09-29 02:36:47 +03:00
|
|
|
startHeight := ntfn.HeightHint
|
2018-12-07 08:13:38 +03:00
|
|
|
hint, err := n.confirmHintCache.QueryConfirmHint(ntfn.ConfRequest)
|
2018-08-25 06:09:11 +03:00
|
|
|
if err == nil {
|
2018-09-29 02:36:47 +03:00
|
|
|
if hint > startHeight {
|
2018-12-07 08:13:38 +03:00
|
|
|
Log.Debugf("Using height hint %d retrieved from cache "+
|
2019-03-20 04:37:28 +03:00
|
|
|
"for %v instead of %d", hint, ntfn.ConfRequest,
|
|
|
|
startHeight)
|
2018-09-29 02:36:47 +03:00
|
|
|
startHeight = hint
|
2018-08-25 06:09:11 +03:00
|
|
|
}
|
2018-09-29 23:55:30 +03:00
|
|
|
} else if err != ErrConfirmHintNotFound {
|
|
|
|
Log.Errorf("Unable to query confirm hint for %v: %v",
|
2018-12-07 08:13:38 +03:00
|
|
|
ntfn.ConfRequest, err)
|
2018-08-25 06:09:11 +03:00
|
|
|
}
|
|
|
|
|
2018-10-05 12:07:55 +03:00
|
|
|
n.Lock()
|
|
|
|
defer n.Unlock()
|
2018-07-27 07:31:32 +03:00
|
|
|
|
2019-03-20 04:37:28 +03:00
|
|
|
Log.Infof("New confirmation subscription: conf_id=%d, %v, "+
|
|
|
|
"height_hint=%d", ntfn.ConfID, ntfn.ConfRequest, startHeight)
|
|
|
|
|
2018-12-07 08:13:38 +03:00
|
|
|
confSet, ok := n.confNotifications[ntfn.ConfRequest]
|
2018-07-27 07:31:32 +03:00
|
|
|
if !ok {
|
2018-12-07 08:13:38 +03:00
|
|
|
// If this is the first registration for this request, construct
|
|
|
|
// a confSet to coalesce all notifications for the same request.
|
2018-08-25 05:29:55 +03:00
|
|
|
confSet = newConfNtfnSet()
|
2018-12-07 08:13:38 +03:00
|
|
|
n.confNotifications[ntfn.ConfRequest] = confSet
|
2018-08-25 05:29:55 +03:00
|
|
|
}
|
|
|
|
confSet.ntfns[ntfn.ConfID] = ntfn
|
|
|
|
|
|
|
|
switch confSet.rescanStatus {
|
|
|
|
|
|
|
|
// A prior rescan has already completed and we are actively watching at
|
2018-12-07 08:13:38 +03:00
|
|
|
// tip for this request.
|
2018-08-25 05:29:55 +03:00
|
|
|
case rescanComplete:
|
2018-12-07 08:13:38 +03:00
|
|
|
// If the confirmation details for this set of notifications has
|
|
|
|
// already been found, we'll attempt to deliver them immediately
|
|
|
|
// to this client.
|
|
|
|
Log.Debugf("Attempting to dispatch confirmation for %v on "+
|
|
|
|
"registration since rescan has finished",
|
|
|
|
ntfn.ConfRequest)
|
|
|
|
|
|
|
|
return nil, n.currentHeight, n.dispatchConfDetails(
|
|
|
|
ntfn, confSet.details,
|
|
|
|
)
|
2018-08-25 05:29:55 +03:00
|
|
|
|
|
|
|
// A rescan is already in progress, return here to prevent dispatching
|
2018-12-07 08:13:38 +03:00
|
|
|
// another. When the rescan returns, this notification's details will be
|
2018-08-25 05:29:55 +03:00
|
|
|
// updated as well.
|
|
|
|
case rescanPending:
|
2018-09-29 23:55:30 +03:00
|
|
|
Log.Debugf("Waiting for pending rescan to finish before "+
|
2018-12-07 08:13:38 +03:00
|
|
|
"notifying %v at tip", ntfn.ConfRequest)
|
|
|
|
|
|
|
|
return nil, n.currentHeight, nil
|
2018-08-25 05:29:55 +03:00
|
|
|
|
|
|
|
// If no rescan has been dispatched, attempt to do so now.
|
|
|
|
case rescanNotStarted:
|
2018-07-27 07:31:32 +03:00
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:38 +03:00
|
|
|
// If the provided or cached height hint indicates that the
|
|
|
|
// transaction with the given txid/output script is to be confirmed at a
|
|
|
|
// height greater than the notifier's current height, we'll refrain from
|
|
|
|
// spawning a historical dispatch.
|
2018-10-05 12:07:55 +03:00
|
|
|
if startHeight > n.currentHeight {
|
2018-12-07 08:13:38 +03:00
|
|
|
Log.Debugf("Height hint is above current height, not "+
|
|
|
|
"dispatching historical confirmation rescan for %v",
|
|
|
|
ntfn.ConfRequest)
|
|
|
|
|
|
|
|
// Set the rescan status to complete, which will allow the
|
2018-08-25 05:29:55 +03:00
|
|
|
// notifier to start delivering messages for this set
|
|
|
|
// immediately.
|
|
|
|
confSet.rescanStatus = rescanComplete
|
2018-12-07 08:13:38 +03:00
|
|
|
return nil, n.currentHeight, nil
|
2018-08-25 05:29:55 +03:00
|
|
|
}
|
2018-07-27 07:31:32 +03:00
|
|
|
|
2018-12-07 08:13:38 +03:00
|
|
|
Log.Debugf("Dispatching historical confirmation rescan for %v",
|
|
|
|
ntfn.ConfRequest)
|
2018-09-29 23:55:30 +03:00
|
|
|
|
2018-09-29 02:36:47 +03:00
|
|
|
// Construct the parameters for historical dispatch, scanning the range
|
|
|
|
// of blocks between our best known height hint and the notifier's
|
|
|
|
// current height. The notifier will begin also watching for
|
|
|
|
// confirmations at tip starting with the next block.
|
|
|
|
dispatch := &HistoricalConfDispatch{
|
2018-12-07 08:13:38 +03:00
|
|
|
ConfRequest: ntfn.ConfRequest,
|
2018-09-29 02:36:47 +03:00
|
|
|
StartHeight: startHeight,
|
2018-10-05 12:07:55 +03:00
|
|
|
EndHeight: n.currentHeight,
|
2018-09-29 02:36:47 +03:00
|
|
|
}
|
|
|
|
|
2018-08-25 05:29:55 +03:00
|
|
|
// Set this confSet's status to pending, ensuring subsequent
|
|
|
|
// registrations don't also attempt a dispatch.
|
|
|
|
confSet.rescanStatus = rescanPending
|
2018-09-29 02:36:47 +03:00
|
|
|
|
2018-12-07 08:13:38 +03:00
|
|
|
return dispatch, n.currentHeight, nil
|
2018-07-27 07:31:32 +03:00
|
|
|
}
|
|
|
|
|
2018-12-11 05:27:25 +03:00
|
|
|
// CancelConf cancels an existing request for a spend notification of an
|
|
|
|
// outpoint/output script. The request is identified by its spend ID.
|
|
|
|
func (n *TxNotifier) CancelConf(confRequest ConfRequest, confID uint64) {
|
|
|
|
select {
|
|
|
|
case <-n.quit:
|
|
|
|
return
|
|
|
|
default:
|
|
|
|
}
|
|
|
|
|
|
|
|
n.Lock()
|
|
|
|
defer n.Unlock()
|
|
|
|
|
|
|
|
confSet, ok := n.confNotifications[confRequest]
|
|
|
|
if !ok {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
ntfn, ok := confSet.ntfns[confID]
|
|
|
|
if !ok {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
Log.Infof("Canceling confirmation notification: conf_id=%d, %v", confID,
|
|
|
|
confRequest)
|
|
|
|
|
|
|
|
// We'll close all the notification channels to let the client know
|
|
|
|
// their cancel request has been fulfilled.
|
|
|
|
close(ntfn.Event.Confirmed)
|
|
|
|
close(ntfn.Event.Updates)
|
|
|
|
close(ntfn.Event.NegativeConf)
|
|
|
|
delete(confSet.ntfns, confID)
|
|
|
|
}
|
|
|
|
|
2018-07-27 07:31:32 +03:00
|
|
|
// UpdateConfDetails attempts to update the confirmation details for an active
|
|
|
|
// notification within the notifier. This should only be used in the case of a
|
2018-12-07 08:13:38 +03:00
|
|
|
// transaction/output script that has confirmed before the notifier's current
|
|
|
|
// height.
|
2018-07-27 07:31:32 +03:00
|
|
|
//
|
|
|
|
// NOTE: The notification should be registered first to ensure notifications are
|
|
|
|
// dispatched correctly.
|
2018-12-07 08:13:38 +03:00
|
|
|
func (n *TxNotifier) UpdateConfDetails(confRequest ConfRequest,
|
2018-09-29 02:38:08 +03:00
|
|
|
details *TxConfirmation) error {
|
2018-07-27 07:31:32 +03:00
|
|
|
|
|
|
|
select {
|
2018-10-05 12:07:55 +03:00
|
|
|
case <-n.quit:
|
|
|
|
return ErrTxNotifierExiting
|
2018-07-27 07:31:32 +03:00
|
|
|
default:
|
|
|
|
}
|
|
|
|
|
|
|
|
// Ensure we hold the lock throughout handling the notification to
|
|
|
|
// prevent the notifier from advancing its height underneath us.
|
2018-10-05 12:07:55 +03:00
|
|
|
n.Lock()
|
|
|
|
defer n.Unlock()
|
2018-07-27 07:31:32 +03:00
|
|
|
|
2018-12-07 08:13:38 +03:00
|
|
|
// First, we'll determine whether we have an active confirmation
|
|
|
|
// notification for the given txid/script.
|
|
|
|
confSet, ok := n.confNotifications[confRequest]
|
2018-07-27 07:31:32 +03:00
|
|
|
if !ok {
|
2018-12-07 08:13:38 +03:00
|
|
|
return fmt.Errorf("confirmation notification for %v not found",
|
|
|
|
confRequest)
|
2018-07-27 07:31:32 +03:00
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:38 +03:00
|
|
|
// If the confirmation details were already found at tip, all existing
|
2018-10-18 04:10:08 +03:00
|
|
|
// notifications will have been dispatched or queued for dispatch. We
|
|
|
|
// can exit early to avoid sending too many notifications on the
|
|
|
|
// buffered channels.
|
|
|
|
if confSet.details != nil {
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2018-08-25 05:29:55 +03:00
|
|
|
// The historical dispatch has been completed for this confSet. We'll
|
|
|
|
// update the rescan status and cache any details that were found. If
|
|
|
|
// the details are nil, that implies we did not find them and will
|
|
|
|
// continue to watch for them at tip.
|
|
|
|
confSet.rescanStatus = rescanComplete
|
2018-07-27 07:31:32 +03:00
|
|
|
|
2018-12-07 08:13:38 +03:00
|
|
|
// The notifier has yet to reach the height at which the
|
|
|
|
// transaction/output script was included in a block, so we should defer
|
|
|
|
// until handling it then within ConnectTip.
|
2018-09-29 23:55:30 +03:00
|
|
|
if details == nil {
|
2018-12-07 08:13:38 +03:00
|
|
|
Log.Debugf("Confirmation details for %v not found during "+
|
|
|
|
"historical dispatch, waiting to dispatch at tip",
|
|
|
|
confRequest)
|
2018-10-15 03:52:09 +03:00
|
|
|
|
|
|
|
// We'll commit the current height as the confirm hint to
|
|
|
|
// prevent another potentially long rescan if we restart before
|
|
|
|
// a new block comes in.
|
|
|
|
err := n.confirmHintCache.CommitConfirmHint(
|
2018-12-07 08:13:38 +03:00
|
|
|
n.currentHeight, confRequest,
|
2018-10-15 03:52:09 +03:00
|
|
|
)
|
|
|
|
if err != nil {
|
|
|
|
// The error is not fatal as this is an optimistic
|
|
|
|
// optimization, so we'll avoid returning an error.
|
|
|
|
Log.Debugf("Unable to update confirm hint to %d for "+
|
2018-12-07 08:13:38 +03:00
|
|
|
"%v: %v", n.currentHeight, confRequest, err)
|
2018-10-15 03:52:09 +03:00
|
|
|
}
|
|
|
|
|
2018-09-29 23:55:30 +03:00
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2018-10-05 12:07:55 +03:00
|
|
|
if details.BlockHeight > n.currentHeight {
|
2018-12-07 08:13:38 +03:00
|
|
|
Log.Debugf("Confirmation details for %v found above current "+
|
|
|
|
"height, waiting to dispatch at tip", confRequest)
|
|
|
|
|
2018-07-27 07:31:32 +03:00
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:38 +03:00
|
|
|
Log.Debugf("Updating confirmation details for %v", confRequest)
|
2018-09-29 23:55:30 +03:00
|
|
|
|
2018-12-07 08:13:38 +03:00
|
|
|
err := n.confirmHintCache.CommitConfirmHint(
|
|
|
|
details.BlockHeight, confRequest,
|
|
|
|
)
|
2018-05-22 22:55:32 +03:00
|
|
|
if err != nil {
|
|
|
|
// The error is not fatal, so we should not return an error to
|
|
|
|
// the caller.
|
|
|
|
Log.Errorf("Unable to update confirm hint to %d for %v: %v",
|
2018-12-07 08:13:38 +03:00
|
|
|
details.BlockHeight, confRequest, err)
|
2018-05-22 22:55:32 +03:00
|
|
|
}
|
|
|
|
|
2018-09-29 02:30:13 +03:00
|
|
|
// Cache the details found in the rescan and attempt to dispatch any
|
|
|
|
// notifications that have not yet been delivered.
|
|
|
|
confSet.details = details
|
2018-08-25 05:29:55 +03:00
|
|
|
for _, ntfn := range confSet.ntfns {
|
2018-10-05 12:07:55 +03:00
|
|
|
err = n.dispatchConfDetails(ntfn, details)
|
2018-09-29 02:30:13 +03:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// dispatchConfDetails attempts to cache and dispatch details to a particular
|
2018-12-07 08:13:38 +03:00
|
|
|
// client if the transaction/output script has sufficiently confirmed. If the
|
|
|
|
// provided details are nil, this method will be a no-op.
|
2018-10-05 12:07:55 +03:00
|
|
|
func (n *TxNotifier) dispatchConfDetails(
|
2018-09-29 02:30:13 +03:00
|
|
|
ntfn *ConfNtfn, details *TxConfirmation) error {
|
|
|
|
|
|
|
|
// If no details are provided, return early as we can't dispatch.
|
|
|
|
if details == nil {
|
2018-09-29 23:55:30 +03:00
|
|
|
Log.Debugf("Unable to dispatch %v, no details provided",
|
2018-12-07 08:13:38 +03:00
|
|
|
ntfn.ConfRequest)
|
|
|
|
|
2018-09-29 02:30:13 +03:00
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:38 +03:00
|
|
|
// Now, we'll examine whether the transaction/output script of this
|
|
|
|
// request has reached its required number of confirmations. If it has,
|
|
|
|
// we'll dispatch a confirmation notification to the caller.
|
2018-09-29 02:30:13 +03:00
|
|
|
confHeight := details.BlockHeight + ntfn.NumConfirmations - 1
|
2018-10-05 12:07:55 +03:00
|
|
|
if confHeight <= n.currentHeight {
|
2018-12-07 08:13:38 +03:00
|
|
|
Log.Infof("Dispatching %v confirmation notification for %v",
|
|
|
|
ntfn.NumConfirmations, ntfn.ConfRequest)
|
2018-09-29 02:30:13 +03:00
|
|
|
|
|
|
|
// We'll send a 0 value to the Updates channel,
|
2018-12-07 08:13:38 +03:00
|
|
|
// indicating that the transaction/output script has already
|
|
|
|
// been confirmed.
|
2018-09-29 02:30:13 +03:00
|
|
|
select {
|
|
|
|
case ntfn.Event.Updates <- 0:
|
2018-10-05 12:07:55 +03:00
|
|
|
case <-n.quit:
|
|
|
|
return ErrTxNotifierExiting
|
2018-03-19 22:22:44 +03:00
|
|
|
}
|
|
|
|
|
2018-09-29 02:30:13 +03:00
|
|
|
select {
|
|
|
|
case ntfn.Event.Confirmed <- details:
|
|
|
|
ntfn.dispatched = true
|
2018-10-05 12:07:55 +03:00
|
|
|
case <-n.quit:
|
|
|
|
return ErrTxNotifierExiting
|
2018-09-29 02:30:13 +03:00
|
|
|
}
|
|
|
|
} else {
|
2018-12-07 08:13:38 +03:00
|
|
|
Log.Debugf("Queueing %v confirmation notification for %v at tip ",
|
|
|
|
ntfn.NumConfirmations, ntfn.ConfRequest)
|
2018-09-29 23:55:30 +03:00
|
|
|
|
2018-09-29 02:30:13 +03:00
|
|
|
// Otherwise, we'll keep track of the notification
|
|
|
|
// request by the height at which we should dispatch the
|
|
|
|
// confirmation notification.
|
2018-10-05 12:07:55 +03:00
|
|
|
ntfnSet, exists := n.ntfnsByConfirmHeight[confHeight]
|
2018-09-29 02:30:13 +03:00
|
|
|
if !exists {
|
|
|
|
ntfnSet = make(map[*ConfNtfn]struct{})
|
2018-10-05 12:07:55 +03:00
|
|
|
n.ntfnsByConfirmHeight[confHeight] = ntfnSet
|
2018-03-19 22:22:44 +03:00
|
|
|
}
|
2018-09-29 02:30:13 +03:00
|
|
|
ntfnSet[ntfn] = struct{}{}
|
|
|
|
|
|
|
|
// We'll also send an update to the client of how many
|
2018-12-07 08:13:38 +03:00
|
|
|
// confirmations are left for the transaction/output script to
|
|
|
|
// be confirmed.
|
2018-10-05 12:07:55 +03:00
|
|
|
numConfsLeft := confHeight - n.currentHeight
|
2018-09-29 02:30:13 +03:00
|
|
|
select {
|
|
|
|
case ntfn.Event.Updates <- numConfsLeft:
|
2018-10-05 12:07:55 +03:00
|
|
|
case <-n.quit:
|
|
|
|
return ErrTxNotifierExiting
|
2018-09-29 02:30:13 +03:00
|
|
|
}
|
|
|
|
}
|
2017-11-13 22:55:22 +03:00
|
|
|
|
2018-12-07 08:13:38 +03:00
|
|
|
// As a final check, we'll also watch the transaction/output script if
|
|
|
|
// it's still possible for it to get reorged out of the chain.
|
|
|
|
reorgSafeHeight := details.BlockHeight + n.reorgSafetyLimit
|
2018-10-05 12:07:55 +03:00
|
|
|
if reorgSafeHeight > n.currentHeight {
|
2018-12-07 08:13:38 +03:00
|
|
|
txSet, exists := n.confsByInitialHeight[details.BlockHeight]
|
2018-09-29 02:30:13 +03:00
|
|
|
if !exists {
|
2018-12-07 08:13:38 +03:00
|
|
|
txSet = make(map[ConfRequest]struct{})
|
|
|
|
n.confsByInitialHeight[details.BlockHeight] = txSet
|
2018-03-19 22:04:19 +03:00
|
|
|
}
|
2018-12-07 08:13:38 +03:00
|
|
|
txSet[ntfn.ConfRequest] = struct{}{}
|
2017-11-13 22:55:22 +03:00
|
|
|
}
|
2017-12-05 00:30:33 +03:00
|
|
|
|
|
|
|
return nil
|
2017-11-13 22:55:22 +03:00
|
|
|
}
|
|
|
|
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
// RegisterSpend handles a new spend notification request. The client will be
|
2018-12-07 08:13:41 +03:00
|
|
|
// notified once the outpoint/output script is detected as spent within the
|
|
|
|
// chain.
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
//
|
|
|
|
// The registration succeeds if no error is returned. If the returned
|
|
|
|
// HistoricalSpendDisaptch is non-nil, the caller is responsible for attempting
|
2018-12-07 08:13:41 +03:00
|
|
|
// to determine whether the outpoint/output script has been spent between the
|
|
|
|
// start and end heights. The notifier's current height is also returned so that
|
|
|
|
// backends can request to be notified of spends from this point forwards.
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
//
|
2018-12-07 08:13:41 +03:00
|
|
|
// NOTE: If the outpoint/output script has already been spent within the chain
|
|
|
|
// before the notifier's current tip, the spend details must be provided with
|
|
|
|
// the UpdateSpendDetails method, otherwise we will wait for the outpoint/output
|
|
|
|
// script to be spent at tip, even though it already has.
|
|
|
|
func (n *TxNotifier) RegisterSpend(ntfn *SpendNtfn) (*HistoricalSpendDispatch,
|
|
|
|
uint32, error) {
|
|
|
|
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
select {
|
|
|
|
case <-n.quit:
|
2018-12-07 08:13:41 +03:00
|
|
|
return nil, 0, ErrTxNotifierExiting
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
default:
|
|
|
|
}
|
|
|
|
|
|
|
|
// Before proceeding to register the notification, we'll query our spend
|
|
|
|
// hint cache to determine whether a better one exists.
|
|
|
|
startHeight := ntfn.HeightHint
|
2018-12-07 08:13:41 +03:00
|
|
|
hint, err := n.spendHintCache.QuerySpendHint(ntfn.SpendRequest)
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
if err == nil {
|
|
|
|
if hint > startHeight {
|
|
|
|
Log.Debugf("Using height hint %d retrieved from cache "+
|
2019-03-20 04:37:28 +03:00
|
|
|
"for %v instead of %d", hint, ntfn.SpendRequest,
|
|
|
|
startHeight)
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
startHeight = hint
|
|
|
|
}
|
|
|
|
} else if err != ErrSpendHintNotFound {
|
|
|
|
Log.Errorf("Unable to query spend hint for %v: %v",
|
2018-12-07 08:13:41 +03:00
|
|
|
ntfn.SpendRequest, err)
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
n.Lock()
|
|
|
|
defer n.Unlock()
|
|
|
|
|
2018-12-07 08:13:41 +03:00
|
|
|
Log.Infof("New spend subscription: spend_id=%d, %v, height_hint=%d",
|
2019-03-20 04:37:28 +03:00
|
|
|
ntfn.SpendID, ntfn.SpendRequest, startHeight)
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
|
|
|
|
// Keep track of the notification request so that we can properly
|
|
|
|
// dispatch a spend notification later on.
|
2018-12-07 08:13:41 +03:00
|
|
|
spendSet, ok := n.spendNotifications[ntfn.SpendRequest]
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
if !ok {
|
2018-12-07 08:13:41 +03:00
|
|
|
// If this is the first registration for the request, we'll
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
// construct a spendNtfnSet to coalesce all notifications.
|
|
|
|
spendSet = newSpendNtfnSet()
|
2018-12-07 08:13:41 +03:00
|
|
|
n.spendNotifications[ntfn.SpendRequest] = spendSet
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
}
|
|
|
|
spendSet.ntfns[ntfn.SpendID] = ntfn
|
|
|
|
|
|
|
|
// We'll now let the caller know whether a historical rescan is needed
|
|
|
|
// depending on the current rescan status.
|
|
|
|
switch spendSet.rescanStatus {
|
|
|
|
|
2018-12-07 08:13:41 +03:00
|
|
|
// If the spending details for this request have already been determined
|
|
|
|
// and cached, then we can use them to immediately dispatch the spend
|
|
|
|
// notification to the client.
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
case rescanComplete:
|
2018-12-07 08:13:41 +03:00
|
|
|
Log.Debugf("Attempting to dispatch spend for %v on "+
|
|
|
|
"registration since rescan has finished",
|
|
|
|
ntfn.SpendRequest)
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
|
2018-12-07 08:13:41 +03:00
|
|
|
return nil, n.currentHeight, n.dispatchSpendDetails(
|
|
|
|
ntfn, spendSet.details,
|
|
|
|
)
|
|
|
|
|
|
|
|
// If there is an active rescan to determine whether the request has
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
// been spent, then we won't trigger another one.
|
|
|
|
case rescanPending:
|
2018-12-07 08:13:41 +03:00
|
|
|
Log.Debugf("Waiting for pending rescan to finish before "+
|
|
|
|
"notifying %v at tip", ntfn.SpendRequest)
|
|
|
|
|
|
|
|
return nil, n.currentHeight, nil
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
|
|
|
|
// Otherwise, we'll fall through and let the caller know that a rescan
|
2018-12-07 08:13:41 +03:00
|
|
|
// should be dispatched to determine whether the request has already
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
// been spent.
|
|
|
|
case rescanNotStarted:
|
|
|
|
}
|
|
|
|
|
|
|
|
// However, if the spend hint, either provided by the caller or
|
|
|
|
// retrieved from the cache, is found to be at a later height than the
|
|
|
|
// TxNotifier is aware of, then we'll refrain from dispatching a
|
|
|
|
// historical rescan and wait for the spend to come in at tip.
|
|
|
|
if startHeight > n.currentHeight {
|
|
|
|
Log.Debugf("Spend hint of %d for %v is above current height %d",
|
2018-12-07 08:13:41 +03:00
|
|
|
startHeight, ntfn.SpendRequest, n.currentHeight)
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
|
|
|
|
// We'll also set the rescan status as complete to ensure that
|
2018-12-07 08:13:41 +03:00
|
|
|
// spend hints for this request get updated upon
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
// connected/disconnected blocks.
|
|
|
|
spendSet.rescanStatus = rescanComplete
|
2018-12-07 08:13:41 +03:00
|
|
|
return nil, n.currentHeight, nil
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// We'll set the rescan status to pending to ensure subsequent
|
|
|
|
// notifications don't also attempt a historical dispatch.
|
|
|
|
spendSet.rescanStatus = rescanPending
|
|
|
|
|
2018-12-07 08:13:41 +03:00
|
|
|
Log.Debugf("Dispatching historical spend rescan for %v",
|
|
|
|
ntfn.SpendRequest)
|
|
|
|
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
return &HistoricalSpendDispatch{
|
2018-12-07 08:13:41 +03:00
|
|
|
SpendRequest: ntfn.SpendRequest,
|
|
|
|
StartHeight: startHeight,
|
|
|
|
EndHeight: n.currentHeight,
|
|
|
|
}, n.currentHeight, nil
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// CancelSpend cancels an existing request for a spend notification of an
|
2018-12-07 08:13:41 +03:00
|
|
|
// outpoint/output script. The request is identified by its spend ID.
|
|
|
|
func (n *TxNotifier) CancelSpend(spendRequest SpendRequest, spendID uint64) {
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
select {
|
|
|
|
case <-n.quit:
|
|
|
|
return
|
|
|
|
default:
|
|
|
|
}
|
|
|
|
|
|
|
|
n.Lock()
|
|
|
|
defer n.Unlock()
|
|
|
|
|
2018-12-07 08:13:41 +03:00
|
|
|
spendSet, ok := n.spendNotifications[spendRequest]
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
if !ok {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
ntfn, ok := spendSet.ntfns[spendID]
|
|
|
|
if !ok {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
2018-12-11 05:27:25 +03:00
|
|
|
Log.Infof("Canceling spend notification: spend_id=%d, %v", spendID,
|
|
|
|
spendRequest)
|
|
|
|
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
// We'll close all the notification channels to let the client know
|
|
|
|
// their cancel request has been fulfilled.
|
|
|
|
close(ntfn.Event.Spend)
|
|
|
|
close(ntfn.Event.Reorg)
|
2018-12-11 05:29:22 +03:00
|
|
|
close(ntfn.Event.Done)
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
delete(spendSet.ntfns, spendID)
|
|
|
|
}
|
|
|
|
|
|
|
|
// ProcessRelevantSpendTx processes a transaction provided externally. This will
|
|
|
|
// check whether the transaction is relevant to the notifier if it spends any
|
2018-12-07 08:13:56 +03:00
|
|
|
// outpoints/output scripts for which we currently have registered notifications
|
|
|
|
// for. If it is relevant, spend notifications will be dispatched to the caller.
|
|
|
|
func (n *TxNotifier) ProcessRelevantSpendTx(tx *btcutil.Tx,
|
|
|
|
blockHeight uint32) error {
|
|
|
|
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
select {
|
|
|
|
case <-n.quit:
|
|
|
|
return ErrTxNotifierExiting
|
|
|
|
default:
|
|
|
|
}
|
|
|
|
|
|
|
|
// Ensure we hold the lock throughout handling the notification to
|
|
|
|
// prevent the notifier from advancing its height underneath us.
|
|
|
|
n.Lock()
|
|
|
|
defer n.Unlock()
|
|
|
|
|
2018-12-07 08:13:56 +03:00
|
|
|
// We'll use a channel to coalesce all the spend requests that this
|
|
|
|
// transaction fulfills.
|
|
|
|
type spend struct {
|
|
|
|
request *SpendRequest
|
|
|
|
details *SpendDetail
|
|
|
|
}
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
|
2018-12-07 08:13:56 +03:00
|
|
|
// We'll set up the onSpend filter callback to gather all the fulfilled
|
|
|
|
// spends requests within this transaction.
|
|
|
|
var spends []spend
|
|
|
|
onSpend := func(request SpendRequest, details *SpendDetail) {
|
|
|
|
spends = append(spends, spend{&request, details})
|
|
|
|
}
|
|
|
|
n.filterTx(tx, nil, blockHeight, nil, onSpend)
|
|
|
|
|
|
|
|
// After the transaction has been filtered, we can finally dispatch
|
|
|
|
// notifications for each request.
|
|
|
|
for _, spend := range spends {
|
|
|
|
err := n.updateSpendDetails(*spend.request, spend.details)
|
|
|
|
if err != nil {
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// UpdateSpendDetails attempts to update the spend details for all active spend
|
2018-12-07 08:13:41 +03:00
|
|
|
// notification requests for an outpoint/output script. This method should be
|
|
|
|
// used once a historical scan of the chain has finished. If the historical scan
|
|
|
|
// did not find a spending transaction for it, the spend details may be nil.
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
//
|
2018-12-07 08:13:41 +03:00
|
|
|
// NOTE: A notification request for the outpoint/output script must be
|
|
|
|
// registered first to ensure notifications are delivered.
|
|
|
|
func (n *TxNotifier) UpdateSpendDetails(spendRequest SpendRequest,
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
details *SpendDetail) error {
|
|
|
|
|
|
|
|
select {
|
|
|
|
case <-n.quit:
|
|
|
|
return ErrTxNotifierExiting
|
|
|
|
default:
|
|
|
|
}
|
|
|
|
|
|
|
|
// Ensure we hold the lock throughout handling the notification to
|
|
|
|
// prevent the notifier from advancing its height underneath us.
|
|
|
|
n.Lock()
|
|
|
|
defer n.Unlock()
|
|
|
|
|
2018-12-07 08:13:41 +03:00
|
|
|
return n.updateSpendDetails(spendRequest, details)
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// updateSpendDetails attempts to update the spend details for all active spend
|
2018-12-07 08:13:41 +03:00
|
|
|
// notification requests for an outpoint/output script. This method should be
|
|
|
|
// used once a historical scan of the chain has finished. If the historical scan
|
|
|
|
// did not find a spending transaction for it, the spend details may be nil.
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
//
|
|
|
|
// NOTE: This method must be called with the TxNotifier's lock held.
|
2018-12-07 08:13:41 +03:00
|
|
|
func (n *TxNotifier) updateSpendDetails(spendRequest SpendRequest,
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
details *SpendDetail) error {
|
|
|
|
|
2018-12-07 08:13:41 +03:00
|
|
|
// Mark the ongoing historical rescan for this request as finished. This
|
|
|
|
// will allow us to update the spend hints for it at tip.
|
|
|
|
spendSet, ok := n.spendNotifications[spendRequest]
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
if !ok {
|
2018-12-07 08:13:41 +03:00
|
|
|
return fmt.Errorf("spend notification for %v not found",
|
|
|
|
spendRequest)
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// If the spend details have already been found either at tip, then the
|
|
|
|
// notifications should have already been dispatched, so we can exit
|
|
|
|
// early to prevent sending duplicate notifications.
|
|
|
|
if spendSet.details != nil {
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:41 +03:00
|
|
|
// Since the historical rescan has completed for this request, we'll
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
// mark its rescan status as complete in order to ensure that the
|
|
|
|
// TxNotifier can properly update its spend hints upon
|
|
|
|
// connected/disconnected blocks.
|
|
|
|
spendSet.rescanStatus = rescanComplete
|
|
|
|
|
|
|
|
// If the historical rescan was not able to find a spending transaction
|
2018-12-07 08:13:41 +03:00
|
|
|
// for this request, then we can track the spend at tip.
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
if details == nil {
|
2018-10-15 03:52:09 +03:00
|
|
|
// We'll commit the current height as the spend hint to prevent
|
|
|
|
// another potentially long rescan if we restart before a new
|
|
|
|
// block comes in.
|
2018-12-07 08:13:41 +03:00
|
|
|
err := n.spendHintCache.CommitSpendHint(
|
|
|
|
n.currentHeight, spendRequest,
|
|
|
|
)
|
2018-10-15 03:52:09 +03:00
|
|
|
if err != nil {
|
|
|
|
// The error is not fatal as this is an optimistic
|
|
|
|
// optimization, so we'll avoid returning an error.
|
|
|
|
Log.Debugf("Unable to update spend hint to %d for %v: %v",
|
2018-12-07 08:13:41 +03:00
|
|
|
n.currentHeight, spendRequest, err)
|
2018-10-15 03:52:09 +03:00
|
|
|
}
|
|
|
|
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// If the historical rescan found the spending transaction for this
|
2018-12-07 08:13:41 +03:00
|
|
|
// request, but it's at a later height than the notifier (this can
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
// happen due to latency with the backend during a reorg), then we'll
|
|
|
|
// defer handling the notification until the notifier has caught up to
|
|
|
|
// such height.
|
|
|
|
if uint32(details.SpendingHeight) > n.currentHeight {
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:41 +03:00
|
|
|
// Now that we've determined the request has been spent, we'll commit
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
// its spending height as its hint in the cache and dispatch
|
|
|
|
// notifications to all of its respective clients.
|
|
|
|
err := n.spendHintCache.CommitSpendHint(
|
2018-12-07 08:13:41 +03:00
|
|
|
uint32(details.SpendingHeight), spendRequest,
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
)
|
|
|
|
if err != nil {
|
|
|
|
// The error is not fatal as this is an optimistic optimization,
|
|
|
|
// so we'll avoid returning an error.
|
|
|
|
Log.Debugf("Unable to update spend hint to %d for %v: %v",
|
2018-12-07 08:13:41 +03:00
|
|
|
details.SpendingHeight, spendRequest, err)
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
spendSet.details = details
|
|
|
|
for _, ntfn := range spendSet.ntfns {
|
|
|
|
err := n.dispatchSpendDetails(ntfn, spendSet.details)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// dispatchSpendDetails dispatches a spend notification to the client.
|
|
|
|
//
|
|
|
|
// NOTE: This must be called with the TxNotifier's lock held.
|
|
|
|
func (n *TxNotifier) dispatchSpendDetails(ntfn *SpendNtfn, details *SpendDetail) error {
|
|
|
|
// If there are no spend details to dispatch or if the notification has
|
|
|
|
// already been dispatched, then we can skip dispatching to this client.
|
|
|
|
if details == nil || ntfn.dispatched {
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:41 +03:00
|
|
|
Log.Infof("Dispatching confirmed spend notification for %v at height=%d",
|
|
|
|
ntfn.SpendRequest, n.currentHeight)
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
|
|
|
|
select {
|
|
|
|
case ntfn.Event.Spend <- details:
|
|
|
|
ntfn.dispatched = true
|
|
|
|
case <-n.quit:
|
|
|
|
return ErrTxNotifierExiting
|
|
|
|
}
|
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2018-10-05 12:07:55 +03:00
|
|
|
// ConnectTip handles a new block extending the current chain. It will go
|
|
|
|
// through every transaction and determine if it is relevant to any of its
|
|
|
|
// clients. A transaction can be relevant in either of the following two ways:
|
|
|
|
//
|
2018-12-07 08:13:44 +03:00
|
|
|
// 1. One of the inputs in the transaction spends an outpoint/output script
|
|
|
|
// for which we currently have an active spend registration for.
|
2018-10-05 12:07:55 +03:00
|
|
|
//
|
2018-12-07 08:13:44 +03:00
|
|
|
// 2. The transaction has a txid or output script for which we currently have
|
|
|
|
// an active confirmation registration for.
|
2018-10-05 12:07:55 +03:00
|
|
|
//
|
|
|
|
// In the event that the transaction is relevant, a confirmation/spend
|
2018-10-12 03:29:58 +03:00
|
|
|
// notification will be queued for dispatch to the relevant clients.
|
2018-12-07 08:13:44 +03:00
|
|
|
// Confirmation notifications will only be dispatched for transactions/output
|
|
|
|
// scripts that have met the required number of confirmations required by the
|
|
|
|
// client.
|
2018-10-12 03:29:58 +03:00
|
|
|
//
|
|
|
|
// NOTE: In order to actually dispatch the relevant transaction notifications to
|
|
|
|
// clients, NotifyHeight must be called with the same block height in order to
|
|
|
|
// maintain correctness.
|
2018-10-05 12:07:55 +03:00
|
|
|
func (n *TxNotifier) ConnectTip(blockHash *chainhash.Hash, blockHeight uint32,
|
|
|
|
txns []*btcutil.Tx) error {
|
2017-11-13 22:55:22 +03:00
|
|
|
|
2017-12-05 00:30:33 +03:00
|
|
|
select {
|
2018-10-05 12:07:55 +03:00
|
|
|
case <-n.quit:
|
|
|
|
return ErrTxNotifierExiting
|
2017-12-05 00:30:33 +03:00
|
|
|
default:
|
|
|
|
}
|
|
|
|
|
2018-10-05 12:07:55 +03:00
|
|
|
n.Lock()
|
|
|
|
defer n.Unlock()
|
2018-07-27 07:31:32 +03:00
|
|
|
|
2018-10-05 12:07:55 +03:00
|
|
|
if blockHeight != n.currentHeight+1 {
|
2018-12-07 08:13:44 +03:00
|
|
|
return fmt.Errorf("received blocks out of order: "+
|
2017-11-13 22:55:22 +03:00
|
|
|
"current height=%d, new height=%d",
|
2018-10-05 12:07:55 +03:00
|
|
|
n.currentHeight, blockHeight)
|
2017-11-13 22:55:22 +03:00
|
|
|
}
|
2018-10-05 12:07:55 +03:00
|
|
|
n.currentHeight++
|
|
|
|
n.reorgDepth = 0
|
2017-11-13 22:55:22 +03:00
|
|
|
|
2018-10-05 12:07:55 +03:00
|
|
|
// First, we'll iterate over all the transactions found in this block to
|
|
|
|
// determine if it includes any relevant transactions to the TxNotifier.
|
2017-11-13 22:55:22 +03:00
|
|
|
for _, tx := range txns {
|
2018-12-07 08:13:44 +03:00
|
|
|
n.filterTx(
|
|
|
|
tx, blockHash, blockHeight, n.handleConfDetailsAtTip,
|
|
|
|
n.handleSpendDetailsAtTip,
|
|
|
|
)
|
|
|
|
}
|
2018-09-29 23:53:24 +03:00
|
|
|
|
2018-12-11 05:28:26 +03:00
|
|
|
// Now that we've determined which requests were confirmed and spent
|
|
|
|
// within the new block, we can update their entries in their respective
|
|
|
|
// caches, along with all of our unconfirmed and unspent requests.
|
2018-12-07 08:13:44 +03:00
|
|
|
n.updateHints(blockHeight)
|
2018-10-05 12:07:55 +03:00
|
|
|
|
2018-12-11 05:28:26 +03:00
|
|
|
// Finally, we'll clear the entries from our set of notifications for
|
|
|
|
// requests that are no longer under the risk of being reorged out of
|
|
|
|
// the chain.
|
|
|
|
if blockHeight >= n.reorgSafetyLimit {
|
|
|
|
matureBlockHeight := blockHeight - n.reorgSafetyLimit
|
|
|
|
for confRequest := range n.confsByInitialHeight[matureBlockHeight] {
|
|
|
|
confSet := n.confNotifications[confRequest]
|
|
|
|
for _, ntfn := range confSet.ntfns {
|
|
|
|
select {
|
|
|
|
case ntfn.Event.Done <- struct{}{}:
|
|
|
|
case <-n.quit:
|
|
|
|
return ErrTxNotifierExiting
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
delete(n.confNotifications, confRequest)
|
|
|
|
}
|
|
|
|
delete(n.confsByInitialHeight, matureBlockHeight)
|
|
|
|
|
|
|
|
for spendRequest := range n.spendsByHeight[matureBlockHeight] {
|
|
|
|
spendSet := n.spendNotifications[spendRequest]
|
|
|
|
for _, ntfn := range spendSet.ntfns {
|
|
|
|
select {
|
|
|
|
case ntfn.Event.Done <- struct{}{}:
|
|
|
|
case <-n.quit:
|
|
|
|
return ErrTxNotifierExiting
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
delete(n.spendNotifications, spendRequest)
|
|
|
|
}
|
|
|
|
delete(n.spendsByHeight, matureBlockHeight)
|
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:44 +03:00
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// filterTx determines whether the transaction spends or confirms any
|
|
|
|
// outstanding pending requests. The onConf and onSpend callbacks can be used to
|
|
|
|
// retrieve all the requests fulfilled by this transaction as they occur.
|
|
|
|
func (n *TxNotifier) filterTx(tx *btcutil.Tx, blockHash *chainhash.Hash,
|
|
|
|
blockHeight uint32, onConf func(ConfRequest, *TxConfirmation),
|
|
|
|
onSpend func(SpendRequest, *SpendDetail)) {
|
|
|
|
|
|
|
|
// In order to determine if this transaction is relevant to the
|
|
|
|
// notifier, we'll check its inputs for any outstanding spend
|
|
|
|
// requests.
|
|
|
|
txHash := tx.Hash()
|
|
|
|
if onSpend != nil {
|
|
|
|
// notifyDetails is a helper closure that will construct the
|
|
|
|
// spend details of a request and hand them off to the onSpend
|
|
|
|
// callback.
|
|
|
|
notifyDetails := func(spendRequest SpendRequest,
|
|
|
|
prevOut wire.OutPoint, inputIdx uint32) {
|
|
|
|
|
|
|
|
Log.Debugf("Found spend of %v: spend_tx=%v, "+
|
|
|
|
"block_height=%d", spendRequest, txHash,
|
|
|
|
blockHeight)
|
|
|
|
|
|
|
|
onSpend(spendRequest, &SpendDetail{
|
2018-10-05 12:07:55 +03:00
|
|
|
SpentOutPoint: &prevOut,
|
|
|
|
SpenderTxHash: txHash,
|
|
|
|
SpendingTx: tx.MsgTx(),
|
2018-12-07 08:13:44 +03:00
|
|
|
SpenderInputIndex: inputIdx,
|
2018-10-05 12:07:55 +03:00
|
|
|
SpendingHeight: int32(blockHeight),
|
2018-12-07 08:13:44 +03:00
|
|
|
})
|
|
|
|
}
|
2018-10-05 12:07:55 +03:00
|
|
|
|
2018-12-07 08:13:44 +03:00
|
|
|
for i, txIn := range tx.MsgTx().TxIn {
|
|
|
|
// We'll re-derive the script of the output being spent
|
|
|
|
// to determine if the inputs spends any registered
|
|
|
|
// requests.
|
|
|
|
prevOut := txIn.PreviousOutPoint
|
|
|
|
pkScript, err := txscript.ComputePkScript(
|
|
|
|
txIn.SignatureScript, txIn.Witness,
|
|
|
|
)
|
|
|
|
if err != nil {
|
|
|
|
continue
|
2018-10-05 12:07:55 +03:00
|
|
|
}
|
2018-12-07 08:13:44 +03:00
|
|
|
spendRequest := SpendRequest{
|
|
|
|
OutPoint: prevOut,
|
|
|
|
PkScript: pkScript,
|
2018-10-05 12:07:55 +03:00
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:44 +03:00
|
|
|
// If we have any, we'll record their spend height so
|
|
|
|
// that notifications get dispatched to the respective
|
|
|
|
// clients.
|
|
|
|
if _, ok := n.spendNotifications[spendRequest]; ok {
|
|
|
|
notifyDetails(spendRequest, prevOut, uint32(i))
|
|
|
|
}
|
|
|
|
spendRequest.OutPoint = ZeroOutPoint
|
|
|
|
if _, ok := n.spendNotifications[spendRequest]; ok {
|
|
|
|
notifyDetails(spendRequest, prevOut, uint32(i))
|
|
|
|
}
|
2018-08-25 05:29:55 +03:00
|
|
|
}
|
2018-12-07 08:13:44 +03:00
|
|
|
}
|
2018-08-25 05:29:55 +03:00
|
|
|
|
2018-12-07 08:13:44 +03:00
|
|
|
// We'll also check its outputs to determine if there are any
|
|
|
|
// outstanding confirmation requests.
|
|
|
|
if onConf != nil {
|
|
|
|
// notifyDetails is a helper closure that will construct the
|
|
|
|
// confirmation details of a request and hand them off to the
|
|
|
|
// onConf callback.
|
|
|
|
notifyDetails := func(confRequest ConfRequest) {
|
|
|
|
Log.Debugf("Found initial confirmation of %v: "+
|
|
|
|
"height=%d, hash=%v", confRequest,
|
|
|
|
blockHeight, blockHash)
|
|
|
|
|
|
|
|
details := &TxConfirmation{
|
2018-12-11 05:24:04 +03:00
|
|
|
Tx: tx.MsgTx(),
|
2018-12-07 08:13:44 +03:00
|
|
|
BlockHash: blockHash,
|
|
|
|
BlockHeight: blockHeight,
|
|
|
|
TxIndex: uint32(tx.Index()),
|
|
|
|
}
|
2018-09-29 23:53:24 +03:00
|
|
|
|
2018-12-07 08:13:44 +03:00
|
|
|
onConf(confRequest, details)
|
2018-09-29 23:53:24 +03:00
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:44 +03:00
|
|
|
for _, txOut := range tx.MsgTx().TxOut {
|
|
|
|
// We'll parse the script of the output to determine if
|
|
|
|
// we have any registered requests for it or the
|
|
|
|
// transaction itself.
|
|
|
|
pkScript, err := txscript.ParsePkScript(txOut.PkScript)
|
|
|
|
if err != nil {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
confRequest := ConfRequest{
|
|
|
|
TxID: *txHash,
|
|
|
|
PkScript: pkScript,
|
2018-10-03 23:43:44 +03:00
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:44 +03:00
|
|
|
// If we have any, we'll record their confirmed height
|
|
|
|
// so that notifications get dispatched when they
|
|
|
|
// reaches the clients' desired number of confirmations.
|
|
|
|
if _, ok := n.confNotifications[confRequest]; ok {
|
|
|
|
notifyDetails(confRequest)
|
2017-11-13 22:55:22 +03:00
|
|
|
}
|
2018-12-07 08:13:44 +03:00
|
|
|
confRequest.TxID = ZeroHash
|
|
|
|
if _, ok := n.confNotifications[confRequest]; ok {
|
|
|
|
notifyDetails(confRequest)
|
2018-03-19 22:04:19 +03:00
|
|
|
}
|
2017-11-13 22:55:22 +03:00
|
|
|
}
|
|
|
|
}
|
2018-12-07 08:13:44 +03:00
|
|
|
}
|
2017-11-13 22:55:22 +03:00
|
|
|
|
2018-12-07 08:13:44 +03:00
|
|
|
// handleConfDetailsAtTip tracks the confirmation height of the txid/output
|
|
|
|
// script in order to properly dispatch a confirmation notification after
|
|
|
|
// meeting each request's desired number of confirmations for all current and
|
|
|
|
// future registered clients.
|
|
|
|
func (n *TxNotifier) handleConfDetailsAtTip(confRequest ConfRequest,
|
|
|
|
details *TxConfirmation) {
|
2018-05-22 22:55:32 +03:00
|
|
|
|
2018-12-07 08:13:44 +03:00
|
|
|
// TODO(wilmer): cancel pending historical rescans if any?
|
|
|
|
confSet := n.confNotifications[confRequest]
|
|
|
|
confSet.rescanStatus = rescanComplete
|
|
|
|
confSet.details = details
|
|
|
|
|
|
|
|
for _, ntfn := range confSet.ntfns {
|
|
|
|
// In the event that this notification was aware that the
|
|
|
|
// transaction/output script was reorged out of the chain, we'll
|
|
|
|
// consume the reorg notification if it hasn't been done yet
|
|
|
|
// already.
|
|
|
|
select {
|
|
|
|
case <-ntfn.Event.NegativeConf:
|
|
|
|
default:
|
|
|
|
}
|
|
|
|
|
|
|
|
// We'll note this client's required number of confirmations so
|
|
|
|
// that we can notify them when expected.
|
|
|
|
confHeight := details.BlockHeight + ntfn.NumConfirmations - 1
|
|
|
|
ntfnSet, exists := n.ntfnsByConfirmHeight[confHeight]
|
|
|
|
if !exists {
|
|
|
|
ntfnSet = make(map[*ConfNtfn]struct{})
|
|
|
|
n.ntfnsByConfirmHeight[confHeight] = ntfnSet
|
|
|
|
}
|
|
|
|
ntfnSet[ntfn] = struct{}{}
|
|
|
|
}
|
|
|
|
|
|
|
|
// We'll also note the initial confirmation height in order to correctly
|
|
|
|
// handle dispatching notifications when the transaction/output script
|
|
|
|
// gets reorged out of the chain.
|
|
|
|
txSet, exists := n.confsByInitialHeight[details.BlockHeight]
|
|
|
|
if !exists {
|
|
|
|
txSet = make(map[ConfRequest]struct{})
|
|
|
|
n.confsByInitialHeight[details.BlockHeight] = txSet
|
|
|
|
}
|
|
|
|
txSet[confRequest] = struct{}{}
|
|
|
|
}
|
|
|
|
|
|
|
|
// handleSpendDetailsAtTip tracks the spend height of the outpoint/output script
|
|
|
|
// in order to properly dispatch a spend notification for all current and future
|
|
|
|
// registered clients.
|
|
|
|
func (n *TxNotifier) handleSpendDetailsAtTip(spendRequest SpendRequest,
|
|
|
|
details *SpendDetail) {
|
|
|
|
|
|
|
|
// TODO(wilmer): cancel pending historical rescans if any?
|
|
|
|
spendSet := n.spendNotifications[spendRequest]
|
|
|
|
spendSet.rescanStatus = rescanComplete
|
|
|
|
spendSet.details = details
|
|
|
|
|
|
|
|
for _, ntfn := range spendSet.ntfns {
|
|
|
|
// In the event that this notification was aware that the
|
|
|
|
// spending transaction of its outpoint/output script was
|
|
|
|
// reorged out of the chain, we'll consume the reorg
|
|
|
|
// notification if it hasn't been done yet already.
|
|
|
|
select {
|
|
|
|
case <-ntfn.Event.Reorg:
|
|
|
|
default:
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// We'll note the spending height of the request in order to correctly
|
|
|
|
// handle dispatching notifications when the spending transactions gets
|
|
|
|
// reorged out of the chain.
|
|
|
|
spendHeight := uint32(details.SpendingHeight)
|
|
|
|
opSet, exists := n.spendsByHeight[spendHeight]
|
|
|
|
if !exists {
|
|
|
|
opSet = make(map[SpendRequest]struct{})
|
|
|
|
n.spendsByHeight[spendHeight] = opSet
|
|
|
|
}
|
|
|
|
opSet[spendRequest] = struct{}{}
|
2018-10-12 03:29:58 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// NotifyHeight dispatches confirmation and spend notifications to the clients
|
|
|
|
// who registered for a notification which has been fulfilled at the passed
|
|
|
|
// height.
|
|
|
|
func (n *TxNotifier) NotifyHeight(height uint32) error {
|
|
|
|
n.Lock()
|
|
|
|
defer n.Unlock()
|
|
|
|
|
|
|
|
// First, we'll dispatch an update to all of the notification clients
|
2018-12-07 08:13:47 +03:00
|
|
|
// for our watched requests with the number of confirmations left at
|
2018-03-19 22:22:44 +03:00
|
|
|
// this new height.
|
2018-12-07 08:13:47 +03:00
|
|
|
for _, confRequests := range n.confsByInitialHeight {
|
|
|
|
for confRequest := range confRequests {
|
|
|
|
confSet := n.confNotifications[confRequest]
|
2018-08-25 05:29:55 +03:00
|
|
|
for _, ntfn := range confSet.ntfns {
|
2018-09-29 23:55:30 +03:00
|
|
|
txConfHeight := confSet.details.BlockHeight +
|
2018-03-19 22:22:44 +03:00
|
|
|
ntfn.NumConfirmations - 1
|
2018-10-12 03:29:58 +03:00
|
|
|
numConfsLeft := txConfHeight - height
|
2018-03-19 22:22:44 +03:00
|
|
|
|
|
|
|
// Since we don't clear notifications until
|
2018-12-07 08:13:47 +03:00
|
|
|
// transactions/output scripts are no longer
|
|
|
|
// under the risk of being reorganized out of
|
|
|
|
// the chain, we'll skip sending updates for
|
|
|
|
// those that have already been confirmed.
|
2018-03-19 22:22:44 +03:00
|
|
|
if int32(numConfsLeft) < 0 {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
|
|
|
select {
|
|
|
|
case ntfn.Event.Updates <- numConfsLeft:
|
2018-10-05 12:07:55 +03:00
|
|
|
case <-n.quit:
|
|
|
|
return ErrTxNotifierExiting
|
2018-03-19 22:22:44 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:47 +03:00
|
|
|
// Then, we'll dispatch notifications for all the requests that have
|
2018-03-19 22:22:44 +03:00
|
|
|
// become confirmed at this new block height.
|
2018-10-12 03:29:58 +03:00
|
|
|
for ntfn := range n.ntfnsByConfirmHeight[height] {
|
2018-12-07 08:13:47 +03:00
|
|
|
confSet := n.confNotifications[ntfn.ConfRequest]
|
2018-10-18 04:10:08 +03:00
|
|
|
|
2018-12-07 08:13:47 +03:00
|
|
|
Log.Infof("Dispatching %v confirmation notification for %v",
|
|
|
|
ntfn.NumConfirmations, ntfn.ConfRequest)
|
2018-07-27 07:27:27 +03:00
|
|
|
|
2017-12-05 00:30:33 +03:00
|
|
|
select {
|
2018-10-18 04:10:08 +03:00
|
|
|
case ntfn.Event.Confirmed <- confSet.details:
|
2017-12-05 00:30:33 +03:00
|
|
|
ntfn.dispatched = true
|
2018-10-05 12:07:55 +03:00
|
|
|
case <-n.quit:
|
|
|
|
return ErrTxNotifierExiting
|
2017-12-05 00:30:33 +03:00
|
|
|
}
|
2017-11-13 22:55:22 +03:00
|
|
|
}
|
2018-10-12 03:29:58 +03:00
|
|
|
delete(n.ntfnsByConfirmHeight, height)
|
2018-10-05 12:07:55 +03:00
|
|
|
|
2018-12-11 05:28:26 +03:00
|
|
|
// Finally, we'll dispatch spend notifications for all the requests that
|
2018-10-05 12:07:55 +03:00
|
|
|
// were spent at this new block height.
|
2018-12-07 08:13:47 +03:00
|
|
|
for spendRequest := range n.spendsByHeight[height] {
|
|
|
|
spendSet := n.spendNotifications[spendRequest]
|
2018-10-05 12:07:55 +03:00
|
|
|
for _, ntfn := range spendSet.ntfns {
|
|
|
|
err := n.dispatchSpendDetails(ntfn, spendSet.details)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-11-13 22:55:22 +03:00
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// DisconnectTip handles the tip of the current chain being disconnected during
|
2018-12-07 08:13:50 +03:00
|
|
|
// a chain reorganization. If any watched requests were included in this block,
|
|
|
|
// internal structures are updated to ensure confirmation/spend notifications
|
|
|
|
// are consumed (if not already), and reorg notifications are dispatched
|
|
|
|
// instead. Confirmation/spend notifications will be dispatched again upon block
|
|
|
|
// inclusion.
|
2018-10-05 12:07:55 +03:00
|
|
|
func (n *TxNotifier) DisconnectTip(blockHeight uint32) error {
|
2017-12-05 00:30:33 +03:00
|
|
|
select {
|
2018-10-05 12:07:55 +03:00
|
|
|
case <-n.quit:
|
|
|
|
return ErrTxNotifierExiting
|
2017-12-05 00:30:33 +03:00
|
|
|
default:
|
|
|
|
}
|
|
|
|
|
2018-10-05 12:07:55 +03:00
|
|
|
n.Lock()
|
|
|
|
defer n.Unlock()
|
2018-07-27 07:31:32 +03:00
|
|
|
|
2018-10-05 12:07:55 +03:00
|
|
|
if blockHeight != n.currentHeight {
|
2017-11-13 22:55:22 +03:00
|
|
|
return fmt.Errorf("Received blocks out of order: "+
|
|
|
|
"current height=%d, disconnected height=%d",
|
2018-10-05 12:07:55 +03:00
|
|
|
n.currentHeight, blockHeight)
|
2017-11-13 22:55:22 +03:00
|
|
|
}
|
2018-10-05 12:07:55 +03:00
|
|
|
n.currentHeight--
|
|
|
|
n.reorgDepth++
|
2017-11-13 22:55:22 +03:00
|
|
|
|
2018-10-05 12:07:55 +03:00
|
|
|
// With the block disconnected, we'll update the confirm and spend hints
|
2018-12-07 08:13:50 +03:00
|
|
|
// for our notification requests to reflect the new height, except for
|
|
|
|
// those that have confirmed/spent at previous heights.
|
2018-10-05 12:07:55 +03:00
|
|
|
n.updateHints(blockHeight)
|
2018-08-25 03:58:02 +03:00
|
|
|
|
2018-12-07 08:13:50 +03:00
|
|
|
// We'll go through all of our watched confirmation requests and attempt
|
|
|
|
// to drain their notification channels to ensure sending notifications
|
|
|
|
// to the clients is always non-blocking.
|
|
|
|
for initialHeight, txHashes := range n.confsByInitialHeight {
|
2018-03-19 22:22:44 +03:00
|
|
|
for txHash := range txHashes {
|
2018-12-07 08:13:50 +03:00
|
|
|
// If the transaction/output script has been reorged out
|
|
|
|
// of the chain, we'll make sure to remove the cached
|
|
|
|
// confirmation details to prevent notifying clients
|
|
|
|
// with old information.
|
2018-10-05 12:07:55 +03:00
|
|
|
confSet := n.confNotifications[txHash]
|
2018-10-03 23:47:26 +03:00
|
|
|
if initialHeight == blockHeight {
|
|
|
|
confSet.details = nil
|
|
|
|
}
|
|
|
|
|
2018-08-25 05:29:55 +03:00
|
|
|
for _, ntfn := range confSet.ntfns {
|
2018-03-19 22:22:44 +03:00
|
|
|
// First, we'll attempt to drain an update
|
|
|
|
// from each notification to ensure sends to the
|
|
|
|
// Updates channel are always non-blocking.
|
2017-11-14 04:32:11 +03:00
|
|
|
select {
|
2018-03-19 22:22:44 +03:00
|
|
|
case <-ntfn.Event.Updates:
|
2018-10-05 12:07:55 +03:00
|
|
|
case <-n.quit:
|
|
|
|
return ErrTxNotifierExiting
|
2018-03-19 22:22:44 +03:00
|
|
|
default:
|
2017-11-14 04:32:11 +03:00
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:50 +03:00
|
|
|
// Then, we'll check if the current
|
|
|
|
// transaction/output script was included in the
|
|
|
|
// block currently being disconnected. If it
|
|
|
|
// was, we'll need to dispatch a reorg
|
|
|
|
// notification to the client.
|
2018-03-19 22:22:44 +03:00
|
|
|
if initialHeight == blockHeight {
|
2018-10-05 12:07:55 +03:00
|
|
|
err := n.dispatchConfReorg(
|
2018-10-03 23:51:05 +03:00
|
|
|
ntfn, blockHeight,
|
|
|
|
)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
2018-03-19 22:22:44 +03:00
|
|
|
}
|
|
|
|
}
|
2017-11-13 22:55:22 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2018-03-19 22:04:19 +03:00
|
|
|
|
2018-12-07 08:13:50 +03:00
|
|
|
// We'll also go through our watched spend requests and attempt to drain
|
2018-10-05 12:07:55 +03:00
|
|
|
// their dispatched notifications to ensure dispatching notifications to
|
2018-12-07 08:13:50 +03:00
|
|
|
// clients later on is always non-blocking. We're only interested in
|
|
|
|
// requests whose spending transaction was included at the height being
|
2018-10-05 12:07:55 +03:00
|
|
|
// disconnected.
|
2018-12-07 08:13:50 +03:00
|
|
|
for op := range n.spendsByHeight[blockHeight] {
|
2018-10-05 12:07:55 +03:00
|
|
|
// Since the spending transaction is being reorged out of the
|
|
|
|
// chain, we'll need to clear out the spending details of the
|
2018-12-07 08:13:50 +03:00
|
|
|
// request.
|
2018-10-05 12:07:55 +03:00
|
|
|
spendSet := n.spendNotifications[op]
|
|
|
|
spendSet.details = nil
|
|
|
|
|
|
|
|
// For all requests which have had a spend notification
|
|
|
|
// dispatched, we'll attempt to drain it and send a reorg
|
|
|
|
// notification instead.
|
|
|
|
for _, ntfn := range spendSet.ntfns {
|
|
|
|
if err := n.dispatchSpendReorg(ntfn); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:50 +03:00
|
|
|
// Finally, we can remove the requests that were confirmed and/or spent
|
|
|
|
// at the height being disconnected. We'll still continue to track them
|
|
|
|
// until they have been confirmed/spent and are no longer under the risk
|
|
|
|
// of being reorged out of the chain again.
|
|
|
|
delete(n.confsByInitialHeight, blockHeight)
|
|
|
|
delete(n.spendsByHeight, blockHeight)
|
2017-11-13 22:55:22 +03:00
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2018-10-05 12:07:55 +03:00
|
|
|
// updateHints attempts to update the confirm and spend hints for all relevant
|
2018-12-07 08:13:53 +03:00
|
|
|
// requests respectively. The height parameter is used to determine which
|
|
|
|
// requests we should update based on whether a new block is being
|
|
|
|
// connected/disconnected.
|
2018-10-05 12:07:55 +03:00
|
|
|
//
|
|
|
|
// NOTE: This must be called with the TxNotifier's lock held and after its
|
|
|
|
// height has already been reflected by a block being connected/disconnected.
|
|
|
|
func (n *TxNotifier) updateHints(height uint32) {
|
|
|
|
// TODO(wilmer): update under one database transaction.
|
|
|
|
//
|
2018-12-07 08:13:53 +03:00
|
|
|
// To update the height hint for all the required confirmation requests
|
|
|
|
// under one database transaction, we'll gather the set of unconfirmed
|
|
|
|
// requests along with the ones that confirmed at the height being
|
2018-10-05 12:07:55 +03:00
|
|
|
// connected/disconnected.
|
2018-12-07 08:13:53 +03:00
|
|
|
confRequests := n.unconfirmedRequests()
|
|
|
|
for confRequest := range n.confsByInitialHeight[height] {
|
|
|
|
confRequests = append(confRequests, confRequest)
|
2018-10-05 12:07:55 +03:00
|
|
|
}
|
|
|
|
err := n.confirmHintCache.CommitConfirmHint(
|
2018-12-07 08:13:53 +03:00
|
|
|
n.currentHeight, confRequests...,
|
2018-10-05 12:07:55 +03:00
|
|
|
)
|
|
|
|
if err != nil {
|
|
|
|
// The error is not fatal as this is an optimistic optimization,
|
|
|
|
// so we'll avoid returning an error.
|
|
|
|
Log.Debugf("Unable to update confirm hints to %d for "+
|
2018-12-07 08:13:53 +03:00
|
|
|
"%v: %v", n.currentHeight, confRequests, err)
|
2018-10-05 12:07:55 +03:00
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:53 +03:00
|
|
|
// Similarly, to update the height hint for all the required spend
|
|
|
|
// requests under one database transaction, we'll gather the set of
|
|
|
|
// unspent requests along with the ones that were spent at the height
|
|
|
|
// being connected/disconnected.
|
|
|
|
spendRequests := n.unspentRequests()
|
|
|
|
for spendRequest := range n.spendsByHeight[height] {
|
|
|
|
spendRequests = append(spendRequests, spendRequest)
|
2018-10-05 12:07:55 +03:00
|
|
|
}
|
2018-12-07 08:13:53 +03:00
|
|
|
err = n.spendHintCache.CommitSpendHint(n.currentHeight, spendRequests...)
|
2018-10-05 12:07:55 +03:00
|
|
|
if err != nil {
|
|
|
|
// The error is not fatal as this is an optimistic optimization,
|
|
|
|
// so we'll avoid returning an error.
|
|
|
|
Log.Debugf("Unable to update spend hints to %d for "+
|
2018-12-07 08:13:53 +03:00
|
|
|
"%v: %v", n.currentHeight, spendRequests, err)
|
2018-10-05 12:07:55 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:53 +03:00
|
|
|
// unconfirmedRequests returns the set of confirmation requests that are
|
|
|
|
// still seen as unconfirmed by the TxNotifier.
|
2018-10-05 12:07:55 +03:00
|
|
|
//
|
|
|
|
// NOTE: This method must be called with the TxNotifier's lock held.
|
2018-12-07 08:13:53 +03:00
|
|
|
func (n *TxNotifier) unconfirmedRequests() []ConfRequest {
|
|
|
|
var unconfirmed []ConfRequest
|
|
|
|
for confRequest, confNtfnSet := range n.confNotifications {
|
2018-10-05 12:07:55 +03:00
|
|
|
// If the notification is already aware of its confirmation
|
|
|
|
// details, or it's in the process of learning them, we'll skip
|
|
|
|
// it as we can't yet determine if it's confirmed or not.
|
|
|
|
if confNtfnSet.rescanStatus != rescanComplete ||
|
|
|
|
confNtfnSet.details != nil {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:53 +03:00
|
|
|
unconfirmed = append(unconfirmed, confRequest)
|
2018-10-05 12:07:55 +03:00
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:53 +03:00
|
|
|
return unconfirmed
|
2018-10-05 12:07:55 +03:00
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:53 +03:00
|
|
|
// unspentRequests returns the set of spend requests that are still seen as
|
|
|
|
// unspent by the TxNotifier.
|
2018-10-05 12:07:55 +03:00
|
|
|
//
|
|
|
|
// NOTE: This method must be called with the TxNotifier's lock held.
|
2018-12-07 08:13:53 +03:00
|
|
|
func (n *TxNotifier) unspentRequests() []SpendRequest {
|
|
|
|
var unspent []SpendRequest
|
|
|
|
for spendRequest, spendNtfnSet := range n.spendNotifications {
|
2018-10-05 12:07:55 +03:00
|
|
|
// If the notification is already aware of its spend details, or
|
|
|
|
// it's in the process of learning them, we'll skip it as we
|
|
|
|
// can't yet determine if it's unspent or not.
|
|
|
|
if spendNtfnSet.rescanStatus != rescanComplete ||
|
|
|
|
spendNtfnSet.details != nil {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:53 +03:00
|
|
|
unspent = append(unspent, spendRequest)
|
2018-10-05 12:07:55 +03:00
|
|
|
}
|
|
|
|
|
2018-12-07 08:13:53 +03:00
|
|
|
return unspent
|
2018-10-05 12:07:55 +03:00
|
|
|
}
|
|
|
|
|
2018-10-03 23:51:05 +03:00
|
|
|
// dispatchConfReorg dispatches a reorg notification to the client if the
|
|
|
|
// confirmation notification was already delivered.
|
|
|
|
//
|
|
|
|
// NOTE: This must be called with the TxNotifier's lock held.
|
2018-10-05 12:07:55 +03:00
|
|
|
func (n *TxNotifier) dispatchConfReorg(ntfn *ConfNtfn,
|
|
|
|
heightDisconnected uint32) error {
|
2018-10-03 23:51:05 +03:00
|
|
|
|
2018-12-07 08:13:50 +03:00
|
|
|
// If the request's confirmation notification has yet to be dispatched,
|
|
|
|
// we'll need to clear its entry within the ntfnsByConfirmHeight index
|
|
|
|
// to prevent from notifying the client once the notifier reaches the
|
|
|
|
// confirmation height.
|
2018-10-03 23:51:05 +03:00
|
|
|
if !ntfn.dispatched {
|
|
|
|
confHeight := heightDisconnected + ntfn.NumConfirmations - 1
|
2018-10-05 12:07:55 +03:00
|
|
|
ntfnSet, exists := n.ntfnsByConfirmHeight[confHeight]
|
2018-10-03 23:51:05 +03:00
|
|
|
if exists {
|
|
|
|
delete(ntfnSet, ntfn)
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// Otherwise, the entry within the ntfnsByConfirmHeight has already been
|
|
|
|
// deleted, so we'll attempt to drain the confirmation notification to
|
|
|
|
// ensure sends to the Confirmed channel are always non-blocking.
|
|
|
|
select {
|
|
|
|
case <-ntfn.Event.Confirmed:
|
2018-10-05 12:07:55 +03:00
|
|
|
case <-n.quit:
|
|
|
|
return ErrTxNotifierExiting
|
2018-10-03 23:51:05 +03:00
|
|
|
default:
|
|
|
|
}
|
|
|
|
|
|
|
|
ntfn.dispatched = false
|
|
|
|
|
|
|
|
// Send a negative confirmation notification to the client indicating
|
|
|
|
// how many blocks have been disconnected successively.
|
|
|
|
select {
|
2018-10-05 12:07:55 +03:00
|
|
|
case ntfn.Event.NegativeConf <- int32(n.reorgDepth):
|
|
|
|
case <-n.quit:
|
|
|
|
return ErrTxNotifierExiting
|
2018-10-03 23:51:05 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2018-10-05 12:07:55 +03:00
|
|
|
// dispatchSpendReorg dispatches a reorg notification to the client if a spend
|
|
|
|
// notiification was already delivered.
|
|
|
|
//
|
|
|
|
// NOTE: This must be called with the TxNotifier's lock held.
|
|
|
|
func (n *TxNotifier) dispatchSpendReorg(ntfn *SpendNtfn) error {
|
|
|
|
if !ntfn.dispatched {
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// Attempt to drain the spend notification to ensure sends to the Spend
|
|
|
|
// channel are always non-blocking.
|
|
|
|
select {
|
|
|
|
case <-ntfn.Event.Spend:
|
|
|
|
default:
|
|
|
|
}
|
|
|
|
|
|
|
|
// Send a reorg notification to the client in order for them to
|
|
|
|
// correctly handle reorgs.
|
|
|
|
select {
|
|
|
|
case ntfn.Event.Reorg <- struct{}{}:
|
|
|
|
case <-n.quit:
|
|
|
|
return ErrTxNotifierExiting
|
|
|
|
}
|
|
|
|
|
|
|
|
ntfn.dispatched = false
|
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2018-10-05 12:07:55 +03:00
|
|
|
// TearDown is to be called when the owner of the TxNotifier is exiting. This
|
|
|
|
// closes the event channels of all registered notifications that have not been
|
|
|
|
// dispatched yet.
|
|
|
|
func (n *TxNotifier) TearDown() {
|
|
|
|
n.Lock()
|
|
|
|
defer n.Unlock()
|
2018-07-27 07:31:32 +03:00
|
|
|
|
2018-10-05 12:07:55 +03:00
|
|
|
close(n.quit)
|
2017-12-05 00:30:33 +03:00
|
|
|
|
2018-10-05 12:07:55 +03:00
|
|
|
for _, confSet := range n.confNotifications {
|
2018-08-25 05:29:55 +03:00
|
|
|
for _, ntfn := range confSet.ntfns {
|
2017-11-13 22:55:22 +03:00
|
|
|
close(ntfn.Event.Confirmed)
|
2018-03-19 21:48:44 +03:00
|
|
|
close(ntfn.Event.Updates)
|
2017-11-13 22:55:22 +03:00
|
|
|
close(ntfn.Event.NegativeConf)
|
2018-12-11 05:29:22 +03:00
|
|
|
close(ntfn.Event.Done)
|
2017-11-13 22:55:22 +03:00
|
|
|
}
|
|
|
|
}
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
|
|
|
|
for _, spendSet := range n.spendNotifications {
|
|
|
|
for _, ntfn := range spendSet.ntfns {
|
|
|
|
close(ntfn.Event.Spend)
|
|
|
|
close(ntfn.Event.Reorg)
|
2018-12-11 05:29:22 +03:00
|
|
|
close(ntfn.Event.Done)
|
chainntnfs/txnotifier: allow registration of spend notifications
In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
2018-10-05 12:07:55 +03:00
|
|
|
}
|
|
|
|
}
|
2017-11-13 22:55:22 +03:00
|
|
|
}
|