You could setup a certification that provides guidelines and specs on how to run an exchange. Think CSA, COR, ISO, ANSI, NACE. These are are guidelines that must be met. If its not met, you can not say your exchange is something like PBEA approved. (peoples bitcoin exchange association) Once up and running it would be in an exchanges best interest to get certified to attract new customers. The PBEA employs a handful of accountants that are paid by I have no idea who. Paid in tips? Someone other than the exchanges as that is just a conflict of interest. All useless. Rules enforced by humans aren't worth the electrons they're printed on. The only regulation that isn't a complete waste of time is cryptographic protocols expressed in and enforced by software. |
|
|
|
|
Hiding signatures doesn't provide feedback.
|
|
|
|
The stupidity of this action by mtGox is beyond comprehension. Is the CEO suicidal or what? Did he forget what his business-model is supposed to be and what he is supposed to be selling?
Either he is a complete and utter moron who thinks he can fix things by destroying the product he's selling in the public eye, or he's organizing some major inside trading scheme.
I thought it was incompetence for a long, long time. I'm starting to wonder... Maybe it's the businesses equivalent of " suicide by cop" - retirement by bankruptcy. |
|
|
|
|
Just ignore all posters who do that shit. Once their ignore indicators start to turn orange, the people paying them for those signatures will start to question the value of their investment.
|
|
|
|
You overstate your case, unless you wish to argue that Satoshi was not competent. Considering some of the bugs that made it into his initial release, it's at least safe to say he's a better cryptographer than software engineer. In any case, the reissue fraud is more or less independent of mutation. The way you protect yourself against double payment when reissuing is that you must spend at least some of the same coins so that only one transaction or the other can get mined. If you do this, no amount of mutation will result in funds loss (though it might confuse people!), if you don't do this then you can still have payments doubled up even with no mutation at all. (E.g. first payment delay, second authored, second gets confirmed, first gets rebroadcast and makes it in too). It appears that Mt Gox was trying to function using " dead reckoning" accounting by treating their internal database as canonical when in fact only the blockchain is canonical. This is incompetent accounting even in the fiat world - it's like going off your checkbook balance exclusively and never checking your actual bank account balance. (For everybody not born in ancient times, this is an analogy from the dark ages of the 1980s and 1990s). That's what I meant by being incompetent. If one of your UTXOs gets spent by being included in a transaction that makes it into the blockchain, your wallet should notice this regardless of anything else you think should be happening. Theirs didn't - if it did they wouldn't have this problem. This is in addition to other errors like not accounting for coin maturation and also their long, multi-year history of failing to respond to problems proactively when they are first pointed out as opposed to waiting for catastrophe to take action. |
|
|
|
Sure, they are responsible for it, but that doesn't absolve the Bitcoin devs from working out better solution, nor does it absolve the bitcoin community to all pile it on MtGox. This is an image issue there, look at the outside perception: - the obvious well defined transaction ID (a basic accounting principle) isn't guaranteed by bitcoin
- bunch of geeks says MtGox was wrong because of obscure incomprehensible reasons for most outsiders
- the biggest exchange obviously got it wrong on those incomprehensible reasons
- bitcoin devs resist change, giving an image of denial
- bitcoin community runs afraid screaming "hard fork" whenever a protocol change is mentioned
So that just gives an image of a fossilized complex tech that even large players get wrong. Just won't build much mainstream confidence, will it? There is no image problem, just altcoin pumpers who grasp at any straw to keep their exchange rates pumped up just a little bit longer. Same shit that's been going on for three years now. |
|
|
|
No, you haven't, because an address is not a wallet. |
|
|
|
is a mathematically true statement. is mathematically true, and in fact is the same statement. They've got different hash values though, because hash functions care about binary representations, not mathematical equivalence. |
|
|
|
The simple solution is to know what coins (UTXO) one owns and recognize if they are spend no matter with what hash. I can't comprehend why anyone would code a wallet that doesn't do this. There's no excuse for failing to notice relevant changes to the canonical source of your balance information, the blockchain. |
|
|
|
MtGox, continuing to prove the dunning-kruger effect
Their incompetence and arrogance really boggles the mind-- have they really not hired a consultant, ever? They really feel like they're this brilliant powerhouse that discovered this (non)-issue?
I'm willing to bet an exploit using this very tactic was reported dozens of times, only to fall into customer support limbo. And if that's the case, they deserve whatever lawsuit and/or criminal punishment is coming to them.
"The brillianty smart-people at MtGox have created a new way to store coins long term, in an encrypted zip file! MtGox a hub of innovation and security! A pillar of the community! We discover critical security flaws only after they've made us insolvent! HOORAY!"
Seriously this shit makes me rage so hard. Fade into irrelevance MtGox, you served your purpose, and now you're like a herpes sore that just refuses to dry up.
Had Mt Gox been competent at all when designing their custom wallet software, they would have noted that tx-ids are mutable, so not reliable as an identifier until after being confirmed in the blockchain. They also should have been tracking UTXOs directly, not just blindly assuming that as long as no transaction matching a tx-id they generated those outputs remained unspent. |
|
|
|
Unfortunately sender only have one shot. Should they underestimate the fee needed (as I just did), they face arbitrary delay during which funds are locked, since a subsequent attempt will be rejected by relay nodes as double spend. One can only wait until it confirms or drops out of the mempool. Both could be days. Only until 0.9 comes out. After that senders will receive failure messages that tell them why their transaction was rejected. I am also afraid that an automated adjustment will create a positive feedback loop in transaction fees, but think that it is inevitable, since hard coding some fee/KB can't keep up with changing environment. If markets were not a (the only) successful method of price discovery, we wouldn't be having this conversation because we'd be dead or living as hunter-gathers. |
|
|
|
Well, that's clearly a well-though out and thorough response. I don't feel particularly obligated to give a reply that is more thought out and thorough than the message that proceeded it. I have a pile of transactions with fees. The bottom 50% don't get relayed. Everyone bumps up their fees slightly to ensure transmission. The bottom 50% don't get relayed. They try again with slightly higher fees. The bottom 50% don't get relayed. They bump their fees up again.
Lather, rinse, repeat.
Spenders get more than one attempt per transaction. If we assume they aren't going to behave moronically, they'll move their bid in both directions, up and down, in order to hit their desired price/speed point. |
|
|
|
Any system that implements a reward as you suggest will create a positive feedback loop with transaction fees racing to be as high as possible without any upper limit.
No, it won't. |
|
|
|
|
Any service which could potentially keep logs which deanonymize customers must be assumed to be doing so.
|
|
|
|
|
Thou Shalt Not Tamper With The Reward Formula.
|
|
|
|
|
Actually full node operators will probably care about this before miners will. What if the relay rules were like this?
For paying transactions: Track fee/KB statistics over the last 24 hours and calculate what percentile new transactions fall into based on that data set. Refuse to relay the lowest 5% (configurable in bitcoin.conf).
For free transactions: Track bitcoin-days statistics over the last 24 hours and calculate what percentile new transactions fall into based on that data set. Refuse to relay the lowest 50% (configurable in bitcoin.conf)
|
|
|
|
Transactions should be simply sorted by fee/KB and stuffed into the blocks until they fit.
This isn't going to happen until the transaction volume gets much, much larger than it currently is. Right now miners don't care about transaction fees because the block subsidy distorts their incentives. |
|
|
|
|
Show Posts
