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

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.

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

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

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)

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

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

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

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.

Sorry for having been thick 

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

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   

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.

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?

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

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.

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.

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.

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 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://bitcointalksearch.org/topic/m.29426613

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'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?