Topic: Lightning Labs just made "Taproot Assets" v0.2 a BRC20 alternative. (Read 366 times)

Alex Bosworth today tweeted a standard for taproot asset channels that has been submitted to the lightning network specification repository


https://twitter.com/alexbosworth/status/1702350630537585113

from the following github link you can see everything else:

https://github.com/lightning/blips/pull/29/files

Been working in fintech (and then later crypto with a big question mark) and it does seem that this lack of social skills is not uncommon with developers, or the C-level suits heading these companies/projects... sometimes I wonder even if deliberately so.

Used to wonder why these Bitcoin sides seemed to take forever to take hold, even looking back at RSK days (and when picked up again result in Ordinals heh). Today I "understand" it's really because "core" simply doesn't see it as critical, and I'm inclined to agree.

Most recently am curious about Drivechains but also the private key-based products developed by Synonym (though I suspect it has Bitfinex links)

Yes it does. The co-founder and CEO of LayerTwo Labs is Drivechains creator Paul Sztorc, https://layertwolabs.com/about

He's brilliant developer, but regarded as a cry-baby by the Bitcoin community because, in conferences, it's the way he complains why BIP-300/301 are not being considered by the Core Developers. It's just he lacks some social skills in my opinion.


Technically not a bug. But if it's a bug in your opinion, then it's a feature to someone else's opinion.

Yes, you cannot do "public key recovery", because:
1. The way how signatures are made, makes it hard to do it in the same way as for pre-Taproot addresses. If you have some output with a script " OP_SWAP OP_CHECKSIG", it works for pre-Taproot public keys, but it cannot be done for Schnorr signatures.
2. You don't need to recover any key, because Taproot address is used to encode your compressed public key directly, and it is automatically assumed that it has "02" prefix.
3. If you have more than one party, then after aggregation you only know the public key for the combined signature, you don't know which public keys are used in the middle, because if you know that the result is "10", then you don't know if it was "2+8" or maybe "3+7", or even "2+3+5".

I didn't say you wrote this I'm just motivating my comment.  If you read what I wrote then you should understand.

With regards to the layer 1 and not to any auxiliary layer such as LN, I thought the whole (or at least one of the main) purpose of Taproot addresses was that the Schnorr signatures used to make Taproot transactions prevent public key recovery in the first place.


Where did you get that quote from, because as far as the OP topic is concerned, I never wrote those things.

Yes, of course. It is called "public" for a reason.

No, because if you want to make a multisig, which could be properly aggregated, then you need public keys. Even if you have some LN channel, and on-chain there is some P2WSH, then still, another party in your channel has to know your public key.

So, when you are using a taproot address, you are actually revealing your public key? Are we going backwards now?

I very much agree with you that ordinals are a waste of space in the block, but regarding the question of LN development I had already mentioned it in my thread that in my opinion we don't need new portfolios because we already have so many and those can be improved but more applications are needed.  For example there are many apps (I say some at random) Uber, Ebay or less common sites that use PayPal or credit cards or new payment systems always through Fiat, instead if we were able to implement a payment through LN that would be the real victory .  Think of all the unbanked people in the world who can't even use these apps, with LN everyone could.

I know I commented in some places that all this live money on these tokens is preventing us from pulling the plug, but come to think of it, if we can get even a slice of these users to dump their spam on some off-chain protocol instead, using one of the new technologies, then that would be a good time to push a "deprecation" of unlimited Taproot data size and eventually shut it down on the rest of those BRC20 holdouts. Whatever "live money" is left on these tokens can be treated the same way as (hypothetically) legacy ECDSA bitcoin addresses that are disabled in a post-quantum world.

Because the general sentiment of the dev mailing list, is that currently nothing is going to happen. Perhaps they are thinking that because they might still see a use case in unlimited Taproot witness size.

Now with these alternate technologies springing up like Taproot Assets, Ark, and others, when people eventually script those things creatively on those protocols, it will hopefully be agreed on by core devs that nobody has actually used Taproot witness size for anything useful and go along with its deprecation.

Lightning would be a nice way to solve this BRC-20 bug problem. I am in favor of moving these transactions off chain. I saw this article a few days ago.

Unfortunately, wishing it onto the Lightning network won't make it happen.

1. The Lightning network has less than 5% of transactions, by volume. It's not being used. Moving this to Lightning would at best only solve 5% of the problem.
2. Wind FURY nailed it. This spam only has value because it is being immortalized in something valuable - the Bitcoin blockchain.
Unfortunately, this is coming at the cost of Bitcoin's original purpose as a peer-to-peer method of exchange. It is destroying it's value.
This bug is acting more like a parasite that is killing it's host.
Lightning is not a real solution and this BRC-20 bug needs to be patched.

Not untrue. Surprised me a many years back to hear some people "had Bitcoin" on eToro until I learnt later it was heavily advertised in London.

First wallet I ever used was Electrum, quite literally because the first legible guide I liked and thought was the most useful and not annoying said to use Electrum. It's still the one I use today, but if I hadn't heard of Ordinals from this forum first, I'd be using OrdinalsWallet (which is what Google shows first and what YTers seem to like).

So you're right. If LL's new Taproot Assets proves to be as good and easy to use as claimed, and is picked up by the YTers and influencers etc.


That anything to do with BIP300, 301 I'm hearing about lately?

OP, but the problem, Ordinals/NFT users want to store their dick pics and fart sounds in a bank vault, not in a museum. They believe it's part of the attraction, and part of what makes them "more valuable".

BUT I believe some of them, especially the plebs, will concede that the inefficiency and the fees are not worth the costs on their capital. It also gives speculators some opportunities to do some shitcoinery.

Stacks has a token, STX, which might surge during the next bull cycle, and there's also another offchain/layer 2 network called MintLayer, which will have its own token soon. The most compelling one is LayerTwo Labs. No token, just Drivechains, https://layertwolabs.com/

Nah it's definitely in-place , the more software that supports Taproot Assets, the smaller the chance some minter discovers BRC20 minting software which is currently hosted on only a few online webapps.


Don't worry about it (for now). The current crop of shitcoiners are using BRC20 to transact via (drum roll please....) exchanges.

That means the BRC20 transactions that are being done between users in these marketplaces are completely custodial. So in this particular case, the exchanges will definitely set it up as the sender interacts with the exchange who then sells the asset to the exchange, and the buyer does the same. Especially those who want to make "NFT marketplaces". Because exchanges always want to make fat commissions. This arrangement inadvertently works in our favor.

Thanks @vjudeu for explaining. This seems indeed very similar to RGB then where you use transactions only for commitments (not for data publication), even if RGB is more "general" and not so much focused on tokens/assets. If I understand correctly then, the idea is keeping most data off-chain as long as possible, and only in case of a conflict pushing it onchain.

I'm currently reading some more text about Taproot Assets and would like to emphasize that Taproot Assets has also a disadvantage. It seems it is necessary that payment senders interact with the receiver before a payment occurs, the receiver has to generate an address containing the hash of the Taproot script (in a similar way like with P2SH, but they have to provide some "private" data so that address can't be generated from the sender alone, if I understand correctly) before a payment can be sent. That's of course solvable by technology but the payment receivers have to be online every now and then, although probably not as much as with Lightning invoices/transfers (where sender and receiver afaik have to be online at the same time during the transaction).

i don't know if this belongs to this particular topic, but there is now the polar v2.0 release which now also supports the taproot assets protocol daemon (tapd) nodes. if it is out of place here i apologize and you don't need to pay attention to it...

https://github.com/jamaljsr/polar/releases
https://lightningpolar.com/
https://github.com/lightninglabs/taproot-assets

I can confirm that. If you have a commitment, then it can contain anything, even as large as 1 GB file, and it can be created, passed to someone, or destroyed. The only thing that goes on-chain is the connection between your data, and your Taproot address. However, because that connection is based on public key alone (and is never pushed on-chain), nobody knows if something is connected or not, if you won't tell them. Also note that you can easily detach any data, just by moving it once into some address that contains no commitments.

Yes, any commitment can be stored behind some public key. And then, revealing that public key alone will not tell someone, if it is just some regular key, or if it contains some hidden commitments. For that reason, nodes in the middle don't know if they are processing any other assets than just coins or not.

Taproot Assets is a highly interesting technology, but what I was missing until now was a really good "ELI5".

I've found this video now (it's already a year old so I simply missed it), so I'll describe in this post what seems to be the main benefits of TA with respect to competing technologies (not only BRC-20 but also systems like Counterparty or OmniLayer).

1) TA transactions look like regular Bitcoin (Taproot) transactions, which increases privacy. Due to the structure of transactions, a "Merkle Sum, Sparse Merkle Tree" (MS-SMT) embedded in a Taproot tree, it is easy to realize proofs (e.g. about token balances/quantities) without revealing other information like the transaction history.

2) TA transactions can transfer multiple kinds of assets or tokens at a time, as they can all be stuffed into a MS-SMT. This also allows to issue tokens to multiple accounts in single and relatively small transactions. Thus also on-chain TA transactions need less blockchain space than the competitors. (I am not 100% sure about the first part, maybe somebody can confirm this )

3) There is a way to transfer TA assets over Lightning without all nodes between sender and receiver needing to support TA. As far as I have understood it, you need to be connected to a node which can do an atomic swap to Bitcoin, then route through Bitcoin Lightning nodes until another TA atomic swap node connected with the receiver of the payment. Basically you do 2 exchange operations in such a transfer, but as they're all instant it doesn't feel complicated. This looks however that some significant fees could be needed for the swaps, but for sure that depends on the liquidity of the token.

What would be also interesting for me are common characteristics and differences with RGB (another Lightning-supporting token/smart contract protocol). The RGB documentation is even more technical than TA's, and it seems it's an even more abstract/low level protocol than TA. It was said that TA took some concepts from RGB and the dev team was even accused of plagiarism, but I don't know the details so I don't want to adhere to this claim or not

Well, finally. I hope all that NFT crap migrates to LN ASAP. I was going to send some BTC to another wallet today and my wallet kept telling me minimum fee not met. It turned out minimum fee today was about 18sat/byte! If the fee is lower than that, blockchain won't even accept the transaction! For my amount (not big) this fee was about 7-8% which was about 10% of the amount. I guess that's even more expensive than Paypal 
 

I've been saying it all along: do this stuff on Lightning using RGB or Taro! It's better for everyone. Cheaper and faster for NFT users, no mempool congestion for L1 users who just want to efficiently spend / receive Bitcoin as well as Lightning operators that need to open new channels.

In case this motivated anyone to finally spin up their own Lightning node; here's my obligatory pitch (since the topic always gets pushed down quickly) for my (usually) up-to-date FULL NODE installation guide.