Pages:
Author

Topic: Contrary to Mt.Gox’s Statement, Bitcoin is not at fault - Gavin Andresen 10/2/14 - page 3. (Read 13141 times)

full member
Activity: 157
Merit: 100
Adding any new requirement would "break" the protocol. Changing the behavior of signature production/requiring a new field in the transaction indicating which input signed the txid, would make all old wallet/miners/clients/exchange software unoperative.

It would require forking the chain, because the blockchain does not actually contain that info. (I guess though the whole transaction signature might be dropped when the transaction is included in the chain; but then it would be only an "voluntary" rule enforced by miner to NOT include a mutated transaction by a third party.)

Anyway, such "breaking" behavior is generally undesirable.[…]

There is always the possibility to create an alternative format and make it mandatory, starting with block 12345 some time in the future.

Obviously the clients would have to be able to process both the old format (before block 12345) and the new (block 12345 and beyond).

It is a fork, but it could be pre-announced well in time, if a large majority of miners agree.

Of course! Bitcoin has already done that a few time.

But even if the change makes total sense, and all miners agree to it, it is still something the devs try to avoid as much as possible. Because it renders all unupdated clients non-functionnal. One could say "they just had to update", but sometimes it is not easy. For example, I remember seeing a pool table which could accept bitoin payments to release the balls. It is embedded electronics. Updating that is not easy. In any case, it is bad PR to have some people's software break because of an update, even it is their own fault.

Thus the devs usually try to bunch such "breaking" changes in a single update to minimize the need for such updates, and only do it when a compelling problem requires it. The mutability problem had not been compelling enough before, but it is now.
hero member
Activity: 695
Merit: 500
Adding any new requirement would "break" the protocol. Changing the behavior of signature production/requiring a new field in the transaction indicating which input signed the txid, would make all old wallet/miners/clients/exchange software unoperative.

It would require forking the chain, because the blockchain does not actually contain that info. (I guess though the whole transaction signature might be dropped when the transaction is included in the chain; but then it would be only an "voluntary" rule enforced by miner to NOT include a mutated transaction by a third party.)

Anyway, such "breaking" behavior is generally undesirable.[…]

There is always the possibility to create an alternative format and make it mandatory, starting with block 12345 some time in the future.

Obviously the clients would have to be able to process both the old format (before block 12345) and the new (block 12345 and beyond).

It is a fork, but it could be pre-announced well in time, if a large majority of miners agree.

Fundamentally, if the bitcoin algorithm could not be repaired and improved, it would die an early death.
full member
Activity: 157
Merit: 100
Why not sign the entire transaction including the TXID?

Any random one? Even with thousands of inputs an attacker wouldn't be able to sign a mutated ID with any of the inputs.
Looking around I actually get the feeling that one of the reasons why this minor issue was left on the shelf was because there's so many different people with so many possible different solutions.

Adding any new requirement would "break" the protocol. Changing the behavior of signature production/requiring a new field in the transaction indicating which input signed the txid, would make all old wallet/miners/clients/exchange software unoperative.

It would require forking the chain, because the blockchain does not actually contain that info. (I guess though the whole transaction signature might be dropped when the transaction is included in the chain; but then it would be only an "voluntary" rule enforced by miner to NOT include a mutated transaction by a third party.)

Anyway, such "breaking" behavior is generally undesirable. The devs were trying to come up with a unique "canonical" way to construct a transaction such as there is only ONE way to make a given transaction, so that the resulting txid is unique too. A pool recieving a non-canonical transaction would mutate it before inclusion. Software requiring specific txid would make sure of producing a canonical transaction.

That way we would introduce a new desirable behavior, without breaking anything.

Looking around I actually get the feeling that one of the reasons why this minor issue was left on the shelf was because there's so many different people with so many possible different solutions.

In fact I feel it is EXACTLY that.

That, and that, any change cannot be made overnight. And requires a few month of developpement/testing/deployment before thinking of enforcing it. -> A very complicated process for a "non-bug", if people had read the specs and had not assumed txid were non-mutable.

