-
Notifications
You must be signed in to change notification settings - Fork 26
Possible conflict of pay-to-contract schemes with Taproot #61
Comments
I really have to catch up on Taproot since I don't know much about it, but my initial impression is that doing this would require to break an hash function: in our pay-to-contract scheme we would only commit to the hash of a proof, and many of its fields are controlled by the "sender" (which, if I understood correctly, should be the victim in the model you described). So, the attacker would have to craft and "address" such that, once embedded into a proof (possibly with some data he doesn't know yet) will make the hash of the proof an executable, malicious, Bitcoin SCRIPT. Now I'll go study and come back later when I fully understand how Taproot works ;) PS: if you have any good references/articles please let me know here or via DM at twitter.com/afilini |
Oh, and about your suggestion of making small Bitcoin amounts: I was thinking about it while writing the slides for the Berlin Lightning hackday a couple of days ago.. Speaking for the Lightning part, my idea was to force the payment of fees on the underlying Bitcoin layer, to reduce the amount of data we have to gossip around (we already have Bitcoin fees and asset/Bitcoin exchange rate). In this model, in order to have proportional fees, you would need to use the exchange rate to estimate the value of the asset being moved in Bitcoin, and then apply the Bitcoin proportional fee to it. If this is really what we end up doing (I honestly don't really like it but I don't have any other solution yet) you would need pretty "big" Bitcoin channels to transport "big" RGB proofs, otherwise you wouldn't have enough liquidity to move the tokens. Link to the talk if you are interested: https://youtu.be/QrX1SpD6l9g?t=5h9m47s |
It may be possible to do so opportunistically. For instance, if the first two bytes of the hash are Of course, it is possible that Taproot will also use a hash to further protect the Bitcoin SCRIPT and make such reinterpretation much harder with high probability. I have not seen enough details on the low-level of Taproot myself, perhaps it may also use a hash around the script before concatenating with the pubkey and hashing again. It may be useful to ask gmax or similar if this concern is unfounded. |
No, I apologize, I am being daft here. If Taproot does use a hash and you also use a hash, and it is the same hash function, then the direct serialization of your proof might be reinterpreted as a direct serialization of a Bitcoin SCRIPT, and various values and codes you use in your proofs may correspond to particular Bitcoin SCRIPT opcodes that could lead to an easily-spendable Bitcoin SCRIPT. In short: you may need to look very well into any concrete Taproot proposal that comes up in the future (there are none yet other than basic sketches). |
Yes, if the hash function is the same (and I think it would be likely), then it could become an issue. As I said before, I think it would be hard to force the victim into unknowingly pay to a precise SCRIPT, but as you pointed out in many cases a big "family" of SCRIPTs can make you loose funds. I guess I will keep this open as a reminder and to see if someone else has an idea to propose. Once Taproot will be finalized we will make sure there are no conflicts. |
Taproot is the most obvious, but, if other schemes also use pay-to-contract similarly, again a UTXO committing to an RGB proof may itself be reinterpreted as committing to a different pay-to-contract scheme contract. I have a thread on bitcoin-dev awaiting moderation about the reinterpretation problem. I believe the general solution is to adjust the tweak to:
Where In short, pay-to-contract must commit, not only to the contract itself, but to how the contract is to be interpreted. |
Thread on bitcoin-dev: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-September/016354.html |
I think it might make more sense to have the taproot-based p2c scheme be:
So |
That certainly seems a plausible solution aj. |
A possibility when using Taproot is to merge the Still, we must be careful that a RGB contract serialization may be interpretable as the serialization of another pay-to-contract system using the same technique. So we should use tagged sha just as in bip-taproot. |
I do like this proposal, it looks workable @ZmnSCPxj, have you had any further thoughts on the topic since then? |
Comment by ajtowns seems better. Alternatively, given current taproot proposal it would be possible to embed a hash of the RGB contract in a taproot branch that is |
Looks cool and sounds like a new commitment scheme for RGB. @giacomozucco, @afilini what do you think?
Emm... I don't get why |
I see a problem here: double spend. It is possible to commit more then one RGB proofs into the taproot scripts tree. I don't see trivial solutions without affect privacy (i.e. include all the taproot scripts into the RGB proof) |
The original problem pointed out that multiple pay-to-contract schemes may exist, not just RGB. The extra
You are correct and indeed the @ajtowns solution is strictly superior, as it avoids this issue. |
Got it and agree. Since I'm doing implementation of the complete RGB spec from scratch (here https://github.com/dr-orlovsky/rgb-rust) I'll add this to the code and also will do a PR to the spec itself. |
Adding "RGB" string to the public/private key tweaking procedure in pay-to-contract commitment scheme in order to prevent attacks around re-interpreting RGB contracts as some non-RGB contracts.
Seems like we need to add "RGB" prefix into the contract serialization as well (additionally to the actual PK tweak), in order to make the serialized contract code unambiguous. This prefix has to be included into the hash of the contract. I've already made this in code (see commit |
Adds "RGB" prefix into the contract serialization as well (additionally to the actual PK tweak), in order to make the serialized contract code unambiguous.
with more standard-compliance (alike in Taproot and other OP_RETURN schemes), enhancing security according to rgb-archive#61
Closing, discussion shall continue in the new PR #73 |
Implementing issue #61: disambiguing P2C RGB tweak
As the subject says, pay-to-contract schemes may conflict with Taproot in the future, if extended naively to a future Bitcoin version with Taproot support.
Proofs may themselves be marshalled into a form which can also be read as Bitcoin SCRIPT. This would allow a scammer to induce a victim to construct a proof that can be reinterpreted as a Bitcoin SCRIPT which the scammer may know how to solve, allowing the scammer to burn the colored asset and steal the backing Bitcoin UTXO via the always-enabled Taproot branch. I have not seen spec about proof marshalling (perhaps, not yet created?), but this is care point.
An idea, is to make an
OP_RETURN
byte (0x6A) be the first byte in every marshalling of a proof. Thus when reinterpreted as Bitcoin SCRIPT, the first instruction, is anOP_RETURN
, which prevents the proof from being reinterpreted as a Bitcoin SCRIPT that can be solved, asOP_RETURN
scripts are unsolveable.(Another mitigation is to make the backing Bitcoin funds so small as to be not worth the effort of stealing, but this may conflict with your intended plan, for using also a UTXO to back LN channels with both Bitcoin and asset)
(also this may be an argument against an always-enabled Taproot; possibly we could add a flag or marker, in the contract space, which selects "domain", and Bitcoin Taproot is simply an additional domain)
Care must still be taken in future. Other schemes that use pay-to-contract may also conflict with RGB usage in the same manner: a proof marshalling under RGB may be reinterpreted as a contract in another scheme, which may lead to victims assuming they have proofs under one system and then inadvertently signing off on a proof/contract for another system.
The text was updated successfully, but these errors were encountered: