Topic: [self-moderated] Is LN Bitcoin? franky1: About scaling, on-chain and off-chain - page 10. (Read 3211 times)

The funny part is that he does talk about the LN and that responding him likewise make him look right about your behavior towards us.

Commitments of directs payments is LN's niche. You just want to discuss whatever it's in your interest. Please allow us to try make a point out of this mess, thank you.

And whose fault is this? Lightning's?

hmmm. now should i bother to review all the posts of this topic and look at who has mentioned the most insults..
but anyway funny part is that darkv0rt3x post had no content related to how LN works, or scaling bitcoin, yet was just a personal attack message. (boring, but nice try to poke the bear)

oh well i now agree this topic is dead. seems people just want to talk about commitments of direct payments(not LN's niche) and not the LN payments(ln's niche of being able to pay different people)
some people just want to get angry and insult(funny part is darkv0rt3x could be talking about them)
some just want to merit cycle each other and show their loyalty to friends.

seems LoyceV is not 'Switzerland' when he merits a post thats not ontopic and just an insult slam (hypocritical)

---

you might want to look at the current proposals wanting to be 'bolted' into protocol of LN and a few services already using the proposals in their own software. these are where peers create LN balance(msats) without a block confirmed pegged btc as collateral. where the msat balance is based on 'trust'
 
by this i dont mean they are pegged to a different blockchain transaction for msat payment smart contracts. this means its making 'fake' channel, by sending 'funding_locked' messages on trust even when a transaction has not confirmed. where it does not even reference a utxo(txid and blocknumber) because it has no blocknumber to reference. instead it uses random number for channel ID

as i said a couple years ago.. the pegs are not guaranteed and the promises are based on trust. even the devs involved with the LN proposal and its current usage in their software use the words "fake" and "trust" when describing the channel setup
reference to post on other topic baited by doomad.. (so dont get angry and upset that i responded with proof)
https://bitcointalksearch.org/topic/m.58991641

i was trying to keep this topic inline by trying to get people to stick to a non flipflop(contradiction) conversation by setting questions to finally summarise their opinion. (tie them to a single stance they stand by)
i was also trying to get people to learn about the differences of LN payment s vs commitments. to then when they realise LN payments are not commitments but their own promises.. then move onto describing commitments to show how LN devs dont even want commitments to be solidly pegged to blockchains..

but it looks like they just want to stay in their utopian fantasy PR campaign version of function, rather than care enough, desire enough to learn how things work and want to know about potential flaws.

you cant teach the blind to see, or be independent especially when all they can feel is their friends holding their hands guiding them.

We don't just keep the discussion here. We create discussion(s) here. In other topics, those discussions would have got deleted justifiably.

You're missing the bigger picture, which is this:

---

---

I must say the discussion so far is much better than I expected in Bitcoin Discussion. I don't think anyone will change their mind, but that was to be expected. At least it's more or less on-topic and I don't have to delete a lot of spam.

Hi.

I feel I just read a 700 page book of some mix of technical book and I don't even know what to call it.
My eyes are almost crying due to the amount of things said, the amount of the same things repeated, the amount of times the answers are not objectively replied, the amount of times the posts writing, simply deviates in some way the person who's typing wants.

The worse is that there is someone trying to inflict his point of view to everybody else, no matter if he's 100% accurate in his claims or not (which apparently he's not). And in the process he tries to diminish other people's knowledge, confidence and self-esteem by insulting, by not being concise and objective, by deviating the point of the post with an attempt to be grammatically correct, by all sorts of means of demagogy.
I would even say this is as close and cyber bullying as it gets. Amazingly, most of the people here can take all this crap over and over again. I wouldn't, for Christ sake. Blinder than a blind man is the one who don't want to see.