(un)fortunately, the current crisis provides an opportunity to act much more quickly, because we already -do- have broken behavior, it can't get much worse. It can now be "spun" as a critical update that anybody must implement to continue to be able to use bitcoin.
legendary
Activity: 1176
Merit: 1005
Anyway, bitcoin foundation is working to find a quick and effective solution, so our bitcoins are safe Wink

Your BITCOINS have ALWAYS been safe.  What has not been safe, necessarily, is balances in exchanges, which are not actually Bitcoins, any more than your money in a bank is actually dollars.
legendary
Activity: 1100
Merit: 1032
Sign it with which private key?  A tx can (and usually does) have multiple inputs.
Any random one, doesn't really matter as long as it can't be changed and can be verified, no?

A "good practice" could be to use that of the first or last input (to speed up verification). The (non-compulsory) ordering could be done when submitting (by the wallet) or when mining the transaction (as a courtesy from miners).
hero member
Activity: 742
Merit: 500
[…]
To clarify further: in an transaction, only the inputs, the outputs and the amount are signed. The TXID is -not- signed, and thus can be changed by anybody while keeping the transaction valid. It is -not- a bug, it's a design choice. The Bitcoin protocol never stated that the TXID was to be unchangeable, and thus nobody should have expected that in their software.

One can uniquely track transactions otherwise. Even if the TXID is changes, the inputs are not. Thus one can know if a transaction went trough by checking if a given input has been spent according to the blockchain.

Why not sign the entire transaction including the TXID?

Sign it with which private key?  A tx can (and usually does) have multiple inputs.

Any random one? Even with thousands of inputs an attacker wouldn't be able to sign a mutated ID with any of the inputs.

Looking around I actually get the feeling that one of the reasons why this minor issue was left on the shelf was because there's so many different people with so many possible different solutions.

donator
Activity: 1218
Merit: 1079
Gerald Davis
[…]
To clarify further: in an transaction, only the inputs, the outputs and the amount are signed. The TXID is -not- signed, and thus can be changed by anybody while keeping the transaction valid. It is -not- a bug, it's a design choice. The Bitcoin protocol never stated that the TXID was to be unchangeable, and thus nobody should have expected that in their software.

One can uniquely track transactions otherwise. Even if the TXID is changes, the inputs are not. Thus one can know if a transaction went trough by checking if a given input has been spent according to the blockchain.

Why not sign the entire transaction including the TXID?

Sign it with which private key?  A tx can (and usually does) have multiple inputs.
hero member
Activity: 695
Merit: 500
[…]
To clarify further: in an transaction, only the inputs, the outputs and the amount are signed. The TXID is -not- signed, and thus can be changed by anybody while keeping the transaction valid. It is -not- a bug, it's a design choice. The Bitcoin protocol never stated that the TXID was to be unchangeable, and thus nobody should have expected that in their software.

One can uniquely track transactions otherwise. Even if the TXID is changes, the inputs are not. Thus one can know if a transaction went trough by checking if a given input has been spent according to the blockchain.

Why not sign the entire transaction including the TXID?
legendary
Activity: 1100
Merit: 1032
As always on technology, the name of the game is "shit happens", and the subtitle is "the question is when, not if".

Hopefully some here will have learned a lesson: bitcoin is technology.

Technology is not about finger pointing or religious faith, it's about finding issues, fixing issues and moving everyone forward.

Everyone will mess up technology sooner or later, that's a fact, just like everyone will trip and fall someday.
Communities should be about helping those that fall get back on their feet, not kick them while they're down.

Great to see key proponents cooperating on this issue!
legendary
Activity: 1400
Merit: 1000


from Bitcoin Foundation:
Update on Transaction Malleability
Gavin Andresen    Feb 11 2014

You may have noticed that some exchanges have temporarily suspended withdrawals and wondering what’s going on or more importantly, what’s being done about it. You can be rest assured that we have identified the issue and are collectively and collaboratively working on a solution.
 
Somebody (or several somebodies) is taking advantage of the transaction malleability issue and relaying mutated versions of transactions. This is exposing bugs in both the reference implementation and some exchange’s software.
 
We (core dev team, developers at the exchanges, and even big mining pools) are creating workarounds and fixes right now. This is a denial-of-service attack; whoever is doing this is not stealing coins, but is succeeding in preventing some transactions from confirming. It’s important to note that DoS attacks do not affect people’s bitcoin wallets or funds.
 
