> I am really looking for a bitcoin-native solution to leverage
> bitcoin's robustness and security properties.
I understand. I would briefly point out that there are other advantages
to not storing a signature for an ephemeral key in the annex. For
example, if you want to generate multiple different potential spending
transactions, you need to store one signature for each potential
transaction. The more data you store in the annex, the less scalable
the vault protocol becomes; by comparison, it's possible to cheaply
store a very large amount of data offchain with high robustness.
Each byte on-chain indeed has a cost. Though for practical vault usage, you may only need two spend paths - one for the unvaulting transaction and another for an emergency transaction.
Also, depending on construction of the vault, a possible advantage of a
presigned vault (without using the annex) over a solution like OP_VAULT
is that all actions might be able to use keypath spends. That would be
highly efficient, increasing the usability of vaults. It would also be
more private, which may be important to certain classes of vault users.
Even if OP_VAULT was added to Bitcoin, it would be interesting to have
an alternative vault protocol that offered different tradeoffs.
It would indeed be interesting to compare the on-chain footprint of both vault protocols. The main downside of presigned transactions of course is the requirement for an ephemeral signer and key deletion. I am not sure if a potentially smaller on-chain footprint is able to compensate for that. But the landscape of tradeoffs is complicated, and hard to say what users prefer if both options would be available to them.
> That years-long timeline that you sketch for witness replacement (or
> any other policy change I presume?) to become effective is perhaps
> indicative of the need to have an alternative way to relay
> transactions to miners besides the p2p network?
The speed depends on the policy change. In this case, I think there's a
reasonable argument to be made that a mitigation for the problems of
annex relay should be widely deployed before we enable annex relay.
On the other hand, maybe we are inside a window of opportunity where the annex can still be enabled without mitigating this problem fully. Taproot is still young and you could argue that there are not that many applications that would be affected by this yet. By clearly communicating the lack of witness replacement by commonly used node software now, developers may want to hold off on implementing these applications, rather than giving them a false sense of security offered by policy. But we've covered that in this thread before.
To be specific towards this proposal, if an alternative relay network
naively implemented annex relay, any miners who used that network could
receive a coinjoin-style transaction with a large annex that
significantly reduced the transaction's feerate. By comparison, any
miners who continued to only receive transactions from the P2P network
of Bitcoin Core (or similar) nodes would have received the transaction
without an annex at its original (higher) feerate, allowing them to to
receive greater revenue if they mined it. If, instead, the alternative
relay network implemented the witness replacement proposal you've linked
to, those miners could still receive up to 4.99% less revenue than
Bitcoin Core-based miners
Perhaps way to fix this is to combine the 5% (or whatever constant is chosen) with Greg's proposal above to also always allow replacement by an empty annex? That way it's always possible to put in an annex-less transaction that is part of an annex-less protocol, regardless of how few extra bytes the annex was inflated with in a previous version of that tx.
and the operators of the alternative relay
network might have had to pay extra costs for the replacement relays.
You can tweak the proposal to tweak those ratios, but I'm not sure
there's a case where an alternative relay network comes up as a clear
winner over the existing network for general purpose transactions.
Instead, like many things, it's a matter of tradeoffs.
It is the question whether those 5% replacement DoS attacks are powerful enough to make it worthwhile for an attacker. And in the case for example the nostr proposal, there could be anti DoS on a different level as well.
> I agree though that it would be ideal if there is a good solution that
> doesn't require any protocol changes or upgrade path.
Apologies for the salt, but there is a good solution: don't use the
block chain to store backup data.
Any auxiliary system that is required for operating a vault adds risk. Whether it is still good enough is debatable, but I expect some users to hold the opinion that it isn't.
Joost