Stats on malled transactions

[itod]

I think you are misunderstanding.  

...

Right now there is no way for an average user to force the client to only used confirmed change in new transactions even if they wanted to, other than manually wait and make sure they have no unconfirmed change outputs before sending funds.

I see what you mean, you are right. Would a simple configuration option whether to show unconfirmed inputs in the balance do the trick? No may be the default option, and you can always go to the console and temporarily force the opposite behavior if you want to. It may not even mess up how QT client handles the blockchain, just how it calculates the balance.

Edit: I have to check how it is this done right now in the code. I'm not positive how the balance is calculated.

[klondike_bar]

I think you are misunderstanding.  

...

Right now there is no way for an average user to force the client to only used confirmed change in new transactions even if they wanted to, other than manually wait and make sure they have no unconfirmed change outputs before sending funds.

I see what you mean, you are right. Would a simple configuration option whether to show unconfirmed inputs in the balance do the trick? No may be the default option, and you can always go to the console and temporarily force the opposite behavior if you want to. It may not even mess up how QT client handles the blockchain, just how it calculates the balance.

Edit: I have to check how it is this done right now in the code. I'm not positive how the balance is calculated.

THIS.

I compared my wallet balance against the transaction export and found that the two DID NOT MATCH. my hot wallet is 'richer' by exactly the amount in the second transaction's change wallet - I am not 100% sure which total is correct, though I imagine the wallet balance is the correct version

EDIT: my client just forced me to undergo 'reindexing blocks on disk', a process that appears to be going to take ~20min

[Loozik]

Jan,

Can your programme also calculate / include the information about the value of double spends?

Date           | Number of double spends      | Value of double spends
2014-01-29  | 470                                  | e.g. 59099 BTC

[itod]

It looks like it's already done, there are GetBalance(), GetUnconfirmedBalance() and GetImmatureBalance() methods in /src/wallet.cpp:

Code:

int64_t CWallet::GetBalance() const
{
    int64_t nTotal = 0;
    {
        LOCK(cs_wallet);
        for (map<uint256, CWalletTx>::const_iterator it = mapWallet.begin(); it != mapWallet.end(); ++it)
        {
            const CWalletTx* pcoin = &(*it).second;
            if (pcoin->IsConfirmed())
                nTotal += pcoin->GetAvailableCredit();
        }
    }

    return nTotal;
}

int64_t CWallet::GetUnconfirmedBalance() const
{
    int64_t nTotal = 0;
    {
        LOCK(cs_wallet);
        for (map<uint256, CWalletTx>::const_iterator it = mapWallet.begin(); it != mapWallet.end(); ++it)
        {
            const CWalletTx* pcoin = &(*it).second;
            if (!IsFinalTx(*pcoin) || !pcoin->IsConfirmed())
                nTotal += pcoin->GetAvailableCredit();
        }
    }
    return nTotal;
}

int64_t CWallet::GetImmatureBalance() const
{
    int64_t nTotal = 0;
    {
        LOCK(cs_wallet);
        for (map<uint256, CWalletTx>::const_iterator it = mapWallet.begin(); it != mapWallet.end(); ++it)
        {
            const CWalletTx* pcoin = &(*it).second;
            nTotal += pcoin->GetImmatureCredit();
        }
    }
    return nTotal;
}

And there's a flag if unconfirmed outputs should be collected in spendable outputs:

Code:

// populate vCoins with vector of spendable COutputs
void CWallet::AvailableCoins(vector<COutput>& vCoins, bool fOnlyConfirmed, const CCoinControl *coinControl) const
{
    vCoins.clear();

    {
        LOCK(cs_wallet);
        for (map<uint256, CWalletTx>::const_iterator it = mapWallet.begin(); it != mapWallet.end(); ++it)
        {
            const CWalletTx* pcoin = &(*it).second;

            if (!IsFinalTx(*pcoin))
                continue;

            if (fOnlyConfirmed && !pcoin->IsConfirmed())
                continue;

            if (pcoin->IsCoinBase() && pcoin->GetBlocksToMaturity() > 0)
                continue;

            for (unsigned int i = 0; i < pcoin->vout.size(); i++) {
                if (!(pcoin->IsSpent(i)) && IsMine(pcoin->vout[i]) &&
                    !IsLockedCoin((*it).first, i) && pcoin->vout[i].nValue > 0 &&
                    (!coinControl || !coinControl->HasSelected() || coinControl->IsSelected((*it).first, i)))
                        vCoins.push_back(COutput(pcoin, i, pcoin->GetDepthInMainChain()));
            }
        }
    }
}

So problem witch DeathAndTaxes talked about should not happen at all. If it does happen, there's easily correctable bug somewhere.

[nibyokwy]

It really is not that much of a problem IMHO. If those change outputs will eventually confirm or not has nothing to do with mutated TxID. If someone wants to include unconfirmed change outputs as his new inputs that's his problem. .

it's not a matter of wanting to include unconfirmed change outputs, it's the fact that the satoshi client does this by default and you can't stop it without patching it. so user is vulnerable to getting their wallet messed up.

[Barek]

This might be interesting.

https://github.com/bitcoin/bitcoin/pull/3651

[itod]

This might be interesting.

