Bitcoin Forum

However, we can estimate Bitcoin mining power consumption in 12 years, provided that Bitcoin replaced all M1 money supply in the world, what is very unrealistic, but we want to make a conservative estimate. As of 2009 M1 was about 20*10¹²USD http://dont-tread-on.me/wp-content/uploads/2011/02/SmallGlobalMoneySupply.png
In 12 years block reward will be 8 times less than now, let's assume that fees still constitute a minor part of block reward, i.e. block reward is 3.125 BTC, that means 18.75 BTC created per hour. Value of 1 BTC equals roughly 1 million USD of 2009 purchasing power (in 2027 USD doesn't exist already, since BTC completely replaced it). Let's now assume, that miners spend half of their revenue to pay for electricity (that's rather unrealistic, but we want to make a conservative estimation), so we have 9.4*10⁶ USD per hour to pay for electricity. If we take a reasonable price of 0.07 USD/kWt*h, that results in 1.3*10¹¹ Watts of total power consumption by all miners in the world. In 2007 the world produced about 20*10¹⁵ Wt*h of electric power, or 2.3*10¹² Watts on the average. We can see that under such unrealistic conditions bitcoin mining consumes less than 6% of total world electric power.
Hope I didn't make a mistake in calculations.

BTW, we can conclude that even in 12 years Bitcoin is unlikely to replace all money in the world, since 6% of total electric power produced in the world is a bit much, I'd say that bitcoin will need not less than 16 years to achieve that  :)

BTC Transactions Congestion Problems   :-[

Simulation Example
each block has 1 MB of transactions with a theoretical Limit of 4200 transactions per block with a 10 minute BlockSpeed , [] is a block
One Hour of Blocks
[1] 10 minutes [1] 10 minutes [1] 10 minutes [1] 10 minutes [1] 10 minutes [1] 10 minutes
6 Blocks * 4200 Transactions =  25200 Maximum Theoretical Transactions per Hour

BTC Transactions Congestion Solutions   ;D

Simulation Example Updated with Larger BlockSize and Shorter BlockSpeed
each block has 2 MB of transactions with a theoretical Limit of 8400 transactions per block with a 2½ minute BlockSpeed , [] is a block
One Hour of Blocks
[2] 2½ minutes [2] 2½ minutes [2] 2½ minutes [2] 2½ minutes
[2] 2½ minutes [2] 2½ minutes [2] 2½ minutes [2] 2½ minutes
[2] 2½ minutes [2] 2½ minutes [2] 2½ minutes [2] 2½ minutes
[2] 2½ minutes [2] 2½ minutes [2] 2½ minutes [2] 2½ minutes
[2] 2½ minutes [2] 2½ minutes [2] 2½ minutes [2] 2½ minutes
[2] 2½ minutes [2] 2½ minutes [2] 2½ minutes [2] 2½ minutes

24 Blocks * 8400 Transactions = 201600 Maximum Theoretical Transactions per Hour

Compare Updated Simulation with Original
201600 / 25200  = 8
Updated Version can handle 8X the Transaction Capacity.  ;)

Now the educated asshats that live in these forums will tell you it can't work or it is a security risk, (They are Lying!)
Real World Examples.
PoW coin LTC has a 2½ minute block time with no problems whatsoever from it.
In Fact Chinese Mining Pools are over 51% of the BTC Hash rate , and are also over 51% of the LTC Hashrate.
In Fact some alts run at a 30 second blockspeed.
Oh, they also will complain, it will affect the Block Reward and Halving Dates,
(All of that are Variables that can be modified to compensate for the changes)

If they lower the Blockspeed,
then they will have to increase the Final Supply Number of Bitcoins or allow it to get to the Final Supply Number 4X faster than it would have.

If they only increase the BlockSize ,
then the Block rewards and halving dates are not affected, and will not need modification.
But Transactions grow will be directly proportional to the increase in BlockSize.
IE: 2 MB Block only Double the Transaction Capacity
     8 MB Blocks would increase by 8X also   

 8)

Instead, the mining pool favors a hard fork to remove the one megabyte block size limit, as proposed by Bitcoin Core fork Bitcoin Unlimited.

Using data pulled from their open source simulator of a proof-of-work blockchain (bitcoin and ethereum are two such blockchains), researchers from ETH Zürich argued that bitcoin could securely reduce its block time from 10 to 1 minute.

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

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

