Content pfp
Content
@
0 reply
0 recast
0 reaction
‎ pfp
‎
@mpryor.eth
The first trustless DEX between Bitcoin and Ethereum? https://x.com/riftdex/status/1842242143005614489?s=46
6 replies
0 recast
29 reactions
HH pfp
HH
@hamud
I don't understand why a zkproof is necessary here.
3 replies
0 recast
0 reaction
‎ pfp
‎
@mpryor.eth
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
‎
@mpryor.eth
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
Harris
@harris-
Yeah, you can just do a HTLC on Bitcoin
2 replies
0 recast
1 reaction
‎ pfp
‎
@mpryor.eth
Is a hash based time lock better than ZK?
1 reply
0 recast
0 reaction
Harris pfp
Harris
@harris-
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
HH pfp
HH
@hamud
You gotta add a bio. Though you were a bot initially.
1 reply
0 recast
0 reaction
Harris pfp
Harris
@harris-
Fixed it :)
0 reply
0 recast
0 reaction