Bitcoin Forum

Found it on hacker news and I though it's worth sharing:

http://lightning.network/lightning-network.pdf

A white paper draft has been released on the 28th of February:

http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf

Looks suspiciously similar to my Amiko Pay (http://cornwarecjp.github.io/amiko-pay/), except that the commit conditions are different. I'll have to dive into the details of their proposal to figure out whether this is an improvement or not. Their proposal also seems to require additional Bitcoin scripting functions, but possibly less intrusive ones than my proposal. I'm also interested in to what degree a useful implementation of this can be made without those scripting extensions (presumably that would be less "trust-free").

And of course: I'll think about whether their commit conditions leave any vulnerabilities / abuse modes. It can be really hard to get these things 100% right.

Interesting Proposal-

https://www.youtube.com/watch?v=8zVzw912wPo

The average transaction size is more like 400 bytes at best.

Is there any more information or discussion about this fascinating proposal out there? All I've seen so far is the whitepaper and the excellent presentation. I'm flabbergasted by its simplicity, ease of execution, and power at eliminating the three biggest blocks to consumer adoption of bitcoin as a currency: scalability, minimum transaction amounts (microtransactions), and transaction speed. I'd love to learn more about the timeline for implementing the malleability fixes they recommend, along with relative nLockTime.

http://www.coindesk.com/could-the-bitcoin-lightning-network-solve-blockchain-scalability/

"If the bitcoin blockchain were a horse, ordinary hub-and-spoke payment channel proposals would be proposing to replace that horse with a truck; the Lightning guys are proposing to replace that horse with a rocket ship."  -- Peter Todd

Requires some more work and a soft fork to implement. The future looks bright :)

A leading candidate for testing the soft-fork on a sidechain perhaps.

Merge-mined sidechains require a fork too!  :D

I guess a federated sidechain could do it.

wouldn't it be the easiest way to just create a bitcoin clone with it as proof of concept?

sidechains seems too much in the future

Why create a clone when this can be tested in a bitcoin testnet and than rolled out to be tested in a sidechain where we can test 2 important upgrades simultaneously?

Creating an alt to test this feature doesn't seem necessary and could be a distraction, but developers are free to use the info in an alt if they like.

The reason being, federation functionaries could be the lightning transaction routing hubs incentivised through fees ... so yes a fed peg fork for a lightning network.

Anyone already working on an implementation?

2 Applied examples of the Lightning network:

Lightning Networks Part I: Revocable Transactions

http://rusty.ozlabs.org/?p=450

Lightning Networks Part II: Hashed Timelock Contracts (HTLCs)

http://rusty.ozlabs.org/?p=462

Another one from Rusty: "Lightning Networks Part III: Channeling Contracts"

http://rusty.ozlabs.org/?p=467

And here we have the last of the series: "Lightning Networks Part IV: Summary"

http://rusty.ozlabs.org/?p=477

Quoting the first paragraph:


emph is mine.

This is a must read series IMHO.

just stumbled upon this collection of links of resources related to payment channels

https://github.com/utxo/wheels/wiki

not entirely related to lightning network but still worth sharing.

Fantastic resource that really helped piece things together for me.  On Part III, Rusty posted a diagram of a complete HTLC transaction: http://ozlabs.org/~rusty/diagrams/lightning-transactions-complete.svg (http://ozlabs.org/~rusty/diagrams/lightning-transactions-complete.svg)

I'm trying to wrap my head around what SIGHASH types go where, so I annotated Rusty's with my best guess:

https://i.imgur.com/JdcjYF3.png?1

Does this look right?

The paper suggests a soft-cap to combat "Forced Expiration Spam".

An attacker who causes many of the channels to be prematurely closed at once could overwhelm the network.  

This means that some nodes might not be able to get their refund transactions accepted before the expiry of the locktime.

The soft cap rule means that blocks can be made larger in an "emergency" but would normally be smaller than the soft cap.

This could be accomplished by allowing transactions to reserve space for the closing transactions using a new opcode (OP_RESERVE).


and the P2SH version


OP_RESERVE in any other place would count as a failed script.  Otherwise, it is just a NOP.

This transaction would count as that much extra space in the block.  If a 250 byte transaction reserved another 300 bytes, then when computing the soft cap, that transaction would count as 550 bytes.

A transaction which spends that output would get credit for the reserved bytes.  If it was 300 bytes, then it would count as zero bytes in size and not count towards the soft-cap.  In effect, the bandwidth was already "paid" in the previous transaction.

The soft cap would be paired with a much higher hard cap.  The average block size would be limited to the soft cap, but individual blocks could be much higher (say 10-20X).

Each tx would have an effective size of

(tx size) + sum(bytes reserved by outputs) - sum(bytes reserved by inputs)

Mike Hearn wrote a good article on the challenges of developing and testing the lightning network:

https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e

Yes, the uptime requirements for nodes, concurrency of hot-swappable redundant servers with loaded hot wallets and signing keys, etc. Tough problems. Sounds almost like real banking and payments  :D

Except these are engineering problems for a key management system. Key management can be permanently isolated and offline.

You make it sound like "engineering problems" are not tough problems. Note how Bitcoin is hard in theory, even harder in practice.

They are hard problems. The principles of Bitcoin have been known for decades. It took Satoshi Nakamoto finding a breakthrough to make it work. The hard part is finding clever ways to use well known principles without taking compromising shortcuts. Compromises like POS are an example. (Note: I am not against POS, but it should be 100% transparent with full identities known and never anonymous or private.) Kludges are okay until elegant solutions are found as long as there is solid backup and redundancy. Breakthroughs are great, but incremental innovations are what wins the day. So SPV as micropayments is an innovation, but making it into a full blown payment system will require building the tools to kludge it together. I am certain an elegant solution can be found because it will challenge our best and brightest.

Lightning Network Expected 3rd Q 2016


https://www.coingecko.com/buzz/eric-lombrozo-7-use-cases-lightning-network

Older links --

https://bitcoincore.org/en/segwit_adoption/
https://bitcoincore.org/en/2016/01/26/segwit-benefits/

What happens in the opposite case: if an attacker tries to fill the channels with unsettled / open transactions, by breaking, say, 100 bitcoins into billions of transactions of few satoshis and letting them intentionally unsettled, so to speak, for the lolz...

I'm thinking whether the LN network can be bloated to such an extent that it becomes unusable, if the proper fee or dust disincentives aren't placed there (?). In general there are very few scenarios where very low cost use can't lead to very low cost abuse.

https://www.youtube.com/watch?v=-lgYYz3y_hY


Lightning Network as a Directed Graph: Single-Funded Channel Network Topology