Yes, but Segwit increases the blocksize anyway. Which appears to be your point "blocksize needs an increase". Seems like a circular argument to me.

One of its many technical improvements is the ability to fit almost 2MB of transactions per block. Many estimates put the total block size, with SegWit, at about 1.7mb.

The Lightning Network’s Failure Mode

The Lightning Network failure scenario described by Todd, takes place when a large number of people on the Bitcoin network need to settle their Lightning Network disputes on the blockchain in a relatively short period of time.

https://bitcoinmagazine.com/articles/here-s-how-bitcoin-s-lightning-network-could-fail-1467736127
“We do have a failure mode which is: Imagine a whole bunch of these [settlements] have to happen at once,” Todd explained. “There’s only so much data that can go through the bitcoin network and if we had a large number of Lightning channels get closed out very rapidly, how are we going to get them all confirmed? At some point, you run out of capacity.”

In a scenario where a large number of people need to settle their Lightning contracts on the blockchain, the price for doing so could increase substantially as the available space in bitcoin blocks becomes sparse. “At some point some people start losing out because the cost is just higher than what they can afford,” Todd said. “If you have a very large percentage of the network using Lightning, potentially this cost is very high. Potentially, we could get this mass outbreak of failure.”

Hardforks don't depend on hashpower, you can hardfork off Bitcoin with 1% of hashpower, provided that your hardfork will include difficulty adjustment algo change (otherwise it will take forever to mine several hundreds of blocks for next difficulty adjustment).

If you don't care about users, who can miss your announcement, forget to upgrade their software, then indeed

Example:
BTC is the Foundation of Building
SegWit , the 1st floor, and LN the Skyscraper on top of it,
If BTC crumbles because it can't handle the stress, SegWit & LN are going to come crashing down on top of it.  :P

Nope,
Reason:
It has to be close to 70% to make sure your network is still secure, otherwise the other group can 51% attack you all day and block all transactions.

Make a Big Press Release , Call the Largest Mining Pools by Phone to confirm they are ready.
Trying to make out like a hard fork is so hard is BS, it is not.
Make some phone calls, send some email, or even broadcast a alert message out to all wallets, it ain't hard.

ETC is still alive despite they had maybe 10% of the prefork hashpower. Also, if your hardfork is such a minority fork, you can change PoW algo.

I doubt anyone wants to have wasted all of the money spent on ASICS.
Also for all you know they have more mining capacity of the other Algo too.
FYI: Message on Poloniex   (Safer with 70%)  ;)
ETC withdrawal and deposits are disabled due to network issues.
Posted by OldManKidd at 2016-11-24 02:04:11

Imagine a user who doesn't follow all this mess. He turns on his client say a month after the fork to receive a payment but receives worthless original chain coins. He won't be able to spend them, unless he finds somebody as unaware as he is.

That's why it's better to ponder the bigger blocks hardfork very well before implementing it. Bitcoin needs dynamic blocksize to be able to handle LN failure mode described in the article. There are some solutions proposed, for instance Meni Rosenfeld's (https://bitcointalk.org/index.php?topic=1078521.0).

I would not penalize the Miner that used the Larger Blocks, he is actually doing the network a better service.

it should be the miner that only adds a few transactions , because he basically wasted the capacity of that block when the queue transactions are over 2000.

Also for all you know they have more mining capacity of the other Algo too.

If Miners don't keep up with the updates , that is on them, you can not hold back an entire community because one guy won't watch the news or check an email.
Otherwise we all still be living in caves.[/color]

It's easy to DoS your Bitcoin then, especially if you are a miner. Just send tons of transactions to yourself, pay fees to yourself, make 20 GB blocks. Bloat the chain.
What if there are just few unconfirmed transactions around? Are you going to penalize a miner who includes them in a block?

What do you mean by "the other Algo"? I know many other algos, and much more could be "invented".
I guess you mentioned miners because the original chain needs to be mined, in order for our unaware user to receive the payment. You don't need many of them however, 1 block in several hours could be enough, users need not to be technical savvy.

I think if their are over 2000 transactions in a queue and the miner only mines a block with 1 transaction, yes I would penalize him for wasting capacity,
but that is not my call and just my personal opinion.

Majority of BTC users are letting someone else maintain their BTC wallets, the few that don't , will not lose anything if they are not mining.
(They will update when their old wallet does not work.)

More Transactions will take more space , no way around that.

