Microsoft planning blockchain-as-a-service for Azure apps Microsoft might not be keen on Bitcoin, but it's cock-a-hoop about the backend blockchain the currency uses and has given the first details of Project Bletchley, a plan to add the tech into Azure services via some new middleware. "Project Bletchley is a vision for Microsoft to deliver Blockchain-as-a-Service (BaaS) that is …
re falsification....
To falsify a single record you'd have to regenerate every record before the one you were trying to change, then convince every node that your version of the chain is the valid one. ie you're talking vast computing power, as well as controlling >51% of the network hashrate.
http://bitcoin.stackexchange.com/questions/18841/is-there-a-real-threat-of-so-called-50-attack is worth a look.
The falsification conditions come up as a result of the way that blockchain works. Basically, as the name suggests, this is a public ledger with the use of mutual digital signatures to agree transactions. The problem comes in the way that the blocks themselves are managed. I am going to simplify, largely because although I read through it in detail, that was a while ago and I am not confident of my ability to relate the key points accurately.
When you have large numbers of disparate parties all attempting to append a transaction to the same block in a chain, you are going to get scenarios where there are atomic failures at the transaction level. For example, suppose there is one free slot in a block and two or more parties try and use it. Only one will succeed and the others will fail. The entire blockchain is designed to handle this using a mechanism analogous to the 2-stage commit of XA-comliant systems... However, it does this, at least in part, by allowing splitting of blockchains and downstream conflict resolution of scenarios such as the one I described above.
But what happens if you and I have a transaction thrown out and then, we it's time to re-submit, I decline? This is [as I understood it from the read-through] an extremely narrow scenario that is virtually impossible to predict in advance. When all the potential conflicts and block splits are resolved and confirmed into the chain, then a transaction is deemed "guaranteed". However, there exists a narrow window of time between when the transaction is written to the block and when it is fully committed, in which another user/transaction source could challenge/trump that commit and force a do-over.
I think that's the "almost impervious to falsification" bit, if I understand it correctly...
For what it's worth, people are predicting that we need to change the underlying architecture of Bitcoin because the collision scenario I describe will only get more prevalent as more people use it. There appears to be something of a tussle underway in the BC community on this very point...
It's not true block chain ... The key word being "distributed"...
The word "distributed" may be key, but it's no part of the word "blockchain".
The point about blockchains being "distributed" is that the people who invented Bitcoin specifically wanted it to be anarchic in nature, and not to require -- or be subject to -- regulatory oversight by any body such as a bank or government. Blockchain is the solution that they came up with to make Bitcoin transactions verifiable without putting anyone "in charge".
Now Microsoft apparently want to offer a blockchain-like "service" ... but if that's the case they're missing the point ... once Microsoft is in charge you don't need need blockchain because you have Microsoft in a position to provide regulation. Rather than basing transactions on a blockchain hash you can base them on the hash of a Microsoft Magic Cookie. Blockchain becomes irrelevant.
Unless, of course, you don't trust Microsoft ... but if you don't trust Microsoft why would you trust them to be the custodians of your blockchain?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
