What the "average user" needs to know about Transaction Mutability

[monsterer]

Excellent definition of the real scope of the problem. I was waiting for someone to admit the problem was not only affecting custom wallets, but in fact troubled the reference implementation as well.

Cheers, Paul.

[1715328010]

1715328010

[1715328010]

1715328010

[1715328010]

1715328010

[DeathAndTaxes]

Can someone please elaborate why the unconfirmed-change-spending issue is a real problem? To me, it sounds like it may cause some users to accidentally reverse subsequent zero-confirmation transactions, and that's it.  But the community has been pretty darn vocal about telling people/merchants not to accept zero-conf tx, and there's plenty of ways to intentionally double-spend them without this bug/quirk.  It seems that this particular part of the problem is simply making it (more) painfully obvious why they shouldn't be accepting zero-conf tx.

What am I missing?  

(Of course I know there's bigger problems with transaction mutability than just spending unconf change, but that seems to be the only issue Armory currently has ... if it's a real issue)

It isn't a security issue it is a usability issue.  Traditional double spends require the SENDER to be malicious.  That is a rather narrow security scope.  For a duplicate tx to break a subsequent tx which uses unconfirmed change output only requires that a single third party on an anonymous global decentralized network is malicious.   That is a rather asininely large security scope.  It becomes "Are there any bad/mean people in the world right now?  If no then you are fine nobody can break your tx. If yes then your tx might break randomly".

Example
I create a tx with a hash of "A".  It send 1 BTC somewhere and 4 BTC back to me as change. A malicious user looking to just create chaos mutates it so that it has a hash of "B". For this tx there is no possibility of the payment being broken.  Either A or B will be confirmed and the receiver will get their 1 BTC. 

The problem is created when I create a second payment (tx "C") before "A" or "B" confirms and my wallet uses the change output from "A".  As far as it knows (due to relay rules) tx "B" doesn't even exist so of course it is ok to use "A" we aren't going to double spend ourselves.  This makes tx "C" dependent on tx "A" being confirmed.  If "B" confirms then "A" never will and as a result "C" never will either.

The user is honest, he is following the rules, creating a valid tx (proper fee, no spam, etc), the merchant is being safe and waiting for a confirmation, essentially both parties are doing the "right thing".  However the payment just breaks due to the actions of a third party.  Can it be resolved?  Sure delete Tx "C", create a new Tx "D" which is identical to C except it uses the change output from "B" not "A" and send again.  Now try to explain why you "randomly" need to do that sometimes to a non-technical user.

To a non-technical user it simply looks like the Bitcoin network "breaks" randomly and then you need to pay again, sometimes.  Not exactly confidence building huh.  Sometimes after you pay it will just break and then you need to pay again.  On top of that imagine you believe you paid a merchant and then they ask you to pay them again because Bitcoin broke.  It seems suspicious right?   I just makes the tx flow counter intuitive.  

Until transaction ids are immutable, allowing users to spend unconfirmed change outputs is just going to cause chaos.

[etotheipi]

It isn't a security issue it is a usability issue.  Traditional double spends require the SENDER to be malicious.  That is a rather narrow security scope.  For a duplicate tx to break a subsequent tx which uses unconfirmed change output only requires that a single third party on an anonymous global decentralized network is malicious.   That is a rather asininely large security scope.  It becomes "Are there any bad/mean people in the world right now?  If no then you are fine nobody can break your tx. If yes then your tx might break randomly".

...

The user is honest, he is following the rules, creating a valid tx (proper fee, no spam, etc), the merchant is being safe and waiting for a confirmation, essentially both parties are doing the "right thing".  However the payment just breaks due to the actions of a third party.  Can it be resolved?  Sure delete Tx "C", create a new Tx "D" which is identical to C except it uses the change output from "B" not "A" and send again.  Now try to explain why you "randomly" need to do that sometimes to a non-technical user.

