Live data from Hacker News

First Lightning mainnet release

blog.lightning.engineering

141–150 of 216 posts

Re: First Lightning mainnet release

#141

Earlier quoted context omitted.

To a close approximation, the first couple million bitcoins were created for free as well.

It's funny to think of all the people getting into Bitcoin in 2018 thinking they're "getting in early" when the math behind Bitcoin granted those early users nearly the entire supply for pennies and anyone buying in recently or in the future will exchange real capital in exchange for these tokens generated for nearly 0 capital effort. Measurably less CAPEX and OPEX for the first users to run the software "securing" t…

Sounds like a pretty good way to drive adoption.

Re: First Lightning mainnet release

#142

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)...

BCH's approach would eventually centralize the network. Remember that at least one of these blocks is generated every 10 minutes, and more than one might be flying around during a chain split. Remember also that nodes do actually need to iterate over all the transactions in the block to check they are valid when they receive a new block. Proof of stake prevents malicious actors from wasting CPU/DiskIO on full nodes w…

You're talking about the cost of future tx thruput and comparing it to today's storage prices. How can you not see what's wrong with that?

>But bigger blocks is definitely not that solution.

How easy it is to make a claim without any proof.

>Originally with the 1MB block, there were quite a lot of full bitcoin nodes running on raspberry PI's under peoples desks in places with really shitty internet. Segwit kinda-sorta actually increased the block size from 1MB to up to 4MB. 16% of Malaysia gets internet slower than 256kbps. Running a bitcoin node today takes up ~20% of a connections total bandwidth in these places. Increase the block size to 20MB, and it will not be possible to run a node in some areas of Malaysia, because 20MB/10min is too fast for the connection.

Heh, even Segwit proponents don't understand Segwit. Please stop lying about 4MB blocks, it just wastes all of our time. Segwit arbitrarily considers the "witness" portion of the TX to be 25% of its real size in bytes (they define a "block weight" accounting measure that distorts the true storage cost).

This means blocks can only be 4MB if the block is entirely witness data, which never happens in the real world. In practice, segwit will give you 1.7-2MB blocks. There is no efficiency increase (in terms of tx thruput per unit of computation, etc) with Segwit at all, there is only the increased tx thruput caused by bigger blocks (how ironic).

>Running a bitcoin node today takes up ~20% of a connections total bandwidth in these places. Increase the block size to 20MB, and it will not be possible to run a node in some areas of Malaysia, because 20MB/10min is too fast for the connection.

You use a misleading definition of bitcoin nodes that has been used to poison the discussion. A non-mining node has no role in securing the network, except for SPV wallets (lite wallets). Mining nodes have the full power to choose which transactions are uptaken into the blockchain (merkle tree), so non-mining nodes are a garbage metric to use to judge 'centralization'. It doesn't matter if everyone and their dog has a copy of the blockchain on their raspberry pi, if they're not mining they're not securing the network, period.

The original bitcoin whitepaper written by Satoshi is quite clear - when they refer to nodes, they mean miners.

As you can see, the entire manufactured block size debate is built on misinformation and propaganda. How sad that the bitcoin community fell apart as soon as Satoshi disappeared.

>At 20MB of transactions per 10 minutes it's also possible that the diskIO on a gen-1 Raspberry PI using a cheap SD card might not be enough to scan and validate every transaction in an incoming block. Remember that a node might have to scan very far back in the blockchain to find the last time an unspent output was interacted with. I'm not sure how big a block has to be before that IO overhead starts eliminating entry-level hardware.

Entirely irrelevant. Your average cryptocurrency user does not need to validate the entire blockchain. They only need to ensure their own TX have made it into the chain, a role fulfilled by SPV wallets like electrum. Again, Satoshi himself said this.

Re: First Lightning mainnet release

#143

Earlier quoted context omitted.

> leading to centralization Repeating this propaganda over and over and over doesn't make it true. No centralization will occur with an increase in block size, as there will still be enough participants to prevent attacking the block chain. If what is meant by centralization is the reduction of people who can run nodes, then keeping the block size small also increases centralization by this definition, as there is a…

How does reducing the number of people who can transact involve centralization? Aren't we discussing centralization of the mining/network power?

