Skip to main content
added 1227 characters in body
Source Link

Why commitment transactions can't simply be HTLCs instead of contracts revocable by having the second half of the Revocable Private Key? I mean, why bother to create a Revocable Public Key from two halves of Alice's and Bob's private keys and when invalidating a transaction sharing the other half, when both Alice and Bob could create two transactions, both revocable with two separate keys known only to Alice and Bob, which later would be exchanged in order to invalidate old transactions?

Edit: My current understanding of how commitment transactions work

Both Alice (A) and Bob (B) create opposite transactions:

TX_A:

5 BTC -> B
if RK_A
  5 BTC -> B
else if 1k blocks later
  5 BTC -> A
(Signed by B)

TX_B:

5 BTC -> A
if RK_B
  5 BTC -> A
else if 1k blocks later
  5 BTC -> B
(Signed by A)   

Where RK_A is A's revocation key. Now if TX_A and TX_B are valid, neither B has RK_B, nor A has RK_B. Therefore, both of them can sign their respective transactions and "get out" of this channel after 1k blocks without risk of loosing all their BTC.

However, once both A and B decide to forget about the old balance they have to invalidate TX_A and TX_B. They do this by A revealing RK_A to B and B revealing RK_B to A. This way, if for instance A signs TX_A and broadcasts it to the Bitcoin network, B can provide RK_A and claim additional 5 BTC.


Now the process of creating and revealing RK_X seems to be involved, and my questions therefore is, why not simply have some random numbers in place of RK_A and RK_B that only A and B knows and which are later exchanged when TX_A and TX_B need to be invalidated?

Why commitment transactions can't simply be HTLCs instead of contracts revocable by having the second half of the Revocable Private Key? I mean, why bother to create a Revocable Public Key from two halves of Alice's and Bob's private keys and when invalidating a transaction sharing the other half, when both Alice and Bob could create two transactions, both revocable with two separate keys known only to Alice and Bob, which later would be exchanged in order to invalidate old transactions?

Why commitment transactions can't simply be HTLCs instead of contracts revocable by having the second half of the Revocable Private Key? I mean, why bother to create a Revocable Public Key from two halves of Alice's and Bob's private keys and when invalidating a transaction sharing the other half, when both Alice and Bob could create two transactions, both revocable with two separate keys known only to Alice and Bob, which later would be exchanged in order to invalidate old transactions?

Edit: My current understanding of how commitment transactions work

Both Alice (A) and Bob (B) create opposite transactions:

TX_A:

5 BTC -> B
if RK_A
  5 BTC -> B
else if 1k blocks later
  5 BTC -> A
(Signed by B)

TX_B:

5 BTC -> A
if RK_B
  5 BTC -> A
else if 1k blocks later
  5 BTC -> B
(Signed by A)   

Where RK_A is A's revocation key. Now if TX_A and TX_B are valid, neither B has RK_B, nor A has RK_B. Therefore, both of them can sign their respective transactions and "get out" of this channel after 1k blocks without risk of loosing all their BTC.

However, once both A and B decide to forget about the old balance they have to invalidate TX_A and TX_B. They do this by A revealing RK_A to B and B revealing RK_B to A. This way, if for instance A signs TX_A and broadcasts it to the Bitcoin network, B can provide RK_A and claim additional 5 BTC.


Now the process of creating and revealing RK_X seems to be involved, and my questions therefore is, why not simply have some random numbers in place of RK_A and RK_B that only A and B knows and which are later exchanged when TX_A and TX_B need to be invalidated?

Source Link

HTLCs and commitment transactions

Why commitment transactions can't simply be HTLCs instead of contracts revocable by having the second half of the Revocable Private Key? I mean, why bother to create a Revocable Public Key from two halves of Alice's and Bob's private keys and when invalidating a transaction sharing the other half, when both Alice and Bob could create two transactions, both revocable with two separate keys known only to Alice and Bob, which later would be exchanged in order to invalidate old transactions?