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

https://bitcointalksearch.org/topic/rfc-detecting-malled-transactions-463945  [RFC] Detecting Malled Transactions

So basically stop accepting 0-conf transactions for all purposes, even from trusted customers, until all wallet software has been updated to not spend unconfirmed change?  This seems like an extremely severe setback for bitcoin adoption and its utility in general.

I thought it was possible to determine if a tx looks like it was created by the standard client or not. Should this not be possible or there are too many different legitimate tx styles out there then I guess we will have to deal with malled txs.

You probably won't be able to so the only solution is to prevent it from happening to begin with.


The client waiting until change is confirmed isn't "ideal".  The ideal solution is to make tx ids immutable but that is a long term fix.  In the interim a user (possibly) having to wait for the change to be confirmed is far superior to transactions randomly breaking and non-technical users and merchants trying to figure out why it seems to just fail randomly.  The later is just going to kill adoption. 

What is a malled tx look like?  There are many ways that a tx can be mutated that makes identifying the "correct" one impossible.  Most nodes and pools already drop the duplicate the issue is the duplicate is getting to the pool before the original.  It wouldn't end up in a block otherwise.

If you have two tx each are equally valid and correct, how do you know which one was mutated after sending?   You can't so you do what you already do.  You keep the one you receive first and you drop the other one.  That means if the mutated tx gets to a miner's memory pool first, it will get included in a block.

Hey,

I have been working on the idea about trying to find the rogue nodes/pool over the past day or so. Check this thread for more https://bitcointalksearch.org/topic/working-around-malleability-catching-the-culprit-if-there-is-one-463350. Its a simple idea that I have thought about but I cant implement it on my own because I am not a programmer. Maybe you could contribute ?

Cheers

Seems obvious to me. You don't try and spend what you don't know you have. Maybe that means wallets have to jump through hoops or you just don't get your donut but to my mind, that's what it boils down to. Bitcoin is supposed to be about cold, hard facts not payday loans.

What about a soft fork: pools don't include malled txs and clients don't relay them. I think this would very quickly solve the problem.

Distinguishing between those two types of transactions is fine from a technical point of view but we'd never be able to explain that difference to a customer.  I'm mostly concerned about the customer service problems this will create.  Alice gets her donut because she spent confirmed inputs.  Bob doesn't get his donut because he spent unconfirmed change.  Neither Alice nor Bob have clue what any of that means.  How do we explain to Bob that he doesn't get his donut without resulting in a fist fight, a discrimination lawsuit, an all day seminar on the technical workings of the blockchain, giving away a free donut, and/or potentially losing Bob as a regular customer?

Are there any ideas on whether a technical solution to this problem will be forthcoming or any suggested workarounds?

I thought 0.8+ clients did not relay some (the current?) malled transactions...


It would be fun to try and find the source nodes (given they can be distinguished and it's not a large botnet). Of course this is not a solution (Tor, intermediate node, ...).
1. Get well connected, don't relay malled txs
2. Wait until a malled tx propagates through the network
3. Drop the 50% connections that you receive the malled tx from last
4. goto 1

optional 3b. ddos the #1 node on the list until it stops

The network police might come handy with some types of ddos attacks

I wonder if anybody ever tried homing in on a malicious node like this.

That is the long term fix.  You essentially are talking about transaction immutability.  However it can't simply be a client side "feature" as an attacker would just modify their client.  It will need to be enforced by the protocol.   That means (most likely) a hard fork and there just is no way to do that "fast and easy".   The situation is made more complex by the fact that ECDSA signatures are not "unique" it is possible for more than one set of inputs to produce the same signature. 

Simple version:
Long Term Goal (hopefully share unanimously by core developers):  Make unconfirmed tx ids immutable (or at least immutable to third parties).
Short Term Goal: Client behavior in dealing with mutable tx ids needs to be more consistent and expected until we get to the long term goal.

As a historical note.  Adding P2SH was a much simpler fork to the protocol.  From the time that P2SH code was completed to the time P2SH was supported by the protocol was about 8 months.

Wouldn't a better fix be to change the client behavior such that there is only one correct way to encode a transaction (with enforcement to begin in some future block), removing the possibility of malleability?

The attacker stopped.  Why and for long run remains unknown.  A patched client doesn't prevent the duplicates from existing so if tx were still being duplicated they should show up.

Is this because of the attacker / the exchanges on hold?

Or is it because pools updated their software with the 0.8 fixes?

Wallets will need to be "smarter".  A wallet knows how many unique unspent outputs it has.

So in the 100 BTC example it could spend it back to itself as 5x 20 BTC outputs.  Then a user could spend 1, have 19 BTC change confirming and still have 80 BTC available to spend.

Wallets also probably need to use simpler language like:  "Total balance: XXXX (available to spend: XXXX)  Why is this different?" with link/popup to simple user level explanation.

A "smart wallet" can engage in output management to minimize the disruption to a user.  There is no reason a tx must have 1 change output (to the protocol change is simply an output no different than the "intended" output).  If anything multiple change outputs would make blockchain analysis slightlymore difficult.  So when creating an outbound tx the wallet could look at its internal confirmed output pool and if it is "low" make 2 or more change outputs.  How many to make would depend a lot of the amount of the change (in BTC) and the number of unspent outputs (in discrete outputs not value).

Instead of

The wallet could instead do this:


Where * is a random amount such that the sum of the change addresses is 99 BTC.



It is important now with mass mutation attack going on to distinguish between:

0 confirm tx where all inputs are confirmed
vs
0 confirm tx where one or more inputs are also 0 confirm.

The former requires a race attack and malicious intent of the sender for the receiver to lose funds.  So if you trust your customers, or feel only a small % of your customers would attempt an attack you are relatively safe (especially for low value, low risk purchases).   The later however only requires that SOMEONE on the network mutate the prior unconfirmed transaction and that the mutated version ends up confirming.   The risk profile becomes "do you trust the entire world to not mess with your money even though it is painfully easy?"  In most cases that answer should be no.

In the donut shop example up thread, the customer isn't the one doing the mutating. He could be a regular customer and liked by the shopkeeper however his coffee tx gets mutated by a malicious third party.  Now mutated or not the coffee tx will go through, no risk to the shop there.   However if the duplicate is the one which is confirmed, then the change output used for the doughnut becomes invalid.  Now through no fault of either the shopkeeper or the legit customer the donut payment will never confirm.  It gets worse when you consider how confusing this will be to put the shopkeeper and the customer especially if their are "crypto-nerds".

Honestly until tx ids are immutable the use of unconfirmed change outputs is just going to cause mass chaos.  The long term goal should be immutable tx ids but lets be honest that is probably a six to nine month project.  It will most likely require a hard fork of the protocol and there is simply no fast and easy way to do that.    So in the immediate future transactions are mutable (even by third parties) and that means unconfirmed change can be broken by a malicious third party.  For the record the "DDOS attack" against exchanges involves this aspect of mutable transactions. 

I would also point out how nuanced this conversation is.  Now imagine someone who has a "user level" knowledge of Bitcoin.  Many people have no idea that Bitcoin works on the concepts of inputs and outputs.  Their knowledge is no deeper than the "abstraction" of wallet balances.  Now that is fine, the job of good software is to abstract a very complex system into a simple concept.  It isn't the user's fault that they don't know the inner workings, however you can't even start to explain the problem, until you explain how Bitcoin "really works".  That simply isn't a viable scenario for non-enthusiasts.  Case in point my need for a side note here: https://bitcointalksearch.org/topic/what-the-average-user-needs-to-know-about-transaction-mutability-460944

Yes, I do appreciate the problem. But I would say it could/should be attacked from three angles: 1, disallow it by default but allow it to be switched on, 2, make people aware that they sometimes have to wait for confirmations before proceeding and 3, some alterations within wallets, e.g. automatic internal transfers to split up into denominations.

For sure, it is much more convenient if we don't have to worry about this - but if I'm reading things correctly, malleability is with us for some time.

Zero conf payments still work - it's just zero conf payments spending existing  zero confirm payments that don't.

The client could just try to/prompt to respend if after 10 minutes or so if it fails to see the expected change txid, but some outputs summed to the same amount with another txid getting confirmed in a block, and the sum of all outputs doesn't change.

Do you realize how confusing and frustrating can be for users to disallow spending of unconfirmed change?

Imagine you received 100 BTC and you spend 1 BTC - suddenly 99 BTC become unspendable for 5,10, 30 minutes... That's very counter intuitive and will confuse a lot many users who do not understand how the protocol works.

Not allowing to spend unconfirmed change is an important steps backwards, and I think that we shouldn't downplay it's effect. I'd probably have it as an optional feature on the client, but if possible I wouldn't make it the default behaviour.

About 0-conf: for small, day by day payments they were absolutely safe. The cost to perform a double spend was simply not worth the cost of a coffee. Now, that changes, 0-conf are not safe even if the buyer is 100% honest and the cost of the product is negligible: again we cannot downplay the effect of that, it's quite serious.

Oh yes of course, stupid of me, the customer loses out there. But it still always comes back to the same thing for me: wallets should not attempt to spend unconfirmed change. Yes, I know there are some practical difficulties there with the way wallets are designed, but it doesn't look insurmountable - at worst it just causes a few inconveniences.

Today BitPay would accept it.  Unconfirmed change is used rather routinely although probably will be changing soon.  In your scenario though the bad news is not BitPay needs to figure out a way to return your coins.  You can't undo it and eventually it will confirm (unless a duplicate of the prior output is what confirms).  So you are now out the donut and coins.  Of course the shop will have no clue how to get your coins back, and "you" (or a less educated user) might be kinda upset seeing the donut funds deducted from your wallet but not getting the donut and the clueless clerk having no idea how to get your coins back or even where they went.

If this happened enough the store might just not accept Bitcoin in the future.  Now I am not going all doom and gloom and none of this is unsolvable but you can see how all this starts to get really ugly real quick.  Transaction Ids need to be immutable.  Period.   There is no other viable long term option.  However that is going to take some time so things might get a little clunky for service providers before they get better.