https://github.com/bitcoin/bitcoin/pull/3651

Exactly what we talked above, lol. It really is the most obvious solution. There's already the pull request to make this the default option: https://github.com/bitcoin/bitcoin/pull/3654

[Syke]

Malled transactions cannot steal coins.

You sure? It's pretty usual practice for Bitcoin merchants to update database upon transaction first seen in the network.

Whenever I want to receive bitcoins, I give the sender a unique address. I couldn't care less what the TXID is. I think most merchants work the same way. Malled transactions do not change the addresses.

[btceic]

This might be interesting.

https://github.com/bitcoin/bitcoin/pull/3651

Exactly what we talked above, lol. It really is the most obvious solution. There's already the pull request to make this the default option: https://github.com/bitcoin/bitcoin/pull/3654

Any indication or chatter on when this patch will be available?

[Sukrim]

I guess the issue is more often that people do send Bitcoins, then get a TXID from bitcoind after submitting the RPC call and store that TXID in case they need to check later if that transaction really went through.

[il--ya]

It really is not that much of a problem IMHO. If those change outputs will eventually confirm or not has nothing to do with mutated TxID. If someone wants to include unconfirmed change outputs as his new inputs that's his problem. .

it's not a matter of wanting to include unconfirmed change outputs, it's the fact that the satoshi client does this by default and you can't stop it without patching it. so user is vulnerable to getting their wallet messed up.

>it's not a matter of wanting to include unconfirmed change outputs, it's the fact that the satoshi client does this by default
is it a fact?

[itod]

is it a fact?

It seems so, not only unconfirmed change outputs but any unconfirmed outputs. The developers are applying patches to make the opposite the default behavior as we speak, the patch is seven hours old.

[DeathAndTaxes]

It really is not that much of a problem IMHO. If those change outputs will eventually confirm or not has nothing to do with mutated TxID. If someone wants to include unconfirmed change outputs as his new inputs that's his problem. .

it's not a matter of wanting to include unconfirmed change outputs, it's the fact that the satoshi client does this by default and you can't stop it without patching it. so user is vulnerable to getting their wallet messed up.

>it's not a matter of wanting to include unconfirmed change outputs, it's the fact that the satoshi client does this by default
is it a fact?

Yes.  The QT client (and all other clients AFAIK) does NOT allow spending unconfirmed outputs received from outside the wallet.  Change is treated differently and unconfirmed change is allowed to be spent.  Under normal conditions this is actually a beneficial thing (otherwise you can end up not being able to spend coins until change outputs confirm) but right now that action is undesirable.

[DeathAndTaxes]

is it a fact?

It seems so, not only unconfirmed change outputs but any unconfirmed outputs. The developers are applying patches to make the opposite the default behavior as we speak, the patch is seven hours old.

The reference client will not allow spending unconfirmed outputs received from outside the wallet.

If I send you 1 BTC right now, the client will indicate you do not have sufficient funds to make a tx if you try to spend it before it confirms.  Change outputs are handled differently though and could break transactions which use them before they are confirmed.

[itod]

The reference client will not allow spending unconfirmed outputs received from outside the wallet.

Ah, yes, that's correct, sorry.

[Anotheranonlol]

I am running a custom node that does real-time double spend analysis. I took a look at the log file over the last few days to see what was going on now that we have a lot of focus on malleable transactions.

Note that my custom node counts mutations on the same transaction as a double spend, which it isn't.

Detected double spends by date:

2014-01-29 470
2014-01-30 460
2014-01-31 460
2014-01-29 470
2014-01-30 460
2014-01-31 0
2014-02-01 39
2014-02-02 18
2014-02-03 97
2014-02-04 918
2014-02-05 461
2014-02-06 406
2014-02-07 769
2014-02-08 1260
2014-02-09 2618
2014-02-10 14576

Byzantine Candor CNY tea-break

[waxwing]

Byzantine Candor CNY tea-break

good call. The other "features" of this dataset are pretty interesting too, eh? The weird constancy around 460 and the massive ramp up just after the first Gox announcement.

[Jan]

The number of "double spends" (most of which I believe is mutated transactions) for the last 24 hours:
2014-02-11 16960
(will edit OP to reflect this)

It is slightly lower than I anticipated, as it was already above 16k 9 hours before the CET day ended (24 hours). Maybe the attack subsided, or someone is having a break.

[waxwing]

The number of "double spends" (most of which I believe is mutated transactions) for the last 24 hours:
2014-02-11 16960
(will edit OP to reflect this)

It is slightly lower than I anticipated, as it was already above 16k 9 hours before the CET day ended (24 hours). Maybe the attack subsided, or someone is having a break.

Or maybe they went to bed around midnight? It's currently 9am in China...

[il--ya]

The number of "double spends" (most of which I believe is mutated transactions) for the last 24 hours:
2014-02-11 16960
(will edit OP to reflect this)

It is slightly lower than I anticipated, as it was already above 16k 9 hours before the CET day ended (24 hours). Maybe the attack subsided, or someone is having a break.

LOL, isn't it MtGox with their custom client trying to re-submit failed transactions relentlessly?

Can you please post a couple of transactions to check what exactly was mutated? Many trivial mutations are already rejected by most nodes. Just want to see what's going on.