Topic: [LN] What is revocation key? How does revocation works on bitcoin blockchain? - page 2. (Read 481 times)

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.


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?

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.

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.

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

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

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?

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)

---

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.

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

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.

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.

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?