To a non-technical user it simply looks like the Bitcoin network "breaks" randomly and then you need to pay again, sometimes.  Not exactly confidence building huh.  Sometimes after you pay it will just break and then you need to pay again.  On top of that imagine you believe you paid a merchant and then they ask you to pay them again because Bitcoin broke.  It seems suspicious right?   I just makes the tx flow counter intuitive.  

Until transaction ids are immutable, allowing users to spend unconfirmed change outputs is just going to cause chaos.

Where we are differing is the fact that the alternative is also quite confusing to the user.  They spend 0.3 BTC and suddently 54.3228 of their Bitcoins are unspendable.  Perhaps it's a better alternative, than the confusion you mention.  But I was also responding to people requesting the ability to optionally make unconf change unspendable, i.e. through an option in the menu or CLI argument.  That doesn't solve either problem, it just allows knowledgeable users to avoid accidentally double-spending when doing a chain of transactions, but regular users have the same problem.

At least with Armory, it already scores CoinSelection solutions spending unconfirmed-change lower than any other solutions.  Meaning, it would rather pay a fee and/or bundle extra inputs, rather than include any zero-conf UTXOs (though it will count the ZC UTXOs in your spendable balance, and it will use them if there are no other options).  Even though it may not have been necessary, I didn't care much for ZC outputs, which is why I deprioritized them so heavily.  It appears to have made Armory as resistant as possible to this problem, without inconveniencing the user (though I admit, it was kind of coincidental that I the criteria I chose happened to be the correct one to minimize the malleability issues).

[Peter R]

Can someone please elaborate why the unconfirmed-change-spending issue is a real problem? To me, it sounds like it may cause some users to accidentally reverse subsequent zero-confirmation transactions, and that's it.  But the community has been pretty darn vocal about telling people/merchants not to accept zero-conf tx's...

What am I missing?  

In my opinion, the reliability of zero-confirm transactions has been significantly degraded.  This affects brick-and-mortar stores that are required to accept zero-confirm transactions in order to be viable (e.g., selling coffee).

Before the malleability attack, I believed that zero-confirm transactions were reliable provided the person sending them was honest, they included an appropriate fee, and that the transcation was accepted by the network [I thought that only a dishonest customer in cahoots with a nefarious miner could cheat on a zero-confirm tx].  When the network is under malleability attack, this is no longer the case if the transaction in question uses any unconfirmed outputs.  

I described a practical example of a problem that could arise at Wave Coffee here in Vancouver (they accept bitcoin via BitPay): https://bitcointalk.org/index.php?topic=459678.msg5113081#msg5113081

I agree that we must dis-allow spending of unconfirmed change outputs by default, in order for zero-confirm transactions to be reasonably trustworthy again.

Until malleability can be eliminated, wallets will need to become smarter, ensuring that you have a good supply of confirmed coins at your disposal, by breaking up large coins when necessary.  

[etotheipi]

It sounds to me like the way for wallets to handle this (like Armory), is to popup a warning if a user sends one transaction, and then later attempts to send a second transaction that requires unconfirmed change. 

-- If they are not spending unconfirmed change, nothing needs to be done.  User is not inconvenienced.
-- If they are, pop up a message to the effect of:

This transaction may have problems reaching its intended recipient(s) if you send it right now.  You might have to re-create and sign a replacement unless you wait for your previous transactions to be confirmed by the network. 

To avoid these issues, please wait until all previous transactions in the ledger have at least one confirmation, and then restart the "Send Bitcoin" procedure as before.

