[HN Gopher] An analysis of Bitcoin's throughput bottlenecks
___________________________________________________________________
An analysis of Bitcoin's throughput bottlenecks
Author : billytetrud
Score : 56 points
Date : 2021-05-12 07:21 UTC (15 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| itsdsmurrell wrote:
| Try Bitcoin Cash. The devs have full control over the BTC
| protocol.
| ilaksh wrote:
| Bitcoin is the cryptocurrency you pick when you don't want to
| improve or change anything about cryptocurrency. It's the digital
| gold cryptocurrency.
|
| Many people have tried over the years to improve it such as
| reducing bottlenecks etc. At this point, I think they have proven
| that they are not going to make structural changes. And so I
| think the rational response is just to appreciate and use Bitcoin
| for what the devs or evil conspirators or whatever have decided
| that Bitcoin is going to be.
|
| Thankfully we have other cryptocurrencies.
| Havoc wrote:
| I'm still not quite following why people are looking at bitcoin
| for this. Surely one of the newer generation like eth is better
| suited? Or better yet a layer 2 on eth
| gruez wrote:
| >Surely one of the newer generation like eth is better suited?
|
| What scaling technologies do they have? The ones I'm aware of
| are: "commit the global state every n blocks and trust that",
| and "have n parallel blockchains so it's not one big chain"
|
| >Or better yet a layer 2 on eth
|
| or layer 2 on BTC, aka lightning network?
| CyberDildonics wrote:
| Why? It has been in development for 7 years.
|
| Why use this complicated hack solution when anyone can just
| use a different cryptocurrency and not have these problems in
| the first place?
| wyager wrote:
| > It has been in development for 7 years.
|
| Good. They need to get it right.
|
| > Why use this complicated hack solution
|
| It's complicated but not a hack at all. It makes perfect
| sense.
|
| > when anyone can just use a different cryptocurrency and
| not have these problems in the first place?
|
| There are 0 (zero) cryptocurrencies that scale better than
| Bitcoin that don't also compromise on security or
| decentralization. Lightning is the best known option which
| keeps these properties which make Bitcoin desirable in the
| first place.
| DennisP wrote:
| Ethereum shards share security, so you can't just do a 51%
| attack on one shard.
|
| Zkrollups on Ethereum have the same security properties as
| on-chain transactions, with no need for monitoring and no
| withdrawal delays. That can't be said for the LN.
| wyager wrote:
| You would think so, but there have not actually been any
| meaningful scaling improvements that don't boil down to "trust
| a centralized authority". Lightning is currently the best known
| option.
| dylkil wrote:
| its a pity bitcoin devs are so opposed to changing the protocol.
| So much research has been done showing the feasibility of
| increasing bitcoins throughput. Xthinner for instance is capable
| of compressing bitcoin blocks by up to 99% using bloom filters
| [1]. Much of this research was conducted on the bitcoin fork,
| bitcoin cash, by people ostracized from the bitcoin community for
| wanting to explore these ideas.
|
| [1]https://reddit.com/r/btc/comments/bas60b/by_the_power_of_cto..
| .
| itsdsmurrell wrote:
| For anyone who joined late:
| https://www.reddit.com/r/btc/comments/61mxuj/block_size_limi...
| scotty79 wrote:
| The lower transaction throuput,the higher the fees, the higher
| the incentive for the miners to process transactions.
|
| They probably don't want to mess with that dynamic too harshly.
| dylkil wrote:
| this was the debate circa 2014/2015. Should the bitcoin
| network consist of many low fee transactions or few high fee
| transactions. Right now the incentive for miners to secure
| the network is produced with the block reward, but when the
| block reward runs out this incentive will be from fees alone.
| In order to provide miners with the same revenue as today
| when the block reward runs out, the average fee per tx will
| need to be close to $200. If you increase the block size to
| 100mb and use block compression tech like xthinner to make
| blocks essentially 1mb (like today), then the average fee
| needed is only $2.
| scotty79 wrote:
| Why many low fee transactions were not chosen?
| dylkil wrote:
| You'll get many different responses to this question
| depending on who you ask. If you want to read into
| further i recommend you read the great scaling debate[1].
| Its pretty long but does a fantastic job of summarizing
| the history.
|
| In short the most popular reason for not having a block
| size increase (to allow many low fee transactions) was
| that it would increase the cost of running a full node,
| in turn centralising the network. More transactions would
| mean nodes would need a bigger hard drive and a better
| cpu to process the transactions. The small block camp
| wanted people to be able to run nodes on a raspberry pi.
| This theory is misguided in my opinion though, they chose
| to sacrifice cheap transactions to keep node running
| costs cheap.
|
| [1]https://medium.com/hackernoon/the-great-bitcoin-
| scaling-deba...
| itsdsmurrell wrote:
| They (the devs that control the repo that almost all
| miners run code from) chose to stifle the base layer to
| profit from higher layers using 'goat herders should be
| able to run a full node' as the excuse.
| gruez wrote:
| >to profit from higher layers
|
| How are they profiting?
| gruez wrote:
| >use block compression tech like xthinner to make blocks
| essentially 1mb (like today), then the average fee needed
| is only $2.
|
| Claiming that xthinner can reduce 100mb blocks down to 1mb
| is dishonest. It might reduce the network transfer down to
| 1mb (assuming you already the txes), but on-disk storage
| would stay the same.
|
| https://news.ycombinator.com/item?id=25688004
| rawtxapp wrote:
| There are some very important changes happening in bitcoin
| (taproot, eltoo, lightning). Devs aren't opposed to protocol
| changes, they are opposed to ill-thought changes that make it
| less decentralized and weaker.
| itsdsmurrell wrote:
| Wrong, they are opposed to changes that will stop them from
| profiteering off higher layer solutions they provide.
| rawtxapp wrote:
| Devs are _not_ profiting from 2nd layers, people who commit
| capital to these payment channels do! And even then it 's
| tiny amounts.
| oogabooga123 wrote:
| Bitcoin could handle 100k+ tps with some more serious
| optimizations (but keeping the same protocol / data structures)
| it's simply tragic what small blockers have done with Bitcoin
| instead. UTXO is massively parallel! The double spend critical
| path could do millions of double spend checks per second.
| TheDong wrote:
| > UTXO is massively parallel
|
| I don't quite understand what you mean by UTXO being parallel.
| Can you explain more?
|
| My naive understanding is that the amount of unspent bitcoin
| you have at an address (UTXO) has to be accurate for the
| critical path of verifying a double spend doesn't happen, and
| updating multiple UTXOs in parallel seems like it would allow
| violating that.
| [deleted]
| nivexous wrote:
| The reason UTXOs parallelize better is because when you look
| at a transaction on a UTXO-based blockchain like Bitcoin, you
| can deterministically and often immediately know from it
| exactly how the state of the system will change, and which
| states will change. A Bitcoin transaction for example
| completely describes which outputs will be spent, which new
| outputs will be created, and the new amounts in those
| outputs. This is a really nice property. It makes validating
| and analyzing transactions parallelizable _by design_. The
| system still has to protect against double-spends globally,
| but this part is light in comparison and can be very fast.
|
| In contrast to Bitcoin, basically every other smart contract
| blockchain is account-based, not UTXO-based, and has shared
| global state. This does not parallelize naturally at all. I
| like to think its similar to using cash vs transferring money
| using Venmo. Giving someone cash parallelize naturally, like
| UTXOs, whereas Venmo requires a database lock.
|
| In account-based systems, it's impossible to tell how a
| transaction will change the system's state without executing
| it. The order that transactions are executed is crucial too,
| which is why people say Ethereum is single-threaded. Attempts
| to parallelize account-based systems fall into different
| categories. Ethereum 2.0's plan is to basically create
| separate VMs with separate state, called shards or rollups.
| This can work sometimes, but it makes interactivity between
| shards (think applications) much more difficult, and
| interactivity to me is a major reason for using blockchain.
| Another approach is to embed information into transactions to
| make them parallelize more like UTXO-based transactions,
| which is what Solana does. But they parallelize only at the
| smart contract level, not at the asset level as UTXOs can.
|
| Whereas UTXO-based designs get parallelizability by design,
| creating a programming model for smart contracts and tokens
| has to-date been harder on these systems, and frankly there
| aren't even that many people trying. I've been working on
| this problem for a while and believe I've found a
| breakthrough. Check out https://run.network if it interests
| you.
| Taek wrote:
| A design technique called utreexo allows you to validate
| essentially every single transaction in the entire history in
| full parallelism. With an infinite number of cores, you could
| in theory validate the entire bitcoin blockchain in under a
| second.
|
| That said, you need to do billions of cryptographic
| operations still, and you need to actually posses the full
| blockchain. 100k tps+ is not really reasonable on modern
| consumer hardware, and even getting to 100 requires a lot
| more engineering than has currently been completed.
| chromaton wrote:
| Here is the real world, Bitcoin is currently running a blazing
| 3.3 transactions per second.
|
| Etherium dwarfs that at a mighty 14 transactions per second.
|
| Meanwhile, PayPal crawls along with a pathetic 488 tps.
|
| https://www.statista.com/statistics/730838/number-of-daily-c...
|
| https://www.businessofapps.com/data/paypal-statistics/
| pa7x1 wrote:
| Ethereum layer 1 is processing closer to 20 per second. In
| particular, it did 1716000 in the last 24 h.
|
| Ethereum's layer 2 can handle tens of thousands transactions
| per second. These are then settled on chain as a single
| transaction. There are multiple layer 2 solutions already
| working and more are coming. It's not a pipedream anymore they
| are live.
| chromaton wrote:
| How many transactions per day are currently being run on
| Ethereum layer 2? I can't find this info.
| meowkit wrote:
| Because layer 2 is nebulous.
|
| You'll have to look up the transactions for each ERC20
| token with volume. Volume is much higher than the base
| chain, but we are still waiting on rollups and sharding to
| supercharge TPS.
| dboreham wrote:
| "already working" hmm.
| DennisP wrote:
| Yes, they're called rollups and several are already in
| production on the public chain.
| scotty79 wrote:
| Seriously? Bitcoin that has intentionally low transaction
| throuput is only two orders of magnitude slower than largest
| online payment processor that was designed with highest
| possible throuput in mind?
| Qworg wrote:
| VisaNet will do 76,000 tps - 4 orders of magnitude.
| ChainOfFools wrote:
| has anyone ever done the modeling on the dynamic limits of
| decentralized network consensus? my intuition has always been
| that getting, say, 100,000 globally distributed voting nodes to
| agree on even a simple truth value will quickly run into
| exponential (or worse) latency bottlenecks by way of metcalfe's
| law. the speed of light, as a hard limit,
| starts to become insurmountable when your consensus pathway has
| to be traversed the equivalent of tens of millions of km of
| signal path in order for every node to have an equal influence
| on the validity of every other node's vote.
|
| these high tps coins all seem to get around this by weakening
| decentralization, whether by shortening this path, either
| because they have far fewer nodes, or are deciding to sum over
| some approximation of node consensus by sampling or creating
| privileged paths, or because geography already creates
| privileged paths (all the nodes are in the same general area,
| or even in the same datacenter).
|
| I suspect the reason TX speed tends to stay mired in the tens
| per second region is that no amount of consensus accounting
| gimmickry will overcome the underlying physical limitations of
| true global scale decentralization of consensus.
| Taek wrote:
| Bitcoin's Proof of Work algorithm has linear scaling.
| Basically 100,000 nodes all trying to build consensus using
| Nakamoto PoW can do it in O(100,000) messages. The scaling
| factor on the number of miners is not what is a bottleneck
| here.
|
| The main bottleneck for cryptocurrencies is that every single
| node has to validate every single transaction. So your global
| throughput is effectively limited to what a single node can
| process.
|
| Technologies like STARKs can improve these bottlenecks
| without introducing new trust layers or trust assumptions but
| still carry data availability requirements which once again
| require every node to have all the data, even if they don't
| have to actually process all the data.
|
| There are additional techniques you can use to minimize the
| data availability impact but then you start introducing trust
| assumptions again.
|
| It's a tricky problem and there's a good reason none of the
| major chains have adopted a solution, but it's not as dire as
| your post suggests, nor does your post highlight any of the
| fundamental issues at play.
| ChainOfFools wrote:
| > The main bottleneck for cryptocurrencies is that every
| single node has to validate every single transaction. So
| your global throughput is effectively limited to what a
| single node can process
|
| literally what I said in my post. the mining aspect was
| your addition, not mine. I am describing an idealized model
| which doesn't even consider the added complication of
| mining to incentivise playing by the rules(let's assume
| coins are issued based on signs from, say, zeus). just
| simple consensus on a single 0/1 truth value.
|
| this is the hard scalability problem, and people claiming
| to fix it are ultimately bound to create hierarchies of
| truth authority, undermining decentralization and
| recreating the existing concentric power structure (with
| themselves in the center) they claim to obsolete.
| buckie wrote:
| There is an example of directly scaling PoW that's been in
| prod for 1.5 years now:
| https://explorer.chainweb.com/mainnet
|
| Instead of having X PH of PoW difficulty for a single
| blockchain, you have N parallel blockchains with ~X/N PH
| difficulty. Same energy needs, N*single chain performance.
| The coolest bit being that N can increase in an upgrade w/o
| needing to increase energy consumption, should the network
| gain traction and need more throughput. It upgraded from 10
| to 20 chains last summer.
|
| Other cool bit is that each chain runs a formally
| verifiable LISP (Pact)... I jokingly refer to Kadena as "a
| multithreaded LISP machine in the sky".
|
| Disclaimer: I designed the Chainweb consensus algorithm
| aeternum wrote:
| Those are on-chain transactions. Coinbase and many other
| wallets now support offline, or 'Instant Sends' which is more
| akin to the simple database update that PayPal/Visa performs.
|
| Sure those aren't purely decentralized but a decentralized
| settlement layer is probably where most of the value is anyway.
| chromaton wrote:
| >a decentralized settlement layer is probably where most of
| the value is anyway.
|
| Why?
| aeternum wrote:
| Graph theory. A purely centralized topology has significant
| problems with fault tolerance, trust, and control. However
| you do not need a hyperconnected graph to achieve strong
| fault tolerance and protect against a single node with full
| control.
|
| The internet itself is a good example. It strikes a balance
| between decentralization and efficiency through the use of
| ISPs as supernodes.
| bourgwaletariat wrote:
| How many transactions happen in the world?
| PeterisP wrote:
| Looking solely at electronic direct payments, it would be
| more than a billion transactions per day, there are multiple
| major schemes that work on the 100m/day scale each (Visa,
| Mastercard, US ACH, EU SEPA, China Unionpay, etc) and a lot
| of smaller ones that add up. So that's in the ballpark of 10k
| _sustained average_ txn /sec, more in peaks.
|
| On the other hand, there's room for a lot of growth, it's not
| even a single transaction per day for the almost 8 billion
| people that we have.
| ketzo wrote:
| Visa says they do 150 million transactions in a day, for an
| average of 1,700tps -- and I'd have to imagine their spikes
| are _much_ higher.
| answertojob wrote:
| check IOTA if you want to learn (if you have not) about DAG
| structure that potentially solves decentralized scalability.
| GOSSIP protocol
| chromaton wrote:
| I looked into this and IOTA requires special blessed
| "Coordinator" nodes, so it's not really decentralized.
| ulzeraj wrote:
| How many settlement layers exist between a PayPal transaction
| and the underlying money transfer protocol (SEPA, SWIFT etc)?
| homakov wrote:
| Bitcoin dominance is fading this year only because it has bet on
| LN with fundamental inbound capacity problem. LN rejected my
| proposal to solve it and extend channels with credit lines: XLN
| https://medium.com/fairlayer/xln-extended-lightning-network-...
| rawtxapp wrote:
| Bitcoin dominance always goes down in altcoin season and then
| comes right back up.
| brighton36 wrote:
| Meanwhile, crypto indexers beat Bitcoin maximalists. But, the
| evidence for indexing performance will never see the light of
| day . :)
| gruez wrote:
| >But, the evidence for indexing performance will never see
| the light of day . :)
|
| Why not? If such evidence exists why aren't you presenting
| it?
| brighton36 wrote:
| You'll note that my comment was downvoted. This evidence
| is immoral. Thus, it won't be aired.
|
| You can go to pandaanalytics.com if you'd like, and play
| with their index options. See what strategies have worked
| well. (I weight by market cap, top-10, no stablecoins)
| rawtxapp wrote:
| Not sure what you mean by crypto indexer, you mean people
| who buy a basket of crypto? Sure, in the short term, they
| might outperform BTC, over long term 70% will die, 90+%
| won't recover to their ATHs. If you indexed back in 2017
| into top 10 coins, only like 3 of them crossed their old
| prices from 2017, rest are as good as dead.
| wmf wrote:
| Usually you'd rebalance periodically.
| thegreatpeter wrote:
| Seems like stuff folks say in a bubble. 90% of it will
| disappear once ethereum fixes this/that.
| brighton36 wrote:
| Where did you get these numbers? I assume this is a post-
| hoc rationalization?
| crazypython wrote:
| Interesting.
|
| > Also, uninsured balances are enforceable onchain, which is
| very different from a trusted balance.
|
| Does this mean XLN is implemented with a smart contract that
| withdraws the money from an address if you fail to pay? Or
| automatically cancels the channel if you withdraw more than
| what you have in the channel?
| londons_explore wrote:
| It looks like you are explaining some good stuff in that blog
| post, but the overall arrangement and writing style of the post
| reduces it's impact.
|
| Your post could be more influential if you refined it through a
| technical writing type process - perfecting the ordering of
| presenting information for the audience you hope to persuade.
| Qworg wrote:
| Payment channels ARE credit, generally - I'm sorry this
| proposal was rejected. Was there a reason for the rejection?
| RcouF1uZ4gsC wrote:
| > I will also show that while Bitcoin currently may not be in a
| safe state, future software optimizations could allow Bitcoin
| safely process likely more than 100 transactions/second on
| today's hardware.
|
| 100 transactions/second still doesn't sound like a lot,
| especially if you want Bitcoin to be an actual currency used for
| exchange of goods.
| MereInterest wrote:
| If Bitcoin were used by everybody on the planet, the current
| max of 10 transactions/second means that each person could be
| part of a transaction once every 13 years (4 billion pairs of
| people / 10 Hz). Boosting the rate up to 100 transactions per
| second reduces that down to 15 months. Just think, receive you
| paycheck this week, and over a year later you can use it to buy
| groceries.
|
| Bitcoin's throughout is absolutely pathetic, by several orders
| of magnitude. I think the only reason that aspect hasn't gotten
| more attention is because the energy efficiency is even worse.
| wskinner wrote:
| This is not really true, for several reasons. One simple
| reason is that a bitcoin transaction can have multiple
| outputs, while your analysis assumes each transaction is
| between two people.
| ezekg wrote:
| Are there any cryptocurrencies that are attempting to solve
| this issue?
| amackera wrote:
| Algorand looks like a promising proof of stake altcoin in
| my opinion.
|
| https://www.algorand.com/
| CyberDildonics wrote:
| It is only an issue in the first place because of bitcoin's
| purposely meniscule throughput. Monero's throughput adapts
| while bitcoin cash has 32x the max blocksize.
| sambroner wrote:
| Basically all (hardly even an exaggeration!) other
| cryptocurrencies are attempting to improve upon the
| throughput issue. Solana is a particularly prominent one
| with 50k/s
|
| https://solana.com/
| uncoder0 wrote:
| I'm interested in how all these other chains deal with
| people writing tons of junk transactions per second to
| bloat up the chain.
| cgb223 wrote:
| Having a transaction fee de-incentivizes most people who
| want to do this
|
| Every junk transaction costs them money
| WanderPanda wrote:
| From what I've seen they don't
| ezekg wrote:
| NANO actually just went through a pretty big spam attack
| and it crippled the network for awhile, but they
| supposedly came up with a pretty novel solution in the
| latest version. I haven't dug into it yet though. But
| NANO is fee-less, so it is (was?) more prone to these
| types of attacks. Having a fee increases the cost of a
| spam attack.
| chromaton wrote:
| I looked into it and Solana requires "Validator" nodes to
| be specially blessed by them to get rewards for running
| their software, so this isn't particularly de-
| centralized.
| [deleted]
| djanogo wrote:
| I don't know how Bitcoin transactions work, but can a company
| (like Paypal) buy bunch of bitcoins (10000), and then proceed
| to do all transaction internally with their own ledger
| mechanism without depending on other networks?, wouldn't this
| allow anybody within paypal network to send/receive super
| fast?
| quadcore wrote:
| This is basically the principle behind a tech on top of
| bitcoin called lighning network: https://lightning.network
| hgfxgkgc wrote:
| Paypal already does this with bitcoin.
| CrLf wrote:
| That's how traditional financial systems work.
| MereInterest wrote:
| Correct. This adds a point of centralization, which defeats
| the entire purpose of cryptocurrency. As far as I can tell,
| cryptocurrency is based on wanting (1) a shared database
| that (2) can be updated by anyone within specific rules and
| (3) doesn't require anybody to trust anybody else. In the
| same way that low-trust societies have a much bigger
| overhead as a result of the lack of trust, I do not think
| cryptocurrencies are feasible while holding to (3) without
| massive, massive expenditure as a result.
| CSSer wrote:
| > without massive, massive expenditure as a result.
|
| Could you elaborate on this?
|
| The problem I foresee is that having someone you have to
| trust is not a bad thing because at least you're able to
| identify that entity's traits and act accordingly. If
| that entity is, for example, the world's largest military
| power, I might feel like I have a lot less to worry about
| than if they're, as another example, a publicly traded
| company about half the size of the average major U.S.
| bank.
|
| Is this what you're alluding to?
| lottin wrote:
| The whole selling point of bitcoin is that it's a
| decentralised ledger that isn't owned by anybody. If the
| transactions are managed by a central entity, then that's
| no longer true. For example, what's to stop such an entity
| from creating bitcoins out of nothing and thus debasing the
| bitcoin currency?
| unwoundmouse wrote:
| Yeah that's how all centralized crypto exchanges do it
| CSSer wrote:
| What if there's a run on the exchange?
| beiller wrote:
| I don't think there can theoretically be a run on the
| exchange because in theory all the deposits are there, in
| the exchange, in theory, unlike a bank which only had a
| fraction of the deposited money in reserve. A run on a
| crypto exchange would be great for them considering they
| usually charge a withdrawal fee.
| CyberDildonics wrote:
| Those aren't withdrawal fees, those are transaction fees
| for the network. Most cryptocurrencies cost next to
| nothing for each transaction, while bitcoin and ethereum
| cost from $20 - $60 USD for the average transaction.
| wmf wrote:
| If the blockchain gets backed up it would take a few days
| to get money in/out of exchanges.
| ChainOfFools wrote:
| they suddenly have a 'technical issue' and suspend
| trading until it is 'fixed.' sometimes its never fixed
| and the exchange founder mysteriously disappears to
| Thailand or dies, or claims to start an orphanage in
| india. sometimes all three.
| Taek wrote:
| In some senses it's not a lot, in other senses it is a lot.
| Large systems (like the US banking system) only do a few intra-
| bank settlements per day, 100 tps is well beyond what you need
| for nation states to do business with eachother.
|
| And then down at the consumer level it's nothing at all. During
| peak hours of the peak season (Christmas), Visa does something
| like 50,000 tps.
|
| What makes Bitcoin interesting is the trustlessness of the
| transfers, and that tends to be more interesting higher up the
| stack (at the inter-bank and inter-national levels) than at the
| consumer level. But you can also combine this with layer two
| technologies like payment channels, ILP (interledger protocol),
| and the lightning network to get rapid transfers where most of
| the transactions never hit the chain.
|
| The Sia network for example does something like 30 million
| transactions per day (that's about 300 tps), but only about 500
| of those are actually on-chain at the settlement layer. The
| rest are ultra efficient off-chain payments that only require a
| packet or two to be sent between two machines (as opposed to
| broadcast).
|
| ---------
|
| From the perspective of "everyone can own and use bitcoin", 100
| tps is not quite enough. To support 1 billion people on Bitcoin
| even with the best layer 2 systems we have in theory, you need
| about 400 tps. So 7 billion would need like 3,000 tps.
| mullingitover wrote:
| > What makes Bitcoin interesting is the trustlessness of the
| transfers, and that tends to be more interesting higher up
| the stack (at the inter-bank and inter-national levels) than
| at the consumer level
|
| What's interesting about that? Higher up the stack,
| trustlessness is not compelling at all - if I'm transacting
| with you on the scale of six-plus figures, I absolutely won't
| transact with someone I don't trust, and anonymity is a
| defect - I want to know who you are _so I can sue you_ if our
| deal goes sideways.
| Taek wrote:
| The whole point of a trustless transaction is that you
| don't need to worry about who the counterparty is. You
| don't need the leverage to sue somebody because fraud is
| not possible. For digital transactions, the lack of trust
| can be two-way - two mutually distrusting people can
| confidently exchange Bitcoin for Ethereum in a transaction,
| because the software and math behind the blockchain
| prevents fraud from happening at all.
|
| For meatspace the best you can do is one-way. If I'm buying
| a car with Bitcoin, I still need to trust the car
| manufacturer to deliver, but the car manufacturer does not
| need to trust me. They don't need to know who I am or how
| deep my credit line is, as soon as the bitcoin hits their
| wallets they have extreme confidence that the transaction
| won't be reverted. No bounced checks, no chargebacks, etc.
| It's a zero fraud system, and there's also no intermediate
| party (like PayPal or a bank) that can decide the
| transaction shouldn't happen. Whether or not the payment is
| accepted is at the sole discretion of the recipient.
| jsf01 wrote:
| This is a great way to put it. If you look at settlement
| times 3tps is great. If you're actively transacting as a
| consumer then that won't cut it.
| djschnei wrote:
| Bitcoin doesn't need to increase its throughput. This is what
| layer 2 (3,4,...,n) solutions are for. This is like saying "Well,
| the dollar is useless because Fedwire TPS doesn't accommodate all
| transactions." If you compare apples to apples, Bitcoin is more
| than adequate to replace something like Fedwire with a zero trust
| decentralized system. Layer 2 solutions for Bitcoin can look
| something like The Lightning Network (trustless) or something
| like the Liquid side-chain (maybe for institution-to-institution
| settlement?).
| lottin wrote:
| Sorry but bitcoin is peer-to-peer cash system. If it can't
| handle peer-to-peer transactions then it's an utter failure.
| itsdsmurrell wrote:
| Correct, BTC is not peer to peer cash, try the real Bitcoin,
| Bitcoin Cash.
| dalmo3 wrote:
| 99% of the content on news.ycombinator.com is not about
| startups. An utter failure!
| ketzo wrote:
| If you want people to actually be able to pay for things with
| Bitcoin (often a stated goal), then yes, it does.
___________________________________________________________________
(page generated 2021-05-12 23:00 UTC)