01:32:24 <derpy_bridge> <[keybase] unseddd>: pong sarang
01:39:35 <sarang> I haven't run local fuzz tests before (shame on me) and I'm getting an error asking for an input file
01:39:50 <sarang> The gen_corpus flag is being parsed as a filename
01:39:54 <sarang> wat do unseddd
01:40:15 <sarang> (this is for your CLSAG fuzz PR)
01:58:34 <derpy_bridge> <[keybase] unseddd>: what's up?
01:59:25 <derpy_bridge> <[keybase] unseddd>: hrm, maybe I checked in a previous version of the test... my bad, will fix and push
02:16:43 <derpy_bridge> <[keybase] unseddd>: idk what the problem would be. does not happen on my end. will do a fresh pull, and try re-running the test
02:36:04 <derpy_bridge> <[keybase] unseddd>: sarang: I am dumb, wrote `--gen_corpus` when it should be `--gen-corpus`. doc error...
02:37:27 <derpy_bridge> <[keybase] unseddd>: let me know if that fixes it for you
10:53:44 <sarang> unseddd: please update the CLSAG fuzzer to integrate with moneromooo's fuzz shell script runner
15:49:04 <derpy_bridge> <[keybase] unseddd>: sure, was not aware of the fuzzer script. will take a look after the meeting
16:50:12 <sarang> Meeting here begins at 17:00 UTC (about 10 minutes from now)
16:59:31 <sarang> OK, let's get started with the research meeting!
16:59:36 <sarang> First, GREETINGS
16:59:37 <sarang> hi
17:00:32 <ArticMine> hi
17:00:34 <derpy_bridge> <[keybase] unseddd>: o7
17:00:57 <UkoeHB_> hi
17:01:17 * Isthmus boots up
17:02:14 <sarang> Let's go ahead and continue with the ROUNDTABLE
17:02:22 <sarang> Anyone is welcome to share research topics of interest
17:03:18 <sarang> I suppose that I can share a few things
17:03:49 <sarang> Relating to timelocks, I extended CLSAG and Triptych to support them
17:03:59 <sarang> CLSAG: https://github.com/SarangNoether/monero/commit/28f098260c5bb4da57bb78ebc885fe27c9f10c39
17:04:05 <sarang> Triptych: https://github.com/SarangNoether/monero/commit/ed48ab1686b7e7405bd6656c18e37ea21e01fe05
17:04:44 <sarang> Here is corresponding timing data: https://usercontent.irccloud-cdn.com/file/dQXuFH2U/timing.png
17:05:02 <sarang> 3-CLSAG and 3-Triptych are the timelock-friendly data series
17:05:16 <sarang> The other data series are unchanged from when I first shared them
17:05:52 <sarang> I suspect that 3-CLSAG could be optimized by perhaps another 10% or so from what appears on the plot
17:06:47 <sarang> Unrelated to this, I'm updating how in-memory key encryption is handled, which is taking a bit longer than expected
17:07:12 <sarang> and am reviewing the new CLSAG fuzzer tool that unseddd provided
17:07:22 <sarang> That's about it from me!
17:07:30 <sarang> Are there any questions that I can answer?
17:07:52 <Isthmus> Nice work
17:07:57 <sarang> Thanks!
17:08:23 <ArticMine> CLSAG optimization in verification time, size or both
17:08:28 <derpy_bridge> <[keybase] unseddd>: seconded, nice stuff sarang
17:08:49 <sarang> ArticMine: in verification time, and only for the new 3-CLSAG variant that would apply to encrypted timelocks
17:08:49 <ArticMine> Great work by the way
17:09:02 <ArticMine> Thanks
17:09:24 <sarang> When I wrote 3-CLSAG, I used a particular multiscalar multiplication that could likely be made faster for this particular case
17:09:56 <sarang> Also, huge thanks to unseddd for reviewing CLSAG and writing the fuzzer tool
17:10:10 <derpy_bridge> <[keybase] unseddd>: is 3-CLSAG limiting the multisig to three parties?
17:10:25 <derpy_bridge> <[keybase] unseddd>: np :)
17:10:26 <sarang> No, it adds another key component that would be used for timelocks
17:10:46 <sarang> Right now we have two key components: one for the usual signing, and the other for balance purposes
17:10:49 <derpy_bridge> <[keybase] unseddd>: ah, thanks for the clarification
17:11:36 <sarang> Does anyone else wish to share research of interest?
17:12:25 <UkoeHB_> it seems like 3-triptych would reduce the ringsize likely to be selected by a power of 2
17:12:38 <derpy_bridge> <[keybase] unseddd>: not much interesting on my end. just reading formal verification papers + some pq-crypto stuff from Mike Hamburg
17:12:43 <sarang> Adding encrypted timelocks is a nontrivial verification hit
17:13:29 <ArticMine> What is the time ans size cost
17:13:44 <sarang> What might be interesting as an alternative would be to allow cleartext timelocks, but update decoy selection to account for known spend patterns
17:14:00 <sarang> It would not eliminate fingerprinting, but could help to mitigate age-related selection heuristics
17:14:22 <derpy_bridge> <[keybase] unseddd>: are there any leakage issues having the timelock in the clear?
17:14:43 <sarang> ArticMine: going from CLSAG to 3-CLSAG is about 1.4x increase in verification time
17:14:59 <sarang> Which could probably be reduced slightly with some extra work
17:15:45 <sarang> In terms of size it's fairly trivial... adding an extra auxiliary key image (this does not account for other non-signature data)
17:16:04 <sarang> unseddd: for sure
17:16:22 <sarang> I'm not saying that I advocate for such an approach, only that it could be an option
17:16:33 <sarang> and would not imply any size/time hits
17:17:07 <UkoeHB_> it's a ways down the road, but I'd like to mention it now; when deciding ring sizes for next gen tx protocol I feel it should be based on a broader analysis of theoretical maximum tx throughput of the network; this is because the max tx volume is when rings are _least_ useful to defend against non-scaling graph heuristics, and because larger ring sizes actually reduce the max tx volume; it's an optimization
17:17:07 <UkoeHB_> problem
17:17:41 <derpy_bridge> <[keybase] unseddd>: right, from a naive perspective, triptych seems like it has enough savings for the hit from timelocks
17:20:04 <sgp_> sorry I'm late. catching up
17:20:04 <ArticMine> UkoeHB_ The maximum tx throughput is also dependent on external factor tat keep improving over time
17:20:42 <UkoeHB_> unfortunately that optimization depends on the efficacy of ring sizes.. which we don't have a complete understanding of; I hope suraeNoether can return to that topic at some point
17:20:55 <UkoeHB_> ArticMine: true, there are a lot of factors to consider!
17:21:27 <sarang> At the very least, we now have concrete numbers for the spacetime effects of ring size increases
17:21:33 <atoc> hi
17:22:05 <sgp_> the cost of encrypted timelocks seems extreme to me tbh. I don't want to go there unless we know we need to support them for a good use-case
17:22:42 <sarang> Getting timelock-related spend age data from transparent chains might be helpful if it's decided to continue to allow cleartext timelocks
17:23:01 <sarang> Then output selection could be improved to account for it, and reduce the usefulness of spend-age heuristics
17:23:39 <derpy_bridge> <[keybase] unseddd>: use-case: timelocks necessary for atomic swap, encrypting is the most private
17:24:50 <derpy_bridge> <[keybase] unseddd>: could also see the counter-point for clear timelocks if they are necessary for atomic swaps (interop w/ clear chains maybe)
17:25:37 <sgp_> sarang: I agree, but given the current low utilization, I consider this low priority. The impact to the wider network is negligible
17:25:55 <ArticMine> Payment channels come to mind here
17:26:10 <ArticMine> also escrow
17:26:30 <sgp_> if there's a payment channel, then we can move to make encrypted mandatory. when that happens
17:26:30 <sarang> Getting that kind of transparent chain data seems pretty straightforward
17:26:50 <Isthmus> @sarang, it's on my to-do list for XMR and BTC
17:26:54 <sarang> :D
17:27:12 <sarang> How do you plan to examine spend-age data for XMR?
17:27:57 <sarang> It was examined in Miller for "deducible" outputs (pretty sure that's the term they used) that were the result of chain reactions, which we find don't occur anymore
17:28:25 <Isthmus> Oh, I just meant comparing the unlock time height to block height to see how many of them even make sense
17:28:38 <Isthmus> Not that current usage tells us much about future applications.
17:28:45 <sarang> Ah, got it
17:28:52 <Isthmus> What is it that you were interested in?
17:28:53 <atoc> Isthmus are you thinking about atomic swaps these days at all/
17:29:22 <Isthmus> @sarang sorry I'm in a zoom call and IRC meeting at the same time, and missing little pieces of both
17:29:37 <sarang> I'd like to see the age distribution of spent outputs in a transparent asset (like BTC) relative to lock expiration, to see if it differs substantially from the overall age distribution
17:30:04 <sarang> No problem Isthmus!
17:30:09 <Isthmus> ahhh, yea I can't officially do that for Monero yet. I'll pull it for BTC though.
17:30:33 <UkoeHB_> can't officially? it's possible?
17:30:36 <sarang> Thanks! The overall distribution likely is still similar to the Miller data
17:30:42 <sarang> (for BTC, of course)
17:30:58 <sarang> and having that data would be an interesting check of that
17:31:47 <Isthmus> @UkoeHB_ yeah, I mean my research over the past few years reveals anonymity puddles covering like 20% of transactions. Then change outputs bleed everything, so there's a ton of data  on obviously real spend times. BUT no guarantee that it's representative.
17:32:53 <Isthmus> I'll be supper curious to see the BTC distributions, will try to get that in the next week or so.
17:32:57 <Isthmus> *super
17:33:13 <sarang> Yeah, Miller's team used two different large sets of blocks in BTC for their analysis
17:33:22 <sarang> and found the distributions to be similar
17:33:57 <sarang> but it doesn't appear they accounted for locks
17:37:01 <sarang> OK, did anyone else have a topic to discuss?
17:37:21 <Isthmus> Insight is interested in researching practical post-quantum cryptography for Monero, especially privacy features that will remain secure against retrospective deanonymization by future adversaries that can utilize Shor's algorithm, Grover's algorithm, etc. I want to know what our options are, and their costs (complexity, proof size, generation/verification time, etc)
17:37:23 <Isthmus> https://github.com/insight-decentralized-consensus-lab/post-quantum-monero/blob/master/README.md
17:37:37 <Isthmus> Looking for feedback on the research plan.
17:38:43 <Isthmus> Our goals are to (1) study and simulate the threats listed above to assess vulnerability to quantum computers, (2) evaluate post-quantum cryptography scheme candidates to create a roadmap for hardening Monero against quantum adversaries, and (3) provide open-source proof-of-concept code and demos where applicable.
17:39:16 <derpy_bridge> <[keybase] unseddd>: i like pq stuff :) will take a look
17:40:02 <sarang> Sounds like a fascinating project
17:40:22 <sarang> I'd be very curious to see what exactly the Phase 3 deliverables would look like
17:40:43 <Isthmus> Me too! ^_^
17:40:55 <sarang> and I think it'd be important to assess any transtion points between constructions/protocols
17:41:07 <sarang> e.g. it was possible to transition from pre-CT to post-CT
17:41:21 <Isthmus> Yeah, we'll have to document both the transition and post-transition costs/tradeoffs
17:41:43 <sarang> New constructions are great, but if it's not possible/feasible to transition on the same chain, that's a sticking point
17:42:01 <derpy_bridge> <[keybase] unseddd>: here is the Hamburg paper i am reading through: https://www.shiftleft.org/papers/qromcca/
17:42:12 <ArticMine> Yes this is a very interesting project
17:42:13 * Isthmus bookmarks paper
17:44:30 <sarang> Are you confident about the timeline?
17:44:37 <sarang> Particularly surrounding the Phase 3 stuff
17:45:06 <sarang> (not that practical quantum computers are expected by the end of summer...)
17:45:49 <Isthmus> There's two types of things we could prototype
17:46:00 <UkoeHB_> it does say May - June, only a couple days away, not sure if a CCS could be approved and funded in time
17:46:07 <derpy_bridge> <[keybase] unseddd>: ten million qubits by fall!!!
17:46:16 * Isthmus makes a note to update the date, thanks.
17:46:34 <Isthmus> (1) demo of a quantum computer breaking a Monero encryption feature (at a reduced keysize, or something like that)
17:46:37 <UkoeHB_> s/June/July
17:46:37 <monerobux> UkoeHB_ meant to say: it does say May - July, only a couple days away, not sure if a CCS could be approved and funded in time
17:46:55 <Isthmus> Adam did this before, got an IBM quantum computer mining bitcoin at shorter hash length
17:47:21 <Isthmus> So that's demo breaking classical crypto
17:47:22 <Isthmus> (2) prototype a possible solution
17:47:34 <Isthmus> (so we'd use traditional computers and prototype a future solution)
17:47:35 <derpy_bridge> <[keybase] unseddd>: _thoroughly impressed_
17:47:46 <Isthmus> Now honestly, I think that #2 would be way cooler. But it also may be hopeful thinking
17:48:03 <Isthmus> I've seen Adam rapidly convert math papers to code before, but this is going to be a pretty serious endeavor
17:48:04 <sarang> Either way, would be fascinating
17:48:21 <Isthmus> here was my note in the writeup
17:48:23 <Isthmus> "Phase 3 deliverables: The best use of time during this final stage depends strongly on results from the exploratory research. Likely deliverables are a proof of concept or prototype tooling for demonstrating a vulnerability or potential solution"
17:48:23 <UkoeHB_> would (1) also include a comparison with a classical computer on the same task? at reduced keysizes, the encryption is weaker on classical computers too
17:48:30 <derpy_bridge> <[keybase] unseddd>: Isthmus: are Adam and you regularly in IRC? what is best communication channel?
17:48:35 <Isthmus> @UkoeHB_ exactly
17:48:45 <Isthmus> Adam'll be on IRC shortly :- )
17:48:59 <Isthmus> We'll probably do a lot of the research in this room, if that's okay with people?
17:49:04 <Isthmus> Or could make #pq-mrl
17:49:12 * Isthmus ops just in case
17:49:19 <sarang> Up to you!
17:49:44 <Isthmus> 👍
17:50:45 <sarang> OK, any other topics to address before finishing up the meeting?
17:50:52 <UkoeHB_> does anyone have new thoughts on https://github.com/monero-project/monero/issues/6456?
17:51:43 <derpy_bridge> <[keybase] unseddd>: UkoeHB_: unfortunately no, have been consumed elsewhere. many apologies
17:51:44 <sarang> UkoeHB_: I got unexpectedly caught up in other coding, and didn't review in detail yet :/
17:51:45 <Isthmus> Oh! Yeah, I'll look at that by Monday. Hopefullly today
17:51:46 <sarang> my aopologies
17:51:56 <sarang> s/aopologies/apologies
17:51:56 <monerobux> sarang meant to say: my apologies
17:52:50 <sarang> All righty, any ACTION ITEMS for the next week to share?
17:53:48 <sarang> I will be reviewing 6456, reviewing some CLSAG tests, updating some in-memory encryption code, etc.
17:54:03 <Isthmus> I'll probably bump the pq-monero proposal over to CCS by EOW, so shoot me a message (irc or isthmus⊙go works) if you have any suggestions for updates or additions
17:54:03 <UkoeHB_> on a certain level I have nothing else to contribute to the proposal; whether it gets implemented or not is out of my control; keep in mind it likely won't be superseded by anything, so for 'tx extra', 'janus mitigation', 'tx pub keys', and 'view tag', that's the 'final answer' for the forseeable future
17:54:46 <atoc> I'm working on some slides (summary) that details how Grin does their grin-btc atomic swap
17:55:07 <atoc> looking to see if we can get some insight for xmr-btc swaps
17:56:25 <hyc> Iǘe become convinced that itś never in any XMR holders'interest to swap for BTC, due to BTC taint issues
17:57:34 <hyc> but I'd be curious to see how it can work, for future XMR(earth)/XMR(mars) swaps
17:57:40 <derpy_bridge> <[keybase] unseddd>: hyc: even for true DEX scenario?
17:58:09 <derpy_bridge> <[keybase] unseddd>: marsero
17:58:18 <hyc> especially for true DEX, wher eyou can't vet the BTC
17:58:49 <hyc> the benefits are all one-sided, in favor of the BTC seller
17:58:51 <Isthmus> Eh if I've got a wallet full of Monero, but the sandwich shop I'm standing in only takes BTC, I might find that swap useful.
17:59:05 <ArticMine> I have to agree with hyc Selling XMR for BTC on a swap is very dangerous
17:59:05 <derpy_bridge> <[keybase] unseddd>: yeah, i see your point. do you have the same opinion for other swap pairs?
17:59:24 <hyc> if the other pairs also involve transparent coins, yes
17:59:56 <sgp_> +1 concern here
17:59:56 <sarang> Well, in the interest of time (our hour is up), I'll adjourn the meeting for log purposes, but discussion can of course continue
18:00:14 <atoc> i still think swaps for dex is better as currently many use centralized exchanges for xmr-btc swap
18:01:05 <derpy_bridge> <[keybase] unseddd>: thanks for the meeting and lively discussion :)
18:01:21 <UkoeHB_> I don't really understand the benefit of swaps, since you can already exchange xmr/btc fairly easily
18:01:29 <hyc> I think in the case of BTC it's safer for users to use centralized exchanges
18:01:38 <hyc> who guarantee the BTC you receive is clean
18:01:48 <atoc> true UkoeHB_
18:01:52 <atoc> hmm good point
18:02:22 <hyc> there may be other coins worth swapping with. maybe zcash if they every migrate to z-only
18:02:33 <derpy_bridge> <[keybase] unseddd>: atoc: i agree with you. while xmr-btc is riskier from a "might-be-dirty" perspective, atomic swaps are a practical improvement from a trust perspective
18:02:58 <atoc> btc-xmr atomic swap is a research topic which is why I have been investigating
18:03:06 <atoc> and yeah hopefully it can be applied to other coins
18:03:08 <derpy_bridge> <[keybase] unseddd>: the protocol could also include built-in taint analysis for "dirty" coins
18:03:32 <hyc> ah that's an interesting idea
18:03:36 <atoc> as far as btc-xmr in particular we should note implications you describe
18:03:42 <sgp_> the only swap I'm interested in tbh is XMR/zZEC
18:03:44 <hyc> if you actually *can* screen the BTC before the swap commits, that could be ok
18:04:00 <atoc> hmm that would be interesting
18:04:09 <Isthmus> What about BTC coinbase <> XMR swaps
18:04:19 <sgp_> BTC coinbase, maybe
18:04:26 <atoc> idk how that screening algo (taint analysis) would work
18:04:28 <hyc> hm, that sounds ok
18:04:43 <atoc> and hopefully there are no false-positives
18:04:53 <atoc> yeah that's good
18:04:54 <sgp_> atoc: it would be terrible unless you pay for a "big three" blockchain analytics firm (and perhaps some smaller ones)
18:04:55 <atoc> Isthmus
18:05:03 <Isthmus> taint analysis requires blacklists or oracles, so coinbase-only is the only way I can think of to do it a priori without centralization
18:05:04 <UkoeHB_> would swapping to XMR automatically taint coins? is a swap identifiable?
18:05:16 <Isthmus> taint is in the eye of the beholder
18:05:41 <sgp_> Isthmus: sure, but....... not really
18:05:43 <atoc> good question UkoeHB_ and yeah Isthmus lol
18:05:47 <derpy_bridge> <[keybase] unseddd>: atoc: no idea how it would work either (not a chain analyst). but those c*nts have some algos that work, so we could repurpose them for good ;)
18:05:53 <sgp_> UkoeHB_: it might taint the BTC
18:06:12 <UkoeHB_> well using a mixer already taints BTC so I imagine xmr<->btc would too
18:06:16 <Isthmus> Hey @atoc - circling back to earlier. I haven't thought about atomic swaps much but I'd be happy to :- ) What are the interesting questions there these days.
18:06:32 <atoc> @unseddd indeed
18:06:51 <hyc> I would guess you can't hide that it's a swap txn on the BTC chain
18:06:56 <atoc> we are currently trying to use this implementation
18:06:58 <atoc> or rather
18:07:09 <atoc> get an implementation for these ideas by h4sh3d
18:07:18 <atoc> https://github.com/h4sh3d/xmr-btc-atomic-swap
18:07:40 <atoc> we are missing ideas for a general zkp that proves the pre-images of discrete log groups
18:07:44 <atoc> well there are some ideas
18:07:50 <atoc> however we need to try and see if they work
18:08:21 <atoc> Grin claims to have successfully done a grin-btc atomic swap in a similar fashion along the same lines
18:08:39 <atoc> so right now I am looking to get a better understanding of their implementation
18:08:48 <atoc> and see how it could work for xmr-btc
18:09:10 <derpy_bridge> <[keybase] unseddd>: xmr-grin-btc could create some interesting tx-flows
18:09:53 <sgp_> I'm iffy about even xmr/grin
18:10:18 <derpy_bridge> <[keybase] unseddd>: (derp thought, not serious)
18:10:21 <atoc> discrete log groups equality (ideas of @andytoshi, documented by @sarang) here: https://web.getmonero.org/resources/research-lab/pubs/MRL-0010.pdf
18:10:38 <atoc> has useful ideas for this as well
18:10:49 <atoc> @unseddd hmm that would be interesting
18:11:04 <atoc> I haven't considered that
18:11:43 <derpy_bridge> <[keybase] unseddd>: lol mb, think it would be funny to see an analysts face, like "wtf is even happening?"
18:11:46 <atoc> hopefully that gives an idea of current questions Isthmus :)
18:11:49 <hyc> presumably after you solve it for XMR-BTC others will follow easily
18:12:20 * Isthmus is on a video call, will be back in a bit
18:12:37 <atoc> yes this is what I am thinking about grin-btc
18:12:46 <atoc> it seems they have a relatively general approach
18:13:29 <atoc> https://www.youtube.com/watch?v=sT3vNycMxw4
18:13:29 <monerobux> [ 06 @jaspervdm: Atomic Swaps - YouTube ] - www.youtube.com
18:13:47 <atoc> @unseddd yeah lol
18:14:29 <derpy_bridge> <[keybase] unseddd>: think i will follow Isthmus out the room. thanks again for such a cool conversation
18:14:49 <atoc> yes thanks everyone
18:16:02 <scoobybejesus> .time pdt
18:16:02 <monerobux> Could not find timezone pdt.
18:16:17 <hyc> 11:16am
18:16:35 <hyc> pretty shit timezone lookup
18:16:48 <scoobybejesus> .time pst
18:16:48 <monerobux> Could not find timezone pst.
18:16:59 <scoobybejesus> one last try....
18:17:01 <moneromooo> .time `ls`
18:17:01 <monerobux> Could not find timezone `ls`.
18:17:04 <scoobybejesus> .time est
18:17:04 <monerobux> 2020-04-29 - 13:17:04EST
18:17:50 <scoobybejesus> it's not including daylight savings i guess..  off an hour...  anyway    /spam
18:18:18 <atoc> btw what's the story behind monerobux
18:18:37 <atoc> is this bot opensource and worked on by the Monero community?
18:18:40 <atoc> cool feature
18:18:48 <hyc> jwinterm is author, I believe
18:18:58 <atoc> ah nice
18:19:16 <sarang> I invited it to help with time, substitutions, etc.
18:19:23 <sarang> My favorite color is green
18:19:25 <sarang> s/green/blue
18:19:25 <monerobux> sarang meant to say: My favorite color is blue
18:19:34 <hyc> lol
18:21:01 <hyc> but as you might guess from the name, was originally written to give us coin stats in the -markets channel
18:21:49 <atoc> i like the meant to say feature
18:21:50 <atoc> lol
18:22:14 <atoc> s/meant to say/bux
18:22:14 <monerobux> atoc meant to say: i like the bux feature
18:24:28 <moneromooo> s/`/\\/
18:24:28 <monerobux> moneromooo meant to say: .time \/ls`
18:24:57 <hyc> I guess once you get atomic swap working, screening could be an extensible addon
18:25:11 <hyc> first default screener would be "coinbase coins only"
18:25:32 <hyc> users could opt to set "any coins, except blacklist at foo.bar.com"
18:25:36 <atoc> yeah - that would be good
18:26:04 <moneromooo> You dont' want to refer to outside resources for consensus.
18:26:10 <atoc> yeah whitelisting and blacklisting servers is useful too (similar to email feature)
18:27:22 <hyc> is this consensus? I think this is a mutual choice between the two swap parties
18:27:44 <hyc> Alice can abort the txn if she doesn't like the BTC Bob is offering
18:27:55 <moneromooo> Depends how it's done I guess. I was imagining Alice puts up a partial tx, which Bob can then fill.
18:28:07 <atoc> well typically you only want to abort if something went wrong
18:28:21 <atoc> i guess this could be included in some exception
18:29:31 <atoc> if it's done how moneromooo suggests then it doesn't need abort
18:29:40 <atoc> rather wait for the correct criteria
18:30:20 <atoc> aborting results in some loss (to account for fees)
18:33:49 <jwinterm> atoc, not exactly, it is based on sopel irc bot, which is based on willy irc bot
18:34:06 <jwinterm> I mostly added price and network and silly commands
18:34:21 <sarang> The bot is in #monero-research-lounge now too
18:34:59 <atoc> jwinterm nice
18:35:07 <atoc> how do we get price?
18:35:26 <sarang> Please do not use this channel for price stuff
18:35:52 <jwinterm> yea, join #monero-markets or #monero-pools for other stuff