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

Many Bitcoiners have heard of Bitcoin’s “lack of scalability” — it is one of the most common critiques waged against the project by both gluttonous cryptocurrency competitors and incumbent establishment actors.
Some oldtimers may remember the heated, bathed-in-controversy Blocksize Wars of 2015 to 2017 which, aided by industry insiders, most shallowly aimed to make Bitcoin scale to more transactions by increasing the maximum block size and by doing so, almost set precedent and changed Bitcoin’s future course forever.
Both of these issues will ultimately prove to be left on the wrong side of history. In this piece, we are going to show how the Lightning Network addresses Bitcoin’s scalability problems and undoubtedly proves that the small-block decision was ultimately the right one.

liquid

IN LN and im not talking about session close events. im talking about within LN

even the update is not saved to your ram/hard drive in a bitcoin TX format

msats

if you are still thinking "lightning" is and only is bitcoin then you have major learning to do

https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#the-open_channel-message

The [chain_hash] value denotes the exact blockchain that the opened channel will reside within. This is usually the genesis hash of the respective blockchain. The existence of the [chain_hash] allows nodes to open channels across many distinct blockchains as well as have channels within multiple blockchains opened to the same peer (if it supports the target chains).

"lightning funds"
well you can open a lightning channel using litecoin and other currencies..

if you are still thinking "lightning" is and only is bitcoin then you have major learning to do

Literally every channel close transaction ever. Not Onion packets, but the channel state updates that are exchanged through them; those are simply valid channel close transactions that you can publish.

Would you argue that any Bitoin script that is not the regular OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG P2PKH transaction, 'is not Bitcoin'?

Lightning is nothing more than a different (but totally standard and accepted - otherwise it would be impossible to close channels - Bitcoin script) and exchanging updates of the spending transaction in an off-chain manner.

That makes no sense. When updating channels, you don't do much more than updating a spending transaction for both peers. If there is no blockchain to create transactions on, the whole thing doesn't work. The blockchain is absolutely necessary.

If Lightning funds 'are not Bitcoin', what do you think happens when opening a Lightning channel? Funds are burned? And what happens when you close it? They reappear out of thin air into your wallet? It's a script. Lightning is just a Bitcoin script. It's not that complicated..

The [chain_hash] value denotes the exact blockchain that the opened channel will reside within. This is usually the genesis hash of the respective blockchain. The existence of the [chain_hash] allows nodes to open channels across many distinct blockchains as well as have channels within multiple blockchains opened to the same peer (if it supports the target chains).

I agree, also meanwhile feel free to have a look at @metiaisland_gg on twitter

dare you guys to try to take a onion packet (LN payment) and get it confirmed on the bitcoin network
i guarantee you it would even relay around the nodes, it wont end up in mempools and wont be put into a block.
LN payments are not bitcoin nor even measured in anything bitcoin understands

LN network can continue running with channels and making payments even if there was no bitcoin "locks" pegged to channel payments because the channels would still make payments using different currencies pegs.. so yea LN hint is in the N of LN is a different network and not bitcoin

bitcoin does not ever leave the bitcoin network. it relies on locks and pegs.. and LN has no network wide consensus to audit/account/secure those pegs/locks. so LN users need to be risk aware of methods where their co-partner of channel can use and abuse LN features to break those locks/pegs to steal funds from the other person. and yep there are many ways to lose value due to those weak mechanisms

im saying be risk aware when using it and not think that its as secure as bitcoin
just be smart and not utopian dreamy. understand the difference between LN vs bitcoin. there is alot of differences..

Back to Lightning network.
A very nice thread on BOLT 12:
[...]

Has anyone of our Lightning node operators here tried BOLT12 Offers yet?
[...]

BOLT 12 is a sleeping giant.

But 99% of Bitcoiners don’t understand it yet.

In this thread, we’ll break it down as simply as possible:
Firstly, what is a BOLT?

BOLT stands for Basis of Lightning Technology

It’s a type of draft specification, similar to a BIP.
BOLT 12 is being developed on @Blockstream’s c-lightning by @rusty_russel

When finalized, it will need to be implemented by either eclair @acinq or lnd @lightning to be considered ‘activated’
So what problems does BOLT 12 solve?

To answer this question, let’s take a look at the current invoicing protocol on Lightning, BOLT 11

BOLT 11 Invoices have three main components:

1. A Destination(Node pubkey)
2. An amount(denominated in sats)
3. A payment secret(hash)
So what are the limitations of BOLT 11?
Image
1. A BOLT 11 invoice can only be used once. As soon as the invoice is created, the payment secret can be leaked. If you were to create a new invoice with the same secret, someone could discover the secret and claim funds that aren’t theirs.
2. Because each invoice can only be used once, they must be generated in real-time. This means that BOLT 11 invoices aren’t ideal for donation pages, printed price tags, and other asynchronous payment scenarios.
For example, if you were selling apples in a grocery store and printed price tags on them denominated in sats, the USD value may increase before someone buys your apples. This leaves merchants exposed to BTC’s volatility until BTC is widely adopted as a unit of account.
3. BOLT 11 invoices can only be used to receive, not send. This prevents the use of credit invoices.

For example- a BOLT 11 Lightning ATM would not be able to send you sats in exchange for dollars, you would have to create an invoice and send it to the ATM(not ideal UX).
With BOLT 12, you would insert your fiat dollars, scan a QR code, and the ATM would pay you.
To summarize:

BOLT 11 invoices can only be used once(insecure)

They MUST be generated in real-time(bad for donations, price tags)

BOLT 11 invoices can only be used to receive, not send.
So what’s BOLT 12?

In short, BOLT 12 is a new specification for Lightning invoices.

It consists of a new type of invoice called an “offer”.



You can think of an offer as a ‘meta’ invoice- an invoice on top of an invoice.
You can scan a BOLT 12 offer and your wallet will prompt you to pay it, just like BOLT 11.

But it could also offer to send YOU money, like in the ATM example above.
Unlike a BOLT 11 invoice, you can reuse them to create static Lightning invoices on donation pages, billboards, or even a tattoo(although, tattoos aren’t recommended until the BOLT is fully ratified😂)
Now you’re probably thinking, “this sounds a lot like LNURL. Why not just use that?”

The main difference is that BOLT 12 offers are Lightning-native, i.e- they do not require a web server, TLS certificate, and a domain name.
BOLT 12 is a protocol layer solution to the invoice problem, while LNURL is an application layer solution.

This means BOLT 12 has better privacy, less centralization risk (DNS), and better UX for non-technical users.
What can we use BOLT 12 for?

1. Subscriptions.

BOLT 12 offers can ask users to pay an invoice every day, week, or month(denominated in USD or sats)

Wallets still need to build out this functionality, but the infrastructure will be in place.
2. Bitcoin Lightning ATMs

Offers can send you money in the form of a credit invoice.

This was previously impossible, and allows for better UX, which leads to adoption.
3. Private Refunds

Instead of a user creating an invoice and sending it to a merchant for them to pay, a user can scan a ‘refund’ offer and receive their sats without creating their own invoice.

This is more private for the receiver, and has better UX overall.
TLDR:

BOLT 12 is a draft specification for a new ‘meta’ invoice called an offer.

Offers are static, and allow users and merchants to both receive AND send.

Because offers are persistent, and can be denominated in USD, they remove BTC volatility for merchants.
BOLT 12 has many other features, including privacy enhancements, that were outside the scope of this thread.

Comment below if you want a part 2!

Thanks for reading, and follow us for more.
Additional Resources:

bolt11.org

bolt12.org

dare you guys to try to take a onion packet (LN payment) and get it confirmed on the bitcoin network

i guarantee you it would even relay around the nodes, it wont end up in mempools and wont be put into a block.

LN network can continue running with channels and making payments even if there was no bitcoin "locks" pegged to channel payments because the channels would still make payments using different currencies pegs..

bitcoin does not ever leave the bitcoin network. it relies on locks and pegs.. and LN has no network wide consensus to audit/account/secure those pegs/locks.

Eeh.  I dunno.  How many funds are there?  The advantage to a custodial wallet is you have pros handling the nodes.  Of course NYKNYC and all that.  Also, you can easily switch them back over to BTC. 

One clever way to do it is Coinos.io, though I think now they charge a fee?  I will do it for free if you prefer, too.  But you'll have to TRUST me for a moment.

Franky's argument that Bitcoin on Lightning is not actual Bitcoin, actually has its own complete 13-page thread, and I think periodically bringing the question back up in random discussions is just off-topic.

I am ignorant, as I am not currently aware of any implementation of LN outside Bitcoin.

And many statement you describe above, are not bug of LN, but actually feature.

On a personal level, I realize that I probably put too many funds in the lighting network portion of my BlueWallet because I had thought that I was going to be using it to experiment, and so far I have not experimented too much, so those funds are mostly just sitting there rather than being used.. and if I hear about some kind of issue with LN, I start to consider whether I might need to move some of those funds into a different location.

I am ignorant, as I am not currently aware of any implementation of LN outside Bitcoin.

lightning is not a "bitcoin layer 2"

lightning is a separate network where multiple crypto's can lock value and peg in some Msats to be transfered within LN

Agree with this.  But also get the set up comment.

The op_return message is informative.  There has been speculation (founded or not, I have absolutely NO idea) that Lightning Labs has connections to some fairly anti  bitcoin-ethos organizations.

https://www.weforum.org/organizations/lightning-labs

"You will use CL and be happy"  Sound familiar?

One could consider the development of "stable coins" on a bitcoin layer 2 could be dubious.  Many have said as much.  I am personally ambivalent.  But at the same time Blockstream is doing the exact same thing ALREADY with Tether on Liquid.  But they do not have a WEF page.

Anyway... totally agree that competition is a good thing.  Though at the same time when we are talking about money it certainly has it's risks.

One could consider the development of "stable coins" on a bitcoin layer 2 could be dubious.  

Having competing LN implementations seems like a set up? I don't think so; a healthy competition is the best driver of innovation, which is exactly what Lightning is all about.

Seems like a set up from my point of view.  Lightning network is likely starting to become big enough to "pay attention" to it from banks, governments, bitcoin naysayer, even shitcoiners... Yes.. try to create divisiveness within bitcoin, whether it is about aspects of lighting network and lack of confidence or their other nonsense attacks regarding energy and the loveliness of proof of stake..   Hopefully the various implementations and transactional options that we have available continue to get stronger..

Anyone else watching the CL vs LND throw down of the geek-chicks on Twitter?

Well, they have made up and hugged already.  

But the overly cute @starkness and the eccentrically inscrutable, feminist, gem lover @niftynei have been tossing 'WTF's at each other in the wake of LND's vulnerability discovery.  

Well, Lightning labs has issued an update at this point.  And YOU SHOULD UPGRADE IF YOU HAVE NOT ALREADY.

0.15.4 is safe, and the latest.

The attacker (supposedly) put op_returns into blocks saying something like "You will run CL, and you will be happy".

Personally? My experience?  My CL node has been less vulnerable to error, but not at good at at routing than my LND node.

I hope the two implementations compete/cooperate/bicker/jello-wrestle forever!  Keep it up!

Oh, and I did not forget about you eclair!!! yOU THERE?  hELLO?  wAKE UP!