pull down to refresh

This looks really cool: #1427029

reply

Sadly, my naive enthusiasm for interesting things to do with Bitcoin transactions knows no bounds.

Is there a place where I can find a good critique of the PIPEs thing? There wasn't much on delving...

reply

If it contains the word covenant or ZKP, it's bullshit. Every single time. It's all DeFi grift. The physics of Bitcoin are immutable, there's no novel magic to be had, it all comes down to re-branding trust and centralization and calling it a perpetual motion machine.

Ignore these papers as you would any shitcoin paper because its all downstream of the shitcoin-on-bitcoin mind virus.

reply

Zero Knowledge Proof just sounds so damn cool. But I still have a hard time understanding what it means, especially within the contexts in which they're being used.

With ZKPs, it seems like the devil is entirely in the details, and thus throwing the buzzword out like that tells me almost nothing about what the security and trust assumptions really are.

reply

It's how you know they're playing a trust shell game #1427126

reply

"There's no trust assumptions other than having to trust the entire thing"

reply

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?

reply

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 5 Feb
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.