Pages:
Author

Topic: Basics of the Lightning Network - page 3. (Read 2321 times)

legendary
Activity: 2898
Merit: 1823
August 24, 2018, 02:22:33 AM
#9
If miners start censoring transactions, [...]

Well, it actually depends on how you define censoring.

Miner do choose transactions based on some properties. And the most important one is the fee rate (sat/B) payed.

Since all miner have to agree, there needs to be an incentive for all of them. And all miner do definitely benefit from higher fees.
So most do choose the top X transactions from their list (ordered by fee rate) from transactions from the mempool.

They might not censor transactions from/to specific addresses since an incentive for all miner is missing here, but as far as all of them can profit, they probably always 'favor' transactions based on some properties.


What I am trying to say is real censorship by miner collusion or miner centralization. If that becomes real in the network then it will become nothing but an inefficient and expensive FED 2.0.

But a community-backed UAHF will happen before FED 2.0 happens in my opinion. The miners should be careful.
legendary
Activity: 1876
Merit: 3132
August 23, 2018, 02:41:30 PM
#8
I'm currently installing Neutrino+LND to test the "light client" scenario which would make LN available "for the masses", but I ran into some problems. But I won't spam this thread with them - I'll look if I can solve them myself (I'm a total Go noob, so maybe a bit of RTFM is enough Wink ). Perhaps we can start another thread of this "Lightning series": "Lightning Network Experiences"?

That might be a good idea. Feel free to PM me if you need some help.

~snip

Thanks for your suggestions. I haven't mentioned Schnorr signatures because they are not strictly connected with the Lightning Network. Updated.

I wonder, if during this LN implementation, it would be too difficult to add a second second layer (or 2 parallel layers) to also allow for escrow, or perhaps within LN itself? Or using LN as an escrow method?

There won't be any problems with having more than one second layer, especially if they have different features. It is possible to build more layers on top of the Lightning Network. Some think that ordinary people will use them instead of on-chain transactions.

I am going to write a long guide on the Lightning Network wallets once they stop changing so much. Developers are constantly updating their implementations.
legendary
Activity: 1904
Merit: 1074
August 23, 2018, 10:43:31 AM
#7
If miners start censoring transactions, [...]

Well, it actually depends on how you define censoring.

Miner do choose transactions based on some properties. And the most important one is the fee rate (sat/B) payed.

Since all miner have to agree, there needs to be an incentive for all of them. And all miner do definitely benefit from higher fees.
So most do choose the top X transactions from their list (ordered by fee rate) from transactions from the mempool.

They might not censor transactions from/to specific addresses since an incentive for all miner is missing here, but as far as all of them can profit, they probably always 'favor' transactions based on some properties.


But at some point of time the tx will be mined by someone not in the group of miners that wants to censor these tx's right?

These tx's might just take a little bit longer, because they have less miners fees, but they will be picked up by some desperate

miner.  Roll Eyes  Some people might even target these "scraps" because it is being discarded by the big boys? 
legendary
Activity: 1624
Merit: 2481
August 23, 2018, 04:31:11 AM
#6
If miners start censoring transactions, [...]

Well, it actually depends on how you define censoring.

Miner do choose transactions based on some properties. And the most important one is the fee rate (sat/B) payed.

Since all miner have to agree, there needs to be an incentive for all of them. And all miner do definitely benefit from higher fees.
So most do choose the top X transactions from their list (ordered by fee rate) from transactions from the mempool.

They might not censor transactions from/to specific addresses since an incentive for all miner is missing here, but as far as all of them can profit, they probably always 'favor' transactions based on some properties.
legendary
Activity: 2898
Merit: 1823
August 23, 2018, 04:08:52 AM
#5
Quote
Colluding miner attacks - miners have power to decide which transactions they want to include in the block so they can refuse certain transactions selected by an attacker. This attack is very unlikely to happen due to high cost and complexity (all miners would have to cooperate).

If miners start censoring transactions, then it would be the only time that I will sell all of my Bitcoins. But, it would also be the best time to start calling for a UAHF type POW change.
legendary
Activity: 2968
Merit: 3684
Join the world-leading crypto sportsbook NOW!
August 23, 2018, 03:11:43 AM
#4
Thanks for this well laid out piece, I'm really going to dig in at some point soon! My burning question is actually about that "Other" second layer you mention: Rootstock. So I apologise if this is completely unrelated, though since I saw you linking to Rootstock...

My first encounter with it was in 2016 I believe, when looking at Bitcoin smart contracts. The interest then, (and still now) was in smart contract use for e-scrow. This is also the use case described by some old articles on Google, but then I can't seem to find a link to an actual code that shows a working example for such a trustless escrow, a service still very much in demand.

