[LN] What is revocation key? How does revocation works on bitcoin blockchain?

[Destrodream]

Hello! I'm trying to improve my understanding of LN but just realized I'm lacking some basic understanding of the revocation process on blockchain, and how revokation keys work.

 



 

The meaning of word revocation means that I can somehow cancel the tx, however given the nature of blockchain transaction I struggle to understand how this is possible. Could someone please explain meaning of revocation in this context?

[DooMAD]

Hello! I'm trying to improve my understanding of LN but just realized I'm lacking some basic understanding of the revocation process on blockchain, and how revokation keys work.

The meaning of word revocation means that I can somehow cancel the tx, however given the nature of blockchain transaction I struggle to understand how this is possible. Could someone please explain meaning of revocation in this context?

I'm still wrapping my head round it all, but my understanding is that revocation is part of the anti-cheat process.  Its purpose is not to cancel a transaction if you change your mind, but to ensure people aren't trying to spend from previous transactions.  You effectively only revoke permission to spend from anything but the most recent balance, because if someone tries to spend from an old transaction, it allows the other participant to spend the entire balance.  There's a decidedly technical explanation here.

[Colorblind]

I am as well interested if unilateral closure of channel (when revocation actually takes place) cause some other channels closure as collateral. In my vision this indeed should happen, since IOU's you fall-through sort of piles up, and if someone posts channel old state they all should be settled to avoid losses for any of the participants. So in theory I can open channel and hold it open for some time, then intentionally close it to damage other. If I wait long enough, the damage I will be able to do will be more then my loss, but I will still be unable to profit from this (which is good thing obviously since unilateral closure isn't incentivised in any way).


But that's all my speculations on the subject since I'm just learning how it works and I may not be correct.

[Colorblind]

Here is great explanation about some of the questions regarding LN security questions https://youtu.be/V3f4yYVCxpk?t=70

[achow101]

The meaning of word revocation means that I can somehow cancel the tx, however given the nature of blockchain transaction I struggle to understand how this is possible. Could someone please explain meaning of revocation in this context?

When a new commitment transaction is made, the old one should become invalid. However commitment transactions are not broadcast to the network, rather they are kept private and only broadcast when you want the channel to close. But because all commitment transactions are technically valid, we need some way to prevent people from broadcasting old commitments as they would effectively allow them to steal money. That's where the revocation key comes in.

During the process to create a new commitment, the revocation key for the commitment being invalidated is revealed to the other party. In this way, if you were to broadcast the old commitment, the other party would have the revocation key and can thus broadcast a punishment transaction where they use the revocation key to take all of the funds in the channel.

The revocation key itself is basically the combination of two keys. What effectively happens is that both parties provide a public key at commitment transaction creation time, and those public keys are combined to create the revocation public key. Then when the commitment is replaced with a new one, the party who is having their commitment revoked (remember that each party has their own personalized commitment transaction and the revocation keys are "personalized" for each commitment) reveals their revocation secret to the other party. This secret is combined with the other party's own revocation secret to create the full revocation key. In this way, the party who would have his commitment revoked with that key does not have access to the full revocation key.

[franky1]

The meaning of word revocation means that I can somehow cancel the tx, however given the nature of blockchain transaction I struggle to understand how this is possible. Could someone please explain meaning of revocation in this context?

When a new commitment transaction is made, the old one should become invalid. However commitment transactions are not broadcast to the network, rather they are kept private and only broadcast when you want the channel to close. But because all commitment transactions are technically valid, we need some way to prevent people from broadcasting old commitments as they would effectively allow them to steal money. That's where the revocation key comes in.

and here achow describes bank2.0 chargeback scheme

imagine [a:10-b:10] where the channel counterparties each funding 10btc
they make their first commitment to agree on who shares what of the 20btc available in the multisig(channel)
in human language its like
tx 1
[input A:10
         B:10
output A:10, spendable if tx2 not confirmed in 3days
           B:10, spendable if tx2 not confirmed in 3days
]

