15:19:27 <Rucknium[m]> There will be a meeting in this room in about 1.5 hours
16:59:21 <disclosure-bot-x> To all meeting participants: please disclose any potential conflicts of interest.
17:00:38 <Rucknium[m]> 🤨
17:00:51 <UkoeHB> meeting time https://github.com/monero-project/meta/issues/627
17:00:51 <UkoeHB> 1. greetings
17:00:51 <UkoeHB> hello
17:01:07 <one-horse-wagon[> Hello.
17:01:11 <rbrunner> Hi there
17:01:17 <Rucknium[m]> disclosure-bot-x: Please define conflict of interest in this context
17:01:31 <carrington[m]> Hi hi hi
17:01:33 <Rucknium[m]> Hi
17:01:52 <UkoeHB> It's a bot
17:02:16 <one-horse-wagon[> Rucknium.  Did you ever post Document A anywhere so I could read it?
17:02:37 <Rucknium[m]> I can send you the working draft
17:02:49 <Rucknium[m]> Do you want it now?
17:03:29 <jberman[m]> hello :)
17:03:49 <UkoeHB> Let's do updates briefly, then get into the agenda
17:03:49 <UkoeHB> 2. updates - what has everyone been working on lately?
17:04:08 <one-horse-wagon[> Rucknium[m]: Sure
17:05:43 <jberman[m]> Finishing up requested changes to the view tag PR (ty to UkoeHB for the review), then will be getting back to decoy selection work
17:06:02 <Rucknium[m]> My OSPEAD CCS proposal was funded (Thank you everyone!). I ran some analysis on the blockchain data for PR#8047. Working on Document A and incorporating feedback.
17:07:16 <UkoeHB> me: I made two MRL issues to discuss the design of a potential seraphis implementation. 1) PoC performance results ( https://github.com/monero-project/research-lab/issues/91 ), 2) Seraphis address schemes ( https://github.com/monero-project/research-lab/issues/92 ). Last week I found and fixed a rare crypto bug ( https://github.com/monero-project/monero/pull/8052 ). My next steps are integrating performance results into the 
17:07:16 <UkoeHB> Seraphis paper, then integrating coinstudent2048['s security modeling work into the Seraphis paper.
17:09:16 <Rucknium[m]> one-horse-wagon: Sent. If anyone else wants the draft of Document A, let me know. I'm just not posting it publicly since it's not good to have old versions floating around publicly.
17:10:55 <carrington[m]> I'm happy to wait unless you need feedback before pub. No shortage of other things here for me to catch up on!
17:12:08 <Rucknium[m]> carrington: I mean, it could be nice to have feedback. Mainly, it needs to be more accessible to laypeople. It sort of needs an introduction. 
17:12:27 <Rucknium[m]> You are not obligated to give feedback just because you receive it.
17:13:04 <carrington[m]> Well in that case sling it over and hopefully I'll be able to give some meaningful feedback in a few days
17:13:35 <UkoeHB> wfaressuissia: are you available to give an update on your multisig PR? It is a blocker for people planning to use multisig, so knowing what timeline to expect can be very helpful.
17:14:18 <rbrunner> Wait, is there a second multisig PR on the way, beside yours, UkoeHB?
17:14:45 <Rucknium[m]> carrington: Sent
17:16:03 <UkoeHB> rbrunner: yes, multisig is unusable until then. Maybe luigi1111 will make a statement ?
17:16:28 <rbrunner> You mean in the sense of "too risky", right?
17:16:33 <wfaressuissia> " It is a blocker for people planning to use multisig ..." soon
17:17:24 <rbrunner> I was asking myself whether it makes sense to test again your updated multisig code. So much changed that I would say my previous results are kind of invalid now.
17:17:40 <rbrunner> But maybe wait, and test with the second one on top?
17:17:49 <UkoeHB> Yeah, might as well wait.
17:19:30 <UkoeHB> wfaressuissia: ok well, sounds like it's closer than last time I asked lol
17:19:55 <UkoeHB> let's move on to agenda items; looks like a new one was added Rucknium[m] 
17:20:51 <Rucknium[m]> Yes. I think it would be great to put together a list of open research questions. Grin has this: https://grin.mw/open-research-problems
17:21:08 <wfaressuissia> " It is a blocker for people planning to use multisig, ..." what's the right place to discuss deeply how it will be used in practice ?
17:21:54 <Rucknium[m]> This would help us in a number of ways. First, it would help us determine priorities and maybe uncover low hanging fruit. The view tag idea comes to mind here.
17:22:35 <Rucknium[m]> It would help attract researchers, in general, since they would then know what the questions they could work on.
17:22:48 <carrington[m]> It seems like a good format for collecting what is presently scattered across github issues, papers, reddit posts and various websites.
17:22:55 <coinstudent2048[> Hi! Regarding open problems listing, I have some, but more "theoretical". What's the status of moneroresearch.wtf?
17:22:58 <Rucknium[m]> And if we have a more formal funding structure for MRL, they could serve as the basis for Requests For Propsals
17:22:59 <UkoeHB> wfaressuissia: I don't think there is a place right now (other than this channel). You could open an MRL github issue for longer-term discussions https://github.com/monero-project/research-lab/issues
17:23:13 <wfaressuissia> What's the performance difference (theoretical maximum, practical maximum, actual diff for wallet2 scanning) of view tag in practice ?
17:23:57 <wfaressuissia> That code is so "beautiful", there is non-zero chance that it's far from theoretical maximum of ~50% (?)
17:24:47 <Rucknium[m]> coinstudent2048[: Theoretical question are great to add. Status of moneroresearch.wtf is carrington was reaching out to spirobel  to work on it I think.
17:24:49 <wfaressuissia> "I don't think there is a place right now (other than this channel). " It makes sense to make usable for any market, not only haveno or something similar
17:25:05 <UkoeHB> I think the theoretical maximum is closer to 25%, since scalar mult key is so expensive compared to the operations you get to skip.
17:25:42 <wfaressuissia> "I think the theoretical maximum is closer to 25%" is it for asm from external/supercop or without ?
17:26:16 <UkoeHB> iirc it is the same with or without
17:27:18 <carrington[m]> I've had a pretty whacky IRL week so haven't made much progress on those ideas sadly. In the meantime I'm rereading ZtM2 and making notes
17:28:06 <UkoeHB> Ok, I don't think I did a direct comparison with 'unoptimized'. It is 25% using supercop.
17:29:32 <Rucknium[m]> Anyway, so it looks like coinstudent2048 has a small list of questions to contribute. I will make a MRL GitHub issue about it. I suppose I can host the working list on https://cryptpad.sethforprivacy.com/
17:30:47 <Rucknium[m]> Or maybe coinstudent2048 can make the MRL issue and start the CryptPad doc
17:30:49 <UkoeHB> > It makes sense to make usable for any market, not only haveno or something similar
17:30:49 <UkoeHB> Multisig has always been generic, although there is an address-generation optimization that really benefits uses of 2-of-3.
17:32:06 <wfaressuissia> I'm about end user API, current multisig related functions are crap and 1 instance of monero-wallet-rpc per 1 multisig wallet is a crap idea too
17:32:25 <carrington[m]> I was thinking that if we consider ZtM2 to be the protocol specification, it might make sense to organise  research/problems on the basis of the chapters of ZtM2 
17:32:29 <wfaressuissia> it's too heavy, there is a need for something more efficient
17:33:34 <UkoeHB> I think the issue is multisig tx builder code is heavily integrated with wallet2.
17:34:08 <UkoeHB> Along with all the labor of tracking outputs and recording state.
17:34:40 <wfaressuissia> The distance between ZtM2 and actual code isn't small and getting increased with time
17:35:37 <UkoeHB> carrington[m]: I wouldn't call ZtM2 a spec... but the organization might be useful. I'd also look at the Seraphis paper introduction for a sense of protocol structure.
17:37:23 <carrington[m]> Yes I should have said "nearest thing we have to a protocol spec". Points taken. Are any parts of ZtM2 badly outdated already? Or only after the next fork?
17:37:24 <Rucknium[m]> Oh, another thing that the list of open questions could be useful for is to tag articles on moneroresearch.wtf according to which questions they may address
17:38:43 <wfaressuissia> "I think the issue is multisig tx builder code is heavily integrated with wallet2." Everything is wallet2 is deeply integrated (due to short term ugly changes without any refactoring or redesign)
17:39:16 <wfaressuissia> * Everything in wallet2 ...
17:39:17 <UkoeHB> outdated: CLSAG is being used, fee/dynamic-block changes for next fork (https://github.com/monero-project/monero/pull/7819), BP+ for next fork, multisig chapter needs an update, a few minor details I can't remember
17:40:04 <rbrunner> Well, that's just progress. Of course ZtM2 is only a snapshot at a certain point in time. I fail to see anyhting special here.
17:40:14 <carrington[m]> Ah yes CLSAG. Thanks for the summary
17:42:27 <Rucknium[m]> Agenda item 7 is: The Science of Blockchain Conference 2022 Jan 24-26. Submission deadline: November 23, 2021 11:59pm PST
17:42:45 <Rucknium[m]> If we want to submit something to this, which I think we should, we need to do it very soon
17:43:08 <Rucknium[m]> Fingerprinting a Flood would be the obvious choice, as a work in progress
17:43:25 <UkoeHB> > Everything is wallet2 is deeply integrated (due to short term ugly changes without any refactoring or redesign)
17:43:26 <UkoeHB> With my Seraphis PoC I am trying to encapsulate as much tx protocol logic as possible, so wallet-level code just has to plug into component library APIs. Hopefully that gets us one step in the right direction.
17:44:49 <UkoeHB> Similarly, the multisig address PR pulled a lot of logic into the `multisig` component library.
17:44:56 <Rucknium[m]> What happened to wallet1? Was it lost in a boating accident?
17:45:19 <UkoeHB> Rucknium[m]: I suppose the authors of that paper would have to submit it.
17:46:08 <Rucknium[m]> I'm an author, so in theory I can submit. isthmus would be the best person to spearhead it, though.
17:48:54 <UkoeHB> Does anyone have any last-minute questions or things they want to discuss?
17:49:10 <Rucknium[m]> Should we discuss the Seraphis performance tests? I suppose my main comment is if there isn't a huge tradeoff, keeping the flavors that allow collaborative funding would be great.
17:49:50 <gingeropolous> which flavors? concise vs. whatever the other was?
17:49:51 <jberman[m]> <wfaressuissia[m]> ""I think the issue is multisig..." <- I was thinking of refactoring a bit of wallet2 during view tag stuff. It seems like we're continuously just going to add booleans for new features based on fork version (e.g. `use_rct`, `bulletproof`, `use_view_tags`), and pass the booleans from function to function
17:50:04 <luigi1111> UkoeHB: couldn't it be 50% if you tag the first pubkey instead of the correct one? 
17:50:04 <UkoeHB> The cost of collaborative funding is `32 + 96*(num_inputs - 1) bytes`.
17:50:12 <luigi1111> (or more) 
17:50:45 <UkoeHB> luigi1111: yeah it's 25% if you have 1:1 matching with outputs and txo pubkeys, there can be more if all outputs share a txo pubkey.
17:51:22 <luigi1111> hmm I don't get it
17:52:01 <luigi1111> not sharing pubkeys should make it faster in my version
17:52:02 <Rucknium[m]> UkoeHB: UkoeHB: Roughly, what's that in percentage terms? I know we haven't yet settled on a tx size yet.
17:52:27 <luigi1111> (same speed, faster as a % increase) 
17:53:45 <UkoeHB> The 25% comes from skipping `Ko - H(derivation,t)*G`. The remaining 75% is from computing `derivation = kv * R`. If a tx has one txo pubkey, then you only need to compute one `derivation` for the entire tx. The `Ko - H(derivation,t)*G` steps can be replaced with view-tag checks for all outputs. If you have one txo pubkey per output, then you have to compute `derivation_t` for each output - quite expensive.
17:55:46 <UkoeHB> Rucknium[m]: ~ 1-10% scaling with the number of inputs.
17:56:46 <Rucknium[m]> So a single input would be close to 1% larger tx size?
17:56:58 <UkoeHB> Yes
17:58:26 <UkoeHB> ~ 5% for a 2-in/2-out tx
17:58:26 <Rucknium[m]> Worth it, in my eyes. It is important that we have a breakdown of the tx characteristics of txs in the last year or so, in order to get a better sense of how your performance tests would play out in "production".
17:59:11 <Rucknium[m]> I can work on this with neptune 
17:59:26 <gingeropolous> what are we adding for 5%?
18:00:52 <UkoeHB> gingeropolous: the ability for multiple people to fund the same tx (provide inputs)
18:04:29 <Rucknium[m]> Noncustodial crowdfunding where donors can recover their XMR if the funding goal is not met.
18:06:12 <luigi1111> ukoe I get that, 25% seems the minimum increase
18:08:20 <luigi1111> <UkoeHB> gingeropolous: the ability for multiple people to fund the same tx (provide inputs) <= can't they do this now? 
18:09:41 <UkoeHB> not without interacting, collaborative funding allows 'independent' funding
18:09:45 <wfaressuissia> tx prefix hash is needed to derive signature challenge, that means set of signers should be known in advance
18:10:35 <UkoeHB> right ^
18:10:46 <wfaressuissia> key images for all inputs should be known in advance
18:10:53 <wfaressuissia> "... You could open an MRL github issue for longer-term discussions https://github.com/monero-project/research-lab/issues" I need at least 1 human who can dive deeply into problem. I don't see any value in comments from people with shallow knowledge of the problem.
18:10:54 <UkoeHB> Anyway, we are past the hour so I will call the meeting here. Thanks for attending everyone.
18:11:12 <wfaressuissia> UkoeHB: do you have few clones ? I need 1 for p2p discussion and 1 for cryptography ?
18:11:59 <UkoeHB> You can msg my matrix account. This IRCCloud account is my original one that I haven't quit using.
18:12:06 <Rucknium[m]> wfaressuissia[m]: Is this what is true now, or would this be true with Seraphis collaborative funding?
18:12:14 <UkoeHB> but matrix has encrypted chat which is nice
18:19:15 <UkoeHB> > I need at least 1 human who can dive deeply into problem.
18:19:15 <UkoeHB> I am open to suggestions, or just message me I guess lol.
18:20:38 <UkoeHB> Rucknium[m]: key images must be known in advance for the current protocol, because they are included (hashed) in input signatures (CLSAG).
18:22:19 <Rucknium[m]> UkoeHB: And that would not be the case with some of the Seraphis options, correct?
18:22:36 <UkoeHB> right
18:23:16 <jberman[m]> Can the collaborative funding model be explained a bit further - how would the protocol flow?
18:23:58 <Rucknium[m]> According to one interpretation, collaborative funding saved BCH from a devtax. It's that important to the ecosystem now.
18:24:21 <Rucknium[m]> jberman: Have you read the flipstarter explanation on read.cash?
18:25:36 <Rucknium[m]> See 
18:25:36 <Rucknium[m]> https://github.com/monero-project/research-lab/issues/91#issuecomment-967768995
18:25:56 <Rucknium[m]> It doesn't go into too technical detail, though
18:26:26 <UkoeHB> 1. define tx outputs (and any memos); send a 'tx proposal' to potential funders with the set of destinations (amounts and recipient addresses)
18:26:27 <UkoeHB> 2. each funder independently decides how much to contribute to the proposal; they make partial inputs and send them to the proposer
18:26:27 <UkoeHB> 3. when the proposer collects enough inputs to cover the output amount sum, they define the tx fee (this probably requires a custom-made output from the proposer, which also covers any remainder between inputs - outputs), complete the balance proof (and optionally, membership proofs); they submit the full tx
18:28:49 <jberman[m]> Got it
18:30:50 <atomfried[m]> i guess the critical part is the funders get the money back if the goal is not reached
18:32:50 <UkoeHB> yes, if a funded proposal never gets completed, then nothing happens to your funds
18:33:11 <Lyza> it seems the proposer can finish funding themselves though, yeah?
18:33:18 <UkoeHB> right
18:33:31 <Rucknium[m]> Yes, but that's true for a CCS, too
18:33:49 <Lyza> right but with CCS funds aren't disbursed until goals are met
18:33:55 <Lyza> this seems to disburse funds immediately
18:33:59 <Rucknium[m]> And they are still obligated by social convention to do the project.
18:34:22 <gingeropolous> it just seems niche for 5%
18:34:34 <Lyza> I think it could work but for proposers with less history / trust I guess the CCS is still there
18:34:42 <Rucknium[m]> Yes, it does, and a huge amount of BCH development runs on it
18:34:50 <jberman[m]> It sounds like it may be extensible to a coinjoin-like protocol
18:34:55 <Lyza> can colaboratively funded transactions be distinguished from normal transactions on the blockchain?
18:35:26 <Rucknium[m]> Monero has funding problems. I have people coming to me with good ideas, but they are wondering if the funding is really there.
18:35:31 <Rucknium[m]> CCS has no undo button
18:36:32 <Rucknium[m]> jberman[m]: 🤯
18:36:53 <UkoeHB> Lyza: there are two variations. In one variation, all funders reveal the output they are spending to the proposer (they delegate making the membership proof to the proposer). This variation is indistinguishable on-chain. In the other variation, funders make their own membership proofs, but since they aren't all made concurrently, this is distinguishable on-chain.
18:36:57 <Rucknium[m]> Hmm. Why didn't I think of how it could be used for BCH CoinJoins
18:38:00 <Lyza> the first seems preferable to me. if the funder is worried about revealing the output, they can send the donation to a fresh wallet they control first, no?
18:40:53 <Lyza> <Rucknium[m]> I don't see this being good for people new to the community. like I said, with CCS funds are held in custody until the work is complete. I can't see a lot of people wanting to fund an unknown person with funds they could run off with. for well known contributors, sure, but in that case are the funds ever in doubt? I guess I don't know how much the general fund is pitching in but I've never seen a CCS go unfunded even the 
18:40:53 <Lyza> imo kinda silly ones
18:41:22 <Lyza> not to say a decentralized way to fundraise isn't good; it would be
18:42:27 <Rucknium[m]> People who are new to Monero may have a previous body of work in another area.
18:42:40 <Rucknium[m]> That they can show. These things are repeated games.
18:43:24 <Lyza> for sure
18:45:05 <Rucknium[m]> >I don't know how much the general fund is pitching in
18:45:06 <Rucknium[m]> Not much, recently. binaryFate said he would indicate whenever the GF contributes
18:45:12 <Rucknium[m]> https://repo.getmonero.org/binaryFate
18:45:31 <Rucknium[m]> https://www.reddit.com/r/Monero/comments/pgdi11/comment/hbc3it7/
18:45:57 <Lyza> cool good info I forgot
18:51:16 <jberman[m]> It seems like it definitely can be extensible to a coinjoin-like protocol. Seems like you could have a server functioning as "the proposer"
18:51:49 <jberman[m]> 1. The server collects fixed amount denominations and recipient addresses from a group of users who want to collaborate
18:51:49 <jberman[m]> 2. Each funder re-connects to the server (to sever the link between recipient address and their inputs), and independently sends partial inputs to the server
18:51:49 <jberman[m]> 3. When the server collects enough inputs to cover the output amount sum... they submit the full tx
18:52:07 <jberman[m]> Could be missing something
18:52:53 <Rucknium[m]> How does that compare with CashFusion?
18:52:55 <Rucknium[m]> https://github.com/cashshuffle/spec/blob/master/CASHFUSION.md
18:54:06 <Rucknium[m]> jberman: If you feel that you have a solid idea, for sure post it on bitcoincashresearch.org
18:56:47 <jberman[m]> There isn't any DDoS protection in what I described. would need to think on it more
18:57:31 <jberman[m]> But in any case, I'm talking about it in the context of Monero here. A coinjoin-like protocol would offer an additional way to sever linkages across outputs, but seems like either it would be distinguishable on chain from others, or would reveal some spent ouputs to a server. neither are great. and plus it's interactive and won't really be ideal for the average user
18:58:23 <Rucknium[m]> How is it interactive?
18:58:47 <UkoeHB> jberman[m]: have you seen TxTangle, ch11 of ztm2?
19:01:53 <jberman[m]> oh sweet, no haven't made it that far yet
19:02:50 <gingeropolous> <Rucknium[m]> Monero has funding problems. I have people coming to me with good ideas, but they are wondering if the funding is really there. >>> well there's only 1 way to find out. i don't see how decentralizing a funding mechanism that costs 5% is necessary. but im just a fuddy duddy when it comes to these things i guess. i never expect the cash in my wallet to start having contracts
19:03:18 <gingeropolous> decentralizing things just for the sake of decentralizing them is ....... something something
19:05:32 <Rucknium[m]> The centralized CCS has lots of problems. I am writing a review essay comparing my experiences with Flipstarter vs CCS. Monerujo wallet tried to go through CCS but was blocked due to its permissioned nature and now uses plowsof  's Wishlist as a Service.
19:06:46 <Rucknium[m]> It's not just decentralizing for the sake of decentralizing. Also, people have mentioned that Monero users are already using Monero to circumvent Kickstarter, et al. preventing them from receiving funding.
19:07:04 <Rucknium[m]> This would allow them to expand their use of Monero for that purpose.
19:09:06 <endogenic> while we're at it can we discussing establishing a legal structure to protect the liability of independent scholarly funded work on the monero project? I'm working with my counsel on this but they're a bit slammed with the holiday season, though I expect movement on it fairly soon
19:09:38 <endogenic> I'll look forward to reading your post Rucknium! 
19:10:14 <wfaressuissia> +
19:10:29 <Rucknium[m]> >liability of independent scholarly funded work on the monero project
19:10:30 <Rucknium[m]> How could there be liability?
19:10:31 <endogenic> s/discussing/discuss/
19:10:47 <endogenic> Rucknium[m]: there are lots of reasons people might suspect it would cause them direct personal liability
19:10:48 <one-horse-wagon[> endogenic: I don't understand what you would be liable for?
19:10:49 <gingeropolous> yeah other mechanisms besides ccs should exist, and now they do
19:11:17 <endogenic> it's often cited as one reason people want to stay behind a corporate shield or why they just want to go totally anonymous 
19:12:02 <Rucknium[m]> Ok, what are those reasons, then?
19:12:42 <jberman[m]> <Rucknium[m]> "How is it interactive?" <- what I described requires interaction between participants and a server/other users to successfully construct a tx. Whereas I can construct a publicly verifiable ring signature today without interaction with others
19:14:08 <Rucknium[m]> Right. With CashFusion users just set the option to fuse in the background and the wallet (with the server) takes care of everything and does as many fusions as it can over hours or days.
19:14:36 <Rucknium[m]> That's interaction at the wallet-to-server level, but not at the user-to-wallet level.
19:17:23 <Rucknium[m]> endogenic: I am aware of the ETH dev case (Virgil Griffith), but he literally went to North Korea.
19:25:27 <endogenic> Ethereum is not monero and Virgil is not necessarily going to be an activist for certain topics nor is he going to be advising the same people etc etc
19:25:41 <endogenic> sorry, the question deserves a reply but I'm not prepared to have the convo at the moment
19:28:45 <neptune> "<Rucknium[m]> I can work on this with neptune" Sounds fun!
19:35:06 <Rucknium[m]> neptune: We can go further. We can work on it with mj-xmr  since mj has the forecasting model apparatus. Forecast the dynamics and demand for each tx variation.
19:36:08 <Rucknium[m]> <endogenic> "sorry, the question deserves a..." <- Ok. Let me know when you have more info.
19:36:31 <endogenic> I will, thank you!
19:41:29 <neptune> Rucknium[m]: interesting idea 
19:43:33 <Rucknium[m]> What we're doing here is talking about scaling in the future. It would be good to have some forecasting to pair with UkoeHB 's performance tests.
19:47:17 <mj-xmr[m]> neptune: So far the Time Series Analysis looks like this:
19:47:19 * mj-xmr[m] uploaded an image: (53KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/GFAECOKBQHdqvTHoZfjeLnCl/image.png >
19:47:53 <mj-xmr[m]> Plus a lot more, that's still hidden, until I decouple it from the rest of the irrelevant parts.
19:49:00 <Rucknium[m]> Does someone want to make an issue on the MRL GitHub?
19:52:35 <UkoeHB> sounds like we have a volunteer :)
19:53:40 <Rucknium[m]> I voluntell mj-xmr  to open a MRL GitHub issue. 😉
19:54:24 <mj-xmr[m]> (trying to find excuses...)
20:10:58 <one-horse-wagon[> <Rucknium[m]> "endogenic: I am aware of the ETH..." <- That was an extremely unusual case.  Griffith comes back from North Korea and proceeds to tell the FBI everything he did.  He left nothing out, did so willingly and signed off on it too.  So what do you want the FBI to do with information?  They proceeded to arrest him and the DA prosecuted him.  Personally, I think the guy was not doing well, mentally.
22:30:08 <luigi1111> <Rucknium[m]> The centralized CCS has lots of problems. I am writing a review essay comparing my experiences with Flipstarter vs CCS. Monerujo wallet tried to go through CCS but was blocked due to its permissioned nature and now uses plowsof  's Wishlist as a Service.
22:30:35 <luigi1111> just to be clear this is untrue, or missing significant context at the very least 
22:31:00 <luigi1111> also interactive coinjoin us certainly possible now
22:31:05 <luigi1111> is*