Lightning Network Observer

[BlackHatCoiner]

your phone wallet does not check integrity. especially if phone wallet is made by the service that told you to download their prefered wallet

If it's a custodial wallet, it is designed to not check for integrity. Non-custodial wallets do that. You know that there are non-custodial mobile lightning wallets, right?

if YOU broadcast and see that instead of your preseumed (1,000,000msat) 1,000sat you only got 10sat.. you cannot penalise a bbroadcast you sent.

Yes, you can. Again, if you used a non-custodial wallet. For custodial, there's faith required.

oh you also have to be online to spot their broadcast. and then use THEIR WALLET app to hope you have a state somewhere that can penalise them..

You're not that dumb franky. I refuse to believe. You just want to make a point, and are run out of arguments.

[1714231705]

1714231705

[franky1]

now im hearing word of "faith" and "trust"

one more time because your ignoring it

lets step away from the phone app custodian you and bet to the NODE scenery..

if YOU press the close channel button to broadcast YOUR copy. your broadcast would have a bad value because you were unable to read the state before the broadcast.

but because its YOUR broadcast. you cannot penalise yourself to get all the funds back to you.. however they can

because your broadcast contains a revoke key for which thy can use to revoke from you

the point of penalties is not to penalise yourself to win everything before the other..
that not how the penalties

..
oh and my examples of flaws. are not the limit of the flaws. they are the introduction of using simple examples to atleast give you a step to move forward from ..   of many flaws. which because you keep tripping up not wanting to understand the first stage its hard to progress the observations when i have to keep circling your holes and pulling you out only for you to fall into again head first, like someone that fears the light

[BlackHatCoiner]

now im hearing word of "faith" and "trust"

Now you're being even more obtusely ironic, because it's well known what custodial and non-custodial means.

lets step away from the phone app custodian you and bet to the NODE scenery..

Okay, so now we go to the non-custodial part?

if YOU press the close channel button to broadcast YOUR copy. your broadcast would have a bad value because you were unable to read the state before the broadcast.

Except that I have every channel state that has happened before. My closing transaction would indicate that I want to put an end at the current, non-revoked channel state. My partner can do nothing about it, because we've agreed that he could have only acquired both funds if I published a revoked channel state. At worse, he can refuse to sign it, and have me withdraw the funds in a non-cooperative manner.

because your broadcast contains a revoke key for which thy can use to revoke from you

My broadcasted transaction contains a revocation public key, whose private is only known by me, unless I've revoked the channel state and revealed the per_commitment_secret to my partner. In that case, he can work out the revocation private key, and establish a penalty.

[franky1]

you have every state??
seems you have gone back in your hole and forgot the whole idea of LN and its flaws mentioned in many posts..

yea.. tell that to someone that is using thor turbo or a phone app with their own key but just not full node access.. where the app is wrote by a malicious dev

oh wait they cant broadcast anything because:
either:  they cant spend . because .. guess what. they dont have a OTXO backing the input
or: cant find the state because "not for humans to read"

heck you again forgot the conversation about the states...

so lets reign it back into the other examples
a. IF say thor turbo changed mSatScale uint64 = 1000 to 1,000,000*
you wont get the amount you were promised
but also
b. they can set it up that because ur using their software. they can do many things
c. they can just do their 0 confirm trick
d. the state if you could find one would be in their favour
e. a multitude of other flaws you are not ready to understand

also
for instance imagine the channel balance is supposed to be:
you 1,000,000msat other party 1.000,000msat

where on screen display it looks like you have 1,000,000msat. but in the state you only have *1sat

you wont know about it until you broadcast.

and your revoke is not to grab what you think it is grabbing because what your broadcasting is different to what they can

..
put it short..
if they had a revoke for their own broadcast to claim everything.. they can steal it all too..

revokes are not for your broadcast for you to use on your own broadcast to steal everything in your broadcast. because thats just theft

 its for a key you hold.. for a output on their contract they could broadcast which if they broadcast you can penalise.

[n0nce]

3. same goes for the 1:1000 rate
you HOPE its a 1:1000 rate but you dont find out until you are trying to settle.

Nah, you find out by checking the code. The wallet code would need to be modified to use a different multiplier when checking the other peer's side of the channel opening. I'm not aware of anyone having attempted this so far, but it would be really interesting if you have a source to indicate otherwise!
I hadn't thought of this attack, even though you must acknowledge it's an implementation attack / malicious wallet and not a flaw in Lightning.

