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

[Carlton Banks]

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.

You're failing to mention another option (that may well be the most popular option):


Set up a uni-directional channel. Then you keep your keys, and go offline whenever you like. You're turning into another one of those people that keeps saying the word "bank" as often as it can be fitted in.

[1714985143]

1714985143

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

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?

Ah, I was confused by the two different references to "you".  "you" providing a service (I thought, in the LN network as a node) with "your" revocation keys only.

You meant: Jack providing a service to Joe, who can give his revocation key to Jack while Joe is on a holiday, and Jack watching whether Joe's partner is, in the mean time, not scamming him, and if ever he does, he sends a punishment transaction with the revocation key in the name of Joe.

Yes, I see now finally what you mean.  A kind of online watchdog that sends punishments only, to keep your channels open and guard them while you're on a holiday.

As you say yourself, I guess the big danger is that Jack can now run with the punishment coins.  If ever he knows who was Joe's partner, they could even make a deal !  Joe's partner sends a stale settlement, Jack sends the punishment transaction with the revocation key to a new address, and Jack and Joe's partner share Joe's part of the channel.  Hmm.  I think I'm going to set up such a service   

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

- snip -
Ah, I was confused by the two different references to "you".  "you" providing a service (I thought, in the LN network as a node) with "your" revocation keys only.
- snip -

I see now how my choice of words might have been confusing, I'll go edit the post and make it easier to understand.

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

- snip -
Ah, I was confused by the two different references to "you".  "you" providing a service (I thought, in the LN network as a node) with "your" revocation keys only.
- snip -

I see now how my choice of words might have been confusing, I'll go edit the post and make it easier to understand.

Sorry for having been thick 

[DannyHamilton]

As you say yourself, I guess the big danger is that Jack can now run with the punishment coins.

Correct.

In exactly the same way that Coinbase.com or localbitcoins.com or ANY of the MANY other services that provide accounts COULD run with all of the bitcoins that the user leaves on account.

BUT (unlike all those other accounts), this service doesn't have access to your coins at all UNLESS your channel partner broadcasts a stale state.

If ever he knows who was Joe's partner, they could even make a deal!

While not impossible, it would not be easy for the service provider to know who the channel partners are. Joe ONLY needs to provide the revocation keys. He doesn't need to tell the service how many bitcoins are in the channel, or who the counterparty is, or which output was used to open the channel.  The revocation key will not be enough information for the service to calculate how many bitcoins are in the channel, or who the counterparty is, or which output was used to open the channel. The service would need to scan every input in every new block for any channel closings and pair up the revocation keys with the data from the closing of the channel to determine if the key could be used to revoke the closing.  Jack on the other hand, would have to contact every available monitoring service in the world to see if any of them were both holding the correct keys AND willing to collude with him.

Furthermore, Joe could run such a service as software on his own computer (hosted or otherwise) while he was "on vacation", so Jack would need to be aware that Joe was doing so AND determine where such a computer was AND access that computer to keep it from broadcasting the revocation transaction.

[dinofelis]

As you say yourself, I guess the big danger is that Jack can now run with the punishment coins.

Correct.

In exactly the same way that Coinbase.com or localbitcoins.com or ANY of the MANY other services that provide accounts COULD run with all of the bitcoins that the user leaves on account.

BUT (unlike all those other accounts), this service doesn't have access to your coins at all UNLESS your channel partner broadcasts a stale state.

If ever he knows who was Joe's partner, they could even make a deal!

While not impossible, it would not be easy for the service provider to know who the channel partners are. Joe ONLY needs to provide the revocation keys. He doesn't need to tell the service how many bitcoins are in the channel, or who the counterparty is, or which output was used to open the channel.  The revocation key will not be enough information for the service to calculate how many bitcoins are in the channel, or who the counterparty is, or which output was used to open the channel. The service would need to scan every input in every new block for any channel closings and pair up the revocation keys with the data from the closing of the channel to determine if the key could be used to revoke the closing.  Jack on the other hand, would have to contact every available monitoring service in the world to see if any of them were both holding the correct keys AND willing to collude with him.

