is bitcoin scalability problem solve now?

[famososMuertos]

Well I understand where your question is going but in a certain way the scalability of bitcoin is possible and is what is really important, it has been shown that there are alternatives that can and make the use of bitcoin possible to the new times and in fact they must continue in the measure of its use, it is necessary to clarify then that bitcoin works correctly as it was conceived and of fact is adapted to the objections of some users.

[1715588067]

1715588067

[1715588067]

1715588067

[1715588067]

1715588067

[BlackHatCoiner]

(point being whether LN exists or not. if bitcoin fee's are $30+ a time, the amount of people using bitcoin daily declines as do those users desire and need to run fullnodes daily)

Ethereum fees are more than that and the amount of users increases. So, I guess it doesn't work exactly like that.

and even if LN did exist people wont want to spend $30 with bitcoin if they can just convert their fiat to an altcoin and still access LN cheaper.

There's no reason to increase the block size, 'cause they don't have to pay right now $30 to open channels and make regular on-chain transactions. Also, Litecoin is cheaper with or without LN, but people prefer Bitcoin, so once again, it doesn't work like that.

LN is not the solution to make bitcoin more useful and scale up. its actually a way to take people away from using bitcoin via many motivations/tactics.

Just-your-opinion.

again you are confusing the LN payments (private playful conversations in bed with the wife) vs the settlement contracts..(divorce papers)
please try to learn the different contracts.

Please learn to read and respond properly. This is not what I said. I showed you that there's a difference between gold and the banknotes of 20th century in contrast with Bitcoin and the Lightning Network.

funny part is that im not the one telling people to f**k off to other networks. thats not consensus.. thats exodus.

I never told you to fuck off or that I screw your solution. Again, this is one of the indications of psychological projection. I recommend you to see a psychiatrist.

your buddy group are the ones that are authoritarian, wanting devs to do mandatory forks and implement gateway features to exodus people off the network by multiple tactics.

Nothing was mandatory. What you just described happened in a democratic way. We didn't use any kind of cunning propagandas to accomplish this, people just appeared to be agreed with our solution.

other funny part is i agree LN is a niche use-case.. for micropayments. .. it is not however the payment network solution for all bitcoin daily use which is what you and your chums advertise it as. and LN is not bitcoin.

Daily, I only make micro-payments. If I want to buy a car, yeah, I won't use the LN.

says the guys that endless call their other network bitcoin2.0, bitcoin2 bitcoin solution.

I never did. However, I agree that you may think I did.

funny that, because in the same post you then admit its not a solution but just a niche for micropayments only

I never said it's beyond micro-payments.

need i remind you that Rath_ a LN dev had a 70% payment fail rate with amounts way under 0.009($500)

I'll leave @Rath respond to this himself as it's not my business.

[DooMAD]

need i remind you that Rath_ a LN dev had a 70% payment fail rate with amounts way under 0.009($500)

I'll leave @Rath respond to this himself as it's not my business.

Rath already did respond, but sociopath1 continues to phrase things in a manipulative fashion to make it sound like LN fails to send payments 70% of the time when that's not true:

(bold emphasis mine)

(success:fail  143:389)
oh and his payment fails. were all of amounts under 9000000000millisat (rounded/converted under 0.09btc)

Sure, my node failed to route 389 payments. Some of them were probing attempts, some failed at a further point in the route and others could not be routed because I didn't have enough coins on my side in the outgoing channel. However, those were not my payments. I keep my fees fairly low compared to other nodes so no wonder why I am getting a lot of routing attempts. Anyway, my point is that my node failed to route 70% of the payments, but it doesn't mean that LN failure rate for transaction smaller than 0.09 BTC is 70%. You can't tell if another attempt for the same transaction was successful or not.

Just because Rath didn't route those particular payments, doesn't mean no one else did.  

Also, there's no requirement for people to route payments at all.  It's more accurate to say Rath successfully helped 143 transactions go through despite having no obligation to do so.  It's quite possible that sociopath1 (being a sociopath and all) isn't capable of altruism and finds it a really difficult concept to grasp.  No wonder they're so confused about all this.  

funny part is that im not the one telling people to f**k off to other networks. thats not consensus.. thats exodus.

I never told you to fuck off or that I screw your solution.

No, that one is definitely aimed at me.  

See this post and about a dozen others I've made over the years which follow a similar theme (but he still doesn't get it).  I keep pointing out that other networks would give him the so-called "scaling solution" he desires.  And it's true.  He can have bigger blocks and be part of a network where those who secure the chain are willing to carry that cost.  Yet, for reasons that even he can't explain, he keeps whining at us to give him the same thing he can get somewhere else, despite a clear demonstration that the users on this network don't want that.  Consensus mechanisms are great for resolving ideological disputes like this.  You want different rules?  Create a fork and do it.  So others did exactly that.  And the matter is now resolved for everyone else.  Just not for him, it seems.  The war is still raging in his head, but everyone else went home and got on with their lives.  He doesn't understand that it's over.

But yes, he should definitely see a psychiatrist.  

[Rath_]

need i remind you that LNPizza experiment in 2018 had a 90% payment fail rate for pizza value

Rath already did respond, but sociopath1 continues to phrase things in a manipulative fashion to make it sound like LN fails to send payments 70% of the time when that's not true:

I also responded to his pizza experiment argument here, but it looks like we have a different understanding of what a "failed payment" and "payment success" are.

[franky1]

im still laughing.

389 fails is still 389 fails.

imagine you made 200 bitcoin transactions waiting to confirm. and 140 just never got confirmed.. people would call that a failure.

Rath_ might call it a 'test of mempool' or a attempt to see what acceptable fees are. but just having a system that doesnt make 70%-90% of payments shows its not the 'instant payment' system

Rath_ knows that the 'network gossip' part of route path finding is completely different to the invoice/payment things. so i truly laugh that he wants to pretend the fails are 'route finding gossip'.

as for my wording of my explanations.. just because i dont use the altnetters silly buzzwords in their silly PR campaign format, and instead i use average joe analogies. does not mean i am flip flopping anything i say.. nothing i say is contradictory from one of my messages to another of my messages.. however altnetters contradict themselves and flip flop all the time.

if you want to cry because i dont call channels 'edges' and instead i use joint-bank-account analogies, then go buy yourself a warehouse of tissues. or grow up.
i dont try bigging up my ego to pretend to be elite by using special words of a boysclub.. i explain my thoughts using words average people can understand.
so keep crying if i dont speak your buzzword language. its not proof i dont know the language, its proof i learned the language and can think outside of the box to translate it into normal-speak. i dont play the ego game you guys are obsessed with

oh.. and by the way.. the 90% fail pizza experiment.. was where the pizza recipient got X amount of orders but x-90% of payments
it was not a case of re-routing and paid seconds later in full via different middlemen. it was pizza orders but no funds to pay for it.

as for Rath_'s 70% fail. Rath_ admitted he has no clue why they failed. but he assume, presumes, guesses possible causes. and has then took an extra step off a cliff to use a guess to try selling the utopian dream cause. rather than being honest and tell people that LN has many causes for fails

[BlackHatCoiner]

You don't like it when others post wall of texts against you, do you? What a noise... Dude, franky must be a so annoying person in real life. Thankfully you don't make a lot of sense and newbies just pass you over when they're reading your replies which is what worried me the most.

imagine you made 200 bitcoin transactions waiting to confirm. and 140 just never got confirmed.. people would call that a failure.

Imagine you appeared in every thread related with the Lightning Network and say the same nonsensical bullshit every time, all over again, for the millionth time. Now that's a failure, if ever there was one.

[franky1]

Imagine you appeared in every thread related with the Lightning Network and say the same nonsensical bullshit every time, all over again, for the millionth time. Now that's a failure, if ever there was one.

imagine anytime hundreds of people want to talk about BITCOIN scaling.
idiot altnet fangirls turn it into an advert for their altnet, trying to convince people to stop using bitcoin and start using their altnet..
.. well no need to imagine it.. it happens every time.

a funny part is that altneters think i am the only one that wants BITCOIN scaling and even funnier that maybe 12 people of the altnet variety keep patting each other on the back thinking the whole community of bitcoin want altnets..
even in topics made by hundreds of people that want to discuss BITCOIN scaling (not LN)

there are thousands of topics regarding BITCOIN scaling and only dozens of topics about LN development

and its funny to see how angry the altnetters get when they get called out and their advert opportunity is wasted. they really hate it when they fail to convert people. and their PR campaigns get ripped apart.

its funny that even now you think this topic thread is related to lightning network.. maybe try to read the title

edit: to reply to below

You can't beat the idiot. The idiot is the strongest among all.

well you prove the opposite. its obvious you beat yourself every night.
its not an insult to your manhood. its an observation of your flip flopping contradiction that end up debunking yourself

