Hi Laolu,
Yeah, that is definitely the main downside, as Ruben also mentioned:
tokens are "burned" if they get sent to an already spent UTXO, and
there is no way to block those transfers.
And I do agree with your concern about losing the blockchain as the
main synchronization point, that seems in
Hi Johan,
I haven't really been able to find a precise technical explanation of the
"utxo teleport" scheme, but after thinking about your example use cases a
bit, I don't think the scheme is actually sound. Consider that the scheme
attempts to target transmitting "ownership" to a UTXO. However, by
Hi,
I wanted to chime in on the "teleport" feature explained by Ruben, as I
think exploring something similar for Taro could be super useful in an LN
setting.
In today's Taro, to transfer tokens you have to spend a UTXO, and present a
proof showing that there are tokens committed to in the output
Hi Hiroki,
(inserting the bitcoin-dev mailing list as this question is mainly
concerning on-chain interaction)
Thanks for taking the time to really dig into things!
> When trying to verify the provenance of a given UTXO, it is necessary to
> verify the state transitions of all transaction graphs
(this might be a double post as I ran into the size limit)
Hi Alex,
Thanks for taking a look at things!
> If that's the case, did you look at other mechanisms to commit to a merkle
> root? For example, I believe mainstay[1] uses a
> pay-to-contract/bip175[2]-like scheme to commit sidechain merkl
Hey Laolu,
Really interesting protocol. I'm not all the way through all of the docs
yet, but had a few questions/comments:
- The top-level doc (
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki) talks
about embedding overlay metadata in the taproot script tree. From my
reading, it