I'm almost compelled to say this guy is autistic. I have dealt with one in the past and this type of behaviour is common among autistic people. They have tons of drive and focus but then they lack basic skills of communication, lack of social skills, they find quite hard to socialize and accept other visions and thoughts other than the ones of their own.They can't verbalize correctly and they often get angry/frustrated when they can't achieve their goals.
This person has all these traces.

I'm not going to be making quotes over and over, and deviate the discussion, but this is pointless. This thread is pointless. Not because there is not good information and tons of will of some of the people to share knowledge but because this become just an attempt of a guy to inflict, by brute force, his point of view on his own terms as if his the owner of the absolute truth, which we can see clearly he's wrong in quite a few aspects.

Anyway, I already read more in this thread a couple of more mentioned along it, than I read in the last week.
I wouldn't even bother to continue this discussion with this person as he's trying to use so many tactics to brute-force his view that only someone completely blind can't see it!

Good luck trying to deal with this type of person!

I don't think we're going to (nor have to) agree on this I'd say "Bitcoin LN" makes it very clear we're talking about Bitcoin locked in channels that can be send through LN and later settled on-chain. You say it's not Bitcoin.

But instead, you started talking about terminology again.

---

---

For the record, I prefer to just call it "LN", but if I do, you say LN can also be used by Litecoin, so I specify "Bitcoin LN", even though almost anyone already understands what I mean when I post about LN on Bitcointalk.

@Rath, I'm reading the discussion and I respect what you're doing, but it doesn't matter if you're right or wrong nor if franky is right or wrong. Franky won't stop derailing your statements until he either proves to be correct or you give up.

You keep shutting him with transaction formats, he keeps telling you that msats aren't sats. You give him the actual scripts, he tells you you're flip flopping. You talk him calmly, he's yelling at you and facepalms himself. You talk with sense, he doesn't.

I've said this before;

2.
(facepalm)

(facepalm)

typical. oh well. but dont worry your not the only one that cant answer basic questions, your not the only one trying desperately hard to avoid talking about the msat payments.

oh an in another topic. Doomad reminded me about how crappy LN is about funding locks. not requiring them to actually peg to 6 confirms locked value onchain.
https://bitcointalksearch.org/topic/m.58991641

anyways. seems the only thing LN PR guys understand is direct payments in hub model.
just a shame LN are even trying to break that by having direct payments not require a locked funding peg

---

in LN payments (measured in Msat denomination, not to be confused with commitment in sat denomination)
the htlc is not a commitment htlc.
the onion routed packet is not a commitment packet
the invoice is not a commitment invoice

those 3 things are messages outside of the channel commitment(sat denominated) protocol of messages, but are indeed part of 'micropayments' protocol(the LN payment(msat))
because in all 3 message types, they all have 'amount' denominated in msat.

i know you find it tough to discuss ln payments and now wish to avoid it. but. like i said first if you cant prevent yourself from meandering back to 'channel management commitments', then yes there is no more to discuss with you.

as for not answering 14 unbiased quick summary questions.. silence is revealing
i have respect for LoyceV atleast he made an effort to answer summary questions

I am going to wait for others to share their thoughts. They probably need some time to catch up with us. This is my last reply for now.


You might want to check what H stands for in HTLC. I can't see any hash in that locking script. HTLCs in commitment transactions are those two scripts that you ignore to comment for some reason.


Again, you completely ignore two locking scripts which are used for HTLC outputs in commitment transactions. Eric can't spend those outputs with just a secret because he also needs valid HTLC signatures, but you don't want to acknowledge them, even though you keep talking about HTLC-success and HTLC-timeout transactions.


If you don't see any difference between an invoice, onion_route_packet and HTLC then we really don't have anything to talk about.
I see that further discussion is pointless as you keep saying that I should read the specifications more carefully without quoting it to prove your statements.

Good night, franky1.

again.. i am talking about the LN payments
EMPHASIS LN PAYMENTS

which allow eric to get paid from alice.