Furthermore, Joe could run such a service as software on his own computer (hosted or otherwise) while he was "on vacation", so Jack would need to be aware that Joe was doing so AND determine where such a computer was AND access that computer to keep it from broadcasting the revocation transaction.

Mmm.  I think you've been buying the domain "bitcoinrevocation.com" 

[franky1]

the "revocation key" of say TX1 becomes part of TX2 when tx2 is formed and agreed

so if a sends out a "stale" tx(tx1)  then all that needs to be done is the other party needs to send out the latest tx(tx2) to overrule tx1
..
issue arises though is when there is a situation where person A cannot get a refund for bad service from B so A hopes B goes offline before B can send TX2.. so that A can send TX1 and hope that B doesnt wake up to send TX2..

B does not need to ask for a TX1 revoke key. as i said its already part of TX2
..
and as i said before B can blackmail/ refuse to make a new payment(tx3) to refund A. and as such forced A to just cry, or send out tx1 in the hope that A can get some funds.. but if B is greedy. B will send out TX2 to overrule tx1. and thus B keeps the goods and the funds


and as for Cbanks comment.. uni-directional (facepalm)(im laughing)
if a channel is you to you... you can only pay yourself in that channel.

if you want to pay others. you need other parties in another channel. but you cant move funds out of the uni channel and into a bi-directional channel without closing the uni channel to then deposit them into the bidirectional channel

i think people need to run scenarios and play around.. instead of just reading they promotional hype on reddit

EG
[A:10-A:10][A:10-A:10]   [A:10-B10]
if A moves all its funds t one side in a uni.. it does not make A's bi directional suddenly fill up with an extra 40btc within LN while the channels are open

i think people need to run scenarios and play around.. instead of just reading the promotional hype on reddit

ok the first 2 channels are unidirectional.. and they do not matter at all because there is no routing.. there is literally no reason/utility in setting up [a-a]  
because the [A-A] channels wont ever change.. at opening A put 20btc in.. at closing A gets 20btc out per channel
EG
true:[A:0-A:20][A:0-A:20]   [A:10-B10]
false: [A:0-A:20][A:0-A:20]   [A:50-B10] {magic used}
false: [A:0-A:0][A:0-A:0]   [A:50-B10] {funds magically move without closing channel}

easier and common sense to just leave the 40btc (uni funds) in a legacy address without even wasting onchain fes to open a stupid uni channel... get a piece of paper and write to yourself i have 40btc and of that 40btc i owe myself 40btc

 its far better to not waste onchain fee's to store funds that wont move.. and just put the 50btc total into the [a-b] because the 40btc in the unichannels wont move as routed payments. because A will always be paying A

[dinofelis]

issue arises though is when there is a situation where person A cannot get a refund for bad service from B so A hopes B goes offline before B can send TX2.. so that A can send TX1 and hope that B doesnt wake up to send TX2..

This is kind of stupid.  Like in normal bitcoin transactions, payments are irreversible.  If there's no escrow, there's no way to "get a refund".  Once you've paid, you've paid.  What you are complaining about, is essentially that A has no possibility to steal back his money, and if he tries so, he risks to get screwed.  Well, the whole idea is that if you try to steal, you get screwed, yes.  With a normal bitcoin transaction, there's not even the smallest possibility to steal back your previous payment (unless you attack the block chain, and orphan the prong in which your payment was done - usually a more expensive undertaking than just propose someone to pay him if he kills B, say).  Now, the LN system may let you a tiny hope to steal your payment back, but it was designed to make this very risky.  You cannot use the tiny risky potential to steal in an LN as a normal way to "get a refund".

[franky1]

issue arises though is when there is a situation where person A cannot get a refund for bad service from B so A hopes B goes offline before B can send TX2.. so that A can send TX1 and hope that B doesnt wake up to send TX2..

This is kind of stupid.  Like in normal bitcoin transactions, payments are irreversible.  If there's no escrow, there's no way to "get a refund".  Once you've paid, you've paid.  What you are complaining about, is essentially that A has no possibility to steal back his money, and if he tries so, he risks to get screwed.  Well, the whole idea is that if you try to steal, you get screwed, yes. With a normal bitcoin transaction, there's not even the smallest possibility to steal back your previous payment (unless you attack the block chain, and orphan the prong in which your payment was done - usually a more expensive undertaking than just propose someone to pay him if he kills B, say).  Now, the LN system may let you a tiny hope to steal your payment back, but it was designed to make this very risky.  You cannot use the tiny risky potential to steal in an LN as a normal way to "get a refund".

