BitPay Will Process Payments on Multiple Blockchains, Starting with Bitcoin Cash

These kinds of transactions aren't feasible on the Bitcoin chain since the fees are prohibitive, so all those small unspent outputs remain in the UTXO set forever and are essentially unspendable.

I'd also argue that increasing the block size scales fine as long as network speeds and storage continue to scale as they have been over the past years.

But it could be years later; years in which other scaling solutions can be researched. If you only accept scaling solutions that can scale to infinity today, you will never accept a single one.

That's not doable today, but it is not TOO far off.

And by the time adoption catches up, maybe the technology and bandwidth costs will be capable of supporting it.

The blocksize does not need to increase forever. All it has to do is replace all of the world's financial transactions.

Also it is important to note that BTC could be like BCH at higher transaction levels if they increased the block size but that won't because of this lightning network idea. Which is what I don't get. You can increase the block size right NOW and work on the lightning network as well. Yet, they don't do that because the lightning network is everything and any other solution is not even considered.

I used to also think that bigger blocks were always bad but that is simply not true. The original block size limit was purely implemented to stop spam when bitcoin's userbase was very low. Satoshi actually wanted to implement bigger blocks as the userbase grew. Bigger blocks is the not the long-term solution but it is a solution that we have right now that works.

https://www.youtube.com/watch?v=5SJm2ep3X_M

You actually have to be able to say: "See, I found a route A-D through B and C: ABCD and all nodes are sufficiently funded to execute the payment."

And that's the big unsolved issue. Can you make an algorithm that will reliably do the latter while keeping the network decentralized?

I think this is very hard, as the channel states between individual nodes will change for each payment, and that's entropy that somehow needs to be synchronized.

Of course, simple centralized solutions like making B and C big enough ("banks") to deal succesfully with almost any payment are possible.

But solving this problem is pretty damn hard, and I have yet to see a satisfying solution to this. Note that satisfying absolutely must include being decentralized.

Because else, we can as well do the simple and sane thing and scale just on-chain, which also ensures that the miners get their fair share of the pie and makes it less likely that the bottom falls out because there's lots of layers, each taking a cut, to the system.

Now, don't get me wrong: I am fine with LN and I think it might have good use in the micro/nano-payment space. Regular, simple payment channels (like BCH and BTC have since the beginning) might fully cover that use case as well. Who knows. In any case, LN as the (and the only) solution to scaling is not going to work out.

The Bitcoin developers (not "Bitcoin Core") had just implemented a block size increase after years of discussion.

The segwit2x intiative didn't take part in this. They didn't bother even writing a specification, let alone a proposal or take it through public discussion.

The last one (Segwit2X) had it's reference nodes so poorly coded that the mining nodes didn't even manage to mine their first block; due to 3 separate off by one errors that even basic testing would have revealed. Shoddy coding like that is yet another reason why the core devs (and the community) wanted nothing to do with the 2x team. And given how it took them months to fix BCH's difficulty algorithm, I'm not really convinced that they've improved.

Litecoin will have the same scalability problems as bitcoin core, and it hasn't attracted a cutting edge-team that will be likely to try a different approach to improve the situation. Litecoin is a clone using recycled code and ideas from bitcoin. Clones with stale ideas don't generally eclipse their originators.

Cars? Not a technology, only wheels and motors are technologies.

For bitpay's usecase Bitcoin is being replaced by other coins because it fails to embrace on-chain scaling in favor of off-chain scaling which is far from ready. This is exactly as predicted.

Bitcoin, the software, solves basic problems very well and is thus the basis of many altcoins.

I'll invest in the next big coin if it is significantly better than Bitcoin while continuing to maintain Bitcoin's core value argument.

Monero is the only real cryptocurrency because it does not have a public ledger. Monero is fungible, meaning you cannot tell two coins apart, which is an essential property of money.

This is a very real issue most people into Bitcoin does not seem to care about. Anyone you transact with can gain insight into your personal finances which at best informs your friends of how rich/poor you are and at worst making you a robbery target.

I understand that miners can choose to leave Bitcoin, and this is largely dependent on price, but historically, Bitcoin provides the most security, so it is the safest crypto for storing a large amount of value.