That is why there should be a max cap on the size of the Block.

Isn't it time now to listen to each other, understand and come to a compromise?

IMO:
1) [...]Contentious hardfork isn't an option it would be disastrous.

I suspect that the majority of Bitcoin related companies wish to stay neutral in the scaling debate, and will not have a strong opinion one way or another, or at least not a strong public opinion.

As we saw with the ETH HF, many exchanges will likely support both branches of a HF to allow them to reap additional trading fees for trades between the two branches. There are however certain technical aspects of Bitcoin that will likely result in the failure of a minority branch of a HF that does not exist with ETH -- long difficulty recalculation time, long block maturity, and currently full blocks.

also, I do not think that I have seen any Bitcoin related company (with the exception of blockstream) that opposed any of the major HF proposals (XT/classic/BU/ect.) -- the only *real* opposition to any of XT/classic/Bu that I have seen has been from blockstream, and their employees, and the majority of the Bitcoin economy did show their support for XT (via their support for BIP101).

This stopped being a technical battle (and became a political battle) long ago.

What profit could core team derive from insisting on segwit acceptance without increasing blocksize?

Who can profit from deadlocking Bitcoin community in current state?
And (a rhetorical question) how many orders of magnitude of profit (how many zeros) could all parties gain from resolving this dispute one way or another?

A bank run (also known as a run on the bank) occurs when, in a fractional-reserve banking system (where banks normally only keep a small proportion of their assets as cash), a large number of customers withdraw cash from deposit accounts with a financial institution at the same time because they believe that the financial institution is, or might become, insolvent; and keep the cash or transfer into other assets, such as government bonds, precious metals or stones. When they transfer funds to another institution it may be characterised as a capital flight. As a bank run progresses, it generates its own momentum: as more people withdraw cash, the likelihood of default increases, triggering further withdrawals. This can destabilize the bank to the point where it runs out of cash and thus faces sudden bankruptcy.[1] To combat a bank run, a bank may limit how much cash each customer may withdraw, suspend withdrawals altogether, or promptly acquire more cash from other banks or from the central bank, besides other measures.

We live in a profit driven world, and politics is no exception.

Whether anyone believes it or not , LN will open the door to Fractional Reserve Banking with BTC.

But if the LN is deployed, it will almost certainly be based on a small number of big hubs.
These big hubs could mutiply the money in circulation in the same way that banks multiply the amount of dollar bills.
Namely, they would start issuing bitcoin IOUs and lend them to people, backed by a fractional reserve of bitcoins.
That is, the hub has 1000 actual BTC, but issues IOUs worth 5000 BTC.

The hubs would extend the LN protocol to let clients use those IOUs for payments (much as people today use checks and bank wires as equivalent alternatives to cash).
Clients would even be able to redeem the IOUs for real BTC; the hubs would be betting that only a small fraction of the clients would redeem at the same time.

If we could lower the capital requirement, we'd lower the barrier for
people wishing to run a Lightning Network node.

Here are some thoughts:
   - The trust-based system you're proposing looks like a
   fractional-reserve banking system.
   - Such fractional-reserve hubs will provide lower transaction fees
   (because of lower capital requirements) — so the idea is worth pursuing.

for instance, if you are a large hub, with lots of capital but with many many connections to individual users and businesses, this means that everyone would want to route payments through you because less hops means less fees. If you had to open up channels by putting matching amounts of your money in with every other user, then this would be a limiting factor. (as you would have to have 100% reserve amounts for all your channels) and inefficient as a whole as the network would require 2 dollars locked up in order to send every 1 dollar.

Instead you only open up channels where the depositor puts in funds. The hub then credits their account balance with that amount. When they are paid money by other parties, the hub just increases the balance by that amount, they don’t actually move the money through a LN channel. This can be done as long as the payee is also another client of the same hub. When a client wants to withdraw, only then do they open up a withdraw LN channel to the client which they can pull money back out. This way the hub only locks up their own funds only when clients withdraw, which most of the time, will be minimal as long as people continue to use the same hub.

When a hub grows large enough, it will start opening bidirectional channels to other large hubs. If they trust each other enough, then they start crediting each other in IOUs instead of real payment channels.
You can end up with a fractional banking system existing as long as hubs trust each other to make good on their promises to pay each other back, and no crisis of confidence happens that causes a bank run.

