@BlueSlime1
94,655 sats stacked
stacking since: #11116longest cowboy streak: 4
by
for
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.
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.
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:
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:
This is what BitEscrow already does for optimizing its musig signing sessions. We even refer to the initial nonce as a "root" nonce.
Very interesting how they came up with that name and term when our solution had been public for a while now.
The scariness is overblown IMO. You just have to remember 12-24 words, or some obscure phrase, and you can convert that into an infinite number of keys.
What can be scary is someone stealing your coins. A good hardware device and proper backup removes this threat 99%. You can protect millions in wealth and should be okay.
When you get to the point of having a trust or corporate treasury, then you may need a basic multi-sig with key rotation, or a vault.
When you have enough wealth that state actors want to give you the gadaffi special, then you should use a vault controlled by a federation of signers.
What is surprising to me is that the user experience for vaults and multi-sig watch towers are still not great.
This project is great.
It is a very easy to host micro-blogging platform that let's you publish NIP-29 long form events, and shows a feed of your NIP-29 events. Including stacker news reposts.
There's a couple bugs that can kill the site if you use unresponsive relays. So it needs a bit of open-source TLC. But it works and looks slick.
You forgot to mention the worst part of all, writing code in C++.
"Lack of publicity might be jeopardizing the MIT / Apache 2 license and the de facto entrance in the domain public of Bitcoin design ideas."
I think this is what is being referred to.
I don't think you understand how nostr works. The relays are not meant to be endpoints, they are only meant to be dumb relays. Also the relays already operate as a hash table for the notes being stored.
There's no IP addresses with nostr gossip, just a list of relays and some overlap between clients. If our clients share a single preferred relay, I can retrieve your note and rebroadcast it to my other preferred relays. It's not a hard concept to understand, and the "links" are on the nostr github.
There is a gossip protocol spec in Nostr. I forget the NIP but you can easily find it.
Clients perform the gossip by republishing the notes of others, which is an intended feature of nostr.
DHT is not really a good fit, as the clients are not meant to be reliable end points, and relays aren't that much more reliable.
Gossip works far better, and there's already a proposal and implementation.
There's also things like blastr, which can mass-update your profile to a list of relays.
The only way I know of that will let you do this is with virtual utxos, which means locking up an on-chain utxo and promising parts of this utxo to many people.
Ark has a solution that accomplishes this, but the ugly path is too ugly without covenants.
Covenants in general would sort of accomplish this, if you could enforce a user to spend with a particular change output. Then you could have users swap vtxos around on a layer 2, and if things get ugly, the covenant restricts everyone to exit with only their share of the utxo.
Any side chain solution is an implicit block size increase, as the total network must store more data in order to validate your holdings.
Also, lightning is not limited to HTLC payments. There may be other channel configurations worth exploring.
The page reads like an investor thirst trap. What has been built so far? Do you have a rough implementation or a github for the project?
Wonderful talk, bit lengthy but you take the time to explain everything in great detail. I feel it gave me a solid understanding of a bitvm transaction and how it works.
Some questions:
Does a challenge tx script grow as the program grows? Or does it just represent a single bit in the program?
Also, have you looked into square and multiply? It could open up key tweaking within a bitvm program, which would be pretty rad.
I am glad to see Vicky again, even though she ruins everything. 😂
Google is evil but their groups platform is one of the few things they have stuck with and supported well. There are group communities that are 20+ years old.