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

the difference is:
im not the one doing a hinder bitcoin to promote altnets
im not the one trying to get people to exodus bitcoin 'because altnet is the solution'
im not the one trying to say bitcoin cant/shouldnt scale because altnet is the direction people should move to
im not the one advertising an altnet thats already separate to become defined as being bitcoin2.0

im not oppose to freedom and choice and opinion.
im oppose to people saying bitcoin is limited, broke, unscalable, useless, not a currency. to promote their other network as al of those things, while also trying to take over brand bitcoin

oh and im not the one trying to ban people because of their opinion

It appears you're providing me with examples which support my assertion that devs can code what they want. 

Despite the part where some people found those clients to be divisive or objectionable, developers were still free to create them.  People had the opportunity to run those clients.  A few people are still running some of those clients even today.  If Bitcoin were a closed-source project with one person having exclusive control over the code repository, then perhaps those clients wouldn't exist.  But Bitcoin is open-source, so anyone is free to use that code and create something new.  Any time someone on the forum has claimed that other developers had no right to use "Core's code" as a base for other clients, I have challenged that.  I stand by the stance that anyone is free to use that code to create other clients. 

As far as I'm concerned, everything works as intended here.  I'm happy with that.  You say you're not happy, but again you don't seem to be able to propose a viable alternative.



Now this is where things get interesting.  We're into the subject of social engineering.  This one is an absolute hornet's nest.  Mostly due to the part where it's a human flaw.  And I'm going to be completely honest with you.  I don't have an answer for you. 

Sometimes people lash out and make petty attacks against things they don't approve of in the hope that they can convince other people to feel the same way.  And this has happened quite often when devs create new features they would like to see implemented.  There's no way I'd deny that.  It absolutely happens.  But the thing is, it's all completely subjective.  What are we supposed to do about it?  One person's ideal might be another person's heresy.  So it's inevitable that people will attack new ideas if they don't like them.  I don't have the slightest clue as to how to change that sort of petty behaviour and I suspect you don't either. 

But I do have an important question for you:

Can you highlight any distinction between the behaviour of those people who made "REKT" campaigns against those implementations like XT/Classic/Unlimited and your behaviour with your ongoing "REKT" campaign towards LN? 

Because I'll be the first to admit that I can't see any difference (aside from the part where your campaign has been remarkably less successful).  You claim you are vehemently opposed to that sort of conduct, but one could argue you're doing exactly the same thing.  Lashing out and attacking a concept you don't approve of.  How are you acting any better than they were?  Is it a revenge thing?  They did it first, so you're justified to do it now?  Help us to understand it.  There's clearly something getting lost in translation here, because none of us can figure out what it is you're actually trying to achieve.

I can assure you that even native English speakers find it difficult to understand franky - his language and spelling is frankly atrocious.

when one group want to say LN is bitcoin2.0 and muddy the water confusing what LN can and cant do. limiting the scope to what LN can do only when talking about bitcoin, makes them ignore what LN actually is, just to make LN fit their narrative.

oh and its not "about LN on the bitcoin network" its the LN network bridging to a network.
LND does not function on the bitcoin network.
EG LND requires a blockchain full node that bridges to LN or a LN lite cellphone app just works on the LN network without touching a blockchain network

the peer connection aspect of nodes.. is separate to channel forming.
LN peers(nodes) can connect together and have different blockchain bridged channels. .. its why atomic swaps is a feature

yes losing private keys, data loss/computer crashes. hackers, are all standard risks of all blockchains and all crypto. including LN.. but LN has flaws ontop of standard risk. where even the devs making LN have lost value, not due to standard risk reasons
EG when i get a confirmed payment on bitcoin.. the sender is not going to punish me somehow and double spend my coin. nor can he. yet these smart contracts add in new clauses that allow delays in confirmation to invoke punishments (much like fiat chargeback scamming is a bane of merchants lives, so will these punishment clauses become)