you just tried to convert a conversation about LN payments and their HTLC(eric payment hash + msat denominated format)
to then quote yourself saying
first let me clarify buzzwords
(LN payment = invoice, aka onion_route_packet aka msat micropayment channel, aka millisat denominated HTLC)
you choose the buzzword. your LN has many buzzwords for the same thing.
just dont confuse LN payment(or its buzzword variations for the same thing) vs comitments(blockchain accepted format)
HTLC is buzzworded as "smart contract(emphasic on the C of HTLC) yes LN payment is one form of smart contract(HTLC) and commitment is another form of smart contract(HTLC) but they are not the same thing.
so please stop referencing commitments as your response to LN payments


ERIC DOES NOT get paid using two valid HTLC signatures produced by only alice and bob.
ERIC DOES NOT get paid using two signatures produces by signing the commitment as the 'message'
ERIC gets paid by Diana and only diana

eric never sees alice bob pubkeys..
alice and bob never put erics payment hash into a commitment

because eric has the secret

..
i know your locked on and zoned in and narrow scoped concentrating on just 'direct payment' scenarios of a hub model payment were its just alice paying bob. where bob is the destination. whereby in that 2016-7 scenario of explanation of bolt 2 is only describing the in channel management of such direct payment of just alice and bob.

but can you just take a few hours away from typing your messages on repeat referring only to yourself as evidence of your thoughts. and instead read the other bolts and do this..
this one thing

distinguish the difference between direct paying bob. vs route payment to eric
by this try to expand your scope beyond the repetitive bolt2 reference of a direct payment scenario of a 'hub model'. and instead grasp the concept of micropayments of a 'hop model'

i know you are endlessly trying to desperately only want to talk about commitments. but grasp that LN msat payments are a thing, stop skipping to point 4 of your ascii image to avoid the 123

grasp things like:
if bob charges 1sat fee, carol charges 1sat fee, diana charges 1 sat fee
thats 3sat to make a payment to eric, alice needs to know this to then set how much to send to bob.

alice cant commit to bob with an amount unless a route has first been tried using the msat denominated payments, where by alice learns what the combined fees of that route will be.

alice also might be looking at other routes. and not yet decided which route to use as a path

i know you want to skip past the payment talk to meander back to commitment.
but untill you can understand the process of the payment talk. and what happens before a commitment is even made.

then it just shows you dont know about the payments.
and its not because they dont exist. its that your stuck (narrow scope view) only on the channel direct payment to partner

also you say HTLC have nothing to do with revocation because revocation uses time lock..... you might want to check on what TL stands for in HTLC (spoiler: Time Lock)
the snippet of IF ELSE statements you referenced in bolt3 are the conditions of .. drum roll.. the HTLC contract

before hitting reply.
1. if you have not read the other bolts. dont bother replying, you have already spammed this topic just referencing yourself in previous posts of your opinion. there is no need to post again referencing yourself.

2. if you have sat back and took some time to wish to discuss LN routed payments (without meandering into examples of inchannel direct commitments) then have the first part of your post quoting my previous post questions. putting a * into the [ ] that applies to your opinion.

then we can establish a baseline of opinion. of where your opinion differs or (dare i say it) agree with mine
i want to get a short quick summary of your actual uncontradicted opinion of your thoughts of LN. so that i can see what things your not getting right

That's why I asked you to check one of my previous posts. There is no point in explaining it again, so I am going to quote myself instead.


For some reason, you refuse to accept the existence of those scripts.


There is no other way to pass the "onion_routing_packet" other than via "update_add_htlc". Any other way wouldn't be specification compliant.


HTLCs have nothing to do with revocation. Revocations and punishments are handled through simple timelocks in locking scripts. For example:


If Alice broadcasts her commitment transaction, she needs to wait for 'to_self_delay' blocks (144 blocks by default) since her transaction has been mined before she can spend this output. Bob can broadcast a penalty transaction at any time.

anyway. its been pages of flip floppy.(contradictions) and avoidance of understanding PAYMENTS. just to meander into only discussing commitments(facepalm)

