Topic: Lightning network (Read 672 times)

OK, there could be more than one recipient in a single payment but since everyone can use the same secret I think a hash time locked contract will be sufficient


Since you're the senior I'll take your words for it but it doesn't change anything to the new concept.


A withdrawal closes the payment channel in the actual system. To avoid this from happening in the new system the user who makes the withdrawal will have to create a second transaction output sending the remaining balance back to the other users (basically returning the funds to the same wallet). The logical in the actual system and the logicial in the new system are COMPLETELY different, if you read the overview carefully from top to bottom you can understand the new logical quite easily (just don't make any presumption based on the current model otherwise you'll get lost). I've revised the new model several hours to make sure there is no major flaw but I guess writting a draft is a bigger challenge...

Actually I was heading more towards a way to implement pay-to-many transactions using LN.


Correct me if I'm wrong but doesn't the current revision of Lightning Network only create locktime transactions when the channel is funded? I don't think they're done when lightning payments are created. But I'd understand if they were made every time a new payment is created so that it can be valid evidence in dispute processes like the one you just outlined. I think the reason why locktime transactions were introduced into LN in the first place was to establish some relation between the LN payment and mainnet (and again when the channel is closed, but I fail to see the reason why regular transactions without locktime can't be used for the channel close and spending).

I get your point but we shouldn't worry about that. If the concept is rock solid then it will gain acceptance through the btc community.
 

I think where you're heading with a Shamir's secret handshake is a system that is somewhat based on trust. We can make it entirely trustless but for that we must think outside of the box and completely remodel the payment channel.

DISPUTE RESOLUTION CLAUSE

When signing a lightning transaction the channel participants create a "bill" that allows the payee to spend the amount of the transaction. Those bills can be used to come to an agreement in the case of a dispute (it can take up to four steps to close a case). I will give you an example showing you how a case can be resolved. In this example there will be three channel participants with the pseudonyms Alice, Bob and Carol.

1.Alice makes a withdrawal.
2.Bob or Carol posts a penalty transaction to invalidate Alice’s withdrawal.
3.Alice sends the latest lightning payment that was signed to her to prove that she has enough funds for her withdrawal.
4.Bob or Carol posts a more recent payment signed by Alice to invalidate her proof.

As you can see in this example if everyone takes their precautions then there's no way around for a cheater to run away with some stolen coins and there's no way anyone can collude to take someone's funds in hostage. In order for this to work, the timelocks shouldn't be part of the lightning payments. A user who makes a withdrawal on his own would have to set a timelock that meets some condition (such as a certain block height) so that the miners would accept to include his transaction in their block. The same rule would apply for the penalty transactions. Keep in mind that the payment channel would have to be a 1-N OR N-N multisig wallet so the withdrawals would be written at the time they are posted (if no one cheats then no off chain record has to be sent to the network).


We don't have to rush it because we know that everyone will have to upgrade their software on the long run but I think we should make sure that we have a good overview of the concept itself before getting into the codes...

In order for changes to the standard to have the best chance of being merged we should avoid changing it too radically and this includes using smart contracts, which aren't covered at all in the original Lightning RFCs. I think that's going to meet opposition from standards drafters.

I can simplify my proposal by applying Shamir's secret sharing directly on the signed transaction without encrypting the transaction first. Because of the way Shamir's secret sharing works, is that in an A-B system with B shares and A required shares to reconstruct the secret, the secret (in this case the signed transaction) cannot be reconstructed without at least A shares. And in this case, because A=N and B=N+N-1, only if each of the A parties uses their one single share, or if the channel operator uses some or all of its N shares in the absence of some of the parties, can the signed transaction can be reconstructed.

It requires minimal modification to BOLT #2 and even then it doesn't require new or less messages to be sent. Only the contents of the messages changes. I have not studied the other standards well enough to assess if it makes breaking changes to any of them.

Ideally we want the new protocol to be backward-compatible with the old one because merchants like Coinpayments are already using LN as a payment network.

I gave a second thought to your proposal and I actually think that what we need is a new type of smart contract where the balance of one user increases if a specific transaction is confirmed on the mainnet. This would allow any user to make a safe deposit. We could also build a smart contract where someone has to commit some funds to earn the right to sign a payment but this would be optional.

It's getting more interesting... We might be on track to blow the actual system and not many people seem to realize it

My bad I misquoted myself (didn't use the copy paste!). The channel participants other than the main user sign their own balance when they send him a payment (so by decreasing their own balance they allow the main user to spend more coins which equals to a payment). The other participants don't own any share before the first payment from the main user and after that payment they can reallocate those funds without him (now you can make the link with the first post I've sent). Allowing all the channel participants to make deposits leads to a big problem (you don't want to make a deposit before everyone agrees that you own those funds but no one will agree that you own those funds before you make the deposit). A commitment transaction doesn't solve this problem because whoever signs first (the deposit or the commitment) expose themselves to a risk. The system I proposed simplifies things a lot but as a consequence only the main user is able to make deposits. As you said, he would be the only one to have something to lose from the moment the channel is created but I guess in the real world most people would have something to lose (like if I'm the customer and you're the merchant you'd probably want to keep me as a customer so you have an incentive to play fair..)