meanwhile on bitcoin even offline someone can pay me. no need for me to sign for it. no need to watch or hire a bank to watch to make sure the sender doesnt refund himself. its mine. done. clear. end of story

LN is different and riskier and the LN PR people need to make people aware of the risks instead of just saying its bitcoin 2.0 and has same security as bitcoin


this is what i mean by needing to explain the risks. you loosely wrote:
when implemented and used correctly, it has the potential to make secure transactions abundant
but even that is sweeping the risks under the carpet. like its not a big deal and pretends to be "secure".
there are more flaws then you might think. or more flaws than others had bothered to make you aware of


with honest partners. no big deal. but we all know from all the bitcoin scams mentioned on this forum. you cant trust someone not to want to take their funds out if they see an opportunity to garner more then they deserve.
again going offline thinking partner wont do it, requires trust


i dont have a problem with LN being advertised as a nice service for micro payments.. the issue is when its described as bitcoins solution to everyones every day payment needs. when its described as bitcoin2.0. when its described as the replacement to not need to scale bitcoin or widen its 'limited blockspace'
seeing as you brought it up. ill just quickly say
the limited blockspace is not limited due to any technical reason. its limited by commercial politics reason, of creating a demand for a altnet that can fill a niche


first its not LN on the bitcoin network. its just LN. whereby you want to restrict it to become LN bridged to the bitcoin network, to fit a limited scope narrative.
again once you understand that atomic swaps and connecting nodes is separate comms than creating channels, it may become clearer for you

actually in the LN code it does mention pico. they just use pico-1 as the measure of mast, but the pico is very much wrote in the code

LN when peers connect. .. is a separate thing and a precursor to funding a channel

you cant obviously already have a channel where you already have funds locked in a partnered multisig, just to be able to establish you are a bitcoin only bridge, to then connect to a peer to then create a channel to then fund into the partnered multisig .. thats a paradox


i will respect you may not know about the peer connect process is separate to the channel establishing process. so ill just mention paradox again. and also mention atomic swap and also LTC bridge

thats more about the limitation of your wallet. not the limitation of LN. its much like saying you have a SPV wallet and so now you believe that the bitcoin network doesnt do blockchain archiving, because your wallet doesnt do it.
much like many that are already thinking that 'pruned nodes' are still full nodes and archiving data to provide new peers with IBD is not part of the decentralisation feature of bitcoin

i understand your wallet doesnt do atomic swaps, nor any decent node interrogation of channels.. nor able to handle other blockchains.. but thats not to say the lightning network cant/doesnt

nah, lets not play into the game of making LN sound like its bitcoin 2.0 by only talking about a limited scope.
again LN peer connection does not require channel establishment first to 'fix' users to a specific bridged blockchain (the paradox)

---

---

LN allows the payment promise of millisats. the bitcoin network allows the confirmed immutable settlement of sats
i know at GUI level you cant tell the difference. but at code level there is a difference.

much like you wish to argue that binance sidechain is not real bitcoins.

---

its not about collective approval anymore..
"backward compatibility" made it so, by not requiring users to upgrade..

its not about saying what people cant code.

its about what they do in their PR campaigns promising one thing but giving another. overhyping something as being something else.


i guess your still forgetting the other implementations..
maybe "REKT bitcoinXT" campaign.. remember now?
how about bitcoinclassic
how about bitcoinunlimited

how about all the topics where everyone says bitcoin-core is THE reference client.
how about the rhetoric where all bip submissions and stuff has to go through their approval process

