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

Very good example to think about, but: did I miss something? I think it won't happen, or at least doesn't have to. When you try to pay for the donut, assuming your wallet makes use of the change utxo which has been malled and is not yet confirmed, will bitpay accept it? I don't know whether they would today, but isn't it trivial to just check each utxo used as input and look at the blockchain to see if that transaction has any confirms? That way, they can accept unconfirmed spends, but not accept unconfirmed spends of unconfirmed spends, which is practically absolutely fine. Except you don't get your donut

Unless your wallet is coded to not use unconfirmed change...

I agree, Before this I pretty much trusted each transaction without confirmations if as there was a fee paid. I really hope this Issue wil be fixed soon.

I disagree.  I think the community now sees zero-confirm transactions as more risky than prior to the malleability attack.  I know I do.  Previously, I think most people were under the impression that to invalidate a zero-confirm transaction (e.g., buying my donut at Waves in Vancouver), the customer would be the attacker (and basically had to be in cahoots with a nefarious miner in order to double spend).  The malleability attack has shown that even if both customer and merchant are honest, proper fees are paid, and the transaction propagates across the network, it's still possible (and in some cases probable) that the transaction doesn't go through (and thus D&T's solution to disallow transactions using unconfirmed "change" outputs).  

So I agree with D&T that we need a smarter way to deal with unconfirmed change, until malleability is properly fixed.  My question was if we enforce this new change rule, how often will casual users find themselves unable to pay immediately (such as my donut example)?  How will this impact the experience of say, my mom using her smartphone, who couldn't wrap her head around this?  

Yes, that is possible, but that's nothing new. Accepting with zero-confirm transactions is risky.

Here in Vancouver, several brick-and-mortar businesses accept zero-confirm transactions using BitPay.  If you are buying a coffee, no one is going to wait 10 minutes (or longer) for confirmation;  it is critical that zero-confirm transactions are reasonably secure in order for this business model to work.  

So let me see if I understand the transaction malleability problem in relation to brick-and-mortar stores:

I pay for my coffee at Waves for 4mBTC.  Assume that to avoid "address reuse," my phone uses the full balance in 1AddressA, sends 4mBTC to Waves, and the rest to a new change address 1AddressB.  BitPay accepts this transaction and I get my coffee.  As soon as I finish paying, I realize that I also wanted a donut.  So I pay for this using what are now unconfirmed coins sitting in 1AddressB.  BitPay still approves the transaction and I get my donut too.  

But my first transaction was mutated, and the mutated version was accepted into the blockchain.  This means that the transaction I used to pay for my donut is now invalid, and Waves/BitPay won't get the money (and I've already left the store).  

This seems like a messy problem to deal with.  If we disallow spending unconfirmed change outputs, then there will be certain cases when I can't actually purchase my donut [without a long wait], correct?  Ideally, my wallet would try to break up my coins so that there are always plenty of fully-confirmed outputs ready for spending.  But how do most wallets actually work?  The Blockchain.info mobile wallet [that I use] sends the change back to the same address, so I'd expect that it would be very rare to have exhausted all of the confirmed outputs.  But for mobile wallets that avoid address reuse [do these even exist?], would it be less likely that you'd have confirmed coins available?

And should BitPay do anything to protect itself?

For those that have transactions that will never confirm, what is the procedure on QT to clean up the wallet?

Really sad that there is no solution to even clean these transactions manually... at least not for official bitcoin-qt client.

Any reason to believe it won't happen again tomorrow? I think we'd all like to know when Bitstamp and other exc will start processing withdrawals again ;-)

Seems we are back to business as usual.
2014-02-12 393
Updating OP.

a) this is already implemented in each bitcoin-QT client. Although it would be time consuming to do it regularly.
b) creating "false blockchain" is almost impossible, it needs forking blockchain somewhere and then constructing new "false blocks". This "construction" means in fact mining new alternative and legitimate blocks from this fork. No single entity has enough computational power to do this. And some "easier blockchain" would not be correctly verified by reference client.

It presumably would, and a few options such as last 100 or last 1000 might be sufficient.

The only concern would be that:
a) this would need to be implemented by each client
b) it *could* create weak points for an evil trojan/virus to replace and then rescan a false short blockchain - seems unlikely though

I am certain it does, but since selection of what outputs are used for a new transaction is (mostly, unless you use coin control) out of your hands you can never be sure unconfirmed change has not been used.

Maybe this is too simple to be right, but...
Would not running rescan in bitcoin-QT from the time "some time before problematic unconfirmed-change-spending transaction" help?

Manipulated? It can always be manipulated with enough money... Actually, for  a normal person/exchange this doesnt affect the btc, because we always waited for 3 or 6 confirms before delivering. It will clear up

AFAIK, Armory automatically send change to a new address, so at least it could have an option to disallow spending unconfirmed change outputs, unless there is nothing else spendable, should work in many cases.

Also, shouldn't the priority of spending be decided by the coin-age? As the fee rule discourages spending "hot" coins.

I am fairly certain that all (or nearly all) clients allow spending unconfirmed change outputs.  Until the "mass mutation attack" it improved the user experience to have this option.  Without the ability to spend unconfirmed change outputs the user could potentially (depending on what other confirmed outputs are available) need to wait for confirmations between spends.  I can't see any wallet intentionally doing that.  Many some minor less tested wallet may have accidentally ended up with that behavior.

I corrected my post, how many clients you know share the same behaviour?

EDIT: I would suggest you somehow also post your OP in the tech discussion board btw.

https://bitcointalksearch.org/topic/m.5089865

Please actually read the section labeled "Mutable Transaction ids break spending unconfirmed change".

To answer your question.  No.  You can "find it" but a tx created from an unconfirmed change output which is subsequently mutated will never confirm.

Well, you said the mutated one gets confirmed, can I find the one or not? Thanks.

EDIT: Okay, I read your OP, I was awfully unaware of the way the reference client works as I have never actually used it, thanks.

Once again you might want to read the link. I am not talking about it being confirmed under a new tx id.  I am talking about it NEVER confirming because it now has become invalid due to the inputs being invalid.