It's as if I distributed a Bitcoin L1 wallet which shows balances 10x higher and pay you 10$ instead of 100$, and then you hand me over an item that's worth 100$.

i know you pretend that everyone reviews code and then has some command line to then search for raw data and read the content to see their msat balance amount is fair rated to their state commitment amount at 1:1000 rate.. but people dont do that. especially your niche userbase you are trying to recruit that are just phone app users.

Code has to be checked; for sure. No matter if L1 or L2. Only difference on L1 is that you can check on some block explorers, but the demographic you're talking about don't do that, either.
That's why I always recommend sticking to 'tried and tested' open-source wallets (i.e. someone else has checked the code) and encourage making sure through sites like https://walletscrutiny.com/ that the binaries actually match the code.

you lot are the ones not thinking with open minds. you cant even want  to admit that LN has flaws.

We do, we do. Just read in this thread. It was repeated over and over again that it has different drawbacks (including risks) and different advantages over L1.

all you lot dream about is everyone floods into use LN and then go to sleep so you can raid their funds.
you lot never seem to have the risk awareness mindset as if you care about protecting the users you want to grab and pull into your silly subnetwork

Oh wow now you're accusing us of trying to steal from people? Two things: (1) it is only possible with channel partners; never have we encouraged people to open channels with us. Generally there's very little talk about who to open channels with and there is nobody actively trying to get as many channels with newbies as possible, from what I can tell. (2) lock times are a thing; 'over night' is more a saying than a definitive duration required for such an attack.

4. LN does not have mechanisms to weed out bad actors using non backed channels or where states are abused by changing the 1:1000 by changing it to say 1:10 on their outbound amount designated for their victim partner they want to cheat.. again a service can do this and the network has no security to prevent it

Again, the victim's software client would also have to have been altered to accept such a closing transaction. This makes the attack scope equal as trying to get someone to accept your Bitcoin L1 transaction by giving them a hacked client which shows all amounts x10.

now to n0nce:
as for you thinking there is no 1:1000 rate and its just some rounding thing where only 1 sat can be lost

https://github.com/lightningnetwork/lnd/blob/master/lnwire/msat.go#L12
here the 1000 rate.. and look how its used alot to convert msat to sat.. which you are avoiding reading and understanding
yes n0nce you showed L19 of same github of a COMMENT misinforming. but you never cared to see the CODE or read the entire thing ^{[that's an assumption you just made up! you don't know if I read it or not.]}

the mSatScale uint64 = 1000
is not the same as "if <1000 then 0"

The code that does this is actually in line 43.

Code: (https://github.com/lightningnetwork/lnd/blob/master/lnwire/msat.go#L43)

uint64(m) / mSatScale

The / in Golang divides and just cuts the rest (i.e. rounding down). See in this example. I basically converted 9,999msat with the same code used in lnd and it was automagically rounded down to 9sat.

if you truly understood all the code in its context and not just the comment sections. you would understand the rounding mechanism. and the scale ratio conversion mechanism are different
if you can only read comments in code and not the code itself..
try this one
https://github.com/lightningnetwork/lnd/blob/master/lnwire/msat.go#L40

I do write and read code, don't worry. I picked the comment because it was easy for everyone to understand and the code was right beneath it. I just explained you the code snippet from L40 onwards; it calculates sats from msats, just like I have been describing all along.

All through the magic power of the / operator. Explained here in golang docs.

x / y truncated towards zero

where the app is wrote by a malicious dev

This must be the worst argument I've ever heard. Of course a malicious wallet can scam you. Just like a malicious L1 wallet, like a malicious banking app or a malicious faked Bitcointalk login page.

[franky1]

3. same goes for the 1:1000 rate
you HOPE its a 1:1000 rate but you dont find out until you are trying to settle.

Nah, you find out by checking the code. The wallet code would need to be modified to use a different multiplier when checking the other peer's side of the channel opening. I'm not aware of anyone having attempted this so far, but it would be really interesting if you have a source to indicate otherwise!
I hadn't thought of this attack, even though you must acknowledge it's an implementation attack / malicious wallet and not a flaw in Lightning.

its a implementation which the network cannot secure against... because there is no consensus

is like your saying..
because there is no road network safety(highway code) its not a road network safety problem its a driver problem

remember no one was calling out the thor turbo as a flaw... shows how great the review process was..

and no dont go playing dumb ignorant and deceptive to say that it will only affect one user if it was applied. we already see thor turbo and they had many users.

and no its not as if whatever silly bitcoin mainnet scenario you tried to pull

bitcoin nodes actually have integrity checks and things like RBF and many other things. lus there is no co-sign both balance system in bitcoin
its just a you want my goods pay me $100 if i only receive $10 confirmed you dont get the goods until tyou send me the other $90

..
in LN payments of msat are sent meaning you think you got paid 1,000,000msat..  you hand goods over. and month later at broadcast realise you only got 1sat

now to n0nce:
as for you thinking there is no 1:1000 rate and its just some rounding thing where only 1 sat can be lost

https://github.com/lightningnetwork/lnd/blob/master/lnwire/msat.go#L12
here the 1000 rate..

The / in Golang divides and just cuts the rest

so now you admit the 2 part process.. divide(convert) and cut)round)
now this whole conversation has been about the red divide part not your blue cut/round.. got it?

