SoylentNews is people
SoylentNews
The financial sector's enthusiasm for blockchain technology might be misplaced, according to a pair of Australian distributed computing experts.
The problem: if everyone in a consortium trusts each other, they don't need blockchains to protect themselves; if they don't, current blockchain protocols have a flaw that allows a bad actor to game the system.
The warning comes from CSIRO/Data61 researcher Vincent Gramoli, lead author of an arXiv paper describing what he and colleague Christopher Natoli call "The Balance Attack" (the name comes from one aspect of their attack, that it's deployed against subgroups of nodes with balanced mining power).
In the finance/banking context, Gramoli says the problem is that blockchains are probabilistic, but for something like an inter-bank transfer, you need determinism. If the system enters a state in which it can't guarantee all transactions, downtime is the best solution.
Gramoli told The Reg "if the assumptions are not met, users should get a message that 'the system is not available, please try again later'".
Source: The Register
(Score: 2) by JNCF on Tuesday January 17 2017, @08:10PM
I'm not claiming expertise. I have played around with programmatically rolling my own bitcoin transactions, and suspect that I blackbox what's going on better than most people -- that's just a really low bar. I'm going to try to answer your questions to the best of my ability.
Can it always be perfectly be predicted whether a transaction will be performed in a "safe" (transaction guaranteed) vs. "exploitable" (not guaranteed) state?
Blocks are sequential, and each block can have many transactions. The number of blocks mined since a given transaction is one of the factors generally used in estimating how probabilistically safe that transaction is (this is called "depth", and since it's 1-indexed it is technically the number of blocks mined since the block before the given transaction). The other factor is attack power. If an attacker has more than 50% of mining power, they will almost certainly eventually be able to outrace all other miners by creating a longer chain of blocks than the one that currently exists. In reality the percentage required is lower than 50% that because the rest of the miners aren't in perfect cooperation, but even if they were an attacker with 51% of mining power would beat them all. If a hypothetical attacker only had 20% of processing power, waiting for a transaction to reach a depth of 10 should give them a < 0.01% of successfully double-spending. If you only waited for a depth of 2, that same attacker would have a > 0.1% chance of success. Don't take my word for it; there's a fancy graph on page 8 of this PDF, [bitcoil.co.il] and a relevant equation on the page before it. That specific paper is actually referenced in the first section of the arXiv paper linked in TFS. Takeaway: no transaction can be 100% guaranteed. Even only caring about attackers with less than 10% of power, the depth of a transaction only makes safety increase probabilistically. A weak attacker could still pull off a double-spend after a transaction reached a depth of 100 just by being astronomically lucky. You could also theoretically make money by just trying random private keys and seeing if anybody has bitcoins attached to them, but it's ridiculously unlikely. This talk about probabilistic systems not being suitable for finance seems to miss the fact everything is probabilistic. The banks could go bankrupt at any moment, through a bland depression or a fantastic display of quantum happenstance. The fermions dance how the fermions dance, man. So, yes, we can make a perfect prediction. Here's our perfect prediction: the transaction isn't safe. Amazingly this prediction applies equally well to dollars, yen, bullion, and bitcoin!
If so, can the transaction be queued by client software until the prediction is a "safe" guaranteed transfer?
If my above rambly paragraph was half a clear as I hoped this shouldn't be necessary, but to answer directly: "safety" increases with the number of blocks hashed since a transaction, so you really want to make a transaction as soon as possible and then wait for it to become more "safe" rather than waiting for some future time to make a transaction. If the block you made a transaction on gets removed because an attacker made a longer chain of blocks that started before it, you can just propagate that same transaction again as long as the previous transaction outputs it relies on haven't been used in another transaction in the meantime or retroactively removed from the system entirely by the prior chain fork.
If not, what good would be a "Thanks for playing; try again later" user failure message if the system can't predict perfectly at least "safe" (false positives on "exploitable/not guaranteed" would be okay, but a false positive "safe/guaranteed" might cost a few [hundred|thousand|million|billion|Bazillion] units of currency)?
I think a better approach might be showing the user some "safety" score of a given transaction derived from its depth (and recent communication delay, etc.). Just made a transaction? It's red. As it approaches a depth of 10 and other factors are still fine, we slowly fade to green. If this doesn't sound like it will work well for large, quick, low-trust transactions, I agree completely. Large transactions should only be trusted after a reasonable wait. I've never waited for a depth less than 9, but I've never spent bitcoins in a hurry. I could easily see being less paranoid for small transactions if I had any need to be. I don't think this kills all of Bitcoin's applications, but I don't think Bitcoin is a be-all-end-all killer currency that everybody will interface with directly. I'd also love to be wrong, and see a future where people pay for candy bars probabilistically. I think it's more likely that third-party corporations will provide people with accounts that have funds backed by bitcoins and trust, and these third-parties will accept a certain amount of risk in exchange for fees and/or the ability to lend out dormant funds (people like to be coddled). Regardless, just not allowing interaction due to latency issues seems like poor UI. Let the user keep clicking buttons, but visually indicate that some application state is less likely to be permanent -- this is what we do in modern web apps and multiplayer games. This is the only disagreement I had with the paper authors, but I did skim sections. As far as I've seen they don't make that point in the paper itself, just in the El Reg interview. We've all said stupid things to journalists on the spot.
I feel like I read people discussing the potential for delay-based double-spend attacks on a Bitcoin forum years ago, but I forget the details and my water-memory could be making it up. It's certainly not surprising. El Reg's presentation seems a bit hyped.
(Score: 2) by JNCF on Tuesday January 17 2017, @08:17PM
s/spent/received
(The statement would be true either way, but only relevant this way.)
(Score: 2) by arslan on Tuesday January 17 2017, @11:41PM
Thanks nice explanation even though I don't get some of the details yet. However your point about conditioning the user with eventual consistency is a key one, even outside the context of blockchains. The finance sector, and likely a lot of others, have been brainwashed with the absolute need for atomic consistency for way too long.
In my 20 years, I've never really seen any application that truly can't live without atomic consistency if designed properly.
(Score: 2) by JNCF on Wednesday January 18 2017, @05:05AM
If you're interested in blockchains and you haven't read the Bitcoin Whitepaper (PDF link [bitcoin.org]) it's highly recommended and pretty short. It gives you a brief overview of what's going on without assuming that you already know any Bitcoin-specific terminology.