Topic: Stats on malled transactions - page 5. (Read 17391 times)

>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?

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.

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

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.

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

This might be interesting.

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

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 looks like it's already done, there are GetBalance(), GetUnconfirmedBalance() and GetImmatureBalance() methods in /src/wallet.cpp:


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

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

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

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

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.

Permanent fix for spam and ddos is for each full node to make a proof-of-work type check (like bitmessage does) for incoming transactions.
Kind of like if transaction is 1satoshi difficulty will be higher than if transaction is 1btc.

I think you are misunderstanding.  

I send you 1 BTC.   It is tx id A.   Someone mutates it so there is a copy with tx id B.

You send a 0.1 BTC to your friend.   As a normal user it isn't you, but the QT client which picks which inputs are used.  The client picks tx id A, index 0 as the input for this new outbound tx.  It can do this because by the QT client right now uses unconfirmed change outputs as inputs in new txs.

Now lets say tx B not A ends up in a block.  Oops. 

The tx to your friend is now invalid, it uses as its input an output which is a double spend (tx a) of a valid confirmed tx (tx b) and thus will never confirm.  There is no user friendly way for you to remove that from your wallet.  Most users may not even know why it didn't work.  They will see the tx to their friend simply never confirms.  It won't be marked as a double spend (because it isn't) it simply will never confirm because it is no longer valid, it became invalid as soon as B not A was included in a block.  It can be solved but it is far from user friendly.  Now imagine that happening for thousands of users every single day forever because some malicious user is intentionally mutating tx to cause chaos.  Nobody ends up losing coins but it makes the system look bad, counterintuitive, and confusion especially for newer users.

If you wait until a tx is confirmed then the txid is immutable (baring a network re-org) and this becomes a non-issue.  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.

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. His last transaction will eventually confirm if those outputs are regular payment, or fail if it is double-spend attempt. The system is designed to work this way.

The later.  It would be a client side change only and wouldn't require the support of anyone beyond the user using it.

Would that require a hard fork or just software update on bitcoin-qt and other wallet software? Im guessing the latter. That sounds like a short term solution at least.

Not it would simply be an unconfirmed tx and after the parent is dropped it becomes an invalid tx.

However it is a genuine case for concern.  There is no profit in it, but the combination of:
a) malicious user malling all tx
and
b) the QT client using unconfirmed change outputs in new tx

can lead to a lot of confusion and broken transactions.   I am not sure what the immediate fix it.

One option would be to either by default or by a user enabled option don't use change outputs until they have at least 1 confirmation.  That combined with simply "hiding" duplicates would make the mutated spam pretty much invisible to "normal users".  Merchants and service providers not using a payment processor need to understand the mutability of txids but honestly they already should.

I'm no expert on this stuff, but I'm wondering, could this behavior in the reference client be amplifying the effects of the malled TX attack as measured in the OP?  i.e. When a client attempts to spend unconfirmed change that never gets confirmed because its tx got malled, is that also counted as a double-spend attempt?

Keep in mind that exchange has in their logs every IP from which you accessed them ever. That data is never erased and regularly log-rotated and backuped for legal purposes. I'm not saying it will be easy for them to catch who's messing with them, but you can bet they will do everything to reveal real identity of that account holder.

If you think massive bitcoin network attack is going to be exposed by linking to an IP address, then you greatly underestimate who you're dealing with.