00:54:23 <Isthmus> Suppose a node hears a transaction with transaction identifier `T`, but the transaction fails verification
00:54:24 <Isthmus> Will it then ignore any subsequent txns with tx_ID `T`
00:54:24 <Isthmus> Is there any situation where the node would re-check a transaction with the same TX_ID as one that failed previousy?
00:56:56 <moneromooo> Depends why it fails verification.
00:57:26 <moneromooo> If it's inherent failure, it won't check it again. Things like key image not in domain are inherent.
00:57:53 <moneromooo> If it fails because MLSAG verification fails, I think it might check it again later.
00:58:03 <moneromooo> (since they might become valid with a reorg)
01:00:56 <Isthmus> Ohhh interesting.
01:00:56 <Isthmus> If I took a junk bitstring and pushed it to a node as a "transactinon" it wouldn't blacklist that tx_ID or anything, right?
01:01:19 <moneromooo> I'd have to look to know.
01:01:48 <moneromooo> I looked, it would try it again.
01:01:59 <moneromooo> But then there is no txid for a junk bitstring.
01:02:23 <moneromooo> It could hash the bitstring and remember, but that's not much faster than trying too parse it.
01:02:38 <Isthmus> Cool, makes sense
01:06:05 <Isthmus> https://usercontent.irccloud-cdn.com/file/ONuUcile/image.png
01:06:10 <Isthmus> Okay, then I'm not quite sure if this section is quite correct ^
01:06:10 <Isthmus> And yea, I'm handwaving over Tx_ID having H(prefix) , H(txn stuff), H(sigs)
01:07:28 <Isthmus> s/correct/correct, given the default behavior of the core node implementation ^
01:07:29 <monerobux> Isthmus meant to say: Okay, then I'm not quite sure if this section is quite correct, given the default behavior of the core node implementation ^ ^
01:09:50 <Isthmus> or if we define `d=H(H(prefix),H(tx stuff),H(sigs))` then maybe it's not handwavey
01:11:03 <moneromooo> Fluffy blocks are irrelevant here AFAICT.
01:12:28 <Isthmus> Ah yea, you're correct.
01:13:10 <Isthmus> The fuffy blocks piece is irrelevant
01:18:09 <Isthmus> Otherwise, if a node hears a block that includes `T` and receives corresponding junk `d'`, will it mark the block as invalid?
01:18:13 <Isthmus> Is there a chance for redemption if a different node relays the right valid `d`
01:19:55 <Isthmus> Or is it game over once the block is marked as invlid?
01:19:56 <moneromooo> It will mark the block as invalid IIRC.
01:20:07 * moneromooo afk
01:21:05 <Isthmus> Cool, that answers what I was wondering about.
01:21:05 <Isthmus> Thanks for the help, mooo 3:)
01:29:33 <Isthmus> Update:
01:29:35 <Isthmus> https://usercontent.irccloud-cdn.com/file/34M4AdXx/image.png
01:50:59 <Isthmus> I've moved edits made today over to the overleaf doc shared during MRL meeting earlier.
01:50:59 <Isthmus> (So if you downloaded a PDF earlier, get a fresh copy)
01:50:59 <Isthmus> Same link: https://www.overleaf.com/project/5f4fc9e599cecd00017c5fe5
01:53:46 <sarang> Is the PDF link in the meeting agenda also updated?
02:25:23 <sarang> Monthly research report: https://www.reddit.com/r/Monero/comments/ilkwx9/august_monthly_report_from_sarang_noether/
02:25:24 <monerobux> [REDDIT] August monthly report from Sarang Noether (self.Monero) | 1 points (100.0%) | 1 comments | Posted by SarangNoether | Created at 2020-09-03 - 02:22:57
02:25:28 <sarang> good bot
06:55:30 <Inge-> Isthmus: so for naive QA mitigation it would be possible to send funds to a new wallet that has never been used before, and then destroy all sender-wallet metadata. As long as nobody except you know the receiving address and it has never been used before - then it sounds like you are somewhat safe (and in theory you could send payment to someone, as long as your "change" is just a payment to
06:55:36 <Inge-> another new address - with the added complexity that the address you paid to is prone to compromise if the address itself is picked up by your QA?)
07:21:22 <kayabaNerve> dEBRUYNE: https://github.com/MerosCrypto/asmr/pull/2 :)
07:21:38 <kayabaNerve> I'll make a Reddit post once it's merged. I asked my co-author to review the PR first.
07:21:48 <kayabaNerve> Also something about it being 2am locally
08:43:06 <dEBRUYNE> kayabaNerve: Awesome, thanks!
12:55:19 <sarang> Hello all; finally a chance to return to Bulletproofs+ coding today!
13:25:48 <knaccc> experiments updated: https://gist.github.com/knaccc/78c691aa1c1e0710bb8264ef17b56768
13:26:05 <knaccc> Conclusion: Churn incoming inputs at least 3 times, and do not merge churned outputs within 24 hours of receipt
14:08:42 <sethsimmons> Wow, so 3x churn per "risky" input
14:08:58 <sethsimmons> Cool to see some stats behind it, but that is a lot of bloat if done for all transactions
14:09:14 <knaccc> monero txs are bloat compared to bitcoin txs
14:09:32 <sech1> what about merging all incoming inputs together and THEN churning them N times?
14:09:33 <knaccc> the question is, how much bloat are we willing to pay
14:09:46 <sethsimmons> Eh, only around 4x the size so far, and about to be ~3x after CLSAG
14:09:58 <sethsimmons> But point taken
14:10:26 <sethsimmons> Triple churning every transaction on the network would be extremely costly, even if it has strong benefits against particular attack vectors
14:12:20 * selsta interested how it would change with ring size 64 or so
14:12:53 <sethsimmons> IIRC small (non-exponential) changes in ring size are not going to help much here
14:12:57 <sethsimmons> But raw numbers on that would be interesting
14:13:37 <sethsimmons> If this attack vector is strong enough to need quick implementation of auto-churn, etc, even just dropping the required churn count by 1x would be a major win for slightly larger overall transactions
14:14:30 <knaccc> sech1 great question. if you are not trying to hide that the 3 outputs are all destined for the same wallet, then you can merge immediately and churn. at this point, the question that is effectively being asked is what the anonymity set size of a single output spend is.  i took a random tx from the blockchain, and the anonymity set sizes are here: https://paste.debian.net/plain/1162446
14:15:52 <knaccc> i meant to say "2 outputs"
14:16:16 <lithiumpt> someone was suggesting the wallets to have a feature where subaddresses could be flagged as "risky", where auto single_sweep's would be performed on those
14:17:51 <lithiumpt> (or i completely misunderstood it)
14:17:53 <knaccc> it all depends on what you're defending against
14:18:06 <sethsimmons> <lithiumpt "someone was suggesting the walle"> That was my idea overall
14:18:17 <knaccc> if you don't want people to know they're both dealing with the same person, you need to churn independently
14:18:25 <sethsimmons> Since we don't necessarily need to churn all incoming transactions, only those from entities that know your IRL identity
14:18:32 <knaccc> if that doesn't matter, you can merge immediately and churn only prior to cashing out
14:19:24 <sethsimmons> <lithiumpt "someone was suggesting the walle"> Ideally when creating a new subaddress you would be prompted to answer a simple question like "Will this address be in any way connected to your identity?" and if you answer yes, all incoming transactions will be churned over time independently before being spendable
14:19:43 <sethsimmons> And then obviously you could manually "flag" other subaddresses/accounts for autochurn if you wanted
14:20:51 <sarang> That's an interesting idea
14:20:57 <knaccc> of course, the iterated-EABE problem is most severe when someone gets an output prior to doing their first cash-out
14:20:59 <sarang> Specifically get the user thinking about use cases and threat models
14:21:09 <knaccc> and then gets another output the next week prior to their next cashout
14:21:14 <sethsimmons> Yeah :)
14:21:19 <knaccc> so their need to cash out early means they can't merge and then churn
14:21:45 <sethsimmons> <sarang "Specifically get the user thinki"> More clear messaging/forced prompts across the GUI would be good in many areas I think
14:22:07 <sethsimmons> And this is a clear win against a well-known heuristic (and churning seems to be a good solution with the research so far!)
14:23:42 <lithiumpt> could the unlock time be dynamic? ie. some subadresses having a longer lock time?
14:24:15 <sethsimmons> The churn profile could vary (and needs to vary FWIW) in timing
14:24:33 <sethsimmons> So they would likely have different "lock" times, although that term is a bit confusing as you *can* spend the inputs
14:24:51 <sethsimmons> You just shouldn't merge them without first churning
14:25:12 <sethsimmons> The only reason I'd like to "lock" them (with a hidden/advanced override) is to keep users from shooting themselves in the foot
14:31:40 <sarang> knaccc: code used to generate that data?
14:32:23 <knaccc> i need to clean it up and remove dependencies so people can actually run it without all of the mess attached, i'll do so and release it
14:40:34 <sarang> Great, would love to review and reproduce the results
14:42:04 <sarang> I have similar code in progress, and it would be neat to tweak it so the methods are the same, and show the overall results are reasonable
14:43:12 <moneromooo> Different methods would actually give more confidence in the results if they roughly match.
14:46:32 <sarang> I don't mean the specific method of implementation... I meant what analysis method (e.g. pick two outputs from this time range, look at this time window...)
14:46:39 <sarang> Sorry, that was confusing wording
15:02:05 <Inge-> https://cryptobriefing.com/ciphertraces-monero-tracking-tool-isnt-effective-researcher-says/
15:05:13 <sarang> That is not an accurate assessment of my quote to that reporter
15:05:30 <Inge-> Color me unsurprised.
15:05:43 <sarang> I'll email the reporter and mention this
15:09:12 <sarang> done
15:10:46 <sarang> Yet another lesson I apparently never learn: don't bother talking to reporters
15:12:12 <moneromooo> The article seems ok, the title not. Typically, the person writing the article does not get to write the title, they have separate assholes for that.
15:12:34 <sarang> https://www.irccloud.com/pastebin/sEOXJp0Y
15:12:36 <moneromooo> The reporter does the work, and the asshole trolls the readers.
15:12:44 <sarang> ^ my email to the reporter
15:13:01 <moneromooo> Though for cryptocurrency sites, maybe it's just the same, it's small outfits...
15:13:40 <sarang> At any rate, definitely won't be providing any future statements to them
15:16:04 <Inge-> "Reporter" - I don't think it means what you think it means. sigh.
15:17:22 <sethsimmons> Thanks for putting in the effort to ask for a revision
15:17:55 <sarang> The correction is never as impactful as the original
15:19:16 <sarang> I'm willing to allow a bit of leeway, but that headline is downright misleading
15:19:29 <sarang> The statement I gave was extremely careful and thorough
15:20:49 <sethsimmons> They dont even appear to have a Twitter account, interesting
15:21:07 <Inge-> I guess this headline fits with the accuracy of the "DHS can now trace monero" headline
15:22:25 <sarang> "They haven't demonstrated the effectiveness" is clearly not the same as "it isn't effective" in your minds, right?
15:22:50 <sarang> I mean heck, Dave Jevans didn't demonstrate that he can make a grilled cheese sandwich, but that doesn't mean anyone is claiming he can't make the sandwich...
15:23:04 <Inge-> it is clear to us.
15:23:13 * sarang wants a grilled cheese sandwich now
15:24:03 <moneromooo> I wonder why there was no "Monero ring size is now 65536" when sarang started investigating lelantus... Alkways in one direction is it ? :D
15:24:47 <sarang> -___-
15:25:11 <moneromooo> "Sarang Noether does not deny being a Venusian"
15:25:33 <sarang> <_<
15:25:33 <sarang> >_>
15:25:43 <moneromooo> "Monero may be alien technology"
15:25:46 <sarang> Here's hoping they change the damn headline
15:26:00 <sarang> Never a dull moment...
15:26:12 <sarang> Thanks for pointing this out Inge-
15:29:36 <Inge-> I thought it would find an interested audience here :)
15:29:40 <sarang> sigh
15:29:47 <sarang> "Interested" is one word
15:30:06 <Inge-> and it didn't look like anyone had pasted it in any of the channels yet.
15:30:24 <sarang> Is that a popular site?
15:31:30 <Inge-> It popped up in tradingview's news bar
15:32:05 <sarang> interesting
15:32:26 <sarang> Well, at least the quote from my statement was correct and seems in context
15:32:26 <sethsimmons> Ive never heard of them and they have no presence on Twitter
15:32:29 <sethsimmons> So not that big I guess
15:33:10 <sarang> Even the snarky part about me not caring about press releases :D
15:47:09 <Isthmus> A few years ago I wrote an article about some bacteria that could change the oxidation state of heavy metals to cause them to precipitate in water. When I picked up a copy of the paper the following week the headline was “new bacteria eat pollution” or something like that
15:47:25 <Isthmus> I had a serious talk with the editors and they didn’t mess with my headlines after that...
15:47:35 <sarang> Yeah, that's some trash reporting
15:47:53 <sarang> and it's why I never make _any_ conclusions about any technical or scientific topic from general media
15:48:25 <sarang> always best to consult an actual expert, or at the very least read the source material yourself if you have the literacy
15:49:39 <sarang> There was a great xkcd on this "cycle" from research to media...
15:49:42 <sarang> can't find it now :(
15:49:49 <sarang> Also: will move this to -lounge, sorry :/
15:58:36 <sech1> sarang https://hsto.org/getpro/habr/post_images/e57/0df/187/e570df1871c286df69cc5eeebf4cac0b.jpg
16:00:12 <sarang> Heh, not the one I was thinking of... but still excellent
16:00:49 <sarang> Oh snap... it was PhD Comics! http://phdcomics.com/comics/archive_print.php?comicid=1174
16:06:11 <Isthmus> Haha yeppppp. To be fair these editors thought they were being helpful by spicing up the title, and were thankfully very receptive when I pointed out the issues with sensationalist headlines for science articles.
16:06:24 <Isthmus> Also, interesting ideas around account management
16:06:57 <sarang> If media would promise never to use the phrase "a study" ever again, I'd be sooooo happy
16:07:32 <moneromooo> You mean as opposed to "study X by authors Y" ?
16:08:47 <sarang> No, because "a study" could mean "a press release about something" or "a preprint" or "a clinical trial in progress" or "a peer-reviewed journal article" or "something in workshop proceedings" or "something claimed by some academic on twitter"
16:08:51 <sarang> and those all mean different things
16:09:13 <sarang> Readers shouldn't be expected to fully grok the implications of those differences
16:11:51 <Inge-> sethsimmons: I like your idea of tagging subaddresses as "requiring of higher privacy" and it could be auto churn, or it could remind you when you launch your wallet, that you should do another 2 churns, would you like to do one/them now?
16:12:11 <sarang> (this "study" talk has moved to -lounge so I can stop spamming this channel)
16:15:25 <sethsimmons> <Inge- "sethsimmons: I like your idea of"> Yeah something like that would be nice, but honestly I don't want the user to have to even think about it after the creation of the subaddress/flagging.
16:15:45 <sethsimmons> Or perhaps a status/progress bar for churns on the left side with the sync info to notify you when things are happening etc.
16:16:43 <moneromooo> Reticulating splines...
17:04:10 <gingeropolous> preparsing intercalators
17:42:09 <knaccc> sarang https://github.com/knaccc/anonymityExplorer
17:43:48 <knaccc> if you want to run it, you need a local node running so it can get blocks via RPC. takes 1-2hrs to load everything into a file, which it stores in ~/.anonymityExplorer
17:44:28 <knaccc> start by running TestOutputCorrelation which will trigger the block retrieval and then perform a test to see if it's correlating outputs properly
17:44:58 <knaccc> it's important to not interrupt it while it's retrieving new blocks from the daemon, because it'll leave the database file in an inconsistent state
17:46:18 <knaccc> it currently needs 470MB of storage available
17:46:22 <sarang> That's fine... I plan not to run it just yet anyway
17:46:24 <knaccc> actually 1GB
17:46:31 <sarang> but to use it to check the method against my own separate code
17:46:34 <knaccc> and it shrinks the file after it updates
17:46:48 <knaccc> i've tried to make it readable
17:47:25 <knaccc> the experiments in the gist correlate to 'tasks' in the code
17:47:34 <knaccc> e.g. MergeAnonymitySetSize is probably what you'd be interested in looking at
17:49:03 <knaccc> https://github.com/knaccc/anonymityExplorer/blob/master/src/knaccc/monero/anonymityExplorer/tasks/MergeAnonymitySetSize.java
18:14:51 <sarang> That article with the inaccurate headline has been updated: https://cryptobriefing.com/ciphertraces-monero-tracking-tool-isnt-effective-researcher-says/
18:14:59 <sarang> My thanks to the author for making this change
18:15:39 <sarang> I think the new headline is an accurate representation of the statement I provided to the author
18:16:53 <sethsimmons> much better
18:17:44 <sarang> The author asked if I wanted the article to include a note about this change, and I said it was up to him
18:17:54 <sarang> but that I don't specifically request a note be made about it
18:26:06 <kayabaNerve> Finally merged Monero support into https://github.com/MerosCrypto/asmr. Atomic swaps are here :D
18:29:50 <sarang> :D
18:31:01 <kayabaNerve> sarang: My partner did use your DL EQ proof btw ;)
18:31:28 <kayabaNerve> Or at least, the underlying algorithm. I'm trying to remember the name of the guy credited in your paper on the topic...
18:31:58 <sarang> Neat! (Usual disclaimer that the discrete log proof has not been formally shown to be secure, nor externally vetted that I know of)
18:32:12 <sarang> AFAIK andytoshi came up with it
18:32:16 <kayabaNerve> Nor has this protocol or this library
18:32:25 <kayabaNerve> It has such a rich family history. Really preserving the lineage :P
18:33:02 <kayabaNerve> But yeah, this is explicitly marked as a PoC. Monero uses the network byte because I did all testing with regtest, but BTC is locked to testnet.
18:33:16 <kayabaNerve> And then the other supported coins don't have different bytes for different networks.
19:50:39 <suraeNoether> moneromooo: in reference to your question yesterday about doubling key length. The good news is (I think) that doubling key length octuples the quantum computing time.   breaking a 512 bit key (double our key length) is concretely as hard for the quantum computer as breaking RSA 2048, at least according to the following paper (shuffles through pile)
19:51:02 <suraeNoether> http://cds.cern.ch/record/602816/files/0301141.pdf
19:51:08 <suraeNoether> Pdf link
19:51:36 <moneromooo> That seems... bad news.
19:52:05 <suraeNoether> "Shor’s discrete logarithm quantum algorithm for
19:52:05 <suraeNoether> elliptic curves"
19:52:05 <suraeNoether> John Proos and Christof Zalka
19:52:26 <suraeNoether> Eh it's better than doubling key length only doubling computing time :P
19:52:59 <sech1> O(N^3) is not as good as O(2^N), you know
19:53:23 <moneromooo> I guess :D
19:53:27 <suraeNoether> Well that's the problem with shor's
20:01:30 <Inge-> Ec
20:02:31 <Inge-> Ecc releasing halo2 source code, considering implementation and getting rid of trusted setup in 2021 https://electriccoin.co/blog/ecc-releases-code-for-halo-2/
20:03:07 <sarang> It's important to note that all the application code for Halo that I've seen has been _only_ for proof of work, not transactions
20:03:31 <sarang> AFAIK there are no details released on if/how Halo 2 could improve Zcash transaction scaling or efficiency
20:03:59 <sarang> See this thread for discussion: https://forum.zcashcommunity.com/t/announcing-halo-2/37215
20:04:08 <sarang> I would treat that press release as... a press release
20:04:14 <sarang> and we all know how that goes :D
20:04:30 <Inge-> Ugh
20:05:14 <Inge-> Wait, so what you're saying is - "Researcher is not impressed" :D
20:05:21 <sarang> A few knowledgeable people in that thread claim that details on transaction applications are forthcoming, but that has yet to be established
20:05:49 <sarang> It's almost like the best way to convince people about new mathematics is to publish the details
20:05:52 <sarang> who knew
20:06:11 <sarang> Anyway, I echo the comments by secparam (Ian Miers) in that thread
20:06:26 <sarang> (Ian is one of the authors of Zerocoin/Zerocash)
20:07:09 <sarang> Don't get me wrong, the ideas in Halo and Halo 2 are quite interesting
20:07:28 <sarang> but that is not what the press release is saying
20:07:52 <sarang> Until there are details, this is another "company says thing" situation
20:08:09 <sarang> I hope the claims about transaction efficiency are true, because that'd be pretty sweet
20:09:28 <Inge-> Yeah claims like this: ""Halo is a significant breakthrough in making recursive SNARKs practical: We now have smaller fields, faster provers and no trusted setups,” said Brendan Farmer, CEO of Predicate Labs,"
20:10:03 <sarang> That's a fairly vague statement
20:10:18 <sarang> The technique is certainly fascinating for idea of recursion in proofs
20:10:34 <sarang> It's also true that SNARK proving has became _far_ more efficient over the past few years
20:10:43 <sarang> But to leap from that to "you can do anything sooper fast now" is absurd
20:10:56 <sarang> Halo is not some magical box that makes your proofs fast
20:11:10 <sarang> It's a specific set of techniques for particular kinds of recursion
20:12:16 <sarang> I've also seen Halo described as "a SNARK", which is not accurate
20:12:28 <sarang> (see the thread for more on that)
20:12:57 <sarang> Any thoughts on the new license under which Halo 2 is released?
20:12:58 <moneromooo> It's not monero. So it can be a SNARK. But monero is monero, so it can't use ZK proofs.
20:13:16 <sarang> https://electriccoin.co/blog/introducing-tgppl-a-radically-new-type-of-open-source-license/
20:13:21 <sarang> moneromooo: STAHP
20:13:23 <moneromooo> :|
20:13:37 <sarang> I am no expert in licenses, but anything described as "radical" in a press release makes me raise my eyebrows
20:14:31 <sarang> Looks like you have to eventually open-source (under the definition in the license), but have a grace period beforehand
20:14:40 <sarang> Would be interesting to have a lawyer review
20:14:54 <moneromooo> You can make money off free software. The premise seems wrong.
20:16:04 <sarang> Yeah, I don't really get it... but I know next to nothing about the consequences of licensing
20:16:24 <sarang> I also don't recall seeing this discussed in Zcash forums, which I follow from time to time
20:16:35 <sarang> So this must have been internal to ECC, as are all the application details for Halo 2
20:16:41 <sarang> Not a fan of that style of operation
20:17:00 <moneromooo> Sounds a lot like we want it closed source but people not to say it's closed source.
20:17:22 <moneromooo> It's missing the point of free software, which is that people can adapt it for their needs.
20:17:39 <moneromooo> Here, it seems to be "you can adapt it in a year's time or whenever". Which defeats the point.
20:17:53 <moneromooo> But I guess it works if you're after hte open source label rather then the use of it.
20:19:49 <sarang> What's interesting is that AFAIK they can't apply licensing to the underlying math
20:19:50 <sarang> Only the code
20:20:03 <sarang> I wonder if this is why they haven't published anything outside of code
20:20:33 <selsta> So they want to sell Holo2 for a couple years before they open source it?
20:20:33 <sarang> "The TGPPL is intended to allow for the best of both worlds: a limited-time period where creators can make money from their software while ensuring that the software will be subsequently open-sourced in order to serve everyone equally." <-- this statement has a footnote mark, but no corresponding footnote ?
20:20:45 <sarang> Well, they have code available now, but it's incomplete
20:20:55 <sarang> Yeah, I don't get what they're after here
20:20:59 <sarang> FWIW there are no papers on this
20:21:01 <sarang> Only their repo
20:21:04 <sarang> which is under this license
20:21:12 <sarang> If there were a paper, they couldn't license the math
20:21:20 <sarang> (you can't license/patent math)
20:22:01 <sarang> Hmm, might ask in the forum about this
20:28:57 <sarang> *no papers for Halo 2
20:29:03 <sarang> There is a preprint for Halo
20:40:23 <sarang> https://mobile.twitter.com/ElectricCoinCo/status/1301613149825556480
20:40:40 <sarang> They can always make money from software under existing licenses, right?
20:40:45 <sarang> This is implying exclusivity?
20:42:03 <sarang> Huh, looks like Zooko himself is the copyright holder for the license: https://github.com/zcash/halo2/blob/main/LICENSE-TGPPL
20:50:49 <sarang> Oh, he wrote that license in 2007
20:50:54 <sarang> It isn't a new thing ECC is doing
20:51:09 <sarang> lol
20:51:15 <sarang> Why does the blog post imply it's new??
20:51:18 <selsta> https://tahoe-lafs.org/~zooko/tgppl.pdf
20:51:24 <selsta> did you see this?
20:51:36 <sarang> Just did, ya
20:52:10 <sarang> It also appears MariaDB does a similar business license
20:52:14 <sarang> This appears neither radical nor new
20:52:26 <sarang> But it is certainly interesting to apply it
20:59:49 <moneromooo> I find it funny one of the reason they give is "underfunding", when they not only got *shitloads* of money from their 4 years 20%, but came back for another bite, breaking their promise.
20:59:53 <moneromooo> The other reason also seems inverted, since how can keeping something closed soure help the public since htey can't adapt it to their needs.
20:59:56 <moneromooo> I might be missing something dumb...
21:01:37 <sarang> Maybe the idea is exclusivity, like trying to make a version of patents?
21:01:55 <sarang> Of course, patents as the standard for innovation is... not great
21:02:36 <moneromooo> Doubt it. He seemed ready to jump onto any shite that might make money.
21:02:42 <moneromooo> Gah.
21:02:48 <moneromooo> Sorry, wring chan agian.
21:02:54 <moneromooo> (not related)
21:04:08 <sarang> I don't really know why they'd do it
21:04:14 <Isthmus> Lol, ECC gets attacked for not making money, but also attacked for trying to make money.
21:04:16 <sarang> It is odd not to have discussed it prior to release
21:04:37 <sarang> I'm not attacking anyone Isthmus
21:04:46 <sarang> Just trying to find out what this is, and why it would be chosen
21:04:49 * Isthmus gestures broadly at twitter
21:04:56 <Isthmus> Not you specifically
21:05:00 <sarang> oh ok
21:05:21 <sarang> Well, trying to move the goalposts for the definition of "open source" without any discussion _should_ be received with skepticism
21:05:43 <selsta> open source*
21:06:20 <sarang> I'm just surprised they did this without any apparent community discussion
21:09:56 <moneromooo> Looks like I got it wrong. It is actually open source, but you *have* to release any changes, even if your mods were private.
21:10:07 <sarang> nice
21:10:13 <moneromooo> At least that is what (i) and (ii) imply.
21:10:17 <sarang> so it's "eventual open source"?
21:10:17 <selsta> > Under this license, ECC receives no special or exclusive privilege — any user or any company can take advantage of the licence’s benefits on an equal footing. Later this week, we will release a post on TGPPL and its potential benefits for the open-source community.
21:10:39 <sarang> I certainly wouldn't use this license without significant scrutiny from attorneys...
21:10:44 <moneromooo> So it's a bit more like AGPL in this respect.
21:10:55 <sarang> The idea that they're doing all this internally and releasing on a schedule is weird
21:10:57 <sarang> I don't like it
21:11:09 <sarang> "This is open source, but the method of releasing it is not"
21:11:57 <selsta> So they will release a bare bones version of it, like they did now and keep their improvements private for 1 year?
21:12:02 <moneromooo> If (i) and (ii) give an accurate view of what it is, I don't see why it addresses underfunding nor capture.
21:12:04 <selsta> Is that the idea? I don’t get it.
21:12:27 <moneromooo> Maybe they're lying. It's a company.
21:12:46 <moneromooo> Or maybe I should read the actual licence :)
21:12:49 <sarang> I don't know
21:12:51 <sarang> This is weird
21:13:09 <sarang> Especially since the Zcash community pays them
21:13:17 <sarang> and AFAIK had no say in this license
21:13:41 <selsta> Ethereum Foundation paid for this apparently
21:14:35 <sarang> The license??
21:14:51 <selsta> > In July, EF granted $120,000 to ECC to continue Halo research.
21:17:41 <sarang> Ah ok
21:17:48 <sarang> Good for them
21:17:49 <sarang> :D