[BlackHatCoiner]

You can't beat the idiot. The idiot is the strongest among all.

[Rath_]

Imagine you made 200 bitcoin transactions waiting to confirm. and 140 just never got confirmed.. people would call that a failure.

I have seen many unconfirmed transactions drop from the mempool. Does it mean that Bitcoin is a failure too?

but just having a system that doesnt make 70% of payments shows its not the 'instant payment' system

If the payment eventually goes through, the path-finding algorithm might as well be blamed. Those algorithms could favour larger nodes, which usually have enough liquidity, to speed up payments, but that would eventually lead to centralisation. Still, large payments usually take only a couple of seconds to complete.

Rath_ knows that the 'network gossip' park of route path finding is completely different to the invoice/payment things. so i truly laugh that he wants to pretend the fails are 'route finding gossip'

Liquidity is not advertised through gossip. So, the path is chosen based on its length and cost. As I have already said, I keep my fees fairly low which encourages wallets to include my node in the path. They don't know if I have enough coins on my side to forward the payment. If my node fails the payment due to no liquidity then they have to try another route.

[franky1]

Liquidity is not advertised through gossip. So, the path is chosen based on its length and cost. As I have already said, I keep my fees fairly low which encourages wallets to include my node in the path. They don't know if I have coins on my side to forward the payment. If my node fails the payment due to no liquidity then they have to try another route.

the path finding gossip. does not 'lock' invoice amount
there has never been or ever will be a 'payment fail' at the path finding gossip stage
a 'payment' attempt is not part of the path finding.

the route finding stage as you have just admitted does not show the active balance(available liquidity) of each channel along the proposed routes, it only shows the amount the channel had when it began. this amount never changes.

if it was able to lock funds at the path finding stage with no intent to pay.. then this would be an attack vector people would abuse to lock up all value on the network and never pay out.

the path finding protocol does not in any way set aside value in each hop of the route at the path finding stage.

what happens is a number of possible routes are found, where by recipient (pass the parcel hops) see how much is wanting to be sent. and they respond if they can deliver.. WITHOUT LOCKING THEIR OWN VALUE by passing the request on.
if they cant deliver they dont pass on the request. and so they don not become a viable route.

when viable routes are discovered, where origin payers software decides the cheapest fee route to follow. and then separately, then a payment is attempted. through that route it decided on.

no "payment fail" is caused by not choosing YOU as the route at this stage.
 payments dont fail at the path finding stage, because funds are not locked at the path finding stage.

as for the established route the payer does decide on. it begins a separate process of locking funds along this route. getting a return message of "funding locked" and then sending the channel_update after that.
channel_announce is completely different than channel_update
the path finding messages do not include any HTLC stuff, so no funds are locked, a response to a path find is not going to include a "funding_locked" message.

you are trying too hard to make it sound like (using bitcoin analogy) that bitcoin transactions in a pools mempool fail to confirm because peers failed to peer-handshake at the relay stage.

sorry but thats not why bitcoin transactions fail to confirm when in a pools mempool.

its now very clear that you dont know why payments fail (your admission).. but atleast admit that payments are not 100% successful every time. be a man

[dezoel]

(point being whether LN exists or not. if bitcoin fee's are $30+ a time, the amount of people using bitcoin daily declines as do those users desire and need to run fullnodes daily)

Ethereum fees are more than that and the amount of users increases. So, I guess it doesn't work exactly like that.

Yes the market doesn’t work that way, because if the market really works as some people thinks that it does, then by now there would have been a really huge change in the market. A lot of things would have changed by now and there would have been a lot of cryptocurrencies that would have overtaken the top cryptocurrencies such as Bitcoin and ethereum.

Bitcoin and Ethereum have had this issue of having a high transaction fee for quite a long time now, and there have been a lot of other options that have been provided in the market that offers lower transaction fees and also a faster rate of transaction.These alternatives were believed to overtake the major cryptocurrencies as soon as they came out, but this never happened. So that goes to show that this is not how it works in the market and you are right for that, 100%.

[Rath_]

what happens is a number of possible routes are found, where by recipient (pass the parcel hops) see how much is wanting to be sent. and they respond if they can deliver.. WITHOUT LOCKING THEIR OWN VALUE by passing the request on.
[...]
no "payment fail" is caused by not choosing YOU as the route at this stage.
[...]
the path finding messages do not include any HTLC stuff, so no funds are locked, a response to a path find is not going to include a "funding_locked" message.

What kind of messages in your opinion nodes use to signal that they are able to route a payment? funding_locked is used only to signal that the funding transaction has reached enough confirmations for the channel to operate safely.

The "path finding gossip" is used to maintain an up-to-date local graph of the network which is then used to construct (not test) possible routes. Path-finding is implementation specific; it is not standardised in any way.

You need to offer an HTLC via update_add_htlc to learn if your peer has enough liquidity to forward your payment.

How do I know that? Well, I can clearly see what's going on in my node's debug log. Here's what happens when my node does not have enough liquidity to forward someone's payment:

Code:

03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: peer_in WIRE_UPDATE_ADD_HTLC
03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: NEW:: HTLC REMOTE 408 = RCVD_ADD_HTLC/SENT_ADD_HTLC
03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: htlc added LOCAL: local 3828178009 remote 1171821991
03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: -> local 3828178009 remote 1074154247
[...]
037659a0ac8eb3b8d0a720114efc861d3a940382dcfa1403746b4f8f6b2e8810ba-channeld-chan#29: Failed to add 1 remove 0 htlcs
037659a0ac8eb3b8d0a720114efc861d3a940382dcfa1403746b4f8f6b2e8810ba-channeld-chan#29: Adding HTLC 1126 amount=97653097msat cltv=716528 gave CHANNEL_ERR_CHANNEL_CAPACITY_EXCEEDED
03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: FAIL:: HTLC REMOTE 408 = SENT_REMOVE_HTLC/RCVD_REMOVE_HTLC 

03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e asked me to forward a payment to 037659a0ac8eb3b8d0a720114efc861d3a940382dcfa1403746b4f8f6b2e8810ba, but I didn't have enough coins on my side in the outgoing channel. The rest of the log is much longer than that, but it mostly consists of signature generation and exchange.

its now very clear that you dont know why payments fail (your admission)..

I can tell when a payment fails due to no liquidity in one of my channels, but I can't tell the exact reason if the payment fails at some further point in the route.

[franky1]

(buzzwordatory:)the path finding gossip is not part of invoice exchange messages
(laymans speek:)finding routes is not part of payments

(buzzwordatory:)
pathfinding gossip uses
"node_announce" message which reveal which channels it owns.
    type: 257 (node_announcement)
    data:
        [signature:signature]
        [u16:flen]
        [flen*byte:features]
        [u32:timestamp]
        [point:node_id]
        [3*byte:rgb_color]
        [32*byte:alias]
        [u16:addrlen]
        [addrlen*byte:addresses]

"channel_announce" which reveals the partners of the node
    type: 256 (channel_announcement)
    data:
        [signature:node_signature_1]
        [signature:node_signature_2]
        [signature:bitcoin_signature_1]
        [signature:bitcoin_signature_2]
        [u16:len]
        [len*byte:features]
        [chain_hash:chain_hash]
        [short_channel_id:short_channel_id]
        [point:node_id_1]
        [point:node_id_2]
        [point:bitcoin_key_1]
        [point:bitcoin_key_2]

"channel_update" which reveals the fee's of the channels

    type: 258 (channel_update)
    data:
        [signature:signature]
        [chain_hash:chain_hash]
        [short_channel_id:short_channel_id]
        [u32:timestamp]
        [byte:message_flags]
        [byte:channel_flags]
        [u16:cltv_expiry_delta]
        [u64:htlc_minimum_msat]
        [u32:fee_base_msat]
        [u32:fee_proportional_millionths]
        [u64:htlc_maximum_msat] (option_channel_htlc_max)

htlc_maximum_msat is not the live available liquidity left. its the first 'state' value of the channel creation without revealing anything about liquidity/payments performed to adjust the balance available.

none of these three messages have anything to do with the payment. but everything to do with route discovery and choosing the cheapest route.

there are no payment fails at route discovery as no payment is 'locked' temporarily at route discovery

when building the route graphs its just a spam of "node_announce" and  "channel_announce" and "channel_update" messages back and fourth. and the software then looks at the possible routes that lead to the desired node

(laymans speek:)
like building a map of a road network and finding out the toll fee's along certain roads
the software then makes a decision about which route has the cheapest total(combined) fee of the route.

your debug log has nothing to do with the process i have mentioned about about the path finding stage..
so lets now explain the nest stage.. (separately)

SEPARATELY AND SECONDARY
then it performs the invoice exchange telling the route how much the payer wants to push forward including a public key(htlc) that requires a secret.(buzzword: update_add_htlc)
then the channels along the route lock up the value into this public key and send back a funding_locked response to say their LN iou msat promises are set..
 
when the payer receives the "funding locked" response(in regards to the LN iou promises) meaning everyone else along the route has also had the same, its deemed a valid route to complete a payment. and the payer sends the "secret" and this pass the parcel forward until the destination gets it.

an error at this stage IS a payment fail

as for your other comments in your post:
do not confuse the 'payment' temporary iou promises of LN with the open/close channel contract of bitcoin format when you try to refer to your version of understanding of the use of "funding_locked"

the open/close session contracts measured in sat are a different format to the temporary LN payment locks measured in msat.
"funding_locked" is used by both the open/close contract... and the temporary LN iou promises. but dont pretend they are the same thing or that the LN payments dont do this because you only know about the bitcoin open/close contract part

I can tell when a payment fails due to no liquidity in one of my channels, but I can't tell the exact reason if the payment fails at some further point in the route.

i know you cant tell.. but one thing you should learn. and understand. is that the fail is not due to the route discovery/path finding gossip stage. and not due to a payer just not choosing you because your fees are too high

it is not the case of "payment failed because they simply chose a different route"
the LN pizza example in 2018 was not scenario of 150 pizza orders with a spam of 1500 'payments' that never complete.

FOLD actually said they had 1500 food orders through dominos portal. but only got 10% payment
meaning 1350 pizza's were not delivered to peoples mouths. who had made a pizza order.

they DID NOT have 150 domino's orders and 1350 spam payments (10x the payment attempts than domino order requests)


a payment failure is not due to:
not establishing a full route to destination (meaning those intermediaries, halfway through map get forgotten)
deciding to try route A (meaning B is declared fail due to simply not taking that route) for reasons of less hops
deciding to try route A (meaning B is declared fail due to simply not taking that route) for reasons of less fees

a payment failure is a fail due to:
delays in messages expiring
   such as not sending the secret before htlc expiry
liquidity issues
   such as the liquidity being 'spent' by other pending payments before the current payment completes
wallet errors
   peer communication issues. loss of keys, going offline. bugs, faults with nodes, ddos

[pooya87]

taproot doesnt help scale bitcoin.
what it does is for those that produce bloaty transactions and even more so multisig transactions they can opt to put their value into a new multisig that can the reduce the 'weight' of the transaction.. thus may reduce some bloat.

Using OP_CHECKMULTISIG(VERIFY) is not "bloat" it is a normal and a very common usage that has existed from the day bitcoin was created and a large number of bitcoin users are using this OP code specially some of the services that make a lot of transactions.
With them switching to new OP code their transaction size and weight will both be reduced significantly.

[franky1]

multisig did not exist since the day bitcoin was created
it started as a Bip in 2012 and not introduced into wallet software until 2013. bitgo was the first wallet to embrace multisig


but my point was about.. taproot is not a thing that makes existing multisig/transaction formats smaller. its not a thing that make all transactions smaller

its a thing where people have to move their current bloaty multisig and bloaty 'scripts' and bloaty 'smart contracts' over to a new tx format only activated november 2020. whereby after putting funds into this new format. when they then want to move funds again after that. the transactions bloat would be less bloat than its previous tx format counterpart

meaning taproot doesnt make all transactions smaller, meaning peoples very next transaction will not be smaller.
it just makes people that usually use bloaty smart contracts/multisig have a option where they can move funds to a new format (same bloat next transaction) to lock into a special contract which has a smaller signature/script area for future movements, after that.. as long as the movements stay in the new format.

EG there is not much point moving funds from a legacy multisig, to a taproot if the taproot just then pays back out to legacy. because although that 1 TR->legacy was less bloat..  the legacy->TR was not.. and the future legacy there after wont be.

it only has a significance to overall bloat of blocks if a significant amount of users move into TR multisigs and stay in them when transacting.

it means people that used to post their mail in A4 envelopes. can decide in the future to start folding their contracts to fit into smaller envelops. it does not mean all A4 envelops are suddenly smaller. it just means for those that decide in the future to fold their contracts to fit into a smaller envelope. will get to pay smaller postage. as long as they keep folding their contracts up into smaller envelopes. and the postage saving only really works with contracts(transactions) that usually have more then one signature in the first place