now A wants to buy something from B for 10. so the new commitment is made.
tx 2 [a:0-b:20]
but each party has a sight variation A in human language its like
tx 2
[input A:10
         B:10
output A:0, spendable if tx3 not confirmed in 3days
           B:20, spendable if tx3 not confirmed in 3days
]

B in human language its like
tx 2
[input A:10
         B:10
output A:0, spendable if tx3 not confirmed in 3days
           B:20, spendable if tx3 not confirmed in 3days
]

-note: they both have variations(but not shown varient) because the 'spendable if' can have extra outputs if TX2A is transmitted or TX2B is transmitted but that would take longer to explain

this way it become self destructive for a counter party to send a previous TX
but imagine if B was to not to deliver the goods and refuses to make a 3rd tx to refund A his 10btc
A is then going to be forced to send out tx1 to HOPE to get his 10btc back, because tx2 wont give him his 10btc back.

A transmits tx1, HOPING B stays offline/doesnt notice for 3 days
B can then transmit his tx2 to overrule A's tx 1 and then B not only gets to keep the goods, but also gets 20btc by blackmailing A into forcibly making A transmit tx1 to then allow B to use his tx2 CSV exception

(i think achow hates it when i highlight the pitfalls but LN is not the utopia people promote.. there are pitfuls)

---

[DannyHamilton]

- snip -

None of what you wrote is an accurate description of how Lightning Network works.

Furthermore, A would have to be pretty STUPID to think that he can chargeback by broadcasting tx1.  It should be obvious to A that broadcasting tx1 will not help him at all.  He has already sent the 10BTC to B and he has no way of getting that value back unless B is STUPID.

If you are engaging in a transaction with someone that you do not have a trust relationship with, you need to take actions (BEFORE YOU SEND THE TRANSACTION) to protect yourself.  As an example, perhaps use an escrow provider?

[franky1]

- snip -

None of what you wrote is an accurate description of how Lightning Network works.

Furthermore, A would have to be pretty STUPID to think that he can chargeback by broadcasting tx1.  It should be obvious to A that broadcasting tx1 will not help him at all.  He has already sent the 10BTC to B and he has no way of getting that value back unless B is STUPID.

If you are engaging in a transaction with someone that you do not have a trust relationship with, you need to take actions (BEFORE YOU SEND THE TRANSACTION) to protect yourself.  As an example, perhaps use an escrow provider?

ofcourse its not 'accurate' as i done it in ELI-5 human understanding. if i wrote it at code level i might aswell tell people to just read github

A's hope would be that B would be offline for the timelock period and hope he can spend the 10btc before B realises that B should send tx2
because if A does not act.. B could still transmit tx2 anyway and all is lost. so A might aswell send out tx1 and hope B dosnt notice. (no guarantee it will work but its his only chance)
.. but this proves that LN is not 'trustless' because humans are greedy.

also its pretty stupid to think my post was about A charging back.. my example was where A tried to withdraw funds due to B not honouring a service, however B done a chargeback on A's withdrawal
much like a paypal CUSTOMER doing a withdrawal. but then paypal doing a chargeback against the customer

B is the charge backer... not A.. just B had to make A try to withdraw so that B could trigger the chargeback

[dinofelis]

A's hope would be that B would be offline for the timelock period and hope he can spend the 10btc before B realises that B should send tx2
because if A does not act.. B could still transmit tx2 anyway and all is lost. so A might aswell send out tx1 and hope B dosnt notice. (no guarantee it will work but its his only chance)

You pinpoint an issue with the LN, of which people, of course, have to be aware: as long as you have an open channel on the LN, you have to remain on-line.  And this for two reasons:

