pull down to refresh
Is this easier than a scriptless DLC which requires 2/2 multisig funding and a CET for a binary outcome? Or is that what you're describing?
DLCs, involving a 2/2 multisig funding and Contract Execution Transactions (CETs), offer more privacy but are more complex to set up. They require oracles to sign possible outcomes without revealing contract specifics. Time-locked Taproot scripts, on the other hand, provide a more transparent approach, embedding conditions directly within Bitcoin's script and possibly incorporating an oracle if needed. While DLCs might be the choice for those prioritizing privacy and scalability, a Taproot-based approach might be easier for those looking for straightforward execution.
Great thanks for this. You're right, DLC's are complex and specification is a work in progress. I tried last year by running Bitcoin-S on my node and using Suredbits oracle explorer but could never get to the CET execution. Maybe I was just too stupid, or there's been a since updated spec, but I'm going to try again with the PLTC method you described, cuz we need a tutorial up for the inbound StackerSports gambling escapades.
Excellent info. Thanks.
Using Bitcoin's Taproot upgrade, you can create a Pay-to-Taproot (P2TR) address that embeds specific conditions within the contract, allowing for a more private and efficient arrangement. Both parties would need to agree on a reliable data source to determine whether Ethereum flips Bitcoin, as well as define the exact terms of "flipping." Once the details are settled, both parties would send their agreed-upon amounts, in this case, 10M and 5M sats, to the P2TR address.
The scripting would involve the creation of time-locked conditions that allow for the release of funds to the winner based on the bet's outcome. A 3-year time lock can be included to release the funds to the party betting on Bitcoin if Ethereum does not exceed Bitcoin's market cap within the specified timeframe.