My point is that neither reducing the people who can transact nor who can mine have any effect that can be called "centralization". It's propaganda. Centralization implies a single point of control. Having less people be able to transact or mine doesn't change the fundamental properties of bitcoin and "centralize" it. Centralization is not a gradient.

Re: First Lightning mainnet release

#144

Earlier quoted context omitted.

Based on the exponential growth of disk size, I don't see this as a problem. I wouldn't be surprised if the entire chain, even at visa levels, could be stored on an average phone in 10 years.

Exponential growth eventually slows down.

Right, for both disk size and transaction rates. Your point?

Re: First Lightning mainnet release

#145

Earlier quoted context omitted.

You're kidding right? We were supposed to be seeing this over a year ago. They've been consistently behind on their promises.

LN Dev: "We're 6 months away." Dec 14th, 2015 https://mobile.twitter.com/starkness/status/6765995708984197... Something seems off with what LN claims is a p2p network, as the claim is they've created something better than BGP yet there's going to be many many race conditions if the network is ever actually used at scale and the only solution to those race conditions will be broadcasting updates to inform other nodes…

LN will have all the problems of BGP, fused with all the problems of KYC/AML/legacy financial institutions.

It's truly a beautiful monstrosity. It'd be hard to come up with a more objectively inferior solution if you really tried.

No longer can a new user just send a transaction and have that magical user experience, instead they have to be given permission to transact by monolithic liquidity hubs, who of course must take their own fee. In fact as a rational lightning hub owner, I would want a rate of return similar to stocks but times some multiple to account for the very high risk of my hot wallet getting hacked and losing all my money.

Full disclosure: I'm a BCH/XMR supporter although I no longer own either since I've been sitting out of the scene for the last few months while waiting for all this idiocy to blow over

Re: First Lightning mainnet release

#146

Earlier quoted context omitted.

It's funny to think of all the people getting into Bitcoin in 2018 thinking they're "getting in early" when the math behind Bitcoin granted those early users nearly the entire supply for pennies and anyone buying in recently or in the future will exchange real capital in exchange for these tokens generated for nearly 0 capital effort. Measurably less CAPEX and OPEX for the first users to run the software "securing" t…

Sounds like a pretty good way to drive adoption.

Only for early adopters who know they'll be able to exploit late adopters. Users clearly become incentivized to market their free tokens as an opportunity at wealth, as they exit and sell them to late bag holders.

Satoshi could easily have designed the PoW to distribute more slowly, and favor long term growth as more users join the network. Instead only early adopters control the supply. The risk of this is catastrophic.

  One important point: if we actually include all 7 billion 
  people on the earth, most of whom have zero BTC or 
  Ethereum, the Gini coefficient is essentially 0.99+. And  
  if we just include all balances, we include many dust 
  balances which would again put the Gini coefficient at 
  0.99+. Thus, we need some kind of threshold here. The 
  imperfect threshold we picked was the Gini coefficient 
  among accounts with ≥185 BTC per address, and ≥2477 ETH 
  per address. So this is the distribution of ownership 
  among the Bitcoin and Ethereum rich with $500k as of July 
  2017.


  In what kind of situation would a thresholded metric like 
  this be interesting? Perhaps in a scenario similar to the 
  ongoing IRS Coinbase issue, where the IRS is seeking 
  information on all holders with balances >$20,000. 
  Conceptualized in terms of an attack, a high Gini 
  coefficient would mean that a government would only need 
  to round up a few large holders in order to acquire a 
  large percentage of outstanding cryptocurrency — and with 
  it the ability to tank the price.

  With that said, two points. First, while one would not 
  want a Gini coefficient of exactly 1.0 for BTC or ETH (as 
  then only one person would have all of the digital 
  currency, and no one would have an incentive to help boost 
  the network), in practice it appears that a very high 
  level of wealth centralization is still compatible with 
  the operation of a decentralized protocol. Second, as we 
  show below, we think the Nakamoto coefficient is a better 
  metric than the Gini coefficient for measuring holder 
  concentration in particular as it obviates the issue of 
  arbitrarily choosing a threshold.


  ...However, the maximum Gini coefficient has one obvious 
  issue: while a high value tracks with our intuitive notion 
  of a “more centralized” system, the fact that each Gini 
  coefficient is restricted to a 0–1 scale means that it 
  does not directly measure the number of individuals or 
  entities required to compromise a system.


  Specifically, for a given blockchain suppose you have a 
  subsystem of exchanges with 1000 actors with a Gini 
  coefficient of 0.8, and another subsystem of 10 miners 
  with a Gini coefficient of 0.7. It may turn out that 
  compromising only 3 miners rather than 57 exchanges may be 
  sufficient to compromise this system, which would mean the 
  maximum Gini coefficient would have pointed to exchanges 
  rather than miners as the decentralization bottleneck.


  Conversely, if one considers “number of distinct countries 
  with substantial mining capacity” an essential subsystem, 
  then the minimum Nakamoto coefficient for Bitcoin would 
  again be 1, as the compromise of China (in the sense of a 
  Chinese government crackdown on mining) would result in 
  >51% of mining being compromised.
