|
vjudeu (OP)
|
This is just an idea, and I think in general, it should be standardized, but I will share it now, to inform people, what is possible.
The first thing to note is that full-RBF is more and more active. It allows fully replacing things, which are unconfirmed. Which means, you can no longer trust any unconfirmed transactions, because they are, well, unconfirmed.
However, some people still want to have some kind of "first-seen", or some other way of knowing, what happened first. For now, many nodes and block explorers just trace all transactions, so you can see the full history of "replaced by", for example on mempool.space.
But still, if you optimize a chain of transactions Alice->Bob->Charlie into Alice->Charlie, then Bob probably wants to have any way of seeing later, that he "owned" some coins, and that he was in the middle of this chain. For some purposes, it may be important, so this post will tell you, how to achieve that.
The first thing to note, is that your R-value in any of your signature, regardless of the type of address you use, can be safely used to make commitments. Which means, each time you have any signature anywhere, in your input, in your output, in your witness, just anywhere, it means you have two options: pick a random R-value, or tweak it, and create a strong, cryptographically-based connection, between your R-value, and any data you want to commit, without pushing that data on-chain.
So, what should be put inside such commitment? Probably the best thing to do, is to put some proof, that Bob was between Alice and Charlie, and he received something from Alice, and later agreed to pass it into Charlie. If such proof will be present, then future nodes could apply any mempool policy, to allow double-spending some unconfirmed transaction, only if the earlier recipient agreed to do so.
The only way, that can safely cover all cases, is just putting both Alice->Bob and Bob->Charlie transactions into such commitment. Because the commitment is never pushed on-chain, that should not be a problem, and can be done with zero additional on-chain bytes, so also zero additional on-chain fees. However, there are probably better ways to do that, for example UTXO-based, or signature-based, but this post is just an idea, that is yet to be clarified, and which didn't pass testing phase yet (but I think it is worth sharing, and also some people asked me to share it earlier anyway, also to show some people, what kind of ideas I have in store).
That kind of system can be scaled in a way of binary tree, similar to merkle root. Which means, if we standardize it as "two transactions, to proof what was inside", then it can be expanded when needed. Which means, if we have the first proof that only Bob was inside, we need two transactions: Alice->Bob, and Bob->Charlie. But if we want to prove, that Daniel was between Alice and Bob, then it can be included into the commitment of the Alice->Bob transaction! Which means, things can be nested in a tree-like structure, and to know, what is inside, the only thing that is needed, is some matching inputs and outputs in both committed transactions. If the commitment matches used sighashes, it should be sufficient as a proof. Which means, in SIGHASH_ALL, everything should match exactly, but in case of other sighashes, it could be weaker, because it should be compatible with the way things were signed.
There are more things to handle, like "how the commitment should look like, exactly, byte-by-byte" or "what to do with invalid commitments" or "what if nothing is committed, and R-value is just random", but I think this description above should give you more information to ask more questions, and I think they will lead this topic better than me, trying to guess upfront, what is the most interesting for the audience. Thoughts?
|
