15 sats \ 2 replies \ @BlueSlime 23 Apr \ on: You stumble upon Satoshi's private key... bitcoin
I would create the longest transaction chain ever, with each transaction time-locked to the next block, and spending 1 BTC in fees. Then publish the 100mb transaction blob and delete the private key.
This should guarantee miners a 1 BTC subsidy for the next 20 years.
Or burn it all in an op return.
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.
Here are a few of my favorites that I am looking forward to:
-
Esports betting pools, with automated payouts based on the game's server API (looking at you DOTA2).
-
ACH transfers that settle a purchase of bitcoin using a banking API.
-
Collateralized pull requests on Github that payout upon a successful merge.
-
Anonymous crowd-funding campaigns that refund when they fail to meet their target by a certain deadline.
-
A loan contract that holds bitcoin and adjusts its payout over time.
100 sats \ 1 reply \ @BlueSlime 28 Mar \ parent \ on: What would you build with an escrow API? bitcoin
We have a few interesting things planned for this use case. :-)
20 sats \ 0 replies \ @BlueSlime 28 Mar \ parent \ on: What would you build with an escrow API? bitcoin
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 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.