00:12:57 As I thought, BS had already given them support (and likely money): https://twitter.com/harryhalpin/status/1304209640675323907?s=21 00:13:02 Nice publicity stunt! 00:15:05 soon™ 00:18:05 Sgp_ clearly cybermiles was more popular than both nano and monero at the height of the crypto boom 00:18:14 How tf did you not know that? They got the most upvotes! 00:18:56 * needmoney90 lays the sarcasm on thick 00:19:19 Support almost always equals money 00:20:00 I don't know enough about Nym but at a high level incentivized Tor with a different token sounds dumb to me 01:03:26 Yeah... their tech so far seems to be an improvement in some areas and could be a good step forward for anonymity networks. 01:03:39 And the token serves some Sybil-resistance purposes 07:39:53 dEBRUYNE: yes, i also know Harry and Nym. they are part of the C3 cluster/telegram group 07:41:58 Another sensational title by CoinTelegraph -> https://twitter.com/Cointelegraph/status/1304255354558177280 07:57:26 No such thing as bad publicity 09:19:52 we should start a community list of unethical journalism sites like cointelegraph 09:20:02 the community does have some pull 09:20:44 cointelegraph also runs HitBTC ads 09:22:47 I don't think anyone is running a "journalism trust index" of any sort 09:23:02 this community has enough respect in the greater crypto ecosystem to possibly pull it off 12:26:05 Sethsimmons: TOR is already working on Sybil resistance through a PoW by our very own Tevador who created RandomX 12:27:00 https://github.com/tevador/equix 12:27:29 https://github.com/tevador/equix/blob/master/devlog.md 12:28:19 Didn't someone appear here recently with an implementation of the atomic swaps h4sh3d is suggesting? 12:29:16 https://www.reddit.com/r/Monero/comments/ilyv9u/atomic_swap_implementation_supporting_monero/ 12:29:17 [REDDIT] Atomic Swap Implementation supporting Monero (self.Monero) | 187 points (99.0%) | 57 comments | Posted by kayabaNerve | Created at 2020-09-03 - 18:14:08 12:31:43 https://blog.torproject.org/stop-the-onion-denial 12:34:44 @cankerwort: Yo 12:36:43 I haven't had time to dig into the recent CCS proposal (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/168) or the implementation kayabanerve has posted about on reddit, but it seems to me there may be some overlap 12:37:16 I'm listed as one of the developers on that proposal. I wrote a very bare bones proof of concept. It needs a lot more work before usage with funds can be discussed. The CCS proposal not only covers removing PoC cryptography (notably the use of a library called secp256k1fun, which will be left in initially to get up and running), yet also re-organization into a more viable structure given the flexibility of the protocol. It aims 12:37:16 to create a codebase that's integratable into existing services, and usable as an app. 12:39:05 Oh I see this has been discussed in the CCS comments also, very good 12:39:19 This is going from "here's technically usable code you should never use with funds" to "here's usable code it's okay to use with funds that you can integrate into a DEX, use right now as an app, or expand". That's why it's so much work. Between proper cryptography, isolation of components, full protocol specification... 12:39:29 I mean, this PoC just uses Rust structs + bincode. That's it. 12:39:38 Sure, it works with itself... and only itself. 12:40:12 Sorry if I'm being a bit argumentative. Yes, there's overlap. Yes, the proposal is worth it. 12:40:56 All sounds good I just connected the dots of things I had bookmarked without digging into the details yet 12:40:58 (or at least, that's my opinion, having worked on the PoC and now contributing to the new project ;) ) 12:41:01 All good, all good 12:43:29 come on, not pushing your PoC into production? you'll never make it in the BTC community ... :P 12:45:31 sethsimmons: TOR is"> Thanks for the links here, I was *just* about to reach out to Tor to suggest RandomX or a variant of it! Great to see tevador getting to work on that, it's a great fit :) 12:46:13 hyc: yes, we are captains of industry! if people lose their coins, that's okay. it's just more publicity for us 12:46:51 idk generally large coin losses are pump catalysts 12:48:56 ^ monero is wasting its time with "researchers" and "proofs". they don't make number go up 12:50:05 finally someone else who empathizes 13:12:48 Re: CCS about atomic swaps: I do think that proposal fits the CCS, but i too am concerned about such big amount of money distributed in so long time. As selsta mentioned, the precedent about long term CCS proposals are all bad. Probably would be better to find a hybrid approach. We look for other communities/projects willing to fund half or a portion of the milestones and the CCS could do the rest. 13:17:23 And i really don't think that "let's fund it in case we redistribute the reward to other projects" should really be an option. Especially given the past experiences with failed projects. We should have learned something at this point :P 13:17:59 breaking in half at least is preferred from my view 13:18:22 makes sense, since this project doesn't only involve monero 13:19:06 also as other people have stated, I only see this as a win for BTC users, or users of other non-fungible coins 13:19:34 an XMR holder only risks acquiring tainted coins 13:19:40 I see no upside 13:23:52 And i really don't think that "let's fund it in case we redistribute the reward to other projects" should really be an option -> i meant to say _should not_ 13:26:05 btw "atomic swaps" definitely became a buzzword that makes people overexcited, but it's true that would make things easier for DEXes 13:27:05 anyway. Even if we agree with half proposal CCS, half proposal other projects. I'm still concerned about the 7 months timeline. 13:27:27 what concerns you specifically erci? 13:29:55 as selsta mentioned, all past experiences with long term proposals went poorly and that's the reason why we usually fund 3 months long proposals. Also, even if i don't doubt their abilities, i don't know these people (and there are 7 people to be funded here). What if one leaves for one or more reasons? Then things will take more time and/or more funds. Shit happens and we should keep that in consideration. 13:30:04 Would be much better to split the proposal 13:30:24 opening one for 3 months of work, when that's done another one can be opened for 3 more monthss. Or something like that 13:30:42 but that's what the milestones are for, right? 13:30:43 Whats the point of milestones if proposals can't be longer than 3m anyways? Aren't milestones the exact way to handle long-running/large proposals? 13:30:56 ^ yeh 13:31:46 That way we have easy and clear ways to only payout if certain goals are met over the life of the proposal. 13:31:52 No. Milestones define how a proposal is divided. But people fund all milestones reguardless. Very different from funding a proposal with n milestones and then funding another one with n milestones as well 13:32:06 Milestones are only paid out as met, correct? 13:32:33 We would fund the entirety, but the funds wouldn't be paid out if the proposal failed/fell short, so they could easily be redirected into GF or other proposals. 13:33:03 Milestones are only paid out as met, correct? 13:33:03 -> yes, but funds would be already allocated for those milestones, which is the problem 13:33:20 If there was large push-back like "I only want to fund these capabilities" it could be broken down more, but if people want all or nothing anyways I don't see the point of breaking it up further instead of just relying on clear milestones. 13:36:23 As a side note, I think it would be worthwhile to seek 'partners', i.e., teams/coins that would benefit from having an open source library and would be willing to donate 13:36:38 so they could easily be redirected into GF or other proposals -> as i said, that's not really optimal. Why would we want that? Why would we take such risk while we can do as we always did? Splitting in more CCS is the way we do, because allow people to see some work done before funding the next proposal. Which allow to verify the quality of the deliverd "product" and allow to have much smaller CCS whch are 13:36:38 easier to fund 13:36:55 ErCiccione[m]: I've talked with KMD. They've offered 2000 EUR for a full XMR PR to their DEX. AFAICT, they have no interest in supporting the wider ecosystem or paying anything that isn't a token amount given the amount of work involved. 13:36:57 it also makes the project more difficult to realize. If you have to stop the project and write another proposal after every month or so that seems very inefficient. 13:37:12 *They offered it to me personally to be clear. 13:37:25 TheCharlatan: why would you need to stop the project? 13:37:47 I don't think a 7 month proposal versus 2 3 month proposals, when the milestones are divided properly, has too much of a difference personally. 13:38:12 Price fluctuations alone make 7 months significantly more risks. 13:38:40 maybe I'm understanding you wrong, but wouldn't that imply that you run out of money every time? 13:39:32 Not sure if the CCS allows for it, but we could set the amount to the first (sub)milestone 13:39:47 Once completed, the 'team' writes a report, and the CCS reopens with an amount for the second (sub)milestone 13:39:51 selsta: yeah there are so many reason to keep doing shorter proposals. I really don't understand how all that happened with kovri and that it's happening with the hardware wallet people still think that such long proposals are a good idea. So much can go wrong in such long time 13:40:35 TheCharlatan: No. The point is simply to receive/ask the mony in differnet (consequential) steps, instead of all at the same time 13:41:06 oh, but the milestones do pay out sequentially 13:41:09 I'm fine with either approach, just sharing that my understanding of milestones was that they helped in these situations. 13:41:29 TheCharlatan: yes. The point is that the proposal would be already discussed, approved and funded 13:41:33 If the authors are fine with having to write multiple proposals, it's not really a bad thing overall. 13:41:39 i think we have 16 milestones for 7 months 13:41:43 Really, milestones don't help at all here 13:42:10 They do imo, as it allows for the proposal to be chopped up in 16 'episodes' 13:42:11 erciccione_[m]: can u explain the purpose of a milestone? 13:42:59 dEBRUYNE: What i meant is that they don't help fix the problem we are trying to solve: one big proposal funded for a lot of money for a long time 13:43:02 Each milestone requiring a report/evidence of work provided before payout is fine with me. 13:43:44 It's not a multi-year proposal, its 7mo, and the milestones allow us to avoid overspending/failure to produce results 13:44:19 ErCiccione[m]: You can if you lock the amount of funding that is possible 13:44:26 Once completed, the 'team' writes a report, and the CCS reopens with an amount for the second (sub)milestone 13:45:00 What happens if/when price fluctuates over that time? 13:45:10 Once completed, the 'team' writes a report, and the CCS reopens with an amount for the second (sub)milestone <- That's what i'm proposing. you are calling it a sub-proposal instead of a brand new proposal :) 13:45:36 sarang: exactly. As selsta mentioned before, there is also this problem to consider 13:45:56 i really don't see a single valid reason to make one huge CCS instead of multiple smaller ones 13:46:00 There is precedent for requesting a payout at the beginning of the project (I have done this) 13:46:13 But that does imply risk to donors 13:46:13 (multiple would mena 2 in this case) 13:47:33 One donor advantage to shorter proposal time periods is that it provides donors with a method to signal the value they see from ongoing work 13:47:59 If donors do not approve of current work, they can choose not to fund future work; or if they do approve and see value, they can choose to fund future work 13:48:15 Yes, it's annoying to have to write new proposals every few months, but that's how it is usually done now 13:48:46 To wrap it up, i'm proposing to: 1. look for other projects interested in funding half or part of the proposal 2. split the CCS in 2 proposals of 3/4 months each. 13:48:50 sarang: exactly 13:48:51 The downside I see to the milestone method is that the signalling method for whether or not a milestone is met is binary, and not up to individual donors 13:49:10 That being said, it does have advantages, as has been mentioned before 13:49:39 And of course donors can still choose whether or not they wish to support a longer-term project 13:49:54 so that is a definite signal to their assessment of its value and their trust in the team 13:50:11 but only in advance 13:51:08 It seems like the price question is probably the biggest uncertainty in that case 13:51:26 How would the team handle such fluctuation? 13:52:14 we thought we would set the exchange rate on the outset, and the payments later would be in XMR 13:53:27 OK, so the team would take on the risk associated with exchange rate fluctuations over the 7 months? 13:53:39 yes 13:53:42 it seems to be a consistent theme that people want other projects who would benefit to contribute also 13:53:42 Got it 13:53:48 Thanks zkao 13:53:52 I'll start poking at some of my contacts in places. 13:54:36 Shorter proposals would result in less time for fluctuations to occur, meaning more stable funding in theory 13:54:42 and provide this ongoing donor signaling 13:54:53 Is this not viewed as a compensating advantage? 13:55:14 I don't see why there would be a need to stop the project to do a new proposal 13:55:28 You open it advance; this is what I do now 13:55:31 *it in advance 13:56:09 Note that this isn't any kind of statement on the trustworthiness of the team or anything, merely a question of price and donor signaling 13:56:35 I have no particular reason to think the team wouldn't be able to deliver their results as stated 13:57:43 ^ same for me. As i said, i see only upsides in splitting the proposal in two 14:00:14 The downside to the team would be that there is no guarantee of a second proposal being funded 14:00:25 but this is also part of the donor signaling 14:00:32 (and could reflect price, economic conditions, etc.) 14:00:50 So it's a tradeoff between price stability and guaranteed funding, to some extent 14:01:57 ErCiccione[m]: Ah I see, thanks for clarifying 14:04:07 On another note -- would this help to minimize the work needed here, if we can leverage existing work by other projects it could help vastly reduce the work needed/cost here: https://github.com/decred/dcrdex 14:04:32 I have no idea if that is viable (or wanted), but they're working on a similar type of FOSS DEX that is run by users, so could be helpful to collaborate/re-use what we can. 14:04:57 sarang: yeah. if the second part doesn't get funded that means the system is working as it supposed to. Personally i don't think that will be a problem, seeing the excitement around atomic swaps 14:05:09 (Note that I do not have a clear technical understanding of the differences here, but want to be sure we avoid duplicating effort if possible) 14:06:15 It's interesting to consider what the good PR for proposals might do to encourage other groups to help fund 14:08:10 The initial feedback I'm hearing from the DCRDEX people is that there is a lot of duplicated efforts in the new proposal, and that they'd likely help fund a smaller request for the back-end pieces needed to integrate DCRDEX (which they say is much smaller/simpler) 14:08:35 I don't know that we want to rely solely on DCRDEX, but could be good to use that for an MVP and only push for an alternative client down the road as-needed. 14:08:54 zkao: how do you personally view the tradeoff between price stability and guaranteed funding (albeit at an unknown fiat level)? 14:09:03 I'm certainly not asking you to speak for your collaborators! 14:26:10 sarang: i know the majority of collaborators involved would be ok in being paid in monero, so not concerned about price depreciation, skin in the game is important. 14:26:27 what im concerned about is orchestrating minimizing consulting work with unguaranteed funding, because then we have to make sure to keep doors wide open 14:26:51 Well sure, all CCS are paid in Monero (you can't get paid in fiat!) 14:27:06 i mean, internally 14:27:24 But ok, so the general view is to prioritize guaranteed XMR funding, rather than fluctuations 14:27:26 ? 14:27:52 yes, you're write, and we dont want to write specs only! haha 14:27:59 ? 14:28:15 Oh, for a first proposal 14:28:15 got it 14:28:33 Can you talk in more detail about community/researcher interaction? 14:28:40 There was brief mention of participating in channels 14:28:56 But I would personally like to see regular guaranteed participation in research channels, meetings, etc. 14:29:13 Nobody is obligated to do this unless specified in the proposal, of course 14:29:30 but I think that regular detailed updates and interactions with R&D folks is essential 14:31:07 my concern with these atomic swap proposals is whether they'll be compatible with future stuff like triptych 14:31:47 zkao: regular interactive updates could also reduce the risk of finishing a milestone and then discovering some error or problem after it's presented to the communities 14:31:49 i mean, beyond the concern of one way fungibility 14:32:14 gingeropolous: Why would they not be? 14:32:20 They're standard XMR TXs 14:32:20 gingeropolous: Triptych/Arcturus are compatible with multisignatures, but notably in a _much_ more complex way 14:32:31 As long as Monero uses Ed25519, this will work, no matter the RingCT algo 14:32:34 IIRC the proposal does assume multisig 14:32:37 This isn't even a multisig 14:32:45 Hmm, then I'm misremembering :) 14:32:47 excellent 14:32:53 Not for Monero. It's two keys which add together to a full key. 14:33:04 You recover the other one using adaptor signatures 14:33:08 Ah yes 14:33:14 The key-sum construction 14:33:25 *So yes, there are multiple keys combined, but there's not multiple signatures or any special signing algo 14:33:33 Except for adaptor sigs which is completely on BTC 14:33:45 FWIW Triptych has the same overall RingCT construction, but replaces the 2-LRS portion 14:33:51 sarang second your call for guaranteed particiapation in -research-lab and -dev. With you and surae stepping down for some time, a project like this could also help carry forward the momentum you have generated. 14:33:53 Arcturus is a bit different, but not wildly so 14:34:00 TheCharlatan: awesome 14:34:17 I think this is good for accountability, but also to avoid situations where there are mistakes that would otherwise delay your progress 14:34:20 Does it use a 32-byte elliptic key algorithm and a spend/view key? :P 14:34:24 lol yes 14:34:27 I mean, even that latter part isn't a firm requirement 14:34:33 It could use 4 keys 14:34:36 ok. i'll try to remember this time that atomic swap and multisig are still fine with super awesome ringsize a bajillion techniques 14:34:38 We have options here 14:34:40 Triptych is literally a drop-in 2-LRS replacement, albeit with very different key image structure 14:34:43 _very_ different 14:34:57 Yeah. Just making the point about how this isn't dependent on any Monero cryptography 14:35:08 I mean, sure, it generates a view key. It's immediately transmitted in full. 14:35:20 The only reason it uses a key-sum is entropy I guess? 14:35:46 I debated optimizing it to a one-sided calc. If one party wants to leak it, they can leak it from the start. Being able to decide at the start really doesn't change it. 14:36:07 I had some concerns about using a key sum without a commitment phase 14:36:10 But it's a simple calc increasing entropy which may have had other ramifications I didn't realize at the time 14:36:16 There is the DL EQ proof 14:36:19 It wasn't immediately clear what the consequences of rogue keys might be 14:36:30 And verified public keys 14:36:30 maybe move this to -research-lab? ^ 14:36:38 Whoops, yes :) 14:36:49 thanks TheCharlatan =p 14:38:49 moved to -lab 14:38:55 sarang: so far we did not have the privilege to work on monero for an income, if we're funded we might free a lot of time and for sure will spend more time with this community -- that is part of the whole point, its a community we recognize ourselves with 14:39:23 I think any interactions key to the project (like research meetings) should be spelled out in the proposal 14:39:39 agree ^ 14:39:42 I realize that I'm saying this as someone who doesn't do this in my own proposals, but hopefully my history of doing weekly meetings makes this ok =p 14:40:23 I noticed that -community interaction was listed, but I would view -lab and -dev interactions as most useful to the technical success of the project 14:40:28 Sarang is stepping down for some time? 14:40:38 I will not be submitting a new CCS after this month 14:41:02 :'( 14:41:12 I've been feeling a lot of burnout for quite some time 14:41:26 And I think it's best for general well-being 14:41:33 Fair enough, it does seem quite intense 14:41:48 There is certainly a lot of stress involved :) 14:42:00 Anyway, that is unrelated to this project! 14:42:21 Stepping back to avoid burnout seems wise and helpful 14:42:42 and it can allow other researchers (like this team) to step up more prominently, which is great for the project 14:44:01 h4sh3d was concerned about u not being present to help us 14:44:15 Side note to zkao and TheCharlatan etc.: thanks for having such a detailed proposal 14:44:21 much appreciated 14:44:25 you helped us a lot 14:44:34 zkao: related to what exactly? 14:44:40 the DLEQ construction? 14:44:54 Hopefully it's been specified sufficiently enough in code and the writeup 14:45:08 yep, it was the last real piece missing 14:45:15 There are a few implementation things I'd recommend (including public params like curves and generators in the hash transcripts, etc.) 14:45:44 I'd be happy to answer the occasional question about it 14:46:27 zkao: have you seen the sample proof-of-concept code I wrote for DLEQ? 14:46:39 sure 14:46:51 https://github.com/SarangNoether/skunkworks/tree/discrete 14:46:54 ah ok 14:47:08 (usual disclaimer, for research only, don't deploy) 14:47:51 Hopefully your down time will allow a chance for peer review of Triptych/Arcturus if it is disseminated widely 14:48:12 Yeah, I'm quite confident about Triptych 14:48:21 I'd like more eyes on the nonstandard hardness assumption underlying Arcturus 14:48:46 I was disappointed that the review of Arcturus produced an incorrect counterexample :( 14:49:21 Is there a mechanism for reviewing reviews so that people see that caveat? 14:49:31 * xmrmatterbridge has no idea how all this works 14:49:52 To be clear, the reviewer presented a claimed break on the Arcturus assumption, but it didn't work (meaning the assumption wasn't broken) 14:50:02 Reviews aren't generally made public 14:50:19 They are private between the anonymous reviewers and the authors 14:50:42 That being said, it's absolutely no guarantee that the Arcturus assumption is safe 15:12:17 Oxygen Orion has won handily 17:14:34 sgp_: Should we announce the result? 17:20:09 dEBRUYNE: my impression is that it's okay to do in the main blog post, but fine for a Reddit post or Tweet I guess? 17:20:33 https://i.imgur.com/C3CA4o3.jpg 17:20:36 thanks infinitejest- 17:20:39 this is delicious 17:23:51 now with more bottle: https://i.imgur.com/Ei2MdUi.jpg 17:24:34 w0w 17:31:30 Alla tua salute fluffypony 17:31:35 yo quiero 17:31:56 sgp_: now you start singing Despacito, right? 17:32:32 I wish 17:32:54 Please no lol 17:33:06 Haha yeah probably for the best 17:33:23 Monthy Monero Karaoke 17:33:26 It's about the song, not you :p 17:35:18 It would be about me if you heard me sing 17:36:13 Hah 17:36:48 sgp_ any word from CipherTrace? 17:36:50 L'acqua fa male, il vino fa cantare. 17:36:51 Nope 17:37:05 Wise italian sayings for you all 17:38:03 Water hurts? Lol 17:39:25 It does, it makes things rust. Wine doesn't. 17:51:50 Any takers? https://www.reddit.com/r/Monero/comments/iqgjih/looking_to_interview_a_monero_dev_on_ciphertrace/ 17:51:51 [REDDIT] Looking to interview a Monero dev on Ciphertrace and IRS bounty (self.Monero) | 15 points (94.0%) | 4 comments | Posted by digitalcashsock | Created at 2020-09-11 - 01:03:27 17:53:58 xmrhaelan: sure, fine lol 17:55:07 The guy seems lazy, but I figure the more content out there the better 17:57:59 oh wait 17:58:01 this is Joel 17:58:02 lmao 17:58:21 hard pass 18:03:37 sgp_: who is he? The self promoting way he wrote that post already irritated me. 18:04:09 Dash Force 18:04:41 lol 18:14:11 sgp_: Joel as in thedesertlynx? 18:14:18 yes 18:14:40 I have no interest in an interview with him 18:16:52 No idea who they are, but "dash force" says enough i guess. 18:17:25 dash masternode funded “news” 18:18:05 One of our arch nemesis from back in the day haha 18:18:10 they were maybe most active from 2015-2017 I think? It's been a while since I've come across them 18:18:58 we probably don't need to get into all the grievances now lol 18:18:58 Think their activity hasn't declined that much, it's more that dash has been kind of out of the spotlight for some time 18:19:38 dash evo update soon^tm 18:20:02 wait is that not out yet? they were saying ~1 yr out in 2016 18:20:09 not sure 18:20:22 but since I‘m into crypto I have been reading that dash evo update will be out soon 18:21:17 they released it on testnet 18:22:39 nah, evonet is "pre-testnet" :p 18:23:14 my life is so much better not following this drama anymore 18:23:14 almost 18:28:34 Uh typo in the naming announcement tweet whoever handles those :P 18:28:44 “Oyxgen Orion” 18:29:14 dEBRUYNE or sgp_? 18:29:52 hmm I'll look into 18:29:55 "Oyxgen" 18:30:21 This is just the text in the tweet by the “official” Monero Twitter 18:38:31 fluffypony: Few of those glasses and I'd reckon you'd be quite tipsy lol 18:38:37 lol 18:50:56 That means the wine is working. 18:52:13 Damn i'm bored. It's raining outside, my van has a leak somewhere and it's dropping, i have no electricity and my nero d'avola is almost finished. Sad day. 18:56:42 Ok. It's spaghetti time. 19:08:54 no electricity? almost as bad as no internet 19:19:59 Yeah. I miscalculated the weather and my batteries are empty and there is no sun for the solar panels. So no electricity. I have internet tho 19:26:12 Maybe an explanation is needed: the batteries of my van are charged by solar panels. I miscalculated the weather (super rainy) of these days, so now i haven't enough electricity to charge my laptop this evening. I have internet using and old phone as hot spot. Tomorrow will be ok. 19:27:37 And that's all from "another day of erciccione's life". Stay tuned for the next episode: is the fridge about to break? 19:31:24 sending thoughts and prayers to your fridge 19:36:14 Thanks. That's always the most effective cure, after smashing that like button and sharing to your friends 20:24:17 sgp good to know. 20:34:52 Orion the most familiar and boring choice :D 21:01:57 yeah I kinda thought it was boring too 21:02:16 and still doesn't flow off the tongue as well 21:33:52 I actually liked Ocelot since there could be a cute Ocelot image to go with it 21:35:51 204 people from Blockfolio clicked on the link to vote, not bad 21:38:15 wait what month is it? 21:39:02 Sept 21:39:07 :) 21:39:21 This is the most clocked on Blockfolio push notification https://blockfolio.com/coin/XMR/signal/xr2qhrq7Ej 21:39:26 s/clocked/clicked 21:39:26 sgp_ meant to say: This is the most clicked on Blockfolio push notification https://blockfolio.com/coin/XMR/signal/xr2qhrq7Ej 21:52:52 Or just buy votes of phone/clicker farms via DNM. Don't know what the prices were circa late 2018, but likely relatively cheap then as well 21:55:41 Would certainly be an interesting project to create, perhaps maybe it would improve journalism in the CC space, but I could be overly optimistic 22:01:50 There was huge scandal/infighting episode I want to say 2018, maybe early 2019 between Dash Force and some other entity I'm spacing on 22:07:39 (Which may account for the quietness) 22:17:05 I just removed his post, he's been told where to go. 22:17:26 Also he's evading a shadowban, which is against reddit rules 22:17:37 👀 22:17:59 I think its hilarious he got shadowbanned 22:19:19 Though I'm confused since I can see his account 22:28:48 Wrt atomic swaps, is there any risk in waiting to see if people implement them independently first? I heard Nano got a bridge with BTC working (headline, possibly not reality) using this method, so it's not like these are the only people with the ability 22:29:43 The idea hasn't been floating around very long, and I'm hesitant to push for paying for an implementation if it might just end up existing on its own in a reasonable amount of time 23:46:35 If other projects donated to get hooked up that would be cool 23:51:40 yes, kayabaNerve and PlasmaPower built the nano/xmr to btc swaps: https://github.com/MerosCrypto/asmr