1) if you're offline, you make life difficult for your channel partner, because at any moment, he might want to transact through the channel you both have, eventually to transmit it further over the LN network.  If you are off-line, you've frozen his channel coins (and yours as well, but that's of course evident).  That's not very nice to your partner, who has now no access to his coins, whatever he does, for at least the lock-out time.  So your partner, seeing that you are offline and wanting to do a payment with the coins he has locked up in his channel, has now the dilemma: should he wait for you to come on-line again (maybe you've just rebooted your machine, maybe you have a network issue, or maybe you're on a world trip, maybe you just dropped dead ?) ; or should he settle one-sided, but then he's sure he cannot access his coins for the lock out time ?  So, being offline when you have an open LN channel is not nice to your partner.  As you have a stake in that channel, he might become less nice too.

2) if you're offline, you cannot continuously check whether your partner didn't send a previous settlement: you have to be online all the time in order to be able to send a punishment transaction.

There's an exception to this: if your channel is completely exhausted in the direction of your partner, you would like to settle, but you're not in a hurry, and you want to test your partner's nerves so that he takes the fee on him.  He has now a big stash in the channel, you, zero.  If you're not interested in keeping that channel or remaining online for that, just go offline.  He will have to settle and pay the fee.  It doesn't matter what he does, you don't risk anything any more (apart from a slightly less nice relationship with that partner).  Note that this is only if you want to stop that channel: you could keep it open to allow your partner to pay through you again.

If you remain online, and if the block chain is not saturated, however, the LN is quite safe to use. 

It is a different story when the block chain is saturated, and broadcast transactions do not necessarily get in the chain quickly.  That's a dangerous situation because you have no guarantee that you will be able to get your punishment transaction in on time if you see that your partner got a previous settlement transaction in.  It is my critique of the LN on a limited-block size block chain: the potential danger of not being able to transact on time.  Most probably, unless there's a kind of "bank run" on the block chain, with high enough fee you can always do this - but as the LN was meant for micro-transactions, needing to pay a very high fee to punish your scamming partner is maybe strange.  The real danger is however, a "bank run" on the block chain.  Suppose that the LN has an immense success, and that there are BIG LN hubs, that have many, many channels open.  Let us assume that the lock out time is one day.  At a certain point in time, it may become very attractive for a big hub to:
1) settle with scammy previous transactions massively (preferentially near-exhausted channels towards the customer)
2) spam the block chain with relatively-high-fee transactions during a day

