Abandon methods are alias for local Remove functions

[mobias17]

Lets take a look onto the spark wallet

void CSparkWallet::RemoveSparkMints(const std::vector<spark::Coin>& mints) {
    for (auto coin : mints) {
        try {
            spark::IdentifiedCoinData identifiedCoinData = coin.identify(this->viewKey);
            spark::RecoveredCoinData recoveredCoinData = coin.recover(this->fullViewKey, identifiedCoinData);

            CWalletDB walletdb(strWalletFile);
            uint256 lTagHash = primitives::GetLTagHash(recoveredCoinData.T);

            eraseMint(lTagHash, walletdb);
        } catch (const std::runtime_error &e) {
            continue;
        }
    }
}


void CSparkWallet::RemoveSparkSpends(const std::unordered_map<GroupElement, int>& spends) {
    LOCK(cs_spark_wallet);
    for (const auto& spend : spends) {
        uint256 lTagHash = primitives::GetLTagHash(spend.first);
        if (coinMeta.count(lTagHash)) {
            auto mintMeta = coinMeta[lTagHash];
            mintMeta.isUsed = false;
            CWalletDB walletdb(strWalletFile);
            addOrUpdateMint(mintMeta, lTagHash, walletdb);
            walletdb.EraseSparkSpendEntry(spend.first);
        }
    }
}

void CSparkWallet::AbandonSparkMints(const std::vector<spark::Coin>& mints) {
    RemoveSparkMints(mints);
}

void CSparkWallet::AbandonSpends(const std::vector<GroupElement>& spends) {
    LOCK(cs_spark_wallet);
    for (const auto& spend : spends) {
        uint256 lTagHash = primitives::GetLTagHash(spend);
        if (coinMeta.count(lTagHash)) {
            auto mintMeta = coinMeta[lTagHash];
            mintMeta.isUsed = false;
            CWalletDB walletdb(strWalletFile);
            addOrUpdateMint(mintMeta, lTagHash, walletdb);
            walletdb.EraseSparkSpendEntry(spend);
        }
    }
}

let's start with AbandonSparkMints which obviously calls RemoveSparkMints. AbandonSpends and RemoveSparkMints are very similar (take different input). Still both seem only to operate on local DB.

Is it per design that when a Spark mint or spend is fired off there is no chance to stop it anymore even when unconfirmed?

[reubenyap]

"Is it per design that when a Spark mint or spend is fired off there is no chance to stop it anymore even when unconfirmed?"

Generally, this is the case though once it's broadcasted as we don't support RBF which to me introduces more issues than solves. Is this what you mean?

[mobias17]

Hi @reubenyap,

this is to some extend what I mean, yes. let's take a look e.g. at Bitcoin core.

bool CWallet::AbandonTransaction(const uint256& hashTx)
{
    LOCK(cs_wallet);

    // Can't mark abandoned if confirmed or in mempool
    auto it = mapWallet.find(hashTx);
    assert(it != mapWallet.end());
    const CWalletTx& origtx = it->second;
    if (GetTxDepthInMainChain(origtx) != 0 || origtx.InMempool()) {
        return false;
    }

    auto try_updating_state = [](CWalletTx& wtx) EXCLUSIVE_LOCKS_REQUIRED(cs_wallet) {
        // If the orig tx was not in block/mempool, none of its spends can be.
        assert(!wtx.isConfirmed());
        assert(!wtx.InMempool());
        // If already conflicted or abandoned, no need to set abandoned
        if (!wtx.isConflicted() && !wtx.isAbandoned()) {
            wtx.m_state = TxStateInactive{/*abandoned=*/true};
            return TxUpdate::NOTIFY_CHANGED;
        }
        return TxUpdate::UNCHANGED;
    };

    // Iterate over all its outputs, and mark transactions in the wallet that spend them abandoned too.
    // States are not permanent, so these transactions can become unabandoned if they are re-added to the
    // mempool, or confirmed in a block, or conflicted.
    // Note: If the reorged coinbase is re-added to the main chain, the descendants that have not had their
    // states change will remain abandoned and will require manual broadcast if the user wants them.

    RecursiveUpdateTxState(hashTx, try_updating_state);

    return true;
}

When trying to abandon, it checks whether it has been confirmed yet, if so no chance to do anything further, on the other hand when not confirmed attempt to catch it from the mempool to abandon.

Where are the use cases? E.g. from a CEX when you send out your coins some offer the possibility to stop the payout while there's no confirmation.

I came along this point when looking further into #1328 how to e.g. "cancel" a stuck mint.

[reubenyap]

As far as I know from a CEX is when the transaction hasn't been broadcasted out you can cancel it when it's still processing, but once it's broadcast, you can't.