I could not believe the idiot dared to blame the Bitcoin protocol.
i hope i am wrong. but i begin to think that they lost so much btc to this issue that they need to buy coins.
|
|
|
Second fix I've come up with for you in the past hour of being awake (spent the first 30 mins of it freaking out after seeing btc-e price too). Use a unique change address for each withdrawal. Makes it easy for you to know if a withdrawal went though
if (deposit to change address) { withdraw succeeded } else { reissue transaction }
this could make problems if you are using multiple wallets which needs to keep in sync (i dont know if mtgox uses that though). the easiest solution is still: do what the reference client does! instead of txid just use in/ouputs as a comparison. problem solved.
|
|
|
Technically you don't even need to do that because the client/wallet already does it but for customer support it likely is easier to have that information available outside of the wallet. The wallet solves different problems, it's like a piggy bank, it only cares about what goes in and out, with limited attribution capability. In the grand scheme of things, exchanges should not be using the wallet, just like stock exchanges aren't run with Excel spreadsheets and VB macros. but you agree that if an exchange builds there own wallet software they are responsible for it? i repeat: it is easy to check. just dont use txid for comparison instead use input and outputs (and i dont mean addresses). it is public knowledge: every wallet developer should closely follow bitcoin changes and bugs. if mtgox had done that they could have avoided this desaster
|
|
|
Once the volume is large enough, that's exploitable as well if the exchange doesn't spam the blockchain with unique withdrawal addresses (since you'll get or can manufacture duplicates).
outputs != withdraw address its very easy to do and bitcoind does it. just mtgox thought txid is ok: and i expect a major exchange which custom software to follow bitcoin changes closely: so they should have known it before
|
|
|
Just improve the damn protocol.
nope its enough when mtgox does the same as the bitcoind wallet: check for outputs and dont rely on txid alone. you really want a hardfork because one company did fuck up their custom client? <sarcasm>while we are at it we could also reverse the transactions which stole money from gox
|
|
|
Solution: do not re-use addresses. Send all change to another address, and track spends on the blockchain using the sending address... No chance of duplicated tracking data (the sending address basically becomes your tx hash). voila. Bo problem here other then MtGox incompetance. Demanding a change to the core protocol is ridiculous.
bitcoinfoundation....how much influence does mtgox have? i am very interested to see how this will end.
|
|
|
now it is time to buy litecoin ! Since litecoin is a clone of bitcoin, they probably have the same problem. Note that although this is technically a flaw in the bitcoin protocol, it is not a serious one, at least not once it is known. It just means that before you conclude that a transaction did not make it into the blockchain, you have to check the blockchain a bit more carefully. Isn't the flaw with the software they are currently using? If they updated I think it'd be fine. hey cant update as they have developed it theirself... and they managed to overlook a bug whixh is fixed in bitcoin for about 3 years i'd like to know how much has been stolen
|
|
|
i'd like to know how much has been stolen.
|
|
|
How could the transaction be changed without needing to be re-signed? I lack the technical knowledge to understand how what you describe is possible.
You don't touch the actual signature, but there are meta-data around it. In a recent version of the official bitcoin client the format of that meta-data has been tightened so the transaction data provided by MtGox is now being rejected by the latest official version. A hacker can then take the rejected raw txdata provided from MtGox, patch it and rebroadcast it. It will get through, but MtGox still thinks it is invalid and returns balance. I don't think I buy your explanation without providing more details. Can you provided more details? What is the new version of the bitcoin client that caused the problem? When the version was released and when the problems started at MtGox? What are the changes on the format that were problematic? I understand that if your theory is correct, there should be initially stuck transactions that finally went through in the blockchain (the modified hacker's version). Can you provide examples of these transactions? (that appeared first in the list of stuck transactions and then went through). sadly its true. just read the reddit: gmaxwell explains it well
|
|
|
Thanks for your support. Unfortunately, I cannot reveal my sources.
He's just posting a garbled rewrite of this post on Reddit. nullc has access to the same facts as me. His post is more into the actual technical details of the exploit. The intention of my post is to bring this topic to higher level because the concept itself is a real problem that exchanges should be aware of. not really. its just that mtgox instead of looking at their coins just looks if the tx they have created goes through - and only in that case subtracts some kind of internal balance. i dont think any other service works this way. just crappy coders there. but you may be right that this could be used to steal btc from gox. but i dont know if mtgox actually refunded tx which they think did not get through (but did because of the changed txid).
|
|
|
Even if the 2nd isn't included in the blockchain, if the site accepts 0 confirmations, then it is still credited.
have you tested this? afaik bitcoind prohibits a transaction which inputs has already been spent in his mempool EDIT: btw this is not a protocol issue. its up to the client how to handle 0confs and transaction which uses already spent inputs. the protocol just supplies the info necessary to make this decision
|
|
|
You have to remember that IF you keep money ONLINE
IF they will LOST their wallets, database etc.
You MIGHT have some problems with getting back your money.
I guess blockchain will payback all eventyally lost. BUT - it is BETTER to keep your bitcoins on some storage devices.
You can make your own copy, even print it and you do not have to worry about it.
Keeping money online might cause some risk.
blockchain.info allows regular backups of the privkeys per mail or dropbox. so i am not afraid that they will vanish. as they dont know my privkeys i am not very concerned that they get robbed or try to rob me. keylogger, dns spoofing could be more problematic
|
|
|
Hi everyone. I'd like to launch my bitcoin bank. Basically, it would work like this: Investor | | (1BTC) | Bank | | (1BTC) | Guy Who Wants A Loan | | (1BTC + Interest (10%) | Bank | | (1BTC + Interest (7%) | Investor Any comments before I start designing the website? A bank isn't something you start on a whim after drawing a doodle on a napkin, nor does starting it consist of "designing the website". If it's not immediately clear to you why citizen banking is a bad idea in general, I'd suggest paying the first person you can find who can draw a flow chart of themselves, your torso, and a scalpel to perform heart surgery on you; on the off-chance you survive, the recovery time'd make for good reconsidering. +1 wow, this is the first time i totally agree with you and you've been (somewhat) nice! just wow... continue that way and it may be that i even like you!
|
|
|
150BTC many thanks to Bitcoinica, genjix and PhantomCircuit that i now only have a fraction left
|
|
|
Anyone who takes an interest bearing loan in bitcoins is either stupid or is intending to default. Due to rising difficulty it's always becoming harder to create more bitcoins. Where does the person who got the 1 BTC loan get the 10% interest from? They have to work really hard to get it. In a scenario where difficulty skyrockets due to BFL getting their Monarchs online and other ASIC hardware, it may become extremely difficult to get enough BTC to pay the interest.
What if the debtor is running a shop and trades their way to a profit and can pay off the interest? You have the same problem. Prices in BTC terms are constantly falling for pretty much everything. Have a look at what mining hardware cost a year ago, and what it costs now.
Paying off interest in a currency that's inflating is easy. Paying off interest in a deflationary currency is economic suicide.
see bitfinex for a working btc loan market. difficulty will not always rise (and did not in bitcoins history btw there where times when it got down a little) the only reason for a btc loan i can imagine is that somebody wants to go short (which is valid). i found that 105% colleteral quite amusing: if the price goes up by more than 5% you'll loose (and op still didnt answer who suffers the loss: bank or customer?) also: does the colleteral have to be transferred to the bank before the loan? otherwise it could be cheated.
|
|
|
how do you handle defaults? who suffers from a default?
|
|
|
i'd like to know who classified that secret.
|
|
|
i like their hardware but really thinks their software policies are crap. they could be so much more if they realise that their customers can think
ive had an iphone once (for about two weeks) never again
|
|
|
i am ok with the alt-section as long it would focus on technical improvements or do some real inventions. but there are nearly none.
as of now bitcointalk is just given them free marketing and an existing userbase.
|
|
|
Being a C# developer I love seeing this project. However, I do agree that hot wallets are a huge risk. Keeping everyone's coin in a single wallet.dat is scary. What if you were to write a class that generated the keys in memory, encrypted them with the users password as key, then save each users wallet to it's own .dat file. Never storing their password. Not using the bitcoind at all for key generation.
If you're looking for someone to collaborate with or discuss ideas with I can help.
blockchain.info's does this and it works quite well but i would never put all my coins in one basket again. what i might use: a balance watcher which allows to send by providing a privkey. after sending i would not use this address ever again
|
|
|
|