josephpoon

I'd just like to interject for a moment. What you're referring to as Linux, is in fact, systemd/Linux, or as I’ve recently taken to calling it, systemd plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning systemd system made useful by the systemd init system, IPC layer, and other vital system components comprising a full OS as defined by POSIX.

Many computer users run a modified version of the systemd system every day, without realizing it. Through a peculiar turn of events, the version of systemd which is widely used today is often called "Linux", and many of its users are not aware that it is basically the systemd system, developed by Red Hat. There really is a Linux, and these people are using it, but it is just a part of the system they use.

Linux is the kernel: the program in the system that allocates the machine’s resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system. Linux is normally used in combination with the systemd operating system: the whole system is basically systemd with Linux added, or systemd/Linux. All the so-called "Linux" distributions are really distributions of systemd/Linux.

(/s)

Sorry Greg! I didn't mean it in the sense that Blockstream is planning for a hub at all! I was being sarcastic, but perhaps that wasn't conveyed properly in text. I thought the "if they ever make one" was sufficient, but it didn't properly convey the cultural apprehension towards those types of systems and could be seen as deeply disrespectful. We were definitely in agreement from the start that decentralization in the protocol layer was immensely important.

I thought it was obvious that the parent poster was being ridiculous, but should've ended the post with :^)

Cheers! :D

If you have any questions, do send me an email. I'm working on making the explanation better so feedback is always appreciated.

No need for username/passwords. The flow would literally be you paid? You're done. No more per-website API tokens.

Pay per website you visit, you visit a lot of different websites.

The notion is that you make each payment to be the smallest atomic component, so you need high-volume for that (since one large purchase gets split into many small purchases).

End-users don't like being scammed. If it's sufficiently low value with sufficiently high service level, you will get adoption. Appstore payments of $0.99 don't even register for a lot of people (with the exception of egregious Pay-to-Win games), if the payment was $0.001 and you only end up spending $0.10 in a day nobody would care. If you're getting billed per-hour on AWS, people prefer that to per-month.

The benefit between companies isn't for persistent relationships. It's the notion that you're reducing information cost (instead of paying a large payment with signon, you don't care who your counteparty is -- if they don't deliver who cares you're only out $0.001). In the longer-term, this is about reframing how you discover business relationships in the first place due to information/transaction costs.

The presumption would be the underwriting risk is batched and pushed to one point (the exchange point). It's economically feasible to underwrite a single transaction for hundreds of dollars to buy Bitcoin (exchanges doing AML/KYC). It's much more uneconomical to underwrite a $0.001 payment -- as a result building a real marketplace for this becomes difficult even if there would be a lot of users.

I thought their minimum was $0.01 last I checked, I stand corrected!

Venmo also explicitly discourages you from sending money to people whom you don't have a social relationship with due to chargeback risks. They're a long ways away from being a general payment platform for goods and services online with people whom you don't have a prior relationship with, and as part of that will likely drop it from their business model. There's a reason why Paypal has been talking about doing it for 15 years but haven't actually done it (paypal doesn't charge any fees for payments to your friends but charges fees if you're paying for goods and services).

Let's say you're Alice. You have a channel open with Bob. Bob is connected to Carol (OKPay).

You update your channel to tell Bob, I will pay you conditional upon a proof that you paid Carol. Bob pays Carol and provides proof. If Bob didn't provide proof after an agreed timeframe, this gets cancelled. There can be an arbitrary number of people between you and Bob (7-degrees of Kevin Bacon, but probably don't go too high!).

This is done completely off-blockchain. At any time this can be moved on-blockchain, but since the blockchain will enforce the payment as part of its transaction scripting language, you both elect to do it off-blockchain. Think of this with the system intent/design where it represents an enforcible caching layer where invalid cache can be corrected on-blockchain.

You can do thousands, even millions of these transactions off-blockchain. Only the final balance is net-settled on the blockchain. So you finalize your balance between Alice and Bob if you want to close out the channel. Note that the channel between Bob and Carol could still be left open and everything still works fine!

Since it's scalable in a routed graph (think switches instead of hubs), you could potentially do millions to billions of transaactions which route value, much like routing packets on the internet.

