10:42:35 <ErCiccione[m]> Where can i find the logo of the research lab?
10:44:25 <ErCiccione[m]> nevermind. I downloaded the logo of this room on matrix
13:43:11 <sarang> ErCiccione[m]: rehrar might have some high-res versions too
13:43:59 <sarang> Also, hello all
13:44:17 <sarang> Finalizing common-key Triptych batching and getting the plots updated today, woo
13:49:16 <UkoeHB_> 🎉
13:51:53 <SerHack> that sounds awesome!
18:08:53 <Isthmus> On a desktop/laptop does validating two blocks in parallel take the same amount of time as validating two blocks serially?
18:09:32 <moneromooo> Probably not.
18:09:57 <moneromooo> The concept of "validating two blocks in parallel" is ill defined though.
18:11:23 <Isthmus> I'm booting up a new node. Instead of processing blocks 1 - 1000 in a row, perhaps I validate [1-250] in parallel with [...], [...], and [751-1000]
18:19:47 <hyc> those example numbers aren't so great, since monerod uses compiled-in hashes for the first couple million blocks
18:21:06 <hyc> but since blocks refer to previous txns, you can't get very far ahead, if at all, by parallelizing
18:22:06 <moneromooo> Blocks are made of txes, which depend on previous txes, so it might be annoying to parallelize, but by all means, any improvement is probably good :)
18:22:48 <hyc> if you're lucky enough that all the txs are old enough to have already been verified
18:23:14 <hyc> if not, then you're implicitly serialized anyway, waiting for those txs to go by
18:28:59 <Isthmus> Oh very interesting, I have to think about that
18:31:16 <moneromooo> You can verify PoW in parallel.
18:32:00 <moneromooo> Without dependency on earlier blocks I mean.
18:33:00 <derbleak> does predictive/optimistic branching/rollback make sense in this context? i.e. groups of blocks expected to be valid done in parallel, invalid triggers rollback + serial validation
18:34:47 <hyc> it's a nice idea in a perfect world
18:35:03 <hyc> because in the ideal case, it would work in parallel most of the time
18:35:32 <hyc> but if you become dependent on that, it's trivial to DoS the network by tossing in crafted blocks
18:36:11 <derbleak> true, could do nasty things w/ invalid blocks nested deep in a valid chain... damn
18:38:30 <derbleak> what about using some of the snapshotting tech to guard against maliciousness? so, snapshot 100k block chunks, do a hash/zkp of the snapshot, validate all included snapshot tx in parallel
18:38:53 <derbleak> or w/e for the snapshot # of blocks
18:41:19 <sarang> A zkp of what exactly?
18:42:03 <sarang> (I only ask because my eye twitches whenever I hear "just use a zkp" for something)
18:42:07 <UkoeHB_> doesn't verifying PoW depend on recomputing all the difficulties, which is a serial operation?
18:42:08 <derbleak> zkp doesn't make sense
18:42:31 <derbleak> disregard, but the hash of the snapshot as checksum
19:01:41 <derbleak> derp dropped (irc gods are angry w me)
19:03:07 * derbleak begins the requisite self-flogging
19:21:37 <UkoeHB_> derbleak: https://monerologs.net/monero-research-lab/20200421 if you need to recover logs
19:28:00 <derbleak> UkoeHB_: thank you :)
19:53:15 <derbleak> re: binary distribution, one possibly dumb idea could be to use serverless functions to `git pull and build`, distributing a freshly built bin every time :)
19:53:44 <derbleak> be fun to see amazon reaction
19:53:53 <derbleak> :p
20:05:30 <derbleak> bezos trolling aside, think the torrenting idea is great
20:06:13 <derbleak> bittorrent has a blockchain project on tron iirc, could enable another channel of decentralized hosting/distribution
20:06:40 <selsta> pls no tron
20:06:50 <derbleak> lol 100% ^
20:07:06 <derbleak> mb filecoin or smth similar?
20:07:50 <jwinterm> did filecoin ever launch?
20:08:56 <derbleak> https://filecoin.io/blog/roadmap-update-april-2020/
20:11:07 <jwinterm> long way to say no
20:11:17 <derbleak> yeah...
20:11:34 <derbleak> sorry, posted b4 reading
20:12:00 <derbleak> ipfs is definitely live though
20:12:11 <jwinterm> siacoin is another one, think storj went out of business(?)
20:12:21 <jwinterm> or whatever happens when blockchains die
20:12:56 <derbleak> bits used as entropy, fading into the heat death
20:14:36 <derbleak> https://onionshare.org
20:16:47 <selsta> a bit off topic here but what would the advantage of torrent / ipfs / ... be over a normal http download?
20:17:37 <derbleak> security and baked in authentication/signing
20:18:08 <derbleak> for ipfs, potentially censorship-resistant, *very* long-term storage
20:18:35 <derbleak> similar for siacoin etc.
20:19:17 <derbleak> could also host the storage coin clients as hidden services, mb
20:19:31 <derbleak> s/clients/nodes
20:19:31 <monerobux> derbleak meant to say: could also host the storage coin nodes as hidden services, mb
20:20:41 <derbleak> mb i'll set one up today :)
20:23:54 * derbleak afk to tinker
22:23:06 <sarang> New multi-input timing data: https://usercontent.irccloud-cdn.com/file/8CJqeZGu/timing.png
22:23:29 <sarang> This example is the per-input timing data for a 2-input transaction
22:24:02 <sarang> Also rewrote some tests for better comparisons that include commitment offsets
22:33:00 <niocbrrrrrr> which version of triptych is that?
22:34:56 <sarang> The C++ implementation I did
22:35:05 <sarang> with some modifications to support commitment offsets more efficiently
22:36:03 <sarang> Shortly, I'll do a quick modification to support multi-index signing and balance assertion
22:36:14 <niocbrrrrrr> triptych or arcturus
22:36:25 <sarang> Triptych
22:36:28 <sarang> ^ is this data
22:36:46 <sarang> Arcturus should have similar timing results
22:36:51 <niocbrrrrrr> thx
22:36:53 <sarang> with better size data