{"type":"rich","version":"1.0","author_name":"npub1jqxs4ftunmm8qjyw9s80hpcayewkjfhpxund29l9qvzy7xqx4duq85jqeg","author_url":"https://nostr.ae/npub1jqxs4ftunmm8qjyw9s80hpcayewkjfhpxund29l9qvzy7xqx4duq85jqeg","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-04-09\n📝 Original message:Hi Sjors\nThanks for the feedback!\n\nThe first step is for the Coordinator to generate a TOKEN, presumably using\n\u003e its own entropy. But IIUC anyone who intercepts that token can decrypt any\n\u003e future step in the setup process. This suggests a chicken-egg problem where\n\u003e you need some pre-existing secure communications channel.\n\u003e\n\nThe exchange of the TOKEN is frequently mistaken as the chicken-and-egg\nproblem, but it is not so.\n\nTo understand why this isn't chicken-and-egg, and why the TOKEN actually\nadds value, consider *the scale of the communication operation needed to\nexchange the TOKEN*, and *the scale of the communication operation needed\nto gather data for the creation of the multisig wallet *(with or without\nthe TOKEN):\n\n1) The TOKEN itself is a single piece of data that is 64- or 96-bit. It is\nsmall enough to be easily exchanged (even memorized) and entered into\nvarious devices. It requires only a single round of communication, but can\nprotect as many rounds of communication as needed.\n\n2) The data needed to create the multisig wallet, on the other hand, are\nquite involving:\n(a) Each Signer needs to share its XPUB, which cannot be memorized\n(b) The XPUBs also come with their own metadata\n(c) The creation of the wallet requires at least two rounds of\ncommunications since the Signers need to voluntarily share their XPUBs\nfirst, only then can a Coordinator combine the XPUBs into a single multisig\nscript and pass back the configuration to the Signers. (Note that without a\nCoordinator, you'll need O(N^2) rounds of communication).\n(d) Because Signers are typically off-line cold storage, the paths between\nthe Signers / the Signers \u003c\u003e Coordinator likely involve multiple hops\nthrough various media, such as unsecure USB connection. This is the way\nmost multisig solutions are currently being implemented. It means the XPUBs\nand the multisig configuration are vulnerable to leaking and/or\nmodifications.\n\nNote that (d) is especially problematic for remote multisig setups. The\nmore remote, the more potential hops along the way, the more problematic.\n\nSo you can see that *the TOKEN ultimately reduces the problem of sharing a\nlarge amount of sensitive data back and forth, to the sharing of a single,\nsmall piece of data upfront.* An added advantage of this approach is that\nif the parties fail to establish a shared TOKEN, the scheme fails with no\nharm done.\n\nThe Coordinator, on the other hand, adds value by solving the O(n^2)\ncommunication problem. Some minimal amount of trust is needed for the\nCoordinator, but this can be greatly mitigated by a number of ways that we\nhave defined in the spec, such as:\n* Signers must check that their XPUBs are included in the final descriptor\n* Signers must display to the user the multisig configuration: M/N,\nrelative position(s) of XPUBs, etc.\n* Signers must display the full descriptor upon user request for manual\ninspection - this one is important because it means that the new scheme\ncannot be worse than the status quo.\n* Signers are recommended to display a preview of the first receive\naddress(es).\n\nAll in all, the Coordinator's role helps ease the setup process, while its\nability to pull off any shenanigans is greatly limited.\n\nBest,\nHugo\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210409/fadc12cb/attachment-0001.html\u003e"}