The fun part of the Lightning Network is that you're actually exchanging bitcoin transactions. You're just keeping a local cache and electing when to broadcast it. It's flipping the double-spend problem on its head (and using it as a feature) and securing it via time-bonded proofs using programmed Bitcoin scripts native to the blockchain itself.

At any time either party can close out the channel unilaterally by broadcasting the most recent state. The person that broadcasted it gets refunded after a delay (assuming the uncooperative case where the other party in the channel goes off the Antarctica or something -- in a cooperative case, both parties close out immediately with the current balance).

Leaving coins in LN is fully backed on-chain, of course, since these are real bitcoin transactions passed around. The added benefit is you can transact instantly in high volume, so coins in LN will probably have more use than coins off LN when it comes to payments.

Ah yeah, that's a good point, I totally forgot about them, thanks!

I think the big difference here is that obviously decentralization is nice, but the real issue is that Linden could do it because they simply didn't become big enough to be a target. There were some attacks at the edges, but if you wanted to do what Linden did at Visa-scale, they would quickly put a stop to it with chargebacks.

Adversarial problems are far easier at smaller scale, but it is a good point, thanks for the correction! It may be more accurate to say nobody's done it where it could be conceptually feasible at high-scale/volume with dedicated adversaries (many of the Linden exchanges solved this with high exchange rates to buy in, e.g. Virwox).

For the HN crowd passing by, here's why this stuff could be interesting to you.

It's not possible to do extremely small micropayments on bitcoin directly as people use it today. Bitcoin's made a lot of promises around micropayments, but doing it in an economical way has tradeoffs, especially if you're talking about millions to billions of transactions per second. In fact it's not possible to extremely small micropayments on ANY platform. Try sending $0.001 to someone once. It's not possible. The closest you're probably going to get is sending someone an item on Steam (and there's no easy way to price the items). The reason for this is underwriting costs, it's too expensive for Visa to process it since they're assuming some liability. Even Paypal, who ostensibly should be doing this, charges $0.30 for payments for goods and services.

Lightning allows for micropayments to actually happen because custody is still pushed to the edges, so you don't have the same kinds of underwriting risk.

This means that something as simple as paying someone $0.001 over the internet one time will become viable this year. The amount of possible business models and use cases could dramatically shift. Users may not know they're using Bitcoin (your application could hide it and abstract it away), but people are getting paid in a way they could not before (even centralized systems did not exist, let alone decentralized ones). Pay-per-click webpages, massive decentralized CDNs, creating API services without a username/password to make onboarding seamless (you paid? you're done!).

We're working on code here: http://github.com/lightningnetwork/lnd It's MIT licenced and will soon have some pretty simple APIs to use. Of course, since this stuff will be in testing for a little while, make sure you only use small amounts/micropayments initially when it's released.

Not sure why it's posted again, but we might have some announcements soon :D

The Lightning Network is blocksize agnostic. I haven't been arguing on either side of the blocksize debate.

Our implementation will not be biased towards Blockstream's hub if they ever make one. In fact, it's designed to work in a scale-free network topology.

You can find it at https://github.com/lightningnetwork/lnd

What are you talking about? I don't control the Bitcoin codebase at all. I don't have commit access to Bitcoin's repo.

Lightning Network for Bitcoin uses Bitcoin's scripting, as it uses real Bitcoin transactions.

You are wrong. Lightning works by using smart contract logic. For Bitcoin in particular, that involves using Bitcoin scripting using real Bitcoin transactions.

That blogpost is basically describing lightning. Lightning Network has explicitly described instant cross-chain swaps privately, and publicly for many months.

I agree wholeheartedly, all aspects of scalability needs to be (are being) looked at, with an eye for practicality. Hopefully, LN will reduce the load on-chain for people currently using bitcoin for instant low-value transactions as well by using LN and freeing up some blockspace.

The paper never refers to hubs, the necessity of a handful of entities routing payments a-la Visa has never been part of the design. There are certainly more connected nodes, but that's true in any P2P system (as well as nodes with higher uptime). Additionally the paper refers to larger blocks, LN doesn't resolve underlying block capacity issues alone, it could help mitigate its problems significantly -- much like how a switched network helps resolve bandwidth (but you still might want faster connections).

I've never argued that it is a dead certainty, certainly less so than you have argued that arbitrarily large blocksizes are the only solution.

