Bitcoin Forum
April 19, 2019, 01:32:51 PM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 »  All
  Print  
Author Topic: Lightning Network (another proposal to make bitcoin scale)  (Read 8164 times)
sickpig
Legendary
*
Offline Offline

Activity: 1260
Merit: 1007


View Profile
February 27, 2015, 01:15:32 PM
 #1

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

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


Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
1555680771
Hero Member
*
Offline Offline

Posts: 1555680771

View Profile Personal Message (Offline)

Ignore
1555680771
Reply with quote  #2

1555680771
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1555680771
Hero Member
*
Offline Offline

Posts: 1555680771

View Profile Personal Message (Offline)

Ignore
1555680771
Reply with quote  #2

1555680771
Report to moderator
1555680771
Hero Member
*
Offline Offline

Posts: 1555680771

View Profile Personal Message (Offline)

Ignore
1555680771
Reply with quote  #2

1555680771
Report to moderator
1555680771
Hero Member
*
Offline Offline

Posts: 1555680771

View Profile Personal Message (Offline)

Ignore
1555680771
Reply with quote  #2

1555680771
Report to moderator
sickpig
Legendary
*
Offline Offline

Activity: 1260
Merit: 1007


View Profile
March 01, 2015, 06:25:08 PM
 #2

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

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

Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
cjp
Full Member
***
Offline Offline

Activity: 210
Merit: 100



View Profile WWW
March 03, 2015, 07:15:48 PM
 #3

Looks suspiciously similar to my 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.

Donate to: 1KNgGhVJx4yKupWicMenyg6SLoS68nA6S8
http://cornwarecjp.github.io/amiko-pay/
inBitweTrust
Hero Member
*****
Offline Offline

Activity: 658
Merit: 500



View Profile
March 05, 2015, 05:37:45 PM
 #4

Interesting Proposal-

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

David Rabahy
Hero Member
*****
Offline Offline

Activity: 709
Merit: 500



View Profile
March 05, 2015, 09:14:27 PM
 #5

The average transaction size is more like 400 bytes at best.
monkeybars
Sr. Member
****
Offline Offline

Activity: 274
Merit: 250



View Profile
March 22, 2015, 09:44:09 PM
 #6

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.
inBitweTrust
Hero Member
*****
Offline Offline

Activity: 658
Merit: 500



View Profile
March 26, 2015, 08:27:06 PM
 #7

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 Smiley

marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2870
Merit: 1129



View Profile
March 27, 2015, 09:06:58 AM
 #8

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 Smiley

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

instagibbs
Member
**
Offline Offline

Activity: 114
Merit: 10


View Profile
March 27, 2015, 01:09:31 PM
 #9

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 Smiley

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

Merge-mined sidechains require a fork too!  Cheesy

I guess a federated sidechain could do it.
criptix
Legendary
*
Offline Offline

Activity: 1862
Merit: 1067


View Profile
March 27, 2015, 10:46:18 PM
 #10

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 Smiley

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

Merge-mined sidechains require a fork too!  Cheesy

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
inBitweTrust
Hero Member
*****
Offline Offline

Activity: 658
Merit: 500



View Profile
March 27, 2015, 10:56:26 PM
 #11

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.

marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2870
Merit: 1129



View Profile
March 28, 2015, 10:49:49 AM
 #12

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 Smiley

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

Merge-mined sidechains require a fork too!  Cheesy

I guess a federated sidechain could do it.

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.

Mellnik
Sr. Member
****
Offline Offline

Activity: 243
Merit: 250


View Profile
March 29, 2015, 07:29:11 PM
 #13

Anyone already working on an implementation?
inBitweTrust
Hero Member
*****
Offline Offline

Activity: 658
Merit: 500



View Profile
April 02, 2015, 12:21:51 PM
 #14

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

sickpig
Legendary
*
Offline Offline

Activity: 1260
Merit: 1007


View Profile
April 06, 2015, 08:42:26 PM
 #15

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

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

Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
sickpig
Legendary
*
Offline Offline

Activity: 1260
Merit: 1007


View Profile
April 08, 2015, 10:10:23 AM
 #16

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

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

Quoting the first paragraph:

Quote from: Rusty Russell of linux kernel fame
The key revelation of the paper is that we can have a network of arbitrarily complicated transactions, such that they aren’t on the blockchain
(and thus are fast, cheap and extremely scalable), but at every point are ready to be dropped onto the blockchain for resolution if there’s a
problem. This is genuinely revolutionary.

emph is mine.

This is a must read series IMHO.


Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
sickpig
Legendary
*
Offline Offline

Activity: 1260
Merit: 1007


View Profile
April 08, 2015, 03:27:29 PM
 #17

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.


Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
Mashuri
Full Member
***
Offline Offline

Activity: 135
Merit: 100


View Profile
April 15, 2015, 07:47:06 PM
 #18

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

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

Quoting the first paragraph:

Quote from: Rusty Russell of linux kernel fame
The key revelation of the paper is that we can have a network of arbitrarily complicated transactions, such that they aren’t on the blockchain
(and thus are fast, cheap and extremely scalable), but at every point are ready to be dropped onto the blockchain for resolution if there’s a
problem. This is genuinely revolutionary.

emph is mine.

This is a must read series IMHO.



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?

TierNolan
Legendary
*
Offline Offline

Activity: 1232
Merit: 1002


View Profile
April 28, 2015, 10:59:10 AM
 #19

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

Code:
<uint16 reserved_bytes> OP_RESERVE OP_DROP  <normal scriptPubKey>

and the P2SH version

Code:
<uint16 reserved_bytes> OP_RESERVE OP_DROP  OP_HASH160 [script hash] OP_EQUAL

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)

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
inBitweTrust
Hero Member
*****
Offline Offline

Activity: 658
Merit: 500



View Profile
May 05, 2015, 07:08:13 PM
 #20

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

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

Pages: [1] 2 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!