This is a commentary which should never have needed to be written.
What is euphemistically called “fractional-reserve banking” is obvious fraud, and obvious crime.
By its very definition, it transforms the banking sector of an economy into a leveraged Ponzi-scheme, and as with all Ponzi-schemes, there is no possible “happy ending” here.

Fractional-reserve banking evolved literally based upon the temptation of all bankers to perpetrate fraud.
Empirically it has always been observed, down through the centuries, that under normal circumstances, only a tiny percentage of depositors will come to claim their cash/wealth at any one time.
Thus the temptation is for bankers to “lend” more funds than they actually possess, i.e. they are “lending” what does not even exist: “fractional-reserve banking” – the ultimate euphemism of banking and fraud.

It goes without saying that anyone or any entity which endeavours to “lend” something which does not exist is perpetrating fraud.
But before examining this inherent fraud more closely, it is important to back-up, and look at the Law.
Note that even when banks “lend” the money which they actually do hold on deposit (as trustees for the depositors) that this is already wholly/totally illegal.
It is the crime known as“conversion”.

Criminal conversion:
A person who knowingly or intentionally exerts unauthorized control over property of another person commits criminal conversion.

When your bank lends-out money you deposited, which it claims to be “holding” for you as trustee, does it seek your prior authorization before lending-out your property and thus putting it at risk? Of course not. The banks get around the naked criminality of their lending operations through general authorization. In the small-print of any/all bank deposit contracts is a clause whereby the depositor “authorizes” the bank to lend-out their property to Third Parties.

But if the LN is deployed, it will almost certainly be based on a small number of big hubs.
These big hubs could mutiply the money in circulation in the same way that banks multiply the amount of dollar bills.
Namely, they would start issuing bitcoin IOUs and lend them to people, backed by a fractional reserve of bitcoins.
That is, the hub has 1000 actual BTC, but issues IOUs worth 5000 BTC.

The hubs would extend the LN protocol to let clients use those IOUs for payments (much as people today use checks and bank wires as equivalent alternatives to cash).
Clients would even be able to redeem the IOUs for real BTC; the hubs would be betting that only a small fraction of the clients would redeem at the same time.

Elaborate please. How exactly a hub could start issuing IOUs on LN? Don't be afraid to go deep in technical details. Your links lead to questions from technical unsavvy users, which are afraid of LN because they don't understand how it works.

Scalability.
The bitcoin network will need to support orders of magnitude higher transaction volume to meet demand
from automated payments. The coming increase in internet-connected devices needs a platform for
machine-to-machine payments and automated micropayment services.
Lightning Network transactions are conducted off the blockchain without delegation of trust and ownership, allowing users to conduct nearly unlimited transactions
between other devices

You Do understand that LN is offchain?
So whatever tokens is transferred around on LN is not really BTC.

Do you understand, that micropayment channels of which LN consists are opened by broadcasting an onchain transaction that locks BTC in the channel? So BTC transfered over LN are very real.
Moreover, LN requires users to freeze a lot of funds in channels. To be able to use a channel one needs to freeze much greater amount of funds than each payment. Therefore it's quite the opposite to fractional reserve banking.

So BTC transfered over LN are very real.

Geez ,

Bidirectional payment channel.

Opening the channel.
1) Alice and Bob create transaction tx1 which sends 5 BTC from Alice and 5 BTC from Bob to a multisignature 2of2 output o1, neither party signs this transaction yet.
2) Alice and Bob create secrets Sa and Sb, and exchange hashes of those secrets (Ha and Hb): Ha goes to Bob, Hb goes to Alice. Alice and Bob will need those hashes to create transactions tx2 and tx3 at steps 3 and 4.
3) Alice creates transaction tx2 which spends o1 and creates 2 new outputs: 5 BTC go Alice (o2), 5 BTC go to output o3, 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 Hb i.e. Sb. Alice signs tx2 and sends it to Bob.
4) Bob creates transaction tx3 which spends o1 and creates 2 new outputs: 5 BTC go to Bob (o4), 5 BTC go to output o5, 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 Ha i.e. Sa. Bob signs tx3 and sends it to Alice.
5) tx1 is signed, broadcast and confirmed.
The channel now is considered open. 5 BTC from Alice and 5 BTC from Bob are now locked in output o1. Both parties however are safe. If Alice disappears, Bob only needs to sign and broadcast tx2 (Alice already signed it), then wait some time, and get his refund from o3. If Bob disappears, Alice can do the same thanks to tx3. Under normal circumstances tx2 and tx3 aren’t broadcast.


