pull down to refresh

I took "trusted setup assumption" to mean trusting that the device on which you are doing the computation is not compromised.

I don't know that I see why covenants are necessarily shitcoinery. For instance, if someone figures out clever ways to split up a key into shares and then does math on the shares so that they can only be reconstructed if a secret is included in a different bitcoin transaction -- this could get kind of close to what what we want covenants to do. Why is such a thing necessarily trustodial?

The party doing the computation, trust the coordinator bro.

Covenants are inherently shitcoinery because what they enable is delegation to a 3rd party run application. Delegation is non-monetary, it's application-level logic, which turns Bitcoin into an application-stack like Ethereum rather than money.

You can split keys with shamir, but someone still has to generate the secrets or do computation. You can't remove the someone from the equation which is what all these scams purport to do, until you read between the lines.

Application logic can only be an application that uses Bitcoin as money, Bitcoin as money cannot be an application. They are mutually exclusive.

reply
17 sats \ 1 reply \ @Scoresby 5h
someone still has to generate the secrets or do computation. You can't remove the someone from the equation which is what all these scams purport to do, until you read between the lines.

This makes sense to me. Would you say the same of distributed key generation schemes like FROST?

Application logic can only be an application that uses Bitcoin as money, Bitcoin as money cannot be an application. They are mutually exclusive.

Don't the existing timelocks in bitcoin come a little close to application logic? I'm thinking of the way Liana does a decaying multisig where after a CSV expires you are able to sign with one key rather than the previous quorum of 2 (for example).

reply
Would you say the same of distributed key generation schemes like FROST?

There's DKG/MPC schemes which can obviate the issue to a degree in contexts like Nostr, and I think Frostr is pretty handy... something i'd like to implement in Sanctum at some point...

With Bitcoin though it's not a simple matter of a shared key, there's validation of any off-chain behavior. The "setup" of that future validation is therefore trusted.

Don't the existing timelocks in bitcoin come a little close to application logic?

If they were using some external clock then yes, you'd need some kind of time oracle, but since block height is inherent part of Bitcoin validation then there's no external application hook to validate, block height is already validated with or without them.

Timelock is really colloquial, not literal, a timelock is really a blocklock. The Satoshi team used the term Timechain in the earliest code due to the chronological nature of blocks.

reply