# Advanced-Reading Paper - details
By: Henk van Cann
Date: July 2nd 2022
Version: 0.8

Introduction: https://hackmd.io/GbQO3p6QTge-8eQMGuMaeQ

## Cause

A PM of Christopher Allen (CA) on April 2 2022: "BTW, if you are interested, we have our first draft of a #SmartCustody full scenario for multisig bitcoin, with Sparrow as watch-only transaction coordinator, Passport and Gordian SeedTool as PSBT signers, and an SSKR offline key. https://github.com/BlockchainCommons/BCSwiftFoundation/blob/master/Docs/Secure%20Components/1-OVERVIEW.md"

HC: Do understand it right that this whole .md file is directed at only 1 Audience in the Multisig Self-Custody Scenario, https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/Scenario-Multisig.md, but it is possible to create similar .md files for a different Audience?

CA: Yes, there will be multiple of these for different scenarios, different devices, etc.\
The iPod Touch is a cheap viable signer. Along with the wifi-only iPad, they both offer "base-bandless" iOS devices for those who don't trust cellular chips (which can't be inspected by international law).
Shannon has a bunch of changes that just came in late this afternoon from Joe, but isn't going to apply them until next Tuesday (...)

CA: The problem with this one is no SSI supports multisig
An SSI scenario is similar to our old ones but with SSKR
First draft of our quarterly report. Sharing in case you had any thoughts before releasing it: https://hackmd.io/JW6Wz5ejQ0G3tuWbXsr47A

HC:Are you sure about KERI based identifiers? The latest stuff discussed is here: https://github.com/WebOfTrust/keri

CA:I see nothing about Schnorr signatures in their proof spec.
HC: True, In the current KERI minimal-sufficient-means design there is a rather rudimentary multisig.

Page 41/141 of the WP: "The description of the ensuing protocol assumes the simplest case of individual not collective signatures but it is anticipated that the protocol may be extended to support collective multi-signature schemes."
Is the weighted threshold based multi-sig not enough to get us going? I remember Dave Huseby being critical about KERI for using the term 'multisig' during the last IIW. In his view Sam Smith should have used a different term for what KERI does at the moment. And of course he has a valid point if you compare to Schnorr (and Taproot). However, I think multi-sig is a container term anyway and the WP explains in great detail what should be understood by it in the KERI.

Christopher Allen:
The problem with this one is no SSI supports multisig
Are you sure about KERI based identifiers? The latest stuff discussed is here: https://github.com/WebOfTrust/keri

Too long and complicated, but is complete detailed checklist, threats and adversaries, and commentary. I welcome advice and comments!

CA: I’m still concerned with lack of support for aggregated Schnorr, musig & frost in KERI.
Still more work to do on this draft, but Collaborative Key Management I believe is the future: https://hackmd.io/hb538SOJT8e3gS2nRerT9Q

HC: Yes, known issue. According to Sam Smith, KERI is extensible in this regard. I can't deliver the depth to discuss this with a great expert like you are.

---
Is BIP-322 (sign messages with bitcoin keys and scripts) on your roadmap?
No, focussing mainly on KERI / ACDC (and other good things in life). I'll have a look at BIP-322 to come up-to-par.
Hope to bridge between Keep (KERI's bare bones key management system) and the BCC projects one day.

---

Christopher Allen:
Is BIP-322 (sign messages with bitcoin keys and scripts) on your roadmap?

HC: Is there a specific reason why you asked?
Quickly read through the BIP-322. Seems to me 1. there must be a very good reason to expose your priv. key of a BTC UTXO in subsequent signatures with this key. I didn't see sufficient sufficient entropy added in the current spec (maybe I overlooked something). 2. BTC priv. keys can't be (pre)rotated nor delegated. Every action with them will either incur transaction fees (brute force "rotation") or less security as I've learned. Hopefully I am wrong.

CA: You can do bip322 with offline keys. It is just like signing anything else, you need a private key to sign. But like bitcoin, the script is used to verify public key.
See https://github.com/WebOfTrustInfo/rwot2-id2020/blob/master/final-documents/smarter-signatures.pdf
See presentation at https://sourcecrypto.pub/posts/transcripts/smart-signatures-christopher-allen/

HC: "For my reading pleasure" 🙂Thx, will have a look. I am not comfortable with idea that priv. key that control assets are going to be used to do multiple signing, with them being non-rotatable and non-delegable.

CA: If you use it with BTCR there are definitely concerns with key reuse with a valid UTXO, less so if the address is already spent. But like KERI you don’t need to register a UTXO at all to use. Only if you want to rotate.

HC:I am missing the point of proving control over a BTC pub key that has no funds on it. As an identity system bitcoin is poor afaik. Great to see your presentation from 2018. Have you had a closer look at CESR and ACDC? The team had working code during the last IIW. I think you might recognize a few of your wishes (presentation 2018) have come through (composability, round-robin binary / text, inspectability (ricardian contracts).
https://wiki.trustoverip.org/display/HOME/ACDC+%28Authentic+Chained+Data+Container%29+Task+Force

---

CA: Another early draft document you may not have seen is on Open Development https://hackmd.io/shJVpilKT_KGgWhMAK_5Lw

Discussed this with Sam Smith today. Key management is in fact done outside of KERI. It's CESR that needs to be adapted to / extended for aggregated Schnorr, musig & frost. KERI doesn't care as long as there are valid sigs in the Key Event Log.
According to Sam there is no current demand for more sophisticated schemes. That's the reason it hasn't been developed yet. The good news though, and that is exactly what I suspected, is that CESR is extensible and KERI then can offer support for aggregated Schnorr, musig & frost.
CESR IETF draft https://datatracker.ietf.org/doc/html/draft-ssmith-cesr
CESR addresed in two articles https://medium.com/happy-blockchains/cesr-proof-signatures-are-the-segwit-of-authentic-data-in-keri-e891c83e070a