Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

First Lightning mainnet release

blog.lightning.engineering

Post reply on HN
Print view View original

31–40 of 216 posts

Re: First Lightning mainnet release

#31

Post by lawlessone »

Ajedi32 wrote: post #27
__blockcipher__ wrote: post #9

Serious question, why does HN seemt o be in favor of lightning over BCH’s approach of not neutering the block size? LN has so many drawbacks. Have to always be online, need to hold hot walkets, need liquidity provided at both ends (kyc/aml)...

I can't speak for anyone else, but for me personally I just don't like the approach of trying to solve the problem by throwing more disk space at it. It feels... inelegant, and probably unsustainable long term. Imagine for a minute a future where Bitcoin goes mainstream and needs to process ~2k transactions per second. (A reasonable estimate of the world's current credit card transaction rate, and 3 orders of magnitu…

If we keep bitcoin block sizes as they are or reasonable we can roughly predict how big the whole chain would be 100 years from now(im being very optimistic here.)

Re: First Lightning mainnet release

#32

Post by CyberDildonics »

cmer wrote: post #12
CyberDildonics wrote: post #11

Earlier quoted context omitted.

Let's stop and think for a moment about how practical it is to promise everyone free and instant transactions. If they prevent spam with proof of work, why couldn't someone just do the proof of work and constantly spam the network anyway?

It quickly gets very expensive to do so.

How? If the proof of work only takes a few seconds, what prevents someone from spamming a new transaction every few seconds?

Re: First Lightning mainnet release

#33

Post by jgeerts »

__blockcipher__ wrote: post #9

Serious question, why does HN seemt o be in favor of lightning over BCH’s approach of not neutering the block size? LN has so many drawbacks. Have to always be online, need to hold hot walkets, need liquidity provided at both ends (kyc/aml)...

If we ever want Bitcoin to evolve from a store of value to an actual payment method we have to come up with something that does at least better than VISA's 8000tx/s and that's just not solved with going from 7tx/s to Bitcoin Cash's ~62tx/s. We have to be able to compete with every payment method out there and we should be able to handle peak throughput during sales period.

Another important factor is the 10 minutes confirmation time, nobody wants to wait for 10 minutes at the counter before they trust you walking out. We need something with instant verification and low fees and increasing the blocksize will never do that.

Re: First Lightning mainnet release

#34

Post by foepys »

knocte wrote: post #25
foepys wrote: post #10

Did the Lightning Network solve the routing problem now or are they still emulating banks by requiring permanent online super nodes?

You know what? All the hops where your TCP/IP connection has gone to allow you to write that message, were provided by devices that had to be online in order to provide you the services. EOM

Yes, but routers aren't responsible for keeping my money safe. If you don't constantly monitor all your LN channels, the other party can just steal your money by issuing fraudulent messages to the network.

Re: First Lightning mainnet release

#35

Post by thisisit »

apo wrote: post #29

For those who may not know the context, this has to do with long-term scaling of the Bitcoin network. The very first public response to Satoshi's announcement of Bitcoin was an expression of doubt about scalability: We very, very much need such a system, but the way I understand your proposal, it does not seem to scale to the required size. ... To detect and reject a double spending event in a timely manner, one must…

> Each one represents a kind of private ledger.

That is an interesting quote. So, without the blockchain, how does Lightning track which transactions have been completed?

Re: First Lightning mainnet release

#36

Post by osteele »

lawlessone wrote: post #30
osteele wrote: post #26

Earlier quoted context omitted.

> then there will be more demands to make the blocks bigger again, eventually leading to centralization Because having a bigger block size raises the barrier to being a miner. (CapEx and OpEx are both greater.) Imagine the other extreme: mining is so cheap that every phone, watch, and — oh let's just throw in every mouse and pigeon cortex — can be a miner. This is near one extreme of decentralization. That's unattain…

Iota is horrendous(they rolled their own crypto and its bad) and no IOT company will ever bother with it.

> Iota is horrendous(they rolled their own crypto and its bad)

Yeah, I probably didn't emphasize this enough. In addition to last year's curl fiasco[1], and this year's email dump[2], there's now this unlucky-13 exploit[3].

> no IOT company will ever bother with it

This would seem to follow, but [4] (partnership with Cisco, Samsung, and Volkswagen), if true, contradicts it. (I'm skeptical of IOTA partnership announcements because of last year's IOTA/Microsoft “partnership”[5].)

[1] https://hackernoon.com/why-i-find-iota-deeply-alarming-934f1...

[2] https://spectrum.ieee.org/tech-talk/computing/networks/crypt...

[3] http://blog.lekkertech.net/blog/2018/03/07/iota-signatures/

[4] https://www.computerworld.com.au/article/630565/blockchain-n...

[5] https://cointelegraph.com/news/iota-clarifies-misleading-mic...

Re: First Lightning mainnet release

#38

Post by brendanw »

jgeerts wrote: post #33
__blockcipher__ wrote: post #9

Serious question, why does HN seemt o be in favor of lightning over BCH’s approach of not neutering the block size? LN has so many drawbacks. Have to always be online, need to hold hot walkets, need liquidity provided at both ends (kyc/aml)...

If we ever want Bitcoin to evolve from a store of value to an actual payment method we have to come up with something that does at least better than VISA's 8000tx/s and that's just not solved with going from 7tx/s to Bitcoin Cash's ~62tx/s. We have to be able to compete with every payment method out there and we should be able to handle peak throughput during sales period. Another important factor is the 10 minutes c…

It exists. It is called nano: no fees and instant transactions through the block lattice. https://nano.org/en/whitepaper

I am surprised more folks on HN are not familiar with nano considering it is one of the few teams in crypto with endorsements from familiar faces: Zack Shapiro on the core team (ex-Product Hunt), Garry Tan (YC, angel investor in Coinbase), and Charlie Lee (former director of engineering @ Coinbase).

Re: First Lightning mainnet release

#40

Post by XR0CSWV3h3kZWg »

apo wrote: post #29

For those who may not know the context, this has to do with long-term scaling of the Bitcoin network. The very first public response to Satoshi's announcement of Bitcoin was an expression of doubt about scalability: We very, very much need such a system, but the way I understand your proposal, it does not seem to scale to the required size. ... To detect and reject a double spending event in a timely manner, one must…

This is an excellent high level description.

Lightning network allows for an arbitrary high number of tx, but can only tx on value that has specifically been locked to do so. Essentially you end up creating a bidirectional link for each on-chain tx, the weight of each link is the amount of value that can flow in that direction. Joining a bunch of these links together potentially allows for just locking up funds with some larger node in the LN and having near instant and extremely cheap payment to node that is traversable from your link.

One of the really cool things about this architecture is that as long as two blockchains offer atomic x-chain txs then the same principal should work for LN. (e.g. send litecoin down a LN payment channel the business gets bitcoin on the other end)

Unfortunately this does have security implications, LN's security model relies on monitoring the blockchain to ensure that the other side of the channel doesn't attempt to close the channel to their benefit, if they do there is remediation you can do, but you have to be monitoring the channel. Also an inability to close the payment channel (tx on the blockchain) within a certain # of blocks could result in the history of the payment channel getting cleared.

Basically if the bitcoin network experiences a huge tx backlog like we saw a couple months ago (tx fees exceeding 15-20 USD) and we see third party routers with high dependency/volume we could see a double spend attack that would be cost prohibitive to stop.

Post reply on HN