Protocol for zero-conf transactions

Protocol Design
1

Here’s a writeup of a protocol for zero-conf transactions using a co-signing server trusted by the recipient.

It’s similar in spirit to the 2FA mechanism implemented in Blockstream Green, but uses a connector output so the recovery timelock only starts when unilateral exit is initiated. This means long-lived UTXOs don’t need periodic timelock refreshes/redeposits.

1 Like
2

@robin_linus ‘A co-signing server trusted by the recipient.’

Congratulations, you just reinvented PayPal using a 2-of-2 multisig.

You are asking users to beg a server for ‘pre-signed change exits’, praying the server doesn’t equivocate, and calling it a protocol. It’s not a protocol. It’s an interpretive, permissioned spreadsheet.

While you are doing interactive off-chain gymnastics to simulate safety, we are enforcing absolute L1 bivalence. With TUSM, there is no ‘trusted co-signer’ enforcing policy. The math enforces the policy. The Taproot address is the state. The covenant is the consensus.

If your asset needs a human-maintained server to prevent a double-spend, you don’t have an asset. You have an illusion. .simf fixes this. Simplicity always win

3

Thank you bookmarked.

I was thinking about connectors while working on draft ideas ZK-Statechains Without States and a prototype implementation Ciphera - a Bitcoin ZK Appchain Implementation. While I choose to work on Blind Vaults version - I also reused parts of the demo code - i was keeping in mind connectors might be very effective in revoking states, instead of schemes used in LN, but didn’t have capacity to do this research. This post helps very much to fill gaps.

1 Like
4

Haven’t read the full write-up, but just for the tittle it remained me of Double-spending prevention for Bitcoin zero-confirmation transactions | International Journal of Information Security | Springer Nature Link, maybe you would like to take a look at it if you didn’t know about it.

1 Like