I wonder, if during this LN implementation, it would be too difficult to add a second second layer (or 2 parallel layers) to also allow for escrow, or perhaps within LN itself? Or using LN as an escrow method?
legendary
Activity: 3906
Merit: 6249
Decentralization Maximalist
August 22, 2018, 08:16:50 PM
#3
Thank you for that great post!

It confirmed a doubt I had for a long time but nobody was able to "refute" it: the "forced expiration spam" problem. That weakness has an important consequence: We should never let Lightning "hubs" become too big, otherwise they would become a systemic risk, as they could spam the blockchain for a long time if they're malicious.

I'm currently installing Neutrino+LND to test the "light client" scenario which would make LN available "for the masses", but I ran into some problems. But I won't spam this thread with them - I'll look if I can solve them myself (I'm a total Go noob, so maybe a bit of RTFM is enough Wink ). Perhaps we can start another thread of this "Lightning series": "Lightning Network Experiences"?
legendary
Activity: 1722
Merit: 1217
August 22, 2018, 03:42:59 PM
#2
This post is a quick proof reading and critique as per the request of OP.


Quote
It has no impact on the Bitcoin network.
Technically I mean if it reduces the total number of on chain transactions this is an impact on the bitcoin network. I understand what you mean but perhaps this sentence could be more clear. Something like "once a lightning channel has been established transactions within said channel do not impact the bitcoin blockchain". Or something like that. Not trying to write it for you, just explaining what I mean.


Quote
To start using the Lightning Network you have to use a compatible software.


Quote
To start using the Lightning Network you have to use a compatible software. Two people establish a payment channel by locking up funds in a multi-signature address which needs both signatures to spend from it. Payment channel can be used as long as both participants agree to cooperate. One can close the channel even if the other participant is offline but it won't happen instantly in that case.
I would change wording and the order a bit here.

To start using the Lightning Network you have to use a compatible software. Two people may establish a payment channel by locking up funds in a multi-signature address which needs both signatures to spend from it. This transaction is time locked so that the funds will be automatically dispersed in the event that one of the parties becomes uncooperative. Payment channel can be used as long as both participants agree to cooperate remain cooperative. One can close the channel even if the other participant is offline but it won't happen instantly in that case.


Great post. Thanks for being a continued asset to the community. +merit
legendary
Activity: 1876
Merit: 3132
August 22, 2018, 02:43:13 PM
#1
Table of contents

      1. What is the Lightning Network?
      2. How do I use it?
             a) Creating a payment channel
             b) Sending and routing payments
             c) Closing a channel
      3. Wallets and nodes
      4. Planned features
      5. Security risks
      6. Useful sources of information

1. What is the Lightning Network?

The Lightning Network is an alternative to the traditional Bitcoin on-chain transactions. It doesn’t replace them completely because on-chain transactions are still needed for closing and opening payment channels. The Lightning Network is a second layer solution and is fully opt-in. Transactions done between Lightning Network participants have no negative impact on the Bitcoin network. The Lightning Network allows for instant and extremely cheap P2P (micro)payments.

The Lightning Network consists of nodes which maintain payment channels with some of the participants of the network.

2. How do I use it?

To start using the Lightning Network, you have to use a compatible software (see Wallets and nodes section). Every wallet has a different setup process and features so you should look up a guide for the one you choose on your own.

a) Creating a payment channel

What is exactly a payment channel?

Payment Channel is class of techniques designed to allow users to make multiple Bitcoin transactions without commiting all of the transactions to the Bitcoin block chain. In a typical payment channel, only two transactions are added to the block chain but an unlimited or nearly unlimted number of payments can be made between the participants.

Two people establish a payment channel by locking up funds in a multi-signature address which needs both signatures to spend from it. Payment channels can be used as long as both participants remain cooperative. The maximum size of a channel is about 0.16 BTC. All major implementations now allow node operators to lift this limitation manually.

b) Sending and routing payments

Both parties transact without broadcasting the current state of their trade to the blockchain. They both keep the copy of the channel information. Each time a channel is updated, both parties sign a commitment transaction which keeps a record of the current state of the channel. This transaction can be published to perform an uncooperative channel close.

Sending payments over the Lightning Network is possible as long as there is at least one path from you to the other person through other nodes which have open channels between themselves. All nodes in the path must have enough liquidity. Each node is rewarded for routing the payment accordingly to their fee policy. Large payments can be split and routed via different routes thanks to MPPs (multipart payments); while all implementations support them, most wallets don't.