https://medium.com/@balajis/quantifying-decentralization-e39...

Re: First Lightning mainnet release

#147

Earlier quoted context omitted.

> leading to centralization Repeating this propaganda over and over and over doesn't make it true. No centralization will occur with an increase in block size, as there will still be enough participants to prevent attacking the block chain. If what is meant by centralization is the reduction of people who can run nodes, then keeping the block size small also increases centralization by this definition, as there is a…

I guess that's true based on your definition of "trustless". But I wouldn't consider a network where as a practical matter I have to rely on a small number of centralized servers for validation "trustless".

That's just unfounded vague fear though. Do you have a concrete concern, or a specific technical scenario where having less mining nodes is a real problem?

Re: First Lightning mainnet release

#148
post #90

Earlier quoted context omitted.

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

I am very curious about this as well. In this example [0] someone was able to precompute 30k transactions in 5 hours with a single 1070. A mining farm with 100 video cards (capital cost of $40k) could generate a sustained load of 10k transactions per second. With precomputation, you could easily do an order of magnitude more damage. All of these transactions are stored permanently on the ledger as far as I can tell.…

Your calculation is wrong. One 1070 is able to produce about 1.6 txs, so 100 x 1070 are able to produce 160 txs. For a full transaction you need to do two time POW (send and receive), so if you use the same cards to receive the tx also you are only able to produce 80 txs. Right now I do not think you would harm the network up to about 10k - 50k txs (a simple laptop is able to monitor about 1k txs). So you may want to target at least 10k txs, therefore you would need more than 10k graphic cards at a cost of about $500 each at least, this sums up to $5,000,000 and as I said it is not clear that this would harm the net in any substantial way.

Re: First Lightning mainnet release

#149

Earlier quoted context omitted.

Lightning Network isn't really a satisfying solution in my opinion. It means that Bitcoin will just be a low-capacity settlement layer, and regular purchases will need to use PayPal-like middlemen to avoid hefty fees. There are a few on-chain scaling solutions. One is Vitalik's approach to sharding. Payments would be split into debits and credits, and a credit transaction would include a Merkle proof showing that a b…

Lightning is not a third party that takes custody of your funds, in what sense is it “paypal-like”?

You must be granted permission by liquidity hubs who route your payment, because it is a complicated (A wants to transact with C so B signs a transaction with C contingent on an equal transaction between A and B) design.

The alternative, just fucking sending your bitcoin without a trusted third party, is the only viable option. And that requires not trying to mandate a transaction limit through a completely arbitrary and manufactured block size cap

Re: First Lightning mainnet release

#150
post #114

Earlier quoted context omitted.

There is no added risk of double spend in lightning. The risk in lightning is that your counterparty can close the channel on an old state that benefits them. If you, or your watchtower (not yet implemented) is not there to punish fast enough, they can run away with your bitcoin.

What happens if they DDOS you (or your watchtower) at the right moment? Most peoples' bandwidth is shit enough that forcing them offline is fairly straightforward.

You get fucked over.

That, along with hot wallets, is why lightning is a horrific security nightmare. It's not built to withstand adversarial attacks the way bitcoin itself was.

To be blunt, they took an elegant vision by Satoshi and shit all over it

Post reply on HN