Users of the reference implementation who are bitten by this bug may see their bitcoins “tied up” in unconfirmed transactions; we need to update the software to fix that bug, so when they upgrade those coins are returned to the wallet and are available to spend again. Only users who make multiple transactions in a short period of time will be affected.
 
As a result, exchanges are temporarily suspending withdrawals to protect customer funds and prevent funds from being misdirected.
 
Thanks for your patience. Follow us @BTCFoundation for updates as we learn more and make progress.




really interesting...  so MTGox was 100% right.

Also bitstamp.net temporarily suspended withdrawals...
https://www.bitstamp.net/article/bitcoin-withdraws-suspended/

Anyway, bitcoin foundation is working to find a quick and effective solution, so our bitcoins are safe Wink
newbie
Activity: 21
Merit: 0
You say that like it shouldn't be somebody's responsibility to provide me with it?

You are responsible for doing your own homework.  Nobody else is.
sr. member
Activity: 322
Merit: 252
I'm just glad I stopped using Gox that last time I was "Goxxed" this past May. The hand writing has been on the wall since way before then. They need to die out before they do anymore damage to Bitcoin. How many times now has a crash, dip or negative Bitcoin media attention been preceded by some sort of Gox malfunction?

I think maybe somebody, other than me because I'm lazy, should go through the forums and tally up all the GOXXXings.  I can think of at LEAST 3 big ones off the top of my head but I know there were more.
full member
Activity: 224
Merit: 100
DigiByte Founder
I'm just glad I stopped using Gox that last time I was "Goxxed" this past May. The hand writing has been on the wall since way before then. They need to die out before they do anymore damage to Bitcoin. How many times now has a crash, dip or negative Bitcoin media attention been preceded by some sort of Gox malfunction?
legendary
Activity: 4690
Merit: 1276
Suspension of other exchanges now for the same problem discredits Gavin's initial statement that the fault was all with Gox. 

Not really.  All of these businesses are trying to make Bitcoin into something it is not (yet) and most of them took more or less the same easy, and somewhat ignorant, road to doing so.

If anyone based their accounting on the potentially mutable tx-id they were either ignorant of it's nature, or just flat out ignorant.  Either of these mistakes calls into question their viability as a financial services business.  Big time.  They'd probably fail for some other reason if not this.

full member
Activity: 154
Merit: 100
Suspension of other exchanges now for the same problem discredits Gavin's initial statement that the fault was all with Gox. 
Why do you feel that it's unlikely that two exchanges can't both do it wrong, independently?

Surely the fact that bitcoin-qt isn't affected lends weight to Gavin's statements?
sr. member
Activity: 826
Merit: 250
CryptoTalk.Org - Get Paid for every Post!
Suspension of other exchanges now for the same problem discredits Gavin's initial statement that the fault was all with Gox. 
full member
Activity: 224
Merit: 104
Gox had a foolish way of checking whether people had been paid or not.  It's not inherently Bitcoin's fault that they did that.  It was clear that people would change transaction IDs so I really do think it was Gox that messed up.  Sure, Bitcoin and the Foundation can change it but it's not like BTC was inherently flawed.  It can be changed to make it easier in the future though.  But this selling, I do blame totally on Gox and I don't think you can disagree.
sr. member
Activity: 322
Merit: 252
Hopefully not. Can't believe they don't audit their balances continiously/from time to time an discover such drains just in time.

Why can't you believe it?
legendary
Activity: 1666
Merit: 1000

Can someone explain how the malleability problem is manifest?

I thought Gox like other waited for 3x confirmations in the Blockchain before acknowledging transfers into or out of a Gox account?

Gox creates a withdrawal and makes note of the TXID. Then, before it is included in a block, someone else changes the transaction such that only the TXID changes, but the transaction is still the same. When the new TXID gets included in the blockchain, the customer who requested the withdrawal claims they never received it. But they actually did! Gox looks up the old TXID and doesn't find it, so they create a whole new transaction and send another withdrawal to the customer. The customer has now been paid twice!!! This is solely Gox's problem because they do not correctly track transactions.
Hopefully not. Can't believe they don't audit their balances continiously/from time to time an discover such drains just in time.
Pages:
Jump to: