Scaling Bitcoin. Is consensus achievable?

[stdset]

rationally LN should regularly close channels.

Could you please elaborate. Why LN needs to frequently close channels?

locktimes
EG say the locktime is  now+864000seconds (10days) 1480244302+864000seconds = 1481108302
LN does not stay active for 10 days
every transaction within LN uses a lock to keep latest relevance
in conception
tx z: unlock 1481108301
tx y: unlock 1481108300
tx x: unlock 1481108299
which means if in milliseconds a hub does 86400 tx's  it now has to close within 9 days of opening
which means if in milliseconds a hub does 172800 tx's  it now has to close within 8 days of opening
which means if in milliseconds a hub does 259200 tx's  it now has to close within 7 days of opening

also the secret is although being conceived that locktime of +864000 seconds means 864000 transactions are possible. its not
firstly. to secure relevance, there needs to be a gap between locks. so that the most relevant(x) doesnt time out and the next irrelevant(y) becomes relevant again due to there not being enough time to broadcast X before Y's time becomes relevant.

its going to end up that locktimes will be 10mins plus, to give a relevance 'grace' period.
eg
tx z: unlock 1481072302
tx y: unlock 1481036302
tx x: unlock 1481000302

That's not the case with CSV, which is already adopted on mainnet.

Scriptable relative locktime provides a predictable amount of time to respond in the event a counterparty broadcasts a revoked transaction: Absolute locktime necessitates closing the channel and reopen it when getting close to the timeout, whereas with relative locktime, the clock starts ticking the moment the transactions confirms in a block. It also provides a means to know exactly how long to wait (in number of blocks) before funds can be pulled out of the channel in the event of a noncooperative counterparty.

https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki

[franky1]

simple illustration


lock= 2 hours
left graph: user spends every 10 minutes
spend at 10th minute - lock release at 1hour 50min
spend at 20th minute - lock release at 1hour 40min
spend at 30th minute - lock release at 1hour 30min
spend at 40th minute - lock release at 1hour 20min
spend at 50th minute - lock release at 1hour 10min
cant use as realtime and locktime release lock is soon
end result lock-in was 2 hours but had to close in an hour - tx processed 5 out of 12

middle graph: user spends every 5 minutes
spend at   5th minute - lock release at 1hour 50min
spend at 10th minute - lock release at 1hour 40min
spend at 15th minute - lock release at 1hour 30min
spend at 20th minute - lock release at 1hour 20min
spend at 25th minute - lock release at 1hour 10min
spend at 30th minute - lock release at 1hour
spend at 35th minute - lock release at 50min
cant use as realtime and locktime release lock is soon
end result lock-in was 2 hours but had to close in 40 minutes - tx processed 7 of 12

middle graph: just once
spend at   Xth minute - lock release at 1hour 50min
time passes locktime release lock is soon
end result lock-in was 2 hours but had to close in at 1 hour 50 minutes - tx processed 1 of 12

[franky1]

That's not the case with CSV, which is already adopted on mainnet.

Scriptable relative locktime provides a predictable amount of time to respond in the event a counterparty broadcasts a revoked transaction: Absolute locktime necessitates closing the channel and reopen it when getting close to the timeout, whereas with relative locktime, the clock starts ticking the moment the transactions confirms in a block. It also provides a means to know exactly how long to wait (in number of blocks) before funds can be pulled out of the channel in the event of a noncooperative counterparty.

https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki

yes
i just called it a laymens term of relevant gap/grace period (dont get hung up on my 10minute arbitrary number i used),
the old mechanism "in number of blocks" (as you quoted)
new concepts are using seconds instead. so instead of saying blockheight. or seconds. i for easy explanation for the scenarios said 10 minutes.. but the 10 minutes is not important. its just a demo purpose random number


the point is: gap simply wont be 1 second as that can be abused, much like in paypal everyone waits till the final second to push their bids)

the gap between acceptable bids needs to be more then one second. due to onchain issues about relay-propagation times and other factors
also i factored in that say the gap was 3 seconds. every time a person doesnt use LN for 3 seconds thats one possible lock wasted.
also i factored in that say the gap was 3 seconds. every time a person uses LN in milliseconds that takes away 3 seconds of utility

meaning its not an unlimited amount of transactions right up to the ONCHAIN nlocktime, there are actual limits to LN

to add to this..

in practice.. using say the middle graph (of my last post)
or
"which means if in milliseconds a hub does 259200 tx's  it now has to close within 7 days of opening" (scenario of post previous to that)

even though a onchain timelock wont allow the close session to be allowed/confirmed onchain until:
middle graph agreed tx(close session) reached 2hours 10 minutes
259200tx agreed tx (close session) reached 10 days 10 minutes

it still closes at:
middle graph 40 minutes - but just not confirmed onchain for another 1 hour 30 minutes (after 2 hours from opening due to onchain lock)
259200tx agreed tx 7 days - but just not confirmed onchain for 3 days. (after 10 days from opening due to onchain lock)

in short .. users are waiting hours or days unable to use LN at all, because all (inner LN) locks are used up. where users cant keep spending and the funds are not released onchain.. basically leaving users left in limbo.

meaning practically the channels SHOULD close earlier to not leave users in limbo. hense my gripe that channels should be able to close earlier.


from what i can see is in concept as their 'work around'
while users are in limbo between the LN inner lock being used up and the onchain locktime (scenario1:1h 30mb, scenario2: 3days)
users are persuaded to make a second channel using different funds (while initial funds are locked) to restart using the service while the limbo time of first session expires.

[stdset]

simple illustration


lock= 2 hours
left graph: user spends every 10 minutes
spend at 10th minute - lock release at 1hour 50min
spend at 20th minute - lock release at 1hour 40min
spend at 30th minute - lock release at 1hour 30min
spend at 40th minute - lock release at 1hour 20min
spend at 50th minute - lock release at 1hour 10min
cant use as realtime and locktime release lock is soon
end result lock-in was 2 hours but had to close in an hour - tx processed 5 out of 12

middle graph: user spends every 5 minutes
spend at   5th minute - lock release at 1hour 50min
spend at 10th minute - lock release at 1hour 40min
spend at 15th minute - lock release at 1hour 30min
spend at 20th minute - lock release at 1hour 20min
spend at 25th minute - lock release at 1hour 10min
spend at 30th minute - lock release at 1hour
spend at 35th minute - lock release at 50min
cant use as realtime and locktime release lock is soon
end result lock-in was 2 hours but had to close in 40 minutes - tx processed 7 of 12

middle graph: just once
spend at   Xth minute - lock release at 1hour 50min
time passes locktime release lock is soon
end result lock-in was 2 hours but had to close in at 1 hour 50 minutes - tx processed 1 of 12

I'm not sure if I understand you right. But it seems to me that you mean, that each consecutive pair of commitment transactions (those that aren't broadcast under normal circumstances) occurring on the channel must have shorter locktimes, so that later ones could be confirmed sooner than earlier ones?
If so, that's not the case. All commitment transactions produce outputs that may have the same time lock of say 1000 blocks, beginning from the block which includes parent commitment transaction. Commitment transactions are invalidated not thanks to newer commitment transactions have shorter timelock, but through exchanging secrets, whose hashes are exchanged at the beginning of state update. So at any step each party has only 1 commitment transaction that can be safely posted to the network, that's the latest transaction. All previous transactions are invalidated because should say X posts one of those transactions, Y can immediately take all funds form the channel.

[franky1]

I'm not sure if I understand you right. But it seems to me that you mean, that each consecutive pair of commitment transactions (those that aren't broadcast under normal circumstances) occurring on the channel must have shorter locktimes, so that later ones could be confirmed sooner than earlier ones?
If so, that's not the case. All commitment transactions produce outputs that may have the same time lock of say 1000 blocks, beginning from the block which includes parent commitment transaction. Commitment transactions are invalidated not thanks to newer commitment transactions have shorter timelock, but through exchanging secrets, whose hashes are exchanged at the beginning of state update. So at any step each party has only 1 commitment transaction that can be safely posted to the network, that's the latest transaction. All previous transactions are invalidated because should say X posts one of those transactions, Y can immediately take all funds form the channel.

im trying not to use buzzwords or over complex things so other readers can understand the fundamentals.

as for the individual spends within LN, they too need to do some things.
the 'secret exchange' in practice does not work. hense the need for the locks aswell.

EG (your concept version)
 i could have a direct connection to a pool and have bribed them to put my tx into a block the exact moment the 1000 block lock is released.. so when i send X in the last second, its in.
you spot mine and think your Y would over ride my X. the problem is that your Y transaction has to relay around the network and sit with the other high fee paying blocks in mempool before a pool accepts it into a block.. which after seeing the mempool bloat this week might be 2 hours.
where as mine gets in. making yours invalid(double spend attack).

thats why locktimes are needed too. to delay mine from being acceptable.

the bip you referenced may have exampled a 24 hour revoke time. but in practice.. users wont accept that.
also that can be attacked/abused in atleast 3 ways.

but hey there are many LN concepts, i just hope the one your viewing is not going to ignore using inner locktimes of descending order.. otherwise thats a weakness of that concept.

[stdset]

im trying not to use buzzwords or over complex things so other readers can understand the fundamentals.

as for the individual spends within LN, they too need to do some things.
the 'secret exchange' in practice does not work. hense the need for the locks aswell.

EG (your concept version)
 i could have a direct connection to a pool and have bribed them to put my tx into a block the exact moment the lock is released.. so when i send X in the last second. you think your Y would over ride it. the problem is that your Y transaction has to relay around the network and sit with the other high fee paying blocks in mempool before a pool accepts it into a block.. which after seeing the mempool bloat this week might be 2 hours.
where as mine gets in. making yours invalid.

thats why locktimes are needed too.

but hey there are many LN concepts, i just hope the one your viewing is not going to ignore using inner locktimes of descending order.. otherwise thats a weakness of that concept

The concept I'm talking about works the following way:
Let's say current channel state is: 5 BTC belong to X, 5 BTC belong to Y. But among previous states there is one where 9 BTC belong to X and only 1 BTC belong to Y. X likes the older state much more. So he broadcasts it. The transaction that he broadcasts spends the original 2 of 2 output and creates 2 new outputs: 1 BTC immediately goes to Y, and another output is created, let's call it o2. o2 can be spent in 2 different ways. First: X can spend it after 1000 blocks are mined on top of the block where o2 was created. Second: Y can spend it at any moment if, besides signature, he also provides preimage of a certain hash. Since Y already has this preimage, otherwise he would refuse to update state of the channel, he can immediately spend o2, thus taking all 10 BTC from the channel. Friendly pool can't help X, because it takes 1000 blocks before o2 can be spent in way preferable for X.

[franky1]

im trying not to use buzzwords or over complex things so other readers can understand the fundamentals.

as for the individual spends within LN, they too need to do some things.
the 'secret exchange' in practice does not work. hense the need for the locks aswell.

EG (your concept version)
 i could have a direct connection to a pool and have bribed them to put my tx into a block the exact moment the lock is released.. so when i send X in the last second. you think your Y would over ride it. the problem is that your Y transaction has to relay around the network and sit with the other high fee paying blocks in mempool before a pool accepts it into a block.. which after seeing the mempool bloat this week might be 2 hours.
where as mine gets in. making yours invalid.

thats why locktimes are needed too.

but hey there are many LN concepts, i just hope the one your viewing is not going to ignore using inner locktimes of descending order.. otherwise thats a weakness of that concept

The concept I'm talking about works the following way:
Let's say current channel state is: 5 BTC belong to X, 5 BTC belong to Y. But among previous states there is one where 9 BTC belong to X and only 1 BTC belong to Y. X likes the older state much more. So he broadcasts it. The transaction that he broadcasts spends the original 2 of 2 output and creates 2 new outputs: 1 BTC immediately goes to Y, and another output is created, let's call it o2. o2 can be spent in 2 different ways. First: X can spend it after 1000 blocks are mined on top of the block where o2 was created. Second: Y can spend it at any moment if, besides signature, he also provides preimage of a certain hash. Since Y already has this preimage, otherwise he would refuse to update state of channel, he can immediately spend o2, thus taking all 10 BTC from the channel. Friendly pool can't help X, because it takes 1000 blocks before o2 can be spent in way preferable for X.

^ wrote to try showing how X cant attack but reveals Y is now the attacker
which is another attack vector.

cant you see the attack vector..
dont think about X doing the 9btc.. for X to gain.. thats then everted by Y(your hope of scenario outcome)

think about Y broadcasting th X9Y1... triggering X so Y can then get 10btc
lets say Y broadcasts X's 9btc. to then allow Y to broadcast the tx that gives Y the whole 10btc

anyway theres many concepts throwing about. and many attack vectors in each.
the bip u quoted is not strong enough on its own and actually makes one person gain.

not really a moral/equal paradigm like some other concepts i have seen

[stdset]

The concept I'm talking about works the following way:
Let's say current channel state is: 5 BTC belong to X, 5 BTC belong to Y. But among previous states there is one where 9 BTC belong to X and only 1 BTC belong to Y. X likes the older state much more. So he broadcasts it. The transaction that he broadcasts spends the original 2 of 2 output and creates 2 new outputs: 1 BTC immediately goes to Y, and another output is created, let's call it o2. o2 can be spent in 2 different ways. First: X can spend it after 1000 blocks are mined on top of the block where o2 was created. Second: Y can spend it at any moment if, besides signature, he also provides preimage of a certain hash. Since Y already has this preimage, otherwise he would refuse to update state of channel, he can immediately spend o2, thus taking all 10 BTC from the channel. Friendly pool can't help X, because it takes 1000 blocks before o2 can be spent in way preferable for X.

^ wrote to try showing how X cant attack but reveals Y is now the attacker
which is another attack vector.

cant you see the attack vector..
dont think about X doing the 9btc.. for X to gain.. thats then everted by Y(your hope of scenario outcome)

think about Y broadcasting th X9Y1... triggering X so Y can then get 10btc
lets say Y broadcasts X's 9btc. to then allow Y to broadcast the tx that gives Y the whole 10btc

anyway theres many concepts throwing about. and many attack vectors in each.
the bip u quoted is not strong enough on its own and actually makes one person gain.

not really a moral/equal paradigm like some other concepts i have seen

Y can't broadcast that transaction because he doesn't have it. He instead has another transaction corresponding to the same state, which immediately pays 9 BTC to X and 1 BTC to similar fancy output which can be spent in 2 different ways. If he broadcasts his version of that obsolete state, X will immediately take all 10 BTC from the channel.

[franky1]

The concept I'm talking about works the following way:
Let's say current channel state is: 5 BTC belong to X, 5 BTC belong to Y. But among previous states there is one where 9 BTC belong to X and only 1 BTC belong to Y. X likes the older state much more. So he broadcasts it. The transaction that he broadcasts spends the original 2 of 2 output and creates 2 new outputs: 1 BTC immediately goes to Y, and another output is created, let's call it o2. o2 can be spent in 2 different ways. First: X can spend it after 1000 blocks are mined on top of the block where o2 was created. Second: Y can spend it at any moment if, besides signature, he also provides preimage of a certain hash. Since Y already has this preimage, otherwise he would refuse to update state of channel, he can immediately spend o2, thus taking all 10 BTC from the channel. Friendly pool can't help X, because it takes 1000 blocks before o2 can be spent in way preferable for X.

^ wrote to try showing how X cant attack but reveals Y is now the attacker
which is another attack vector.

cant you see the attack vector..
dont think about X doing the 9btc.. for X to gain.. thats then everted by Y(your hope of scenario outcome)

think about Y broadcasting th X9Y1... triggering X so Y can then get 10btc
lets say Y broadcasts X's 9btc. to then allow Y to broadcast the tx that gives Y the whole 10btc

anyway theres many concepts throwing about. and many attack vectors in each.
the bip u quoted is not strong enough on its own and actually makes one person gain.

not really a moral/equal paradigm like some other concepts i have seen

Y can't broadcast that transaction because he doesn't have it.

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.

so if your saying Y cannot transmit X's preferred tx because Y has never seen it, been handed it or knows of its existance.. then im guessing whatever LN concept you are viewing has far more weaknesses.

i made the bits bold that you mention.. first bold bit.. an old state.. im assuming for practical reasons Y did infact see that state earlier in the day/weeks when it was relevant. so by seeing it, would have (lik any malicious user) kept a copy of it. then as shown by the second bold part its assumed Y is involved to signing the commitments by seeing the commitments..

reason being both SHOULD be signing together.. so my last paragraph is highlighting even your scenario assumes this to be true..
so im not sure why last post says Y never had first state

[kiklo]

Actually SegWit needs 95% of the Miner's Hash to be accepted ,
1 Mining Pool with 8% said they will block it in favor of a hard fork with larger block size.

If everyone else accepts it, they will either join them or get outhashed.

Or if they hold their 8% for 1 year from the segwit install date, Segwit Fails
Let the Betting Pools Begin!

You only need ~70% of the hash to have a successful hard fork, so it is odd SegWit is pushed for more.

No. You need 95%.

Reading comprehensions is not your strong suit,
SegWit is a Soft Fork, which major design changes that require the 95%.
(No one is Arguing that point.)

A True Hard Fork only requires 70% , because you want enough hash to make sure the 30% can not 51% attack your new chain.  

A Hard Fork is no Big Deal, Schedule the update a few weeks later after the software is ready .

This is completely misleading. Such a hard fork would be very dangerous. I highly advise you to stop trolling now, you are very untrustworthy.

You Nervous Nancies do realized that some ALTs hard fork 2 or 3 times a year with Zero Problems.
Comparing technical aspects of different crypto is not trolling , it is called Analyzing.
So your Fear is amazingly Child like.


 

FYI: Insulting my trustworthiness, shows how weak your attempts at logic are.
I run a Blockchain snapshot Service, Multiple Coins Communities Trust Me , can you say the same?
Kiklo's Premium Blockchain Snapshot Service

FYI2:
If your BTC Devs had the Courage to Hard Fork SegWit, then it would have already been implemented or had already failed.
Now it could be a Year before the final outcome of segwit is determined , and during this time BTC Design evolution is basically halted.

[stdset]

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.

Sure, when parties want to update the channel, the following happens:

1) Alice wants to pay 1 BTC to Bob. Both parties create new secrets S2a, S2b, and exchange hashes of those secrets: H2a and H2b.
2) Alice creates transaction tx4 which spends o1 new way: 4 BTC go to Alice (o6), 6 BTC go to output o7, which can be spent in 2 different ways: a) Bob can spend it himself, but only after significant timeout of say 1000 blocks; b) Alice can spend it herself, but only if she provides preimage of H2b i.e. S2b. Alice signs tx4 and sends it to Bob.
3) Bob creates transaction tx5 which spends o1 similar way to tx4: 6 BTC go to Bob (o8), 4 BTC to output o9, which can be spent in 2 different ways: a) Alice can spend it herself, but only after significant timeout of say 1000 blocks; b) Bob can spend it himself, but only if he provides preimage of H2a i.e. S2a. Bob signs tx5 and sends it to Alice.
4) Alice sends Sa to Bob.
5) Bob sends Sb to Alice.
Now the channel is updated. If either party disappears, remaining party will receive his/her refund thanks to tx4 or tx5. But what prevents Alice from broadcasting tx3 which indirectly pays her 5 BTC, instead of her current share of 4 BTC? Tx3 doesn’t immediately pay 5 BTC to Alice, it immediately pays 5 BTC to Bob and creates o5 which Alice can redeem only after waiting 1000 blocks. But Bob now has Sa, and if he sees tx3 on the chain, he can immediately spend o5, because now he possesses Sa, thus taking all 10 BTC from the channel. Please note, that despite tx3 was created by Bob, his version of this transaction lacks Alice’s signature. Normally only tx1 is broadcast yet. This way the channel can be updated many times. After each update, only the last pair of transactions can be safely broadcast to close the channel and receive proper share of channel funds, because all previous secrets are known to respective counterparties.

You can read this series of articles. I learned this design from there.

I made bold part of the quote which is closely related to your concerns.

[franky1]

You only need ~70% of the hash to have a successful hard fork, so it is odd SegWit is pushed for more.

No. You need 95%.
A True Hard Fork only requires 70% , because you want enough hash to make sure the 30% can not 51% attack your new chain.  

ok clear the matter up.

at any majority. the orphan game will eventually sort it self out.
at a low majority say 55%. it might take a many blockheights where half is disagreeing and the orphan rate is say 65 blocks of 144 have a corresponding orphan..
headache nightmare .. headache nightmare .. headache nightmare
mining pools will be screaming. nodes will be syncing and losing sync.. bad for everyone.. but deemed temporary drama as eventually it leads to one chain and the minority left unsynced.
retailer merchant guidance: wait upto say 100 confirms before fully trusting a tx

at a low say 70%. it might take a many blockheights where a third is disagreeing and the orphan rate is say 42 blocks of 144 have a corresponding orphan..
blah blah same thing. a bit less screaming, but lots of crying still while the orphan drama sorts itself out
retailer merchant guidance: wait upto say 70 confirms before fully trusting a tx

at say 85%. it might take a few dozen blockheights where inder a quarter  is disagreeing and the orphan rate is say 20 blocks of 144 have a corresponding orphan..
blah blah same thing. not screaming, but not much crying while the orphan drama sorts itself out, but not happy
retailer merchant guidance: wait upto say 45 confirms before fully trusting a tx

at say 95%. it might take a a couple blockheights where a few is disagreeing and the orphan rate is say 7 blocks of 144 have a corresponding orphan..
not as bad and miners could live with a slight risk elevation compared to the usual 1-2% a day they usually put up with.
retailer merchant guidance: wait upto 10 confirms before fully trusting a tx

usual daily 1-2% risk advises waiting upto 6 confirms

[Lauda]

if they hold their 8% for 1 year from the segwit install date, Segwit Fails

Nope. They would get outhashed.

A True Hard Fork only requires 70% , because you want enough hash to make sure the 30% can not 51% attack your new chain.  

False. Requires 95% for any reasonable design.

You Nervous Nancies do realized that some ALTs hard fork 2 or 3 times a year with Zero Problems.
Comparing technical aspects of different crypto is not trolling , it is called Analyzing.

Nobody in their right mind gives a damn about some shitcoins hard forking 100 times a year.

I run a Blockchain snapshot Service, Multiple Coins Communities Trust Me , can you say the same?

That service is as useful as your trolling attempts.

If your BTC Devs had the Courage to Hard Fork SegWit, then it would have already been implemented or had already failed.

Hard forks are inherently dangerous in a widely deployed infrastructure (which no shitcoin, e.g. ZEIT, is).

[kiklo]

if they hold their 8% for 1 year from the segwit install date, Segwit Fails

Nope. They would get outhashed.

Rules say 95 % required for segwith soft fork, unless the others can hold 95% for 2 Weeks , it will fail.

A True Hard Fork only requires 70% , because you want enough hash to make sure the 30% can not 51% attack your new chain.  

False. Requires 95% for any reasonable design.

Ok, you're just being stupid now.
Reason they went with a pussy ass soft fork is they know the Chinese mining pools would block it now.
They are hoping enough public pressure comes that forces the Chinese mining pools to succumb to their will over the course of a year.
Again the Betting Pools are open.

You Nervous Nancies do realized that some ALTs hard fork 2 or 3 times a year with Zero Problems.
Comparing technical aspects of different crypto is not trolling , it is called Analyzing.

Nobody in their right mind gives a damn about some shitcoins hard forking 100 times a year.

Nobody gives a Damn , that BTC devs are too incompetent to pull off 1 Hard fork in a year.
You should just ask your self why all of the Alt devs you insult are more competent than your BTC devs.
But I can see Thinking is not something you are good at.    

I run a Blockchain snapshot Service, Multiple Coins Communities Trust Me , can you say the same?

That service is as useful as your trolling attempts.

People smarter than you appreciate it.

If your BTC Devs had the Courage to Hard Fork SegWit, then it would have already been implemented or had already failed.

Hard forks are inherently dangerous in a widely deployed infrastructure (which no shitcoin, e.g. ZEIT, is).

And there you go being a DumbAss,
ZEIT has had no hard forks in more than a year.
ZEIT has been Fully Operational, for going on 3 years. (No DownTime Junior)
ZEIT has 20X the Transaction Capacity of your BitCrap coin and requires no ASICS, so it is fair to all.

Eth hard forks every month,  maybe BTC devs should ask them for help.  

 

[kiklo]

Here is a Point for those that can think.

If segwit does actually manage to get activated.

And people use LN for the majority of their transactions, and stay off the Blockchain.

Do you think the mining pools have already figured out less transactions on the blockchain means less fees for them to collect.
Especially when they need to survive off of transaction fees only and no more BTC are created. Less than 5 Million BTC left to mine.
LN will take money out of the BTC miners pocket.  

 

[franky1]

You can read this series of articles. I learned this design from there.

I made bold part of the quote which is closely related to your concerns.

i see your failure.
1. outdated. may 2016
2. belief that alice and bob have separate(slightly differing) copies (um thats the opposite of the bidirectional buzzword)

in simple terms
its one transaction data they BOTH agree on and both treat as most relevant and both keep
EG (ignore the addresses they are random letters and numbers obviously)

Txid
In:3abcdeklmn987654321 val:5btc (originally A(X) deposit)
In:3abcdeklmn987654321 val:5btc (originally B(Y) deposit)
Out: 1abcdefghij123456789 val: 9btc (goes to A(X))
Out: 1klmnopqrs987654321 val: 1btc (goes to B)
Signature (A(X) signed inputs and output to agree)
Signature (B(Y) signed inputs and output to agree)
lock: now+9d23h58m

where they simply change the out values to who deserves what and then sign together to enforce it.
a tx wont get into a block without both signatures.
so both need to sign the same copy

thats the whole point of multisig. (buzzword bidirectional)

obviously with the out which goes to A can be a script that can halt A from being able to spend it straight after its confirmed
obviously with the out which goes to B can be a script that can halt B from being able to spend it straight after its confirmed

but its one transaction not 2 transactions.
its not about A holds one tx in their favour
its not about B holds one tx in their favour

they both hold the same relevant tx at the same time.

however if they keep a channel open that surpasses the locktime(onchain) set up when opening the channel EG
20 blocks after.. the malicious user can look at their LN history and grab a tx from the say 1-19 relevance ago. and that too would also now be relevant because they went passed the deadline.
which is the case not just for recent concepts but the outdated concept you dragged up from may2016

in your concept. there is a 1000CSV block delay even after its in the blockchain (much like blockreward coinbase tx has 100 block delay)
however the failure of that is simple.
your article says it

CSV, instead, uses relative time. Once a CVS-output is recorded on the blockchain, it takes a specific amount of blocks from that point on before the bitcoins can be spent again.

having a week CSV delay(1000 block) that can be interrupted by another person broadcasting a more relevant tx.. fails
because the LN outputs are already on the blockchain when alice (x in your other scenario) closed the channel.

also another fail is because although on the blockchain. it cant be spent untill it matures in a week. thus like banks... its not "available balance" which then is worse than Visa because visa settles in 2 days.

and by going by your scenario. during that week it can be "charged back" to bob (Y) going by your scenario

see the social issues with that.. funds not being spendable for days..and chargebacks possible!!

thats why other concepts are doing the opposite. having relevance time locks within LN to close a channel sooner and getting it broadcast sooner and simply opening a new channel if the 2 parties want to continue transacting

[franky1]

Here is a Point for those that can think.

If segwit does actually manage to get activated.

And people use LN for the majority of their transactions, and stay off the Blockchain.

Do you think the mining pools have already figured out less transactions on the blockchain means less fees for them to collect.
Especially when they need to survive off of transaction fees only and no more BTC are created. Less than 5 Million BTC left to mine.
LN will take money out of the BTC miners pocket.  

 

core devs dont care about bitcoin. they want everyone offchain so they can throw the onchain tx sky high to make people hate bitcoins blockchain.
then push people over to hyperledger..

core devs spend most of their time working on the hyperledger.. by core devs i mean the PAID devs.. not the 90 unpaid interns that just spellcheck the code.
pieter wuille - paid by blockstream - team leader segwit - also programs bankers hyperledger
Rusty Russel - paid by blockstream - team leader LN - also programs bankers hyperledger
matt corralo - paid by blockstream - main committer - also programs bankers hyperledger
greg maxwell- paid by blockstream - main committer - also programs bankers hyperledger

i could name more

[stdset]

however if they keep a channel open that surpasses the locktime(onchain) set up when opening the channel EG

No locktime is set onchain at the opening of the channel. o1 is just a plain 2 of 2 output without locktime or anything.

they both hold the same relevant tx at the same time.

No, they hold different txes, which however distribute funds in similar ways.
Let current channel state be: 9 BTC belong to Bob, 1 BTC to Alice.

Tx which Alice holds is created and  signed by Bob. It immediately pays 9 BTC to Bob, and creates a fancy 1 BTC output, which Alice can spend after 1000 blocks are mined on top of the block containing this output, or it can be spent immediately by Bob if he knows Alice's secret corresponding to current step.

Tx which Bob holds is created and signed by Alice. It immediately pays 1 BTC to Alice, and creates a fancy 9 BTC output, which Bob can spend after 1000 blocks are mined on top of the block containing this output, or it can be spent immediately by Alice if she knows Bob's secret corresponding to current step.

If Alice disappears, Bob publishes his tx. Alice gets her share immediately, Bob needs to wait 1000 blocks for that. If Bob disappears, Alice publishes her tx, Bob receives his 9 BTC immediately, Alice needs to wait 1000 blocks to be able to spend her share.

a tx wont get into a block without both signatures.
so both need to sign the same copy

Alice can sign her tx at any time and publish it, because it's already signed by Bob. Bob can sign his tx at any time and publish it, because it's already signed by Alice.

having a week CSV delay(1000 block) that can be interrupted by another person broadcasting a more relevant tx..

At this stage o1 - anchoring output is already spent, this is already onchain, there's no way to spend it another way. One of resulting outputs can only be spent by say Alice. Another output is also recorded on the chain, there no way to spend it except 2 ways defined by it's script.

and by going by your scenario. during that week it can be "charged back" to bob (Y) going by your scenario

no "charge backs" are possible

May be it's your design which is outdated. With this design, channels can indeed be kept open for arbitrarily long periods of time. There is essentially no limit on amount of back and forth transactions, unless they completely exhaust share of one of the parties. There is no risk of funds theft because of collusion of one of the parties with a miner.

[franky1]

lol

your article is out dated. its actually time stamped may 2016.

also even if you believe its current try reading it fully.. learn multisig.

Building Block #3: Multisig

have a nice day

[stdset]

learn multisig.

Read what is written in bold. Btw, you should be thankful that someone patiently explains this complex design to you. I had no such help.

I'm however grateful to Aaron van Wirdum for those great articles.