 Show Posts
|
|
Pages: [1]
|
You're not listening. MtGox built their own subway with flawed doors. Only MtGox can fix those doors.
Oh, I am listening. The problem isn't with the doors (as far as we know). Had it been the doors, a wall wouldn't help. |
|
|
|
|
OK, let's try a little experiment.
Suppose you're in charge of the London Underground, and you're having the slight annoyance of an occasional passenger being run over by a train.
You could:
1. play a recording saying "Mind the gap" every ten seconds or
2. put a wall with sliding doors between the platform and the train.
Which one would you choose?
|
|
|
|
They fucked up by assuming that if the txid they sent didn't make it into a block, then no other txid could have spent those coins so they didn't bother checking the blockchain to make sure that was the case.
Wasn't that a reasonable conclusion from sendtoaddress being updated to return a txid? |
|
|
|
Transactions have always been malleable prior to being included in a block. This wasn't really apparent until 2011.
Maybe they were, but this certainly didn't help: I'm proposing one small change to Bitcoin's JSON-RPC api: return a transaction ID when Bitcoins are successfully sent.
Why? Because I want to keep a complete audit trail for any coins going into or coming out of my application's wallet; I want to keep track of the particular transactions in the bitcoin network that correspond to actions my application takes. The alternative is to call sendtoaddress and then call listtransactions, but that won't work properly if two similar transactions (same amount to same address) occur at about the same time. |
|
|
|
In 2010. If I recall correctly 2010 is before 2011.
So the transaction malleability problem was created in 2010 and reported in 2011. |
|
|
|
This address too: 1SochiWwFFySPjQoi2biVftXn8NRPCSQC
The Sochi Olympics organizers are trying to ride on the wave of Bitcoin popularity  |
|
|
|
|
This is great news. It's just too bad bitcoin traders represent a fraction of users that's even smaller than Bing users...
|
|
|
|
italian, swedish or texan people will probably beat the japanese to it.
You know MtGox is not a japanese company, right?
The Texan people probably won't get past airport security (with their firearms and all)... |
|
|
|
|
Thanks for contributing, LostDutchman and bitcoinminer!
|
|
|
|
The problem is not "why is it not done yet", but more "why is it more urgent than taking care of bitcoin's ability to handle much larger transaction volume"?
That seems like a 1.0 feature to me. Addressing transaction malleability, on the other hand, could fit just fine in the 0.x.x roadmap. Nobody (at least to my knowledge) said anything about fixing it overnight. I'm not saying Mt. Gox are the good guys here (they clearly screwed up), but shouldn't Gavin Andresen have accepted some responsibility? |
|
|
|
|
Sounds great, provided Mt. Gox can easily modify their wallet backend, which they proved incapable of (at least according to the Core devs).
|
|
|
|
Because it wasn't considered to be high priority problem.
So why not just state that instead of talking about correcting overnight? |
|
|
|
I started a separate topic by mistake, so I'll repost it here: I hate to be the devil's advocate here (especially being a newbie), but how does "known about since 2011" fit with "cannot be corrected overnight"?
|
|
|
|
Nights are extremely long on Mt. GOXXX. They don't experience Linear Time as we do, down here on Earth.
Also there is no concept of ownership. "Your Coins" are "Our Coins".
Actually, I was quoting Gavin Andresen of the BTC Foundation. |
|
|
|
Actually, I was interested in an answer to my question: I hate to be the devil's advocate here (especially being a newbie), but how does "known about since 2011" fit with "cannot be corrected overnight"?
|
|
|
|
The issues that Mt. Gox has been experiencing are due to an unfortunate interaction between Mt. Gox’s implementation of their highly customized wallet software, their customer support procedures, and their unpreparedness for transaction malleability, a technical detail that allows changes to the way transactions are identified.
Transaction malleability has been known about since 2011. In simplest of terms, it is a small window where transaction ID’s can be “renamed” before being confirmed in the blockchain. This is something that cannot be corrected overnight. Therefore, any company dealing with Bitcoin transactions and have coded their own wallet software should responsibly prepare for this possibility and include in their software a way to validate transaction ID’s. Otherwise, it can result in Bitcoin loss and headache for everyone involved.
The Bitcoin core development team has worked to limit transaction malleability. There is broad agreement in the community that this needs to be eliminated. Finding the best and most responsible solution will take time. In the meantime, users of the reference implementation do not need to be concerned. Transactions are always tracked properly by the Bitcoin-Qt/bitcoind software.
This is a good reminder that Bitcoin is still young and experimental. There are best practices to think about and account for by those who want to build companies. To help improve both the reference implementation and third party software, the Foundation is committed to working with companies to produce best practices to help improve software. I hate to be the devil's advocate here (especially being a newbie), but how does "known about since 2011" fit with "cannot be corrected overnight"? Edit: Changed the subject to clarify the question. |
|
|
|
|