Updating the channel (conducting payments).
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.


Closing the channel.
Both parties know, that they can’t cheat each other. So when they decide to close the channel, one of them (let it be Alice) creates a transaction that spends o1 according to the latest state of the channel, signs it, and sends to Bob. He checks that funds are split fairly, signs it and broadcasts it. This transaction is the second and the last to hit the chain, for the whole lifetime of the channel.

Now seriously. Not only you don't understand how LN is supposed to work. It's OK to not understand it. Even among cryptocurrency enthusiasts most people don't understand it.
But do you believe that so many people (including cryptocurrency experts) are so stupid, that they can't distinguish IOUs from BTC?

if your Delusion was true , then why don't we just shut down the entire BTC network and move all of the BTC to LN and only use LN for everything.

It's clear from the protocol which you apparently don't even try reading, that LN needs onchain transactions, it can't work without them. Normally each channel produces 2 onchain transactions during it's whole lifetime.

If you use LN and think it is anything more than a representative trade value of BTC / IOU for BTC, then you are stupid.  ;)

Let me put it this way , the BTC network itself is an energy waster due to ASICS,
if your Delusion was true , then why don't we just shut down the entire BTC network and move all of the BTC to LN and only use LN for everything.
That way we don't even need the miners.

Reason why that won't happen.
1.  BTC never actually leaves the blockchain, (Notice they use the word Frozen or Locked On the blockchain)
2.  BTC design makes sure no one can counterfeit coins or run a fractional reserve from the BlockChain.
3.  LN network design requires that you trust their network, not to counterfeit coins and not to work as a fractional reserve
4.  If we could trust everyone then we would not need BTC, but sadly enough people are untrustworthy that they will take advantage of others.

LN=Bank
Wishin & Hopin & Prayin it is not true , won't make a difference.
Sorry no way around it.

There's a problem with your argument. Do you know what it is?

LN is Offchain Transactions ,

Whether anyone believes it or not , LN will open the door to Fractional Reserve Banking with BTC.

It's clear from the protocol which you apparently don't even try reading, that LN needs onchain transactions, it can't work without them. Normally each channel produces 2 onchain transactions during it's whole lifetime.

then why don't we just shut down the entire BTC network and move all of the BTC to LN and only use LN for everything.

You can not use BTC not confirmed on LN.

It's not a fractionnal Reserve Banking, because ... at the end of the 10 minutes or LESS, all transactions (with 0-null movment) must be forward to the Bitcoin regular network.

If you have move 100 time your BTC in the LN and lost 10% = at the end of the 10 minutes, you LOOSE 10% on the Bitcoin network.

That's why the Fees of LN is not cheap (for the LN provider) ... because the LN must be withdrawn at the end with the most priority.

You can not use BTC not confirmed on LN.

It's not a fractionnal Reserve Banking, because ... at the end of the 10 minutes or LESS, all transactions (with 0-null movment) must be forward to the Bitcoin regular network.

If we could lower the capital requirement, we'd lower the barrier for
people wishing to run a Lightning Network node.

Here are some thoughts:
   - The trust-based system you're proposing looks like a
   fractional-reserve banking system.
   - Such fractional-reserve hubs will provide lower transaction fees
   (because of lower capital requirements) — so the idea is worth pursuing.

That's why the Fees of LN is not cheap (for the LN provider) ... because the LN must be withdrawn at the end with the most priority.

This should be good , show off that imagined superiority complex you got going for you.  ;)
Waiting to be dazzled.

Here it is: what if people reading your posts actually go out and research and understand the Lightning Network? They're going to realise you're talking out of your ass.

My post was a great deal more factual than what you're spouting, and that was my intention, because you are talking nonsense. I notice that you're trying to be witty, however. With your Game of Thrones memes.

rofl'ing, hard. Of course I don't know what ridiculous television memes you use, that was the purpose of the comment :D I've never even seen Game of Thrones, "do you watch game of Thrones" typically elicits my response "I'll be right back..."

is there not some way of operating a demo lightning network either by the testnet or other means that finally puts all this crap to bed? the proof would be in the pudding.

i know there are papers and the occasional youtube video. it would be a whole lot more compelling if anyone could log into to something and experiment.

