08:24:41 <Halver[m]> Currently, there is no Monero GUI Wallet available at download for Raspberry Pi.
08:24:43 <Halver[m]> Is this definitive, or we could expect it could be available in the (near) future ?
09:06:41 <dr_overdose[m]> Hey all, I'm Peter. My background is theoretical physics. I worked as an academic researcher studying dynamics of black holes and gravitational waves for over a decade. During my MSc I built some coding skills in cpp, shell, and python, simulating binary systems and doing analysis for LIGO. I'm a bit rusty in my coding, but eager to get back to it.  I'm looking to get involved in the Monero project, as it seems to align with my
09:06:41 <dr_overdose[m]> sensibilities and general philosophy, and do some contributing. Is this the place to be? 
09:10:05 <sech1> yes
09:10:17 <sech1> the source code is here: https://github.com/monero-project/monero/
09:10:31 <sech1> and some technical details are here: https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf
09:13:19 <Halver[m]> For a list of resources concerning monero developement, see also : http://moneroar4fiojlkzkvwgt25rp6vifswcpwaxbzlhfkdenczbhc4luqad.onion/monero-dev/
09:13:24 <dr_overdose[m]> I've already downloaded, verified, and compiled the source and can run the client monerod. At least according to make tests
09:15:21 <dr_overdose[m]> sech1: Thx.
12:01:11 <garth> Welcome dr_overdose[m]
12:59:11 <dr_overdose[m]> Thanks garth. I'm just reading through the Zero-to-Monero reference trying to get a handle on the basics first.  I'll try to post questions as they come up in my reading
13:00:23 <sech1> there's also https://www.getmonero.org/resources/developer-guides/
15:02:53 <dr_overdose[m]> <sech1> "and some technical details are..." <- I have question about Diffie-Hellman key exchange as described on page 24 Sec. 2.3.2 in the reference. Everything up to here has been clearly defined but I'm confused what is really meant by "hash the secret S". Why does Alice compute h=\mathcal{H}(S) whereas Bob computes h'=\mathcal{H}(S)? Doesn't then h=h'?
15:03:57 <sech1> yes h=h'
15:04:01 <sech1> that's the point
15:06:19 <dr_overdose[m]> ok that's good. how is h constructed? 
15:07:06 <dr_overdose[m]> and is there a unique h for every S?
15:07:40 <sech1> H is just an arbitrary hash function (cryptographically secure)
15:07:52 <sech1> Monero uses mostly cn_fast_hash and cn_slow_hash in different context
15:08:06 <sech1> IIRC cn_fast_hash is keccak and cn_slow_hash is Cryptonight
15:08:17 <dr_overdose[m]> where in the source code can i find this? do you know off hand?
15:09:06 <dr_overdose[m]> if not I can just grep 
15:09:13 <sech1> monero/src/crypto/hash.c
15:09:18 <sech1> and other files in that folder
15:09:43 <dr_overdose[m]> thank you 
18:20:49 <Rucknium[m]> dr_overdose: Awesome. You may want to check out this list of Monero open research questions that I put together:
18:20:49 <Rucknium[m]> https://github.com/monero-project/research-lab/issues/94
18:22:40 <Rucknium[m]> You may also want to join #monero-research-lab:matrix.org  and #monero-research-lounge:monero.social 
18:22:57 <Rucknium[m]> And #monero-recruitment:monero.social 
20:12:17 <xxfedexx[m]> Hey there, what do you think about implementing self-pruning in Monero? Blockchain size will be an issue in the future, especially after the next hardfork: increased ring size leads to bigger transaction size, and thus bigger blockchain.
20:13:05 <selsta> You have to define self pruning first. Monero does support pruning, but not like in Bitcoin.
20:18:20 <xxfedexx[m]> Self pruning = very old blocks get "deleted" (pruned) automatically and disappear. Currently even if you prune the blockchain, it is not small because of how ring signatures work. But why not preventing transactions from containing very old txs in the ring signature?
20:24:58 <UkoeHB> No one knows whether an ancient output is spent or not.
21:37:49 <dr_overdose[m]> > <@rucknium:monero.social> dr_overdose: Awesome. You may want to check out this list of Monero open research questions that I put together:
21:37:49 <dr_overdose[m]> > https://github.com/monero-project/research-lab/issues/94
21:37:49 <dr_overdose[m]> Awesome, thx. Was looking for something like thiis
21:52:43 <jeffro256[m]> xxfedexx: IIUC old blocks do get deleted while using a  pruned node, except for the data necessary to verify new blocks, i.e. output lists and amount commitments, etc. If you haven't yet seen it, here's a good link: https://www.getmonero.org/resources/moneropedia/pruning.html
22:11:16 <moneromooo> Blocks don't get deleted. What gets deleted is the signatures and a few other things from 7/8ths of the transactions.
22:12:23 <moneromooo> A more thorough pruning is possible, but the current pruning "level" was selected as a good compromise between space savings and utility, since a pruned node is still able to serve blocks to newly syncing nodes, which will want to verify that data.
22:13:09 <moneromooo> It is possible to prune more/better, but if the pruned nodes become useless to peers, it makes the network more brittle.
22:13:51 <moneromooo> There's another pruning capability that I think noone uses, but it only gains 200 or 300 MB or so: pruning known spent (pre-rct) outs.
22:14:30 <moneromooo> (there's a tool to do this in the repo)
22:16:10 <jeffro256[m]> Yeah, a pruned node keeps 1/8 of old blocks, randomly selected, correct?
22:16:38 <moneromooo> 1/8 of old transaction signatures and range proofs.
22:18:26 <jeffro256[m]> So can a pruned nodes serve only some old blocks or none at all?
22:18:36 <Rucknium[m]> Note that I recently added more aggressive pruning to the list of open research questions. It's probably impossible to do bitcoin-style pruning, but that's why it's an open research question:
22:18:46 <Rucknium[m]> https://github.com/monero-project/research-lab/issues/94
22:18:47 <jeffro256[m]> I know it can server newer blocks
22:19:28 <moneromooo> It can serve full blocks for an eigth of the chain, and pruned blocks for.... 7/8th of recent enough chain.
22:19:55 <moneromooo> It can also serve anything from the last 5k blocks.
22:20:26 <moneromooo> If a new node runs with --sync-pruned-blocks, a pruned node can serve pruned blocks to that node.
22:20:43 <moneromooo> Without preventing verification.
22:23:17 <jeffro256[m]> Interesting. How does that work? How does a node accept a pruned block without preventing verification? Is there an extra hash in the headers to verify those pruned blocks?
22:32:57 <moneromooo> From some fork, a txid is made of a hash of hashes of different parts of the tx. Pruning involves deleting the prunable part, but keeping the hash of that part.
22:33:33 <moneromooo> So a newly syncing client can verify an incoming pruned tx matches the txid in the block, which is PoW secured.
22:34:11 <moneromooo> It's not as thorough, but still pretty good, since it requires breaking keccak to exploit.
22:40:45 <jeffro256[m]> Wow I didn't know that; that's genius. So conceivably, someone could write a pruned node that even more aggressively erased data from their copy of the chain, and have it still be verified through PoW? 
22:41:21 <jeffro256[m]> I assume the txid hash now uses some sort of Merkle tree-like algo?
22:41:31 <moneromooo> A node can verify everything whether pruned or not.
22:41:56 <moneromooo> The difference is whether a pruned node can serve pruned data that can be used by another node to verify.
22:42:04 <moneromooo> It's not a merkle tree.
22:44:19 <moneromooo> So you could modify the code to drop lots more data and still verify your whole chain. It's enough to verify as you sync, and drop data afterwards.
22:44:35 <moneromooo> Like all block data is not needed anymore (except recent stuff, in case of reorgs).
22:44:45 <moneromooo> Same for txes.
22:45:07 <moneromooo> But that node becomes useless to the network, so someone decided it was not good.
22:45:32 <moneromooo> It'll probably happen someday.