Lightning allows users to take a single bitcoin transaction, and use it over a finite space of time, in order to shift bitcoin back and forth, with no or vanishingly small transaction fees, as iou's between what are called 'lightning channels'. The actual transaction size will be the same as a normal transaction, with a flag that says it can only be committed to the blockchain at a specific time (or block depth). In effect, these lightning transactions are cryptographically signed 'iou's. The 'thousands' of back-and-forth iou changes are discarded when the channel is closed (massive privacy dividend), and only the aggregated change is committed to the blockchain. This is the great thing about lightning. It is a single transaction with as many inputs and outputs (one/two) as defined in the original transaction. Only the transaction values change.

Consider a channel link of this : John->Bob->Sally->Anne. Only the people next to each other in the chain have a 'channel open' with each other (John/Bob, Bob/Sally, Sally/Anne). Assuming each of the channels between all of the participants have adequate funds in order to achieve this, if John wanted to send 1btc to Anne. A transaction ledger would read :

John->Bob channel : John -1btc, Bob +1btc

Bob->Sally channel : Bob -1btc, Sally +1btc

Sally->Anne channel : Sally -1btc, Anne +1btc.

Anne now has 1btc more, and John has 1btc less, but the net effect in each channel is simply a modification to the distribution of bitcoin in that channel.

Imagine this happening, back and forth, and extended to thousands, tens of thousands, and millions of people. As long as there's a chain between them, you use the chain. You might even have your transaction split over multiple chains. For links that don't have a chain, you create a channel on-the-fly.

Each channel, therefore, only ends up with the same single input, and the same two outputs, just differing values.

It's significantly more complex than that (transaction routing, and channel closure mechanics), but that's the idea. I wish I could remember the lightning dev that explained it. It really is very clever. I haven't actually questioned about the effect of having channels with multiple inputs (John/Sally) and outputs (Bob/Anne) at inception. Technically, I can't see any reason why this wouldn't be possible. Just a much weirder set of ramifications.

I would suggest that the method for creating ln channels is most likely : Carol wants to pay Bob 0.5btc. She creates a ln channel with 1btc, of which Bob is allocated 0.5btc, and carol is allocated 0.5btc. Bob gets paid 0.5btc that is accessible once confirmed. Carol has 0.5btc that is now accessible once confirmed. That way the ln can be bootstrapped by existing txns.

I'd also suggest that it would be easier to understand if Bob were Bob Inc. The incentive will be for the buyer to reduce txn fees. If Carol uses a store (coffee?) she will want to reduce paying those fees. So she creates a channel with 0.1btc and 0.001 is allocated to Bob Inc. For the coffee she buys today, coffee + txn fee. Ever more? Zippo txn fee. When your channel is almost zero, you buy bitcoin, it is delivered back to you by the rebalancing of that channel. And because it's Bob Inc the path through the channels from a source of bitcoin is reduced, maybe even two hops ( exchangeA/exchangeB -> exchangeB/Bob Inc. -> Bob Inc./Carol).

If you "own" bitcoins, you have some numbers graffitied over people's hard drives. Yes they can't change it because electricity, and the numbers only get so big, and you have some different numbers that can be turned into the graffitied numbers by one particular algorithm that people like at the moment. Without transactions, these properties are completely arbitrary. I don't see how by themselves they can give anything approaching the necessities for a store of value. The truth is, without competitive transactional uses bitcoin has no fundamental value. Without fundamental value it can't be much of a store of value, since literally anything else without fundamental value can be equally good. You can store something like the goodwill of the network, as now, which isn't nothing, but it can be notoriously fickle.

Ethereum still has over two times as many full nodes as Bitcoin.

11,415 Bitcoin nodes:

https://bitnodes.earn.com/nodes/

29,805 Ethereum full nodes:

https://www.ethernodes.org/network/1

>>Most people can't even sync a node anymore.

Totally unsubstantiated.

>Bitcoin is about decentralization.

There's more to decentralization than being able to run a full node on your Raspberry Pi with a 128K modem. Like more than 500,000 people in the entire world being able to write to the blockchain with any regularity, which is not possible with a 1 MB limit on the 10-minute blocks (1.67 KB/s throughput limit). With such limited write-access to the Bitcoin blockchain, the vast majority of the world will have to rely on trusted third parties to hold their Bitcoin wealth on their behalf, since it's impossible for the vast majority of the world to have write-access to the Bitcoin blockchain in order to make use of a private key.

I'd rather Ethereum users poll multiple trusted third parties to validate the transaction data they're seeing, and be able to hold their own private keys, and write transactions to the blockchain with those keys, than Ethereum users be able to validate the blockchain trustlessly, but have to trust third parties, acting effectively as banks, to hold their ether.