You know, these lightning network proposals are starting to become fascinating to me.


OK I think an idea just hit me. What if we defined a special data structure for LN payments which includes an unsigned transaction hex of the mainnet, and that signing the whole LN payment is required to redistribute funds but it does not make a valid signed transaction? And then to actually spend the allocated funds the transaction hex for the mainnet can be signed on it's own?

Keeping in mind that the channel operator is the only one who's risking loss of funds if they go offline or cheat, they will be inclined to behave because any misbehavior in the distribution process will affect their committed funds, we can have everyone have a copy of the N-N signed transaction, but:

- The signed transaction will be encrypted
- This encrypted signed transaction will be split into shares using Shamir's secret sharing algorithm, where there are N+(N-1) shares: The channel operator holds N shares so that they can unlock the funds if all other parties go offline, and all other N-1 parties get one share each. Ideally we want the transaction to be decrypted using one share from each party. But in the case that some of the clients go offline, the operator can use their shares to unlock everyone else's distribution.
- If the operator themselves goes offline, then no money is lost for the clients because they did not risk any money in this channel, only the operator will lose money so they will compelled to stay online.


Currently this can only happen when the channel operator closes the channel, users cannot get their funds before that happens. After that the operator doesn't need to stay online because the encrypted signed transaction will be decrypted with everyone's shares so that any of the parties can spend it (ideally the operator will spend it but this isn't required in my idea).

Forgot to mention that after the main user has released some funds the other users can spend those funds without his signature so he doesn't have to stay online.

The 1-N OR N-N model is necessary to prevent anyone from locking anyone else's funds. When the other parties have signed you a payment you have an irrefutable proof that you can spend those funds so you can unlock your funds with your own private key and defend yourself if another party disputes your transaction but you must get everyone to sign your withdrawal if you want your funds to be unlocked immediately.


Exactly, this is what I meant when I said "The creator of the wallet basically signs the total balance of the other users when he sends them a payment and the other users sign his total balance when they send him a payment..." So the main user reallocates the funds to all the other users by allowing them to spend some btcs in the wallet and the other users are able to send him back some funds by signing their own "newTotalBalance". The timestamps will allow the network to know the chronological order of the transactions in the case of a dispute. The conditions to verify for validating a payment would be slightly different than for a regular multisig wallet...



So I just gave an overview of the concept but now we can go into more details.. A cheater gets kicked out of the channel as soon as he is caught cheating. Therefore he won't be able to cancel any payment and even if he could then he would need a valid proof to reverse a transaction.


Actually, in this new type of payment channel, everyone agrees on everyone's balance on every single transaction so no one can steal someone else's coins. As mentionned above, the main user only signs the balance of the other users to redistribute his funds but he does not handle the disputes (the L1 network should be able to determine whether a transaction is legitimate or not if enough information was provided).
 
The whole concept works by these principles; if no one disputes a transaction then we will all assume it's legit, otherwise we will use the counterparties' proof to determine its validity.    

I almost forgot that this is supposed to be implemented using bitcoin resources we already have such as multisig. I don't really like the idea of using 1-N multisig because it makes it trivial for a cheater to transfer balance across LN since only they have to sign it, but to my understanding 1-N multisig is necessary for occasions where the other parties go offline.

This means that we can't just let the signature of a multisig transaction be spendable on layer 1 by itself, an intermediate form of signatures has to be devised.

What about a multisig scheme where every party needs to make a certain signature type to reallocate funds in a channel, and a second signature type which only has to be signed by one person to release their share of the funds. This has the side effect of  users who go offline after the channel creation won't get their money, but you have to play by the rules I guess.

I also think that these sections need to be refined some more:


Let's take the edge case scenario of both channel users trying to cheat each other in a 2-user channel. Removing both of their public keys from the channel will make the locked-in balance. In fact none of the things in this proposal address this edge case. I feel that lightning channels can only be honest if more than half of the users are also honest. Just like more than 50% of the mainnet hash rate must also be honest. This means 2-2 user channels, 2-3 user channels, 3-3 user channels and up where he first number is the number of honest users in a (second number)-user channel.

I think that relying on the channel operator to fairly handle penalties is risky because the operator might also want to rewrite the other parties' shares as less than what it's supposed to be.

The way I imagined it is actually much more simple than that and it would be very similar to a regular multisig wallet (it could be a 1-of-2, 1-of-3...) So let's say we have Alice and Bob on the same payment channel. A valid withdrawal could either have been signed by Alice OR Bob or it could have been signed by Alice AND Bob. If the transaction is only signed by one user then the user who did not sign it is allowed to dispute it. If it happens then the off chain records would serve as proof to validate or invalidate the transaction (for ex if Alice tries to spend 2btc from their wallet but she's signed that she only has 1btc then Bob can show this transaction to invalidate her withdrawal but if Alice makes a legitimate withdrawal and Bob tries to block it then Alice has Bob's signature as proof that her withdrawal is legit). If the withdrawal was signed by both parties then they've already agreed that it is valid so the funds will be available to the new owner as soon as the transaction is confirmed.


So basically, by including someone's public key in your wallet you would give them the permission to spend the coins from your wallet but you would be able to cancel their payments if they try to defraud you. Of course, the creator of the wallet would initially own the full balance of the channel (the funds would be redistributed after he signs the first payment). About what you said regarding the number of participants per channel I would think that in must cases 3 would be ok but we can let people decide what they want...

Btw thanks for replying and late happy new year!

The current system with two-user channels makes one of them send an "open" message and the other send an "acknowledge" message so for this idea, all of the other participants have to reply with "acknowledge" in order for the channel opening process to continue. Same thing with committing payments and signing them. If not all participants sign the payment then the channel will have to be terminated. This is alright for a small number of participants but not for large numbers like say >20. I think for that large number of participants, it's better they split into groups and communicate with each group using a handful of channels.


Like I said above, waiting for all participants to act is risky the more participants you add because some may not be reachable. This'll deadlock all of the other participant's withdrawals, and it leads me to believe that it's a good idea to penalize unreachable participants with larger fines proportional to the number of participants in the channel. Whether they get fined more than cheaters is up for debate but I honestly see more nodes going offline than attempting to cheat. On the other hand, fining unreachable participants more will discourage them from joining such multi-user channels and this'll be bad for LN in the long run.

Guys, I like talking to myself. I think I brought up a good point here because let's be honest as of now the ln is not appealing to the everyday people. You don't want to give the burden to someone to stay online all the time when that person only needs to make transactions once in a while. You don't want to ask the merchants to make a deposit just so they can receive payments from their customers, like come on?? Forget about the geek side a bit and let's talk about the buisness side... The actual design of the payment channel is bad (although the initial idea is good). If we don't make btc a good currency to use all over the world then it could go down as fast as it went up. So now let's talk!

NEW PAYMENT CHANNEL UPGRADE PROPOSAL

This new concept could bring major improvements to the lightning network. These are the proposed improvements.

• Any user could connect to several other users on the same payment channel then go offline without disrupting the channel.
• Users could make instant withdrawals with the cooperation of their peers.
• We would only need the public key of the people we want to connect with to start a channel with them.

                                       
Please, take a minute to read this. This is an overview of the concept (for now let's call it the multidirectional payment channel).

Creating a channel: One of the participants opens the channel by transferring any amount of coins to a new multi-signature wallet. For security reasons the creator of the wallet (or the main user) must preset a limit on the withdrawal fees (this restriction can be overruled with the signature of all the participants).

Deposits/withdrawals: Only the creator of the wallet can fund the channel but any participant can withdraw their coins. The withdrawals can be validated by one signature or by all the signatures (the funds will be temporarily frozen unless the transaction is signed by everyone).

Payments: To make a transaction the payer must sign a payment to the payee then have it signed by all the other participants (they will actually sign their new balance on the channel). The main user does not have to sign the payments of the other users (so he  can go offline and it will not affect anyone).

Security: All the channel participants must protect themselves against fraud by verifying the payments that are made from their wallet. Any user can invalidate a fraudulent transaction with a penalty transaction and prevent the cheater from withdrawing more funds. A transaction can no longer be invalidated after the funds are unfrozen.


DISPUTE RESOLUTION CLAUSE

When signing a lightning transaction the channel participants create a "bill" that allows the payee to spend the amount of the transaction. Those bills can be used to come to an agreement in the case of a dispute (it can take up to four steps to close a case). I will give you an example showing you how a case can be resolved. In this example there will be three channel participants with the pseudonyms Alice, Bob and Carol.

1.Alice makes a withdrawal.
2.Bob or Carol posts a penalty transaction to invalidate Alice’s withdrawal.
3.Alice sends the latest lightning payment that was signed to her to prove that she has enough funds for her withdrawal.
4.Bob or Carol posts a more recent payment signed by Alice to invalidate her proof.


There are a few important things to point out..

1.The creator of the wallet basically signs the total balance of the other users when he sends them a payment and the other users sign their own total balance when they send him a payment. The main user doesn’t need to know the balance of each participant as he can invalidate a withdrawal by simply proving that the user who is making it is spending his balance (on the opposite side the other participants can invalidate his withdrawals by proving that he’s trying to spend their balance). The payments from the main user require two transactions (one signed by his peers and one signed by himself).
2.The public key of any cheater will be removed from the channel (the coins on his channel will be transferred to a new wallet where his key is removed).
3.A withdrawal does not close the channel (the user who requested it must return the amount he owes to the other users).
4.A penalty transaction does not need to include any proof against the targeted user if he is not the main user (that is simply because there could be no proof if the targeted user did not sign any lightning payment).


I believe we could implement this system with a soft fork but for sure there are a lot of technical details to go through. You’re all invited to contribute to the development so we can all prosper!

Thanks,
Thomas