Hacker News Reader

I've also been keeping tabs on the debate and I agree with you except on one account: Not everyone want the Bitcoin to be the next Visa or Paypal, some are perfectly content with a 10 minute confirmation delay as long as the blockchain remains fully distributed and anonymous, whereas others see a business opportunity that could make themselves rich and influential down the line.

The entire narrative about larger block making the network more centralised is a red herring. The network has been going in that direction for quite some time without a block size increase and in any case, going from 1MB to 2MB or even 16MB isn't going to change the economics of running a full node that much, which is to say there are no incentives for non-miners to host a full node at all, regardless of the alleged computing and network overhead (and worse, it can make you a more likely victim of DDoS attacks[0]). The entire point about keeping the 1MB limit (which was meant to be a temporary cap anyway) is to artificially create scarcity in transaction capacity and coerce people into accepting SegWit and eventually fully functional side chains.

This is probably fine for those who believe that A. Bitcoin will become mainstream and B. the ends justify the means, but I find this to be a very unethical position to take.

Disclaimer: I don't own a single cent in BTC, nor do I have association with anyone involved in the Bitcoin scene.

[0]:http://www.financemagnates.com/cryptocurrency/news/the-lates...

> partly because these off-chain networks would quickly form large central "hubs" which would obviate many of the benefits of Bitcoin

The Lightning Network is open-source and decentralized. It has no "hubs", but rather just peers that route payments to each-other using a payment routing algorithm. Lightning has no counterparty risk, as no one can ever steal your bitcoins and you're always in full control.

The best way to describe Lightning is as an write-cache layer. It improves the scalability properties of Bitcoin by many factors, makes micro- and nano- payments a reality, reduces fees to fractions of a cent, and even improves privacy (using a Tor-like onion routing for anonymized payments).

https://www.youtube.com/watch?v=MpfvhiqFw7A

https://bitcoinmagazine.com/articles/understanding-the-light...

How do you counter the description of the network in this article? It seems like de-facto hubs will form out of necessity to avoid creating a channel on the fly, which requires getting a transaction committed to the blockchain.

https://chrispacia.wordpress.com/2015/12/23/lightning-networ...

> Routing paths are much harder to find when values are considered.

Hard, yes, but definitely possible. There was some great work done on P2P routing for Lightning by the developers at BitFury.

http://bitfury.com/content/5-white-papers-research/whitepape...

> We could end up making more on-chain transactions ... Well, it will have to close one of its existing channels. So the process for making a transaction when your wallet can’t find a route is: 1) Make an on-chain transaction closing out an existing channel. 2) Make an on-chain transaction opening a new channel with the payee.

This is not true. You can close an existing channel and open a new one in a single transaction.

> The vast majority of users will be offline.

Some will, some won't. Some will set this up on a VPS, some will use hosted services, some will be professional liquidity providers (early adopters with lots of coins?) that have a machine dedicated to this.

He's making a prediction that he cannot really support in any way.

> Channels cannot be created on-the-fly.

RBF is opt-in, only if you mark your transaction as such. If you don't want RBF, don't use RBF. His assertion that RBF is somehow required is not true.

> Recipients have to be online.

Yes, they do. This is perfectly fine for some use-cases, and not good for others. For use-cases where the recipient is offline, people can always resort to on-chain transactions.

I'm not sure what this has to do with hubs, though.

Basically, he's making tons of assumptions and guesses (some of them based on incorrect/outdated technical information). You should go and read-up yourself on the technology and the improvements the developers are coming up with.

What do you mean that Lightening has no counter party risk? It's my understanding that you have to constantly monitor the Bitcoin network as long as a payment channel is open to make sure your counter party doesn't try to cheat you.

I also don't buy that hubs won't tend to centralize since hubs with channels open with a lot of other peers will naturally be central points.

Yes, you have to watch for cheating attempts, but you get all your money back plus a bonus if you catch someone doing that. If you're doing that properly (and there's no reason you won't), then there's no counterparty risk.

Edit: also, you can outsource this task to someone else, who'll take a small fee out of your bonus if he catches the cheating for you (and only if he does).

That sounds horrible. All your counter party has to do is DDOS your node off line then they can steal your lightening network funds. Outsourcing the task to a centralized service also sounds bad. At that point you have to trust that service.

Anyone that looks at lightening can plainly see that it has a number of properties that aren't as nice as pure Bitcoin. With Bitcoin if I get knocked offline there is zero chance of my counter party stealing funds from me and you don't have to put your trust in any centralized monitoring service to prevent your counter party from stealing from you.

> Outsourcing the task to a centralized service also sounds bad. At that point you have to trust that service.

You don't have to trust that service. He can't steal your money, you don't lose any privacy if the other party doesn't cheat, you don't pay anything to the service if there's no cheating attempt, and the 3rd-party service is financially incentivized to help you prevent cheating.

So, no, you don't "trust" anyone in any more meaningful sense than saying that you're "trusting" the miners.

Yes, you absolutely have to trust the service.

If I have a channel open with Alice and she wants to cheat me but I've out sourced my monitoring to Bob Alice only needs to pay off Bob to go along with her cheating me. I have to trust Bob not to collude with Alice. In Bitcoin I don't have to trust anyone. Surely you can see that there is a difference in the two models.

You can have as many Bobs as you want, which can all function at a very low cost and compete for users with low fees and high service quality. I can easily imagine registering your transactions to tens of different service providers, making it quite impossible for Alice to pay them all of (or even know who they are).

How do you know bob didn't setup many nodes to perform a sybil attack on you? You don't.

