Topic: Lightning Network (another proposal to make bitcoin scale) (Read 8332 times)

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


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

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.

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/

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.

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

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

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  

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

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

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)

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

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



Does this look right?

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.

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.

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

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

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

Anyone already working on an implementation?

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.

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.

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

Merge-mined sidechains require a fork too! 

I guess a federated sidechain could do it.

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