im not saying its the way to get a refund. im saying that B can blackmail A,
many people over many months have been promoting LN as the trustless system of decentralised control.

the reality is that LN is (using a bank analogy to ELI-5 it) a joint account with a spouse..
and that spouse has another joint bank account with the plumber
if YOU want to pay the plumber. you tell your wife she can have a % of you and your spouses account balance. if she then uses her other account with the plumber to give the plumber a % of that separate joint account.
its not about your funds entering the plumbers account direct

its also worth noting and people need to accept the risk that their funds are no longer 100% theirs in a channel.. its not a sole holder bank account. its a joint account. because it requires the other person to agree on what you want to do with "your money".

but back to the topic as the scenario has meandered.
the revocation key is not something you request when a dispute arises. its something thats already part of the latest tx, to revoke any disputes of using previous tx's (but a slight risk the prev tx can succeed if the latest tx is not transmitted in time)

[dinofelis]

its also worth noting and people need to accept the risk that their funds are no longer 100% theirs in a channel.. its not a sole holder bank account. its a joint account. because it requires the other person to agree on what you want to do with "your money".

.... only the time of lock out and a fee.  You can always unilaterally settle a channel, only your funds will not be available to you for a pre-fixed time, say, a day, or a week (100 blocks, 1000 blocks), which you agreed upon when you opened the channel.

If I put 1 BTC in a channel with Joe, and Joe also puts 1 BTC in that channel, and we agree when we do that, that the lock-out time is 1 week, and then Joe goes fishing and I never see him again, I can get my bitcoin back by settling, all by myself.  But I will only be able to use my 1 BTC again next week.  And I'll be the one paying a fee.

That remains true if I bought first something with Joe.  If I buy fishing gear from Joe for 0.25 BTC, and Joe and I do a LN transaction, updating our channel (for that, Joe has to interact with me ; if he doesn't I cannot send him 0.25 BTC over the channel), I now have the new state, and if Joe goes fishing at that point, I can settle unilaterally in a 0.75 / 1.25 ratio.  After a week, the 0.75 BTC minus fee are mine and Joe has his 1.25 BTC if he wants to.  I don't need him to do anything for that.

[franky1]

its also worth noting and people need to accept the risk that their funds are no longer 100% theirs in a channel.. its not a sole holder bank account. its a joint account. because it requires the other person to agree on what you want to do with "your money".

and we agree when we do that, that the lock-out time is 1 week,

still needs agreement, thus LN is not peer to peer its partner to partner, just to clarify the inaccuracy of LN promotional material

..
anyway, without 2 signatures.. funds cant move

[dinofelis]

its also worth noting and people need to accept the risk that their funds are no longer 100% theirs in a channel.. its not a sole holder bank account. its a joint account. because it requires the other person to agree on what you want to do with "your money".

and we agree when we do that, that the lock-out time is 1 week,

still needs agreement, thus LN is not peer to peer its partner to partner, just to clarify the inaccuracy of LN promotional material

..
anyway, without 2 signatures.. funds cant move

Well, if we don't agree that the lock-out time is 1 week, we cannot even start to set up the channel of course, so nothing is locked in.  It is during the same process of fixing the lock-out time, that the initial commitment transaction is made and broadcast.  If there's no agreement on the lock-out time, there's no possibility to even make a commitment transaction, and certainly not to broadcast it.

But I like your expression "partner to partner".  In peer-to-peer, your connection to a peer is "without engagement" and can be broken as fast as it can be set up, with no costs.  If I fire up Openbazaar, I look for peers, but these peers are individually trustless, and if some behave badly (don't respond, flood, do crazy things), I can just cut the connection and look for another peer in a matter of seconds.  Once my funds are locked in with 'a guy on the internet', it is my partner and I cannot whimsically decide to cut that and go elsewhere in a matter of seconds.  it is a matter of days or weeks, and I have to pay money.  This is why I said that one cannot compare IP routing to the LN. 

So indeed, partner to partner.