itod
Legendary
Offline
Activity: 1974
Merit: 1077
^ Will code for Bitcoins
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 11, 2014, 10:53:58 PM |
|
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
Legendary
Offline
Activity: 2128
Merit: 1005
ASIC Wannabe
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 11, 2014, 10:59:09 PM |
|
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
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 378
Merit: 250
Born to chew bubble gum and kick ass
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 11, 2014, 11:21:07 PM |
|
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
Legendary
Offline
Activity: 1974
Merit: 1077
^ Will code for Bitcoins
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 11, 2014, 11:21:33 PM |
|
It looks like it's already done, there are GetBalance(), GetUnconfirmedBalance() and GetImmatureBalance() methods in /src/wallet.cpp: 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: // 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
Newbie
Offline
Activity: 51
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 11, 2014, 11:35:53 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 11, 2014, 11:37:50 PM |
|
|
|
|
|
itod
Legendary
Offline
Activity: 1974
Merit: 1077
^ Will code for Bitcoins
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 11, 2014, 11:50:00 PM |
|
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
Legendary
Offline
Activity: 3878
Merit: 1193
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 12, 2014, 12:06:51 AM |
|
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.
|
Buy & Hold
|
|
|
btceic
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 12, 2014, 12:07:46 AM |
|
Any indication or chatter on when this patch will be available?
|
|
|
|
Sukrim
Legendary
Offline
Activity: 2618
Merit: 1007
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 12, 2014, 12:09:12 AM |
|
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
Newbie
Offline
Activity: 47
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 12, 2014, 12:19:13 AM |
|
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
Legendary
Offline
Activity: 1974
Merit: 1077
^ Will code for Bitcoins
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 12, 2014, 12:29:58 AM |
|
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
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 12, 2014, 12:31:32 AM |
|
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
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 12, 2014, 12:33:05 AM Last edit: February 12, 2014, 12:45:54 AM by 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
Legendary
Offline
Activity: 1974
Merit: 1077
^ Will code for Bitcoins
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 12, 2014, 12:35:38 AM |
|
The reference client will not allow spending unconfirmed outputs received from outside the wallet.
Ah, yes, that's correct, sorry.
|
|
|
|
Anotheranonlol
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 12, 2014, 12:40:34 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 12, 2014, 12:54:07 AM |
|
Byzantine Candor CNY tea-break
![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif) 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.
|
PGP fingerprint 2B6FC204D9BF332D062B 461A141001A1AF77F20B (use email to contact)
|
|
|
Jan (OP)
Legendary
Offline
Activity: 1043
Merit: 1002
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 12, 2014, 01:00:12 AM |
|
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.
|
Mycelium let's you hold your private keys private.
|
|
|
waxwing
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 12, 2014, 01:03:04 AM |
|
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...
|
PGP fingerprint 2B6FC204D9BF332D062B 461A141001A1AF77F20B (use email to contact)
|
|
|
il--ya
Newbie
Offline
Activity: 47
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 12, 2014, 01:16:22 AM |
|
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.
|
|
|
|
|