From f6db54ac3427e3e5acc513a7e33410a505536d5d Mon Sep 17 00:00:00 2001 From: Dave Hrycyszyn Date: Mon, 15 Jul 2024 17:03:08 +0100 Subject: [PATCH] Adding a few use case ideas while working on the larger Side problem --- README.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/README.md b/README.md index 5c4fc5f..b064622 100644 --- a/README.md +++ b/README.md @@ -87,3 +87,15 @@ You'll need to have funded the "dave" address prior to running the `btc` command I was using this primarily as a way to experiment with constructing and broadcasting Bitcoin transactions, with the hope that it would be possible to move on to more advanced constructions (e.g. state channels). However, now that I look at all the options, it seems that multi-party state channels in Bitcoin are (probably) impossible to construct. There is a second, unused Bitcoin client in place which uses Blockstream's Electrum server, but this didn't seem to be working properly with respect to Signet Bitcoin network during my testing, so I went with the esplora / Mutiny version instead. + +## Possible uses + +### DKG + +It strikes me that there are many, many systems which rely on a trusted setup, and which might be able to use Distributed Key Generation (DKG) instead. SNARK systems for instance all have this problem. + +It is not necessarily the case that e.g. signer participants and validators are the same entities. Being able to quickly spin up a blockchain and use it to sign (potentially temporary or ephemeral) keyshare data might be pretty useful. + +### Cross chain transfers + +The ability to be part of multiple consensus groups at once might provide new opportunities for cross-chain transfers.