if you truly understood all the code in its context and not just the comment sections. you would understand the rounding mechanism. and the scale ratio conversion mechanism are different
if you can only read comments in code and not the code itself..
try this one
https://github.com/lightningnetwork/lnd/blob/master/lnwire/msat.go#L40

I do write and read code, don't worry. I picked the comment because it was easy for everyone to understand and the code was right beneath it. I just explained you the code snippet from L40 onwards; it calculates sats from msats, just like I have been describing all along.

no you have been obsessing about rounding not the 1:1000 rate of the converting.. but now you have caught up with the conversation.. dont step backwards

where the app is wrote by a malicious dev

This must be the worst argument I've ever heard. Of course a malicious wallet can scam you. Just like a malicious L1 wallet, like a malicious banking app or a malicious faked Bitcointalk login page.

the scenarios are different and you know it

by not being settled up when you sell a product. the person can give you fake msats in a multitude of ways that never flourish into being real sats .. and you wont know it for the usual x months you dont want people broadcasting for.. because you wont want the broadcasting every payment just to check every payment. as thats a sillty thing to do

however in bitcoin if i get bitcoin i know i got bitocin via a multitude of ways. its settled and i can see its settled so then i can release the goods knowing i been paid in full

[n0nce]

3. same goes for the 1:1000 rate
you HOPE its a 1:1000 rate but you dont find out until you are trying to settle.

Nah, you find out by checking the code. The wallet code would need to be modified to use a different multiplier when checking the other peer's side of the channel opening. I'm not aware of anyone having attempted this so far, but it would be really interesting if you have a source to indicate otherwise!
I hadn't thought of this attack, even though you must acknowledge it's an implementation attack / malicious wallet and not a flaw in Lightning.

its a implimentation which the network cannot secure against...

The network won't save you against a malicious L1 wallet that shows wrong (even made-up) balances, either! You have to make sure you're not running a fake wallet. Either way. L1 or L2. Doesn't matter.

and no its not as if whatever silly bitcoin mainnet scenario you tried to pull

bitcoin nodes actually have integrity checks and things like RBF and many other things. lus there is no co-sign both balance system in bitcoin
its just a you want my goods pay me $100 if i only receive $10 confirmed you dont get the goods until tyou send me the other $90

Sure; but what if your wallet shows you received $100? Because I gave you a malicious wallet that simply shows wrong balances on GUI, no matter what happened on the blockchain?

in LN payments of msat are sent meaning you think you got paid 1,000,000msat..  you hand goods over. and month later at broadcast realise you only got 1sat

If you didn't get a hacked / malicious / fake wallet which has fake multipliers hard-coded into it (anything other than 1000), this is impossible.

where the app is wrote by a malicious dev

This must be the worst argument I've ever heard. Of course a malicious wallet can scam you. Just like a malicious L1 wallet, like a malicious banking app or a malicious faked Bitcointalk login page.

the scenarios are different and you know it

by not being settled up when you sell a product. the person can give you fake msats in a multitude of ways that never flourish into being real sats .. and you wont know it for the usual x months you dont want people broadcasting for.. because you wont want the broadcasting every payment just to check every payment. as thats a sillty thing to do

however in bitcoin if i get bitcoin i know i got bitocin via a multitude of ways. its settled and i can see its settled so then i can release the goods knowing i been paid in full

