Runes are basically a colored coins protocol designed for issuing tokenized assets. They are designed to replace BRC-20 with something more sensible. They are UTXO based, and rely on the OP_RETURN to store the token data (called a runestone). They do not use the ordinal system for anything, but a rune can be tied to an inscription.

Yes Sabine is legit a brilliant scientist. She is knowledgeable in many subjects but mainly physics research.

This video is important but it's a side rant of hers compared to the rest of her content.

If you like scientific news then give her a sub!

Sort of, but not really. 😁

BitEscrow uses a covenant to lock funds to a limited set of outputs that the escrow agent can choose from. The covenant is tweaked with the contract terms, which the agent must sign in agreement to spend an output.

In contrast, a DLC will set up a similar covenant with limited set of outputs, and the "oracle" spends the covenant by signing a particular message.

Both methods use similar cryptography, but the strategy and tradeoffs are different.

yanks are still asleep

get your cap and regalia

Oi mate! Ye got a loicense for that zap?

Here are a few of my favorites that I am looking forward to:

We have a few interesting things planned for this use case. :-)

The most trustless use-case of the API will be coordinating anonymous coin joins via your own custom protocol. You can specify a single spending path with all the desired outputs, and have the contract settle immediately upon funding. The outputs can use any type of address or locking script.

Since Bitcoin is ultimately just software, there's a lot of situations where the network may fail temporarily, but could be fixed with a software upgrade.

I don't think those situations constitute failure. Tor makes changes to their protocol all the time in order to stay ahead of the game.

A true failure case would be:

a) ECDSA and all other digital signature schemes are broken, and there's no replacement.

b) All nation-states unite and restrict / ban all electronic devices. This is to kill all forms of PoW (bitcoin, monero, etc).

c) Apocalyptic event that sends us back to the stone age (can run nodes underground though).

d) A superpower rises up, eliminates all corruption period, and becomes so trustworthy that all commodities are abandoned for fiat.

The core concept of Bitcoin is just a distributed ledger of signed transactions and a PoW lottery for consensus on the transaction order.

That is a really tough thing to kill without wrecking the internet as we know it. And I don't think any other asset comes close in regards to competition. It's like comparing a filing cabinet to a computer.

I would suggest following the book and examples to build your own cryptography library, then go from there.

You can also find code examples of ripemd160 and sha256 hash algorithms in python.

That will give you the tools for most ZKP applications.

You can also ask ChatGPT to write you the code for certain cryptography primitives, and then you can refactor it to your liking.

I made an example repo here:

I think the Docker devs are conflicted on this subject.

On one hand, they have adopted compose into their api, and want you to use it to build out micro services, which leans towards an infra-as-code model.

But otoh, they have also adopted a project called tiny into their container api, which offers better handling of multi-process containers.

If you want to go hard core, there's ways you can run debian systemd or alpine's manager within docker.

I try to keep my process count minimal so a process manager is overkill for me. I just run with tiny enabled and use tmux for basic management.

I run a webserver, postgres db and bitcoin node in the same container all the time, with tor and ngrok tunnels. Works flawlessly.

I like docker compose but I think it can become a crutch that props up overcomplicated setups.

I use docker with a design pattern called workbench. Everything runs inside one container, and it acts more like a VM that you can customize then distribute with your project.

When I want to setup my environment, I just launch the one container. If I have to make changes, I can change the source files then reload the container. It's also easy to login and get a shell prompt.

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:

Keep up the great work gents. Looking forward to this project!

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.