4 ms·
The Bitcoin blockchain, as implemented today: - Takes over 10 minutes to come to consensus - Cannot handle the transaction volume of a reasonably large retail
by bascule 11y ago
The Bitcoin blockchain, as implemented today:
- Takes over 10 minutes to come to consensus
- Cannot handle the transaction volume of a reasonably large retail company
- Loses accepted transactions!!! (blockchain forks, orphan blocks, etc) From a distributed database perspective the Bitcoin blockchain is broken and loses data: like a decentralized MongoDB, but slower by several orders of magnitude.
Articles like this are largely uninformed non-technical people responding to hype. They don't know what a replicated log is, let alone a Merkle tree.
There are many interesting distributed ledger technologies, like Stellar SCP, Hyperledger, and Tendermint.
The Bitcoin blockchain is ill-suited for this purpose.
- maaku 11y agoThese banks aren't talking about _Bitcoin_ block chain.
- bascule 11y agoPerhaps you'd like to define what a blockchain means outside the context of Bitcoin? Is SCP a Blockchain? Is Hyperledger? Is Tendermint? Is every database that uses a replicated log a blockchain? Are Certificate Transparency logs blockchains? Do Merkle trees count as blockchains? It's a meaningless term that was never used or defined in the Bitcoin paper.
- lsseckman 11y agoWhat about, and this is an attempt: "A Merkle tree of transactions signed using an elliptic curve digital signature and validated using a consensus algorithm"
- brighton36 11y agoYou need truth to be objective in order to be a blockchain. There's no mention of pow in that definition. If every single node in the Bitcoin network went down but one, and 99% of the network were "lying" then we'd still know the "truth". That is what a blockchain does. These voting databases are silly decades old technology
- nickpsecurity 11y agoDistributed, log-based systems... old tech... can do that on fault-tolerant hardware in near real-time with no waste from mining. Necessary crypto accelerators already exist for those, too. Some systems in banking on mainframes or NonStop have been doing transaction processing with decades of uptime despite HW faults and hacker threats. Compared to blockchains, variations on old approach seem better from the tech efficiency to field results.
- pilgrim689 11y ago> - Loses accepted transactions!!! (blockchain forks, orphan blocks, etc) From a distributed database perspective the Bitcoin blockchain is broken and loses data: like a decentralized MongoDB, but slower by several orders of magnitude. When a block is orphaned or when there is a fork, transactions are not lost, they'll always be present in the main chain. Or said another way, all miners are trying to mine the unconfirmed transactions in their mempool. If one miner ends up finding the winning block, transactions they didn't include that were included in an orphaned block are going to be mined in the next block. What you may be referencing, though, is not "lost transactions", but rather double spends? What I said above holds true assuming no one else is trying to spend the same outputs. However, if you wait 6 confirmations (the recommended amount before you should consider a transaction "accepted"), you won't see double spends, either.
- tveita 11y agoThe memory pool is not consistent among nodes, and nodes are free to drop or ignore transactions as they see fit. As you say, nodes may have conflicting transactions, a.k.a. double spends. Transactions are not durable in a meaningful way until they have been included in a block. Waiting for six confirmations is probably enough to prevent accidental reversions, but takes on average an hour, with a fair amount of variance.
- pilgrim689 11y agoWaiting for six confirmations is enough, as it's been shown both in theory and in practice. I was correcting the parent as saying Bitcoin loses transactions is false. The network never loses a valid unconfirmed transaction.