I acknowledged that on L1, you can check with a block explorer. You can also check the channel opening transaction on a block explorer and see the other party's real balance.
Even though verifying channel state updates manually may be harder for the average user to do than checking TXID's on blockchain explorers, it is bad running a hacked client anyway.
If you argue that a payment system should work securely even when people deposit coins into hacked clients, then Bitcoin L1 is also bad, because a hacked L1 client could also just simply transfer all funds to the attacker immediately.

[franky1]

you are totally going so far left fields.. its going to take you a while to come back to the discussion


its about the PAYMENTS that convert not the wallet
its about the 1:1000

to quickly address your wallet left field..
which as proven by examples like thor turbo.. many people downloaded and not seen it as a flaw and so just accepted msat balances that didnt represent anything of real value they can fairly claim later..

now lets get back to the 1:1000 issue AGAIN
so lets try again because i think you think its just a problem about ur partner paying you like a small insignificant problem only affecting one persons receipt of payment from only one person
      x    y
      |     |
      v     v
A->b->c->d

you are D
imagine C gives you 'inbound' balance on his side
thus you have no real state or utxo on your side. to claw back

now no matter if a b c x y tries paying you. C gives you fair msat amount. but it converts to an amount thats alot less than expected
in actual bitcoin when people may me.. im gonna get the correct amount.
GET IT YET

the issue is on the conversion.. where u presume your getting 1000sats (1m msat). but your only get 1sat x weeks later

with actual bitcoin
if 5different people wanted to pay me i know im getting the correct amount because there is no C partner to mess with my value

[n0nce]

now lets get back to the 1:1000 issue AGAIN
so lets try again because i think you think its just a problem about ur partner paying you like a small insignificant problem only affecting one persons receipt of payment from only one person
      x    y
      |     |
      v     v
A->b->c->d

you are D
imagine C gives you 'inbound' balance on his side
thus you have no real state or utxo on your side. to claw back

now no matter if a b c x y tries paying you. C gives you fair sat amount. but it converts to an amount thats alot les than expected ^{[emphasis mine]}

Why would the amount that C gives me, convert to a much lower amount when I close the channel a while later? If, as you say, C gave me the right amount and my client is not compromised, I will 100% get the correct amount when settling on-chain / closing the channel.

[AGD]

It´s incredible how much time people can spend with Frankies confused drivel. Face it guys: He doesn´t know shit about the Lightning network!
He is the Master Troll of bitcointalk.org.

[franky1]

now lets get back to the 1:1000 issue AGAIN
so lets try again because i think you think its just a problem about ur partner paying you like a small insignificant problem only affecting one persons receipt of payment from only one person
      x    y
      |     |
      v     v
A->b->c->d

you are D
imagine C gives you 'inbound' balance on his side
thus you have no real state or utxo on your side. to claw back

now no matter if a b c x y tries paying you. C gives you fair sat amount. but it converts to an amount thats alot les than expected ^{[emphasis mine]}

Why would the amount that C gives me, convert to a much lower amount when I close the channel a while later? If, as you say, C gave me the right amount and my client is not compromised, I will 100% get the correct amount when settling on-chain / closing the channel.

in all my posts i have been telling you the scenario.. multiple times
1. that its an app your service provider asked you to use.
     - much like how thor turbo got many people to use theirs
          - where it compromised a feature
              - where no one cared to see it as a flaw/bug

2. the app changed the conversion rate from 1:1000 to 1:1,000,000

3. alternative other scenario: is the value is on a inbound msat allotment to you on your partners commitment/side
..
and you decide to ignore it all to then say your ignorant:
(im paraphrasing(not verbatim))
'in utopian best case scenario of there not being any manipulation there wont be any manipulation'
(facepalm)

you might aswell with your mindset be going around saying
'but if ftx didnt scam users users wouldnt have been scammed..' ignoring the fact that the scenario everyone else is seeing is that ftx scammed users

[BlackHatCoiner]

Franky's arguments be like: lightning isn't secure, because your machine might catch on fire

1. that its an app your service provider asked you to use.

Here's what you can do if a provider asks you to use their wallet software: deny. There are lots of wallet software, most non-custodial, and have no fundamental flaw.

3. alternative other scenario: is the value is on a inbound msat allotment to you on your partners commitment/side

You're from UK, right? No offense, but is it so hard to compose a sentence properly? You can't win an argument if your interlocutors don't make a sense.

[franky1]

There are lots of wallet software, most non-custodial, and have no fundamental flaw.

i should laugh.. but i think it deserves a (facepalm)