That is part of it. I think some miners are against any increase because it will lower fees. Without a blocksize limit fees tend to zero, which is fine while there is the block reward but they still want to milk the congestion fees. To say they are pro segwit or pro unlimited is bluffing. They are pro status quo and congestion and high fees.

The idea that lightning will lead to a hub, in the case of Unlimited believers they think this will be Blockstream and therefore think that the core developers who work for Blockstream are blocking a blocksize increase for nefarious reasons when they are doing it to avoid a hard fork and to maintain the incentives of miners while enabling cheap off chain transactions.

That idea that a natural hub monopoly will form is ill thought out as explained here: https://youtu.be/fst1IK_mrng?list=WL&t=6072

>They also posit that any increase in the block size will make running a full node more difficult, meaning Bitcoin will become more and more centralized and consolidated around the big mining pools that have the hardware to handle bigger block sizes.

With a bigger block size what hardware constraints begin to appear?

> This is a big problem for miners who have poured lots of money into their rigs, because now the blockchain would be little more than a settlement network. There would be far more transactions occurring off the network, meaning less money for miners.

So the motivation is strictly monetary?

> With a bigger block size what hardware constraints begin to appear?

Mostly it is an issue of disk space and network bandwidth. right now a 1 MB block is produced every 10 minutes. That has to be transferred over the network to every node and each so called "full node" has to store that block. The total size of the Bitcoin block chain for all time is currently ~100GB and grows 1 MB every 10 minutes under current conditions. If the block size grew too big that you couldn't transfer a block within the 10 minute space between blocks then your connection is too slow to run a node. On the disk space front you can run what is called a "prunning" node which discards older parts of the block chain that are no longer relevant which reduces disk space requirements greatly.

There is also the issue of the initial blockchain download where when you are setting up a new node you have to download 100GB of historical block chain data to catch up to the current state of the network. These are all solvable problems though and Bitcoin's inventor envisioned that some day full nodes would be run out of data centers on heavy duty hardware. Small block supporters have argued that that hurts decentralization because some poor guy in Africa can't run a node on his Raspberry Pi and 3g internet if the block size gets much bigger. On the other hand if you are too poor to run a full node with a larger block size then you can hardly afford to pay huge transaction fees to transact on a network with a constricted block size so the whole argument that limiting the block size decreases centralization doesn't really hold water because in the end it limits user growth which is the ultimate decentralization mechanism.

> So the motivation is strictly monetary?

I think so. This whole stink started because some guy who happened to have a ton of BTC was upset that people running full nodes didn't get a cut of any of the transaction fees. Today, the main company that is pushing the Segwit / small block agenda hopes to push everyone to their off chain lightening network where they can collect the fees instead of the miners. Miners don't want to do anything that will jeopardize their profitability long term and keeping the block size too small limits their ability to control the supply of their product (block space).

> This whole stink started because some guy who happened to have a ton of BTC was upset that people running full nodes didn't get a cut of any of the transaction fees.

What? Who?

> Today, the main company that is pushing the Segwit / small block agenda hopes to push everyone to their off chain lightening network where they can collect the fees instead of the miners.

Lightning is open-source and was invented by Lighting Labs, a company that has nothing to do with Blockstream. Blockstream are merely working on one out of 6 Lightning implementations that exists in the market.

Also, Lightning is designed for peer-to-peer routing (and not a hub-and-spoke topology) and it is expected that everyone with some spare bitcoins would run lightning nodes to collect fees, so there should be plenty competition.

Finally, Bitcoin Core is an open-source community composed of tens of developers from all over the world and from different associations, plus hundreds of testers, reviewers and other contributors. Nearly all of them support SegWit very strongly, not only the ones associated with Blockstream.

See: https://news.ycombinator.com/item?id=13627371

>it is expected that everyone with some spare bitcoins would run lightning nodes to collect fees, so there should be plenty competition.

Thanks for getting back to me in another comment and I find this assertion interesting. As I said earlier, currently there is no incetive for small players to run full nodes so the network tends towards centralisation over time. How do we know the fees involved in Lightening are sufficient that average users can be convinced to act as intermediataries?

>What? Who?

Mircea Popescu, He is the original guy who started promoting the idea that it was a mistake to raise the block size unless some incentive to run a full node was added to the system. I don't think he actually supports segwit either, he thinks soft forks are crap. He is the original voice in opposition to block size increases though and many people listen to him.

http://trilema.com/

A lot of people disagree with your characterization of how lightening networks will play out. Since they don't really exist in real world usage yet hard to prove one way or the other.

> He is the original voice in opposition to block size increases though and many people listen to him.

Many developers were opposed to reckless block size increases, I think you're giving that guy's voice too much weight. I personally never heard of him.

> A lot of people disagree with your characterization of how lightening networks will play out. Since they don't really exist in real world usage yet hard to prove one way or the other.

They sure do (early and still somewhat buggy alpha, but it does exists and does work):

http://lightning.community/release/software/lnd/lightning/20...

Without a blocksize limit then block space has unlimited supply so the price will be zero. Miners will get LOWER fees so if they think lightning is their enemy and Unlimited is their friend then they don't understand economics.

Those who want the security of on chain transactions will still pay the fees and those who accept the very slight risk of having to watch for channels being dropped for the benefit of lower fees will choose lightning transactions. There's no conflict and is the only way to get the store of value security and low transaction fees with high volume.

The standoff is the miners milking fees for as long as possible. They don't want larger blocks or segwit. This will be broken by having a less efficient lightning without segwit.

Thank you for the concise rundown.