EG
in a channel between X,Y they deposit 10 publicly on the blockchain to open the channel
X and Y 'spend' the 10 to another active channel user Z
asking Z to not use LN but to use Z's onchain balance address to pay 4.9 each to X,Y ONCHAIN and Z keep the 10 offchain, to spend later


X: i have control of 10 in LN, i have 4.9 personally ONCHAIN too. this is my 14.9 collateral. i can sign a message to my personal 4.9 and a message as part of the LN 10.
now give me a government grant,VC money up to 14.8

Y: i have control of 10 in LN, i have 4.9 personally ONCHAIN too. this is my 14.9  collateral. i can sign a message to my personal 4.9 and a message as part of the LN 10.
now give me a government grant,VC money up to 14.8

they receive VC funding to 29.6btc. where infact X, Y have ZERO LN collateral. and only 9.8 personal collateral.

fractional reserve is not just about money CREATION like (CB) thinks. its also about faking collateral you don't have or moving funds around, to profit from something that you dont have

now lets get back ontopic of scaling bitcoin

is there not some way of operating a demo lightning network either by the testnet or other means that finally puts all this crap to bed? the proof would be in the pudding.

i know there are papers and the occasional youtube video. it would be a whole lot more compelling if anyone could log into to something and experiment.

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.

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

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

now lets get back ontopic of scaling bitcoin

if we went with LN's rhetoric of never needing to close channels.. then bitcoins mainnet is never needed once funds are deposited.

rationally LN should regularly close channels.

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

I would imagine it would be to periodically force an audit the value of the coins in the channel by closing out the books, thus making sure no extra LN coins have been created out of thin air. There should be better ways to do this, though.

I would imagine it would be to periodically force an audit the value of the coins in the channel by closing out the books, thus making sure no extra LN coins have been created out of thin air. There should be better ways to do this, though.

Mainnet is still needed, even if channels never closed, because without possibility of emergency closing, channels effectively lose state. It's like nuclear deterrence. Nuclear weapons have great impact on international relations, even though never used.

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

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.

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

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

simple illustration
https://i.imgur.com/40YRxbl.png

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.

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

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

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!

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


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.


 8)

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  (https://bitcointalk.org/index.php?topic=1378653.msg14024451#msg14024451)

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.

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.

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.

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

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

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

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.

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

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

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.

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.



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

That service is as useful as your trolling attempts.

People smarter than you appreciate it.

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

You can read this series of articles (https://bitcoinmagazine.com/articles/understanding-the-lightning-network-part-building-a-bidirectional-payment-channel-1464710791). I learned this design from there.

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

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.

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

 8)

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

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

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

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

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

Building Block #3: Multisig

learn multisig.

Another output is also recorded on the chain, there no way to spend it except 2 ways defined by it's script.

no "charge backs" are possible

you literally talk about a chargeback method where bob can get funds destined for alice, then suddenly say its impossible

That's not chargebacks, but punishment for theft attempt. One party takes all funds from the channel only if another party tries to use an outdated state to steal funds.

a system where the other person can trick the system and chargeback in that week........ = same as visa - worse than wire transfer

a system where funds are locked for a week after settling. where they cant be spent....... = worse then merchants/customers get from accepting visa/paypal

Closing the channel.
Both parties know, that they can’t cheat each other. So when they decide to close the channel, one of them (let it be Alice) creates a transaction that spends o1 according to the latest state of the channel, signs it, and sends to Bob. He checks that funds are split fairly, signs it and broadcasts it. This transaction is the second and the last to hit the chain, for the whole lifetime of the channel.

Show, how the system can be tricked.

step 1: two people communicate together and agree to open a multisig to start a channel.

step 2: they both independently fund the multisig with their amounts. ONCHAIN.

step 3: they agree to the terms of who owes what. initially agreeing to whatever they deposit they get back.
hint 1: the funds cannot be spent in a multisig without both signatures
TXID:AB3
In:3abcdeklmn987654321 val:5btc (originally A(X) deposit)
In:3abcdeklmn987654321 val:5btc (originally B(Y) deposit)
Out script1: if relevant(1abcdefghij123456789 A(X) val: 5btc); if irrelevant(1klmnopqrs987654321 B(Y) val: 5btc)
Out script2: if relevant(1klmnopqrs987654321 B(Y) val: 5btc); if irrelevant(1abcdefghij123456789 A(X) val: 5btc)

maturity 1000 blocks

step 4: and both sign the same tx data.
hint 1: the funds cannot be spent in a multisig without both signatures
TXID:AB3
In:3abcdeklmn987654321 val:5btc (originally A(X) deposit)
In:3abcdeklmn987654321 val:5btc (originally B(Y) deposit)
Out script1: if relevant(1abcdefghij123456789 A(X) val: 5btc); if irrelevant(1klmnopqrs987654321 B(Y) val: 5btc)
Out script2: if relevant(1klmnopqrs987654321 B(Y) val: 5btc); if irrelevant(1abcdefghij123456789 A(X) val: 5btc)
Signature (A(X) signed inputs and output to agree)
Signature (B(Y) signed inputs and output to agree)
maturity 1000 blocks

step 5: B(Y) decides to give A(X) say 4BTC, they agree and they BOTH SIGN
hint 1: the funds cannot be spent in a multisig without both signatures
hint 2: both signing = both seeing a copy to be able to sign
hint 2: they both agree there should be a harsh penalty rather then getting what they deposited back
hint 2: in your scenario they now decide to not having matching data. but both sign each others tweaked tx data

A(X) creates and signs this. making A(X) lose out if not moral
TXID:A5
In:3abcdeklmn987654321 val:5btc (originally A(X) deposit)
In:3abcdeklmn987654321 val:5btc (originally B(Y) deposit)
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)
Signature (A(X) signed inputs and output to agree)
maturity 1000 blocks

