Topic: Lightning Network Observer - page 20. (Read 13049 times)

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

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.

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.

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.

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.

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

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

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.

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.

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

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.

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.

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

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.

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?

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.

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.

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

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?

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



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

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

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.

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.

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.

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.

The code that does this is actually in line 43.

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.


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

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.

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

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

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.

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.

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

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?

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

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

phone wallets in general dont do general checks. you admit:

thor turbo proved you wrong.. shame you didnt observe

Which can talk with the lightning node at home.

I don't understand much from this sentence. There are mobile lightning clients that take your custody in exchange for comfort, if that's what you're saying, such as BlueWallet with hubs. These services don't provide you a proof of their stash, indeed, because you need to trust them either way.

That's not supposed to be seen from a human...

It's called penalty.

Dude, seriously. It's called penalty. Look it up.

Except that your node always checks for the integrity of their partners automatically. They can't just open a 0.1 BTC channel with you, if they don't have the money.

I'm not going to respond to the latter. It's crystal clear now more that you haven't spent even an hour to study lightning.

first to blackhat

things you are IGNORING

1. people using Ln to buy things like coffees and normal small purchases you guys for years have said are not suitable for bitcoin but what people can do on LN
people are not going to be taking a laptop or desktop around with them.. they are going to be reliant on phone app wallets..

2. those phone app wallets are just GUI representations displaying msats. .. mostly funded by imbound balance from a service (partner) own stash which he is presumed but not guaranteed to have on a output directed to you.. presumed becasue those services usually ask you to download their prefered wallet too.

you pretend people can just press a button and see the commitment and know they at they can check its a real 6 confirm utxo.
but here is the thing

THOR TURBO PROVED YOU ALL WRONG

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.

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.

you lot are the ones not thinking with open minds. you cant even want  to admit that LN has flaws.
LN has no network standard protection to weed out bad actors or nodes/apps that are abusive. (abusers: not following rules)

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

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

5. bitcoin network however if i make a payment without a confirmed utxo backing the input.. . the relay network wont relay the transaction
if someone was to try sending abusive data. nodes ban them as peers and dont relay stuff to them.
LN has none of that

.. while you go around saying wrong because wrong and heres some quotes about network chainhash(not even part of my latest thing ) or  your other quotes about AFTER commitment scenarios.. or comments about rounding when the conversation is about none of that..

when i have multiple times now been talking about the problem with the.. CREATING commitment stage.. from the onion payment mismatch of value possibility via abusing the 1:1000 rate

6. you are also saying "if doesnt matter because"
but its that "it doesnt matter because you can broadcast any time.." statement by you lot that show how callous and ignorant you are.. because by the point of broadcasting it..  then its too late!!


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

the mSatScale uint64 = 1000

is not the same as "if <1000 then 0"

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

now learn their comment terms of their comments section i linked.  where rounding is a different function to 'shedding by a factor of 1000'

then you might see the different function i am speaking of

once you can actually be bothered to talk about the risk factor i have been talking about. then i wont ignore your silly comments about something else you are trying to redirect the conversation to

Are you evading my replies and questions?

True; no secret, nor issue, though. You check it yourself whether the 'funds exist' (funding transaction mined or not).

Just correcting misinformation or clarifying things that you yourself are bringing up.

Sure; if you take off the overly-worried risk-exaggerating strawman hat.