you might want to talk to the devs of the main wallets you speak of which all have flaws individually and flaws in unison to all wallets because of faults in the bolts which they all follow but are not enforced by any consensus structure.

LN wallet devs have admitted their flaws and losses.

yep even LN devs have lost funds in the main big brand wallets they developed. losses locally in channel with other same brand users.. . and from just using LN cross-platform with different brands

LN has many flaws

..
but i see what you are subtly implying
that issues only affect the users within the channel of those using a duff wallet so everyone else should not care to implement rules for LN as a whole to protect users.. in short blame the user not the lack of protection on the network that could and should protect users from things

EG
(again)
LN could as part of the [bolt advised] network gossip of establishing route maps. inspect the channel ID's and check on all of the ID's respond to a confirmed funding lock. rather than a temp ID. thus they only keep a 'mempool' of legit channels. thus they only gossip-relay to other nodes a legit list. thus any illegitimate channel is not gossiped. thus taken off the network. or left invisible to the network
 making it difficult for a service that wants to abuse channel users with unbacked msats for instance, from being able to be routers or have routes due to not being seen by the network

but nah.. you lot dont care about reducing risk and problems. you just want to call everything "user error" and brush it under the carpet

[n0nce]

in all my posts i have been telling you the scenario.. multiple times
1. that its an app your service provider asked you to use.
     - much like how thor turbo got many people to use theirs
          - where it compromised a feature
              - where no one cared to see it as a flaw/bug

2. the app changed the conversion rate from 1:1000 to 1:1,000,000

Okay, so since the attack you describe actually only works by getting users to download a malicious wallet, I could also just distribute a hacked L1 wallet that e.g. doesn't show transaction IDs, giving users no way to verify if they actually received funds. Or that allows me to steal part of their funds, while still displaying the old balance in the GUI.

It's not a Lightning issue; it's a hacked wallet issue. We should focus on getting users to use verified, open-source wallets (of any kind: software, hardware, L1, L2) with reproducible builds, which is exactly what I've been doing for the last months.

[franky1]

when i receive payment in bitcoin i know i received it and its confirmed.. settled done..
its not a game of promises of trust that a state/commitment/funding lock hidden beneath the GUI you cant see will settle up correct..
its not a game of sleepless nights making sure a middle man isnt trying to spend value i thought i might get to keep but may not get unless i close off and remove myself from the channel/their control/risk ..

in bitcoin when someone pays me its done in full where there IS a UTXO that backed it. and the amount i get is clear and settled and final.

in LN you cant make the same promises

in LN people can see a msat balance and "think" that it is good. and release product for delivery to the msat sender .. but find out way later when settling up the seller got screwed by the channel partner

bitcoin actually has many consensus rules about the pre-confirm relaty network that check for faults in the payments.
bitcoin has lots of rules that protect about faked balance of holders
bitcoin has many rules to ensure that middle men cant manipulate value

LN cant say the same

i have to remind you there are multiple other flaws of LN but it seems you lot cant even get out of your utopian cloud of dreams to be risk aware of just one issue.

as for you saying its just a single hacked wallet issue of a single victim scenario...

you again forgot that a major service (thor turbo) showed up a major flaw via having a large amount of users thinking "its a feature" where no one was critical to think. "actually this can abuse people"

so your so called "all we need is to review wallets" security check is crap

bitcoin has actual rules it mitigate many "hacked wallet" threats of faking balance. or faking receipt
yep if it aint on the blockchain... it didnt happen.. pure and simple.

[n0nce]

when i receive payment in bitcoin i know i received it and its confirmed.. settled done..

You don't, if you run a hacked client that shows fake amounts and no transaction IDs.

bitcoin has actual rules it mitigate many "hacked wallet" threats of faking balance. or faking receipt
yep if it aint on the blockchain... it didnt happen.. pure and simple.

How do you check against the blockchain if you run a faked, light wallet?

Because if we assume people have access to a legitimate, synced full node, then it's impossible to fake balances in Lightning, just as well.

you again forgot that a major service (thor turbo) showed up a major flaw via having a large amount of users thinking "its a feature" where no one was critical to think. "actually this can abuse people"
so your so called "all we need is to review wallets" security check is crap