B(Y) creates and signs this. making B(Y) lose out if not moral
TXID:B5
In:3abcdeklmn987654321 val:5btc (originally A(X) deposit)
In:3abcdeklmn987654321 val:5btc (originally B(Y) deposit)
Out script1: if relevant(1abcdefghij123456789 A(X) val: 9btc); if irrelevant(1klmnopqrs987654321 B(Y) val: 0btc)
Out script2: if relevant(1klmnopqrs987654321 B(Y) val: 1btc); if irrelevant(1abcdefghij123456789 A(X) val: 10btc)
Signature (B(Y) signed inputs and output to agree)
maturity 1000 blocks

step 6: they both hand eachother a copy and sign their counterparts version
hint 1: the funds cannot be spent in a multisig without both signatures
hint 2: both signing = both seeing a copy to be able to sign
hint 3: doing this invalidates previous TX (step 4)

A(X) created, now B(Y) signs, B(X) KEEPS aswell as the other one below
TXID:A6
In:3abcdeklmn987654321 val:5btc (originally A(X) deposit)
In:3abcdeklmn987654321 val:5btc (originally B(Y) deposit)
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)
Signature (A(X) signed inputs and output to agree)
Signature (B(Y) signed inputs and output to agree)
maturity 1000 blocks

B(Y) created, now A(X) signs
TXID:B6
In:3abcdeklmn987654321 val:5btc (originally A(X) deposit)
In:3abcdeklmn987654321 val:5btc (originally B(Y) deposit)
Out script1: if relevant(1abcdefghij123456789 A(X) val: 9btc); if irrelevant(1klmnopqrs987654321 B(Y) val: 0btc)
Out script2: if relevant(1klmnopqrs987654321 B(Y) val: 1btc); if irrelevant(1abcdefghij123456789 A(X) val: 10btc)
Signature (A(X) signed inputs and output to agree)
Signature (B(Y) signed inputs and output to agree)
maturity 1000 blocks

step 7: many many many trades like steps 5,6 happen where values change hands.. making previous txs irrelevant
hint 1: the funds cannot be spent in a multisig without both signatures
hint 2: both signing = both seeing a copy to be able to sign
hint 3: doing this invalidates previous TX
lets say they are at TXID:A200   TXID:B200 making A4-199  and B4-199irrelevant

step 8: B(Y) kept A6 (step 6), initially you think thats crazy right. but B(Y) broadcasts it

step 9: B(Y) lets it get confirmed

step 10: B(Y) uses the revoke code on the A6 Out script1 to then make the output spendable to him instantly before maturity expires

9    Risks
The primary risks relate to timelock expiration.  Additionally, for core nodes
and possibly some merchants to be able to route funds, the keys must be
held online for lower latency.  However, end-users and nodes are able to keep
their private keys  rewalled o  in cold storage.
9.1    Improper Timelocks
Participants must choose timelocks with suffcient amounts of time.
If insuffcient time is given, it is possible that timelocked transactions believed to
be invalid will become valid, enabling coin theft by the counterparty.
There is a trade-off  between longer timelocks and the time-value of money.
When writing wallet and Lightning Network application software, it is necessary
to ensure that suffcient time is given and users are able to have their trans-actions
enter into the blockchain when interacting with non-cooperative or malicious channel counterparties.

