1604 sats \ 4 replies \ @supertestnet 3 Mar freebie
DLCVM assumes a trusted the party will run the computation honestly.
Other than suggesting the use of multi-party computation (basically a fancy multisig), they explicitly defer any attempt to ensure that the oracle is honest:
Basically they suggest that Alice can pay Bob on the condition that a group of one or more people "authorizes" the transaction, and this group is trusted to authorize Alice's transaction only if they (the group) run a computer program agreed on by Alice, Bob, and the group.
This generalizes very well but it's all based on trust. The authorizers can collude with Bob to steal Alice's money without running the computation. DLC's ordinary "trust assumption" is that the oracle (or in this case the multisig) is not a party to the contract, so it has no incentive to misbehave, but Bob can always inform the oracle about the contract in order to bribe them to let him have the money at stake. Users of a DLCVM must simply trust that the oracle they use is honest and will not take bribes.
reply
0 sats \ 0 replies \ @delta1 3 Mar
you absolutely missed the joke
reply
0 sats \ 2 replies \ @BlueSlime 3 Mar
The one way to mitigate this is to use dumb oracles that only attest to simple things that have a strong consensus (i.e time intervals, stock price, sports scores).
They have to be ubiquitous and just be a dumb publisher of data. Then you can independently construct a contract via their attestations.
This wouldn't be much of a leap from what exists today with SuredBits and other oracle servers.
But when it comes to basic operations that you would want for a VM, like a boolean comparison of two strings, it gets complicated. For example:
a) You will have to interact with oracles and give them data to "prepare" to sign, which already compromises the integrity of the DLC.
b) You will have to use homomorphic encryption, so the oracle isn't tipped off to what is actually being computed.
b) You have to trust that oracle not to lie, which may or may not be provable depending on the data and computation.
c) You can try to use a frost musig of oracles to spread out the risk. But collusion is already a requirement in order to setup the musig, so you are still trusting the group.
So I would say that you could construct some type of state machine that is reliable and useful, and could be reasonably represented as a DLC. But it would really have to be something that makes sense, that can be represented non-interactively by dumb oracles, and works well within the limitations of deterministic computation.
reply
101 sats \ 1 reply \ @supertestnet 3 Mar freebie
I don't think that mitigates the trust issue. [EDIT: Nevermind, see next paragraph.] Even if dumb oracles are ubiquitous, you never really know if a given oracle is really one of the dumb ones or just a wolf in sheep's clothing. You can pick a set of supposedly dumb oracles at random and hope for the best, but regardless, you're still trusting that if Bob tries to bribe them, at least one of them will stand firm.
Ok I just realized that does mitigate it. "1 of 15 is honest" is a mitigation compared to "8 of 15 is honest," for example. It mitigates by "reducing" the number of trusted third parties, which is wonderful. But it only reduces it to a number that remains greater than 1. At the end of the day, trusting that "1 of N is honest" is still trusting the integrity of a federation.
reply
0 sats \ 0 replies \ @doofus 3 Mar
I wish I was smart enough to understand a lot of you two wrote.
reply
205 sats \ 3 replies \ @nout 2 Mar
Well, this is really theoretical - there are many details to be worked out. Is the main novelty the fact that we can plug any VM as Oracle into DLC?
This idea is sort of generalizing BitVM into being able to use any oracle for the "contract" code, not just the taproot leafs as logic gates...
reply
100 sats \ 1 reply \ @BlueSlime 3 Mar
My understanding is that BitVM actually forces you to demonstrate the computation of a particular gate when challenged, or forfeit the money.
With a DLC you can't stop the oracle from lying, unless you throw more oracles at the problem. But then you can't exactly stop them from lying either, so it's turtles all the way down.
reply
100 sats \ 0 replies \ @nout 3 Mar
So all in all this proposal is really not that interesting, unless I'm missing something.
reply
0 sats \ 0 replies \ @BlueSlime 3 Mar
deleted by author
reply
0 sats \ 0 replies \ @notgeld 7 Mar
With my friend, I concluded that it could be called an "offchain covenant". That is another reason why Bitcoin likely doesn't need dedicated covenants.
reply
0 sats \ 0 replies \ @BlueSlime 3 Mar
This was going to be an alternative implementation of BitEscrow, the extended musig signing is designed for computing adapters that attest to execution of a state machine.
However you would need a reliable group of oracles for time and for outcomes, and then you still need arbiters to handle disputes for edge cases, plus signatures from other members of the contract.
Maybe in an ideal future, there's a healthy decentralized market of oracles that you can use to represent the conditional gates you need for the machine. Maybe oracle servers can be lightweight and ubiquitous, and the process of enrolling them into a contract would be painless.
In practice though, this is a very fragile system, because you are relying on so many intermediaries as oracles in order to decentralize the attestations. Also there's currently no market for this, so you have to stand in as the oracle for pretty much everything, which makes you the custodial computer and defeats the purpose of using DLCs altogether.
Lastly, DLCs only work for computation that is deterministic, because you have to pre-compute all execution paths in the contract in order to create the adapters. Things like time and price-pegs have to be modeled in complex and convoluted ways, in order for them to be usable in a DLC based machine.
In BitEscrow, we have a far simpler system, we can support any kind of computation for virtual machines, and the tradeoffs are marginal since we still use covenants and provable execution.
We also have a working product that you can try out today. Our API is available on three separate test networks, with full documentation and live demos. Plus we have a complete SDK for building (and offering) your own smart contracts:
https://bitecrow.dev
Our code is open-source, so if you want to ditch our contract VM and hook up your own, you can do that too. It's pretty easy and I'll help you out:
https://github.com/bitescrow/escrow-core
reply