Bitcoin Forum

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.

 

http://dl3.joxi.net/drive/2018/01/30/0026/3410/1752402/02/ef00ae9fb9.jpg

 

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 (https://bitcoin.stackexchange.com/questions/56764/how-does-lightning-transaction-revocation-work).

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.

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

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.

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)

---

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

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

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.

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.

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?

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?

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.

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.


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.

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.


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.


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.

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?

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.

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   ;D

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  ;D

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.


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"  ;D

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

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)

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

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.