10:17:26 <SanadaYukimura[m> Any idea of implementing sharding after seraphis
12:12:15 <UkoeHB> SanadaYukimura[m: there hasn’t been any discussion of that that I’ve heard
12:31:41 <one-horse-wagon[> Doesn't the safety problem with multisig wallets come having only a partial number of authorized signatures sign off on a transaction?  Examples are 1 out of 2, 2 out of 4, etc.  Would it not be better to split a wallet key, how many number you wish to set up, so that everyone has to present their key portion for the wallet to sign off on a transaction?   
12:35:53 <moneromooo> Being able to sign with fewer members than possible is expressly intended.
12:36:54 <moneromooo> Also, even for N/N, raw secret sharing means someone at some point gets hte whole set and can act alone from that point on.
13:10:19 <one-horse-wagon[> If you can get the whole set at some point with N/N, wouldn't it be easier to do the same with a partial number of authorized signatures?  
13:41:23 <kayabaNerve> one-horse-wagon[: I'm not sure you understand how multisig works
13:41:43 <kayabaNerve> The point of threshold multisig, as mooo said, is for an authorized threshold to be able to create signatures
13:42:09 <kayabaNerve> Your idea, which is presenting keys to a wallet, is insecure as its dealing with raw keys. That lets "the wallet", a central instance, acquire the entire private key.
13:42:36 <kayabaNerve> Such secret sharing is available, I have a tool for it, but its intended for recovery. I give shares to my family and if necessary, can bring them together to get back my key.
13:43:10 <kayabaNerve> With threshold multisig, it's an adversarial model, where everyone is trying to steal the key for their own benefit, yet since they can't, they work together as per their own benefit.
13:43:23 <kayabaNerve> That's why not bringing the key together is important.
13:43:39 <kayabaNerve> It's not easier to do with a partial number of authorized signatures because the signatures don't leak the keys.
13:44:17 <kayabaNerve> While yes, its easier to acquire a sufficient amount of keys, as you only need t, not n, that's why thresholds are chosen carefully. A common example would be 3-5.
13:44:35 <kayabaNerve> Its double-fault tolerant with a majority rule.
14:01:31 <one-horse-wagon[> Thank you for the explanation.  The secret sharing tool you built is something I was thinking about too after mooo's response.  is it not possible to incorporate such a tool for N/N multisig wallets?
14:02:13 <one-horse-wagon[> * multisig wallets?kayabaNerve 
14:02:45 <kayabanerve[m]> You can do n-n multisig as you can do t-n multisig. The question is about where you want the key.
14:03:18 <kayabanerve[m]> The first is multisig. The second is secret sharing.
14:04:21 <kayabanerve[m]> Multisig doesn't reveal your private key when you sign. Recombining secret shares, which requires knowledge of the secret shares, does recover the key onto the computer in question.
14:04:36 <kayabanerve[m]> So whoever owns the computer, then owns the key.
16:06:41 <SanadaYukimura[m> <UkoeHB> "Sanada Yukimura: there hasn’t..." <-  https://eprint.iacr.org/2018/1188.pdf
16:08:17 <SanadaYukimura[m> Sharding is the next hot topic is the list. Hope MRL would have taken in the checklist
16:14:51 <SanadaYukimura[m> https://arxiv.org/abs/1906.12140
16:34:41 <UkoeHB> It sounds like every user wallet would have to maintain an accumulator state in order to spend their enotes - in addition to proving that ring members are on the chain. That sounds very expensive for both wallets and the network.
16:35:37 <UkoeHB> It would be great if we could have an anonymous group membership proof that uses an accumulator, but a) we don’t even have a proof of concept right now, b) afaik such proofs are still very bulky.
16:53:36 <SanadaYukimura[m> UkoeHB: certainly preparing POC. If it is tested well shall I share paper.
16:54:40 <UkoeHB> SanadaYukimura[m: you are working on a PoC? that sounds amazing :)
16:55:40 <SanadaYukimura[m> Yes.. but I didn’t know long it take
16:55:54 <UkoeHB> if you haven't seen, we do have this open issue https://github.com/monero-project/research-lab/issues/100
16:58:08 <SanadaYukimura[m> I have already seen this issue. I want to know why zksnark. Will it ruin monero uniqueness
16:58:49 <UkoeHB> zk-SNARKs aren't required, it's just the most prominent technology for doing those kinds of proofs, so it's worth exploring
17:03:35 <SanadaYukimura[m> Sure thing.. if is ask-SNARKs then plonk 2 will be better. I haven’t gone through full paper.
17:03:48 <SanadaYukimura[m> s/ask/zk/
17:04:30 <SanadaYukimura[m> UkoeHB: shall I explorer more on that issue.
17:04:39 <SanadaYukimura[m> s/explorer/explore/
17:05:35 <moneromooo> In general, knowing more is better. So if you are interested in something in particular, do feel free to investigate.
17:06:21 <SanadaYukimura[m> Thanks moneromooo 
17:06:56 <moneromooo> If you're asking for what would be most helpful for monero, then I don't know. But if you're asking "would it be helpful if I researched this thing I am planning to research", then yes.
17:08:38 <UkoeHB> SanadaYukimura[m: if you feel inspired and enthusiastic, then go for it :) you don't need anyone's permission lol
17:13:39 <SanadaYukimura[m> * UkoeHB: thanks, could you please any help
17:15:50 <SanadaYukimura[m> * UkoeHB: thanks. Really appreciated working with MRL.
17:15:59 <UkoeHB> if you have questions or need help, feel free to ask
17:16:08 <SanadaYukimura[m> Sure