1. do you agree that LN uses multisig. where 2 parties co-sign agreed tx data. if yes read on, if not, research and come back later.
hint 2: both signing = both seeing a copy to be able to sign
Somewhy you fail to understand, that both parties sign the
same commitment transactions before they can be broadcast.
i understand it.. i was the one telling YOU that
here is me telling you its one TX they both sign and
you arguing the oppositethey both hold the same relevant tx at the same time.
No,
they hold different txes, which however distribute funds in similar ways.
Both parties have seen both commitment transactions. But each party has only one of two commitment transactions with both signatures.
you do know that multisigs needs 2 signatures.
you do know that to agree to what you call a "commitment" both parties need to see and agree to it.
Y can't broadcast that transaction because he doesn't have it.
He instead has another transaction corresponding to the same state,
funny that in lastest post your arguing with yourself
Another hint: commitment transaction that Alice holds was created and signed by Bob. Now Alice holds this transaction, she sees it, she can sign it. Same with Bob's transaction. It was created by Alice. But Alice can't herself broadcast transaction which she created, because this transaction lacks Bob's signature. It's how multisignature works. You need both signatures for a transaction to be valid.[/b] Please bother to carefully read either the articles or my narration (or both). May be I'm bad at explaining, because English isn't my native language?
another failure on your part. unless its signed by both sides its not committed.
it needs to be seen by both sides to be signed by both sides to be fully commited. otherwise the state wont update.
no one in LN will update the state unless its fully committed. you cannot broadcast a tx without both signatures so you wont accept anything thats only one sided.
hense they both sign to both commit to
the same terms. so that that if one of them goes offline they know the other has signed their part on the side they kept...
like any contract.
imagine a bank loan agreement if a bank signed a loan and passed it to you... you kept it but didnt sign the copy you kept
imagine a bank loan agreement if you signed a loan and passed it to the bank... they kept it but didnt sign the copy they kept
this leaves things open to abuse.
hense why both need to see BOTH signatures
About your scenario. I'm not sure I fully understand it, what do you mean by B(X) for instance? What do you mean by "maturity 1000 blocks"? It's not tx which matures in 1000 blocks, it's one of it's outputs that does so (in fact not even so, it's one of ways the output can be spent which matures in 1000 blocks).
firstly
THE scenario was me writing it in YOUR concept to show wher YOUR concept fails.
secondly
A(X)is using YOUR identifiers because you first started with X and Y.. then changed to A and B.. so i combined A(X) lets call her alice xavier.. and then a separate person B(Y) lets call him Bob Yonker.
thirdly
right at the bottom i said "
the output spendable to him instantly before maturity expires"
im not sure where you got tx from.
summary:
they are just 2 entities. but i tried to use your identifiers.. but YOU kept switching between X Y then later A B ..
aswell as your flip flops between dual signed single tx and duel signs separate tx..
JUST PICK ONE CONCEPT THAT MAKES SENSE TO YOU AND STICK TO IT.
OR EVEN BETTER
stay uptodate and then know the latest concepts and know what the main guys are trying to build. rather than the flawed out of date stuff
By "out scripts" you mean scripts of 2 outputs which commitment transactions create, Out script1 is for output1, Out script2 is for output2, right?
Then how it's possible
Out script2: if relevant(1klmnopqrs987654321 B(Y) val: 1btc); if irrelevant(1abcdefghij123456789 A(X) val: 10btc)
that the same output may result in significantly different amount of BTC spent, depending on a condition?
Not to mention, that commitment transactions in simple bidirectional channels create only 1 conditional output.
you can have a condition attached to any and all outputs
when its first broadcast its treated as relevant. so a future spender (once maturity expires) would care about this:
Out script1: if relevant(1abcdefghij123456789 A(X) val: 9btc);
if irrelevant(1klmnopqrs987654321 B(Y) val: 10btc)Out script2: if relevant(1klmnopqrs987654321 B(Y) val: 1btc);
if irrelevant(1abcdefghij123456789 A(X) val: 0btc)it ignores the
irrelevant part meaning A(X) alice Xavier gets 9btc. B(y)bob yonker would get 1btc.
however if B(Y) Bob yonker invoked a CSV revoke
when its first broadcast its treated as relevant. but revoke is invoked and so a future spender would care about this:
Out script1:
if relevant(1abcdefghij123456789 A(X) val: 9btc); if irrelevant(1klmnopqrs987654321 B(Y) val: 10btc)
Out script2:
if relevant(1klmnopqrs987654321 B(Y) val: 1btc); if irrelevant(1abcdefghij123456789 A(X) val: 0btc)
it ignores the relevant part meaning B(y)bob yonker would get 10btc. A(X) alice Xavier gets 0btc.