This will avoid the punishment transactions mostly to get in, and the LN hub runs with most of the full channel contents.  The price to pay is the spam campaign and the losses due to those punishment transactions that got in (that's why it is best to only do this with near-exhausted channels, where most of the risk is on the side of the customer).

[Wind_FURY]

If you remain online, and if the block chain is not saturated, however, the LN is quite safe to use.  

Would it be more viable then for the Lightning Network to be more like a web service than something you use as a desktop application?

I can already imagine desktop wallet providers like Electrum setting it up if they wanted to or maybe also Blockchain.info or Greenaddress.it.

[dinofelis]

If you remain online, and if the block chain is not saturated, however, the LN is quite safe to use.  

Would it be more viable then for the Lightning Network to be more like a web service than something you use as a desktop application?

Only if you give your keys also to that web service.  In other words, your bank.  You have to stay online to be able to sign at any moment with your own keys.  If you want another service to do so while you are offline, you have to give them your keys.  But then, they have your coins.  Like an exchange, or a bank.

In fact, the only safe way is to have the server hardware in your own place (say, an old PC running in your basement).  Even using a VPS service on which you run your own LN wallet is not safe, because of course the administrator can access the keys of the wallet if it has to run.  You cannot keep them encrypted, because the wallet software needs to access them all the time.  So the only safe way to run an LN wallet, is to run it on a clean machine over which you have physical control.  In exactly the same way as you do bitcoin transactions right now.

[Wind_FURY]

If you remain online, and if the block chain is not saturated, however, the LN is quite safe to use.  

Would it be more viable then for the Lightning Network to be more like a web service than something you use as a desktop application?

Only if you give your keys also to that web service.  In other words, your bank.  You have to stay online to be able to sign at any moment with your own keys.  If you want another service to do so while you are offline, you have to give them your keys.  But then, they have your coins.  Like an exchange, or a bank.

Yes a service exactly like that where you can zap your coins from one service to another through the Lightning Network. But reading that does not make me more optimistic about LN's decentralization. Maybe Joalnd Fyookball was partly right about centralized hubs in LN.

I believe it's an issue to think about going forward.

In fact, the only safe way is to have the server hardware in your own place (say, an old PC running in your basement).  Even using a VPS service on which you run your own LN wallet is not safe, because of course the administrator can access the keys of the wallet if it has to run.  You cannot keep them encrypted, because the wallet software needs to access them all the time.  So the only safe way to run an LN wallet, is to run it on a clean machine over which you have physical control.  In exactly the same way as you do bitcoin transactions right now.

I am trying to find out what is your stance in the "scaling debate", though I am too lazy to read all your past posts. But are you for bigger blocks? If yes, then what is your opinion on Bitcoin Cash? Is it good enough or can it be better?

[DannyHamilton]

- snip -
If you remain online, and if the block chain is not saturated, however, the LN is quite safe to use.  
- snip -

I'm still getting up to speed on the technical details of exactly how LN works, but I thought...

1. Others will only be able to use your node as a route if your node is online.

2. It would be possible for your node to provide to a service ONLY your revocation keys for your open channels, and not ANY of your other private keys.  As such, that service would not be able to process any LN transactions on your behalf nor be able to spend any of your bitcoins.  However, if a counterparty to any of your channels were to broadcast a stale state, that service WOULD be able to use your revocation key to sign and publish a punishment transaction.  You'd have to trust that the service would not take the punishment bitcoins for themselves, but the very threat of the possibility that the service could do this should prevent the counterparty from ever publishing a stale state in the first place.

Am I mistaken about #2?

[dinofelis]

I am trying to find out what is your stance in the "scaling debate", though I am too lazy to read all your past posts. But are you for bigger blocks? If yes, then what is your opinion on Bitcoin Cash? Is it good enough or can it be better?

I could give you a simplistic answer, but it wouldn't be the right answer.  The simplistic answer is: yes, of course bigger blocks.  However, I think that a single question, like, "are you for bigger blocks" misses entirely the point, simply because everything influences everything.  That's like asking a doctor "are you for or against chemotherapy".

I think bitcoin has fundamental design issues on the deepest conceptual level, that far overshadow the simple question of "bigger blocks".  I think bitcoin is fundamentally broken on the following points:

- the PoW consensus mechanism that is too wasteful and leads to centralization of power, even though it is a very good consensus (no dispute) mechanism, it doesn't provide the other desired factors, on the contrary.

- the fact that the consensus mechanism is remunerated (which, in itself, is necessary for PoW), which gives rise to a lot of game-theoretical issues and is the motor of centralization, by "economies of scale".

- bitcoin's coin emission curve, which links erroneous monetary theory, market speculation, crazy power consumption and security in one big clusterfuck

- bitcoin's lack of anonymity and hence lack of fungibility

In the face of these issues, the block size question is in fact of minor importance: when the overall structure is ill designed, you don't care about smaller design failures.

But if you tell me: "we want to keep all that, and for some or other reason, we think it is the right system", then it is obvious that block size is really not an issue, because, as I pointed out elsewhere, bitcoin is a client/multi-server system, not a P2P system (which itself, is a consequence of PoW and the remuneration of it).

Here's that post: https://bitcointalk.org/index.php?topic=2852931.msg29426613#msg29426613

That doesn't mean that I think that things like the LN are necessarily a bad idea: there can be useful applications of this.   For instance, high frequency trading is a perfect application of it. But not to solve the non-existing scaling problem.  There is no scaling problem in bitcoin's model, and Satoshi even explained that already in November 2008.  You simply have to accept that bitcoin is not a P2P system, but a client/multi-server system.  That is the natural consequence of the design principles of bitcoin, and that is also what is de-facto observed today.  In a client/multi server system, there's no scaling problem, and blocks can be of huge size, because they only need to be kept on servers that have in any case way higher expenses than the data volume it represents.  I repeat that the non-P2P nature of bitcoin is not something that has to do with block size, but is the natural consequence of the PoW design and remuneration of bitcoin, no matter what block size.  You automatically split the ecosystem in "miners" and "users" and you get a power law distribution in the "miner" business, that limits the amount of "servers" to a small number.

PoW was a good P2P thing when people could use their PC.  However, the following aspects of bitcoin rendered it a killer of P2P:
- the all-or-nothing nature of block remuneration.  There are only 52000 blocks to be won per year.
- the increasing difficulty (which in itself is related to the emission curve of bitcoin, which in itself makes it bad money and good speculation)
- the possibility to have specialized hardware outperforming general-purpose computers, leaving it to "specialists"
- the possibility to pool mining, which brings an advantage to flatten out statistical fluctuations.

There has been a lot of disinformation around this entire issue.  People seem to refuse the natural consequences of the design principles of bitcoin (even though Satoshi explained that projection already in 2008), and invented an entirely bogus story about "decentralization".  Mind you, that client/multi server system can work very well !  In fact, there are incentives for the "multi servers" to continue playing by the rules, even if this thing is not decentralized as a true libertarian would dream it.  And that's why bitcoin is functioning even though the power in in the hands of 3 or 4 entities.  All this discussion is about a religious notion of "decentralization" which is not possible in a system like bitcoin, not because of blocks, but because of the design problems I mentioned higher up.  But it works.

I think that the LN invention, in itself, is a good thing, which is why BCH lacking it, is a problem.  But I think that keeping the silly block limit in bitcoin, is a crazy idea too.  The problem with wanting to promote the LN as a "second payment layer", which is in my opinion, a bad application of the LN technology, is self-contradictory for the following reason.  The LN as a second layer only makes sense if the block chain is congested, has high fees, and "pushes people off-chain.  Otherwise, people would use the block chain.  But when  the block chain is congested, the LN becomes less secure !  And if the block chain works well and can easily guarantee you your opening and settling of channels without a hassle, there's no need for it.  I think this has been entirely misguided.  The LN has much better NEW applications, like HF trading, atomic swapping and so on, but also securing your holdings on an exchange.  It can eventually be used for special cases where a lot of fast micropayments have to be made between a limited set of players.  But it is a bad idea IMO to think it should replace the fundamental function of payments on chain.

[dinofelis]

- snip -
If you remain online, and if the block chain is not saturated, however, the LN is quite safe to use.  
- snip -

I'm still getting up to speed on the technical details of exactly how LN works, but I thought...

1. Others will only be able to use your node as a route if your node is online.

2. It would be possible for your node to provide a service with ONLY your revocation keys for your open channels, and not ANY of your other private keys.

I don't see how this is possible.  After all, "using your node" means: updating your balances, and to update your balances, you have to half-sign transactions with your partners.  For that, you need your keys of course.  If updating your balances were possible without your keys, it would be frankly scary !

If you are Bob, and you are connected to Alice in channel 1 and to Joe in channel 2, and Alice wants to pay Joe through you for, say 0.1 BTC, then you have to exchange updated half-transactions with Alice where your balance in channel 1 increases, and you have to exchange updated half-transactions with Joe in channel 2 where your balance in channel 2 decreases.  In other words, you have to pay Joe.  Obviously, in order to pay Joe, you need your keys !  But also to update the state of the balance in channel 1.

[DannyHamilton]

- snip -
If you remain online, and if the block chain is not saturated, however, the LN is quite safe to use.  
- snip -

I'm still getting up to speed on the technical details of exactly how LN works, but I thought...

1. Others will only be able to use your node as a route if your node is online.

I don't see how this is possible.  After all, "using your node" means: updating your balances, and to update your balances, you have to half-sign transactions with your partners.  For that, you need your keys of course.  If updating your balances were possible without your keys, it would be frankly scary !

If you are Bob, and you are connected to Alice in channel 1 and to Joe in channel 2, and Alice wants to pay Joe through you for, say 0.1 BTC, then you have to exchange updated half-transactions with Alice where your balance in channel 1 increases, and you have to exchange updated half-transactions with Joe in channel 2 where your balance in channel 2 decreases.  In other words, you have to pay Joe.  Obviously, in order to pay Joe, you need your keys !  But also to update the state of the balance in channel 1.

I don't understand what you are saying.

Are you agreeing with me? The tone of your comment makes it sound like you are disagreeing, but the content of your comment makes it sound like you are agreeing.  I'm VERY confused in my attempt to make sense of your statement.

2. It would be possible for your node to provide a service with ONLY your revocation keys for your open channels, and not ANY of your other private keys.

As far as I can tell, you still haven't commented on this scenario yet.

[dinofelis]

- snip -
If you remain online, and if the block chain is not saturated, however, the LN is quite safe to use.  
- snip -

I'm still getting up to speed on the technical details of exactly how LN works, but I thought...

1. Others will only be able to use your node as a route if your node is online.

I don't see how this is possible.  After all, "using your node" means: updating your balances, and to update your balances, you have to half-sign transactions with your partners.  For that, you need your keys of course.  If updating your balances were possible without your keys, it would be frankly scary !

If you are Bob, and you are connected to Alice in channel 1 and to Joe in channel 2, and Alice wants to pay Joe through you for, say 0.1 BTC, then you have to exchange updated half-transactions with Alice where your balance in channel 1 increases, and you have to exchange updated half-transactions with Joe in channel 2 where your balance in channel 2 decreases.  In other words, you have to pay Joe.  Obviously, in order to pay Joe, you need your keys !  But also to update the state of the balance in channel 1.

I don't understand what you are saying.

Are you agreeing with me? The tone of your comment makes it sound like you are disagreeing, but the content of your comment makes it sound like you are agreeing.  I'm VERY confused in my attempt to make sense of your statement.

2. It would be possible for your node to provide a service with ONLY your revocation keys for your open channels, and not ANY of your other private keys.

As far as I can tell, you still haven't commented on this scenario yet.

My comment was for scenario 2, not 1.  You have to have your keys at disposal all the time when people use your node.  There's no way to be an intermediate node on a payment route, without using your keys.  Some formatting of the posts went wrong I think.

[DannyHamilton]

My comment was for scenario 2, not 1.

Then you need to go back and read #2 again and actually pay attention to what I am saying this time.  Then if you agree with me, we can perhaps both delete these recent posts since then so as not to confuse others with your misunderstanding.

You have to have your keys at disposal all the time when people use your node. There's no way to be an intermediate node on a payment route, without using your keys.

Correct. That is what #1 states.  We are in agreement.

#2 has nothing to do with people using my node.  #2 has to do with protecting myself from a stale state while my node is offline.

Some formatting of the posts went wrong I think.

No.  I just applied your reply to my comment that it was talking about.  There is NOTHING in your response that has ANYTHING to do with what I said in #2.  If you thought you were responding to #2, then you failed to understand what I wrote.

[dinofelis]

2. It would be possible for your node to provide a service with ONLY your revocation keys for your open channels, and not ANY of your other private keys.

did you mean "impossible" maybe ?  Because it is NOT possible to provide a service with only revocation keys and without other private keys.

[DannyHamilton]

2. It would be possible for your node to provide a service with ONLY your revocation keys for your open channels, and not ANY of your other private keys.

did you mean "impossible" maybe ?  Because it is NOT possible to provide a service with only revocation keys and without other private keys.

Why not?  Did you read the entire paragraph? Or did you just read that one sentence and then assume you knew what I was suggesting?