Harris on Warpcast

Content pfp

0 reply

0 recast

0 reaction

‎ pfp

The first trustless DEX between Bitcoin and Ethereum? https://x.com/riftdex/status/1842242143005614489?s=46

6 replies

0 recast

29 reactions

HH pfp

I don't understand why a zkproof is necessary here.

3 replies

0 recast

0 reaction

‎ pfp

The ZKP is necessary because the user who holds BTC on Bitcoin and wants USDT on Ethereum must prove to the smart contract on Ethereum, which controls the locking and unlocking of their USDT, that they have maintained the five invariants (pictured below).

1 reply

0 recast

0 reaction

‎ pfp

And of course by doing this, you are skipping completely over CEXs like Binance and Coinbase (plus apparently it is cheaper fees) and no KYC, assuming you weren't previously doxxed with the linked addresses.

1 reply

0 recast

0 reaction

Harris pfp

Yeah, you can just do a HTLC on Bitcoin

2 replies

0 recast

1 reaction

‎ pfp

Is a hash based time lock better than ZK?

1 reply

0 recast

0 reaction

Harris pfp

Your p2wsh spend path for eth side uses the hash of an arbitrary probably 32 byte value, and then on the eth side your smart contract verifies that the supplied value hashes to the expected value to unlock the BTC side before releasing the usdc to the BTC side seller. I implemented a basic CLI version of this approach (and many others have done similar over the years) here: https://github.com/0x330a-public/gauloi-cli-rs This is also similar to how lightning network operates but from my understanding lightning has a lot more complexity to get around design copes they made on top of this

2 replies

0 recast

1 reaction

‎ pfp

That’s so neat! I appreciate you sharing all of this, and your cool code. So it would be as hard to guess as a private key? Would you still prefer ZK over this?

1 reply

0 recast

0 reaction

Harris pfp

I think the zk stuff just adds additional cost and complexity. If you want to do it as a full dex or something maybe it makes sense but to just swap BTC and any evm asset you can just use this approach. There's pretty much only timing and maybe some economic attacks around if the exchanged value is less than the tx fees but the eth side gas fee is 21000 + equality checking the sender's pubkey + hashing the input + equality checking the hash + the transfer costs so pretty cheap, probably next to nothing on an L2

1 reply

0 recast

1 reaction

‎ pfp

I’d be curious about the attacks and timing games you mentioned. This is all news to me. It would be nice if zk was less complex, and yes it’s like “just math” but I can’t understand much beyond the demos of proving simple math. I hope I can learn to write circuits one day!

1 reply

0 recast

0 reaction

‎ pfp

I just read, “If the payment gets stuck at any point, the process automatically reverses, and any pledged funds are returned, ensuring no one loses out in case of unforeseen disruptions.” Intermediary nodes seem like a denial of service attack vector? As opposed to the ZK way with Rift DEX, you’re running the light client yourself (possibly), and don’t rely on other nodes, just that the other party sends the crypto.

1 reply

0 recast

0 reaction

Harris pfp

I guess you always have attacks for things like reorgs or potential double spends when you're dealing with different chains that don't talk natively. In terms of the reversing, you basically have two spend paths on each chain, one being the "good" path where people will get the funds they wanted on the other side, but if one party doesn't follow through with the trade then there's a timeout path on both sides as well, enough time that you have a relatively safe guarantee that your money won't be claimed by the other party (if you only make it 2 blocks long on the btc side for example maybe you can have the initiator try to reclaim the BTC back in a few minutes to half an hour?) whereas if you have it too long you basically have your BTC locked up for a while unable to be used, if that's a day and there's a significant market event maybe you're out of luck even though you could retrieve your funds again. ...

1 reply

0 recast

1 reaction

Harris pfp

On the other hand, the btc initiator can basically treat the swap as a future at a guaranteed etc price and not go through with it if they don't want that price. You basically just trade off block time to denying access to the pending funds

1 reply

0 recast

1 reaction