01:32:41 <Snapper> What is a fluffy block?
01:38:27 <Snapper> I'm sorry for the stupid question. https://www.getmonero.org/resources/moneropedia/fluffyblocks.html
02:30:27 <Rucknium[m]> <skirunner[m]> "If Monero had some type of dapp..." <- Townforge, a fork of Monero, is kind of a dapp. It has scripts that are state machines -- not as flexible as turning-complete ETH, but not as dangerous either. https://townforge.net/
02:31:02 <Rucknium[m]> Disclosure: I am helping develop tools within the Townforge ecosystem.
04:20:06 <jberman[m]> PR to fix earliest spents issue: https://github.com/monero-project/monero/pull/7821
04:38:18 <selsta> jberman[m]: please also open against release branch
04:55:31 <jberman[m]> Done (7822)
06:12:33 <rbrunner> Test: Can I post here without "voice"?
06:13:08 <rbrunner> Alright, then here instead of #monero-research-lab, sigh:
06:13:12 <rbrunner> I am still not sure where best to put questions and comments about "Milestone 2 of Triptych multisig research"
06:13:24 <rbrunner> as recently announced on Reddit: https://old.reddit.com/r/Monero/comments/otgw36/milestone_2_of_triptych_multisig_research_complete/
06:13:33 <rbrunner> So I try my luck here
06:13:40 <rbrunner> I try to understand the *practical* consequences of the things described in chapter 7 of the PDF:
06:13:46 <rbrunner> https://github.com/cypherstack/triptych-multisig/blob/main/main.pdf
06:13:53 <rbrunner> Second paragraph of that chapter 7: "Because security of the authorizing proof relies in part on ..."
06:14:01 <rbrunner> Does that mean that doing a multisig transaction would get an extra first preparation step somehow?
06:14:08 <rbrunner> That it would not be enough like today to just send around partly signed transactions and finally submit after fully signed?
06:14:15 <rbrunner> And if yes, how would such an additional first preparation step work?
06:14:21 <rbrunner> Could we send info around "round-robbing style", from one authorized signer to the next, like today with the tx proper?
06:14:27 <rbrunner> Or would another processing pattern of "Collect info from everybody, then send out info to everybody" be needed?
07:31:56 <coinstudent2048[> <rbrunner> "Does that mean that doing a..." <- I think it just means that for the Triptych proof to complete, we need to first get the linking tag/key image, multisig or not.
07:45:44 <coinstudent2048[> Unfortunately, we don't have a way (now, maybe there is, but unlikely) to make the computation of linking tag "round-robin" style. Unlike today's multisig, linking tag is nonlinear: J=p^-1 * U where p is one-time private key.
07:59:42 <rbrunner> Thanks, coinstudent2048. It's impossible for me to judge that proposal without knowing what will be the down-to-earth, practical consequences
08:00:01 <rbrunner> when e.g. doing multisig transactions in the CLI
08:00:40 <rbrunner> Already now we have a requirement to "sync" after each multisig tx and after each receiving of an input, with the current multisig implementation
08:00:45 <coinstudent2048[> Note: in Fiat-Shamir, we hash-to-scalar all the proof "inputs" (sorry I don't know some terminologies). In case of Triptych, proof "inputs" are A, B, C, D, X_j, Y_j, mu, etc. The output of hash-to-scalar serves as the "challenge" instead of the verifier giving the prover. Thus making the proof non-interactive.
08:02:20 <rbrunner> The big question for me is: With Triptych multisig as proposed here, does this get any worse, for *end users*, in terms of numbers of data exchange rounds?
08:04:13 <rbrunner> Sorry that I am almost completely innocent regarding the "crypto", I can't derive myself from the writings whether there will be additional data packets to send around ...
08:13:05 <coinstudent2048[> rbrunner: Hmm... I would say Triptych's linking tag construction is worse in data exchange rounds than today's key image construction (assuming it's Schnorr-like). Sorry I can read some math, but I am not an expert.
08:13:56 <rbrunner> Yeah, no problem, but it's that front where things will get decided. Never mind how awfully complicated the math and the crypto, once implemented, that's ok
08:14:23 <rbrunner> But what matters is what each user, each time, has to do for transacting, say in the CLI wallet, with that proposed Triptych multisig
08:15:15 <rbrunner> Thus my insistence here to translate from the math and the crypto as documented by sarang to down-to-earth handling requirements when users transact
08:16:09 <UnluckyMiner> Hello
08:16:28 <UnluckyMiner> I've 1000 questionss
08:17:19 <UnluckyMiner> How much are you earning per day mining monero from monero gui in laptop running for about 10 hours?
08:17:25 <Inge> wrong channel
08:17:32 <Inge> maybe ask in #monero 
08:17:49 <UnluckyMiner> Is it?
08:17:53 <Inge> also #monero-pools
08:17:58 <UnluckyMiner> Thanks i'll ask there.
08:18:03 <Inge> yes, this channel is related to the actual development of monero code
08:18:42 <UnluckyMiner> oh wow. c++ i found is very hard langauge, how people can buit these all sort of cryptography and things using c++ . 
08:18:50 <UnluckyMiner> You guys are really genius.
08:19:14 <rbrunner> Often it does not feel like that ...
08:20:33 <UnluckyMiner> if you know which file in monero github is really core of monero logic is there . 
08:20:57 <coinstudent2048[> rbrunner: I have a question: do multisig users have to "manually" send the multisig stuff? What I mean by manual is that Monero doesn't provide code for sending...
08:23:45 <TrevorKedge[m]> Sup guys, I'm really interested in this project. I'd describe myself as an intermediate level programmer, but Open Source noob. Could someone give me some pointers to learning about the project and start to be able to contribute?
08:25:03 <sech1> UnluckyMiner logically, all files in monero/src/cryptonote_core dir
08:25:44 <UnluckyMiner> Thank you. I hope i'll generate plastic neuron.
08:25:49 <UnluckyMiner> Thank you all . bye 
08:28:33 <rbrunner> coinstudent2048: Pure CLI wallet just prints multisig data on the console or writes it to files. How you transport this to the intended authorized signer is your problem only
08:28:54 <rbrunner> That's why, with unmodified CLI wallet, each additional round of communication is a big PITA
08:29:39 <rbrunner> If you use "my" MMS it's much more automated, but that MMS needs a setup first, and still more communication needs more time to transact
08:30:02 <rbrunner> and more chances your partners are not online right now, and everybody has to wait
08:31:42 <rbrunner> Instead of "unmodified CLI wallet" better take that "with the basic, non-MMS CLI command set", as the MMS is always there
08:34:55 <rbrunner> TrevorKedge[m]: You may have a look at various threads on the Monero subreddit where every now and then people are at the same point like you now
08:35:19 <rbrunner> For example use subreddit search like so: https://old.reddit.com/r/Monero/search?q=contribute&restrict_sr=on&sort=relevance&t=all
08:39:14 <TrevorKedge[m]> rbrunner: ok thanks for the help!
08:46:19 <rbrunner> You are welcome. And good luck, we can always use new devs!
08:53:27 <TrevorKedge[m]> :)
09:02:15 <coinstudent2048[> rbrunner: That's enlightening, thanks! I hope that the whole thing can be optimized in terms of communication rounds without compromising security. Chapter 6 "Observations" has this "compress the Paillier inversion protocol", removing (only) 1 communication round. I'll try to find optimizations.
09:15:04 <john_r365> https://github.com/monero-project/monero/pull/7819 <- presumably an update to the fees algorithm requires a hard fork? is there a current estimate on when the next hard fork might be? I think the last one was Oct 17 2020? So perhaps a similar time again?
10:16:23 <ErCiccione> there are no plans for a network upgrade at the moment afaik
11:29:12 <john_r365[m]> Ok thanks :) I guess was waiting on triptych, and now that’s a little more complicated since the multisig process appears more complex than desired
13:03:03 <loshen66> Hi, i have problems building last monero docker image with readline support, somebody can help me plz?
13:03:34 <moneromoooo> Paste the build log to, eg, pastebin, paste.debian.net, etc. Then post the link here.
13:03:59 <loshen66> ok thx
13:07:44 <loshen66> https://pastebin.com/Nc4ZvTk0
13:07:51 <loshen66> i paste jsut the readline error
13:08:15 <mj-xmr[m]> mv: cannot stat '/usr/local/lib/libhistory.a': No such file or directory
13:09:49 <mj-xmr[m]> Appears generally undermaintained. I have some time now. I can try to reproduce.
13:09:49 <mj-xmr[m]> Does the Dockerfile require a specific host OS?
13:10:45 <loshen66> no i dont think so, just a recent version of docker
13:12:16 <loshen66> thanks 
13:13:41 <loshen66> i use the master branch
13:13:53 <mj-xmr[m]> I don't like, that the Dockerfile expects Ubuntu 16.04, while we deliver builds for 18.04. A good sign of undermaintenance.
13:14:03 <loshen66> yeah
13:14:42 <loshen66> but i try to use from builder 18.04 it didnt work too
13:14:50 <mj-xmr[m]> I also see, that OpenSSL's version is pre- important security fixes.
13:15:32 <mj-xmr[m]> starting a new branch then ... 
13:15:38 <loshen66> yeah we can upgrade some dependencies
13:17:52 <loshen66> i test with v17 also with some changes in the dockerfile
13:18:24 <loshen66> same readline problem
13:32:25 <mj-xmr[m]> loshen66: I'm building the packages to try to reproduce. Gimme an hour or 2.
13:33:50 <loshen66> thats fine mj-xmr[m] thank you
14:00:06 <wfaressuissia[m]> loshen66: that error doesn't stop docker build, what is the final result of docker build ?
14:01:37 <loshen66> @wfaressuissia no the build success but without readline
15:08:45 <wfaressuissia[m]> https://github.com/monero-project/monero/pull/3200 this commit replaced libreadline-dev with manual compilation and removed implicitly libtinfo-dev without any replacement
15:11:25 <wfaressuissia[m]> https://paste.debian.net/hidden/bc8bc015/ try this, but if it doesn't work then it's easier to depends from docker instead of fixing this outdated Dockerfile
15:11:40 <wfaressuissia[m]> * .. it easier to use depends ...
15:23:16 <hyc> yeah, would rather we quit with the separate dockerfile and just get everyone building with depends
17:27:20 <loshen66> i will try this thanks @wfaressuissia
17:29:21 <loshen66> will tell you if it work
18:43:38 <masterofdead4[m]> does anyone know a platform for getting paid for software development work (freelancing) in crypto?
18:54:28 <gingeropolous> masterofdead4[m], probably better for #monero. But, if you want to work on monero, you can look into getting a CCS funded project