pull down to refresh
131 sats \ 1 reply \ @supertestnet 14 Aug \ on: Introducing: Escrow-Less Bitcoin-Collateralized Lending bitcoin
DLCs create a scenario that is equivalent to a 2 of 3 multisig
Alice has one key and Bob has another and neither one can spend the money on their own, they either need to spend it cooperatively or, if one of them refuses to cooperate, the victim needs to use a secret reveled by the DLC oracle to spend the money. That's essentially a 2 of 3 multisig, just with different math
And since it's essentially a 2 of 3 multisig, there is an escrow: the oracle. Just like hodlhodl is an escrow when they have the third key in their lending product.
And for the same reason, it's not trustless: the oracle can collude with Alice to always give her the money, or the oracle can do the same for Bob. Both users have to trust the oracle not to do that.
It is wonderful that you're making a new product and I hope lots of people freely decide to use it, but only if you tell the truth. This is not trustless or escrowless. You can't have those properties if you are relying on DLCs.
Hey, @supertestnet! I'm a big fan of your work, so I'm very happy that we got your eyes on our proposal.
DLCs create a scenario that is equivalent to a 2 of 3 multisig Alice has one key and Bob has another and neither one can spend the money on their own, they either need to spend it cooperatively or, if one of them refuses to cooperate, the victim needs to use a secret reveled by the DLC oracle to spend the money. That's essentially a 2 of 3 multisig, just with different math And since it's essentially a 2 of 3 multisig, there is an escrow: the oracle. Just like hodlhodl is an escrow when they have the third key in their lending product.
I disagree with the premise that the oracle in a DLC protocol is an escrow in the traditional sense. The oracle is a trusted third-party that can operate without knowledge of the contracts that it signs for. Alice and Bob can set up a contract and the oracle does not need to see any of their coins or what they are doing with them. In comparison, an escrow is keenly aware of what goes on between Alice and Bob during contract setup, and if there is a dispute. With this knowledge, it's easier for an escrow to collude with Alice or Bob.
But I think you already know all this, so I guess we disagree on the semantics of what an escrow is. I think an oracle is sufficiently different to warrant a different category.
And for the same reason, it's not trustless: the oracle can collude with Alice to always give her the money, or the oracle can do the same for Bob. Both users have to trust the oracle not to do that.
I absolutely agree with you here. The protocol is not trustless. The linked whitepaper makes no such claim. In fact, section 6.1 is titled "Trusting the oracle", under "Limitations and future work".
Our post here does use that language, which is incorrect. I can take the blame for that: I did not read our post carefully before we hit submit. We can't edit it anymore, but we will pin a comment to the top to rectify this.
reply