so lets gauge peoples understanding. these questions (by request) have been write short to avoid clauses, and also in pairs of opposition wording to avoid bias. lets see what you know

1.a: lightning network is not the bitcoin network.
agree[ ]   disagree[ ]

1.b: lightning network is the bitcoin network.
agree[ ]   disagree[ ]

2.a: lightning network is a separate network that does different things than bitcoin
agree[ ]   disagree[ ]

2.b: lightning network is always linked to the bitcoin network that does what bitcoin does
agree[ ]   disagree[ ]

3.a: LN "payments" (inside LN code) are denominated in picocoin-1 (11decimal) also known as msat/millisat
agree[ ]   disagree[ ]

3.b: LN "payments" (inside LN code) are denominated in btc
agree[ ]   disagree[ ]

4.a: LN "payments" (inside LN) are different contracts/transactions/promises/lengths of data, to a bitcoin transaction
agree[ ]   disagree[ ]

4.b: LN "payments" (inside LN) are same format, to a bitcoin transaction
agree[ ]   disagree[ ]

5.a: bitcoin network does not understand the format of these LN message formats(payments) in 11decimal valued format
agree[ ]   disagree[ ]

5.b: bitcoin network does understand the format of these LN message formats(payments) in 11decimal valued format
agree[ ]   disagree[ ]

6.a: LN is not tethered to only function on the bitcoin network
agree[ ]   disagree[ ]

6.b: LN is tethered to only function on the bitcoin network
agree[ ]   disagree[ ]

7.a: LN wont work without bitcoin
agree[ ]   disagree[ ]

7.b: LN will work without bitcoin
agree[ ]   disagree[ ]

we are agreed. one step forward for you.. finally


we are half agreed. two steps forward for you.. (being generous)
but kind of weird how you say the exact same thing as what i said.. but then
you say the commitment then has erics payment_hash(facepalm.. ill explain later issues with this)
and then ask me to check something..
and when i go check. you are referring back to commitments of the channel management and nothing to do with the LN payments..
deduct half a step
rath_you are 1.5 steps forward. but looks like you are beginning to step back again


oh and here you go again. talking about step 4(your ascii art) of the commitment and ignoring the steps 123(your ascii art) of the payment..
deduct 1 whole step

your only one step forward.

again you seems to only want to limit the scope to direct payments (inchannel funding commitment where bob is the destination)

HTLC is actually about the revocation part initially(punishment) in regard to routed or in channel direct payments(partner is destination). though in direct payments becasue your trying to pay bob anyway as the destination there is less need for HTLC
but a HTLC main objective is you 'hope' to prevent partner sending an old commitment. by having a time locked contract with revoke conditions

i wont deduct a step yet, as this is a new argument from you. ill just treat is as naive jump to conclusion before checking.
just try to look into it abit and not just repeat it because you said it before


i know you want to concentrate and saturate this topic with endless post just talking about the commitment and ignoring the millsat payments.. yea your game is obvious. and getting boring..

your post you refer to is ignoring the LN payments that involve the payment_hash provided by eric and used throughout the route.
instead you want to only discuss the commitments of channel management
..
here is the thing..
when alice gets payment_hash from eric.
alice has not even told bob how much needs to be routed. because alice might use zoe, yvonne xena.. instead
so how does bob know, well alice chooses to try a route via bob, carol, diana,eric by sending an LNpayment (onion packet msat with erics payment_hash(htlc)) though that path.

alice does not use this (payment)htlc to put into a commitment with bob, because the output is erics key and eric knows the secret, if it were put in, and it was broadcast, eric would see the confirmed utxo to his key and he can then spend that utxo with his secret

the commitment is a separate HTLC using the alice bob pubkeys (not the eric payment_hash HTLC)

i know you want to use bolt 2 because its example is pretending bob is the destination.(direct payment)
where micropayments/routing is not needed needed in bolt 2 scenario.