Ensuring that there is enough liquidity is the most difficult thing for most beginners. When you open a channel to someone, you gain outbound capacity. You won't be able to receive any coins through that channel unless you spend the channel reserve (1-3% of the channel's capacity). The more coins you spend, the more you will be able to receive. If someone opens a channel to you then you will gain incoming capacity and be able only to receive through that channel unless you receive more coins than the value of the channel reserve.

Secure payment routing would not be possible without Hashed Timelock Contracts (HTLCs). The example below explains why they are needed.

1. Alice opens a payment channel to Bob, and Bob opens a payment channel to Charlie.
2. Alice wants to buy something from Charlie for 1000 satoshis.
3. Charlie generates a random number and generates its SHA256 hash. Charlie gives that hash to Alice.
4. Alice uses her payment channel to Bob to pay him 1,000 satoshis, but she adds the hash Charlie gave her to the payment along with an extra condition: in order for Bob to claim the payment, he has to provide the data which was used to produce that hash.
5. Bob uses his payment channel to Charlie to pay Charlie 1,000 satoshis, and Bob adds a copy of the same condition that Alice put on the payment she gave Bob.
6. Charlie has the original data that was used to produce the hash (called a pre-image), so Charlie can use it to finalize his payment and fully receive the payment from Bob. By doing so, Charlie necessarily makes the pre-image available to Bob.
7. Bob uses the pre-image to finalize his payment from Alice

Mobile clients establish private channels which do not take part in the payment routing.

c) Closing a channel

Payment channels can be closed either cooperatively or uncooperatively (forcefully).

Uncooperative channel close can be initiated at any time. Although, it doesn't make much sense to do it if the other node is online and fully cooperative. By default, one has to wait 144 blocks (~24 hours) before one will be able to spend the closing transaction. This value is decided during initial channel negotiations. Note that this value can be significantly higher in some cases. For example, Eclair Mobile sets the delay to 2048 blocks (~2 weeks) if one enables receiving over the LN. The delay gives the other party time to come back online and check if the latest commitment transaction was published. If the other party broadcasts an old commitment transaction then one can revoke it and broadcast a penalty transaction within the delay.

Cooperative channel close can be initiated only when the other party is responsive. The closing transaction can be spent immediately if both parties agree on the current state of the channel.

3. Wallets and nodes

There are only few Lightning Network implementations and each of them might contain some bugs which may lead to the loss of funds. Keep in mind that the Lightning Network is still in beta. iOS and Android wallets are easy to use and don’t require much setup as opposed to LND, Eclair and c-lightning which are used to run stand-alone nodes.

Implementations


Desktop clients


Android clients


iOS clients


4. Planned features

  • Dual-funded channels - two users instead of one will be able to fund a payment channel as originally described in the Lightning Network Paper.
  • Eltoo - eltoo will be an alternative to the current method of settling payments between users. Channel updates are done by building a chain of timelocked transactions. A soft fork is needed to make eltoo available on the Lightning Network (in order to avoid having to broadcast the whole transaction history between users). Here you can find out which opcodes need to be modified.
  • Channel factories - existing Lightning Network channels could be used for creating new channels without broadcasting anything to the rest of the Bitcoin network. Normally, a channel is opened to only one person. In channel factories we have multiple people forming a group. Group members maintain channels between themselves. More interested users = higher savings. If one of the participants is uncooperative, existing channels are not affected - new channels can't be created, though.
  • Splicing In/Out - currently, it is not possible to add or remove funds from channels without reopening them.

There are a few things which can be changed in the Bitcoin code in order to improve privacy. Introducing Schnorr, MAST and Taproot would make transactions opening/closing channel indistinguishable from any other ordinal transaction.

5. Security risks

  • Improper timelocks - sufficient time should be given in case of interaction with non-cooperative or malicious channel counterparties.
  • Forced expiration spam - closing many channels at the same time might lead to filling up the whole block completely. If the spam lasts enough time, some timelocked transactions might become valid.
  • Data loss - most of the Lightning Network clients don’t provide reliable method of backup. Using an old copy of the database might be considered as cheating. The other party broadcasts a penalty transaction in such a case. Data Loss Protection is available in all implementations.
  • Coin theft - most of the Lightning Network nodes work 24/7 and store their coins in hot wallets which makes it easier for an attacker to steal them.
  • Colluding miner attacks - miners have power to decide which transactions they want to include in the block so they can refuse certain transactions selected by an attacker. This attack is very unlikely to happen due to high cost and complexity (all miners would have to cooperate).

6. Useful sources of information

bitcointalk: The Lightning Network FAQ, Electrum Lightning Network walkthrough, Lightning Network Discussion Thread

Lightning Network explorers: 1ml.com, lightblock.me

News: Telegram channel, bitcoinlightning.com, coindesk, Cointelegraph
Pages:
Jump to: