When someone informs Emily of a deposit, they're somehow providing something akin to the proof for a Merkle Tree. If that's the case, can't Emily verify the params and reject invalid requests?

(Sorry on mobile but happy to expand on this with proper info)

When someone informs Emily of a deposit, they're somehow providing something akin to the proof for a Merkle Tree. If that's the case, can't Emily verify the params and reject invalid requests?

Yes, it could, and Emily would need access to bitcoin-core to do a full verification of the proof. Emily currently does a partial verification. We've been tossing around the idea of having Emily verify things against bitcoin-core. I'll add this as an option.

I can be convinced otherwise but I think that anything else than that would add complexity for little gain. We know how to solve this properly, we can evaluate how much of a heavy lift it is to add this to Emily.

Does it need to have access to Bitcoin core though? I'd assume the verification path can be much simpler, because we want it to be pretty specific.

Hm, wouldn't option 2 also let us extract (what look like) sbtc deposits directly from bitcoin blocks and then only ask emily for these, and use the intersection vs. asking Emily for everything it views as pending every block?

Does it need to have access to Bitcoin core though? I'd assume the verification path can be much simpler, because we want it to be pretty specific.

I believe that it essentially does. There are two kinds of verification:

1. Verify that the received data is properly formatted deposit data.
2. Verify that the received data maps to what is on chain.

Emily does (1) but not (2), and for (2) you need Bitcoin Core or you need the user to supply a bunch of information. I think the information is something like: the header of the block that confirmed the deposit, the transaction hex, and some merkle proof of inclusion of the transaction into the block. This is off the top of my head, I'm not entirely sure that this is correct.

Hm, wouldn't option 2 also let us extract (what look like) sbtc deposits directly from bitcoin blocks and then only ask emily for these, and use the intersection vs. asking Emily for everything it views as pending every block?

Yes it would. Also, option 2 would let us extract sbtc deposits directly from bitcoin blocks without speaking to Emily at all. I'm not saying that we should do that, just that it's possible.

Hmmm... but after thinking about this some more, I'm not as sure that option 2 is well-tailored to the problem stated in the ticket. It's more complex than it needs to be for the Emily integrity issue.

Option (3) seems like the only way forward here, unless we require all deposits to have an OP_RETURN output and I wasn't advocating for that. Maybe I'm missing another option. It seems like we cannot leave Emily open to the public for anything besides some GET requests because without Bitcoin Core she cannot validate all the data that she receives. She needs a trusted source. If she has access to bitcoin-core then we'd want to stop users from DoS'ing it, so we may need tighter rate limits.

I can be convinced otherwise but I think that anything else than that would add complexity for little gain. We know how to solve this properly, we can evaluate how much of a heavy lift it is to add this to Emily.

Yeah after thinking about it some more, I agree. But, I think I just like option (2). It appeals to me as a nice feature because it allows me to bridge into sBTC directly from the L1. And I think "the decentralized, trust minimized, bridge from Bitcoin into Stacks" should have L1 support.

On the other hand it adds some complexity, requires leather work, and maybe no one besides me cares. I'd like to think through the work required so I'll open a design ticket and things will be clearer afterwards.

I think I just like option (2). It appeals to me as a nice feature because it allows me to bridge into sBTC directly from the L1. And I think "the decentralized, trust minimized, bridge from Bitcoin into Stacks" should have L1 support.

I +1 this; removing the requirement of Emily is very appealing, but yeah probably deserves its own ticket.

Option (3) seems like the only way forward here

I think that this would necessarily add 1 block to the deposit processing time, right?

the header of the block that confirmed the deposit, the transaction hex, and some merkle proof of inclusion of the transaction into the block. This is off the top of my head, I'm not entirely sure that this is correct.

Thanks!

It seems that here we are trying to solve many things at once. I wonder if we can reduce scope by picking the right problem to solve.

Going back to the issue:

This means that someone can create properly formed deposit requests to Emily that do not match any actual deposits on bitcoin, with the outcome being that actual deposits will be deemed invalid.

Let's say there's a deposit request d. If we think of d as a taproot address, we can think of d = h(sender, amount, recipient, lock-time, sbtc-signers-aggregate-key, etc). That deposit d must be included in a transaction with ID txid.

Now, IIUC Emily gets some inputs to d and verifies them, and txid. But right now can't verify that txid spends to d.

The problem is that if someone provides d' (and not d) for a given txid with valid inputs, Emily will happily accept it but this will break the deposit request for d.

In that case, what I propose to solve this is to have the user provide all inputs.

Even if it's not the same user, as long as d is computed deterministically and the user provides all required to compute txid (including d and its inputs), it's fine!

This will prevent an attacker from invalidating d by providing d' for the same txid.

The nice thing about this is that it is completely stateless. Essentially, Emily reproduces the computation that the bridge performs to obtain d in the first place, then the computation that the wallets performs to get txid.

Now IIUC this should not require the Bitcoin block header. That's useful for a different problem, ie prevent someone from providing a d or a txid that has never made it to the blockchain. But we can tackle this separately imho.

If the goal is only to ensure that the scripts are valid and are a part of the (potential) transaction for the given txid, then we shouldn't need bitcoin-core. But we would need a bit more information to compute the txid -- it might be easier to have them send the hex-encoded transaction at that point, and we validate that we compute the same txid and that both script paths are valid given the taproot in the output.. I think?