[moderator's note: consecutive posts merged]

It can move on without you.  No one single person can block or filibuster a proposal if the majority agree.  We don't need your individual approval.  It's about collective approval.  But the fact that you're still using Bitcoin means you do approve (if reluctantly).  And yes, it is sometimes possible to introduce changes in way that is backwards compatible, so that users who don't want to take advantage of new features can still take part in the network on their own terms.  But why would you oppose that?  It gives you more freedom, not less.  And again, your only counter proposal would be to tell devs what they can't code.  We've established that notion is unworkable.
 


Apologies, but I didn't ask about my mindset or what I've said.  I asked you to provide evidence to the contrary.  Do you have any?  I'd love to see it.  If not, kindly concede the point.  You cannot prevent devs coding what they want.  There isn't a way to do that unless you are suggesting we make Bitcoin closed-source and put you in charge of the code repository.  Is that what you are proposing?

No, I meant to end the discussion about LN in relation to Litecoin (and other altcoins).

Sorry, but I can't answer this nonsense, with all the respect. It's just impossible to understand a sentence and I'm really tired to try hard at the moment.

---

True, franky, don't use phrases such as flip floppy, I've firstly no idea what they mean (and as it seems it happens to others too) and secondly, keep the atmosphere of the discussion calm.

I recommend you to read the lnbook.

---

What you fail understanding is that some of those questions can't be answered with a simple True or False. For instance:
Yes, they're separate networks obviously, but they do the same thing. They allow you to transact bitcoins. The transaction structure and the contracts are different, but the purpose remains same.

yet another flip flop..

did you forget previous talking points where by you have said that bitcoin doesnt require USERS to upgrade clients 'because backward compatibility'.. remember where you script hymn sheet 'bitcoin doesnt need you it can move on without you'


i guess you forgot the other implementations that got treated as opposition and told to fork off.. oh wait it was you telling them to fork off. because you wanted core to be the sole brand of reference client.

and no dont try refering to very old mindset before your switcheroo..
i used to respect you in the days of 2015 and before.. but you have switched over to sound more like a centraliser and altnet fan in recent years

Consensus (and open-source) related post:


I notice a small but crucial step missed out.  Devs can create and release code.  There's no 'automatic update' in any Bitcoin client I've ever used.  Ergo, upgrades can only occur if people freely choose to run that code.

So no, devs can't upgrade the network.  Only those securing the chain can do that.

Also, regardless of how you choose to interpret consensus, the only counter proposal you've ever expressed is that devs shouldn't be allowed to code things you don't approve of.  That's not something anyone can enforce, even if anyone did happen to agree with you that it was the correct course of action.  Which leads me on to the next point:



As we've already established, they can't upgrade the network unilaterally.  But beyond that, yes.  I will state it clearly and with emphasis because it's empirically true:  

Any developer can create any code they want.  No one can stop that in an open-source source environment.  

You might take issue with that statement, but can you provide any evidence to the contrary?

Further, I feel it's one of the most vitally important features of crypto and I'm baffled as to why anyone would want the opposite.

---

//EDIT:


Oh, sorry, heh.  Did you want to start another topic for consensus-related matters, then?  

I wouldn't call a custodial made-up token an off-chain solution. Binance tries to trick people into using their own centralized chain, pretending it's Bitcoin.

Added to the OP. This is what I meant by "Try to limit the scope", but you explained it better.

Agreed. I assumed we were talking about LN on the Bitcoin network, but indeed, it can be applied broader.

I must say I like this system: if you don't trust the existing watchtowers, you can run your own. It's like creating your own bank managers! And if enough people do that, there will be enough watchtowers to rule out being offline when you need one.

I agree with you here! I (still) don't understand all the technical details of LN, but from what I've seen, it is indeed complicated. Much more complicated than signing a simple on-chain Bitcoin transaction. But, and that's why I like LN: when implemented and used correctly, it has the potential to make secure transactions abundant.

This is new to me. But (I think) my earlier point stands: my Bitcoin LN wallet can't transact with for example a Litecoin LN wallet, because the transactions needed for on-chain settlement aren't compatible, hence the transaction on the LN-side can't be accepted.

See:

I think this is correct. But: I think the node's rules on fee for onchain settlement are a much larger concern. Why would I bother about a fraction of a satoshi if the node sends thousands of satoshis as on-chain fee? It's just a rounding difference.
I assume all these details will be explained in the fine print of large nodes in the future, or you can set your own preferred fees on your own node.

I don't think the average transaction size went up because of smart contracts, but it's because more users (and especially large users such as online casinos and exchanges) have finally realized batching transactions is more efficient in terms of blockspace and thus transaction fees than sending separate transactions for each individual withdrawal.

I'm not a native English speaker, and it's kinda hard to understand what you mean if you talk about "altnetters", "flip flop", "waffy clauses" and "flip floppers".

Could you show any example? I don't care whether it's on mainnet, testnet or signet.


While coin-age was part of code, it was never part of Bitcoin protocol. See https://bitcoin.stackexchange.com/q/54583.


I'm aware about low percentage of node which use client that doesn't support SegWit. My point it'll be one of reasons against hard-fork.

your interpretation is flip floppy.
you first (and mainly) pretend that consensus is devs can do as they like and if users dont like it they can fork off.
then you flip flop that users cant propose anything because they are not worthy
then you flip flop that upgrades cant happen without the community where devs cant mandate
then you flip flop that no one can implement an upgrade because no one will every agree unanimously
then you flip flop that bitcoin is open and anyone can propose

my interpretation is simple
pre 2015 consensus required any user to propose and if enough devs 'ack' and it gets put into code. and enough users then download that software release implementation, it activates
pre 2017 consensus required mining pools and nodes to have consensus of devs chosen rule before an upgrade would activate
post 2017 devs can upgrade the network and force users/pools to upgrade or be thrown off the network


i am not in disagreement with you at all in this. i was not the one saying that LN has to work network wide with bitcoin.
i wasnt the one suggesting LN is reliant on bitcoin


oh boy.. my comment is on the peer connection.. not the locked output of funds vs token promises..
its the public keys used purely at the peer connection stage.. that those keys.. SEPARETLY at a later stage can be used to bind together to create a multisig. and separete stage again later then that multisig can be used to fund locks. on different chains.
the public keys are just random generated priv->pub nothing about the keys force it to a certain blockchain at the peer connection stage

its not like a channel is funded. and then keys are produced to then use to node_connect to a peer.. (time doesnt travel backwards)
 
so lets deal with your obvious confusing in 2 stages, or what appears as being a mish-mash of different parts of the network protocol done to confuse the issue
1. peer connection
the gossip: node_announce section of handshaking with a peer.. is a completely different process to that of discovering the channels and which bridged coin a node has.
you cant work out how many chain_hash channels a partner has BEFORE joining the partner(time moves backwards)
you can join the partner to THEN find out what chain_hash his multiple channels might have
(time and action moves forward)

meaning. a litecoin bridged node and a bitcoin bridged node are not separated on different LN's. they can peer connect on the same LN. and then agree on some atomic swap of their different chain_hashed bridged channels

lets just use the flimsy 'bolts' as an example (working backwards, seems the direction you prefer)
4. nodes 'shouldnt' send a channel_update notifying the network of a chain_hash locked channel until funding_locked
3. nodes 'shouldnt' send do funding_locked unless they have funded the multisig
2. nodes 'shouldnt' send funds unless they have shared public keys, made multisig, agreed which chain_hash
1. nodes 'shouldnt' agree on a public key until they are peer_connected

what you learn is this paradox you pretend exists where there are different 'lightning networkz'... does not exist
YOUR VIEW: you cant connect to a node1 without a channel4 designating which blockchain its on.
my response: but then you cant connect to a node1 to then create a channel2 in your paradox.

the reality is though. there is no paradox. you can connect to a node without a pre-existing channel and then inspect what channels they have.

being able to connect to nodes without a channel.. is not a paradox which you hint at, where nodes need to have assumed some chain_hash  locked channel with funding already provided before even connecting..

please please please understand the difference betwen peer connection.. being different to channel locks
(i think you separately know it. and just said some weird mixing of different aspects just to be silly and cause irritation)

2. locked funds of funding_tx vs LN promise.. and their signatures
seems as part of you rmish-mash of aspects of the network. you want to impose your opinion that the signatures of a peer connection are that of the same signature as a established channel with locked funds

signatures of a series of bytes(message) which includes value of msats. wont match a series of bytes(message) of a contract  measured in sats. not a series of bytes(mesage) that contains an IP, port and public key

i think you might want to learn the association between what signatures sign. EG you cant take a litecoin transaction signature over to a bitcoin transaction message and make it fit purely because the use the same public key.
the message(contract wording/node data) have to match too

what you find is that a there is no single signature that lasts for the duration of all things LN
many signing processes happen. signing different things ..
a couple signing processes happen in the payment part. one for the LN payment(mast) promise and another for the commitment(sat). at GUI level you dont see it happen. but at code level it does. and a malicious attacker can mess with is via delays in signing.

just because you dont see the signing stages happen for their respective things. doesnt mean they dont happen, so try not to confuse it.
and definitely dont try pretending a signature for one message can be used on multiple messages
that sounds a bit faketoshi to me. taking an old signature and pretending it refers to a new message

i just corrected your paradox. you cant use a litecoin signature on a bitcoin network. the message/signature wont carry...

but you seem to be meandering away from the actual initial debate now.
you dont need to have an active channel with funds locked just to peer connect to a node..
thus you dont need to be locked to bitcoin with funds locked to talk to other peers.


as for your final two points.. you debate that the nodes of different bridged blockchains cant communicate together. and then at the end flip flop to say you never said they cant and you never restricted their use (facepalm)

---

so because some altnetters want to contradict themselves, flip flop. and confuse even themselves with what they are saying
lets try this one more time. the questions are made simple to avoid any extended waffly clauses, its simply to get flip floppers to finally pledge their opinions to agree or disagree with certain aspects

ill number them and you can quote them and put a * mark in which box you agree or disagree with

1. lightning network is not the bitcoin network. they are separate networks that do different things
agree[ ]   disagree[ ]

---

2. LN promises (payments inside LN) are denominated in picocoin(11decimal) also known as msat/millisat
agree[ ]   disagree[ ]

---

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

---

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

---

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

---

6.LN wont work without bitcoin
agree[ ]   disagree[ ]

its not complicated.
just simple quote the 6 questions and put a * into the box that fits your opinion. an opinion you will not flip flop out of or contradict yourself later.

[moderator's note: consecutive posts merged]

No, so what's bad about that?

By that reasoning, SPV servers' network doesn't require blockchain 'cause there's lack of network wide audited policy.

Depends on how you understand consensus. The current rigmarole that has started with you and my ban request is caused because we both have different understandings of the word “consensus”.

In the Lightning Network everyone does whatever they wish, they don't have to come into an agreement for their implementations. There are different sets of rules (different protocols), but each participant follows the same rules with their co-participants.

Of course and they can. However, in LN it's not just an invented token. Each participant holds signatures which can be used to unlock outputs from the blockchain where there is consensus. Hence, the consensus of Bitcoin is connected with the Lightning Network.

I don't confuse them, I'm just telling you that whether you make a Bitcoin transaction or a Lightning one, in both cases, you carry a signature that can be used to move funds from the blockchain.

Didn't say the network can't.

Didn't restrict their use, stop making things up.

Wouldn't it prevent custodial service from creating batch transaction (where batch transaction use less block size compared with creating a transaction for each user request)?


Since coin-age priority was never part of Bitcoin protocol,
1. Do you think it's possible to enforce it on Bitcoin protocol? Currently miner/pool can mine empty block and choose any transaction.
2. Most miner/pool will be hesitant to support this change.


The number is just example and was picked arbitrary, you could ignore it. If bitcoin community agree to increase block size based on hardware/internet growth and operational cost, IMO it's likely the number is smaller and ignore internet cost since it's part of monthly expenses (unless they consider user who has slow/expensive internet).


I see, but we know it's more than removing the "weight". Since it require hard fork, it'll force many people to upgrade their software and another activation signal which will take some time (IMO at least 6 months is required) and attract another controversy (such as cutting backward compatibility).


To measure SegWit/Taproot success, looking at transaction count/block isn't the only factor you should look. But i don't bother press the topic since other member already do.

ask nicely and you shall receive
https://www.blockchain.com/btc/block/364422
its just 1 transactions and filled the block and took the nodes a heck of a long time to validate due to the bloat of soo many signatures. that prompted a change to sigops /5.. but even thats too high with the increased blocksize, so needs reducing again
taproot was not part of the protocol before X date.
the thing is though. it is not rocket science to do current height - utxo height.
it does not require a PHD in cryptography to master it.


if there are less than 5% using old nodes that dont like 4mb. then there is no hard fork controversy

no, it wont prevent batching. it will prevent spam over batching by performing the legacy linear sigops attack.
currently there are ways to 'fill a block' using just 5 transactions with 16,000 tx sigops each
static const int64_t MAX_BLOCK_SIGOPS_COST = 80000;
static const unsigned int MAX_STANDARD_TX_SIGOPS_COST = MAX_BLOCK_SIGOPS_COST/5;

this could be brought down.. not to just 1-2 like you are thinking, but to say 50 or a few hundred, thus still allowing batching but preventing a max sigops attack of blocks with only 5 transactions using up the block limits

also coin-age is part of code. its a simple: current blockheight - utxo blockheight = coin age
and also miners in the first few years did obide by a different fee formulae than the current weight cludge

enforcing it is the same as how pools obide by the weight (vbyte vs byte) formulae

1. miners do already have a 'fee' formula.. i already explained that they obide by the x 4 legacy rule..
you can tell because legacy transactions are more expensive and so if pools only followed greed of 'more sats the better' they would only accept legacy transactions. and ignore "cheap" segwit.
the very reason they deem a segwit "cheap" the same 'value' as a legacy 'premium' is becasue they do follow the x4 calculation of value per byte/vbyte

2. again they already do support fee formulae. but.. guess what. code is great. you can actually make rules to force support too. thats what code does, it makes rules


backward compatibility.. ? how many people are actually running nodes from pre 2017.. i bet its not 5% of network
also the march2017-august 2017 proved that mandated activation can happen. (bip148 and bip91)

oh and because the consensus.h rule is maxblocksize 4mb. the hard block rule is 4mb. its just the cludgy soft code after that limits some transactions to not utilise it. so all the majority nodes of 2017+ dont need an upgrade. blocks wont be rejected for being 4mb

Since i didn't find word "size", "block size" and "hard fork", i'll ask these question to @franky1
1. Do you think increasing block size limit is the only option for scaling (since you're not fan of SegWit, Taproot and LN)?
2. How should Bitcoin community determine block size limit?  Arbitrary number (4MB, 32MB, etc.)? Based on hardware/internet growth? Based on cost of running full node (e.g. maximum $500 for initial setup and $25/month for operational cost)?

1. there are many ways to increase transaction counts.
a. reducing the tx_signops_limit. dis-incentivizes big corps from filling blocks with just a few hundred transactions,
b. using the now allowed 4mb 'quota' removing the still existent 1mb wall. and the cludgy math that goes with it, allows full 4mb utility rather than constraining transaction data to the 1mb limit
c. also changing the fee formulae to make 'spam transactions (those that spend multiple times a day/every block, just to bloat blocks) more expensive will cut down the amount of needless transactions, giving more room to genuine spenders

2. we are not in 1999 days of floppy disks and dialup.
in 2010 average internet speed was  1.9mbs
in 2022 average internet speed is 58mbs
thats a 30.5x scaling of internet speeds
hard drives are now 4tb and within your range of costs(~$100 ~£75)

a raspberry pi and a 4tb is within your $500 spend limit
as is a $400 desktop with a 4tb hard drive upgrade

as for your monthly internet cost..
without even considering if an average american uses bitcoin.. just to get good internet for real life entertainment the average american spends $61 on the internet.. so i think you have set a very low bar for monthly costs of $25..
heck it costs an average american $25/month just to have their lights, tv and computer on (normal life stuff)


but converting YOUR $25 low bar to UK£ .. yes i can get more then 60mbs for £20 internet with no monthly cap

so lets say people upgrade their computer every 6 years
meaning ~600gb a year. is about 11mb per block..

now im not saying lets jump to 11mb a block now because hardware and internet can cope with it.. im just saying.. internet and hardware can cope with it so people need to drop the 1999 internet/hardware spec propaganda and realise its 2022

as for what the community wanted in 2017 was a 2mb base atleast. i would now say thats about 4mb base block as a acceptable way to go. and that can be achieved by just removing the 'weight' miscalculating cludgy code and just having the maxblocksize as 4mb straight and open for full transaction utility. along with a new fee formulae and sigoplimit reduction to avoid bloaty spam.

as for things like taproot and segwit.
though segwit promised more transactions and cheaper fee's segwit has had 4 years and by the looks of the transaction count charts and the block bloat charts.. the efficiency of transactions per Xbytes have not flourished as promised.

as you can see the average transactions in last 3 years

downward trajectory..
but the bloat is in an upward trajectory.

meaning the transaction per XXXbytes is becoming less efficient due to all these new "smart contract" bloat.

oh and one other segwit promise was the 4x discount of transactions. yet code reveals its not legacy /4 = segwit prices. its instead segwit * 4 = legacy prices.
they did not discount segwit. they instead increased legacy

static const int WITNESS_SCALE_FACTOR = 4;


            // New feerate uses satoshis per virtual byte instead of per serialized byte
            CAmount feerate = weight ? (txfee * WITNESS_SCALE_FACTOR) / weight : 0;


if train tickets were $10, and there was a promise of 4x discount you would think train tickets would be $2.50.
instead though the station decided to make standard seats $40 and new carriages $10

maybe taproot might help change this smart contract inefficiency.. but lets see.. because so far segwit has not helped, even though that was a promise..(as was the NYA 2mb base that triggered(reached threshold in days) allowing segwit to activate).. and we all can see that didnt happen

i am not the one that mentioned LND's altruist watchtowers as an example of how LN 'cant' have watchtowers that hold keys
i am not the one insinuating that LND watchtowers are the default thing/part of some strictly ruled consensus
i am not the one saying LN requires consensus to enforce that watch towers dont need keys

i clearly said that due to lack of consensus means LND's altruist watchtower is not the default policy regarding watchtowers



oh, but it can.. as we have just agreed, the lack of need of a consensus, means that peers can happily communicate with many networks and with no other blockchain due to the lack of network wide audited policy.
are you going to now flip flop about the lack of consensus.. ?
the lack of ned for consensus majority to implement features means people can connect together via just the requirement of a publickey and (ip/tor address)... and then once connected . then set up channels with their desired other network, or private internal token.

again a smart PR person could use this as a advert for the benefits of LN in regards to atomic swapping, evolving network without consensus conflict hindering progress

the ip/tor address connection.. and the subsequent public key, handshake does not lock peer partners to a specific blockchain. that public key and formation of joint multisig can be used on multiple blockchains, or no blockchain at all and just some private token they invent together. the lack of consensus allows this


number 2, is specific about the inside LN payments.. yet you want to confuse this ln payment. with the separate contract to the 'force-close' transaction you also mention.
if you cannot tell the difference. please look into it. dont confuse the two
seems you still cant separate things. and want to cause confusion by pretending they are the same.

here ill give an example of how to separate things..
a condom is not a penis. a condom is not essential for a penis. and a penis is not essential for a condom. people can have sex without a condom and people can use a condom as a balloon or a waterproof cover for a rifle nozzle.
although sometimes a condom is put over a penis. and in those times a woman only feels a condom inside her when the penis is inserted.. but at no time is a condom a penis
do you get the common sense of knowing the differences between a condom and a penis.
that they have two separate functions. one locks in seamen.. one releases seamen

the LN htlc promises.. denominated in msat are a different contract than the funding contract transaction and a different contract than the settlement contract.
and yes even the funding contract. and the settlement contract may be the same format. they are still separate contracts.

EG imagine on the bitcoin blockchain. you paid me with one confirmed transaction. and i paid loyce with another confirmed transaction.. the transaction to loyce is not the same contract as the one you paid to me.
LN payments are not only separate contract to a 'force-close' contract. but also in a very different format. making them significantly more different than each other.

if you want to confuse the matter by saying that litecoin contracts are the same as bitcoin contracts. then try to get an ltc transaction to confirm on bitcoin and then try to get a msat promise to confirm on bitcoin..
point is the msat promise(LN payment) wont ever be understood nor able to confirm on the bitcoin network,.. because.. the LN promise msat promise(LN payment) is not a bitcoin transaction. so dont pretend its the same thing

i know if i read your responses to points 3&4 you then backtrack to then acknowledge the difference. but i thought its worthy of highlighting your ignorance at this point, to then highlight your contradictions and flip flop acknowledgement in the next responses
can you please just stop flip flopping and just understand the differences in things, and stick to acknowledging them

i just explained your flip floppy contradictions. but thanks for finally admitting they are different (you made one step forward, dont try stepping back now, you made progress)
an LN payment (in msat) is not a fixed format that is only used as a mirror of a bitcoin 'force close' settlement contract
the LN payment when rounded and value 'associated to consider what value to settle on can be settled in different blockchain coin denominated contracts. there is no consensus or network wide audit at the point of rounding up/down a valuation of a LN payment and creating a subsequent blockchain formatted contract.
scammy partners can mess with this and not sign a settlement contract to update the promise value into something more
tangeable the victim can use to settle his promised value


thats your personal opinion. not a physical, hardware or software restriction.
just because YOU dont use it for altcoins. doesnt mean the network cant


thats your personal opinion. not a physical, hardware or software restriction..

just because you might only want to use a condom as a replacement of party balloons, does not mean thats its only function. other people have other uses of condoms.

trying to sell it as only to be used as a party balloon is a naive concept. where as a smart PR person can 'sell' a condom as many functions.

did you know in the military on tours of duty.. . more condoms are bought as a waterproof cover for their rifle nozzle. than bought for a soldier to cover his penis. sex is (discouraged in the military tour of duty)
does that mean the US government that funds soldiers waterproof budget should make TV adverts about condoms to be used only as waterproofs for guns?

If you're trying to tell me that you're more confident of being secure in the Bitcoin network, I can easily agree. Lightning is a far more complex term and therefore, requires more awareness from the user's side. However, I can't unsee the fact that you're still, after all, discouraged to cheat me.

Can I have a little bit more context? What does consensus have to do with an implementation of LND's altruist watchtowers? Why is it required?

Yes, they're different networks. However, the Bitcoin's Lightning network can't work without the Bitcoin network. The Lightning network can't work itself without a first layer.

Yes and no. The transactions are made in msats, but the force-close transaction (which is what distinguishes from other debt-based systems) is in BTC.

I guess “inside LN” means those after you've opened your channel and before you close it. Yes, agreed.

Of course.

Yes, however there's no reason I can think of to use it in Litecoin.

Theoretically it can work without Bitcoin. Honestly, though, in practice it wouldn't have another reason of existence. I wouldn't use it in an altcoin. It's the decentralization of Bitcoin that makes it unique, IMO.