Topic: Lightning Network Observer - page 21. (Read 13809 times)

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.

Your point isn't true, and we've explained it to you like a million times. Not only in this page, but in others (which didn't have a lightning niche, but just included a reference, and you immediately started derailing as usual) and in a thread dedicated to you; you can't go more ridiculous than that. You're refuting the irrefutable years now. That's concerning.

I'm not going to write this one more time. I'll quote myself, because I've said it enough times already.

Can you expand this?  Because as far as I can tell you do not actually understand how LN works.  It does not USE UTXO's outside of the ones in the underlying channel transaction open and close.  There are no UTXOs in lightning's accounting system.

And if your understanding of how lightning works, and how it relates to the base layer is this bad, then you really should not be making many arguments at all.

more ignorance and moving away from the issue by trying to think its a rounding error.. it shows you do not observe or think outside the utopia promotions

also my point has always been. that LN has no network consensus to audit channels to ensure that funds exist to honour payments...

well its your network. go play with it.
just dont try jumping to the bitcoin community pretending LN is better than bitcoin. its not.

enjoy your niche market and accept your risks and stay blind. but dont over promise stuff about your network and then call crap on about the bitcoin network while hiding the big flaws of your network

oh and by the way. even pre-confirm.. the bitcoin network wont relay payments that have no valid confirmed UTXO. .. unlike your silly network that would.

and last lesson

inside a forum bout crypto.. inside a topic about a subnetwork.. you do not need to wear the promotion happy utopian hat..
people would have already heard of LN to even be in this topic. so you do not need to be on constant sales pitch .. instead people want to know the hard truths. the risks they should know about.
so wear the risk awareness hat. not the promoter hat

sounding like a over-promising snake oil salesman helps no one even genuine people that want to temporarily give a niche service a try for just a short period or a potential long term user.

when you OBSERVE that the audience of this topic is majority existing LN users. you will soon learn kiss assing a promotion sales bitch of over promise.. is futile in this topic