but things have moved on.. try reading bolt4 and learn about the other things . like micropayments using the onion packets

it seems you are too eager to pretend that the 'payment' is put into commitment and act as if there is no msat format htlc..
and that story of yours is getting boring

That's correct.


A commitment transaction with HTLC outputs uses the public keys of the channel partners, their HTLC public keys and the hash of the payment secret. See the second half of this post again.



The specs literally say that one should not forward an HTLC unless one can enforce the contract on-chain.


It's exactly the opposite. Direct payments could work just fine without HTLCs. The main purpose of HTLCs is to enable payment routing.


franky1, come on. You seem to completely ignore the fact that TWO commitment transactions are signed for each Lightning payment. The first transaction is supposed to prevent the situation you described from happening. The transaction contains additional (HTLC) outputs with locking scripts which I described in the other half of this post.

Bob has no real reason to broadcast his commitment transaction with HTLC outputs unless Carol claims his HTLC and Alice stops cooperating, and refuses to sign another commitment transaction without the HTLC output.

The second commitment transaction is signed once Bob sends "update_fulfill_htlc", which includes the payment preimage, to Alice. It's the transaction you have been talking about all the time.

HTLC is not a specific term which means commitment

HTLC is basically "complex contract"
a LN millisat format payment has a HTLC ..

just because you see something that says HTLC does not mean it refers to the commitment

AGAIN:
a LNmillisat payment HTLC has units of measure in msat and also uses Erics payment hash for all users (ABCD)
a commitment HTLC(different) uses only the pubkeys of the channel partners and is measured in sats

a commitment is an inchannel management thing that occurs after the out of channel payment of routing packets

please try, for the multiple time of telling you. to learn the differences

last time im going to say this.
a HTLC is not "commitment". it refers to a whole range of transactions and formats that use HTLC
so stop trying to say 'it makes a commitment because it says HTLC.

oh and one last thing
bolts2 (the thing your addicted to) uses examples of old old protocol where its describing examples of 'hub' payments (where channel partner is the destination)
try to read the newer bolts. that explain more of the routing and payments of others in hop models using micropayments.

you cant comit to rounding up a millisat to a sat. until you know the millisat payment is complete..

otherwise if alice is trying to pay Eric.  if it was alice commiting to bob first. bob could then broadcast his win he never asked for.. and because its the latest commitment(in your scenario fantasy). bob cant be revoked. and so bob gets the win. eric doesnt get paid and alice is out of money.

sorry but thats not how it works. bob only gets paid after eric gets paid (ref the image several posts ago of 1-9 alice to eric)

No, one side sends "onion_routing_packet" in a "update_add_htlc" message and then commitment update is expected as per specifications (see last quote in this reply for explanation).


I do know that and that's what "update_add_htlc" does.


What exactly is that private message in your opinion? That's what I have been asking you the whole time.


Please, take some time before replying to my posts and show me the actual pieces of code from the official specification which back up your statements.


You make me repeat the same things over and over again.


As per specifications, the node which receives "update_add_htlc" MUST commit the HTLC by signing a new commitment transaction (a series of "commitment_signed" and "revoke_and_ack" messages between both peers) before forwarding the payment further (sending "update_add_htlc" to the next hop).

The receiving node knows the next hop because it obtained this information from the "onion_routing_packet" which was included in "update_add_htlc".

your trying to set a narrative that channel partners update a commitment and then send a "onion_routing_packet"
what you are not realising is what i said a few posts back. with the colourful image cycle of 1-9 alice to eric

you do know that users along a route cant create a commitment update until they have first received a LN payment. else how will they even know what they have to update the commitment by. (oh wait is LN now featuring psychic powers?)

also at the update_add_htlc, they dont update the commitment. they create a LN micropayment promise

this update_add_htlc is a private message between channel partners that update their own micropayment promise.
this micropayment promise is measured in msat and includes the destinations payment_hash as the 'output'

its not the channels commitment that uses the channel partners pubkeys. its a "micropayment" msat format using the payment_hash

once an payment succeeds then they update the commitment. because then and only then has B deserved been paid by A.
if there is a route fail. then the Ln micropayment promise just gets dropped

please take some time to read ALL the bolts. and try not to fear moving away from your adamant desire to only read bolt 2

..
actually.. seeing as you love bolt 2

https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#adding-an-htlc-update_add_htlc

as you can see "update_add_htlc" is the msat message including the "onion_routing_packet"
update_add_htlc is not a trigger for create new commitment

I'm following, although I struggle understanding how franky corrects you. His technical writeups make it infeasible to read and understand.

How's that true? Can't you verify if the channels you're routing transactions exist in the Bitcoin blockchain?

Sure. But, if one out of the ten merchants starts accepting Lightning he makes the difference. The rest have an inferiority when it comes to payment methods. I honestly don't know if the elasticity of demand from such change gives greater profits than the extra costs. I suspect that if the merchants like Bitcoin they will get involved with it and handle it properly. I mean how much dedication do you need to maintain your channels?

Again, routing instructions are a part of the onion packet, but bolt4 does not describe how to pass this information around, which is what we were talking about.


"hop_data" is a part of "onion_routing_packet". It is a piece of data that each hop receives in an encrypted format, which tells them who they should forward the HTLC to (via "update_add_htlc"). You don't send just "hop_data" to the next destination. You need to send the whole "onion_routing_packet" through "update_add_htlc".

You still haven't answered my question. How do nodes forward the "onion_routing_packet"? You have just learnt that they need to forward it because it contains (encrypted) instructions for every hop. How do they do it, though?
I keep asking that question because you insist that nodes do not sign a new commitment transaction before communicating with the next node in the routing path, which is not true.

I am not sure why you keep bringing the msat thing over and over again. I have already admitted that one side asks the other to add an HTLC denominated in msat and expects signatures for the commitment, HTLC-timeout and HTLC-success transactions denominated in satoshis as a reply. If the other side does not reply with valid signatures then the HTLC is failed.

bitcoins reward math. bitcoin transaction data is not 0.X.. its actually measured in sats.
to make the smallest unit subdivide even further requires breaking and bastardising many bitcoin rules.

if you look at the byte data(raw tx) of a tx of 1000sat,  its not 0.00001000  its actually 1000

EG if a legacy UTXO had 1000sat locked to the key. and a BStard transaction format was measured in msats
the then code would think that the 1000 unit of legacy is only 1sat (1000msat)

also the block reward. its not 6.25/2/2/2/2/2/2/2/2
its actually 625000000 /2
or more technically, in binary:
100101010000001011111001000000
were the end bit is dropped every 210,000 blocks

if a new BStard transaction format of msat protocol viewed:
100101010000001011111001000000
it would convert is to not still be 6.25btc but instead appear at GUI as 0.00625btc because the unit of measure has shifted by 3 decimals at GUI level

this means to cludge the code with more code to fix that. the current
100101010000001011111001000000  (6.25bt legacy)
which has 30 halvings left (30 bits to drop)
would need to be changed to
1001000110000100111001110010101000000000
with 40 halvings. meaning it also breaks the 20140 year cut off. and changes it to be 2180 before supply depletes

and also more code ontop to recognise old legacy/segwit formats and convert a legacy/segwit utxo value from
100101010000001011111001000000
to
1001000110000100111001110010101000000000
and if someone wanted to go back to a legacy utxo. the reverse (4bit varient to 30bit varient)
in short, alot of cludgy code and alot of bug risks of translating bytes and crap

..
also with 1000x more sharable units. that can be split and shared around. this also changes the scarcity.
EG no one cares about only 190,000 tonnes of gold. if there is enough gold dust for everyone to have, its not scarce because everyone can have some gold