[Send Anyway] [I'll Wait]

I suppose a better alternative would be to hold the key data in RAM until your tx is confirmed, and sign a new transaction with the new txid, if the first one is mutated.  Perhaps even broadcast the first one, but immediately sign and broadcast the replacement if the first one is invalidated.  I prefer the first one though (where the software just waits before doing anything), which is a bit cleaner.

This transaction may have problems reaching its intended recipient(s) if you send it right now.  You must wait for your previous transactions to become confirmed.  If you click "Send when Ready", Armory will queue the transaction to be sent at that time.  If you close Armory before you see it appear in the transaction ledger, you will have to re-send it next time you start Armory.

[Cancel] [Send when Ready]

[Peter R]

I suppose a better alternative would be to hold the key data in RAM until your tx is confirmed, and sign a new transaction with the new txid, if the first one is mutated.  Perhaps even broadcast the first one, but immediately sign and broadcast the replacement if the first one is invalidated.  I prefer the first one though (where the software just waits before doing anything), which is a bit cleaner.

Interesting.  In my example (https://bitcointalk.org/index.php?topic=459678.msg5113081#msg5113081) where the customer's donut purchase is invalidated because his coffee purchase was malled, the wallet would realize this and then send out a new transaction to remedy the situation [which may occur after the customer has left the store and without his knowledge].

So, the customer could still pay instantly, even if he has no confirmed outputs.  Provided the customer is honest (which we already need to assume), the merchant will still get paid even if the parent transaction gets malled by an attacker: the wallet just checks for malling and, if so, sends a replacement TX to fix the problem.  

[FandangledGizmo]

I'm not very technical, maybe this isn't the right thread to ask but the attack that is happening this week.

A “massive and concerted attack” has been launched by a bot system on numerous bitcoin exchanges

Could somebody tell me whether the person/group doing it need a lot of Bitcoins to pull it off or just computing power?

[DeathAndTaxes]

It sounds to me like the way for wallets to handle this (like Armory), is to popup a warning if a user sends one transaction, and then later attempts to send a second transaction that requires unconfirmed change.  

-- If they are not spending unconfirmed change, nothing needs to be done.  User is not inconvenienced.
-- If they are, pop up a message to the effect of:

This transaction may have problems reaching its intended recipient(s) if you send it right now.  You might have to re-create and sign a replacement unless you wait for your previous transactions to be confirmed by the network.  

To avoid these issues, please wait until all previous transactions in the ledger have at least one confirmation, and then restart the "Send Bitcoin" procedure as before.

[Send Anyway] [I'll Wait]

I suppose a better alternative would be to hold the key data in RAM until your tx is confirmed, and sign a new transaction with the new txid, if the first one is mutated.  Perhaps even broadcast the first one, but immediately sign and broadcast the replacement if the first one is invalidated.  I prefer the first one though (where the software just waits before doing anything), which is a bit cleaner.

This transaction may have problems reaching its intended recipient(s) if you send it right now.  You must wait for your previous transactions to become confirmed.  If you click "Send when Ready", Armory will queue the transaction to be sent at that time.  If you close Armory before you see it appear in the transaction ledger, you will have to re-send it next time you start Armory.

[Cancel] [Send when Ready]

I think either one would be fine and far superior to the wallet without warning creating a tx which it "knows" may be broken in the future.  Personally I prefer the first one only because I am "security paranoid".  The second option is more user friendly but the jump to creating and broadcasting tx automatically shouldn't be taken lightly.  Either way advanced users if they have a specific need could always disable this warning via an option in the menus (i.e. [ ] Do not warn on creating transaction with unconfirmed input).

This limitation is most likely to affect users with a small number of confirmed unspent outputs.  A way to improve the user experience would be for the client to be a little proactive about "output management".

A user who has 100 BTC as a single unspent output spends 1 BTC.  Most clients today would make that In: 100BTC, Out: 1 BTC & 99 BTC.  However if the client seeing this tx will reduce the "unspent output pool" below some safety margin would instead make it Out: 1 BTC, 49 BTC, 50 BTC.   Now once this tx confirms the user could potentially two more txs before, even being presented with the warning.

Just an idea.  It is far less critical than what I put in the OP but sometimes solving a problem means making the problem less likely to occur in the first place.

[etotheipi]

I suppose a better alternative would be to hold the key data in RAM until your tx is confirmed, and sign a new transaction with the new txid, if the first one is mutated.  Perhaps even broadcast the first one, but immediately sign and broadcast the replacement if the first one is invalidated.  I prefer the first one though (where the software just waits before doing anything), which is a bit cleaner.

Interesting.  In my example (https://bitcointalk.org/index.php?topic=459678.msg5113081#msg5113081) where the customer's donut purchase is invalidated because his coffee purchase was malled, the wallet would realize this and then send out a new transaction to remedy the situation [which may occur after the customer has left the store and without his knowledge].

So, the customer could still pay instantly, even if they have no confirmed outputs.  Provided the customer is honest (which we already need to assume), the merchant will still get paid even if the parent transaction gets malled by an attacker: the wallet just checks for malling and, if so, sends a replacement TX to fix the problem.   

My concern with this is that the customer turns off their phone or turns off their computer, and the replacement tx never gets sent.  Yet, they saw the "This invoice has been paid" message and didn't realize that it wasn't guaranteed.  I'd rather they see nothing positive until the tx is done.

But that also assumes that all tx will be mutated.  Thus there's no point to doing the first tx.  If the standard case is no mutations, it might work.

But I am deeply concerned that people will find themselves accidentally reversing paying for their doughnut, and then refusing to allow the replacement tx to go through.   i.e. They pay, turn off their device, turn it back on later, and it tells them the payment never went through, please re-type your password to re-send... "hmm, if I just don't type my password, that was a free doughnut!"

It's one of those things, that makes me feel like the empirical reliability of zero-conf tx allowed too many businesses to build services around them, which can't be supported now.  Technically, you could do an ETF from your bank to pay for your doughnut, or pay with gold flakes, but we don't because the timelines and convenience make it infeasible.  I would argue that Bitcoin should be treated somewhat the same way, and it was only a matter of time before the illusion fell apart.

Bitcoin is fantastic for a whole lot of things, but Point-of-Sale doesn't seem to be one of them.

[Rampion]

It's one of those things, that makes me feel like the empirical reliability of zero-conf tx allowed too many businesses to build services around them, which can't be supported now.  Technically, you could do an ETF from your bank to pay for your doughnut, or pay with gold flakes, but we don't because the timelines and convenience make it infeasible.  I would argue that Bitcoin should be treated somewhat the same way, and it was only a matter of time before the illusion fell apart.

Bitcoin is fantastic for a whole lot of things, but Point-of-Sale doesn't seem to be one of them.

Quite true - but it doesn't change the fact this will be quite a hit for some people that assumed that 0-conf could work in certain - and useful - circumstances.

I sense that a clone of Bitcoin that just fixes the malleability issue by not allowing txid to be mutated could get a lot of publicity ATM.

[Peter R]

It's one of those things, that makes me feel like the empirical reliability of zero-conf tx allowed too many businesses to build services around them, which can't be supported now.  Technically, you could do an ETF from your bank to pay for your doughnut, or pay with gold flakes, but we don't because the timelines and convenience make it infeasible.  I would argue that Bitcoin should be treated somewhat the same way, and it was only a matter of time before the illusion fell apart.

Bitcoin is fantastic for a whole lot of things, but Point-of-Sale doesn't seem to be one of them.

Quite true - but it doesn't change the fact this will be quite a hit for some people that assumed that 0-conf could work in certain - and useful - circumstances.

I sense that a clone of Bitcoin that just fixes the malleability issue by not allowing txid to be mutated could get a lot of publicity ATM.

It affects more than just point-of-sales at brick-and-mortar stores too.  My wife purchases Gyft cards for Amazon, BR, Sephore, etc., all the time.  (I bet she's their best customer  )  Basically, she opens up gyft.com on her Mac, clicks "buy $200 Amazon gift card", then scans the QR code and pays.  She might buy a few cards in a row and then she wants to use them NOW.  The fact that Gyft transfers these cards to her instantly upon receipt of the zero-confirmation transaction is exactly what makes using bitcoin more pleasant than a credit card.  If she had to wait 10 minutes before seeing the Amazon card credited to her account, I bet she would not use Gyft (and thus bitcoin) at all.  

If we make bitcoin more annoying and slower to use, it will greatly detract from adoption.  

We need reliable zero-confirm transactions between honest participants. 

[Carlton Banks]

I'm not very technical, maybe this isn't the right thread to ask but the attack that is happening this week.

A “massive and concerted attack” has been launched by a bot system on numerous bitcoin exchanges

Could somebody tell me whether the person/group doing it need a lot of Bitcoins to pull it off or just computing power?

No bitcoin balances are required. Powerful computer not required either, but lots of attack machines with good internet connections would make it more effective. Locating those machines physically closeby to the servers for Mt Gox, Bitstamp, Coinbase, BTC-e and other targeted sites would also make it more effective.

And you do need to use a copy of the bitcoin software, to send the mutated transactions out with. To make the spamming more effective, the attacker might modify the source code of the bitcoin software so that the original transaction with the original id number isn't sent to the rest of the network. Almost certainly, that was done in the case of this attack.

[DeathAndTaxes]

It's one of those things, that makes me feel like the empirical reliability of zero-conf tx allowed too many businesses to build services around them, which can't be supported now.  Technically, you could do an ETF from your bank to pay for your doughnut, or pay with gold flakes, but we don't because the timelines and convenience make it infeasible.  I would argue that Bitcoin should be treated somewhat the same way, and it was only a matter of time before the illusion fell apart.

I am confident that eventually tx ids will be immutable.  Sipa proposal seems to be a good way forward and it can be done gradually (favor "better over "worse", then consider "worse" nonstandard, then eventually "worse" is invalid at the protocol level).  It is a complex issue because there are multiple ways to mutate a tx.  

Long term goal should be immutable tx ids.
Short term goal should be to minimize the disruption caused by tx id mutability.

As a side note alt-coin designers if you actually want to improve on Bitcoin and not make a pump and dump, don't make the signature part of the transaction input have it follow the tx body and sign the entire transaction.

Bitcoin
-----------------------
<some stuff here>
Inputs (including signature inside)
<some extra stuff here>
Output
<some extra stuff here too>

Better
--------------------------
Header
Input(s)
Output(s)
Signature(s)

The tx body is the header, inputs, and outputs.  Hash the body you get the tx id.  Use the same hash and the private key for each input to produce the signatures.  Append the signatures to the tx body and broadcast the whole thing.   You don't even need to provide pubkey in the input as it can be reconstructed from the signature.  I am not really sure if Satoshi was drunk the day he came up with how to sign transactions but it has to be the most overly complex, convoluted system which really provides no benefit and lot of edge cases.  Compared to the elegance of other parts of the design is seems out of place.  I can't think of a cryptographic system where you sign a payload and then put the signature back into the payload.  It is normally payload & signature.

[gacrux]

Bitcoin is fantastic for a whole lot of things, but Point-of-Sale doesn't seem to be one of them.

I disagree.This is a very popular use case, and there's no reason that it can't work "well enough" in the real world.

Consider this typical scenario of a pub selling beer for bitcoin:
* we have a well connected node
* we receive a ZC txn for the beer composed entirely of confirmed UTXO as its inputs (even just 1 block deep)
* we listen for N seconds and do not observe other txns that double spend our ZC txn's inputs
* our ZC txn pays the appropriate fee to be included in a block quickly

Should we give the beer to this bloke right away, or wait for his txn to make it into a block?

I'd argue we're pretty safe just giving him his beer. It's worth all of $5.50, and the chance of a double spend invalidating that txn, given the above observations, is vanishingly small. Yes, he might:
* have a node connected to hashpower we're not aware of / well connected to
* be able to broadcast his double spend txn to that part of the network without us noticing it
* be lucky and get it into a block
* be really fast at drinking his beer and running out the door

But it's not bloody likely :-)

Honest customers will always outnumber this guy 1000:1.

[Peter R]

Bitcoin is fantastic for a whole lot of things, but Point-of-Sale doesn't seem to be one of them.

I disagree.This is a very popular use case, and there's no reason that it can't work "well enough" in the real world.

Consider this typical scenario of a pub selling beer for bitcoin:
* we have a well connected node
* we receive a ZC txn for the beer composed entirely of confirmed UTXO as its inputs (even just 1 block deep)
* we listen for N seconds and do not observe other txns that double spend our ZC txn's inputs
* our ZC txn pays the appropriate fee to be included in a block quickly

Should we give the beer to this bloke right away, or wait for his txn to make it into a block?

I'd argue we're pretty safe just giving him his beer. It's worth all of $5.50, and the chance of a double spend invalidating that txn, given the above observations, is vanishingly small. Yes, he might:
* have a node connected to hashpower we're not aware of / well connected to
* be able to broadcast his double spend txn to that part of the network without us noticing it
* be lucky and get it into a block
* be really fast at drinking his beer and running out the door

But it's not bloody likely :-)

Honest customers will always outnumber this guy 1000:1.

I think you're muddling two debates into one.  Prior to the risk of malleability attack, zero-confirm transactions for purchasing beer here in Vancouver were reliable regardless of whether the transaction used confirmed or unconfirmed change outputs.  So we already know that, malleability-problem aside, zero confirm transactions work for low-value PoS purchases.  

The ability of shop-keepers (and BitPay) to continue accepting zero-confirm transactions is complicated now because when the network is under malleability attack, zero-confirm transactions built from unconfirmed change outputs are not reliable.

We can restore the reliability of zero-confirm transactions to how secure we thought they were (in our blissful ignorance) if we disallow using unconfirmed change.  But there's still a bunch of complications, for instance:

- What should BitPay do if it receives a valid transaction that was built using unconfirmed outputs while the network was under malleability attack?

- What happens when Bob has a large balance on his phone but no confirmed coins to purchase that martini for the adorable girl he just met?  [I have money, I swear.  I just need to wait for the next block to confirm     Declined my friend!]

[gacrux]

Bitcoin is fantastic for a whole lot of things, but Point-of-Sale doesn't seem to be one of them.

I disagree.This is a very popular use case, and there's no reason that it can't work "well enough" in the real world.

Consider this typical scenario of a pub selling beer for bitcoin:
* we have a well connected node
* we receive a ZC txn for the beer composed entirely of confirmed UTXO as its inputs (even just 1 block deep)
* we listen for N seconds and do not observe other txns that double spend our ZC txn's inputs
* our ZC txn pays the appropriate fee to be included in a block quickly

Should we give the beer to this bloke right away, or wait for his txn to make it into a block?

I'd argue we're pretty safe just giving him his beer. It's worth all of $5.50, and the chance of a double spend invalidating that txn, given the above observations, is vanishingly small. Yes, he might:
* have a node connected to hashpower we're not aware of / well connected to
* be able to broadcast his double spend txn to that part of the network without us noticing it
* be lucky and get it into a block
* be really fast at drinking his beer and running out the door

But it's not bloody likely :-)

Honest customers will always outnumber this guy 1000:1.

I think you're muddling two debates into one.  Prior to the risk of malleability attack, zero-confirm transactions for purchasing beer here in Vancouver were reliable regardless of whether the transaction used confirmed or unconfirmed change outputs.  So we already know that, malleability-problem aside, zero confirm transactions work for low-value PoS purchases.  

The ability of shop-keepers (and BitPay) to continue accepting zero-confirm transactions is complicated now because when the network is under malleability attack, zero-confirm transactions built from unconfirmed change outputs are not reliable.

I was responding to etotheipi's opinion that we should just write off PoS applications as not viable.

Ideally we'd have some sort of "PoS applications standard" that popular / "well behaved" mobile wallet apps would adhere to:
* never send a TX using any unconfirmed UTXO as an input
* never send a TX without the appropriate fee
* (something else?)

Andreas Schildbach's android wallet already forces #2. And we could potentially do away with #1 in future, once TX mutability is fixed properly.

All PoS systems could accept a zero conf TX only if it meets the standard, otherwise wait for a block before displaying "PAID" to the operator. ie. the PoS system should be as defensive as practical, but in a well publicised, well defined way. Then it's up to the customer to use a wallet app that conforms to this standard if he doesn't want to wait at the counter.

- What should BitPay do if it receives a valid transaction that was built using unconfirmed outputs while the network was under malleability attack?

As per the standard I propose: ignore it until it makes it into a block.
If this behaviour was standard then customers / wallet apps would quickly learn better than to do this.

- What happens when Bob has a large balance on his phone but no confirmed coins to purchase that martini for the adorable girl he just met?  [I have money, I swear.  I just need to wait for the next block to confirm     Declined my friend!]

It remains to be seen how big an issue this would be in practice. As was suggested elsewhere in this thread,
a wallet could have a "fragmentation threshold" that it attempts to maintain, eg. by splitting change to itself, which would help mitigate this.

Of course, in an ideal world our wallets will all do an opportunistic CoinJoin whereever possible too ;-) That'll require a certain level of fragmentation to be effective anyway.

Maintaining a single large UTXO, slicing a little bit off every time you make a payment, and returning change in another single large UTXO... just isn't viable from a financial privacy point of view anyway.

[Syke]

Bitcoin is fantastic for a whole lot of things, but Point-of-Sale doesn't seem to be one of them.

There are ways to improve PoS, but the PoS has to be smarter than simply accepting any zero-confirm transaction. It needs to analyze the network and the transaction: how well it is connected to peers, if it sees any malling/double-spending of the current transaction, if a fee was included, if there is a chain of unconfirmed inputs, etc.

[justusranvier]

There are ways to improve PoS, but the PoS has to be smarter than simply accepting any zero-confirm transaction. It needs to analyze the network and the transaction: how well it is connected to peers, if it sees any malling/double-spending of the current transaction, if a fee was included, if there is a chain of unconfirmed inputs, etc.

Sounds like a job for a payment processor.

[tvbcof]

I'm not very technical, maybe this isn't the right thread to ask but the attack that is happening this week.

A “massive and concerted attack” has been launched by a bot system on numerous bitcoin exchanges

Could somebody tell me whether the person/group doing it need a lot of Bitcoins to pull it off or just computing power?

No bitcoin balances are required. Powerful computer not required either, but lots of attack machines with good internet connections would make it more effective. Locating those machines physically closeby to the servers for Mt Gox, Bitstamp, Coinbase, BTC-e and other targeted sites would also make it more effective.

And you do need to use a copy of the bitcoin software, to send the mutated transactions out with. To make the spamming more effective, the attacker might modify the source code of the bitcoin software so that the original transaction with the original id number isn't sent to the rest of the network. Almost certainly, that was done in the case of this attack.

It may not be the case that 'logs of attack machines' were needed, nor that the the software was especially based on the Bitcoin reference code.  This incident brings back and old memory:

"Impact of my DDoS tool is very small, as long as only a few people are running my DDoS tool." You see the problem here...

If I wanted to make DDoS tool, I'd make one. I did not ask people to run it, people asked for code. If bitcoin network can be brought down by couple weak PCs, then something needs to be done to "standard client". There I see the problem.

That thread, and a sister thread where the guy used the code to map out and analyze the entire Bitcoin network are interesting and worth the read whether or not they are related to this attack.  I expect that we'll see many copy-cat attacks along the lines of the one under discussion here going forward.  I'm deeply surprised that it took this long to be honest.

[tx42]

Until transaction ids are immutable, allowing users to spend unconfirmed change outputs is just going to cause chaos.

I should read the code, but I would assume that the transaction ID is a 256 bit hash of the transaction details. If so, then it should take quite a birthday attack to create a valid alternate transaction ID. If the ID isn't a hash of the transaction details, then where is the hole in this idea, because it seems readily obvious.