9.2    Forced Expiration Spam
Forced expiration of many transactions may be the greatest systemic risk when using the Lightning Network.  
If a malicious participant creates many channels and forces them all to expire at once, these may overwhelm block data capacity,
forcing expiration and broadcast to the blockchain.  The re-sult  would  be  mass  spam  on  the  bitcoin  network.  
The  spam  may  delay transactions to the point where other locktimed transactions become valid.
This may be mitigated by permitting one transaction replacement on
all  pending  transactions.   Anti-spam  can  be  used  by  permitting  only  one
transaction replacement of a higher sequence number by the inverse of an
even or odd number.  For example, if an odd sequence number was broad-
cast, permit a replacement to a higher even number only once.  Transactions
would use the sequence number in an orderly way to replace other trans-
actions.   This  mitigates  the  risk  assuming  honest  miners.
 This attack  is extremely  high  risk,  as  incorrect  broadcast  of  Commitment  Transactions entail a full penalty of all funds in the channel.
Additionally,
one may attempt to steal HTLC transactions by forcing a timeout transaction to go through when it should not.
This can be easily mitigated by having each transfer inside the channel be lower than the total
transaction fees used.  Since transactions are extremely cheap and do not
hit the blockchain with cooperative channel counterparties, large transfers
of value can be split into many small transfers.  This attempt can only work
if  the  blocks  are  completely  full  for  a  long  time.   While  it  is  possible  to
mitigate it using a longer HTLC timeout duration, variable block sizes may
become common, which may need mitigations.
If this type of transaction becomes the dominant form of transactions which are included on the blockchain,
it may become necessary to increase the  block  size  and  run  a  variable  blocksize  structure  and  timestop   ags as described in the section below.
This can create suffcient penalties and
disincentives  to  be  highly  unpro table  and  unsuccessful  for  attackers,  as
attackers lose all their funds from broadcasting the wrong transaction,  to
the point where it will never occur.

9.4    Data Loss
When one party loses data, it is possible for the counterparty to steal funds.
This can be mitigated by having a third party data storage service where
encrypted data gets sent to this third party service which the party cannot
decrypt.   Additionally,  one  should  choose  channel  counterparties  who  are
responsible  and  willing  to  provide  the  current  state,  with  some  periodic
tests of honesty.
9.5    Forgetting to Broadcast the Transaction in Time
If one does not broadcast a transaction at the correct time, the counterparty may steal funds.
This can be mitigated by having a designated third party
to send funds.  An output fee can be added to create an incentive for this
third party to watch the network.  Further,  this can also be mitigated by
implementing OP CHECKSEQUENCEVERIFY

10    Block Size Increases and Consensus
If we presume that a decentralized payment network exists and one user will
make  3  blockchain  transactions  per  year  on  average,  Bitcoin  will  be  able
to  support  over  35  million  users  with  1MB  blocks  in  ideal  circumstances
(assuming 2000 transactions/MB, or 500 bytes/Tx).

This is quite limited, and an increase of the block size may be necessary to support everyone in the world using Bitcoin.
A simple increase of the block size would be a hard fork,  meaning  all  nodes  will  need  to  update  their  wallets  if  they  wish  to
participate in the network with the larger blocks.

While it may appear as though this system will mitigate the block size increases in the short term,
if it achieves global scale, it will necessitate a block size increase in the long term.

 8)

FYI: LN means Snidely Whiplash Wins.  :P
http://cdn.quotesgram.com/small/64/28/449675158-922864_10151667671914602_1694026713_n_1_1024x1024.jpeg

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

Out script2: if relevant(1klmnopqrs987654321 B(Y) val: 1btc); if irrelevant(1abcdefghij123456789 A(X) val: 0btc)

We will never achieve full consensus.

Somewhy you fail to understand, that both parties sign the same commitment transactions before they can be broadcast.

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.

Y can't broadcast that transaction because he doesn't have it. He instead has another transaction corresponding to the same state,

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?

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

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

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

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

so i combined A(X) lets call her alice xavier..

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.

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

however if you read the stuff core and LN devs are saying. they are overselling LN as a system where channels never need to close.