Blockstream Green to Become the Blockstream App

[Pmalek]

This development of theirs gives more importance to the Liquid Network and also to Simplicity smart contracts. That was the idea. The Liquid sidechain isn't trustless like Bitcoin. I don't know about Simplicity, though. But history has shown that some smart contracts were badly developed and created huge problems.

One interesting part of the blog post says that the outputs protected with quantum-resistant Simplicity smart contracts don't cost anything until they are spent. Blockstream and Liquid might be looking to earn money with this.

[dkbit98]

The latest Blockstream desktop version was updated to 3.1.0 a few days ago. You can now receive L-BTC via the Lightning channel or pay Lightning invoices using L-BTC. Another newly added feature enables swapping between BTC and L-BTC.

Aqua wallet added this same feature long time ago, not that I use it.

Blockstream claims that they have deployed a new signature verification scheme that includes protection against quantum computer threats. It's supposedly live on the Liquid network thanks to the Simplicity sidechain, using SHRINCS (optimized hash-based sigs). It should enable protection of Liquid Bitcoin and all other tokens on the Liquid network.

They can do that because it's much easier to change anything on liquid chain, unlike on bitcoin blockchain.
Still I don't think L-BTC on Liquid is safe simply because Liquid is federated blockchain, they can literally change anything they want.

[Pmalek]

They can do that because it's much easier to change anything on liquid chain, unlike on bitcoin blockchain.
Still I don't think L-BTC on Liquid is safe simply because Liquid is federated blockchain, they can literally change anything they want.

That's a compromise that users have to accept if they decide to use liquid bitcoin or any of the other tokens available on that network. Bitcoin is decentralized, but moves at the speed of a snail when it comes to upgrading and voting in new features. Liquid is a more centralized network, but they keep increasing the number of federation members, which is a good thing. The more parties there are, the less chance of a collusion for nefarious purposes.

[internetional]

Blockstream App is a non-custodial and open-source (so they say)

"So they say" is a very appropriate qualification - and not only regarding the open-source claim, but also the claim of being non-custodial. When it comes to holding bitcoin in Lightning Network channels, I would not agree that it is truly non-custodial. At least, Blockstream Green wasn't.

I used Green for Lightning in the past, and at one point I ran into a situation where, after a force-close of a channel, my funds were sent to an address that was not controlled by my seed phrase. Recovering those funds required about five months of back-and-forth with Blockstream support, and most of my messages were simply ignored during that time.

Lightning->Liquid submarine swaps are much safer than direct Lightning channels in Greenlight architecture.

[Forsyth Jones]

On the iPhone app, it's taking a long time to access the wallet after entering the PIN... it shouldn't be like that. I haven't yet checked if it accesses without internet.

Here they explained what they actually did.

They didn’t wait for the relevant Liquid consensus and instead used Simplicity to design custom spending conditions that can be signed with PQ signatures using one of the SHRINCS variants they developed for this purpose.

A smart approach, to say the least.

Although I haven't delved into the subject in detail, it's a good addition to prepare for possible future threats. However, from what I understand, it only benefits assets on the Liquid network, while on Bitcoin it depends on the network's general consensus.
Using Liquid assets is very good, it's a shame that very few exchanges support it.

[mikel_012]

Blockstream claims that they have deployed a new signature verification scheme that includes protection against quantum computer threats. It's supposedly live on the Liquid network thanks to the Simplicity sidechain, using SHRINCS (optimized hash-based sigs). It should enable protection of Liquid Bitcoin and all other tokens on the Liquid network.

https://x.com/blksresearch/status/2029225084876189900

Here they explained what they actually did.

They didn’t wait for the relevant Liquid consensus and instead used Simplicity to design custom spending conditions that can be signed with PQ signatures using one of the SHRINCS variants they developed for this purpose.

A smart approach, to say the least.

But if every liquid Bitcoin is pegged to real Bitcoin, if Bitcoin gets attacked by quantum computers isn't liquid losing the backing and making it useless anyways? I don't understand a lot so about the technical parts of this, so this is a honest question I have

[nc50lc]

-snip-
A smart approach, to say the least.

But if every liquid Bitcoin is pegged to real Bitcoin, if Bitcoin gets attacked by quantum computers isn't liquid losing the backing and making it useless anyways? I don't understand a lot so about the technical parts of this, so this is a honest question I have

The answer is simple: Not every Bitcoin UTXO will be susceptible to quantum computers in the future.
Mostly those that have their public key exposed (e.g.: P2PK or reused addresses) are the ones that can be attacked with a reasonable chance.
And "Peg-in address" aren't recommended to be reused and don't have their pubKeys exposed to the public.

If real-time attack is your concern (e.g.: up to 10minutes average, right after broadcasting the transaction).
I believe Bitcoin should already have implemented some QC-proof scripts by then,
Even before a month-long attack become possible, there should already be QC-proof scripts that they can migrate to.

Not to mention, the attacker must do it 11 times since it requires 11 signatures out of the 15 public keys to spend before the timelock.

[satscraper]

Blockstream claims that they have deployed a new signature verification scheme that includes protection against quantum computer threats. It's supposedly live on the Liquid network thanks to the Simplicity sidechain, using SHRINCS (optimized hash-based sigs). It should enable protection of Liquid Bitcoin and all other tokens on the Liquid network.

https://x.com/blksresearch/status/2029225084876189900

Here they explained what they actually did.

They didn’t wait for the relevant Liquid consensus and instead used Simplicity to design custom spending conditions that can be signed with PQ signatures using one of the SHRINCS variants they developed for this purpose.

A smart approach, to say the least.

But if every liquid Bitcoin is pegged to real Bitcoin, if Bitcoin gets attacked by quantum computers isn't liquid losing the backing and making it useless anyways? I don't understand a lot so about the technical parts of this, so this is a honest question I have

Yeah, you are correct and Blockstream admits this:

Blockstream framed what they did as the " first building block" for PQ resistance

[Pmalek]

But if every liquid Bitcoin is pegged to real Bitcoin, if Bitcoin gets attacked by quantum computers isn't liquid losing the backing and making it useless anyways? I don't understand a lot so about the technical parts of this, so this is a honest question I have

Yes, of course. If the value of the real bitcoin drops drastically against the USD, for example, the same would happen to the value of liquid bitcoin as well. There can't be a situation where BTC goes down to $50k but LBTC goes up to $100k. All wrapped bitcoin tokens would suffer in the same way because the underlying asset's price has gone down.

[mikel_012]

The answer is simple: Not every Bitcoin UTXO will be susceptible to quantum computers in the future.
Mostly those that have their public key exposed (e.g.: P2PK or reused addresses) are the ones that can be attacked with a reasonable chance.
And "Peg-in address" aren't recommended to be reused and don't have their pubKeys exposed to the public.

If real-time attack is your concern (e.g.: up to 10minutes average, right after broadcasting the transaction).
I believe Bitcoin should already have implemented some QC-proof scripts by then,
Even before a month-long attack become possible, there should already be QC-proof scripts that they can migrate to.

Not to mention, the attacker must do it 11 times since it requires 11 signatures out of the 15 public keys to spend before the timelock.

Thank you for the answer. So you are saying the chances of losing money with LBTC are tecnically lower than just storing BTC if a quantum attack happens? Or not reusing my address because of exposed public keys is enough to not get my coins at risk in the future?

[nc50lc]

-snip-

Thank you for the answer. So you are saying the chances of losing money with LBTC are tecnically lower than just storing BTC if a quantum attack happens?

Not at all.
I simply mentioned that their peg-in/peg-out scheme shouldn't be a problem for now and strong enough to give them time when QC become a real-world problem.
As for losing your BTC/LBTC, it depends on how users expose their addresses' public keys.
If done correctly, even if it's just a single-sig address compared to 11-of-15, they'll have no problem hodling Bitcoins even in the near theoretical future when there are already fast enough QC.
At least not as fast as mining a block on average which the network will not wait to happen before implementing an upgrade.

[Pmalek]

Or not reusing my address because of exposed public keys is enough to not get my coins at risk in the future?

Not each reuse of a bitcoin address is the same. There is no problem if nc50lc sends bitcoin to an address you give him and then I send BTC to the same address. You can receive coins to the same address numerous times. That doesn't affect the exposure of your public key. Your public key only becomes public when you make a transaction and send BTC out from that address we sent to. If you don't spend all of your outputs, a QC could in theory make that address and the remaining BTC vulnerable and brute force the private key from the exposed public key.

[satscraper]

Today we got new release of  Blockstream App, version 3.4.0. Notably, it adds support for paying BOLT12 Lightning invoices and introduces several Lightning UX improvements confined in LNURL. It’s also worth mentioning that  Blockstream App now supports human‑readable addresses according to BIP353.

[Pmalek]

It’s also worth mentioning that  Blockstream App now supports human‑readable addresses according to BIP353.

I don't remember there being much talk about the BIP-353 standard on Bitcointalk, but that's those addys that resemble email addresses if I am not wrong. For example, pmalek@something.com. BIP-353 has already been around for some time. I am surprised that the Blockstream App didn't add support for the standard earlier, considering their focus on L2s. Maybe because they are mainly focused on the Liquid Network and not Lightning.

[satscraper]

I don't remember there being much talk about the BIP-353 standard on Bitcointalk, but that's those addys that resemble email addresses if I am not wrong. For example, pmalek@something.com.

Yeah, you're correct. Wallets that support BIP-353 should have the ability to parse human-readable addresses, as you mentioned. But the interesting thing is that Matt Corallo, who proposed this BIP, highlighted that such wallets when handling  payment instructions must not give privilege to these addresses when standard Bitcoin addresses are available.

[Pmalek]

Yeah, you're correct. Wallets that support BIP-353 should have the ability to parse human-readable addresses, as you mentioned. But the interesting thing is that Matt Corallo, who proposed this BIP, highlighted that such wallets when handling  payment instructions must not give privilege to these addresses when standard Bitcoin addresses are available.

Human-readable addresses are just an alternative or a backup, but Matt never intended them to replace standard bitcoin addresses. BIP-353 adds new complexities, validation, and DNS lookups. Standard addresses present a direct route or destination. If no other payment instructions are available to the person making the payment, than the human-readable form is ok. It's not superior, though.