Quite frankly, I don't understand why you're so butthurt with my comment, I've stated that I think multiple solutions are best, and have explicitly avoided the politicization with this community.

I can assure you, the CS understanding of the people who disagree with you (like Chris, Gavin, myself and Satoshi) is just fine

I'm pretty sure your comments don't accurately represents Gavin's view (AFAIK, he also thinks we need to explore many technical approaches), nor do you speak for Satoshi (current understanding of bitcoin's risks is significantly different than 2011).

Engineering costs are one thing, technical impossibilities are another. It's not credibly possible for bitcoin to exist in its current form while also being able to make a $0.0001 payment. I agree there are some aspects to consider, esp with maximizing the social value of the network and testing it out, though. Certainly, for all we know there may be unaccounted issues, but that's the case for bitcoin as well (51% risks are still unknown).

For those who are not paying attention to the bitcoin discussions, I have always stated many transactions will still be on-chain (e.g. large directional flows, but paying $0.001 has not been feasible for a very long time in Bitcoin, LN enables those payments to exist using Bitcoin again).

I'm presuming 3dfan is assuming some kind of split in merchant/exchange acceptance, I agree this is less likely, though. However, in a hardfork, you can be sure there will be some kind of forkA/forkB exchange site that will emerge (not at a 1-to-1 exchange rate, of course).

It's already infeasible to directly make a single spend of $0.0001 on the blockchain itself (transaction fees are $0.02-$0.05).

This is correct. The simplest way to do this would be to include in your transaction a spend deriving from the coinbase block reward after the fork.

It seems I wasn’t the only one with this concern as there’s been a fairly recent pivot away from the hub-and-spoke network topology to a more organic, wallet-to-wallet routing. The network is now envisioned as a more pure p2p payment layer without those large scale payment hubs.

As the co-author of the Lightning Network, this is not true, there has been no pivot. The design has always designed around wallet-wallet topologies from the beginning (try doing a Find for the word "hub" in the paper). Will there be nodes more connected than others? Of course. But with LN, they are designed to be interchangeable and formless. It may look like other P2P topologies of ever-shifting "supernodes", but never irreplaceable "hubs" like Visa or Fedex's single primary Memphis, TN hub -- in fact you'd be challenged to find a P2P network with a topology of only a handful of static hubs (this makes sense because establishing connectivity is cheap in a virtual system, opposed to physical infrastructure like wires or an airport).

I'm not particularly happy that "small-block skeptics" are using LN as some kind of punching bag against their pet ideas of who the enemies are (the arguments have become highly politicized in the bitcoin community). The LN paper itself presumes bigger blocks, and have never argued that LN is the sole solution, merely that a large component of scalability needs to occur via moving transactions off-chain. The alternatives are a failure of mining incentives (whether it be low-value transactions get crowded off bitcoin and moves to a bitcoin-backed centralized ledger, or the fee-market breaks down and miners reduce fees far too low due to commons externalities).

There is a clear obvious misunderstanding of core principles in computer science, wishful thinking does not solve real problems. It is is akin to assuming that systems are easily capable of a broadcast topology -- that everyone in the world can be on the same wifi access point. Bigger block capacity is desirable, but it's also desirable to be able to instantly transact a payment of $0.0001 without everyone in the world processing that payment.

(I'm going to be intermittent with computer access today due to the holidays but I will reply to email or respond tomorrow :P)

Instead I'd rather see people try to fix the problem of it being expensive to spend bitcoin sourced from many small inputs.

Lighting does this. With a single blockchain transaction, you can conduct as many micropayment transactions as you desire with anyone else this network. After the first funding transaction (which is broadcast on the blockchain), there are no more blockchain transactions until you wish to settle the channel. All micropayment transactions are deferred and net settled on channel closure. Your current balance is updated off-blockchain securely with real bitcoin transactions (which current state can be broadcast at time by either party).

So if the lightning network does get build, we'll all be able to use microtransaction channels which will slow the growth of the blockchain, but will still cost $20 in fees to send $100 worth of bitcoin sent in tiny UTXOs.

It'll probably cost a lot to set up the channel and to close it out, but you'll only do that once and it can last for years. It's equivalent to setting up a bank account. The actual day-to-day payments are off-chain (without counterparty risk).