I'm not very familiar with 'Thor Turbo', but if I understand it right, users were running a non-verified wallet right? Or they verified it and didn't identify a flaw (because being told it's a feature)? So how is my argument 'we need to review wallets' crap? Properly verified wallets with no weird changes, settings or messed up multipliers won't be susceptible to the attack presented here.

If anyone gives me a wallet whose source code has a multiplier for msat conversion other than 1000, there's no way in hell they convince me this is actually a feature, lol. Like looking at a ransomware binary, its source code and being like 'yup, I want to run this!'.

Maybe other alterations to LND / CLN could be 'sold' as a feature & later reveal as a bug / attack vector; but this story you keep spinning about altering the msat / sat factor, is not realistic. This is way too easy to spot.

[franky1]

you are really really ignoring how things work, playing dumb, or just avoiding things by acting ignorant

how about you go back to your subnetwork and just go back to sleep.

meanwhile for other people that want to be risk aware and not run down some rabbit hole of trying to lay dumb..

there is no network level consensus system in LN that prevents a person from this manipulation. however in bitcoin there is many rules to prevent this type of crap you are trying to say is a user to blame fault..

how many times do i have to repeat it. please try to OBSERVE

heck i even gave you a bug fix that would sort out/reduce exposure to/prevent the ability of how for instance,  thor turbo abused things

Maybe other alterations to LND / CLN could be 'sold' as a feature & later reveal as a bug / attack vector; but this story you keep spinning about altering the msat / sat factor, is not realistic. This is way too easy to spot.

yet no one was spotting thor turbos wallet that had channels of msat balance but no funding lock to back those msats..
... i spotted it the day they announced the features and you lot were telling me to shut up, many of the pals you adore and support were trying to call it a feature not a flaw

[BlackHatCoiner]

you are really really ignoring how things work, playing dumb, or just avoiding things by acting ignorant

He's responding to every bullshit you've been whining about. Ironically, you're going off-topic more often that he does. He's straight to the point, and you're constantly avoiding it.

when you are receiving INBOUND msats

Pleonasm. You can't receive outbound sats. That's why they're called inbound.

ITS NOT ON YOUR FUNDS OF YOUR COMMITMENT YOU GET TO BROADCAST

ITS ON THEIRS

Great. But once they provide the corresponded signature, and we revoke the previous state, they're mine.

because the funds are in their side of the channel, which they only expose to you if you use their wallet. you cannot check your "balance" outside of their app

Here we go again with "their app". Fuck their app, and use a reputable, open-source, peer-reviewed, non-custodial lightning wallet. Gosh.

there is no network level consensus system in LN that prevents a person from this manipulation.

Except if you run your own lightning node.


Look. You're terrible at words. How about we open a channel together and you do your magic to rip me off? Your best course is to make me go offline for 2016 blocks.

[franky1]

Great. But once they provide the corresponded signature, and we revoke the previous state, they're mine.

but what your signing with them.. is a signature of a commitment which is not for the full amount you think it is going to be..  .. ... because whats seen in msat balance at GUI is not whats signed into the state!! do you not understand that part..!
also a revoke is only given to you. when the states change again where they are to not use that old state
yep revokes are for old states not current ones.
so if they broadcast their latest state.. you wont have a revoke for it!
get that yet

...
its like you are both deliberately missing out parts to play things down. rather then you both thinking to actually see things with a risk aware mindset
all your goal for the last couple days is to down play it as user error, and not a flaw which the network should consider finding a solution to prevent.

bitcoin has rules to prevent this crap and yet you lot seem ignorant

no wonder why LN is broke and has flaws and for 5 years has remained like that. which is why LN is not fit for offramping bitcoiners to


due to your attitudes of how little you care about security of your network. ill continue to see LN as a silly subnetwork for small use low value amounts that people should be risk aware, and that they can be prepared to lose. .. where LN should not be seen as a solution to long term use to offramp users away from a secure network

[BlackHatCoiner]

because whats seen in msat balance at GUI is not whats signed into the state!!

What's signed behind is signed in sats, not msats. It is rounded down. It has already been told to you like a gazillion times.

also a revoke is only given to you. when the states change again where they are to not use that old state
yep revokes are for old states not current ones.
so if they broadcast their latest state.. you wont have a revoke for it!

Lol, that's the point. The latest state is the correct state, which has emerged after a number of off-chain transactions. Every other transaction should be penalized, if published.

no wonder why LN is broke and has flaws and for 5 years has remained like that. which is why LN is not fit for offramping bitcoiners to

Hey, how about we do what I said? If you cheat me successfully, you can keep the money.