Hi Laolu,
> ignoring the rules leads to assets being burnt, but in most cases imo
that's a sufficient enough incentive to maintain and validate the relevant
set of witnesses
I agree it is sufficient, but only because using Bitcoin script without an
additional scripting language inside of Taro is
Hi Laolu,
>happy to hear that someone was actually able to extract enough details
from the RGB devs/docs to be able to analyze it properly
Actually, even though I eventually puzzled everything together, this did
not go well for me either. There is a ton of documentation, but it's a maze
of unhelp
Hi Laolu,
Nice work. This is an interesting protocol, in my opinion.
Seeing as there's a large amount of overlap with RGB, a protocol which I
have examined quite extensively, I believe some of the issues I uncovered
in that project also apply here.
The biggest issue revolves around the scripting
Hi Jeremy,
Thanks for sharing your thoughts.
To summarize your arguments: the intentionally malicious path to getting
the 0 sat output confirmed without being spent is uneconomical compared to
simply creating dust outputs. And even if it does happen, the tx spending
from the 0 sat output may stil
Hi Jeremy,
I brought up the exact same thing at coredev, but unfortunately I came up
with a way in which the 0 sat output could still enter the UTXO set under
those rules:
- Parent P1 (0 sat per byte) has 2 outputs, one is 0 sat
- Child C1 spends the 0 sat output for a combined feerate of 1 sat p
