What is a fluffy block?

I'm sorry for the stupid question. getmonero.org/resources/moneropedia/fluffyblocks.html

<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. townforge.net

Disclosure: I am helping develop tools within the Townforge ecosystem.

PR to fix earliest spents issue: monero-project/monero #7821

jberman[m]: please also open against release branch

Done (7822)

Test: Can I post here without "voice"?

Alright, then here instead of #monero-research-lab, sigh:

I am still not sure where best to put questions and comments about "Milestone 2 of Triptych multisig research"

as recently announced on Reddit: old.reddit.com/r/Monero/comments/ot…triptych_multisig_research_complete

So I try my luck here

I try to understand the *practical* consequences of the things described in chapter 7 of the PDF:

Second paragraph of that chapter 7: "Because security of the authorizing proof relies in part on ..."

Does that mean that doing a multisig transaction would get an extra first preparation step somehow?

That it would not be enough like today to just send around partly signed transactions and finally submit after fully signed?

And if yes, how would such an additional first preparation step work?

Could we send info around "round-robbing style", from one authorized signer to the next, like today with the tx proper?

Or would another processing pattern of "Collect info from everybody, then send out info to everybody" be needed?

<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.

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.

Thanks, coinstudent2048. It's impossible for me to judge that proposal without knowing what will be the down-to-earth, practical consequences

when e.g. doing multisig transactions in the CLI

Already now we have a requirement to "sync" after each multisig tx and after each receiving of an input, with the current multisig implementation

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.

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?

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 ...

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.

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

But what matters is what each user, each time, has to do for transacting, say in the CLI wallet, with that proposed Triptych multisig

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

Hello

I've 1000 questionss

How much are you earning per day mining monero from monero gui in laptop running for about 10 hours?

wrong channel

maybe ask in #monero

Is it?

also #monero-pools

Thanks i'll ask there.

yes, this channel is related to the actual development of monero code

oh wow. c++ i found is very hard langauge, how people can buit these all sort of cryptography and things using c++ .

You guys are really genius.

Often it does not feel like that ...

if you know which file in monero github is really core of monero logic is there .

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...

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?

UnluckyMiner logically, all files in monero/src/cryptonote_core dir

Thank you. I hope i'll generate plastic neuron.

Thank you all . bye

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

That's why, with unmodified CLI wallet, each additional round of communication is a big PITA

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

and more chances your partners are not online right now, and everybody has to wait

Instead of "unmodified CLI wallet" better take that "with the basic, non-MMS CLI command set", as the MMS is always there

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

For example use subreddit search like so: old.reddit.com/r/Monero/search?q=co…restrict_sr=on&sort=relevance&t=all

rbrunner: ok thanks for the help!

You are welcome. And good luck, we can always use new devs!

:)

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.

monero-project/monero #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?

there are no plans for a network upgrade at the moment afaik

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

Hi, i have problems building last monero docker image with readline support, somebody can help me plz?

Paste the build log to, eg, pastebin, paste.debian.net, etc. Then post the link here.

ok thx

i paste jsut the readline error

mv: cannot stat '/usr/local/lib/libhistory.a': No such file or directory

Appears generally undermaintained. I have some time now. I can try to reproduce.

Does the Dockerfile require a specific host OS?

no i dont think so, just a recent version of docker

thanks

i use the master branch

I don't like, that the Dockerfile expects Ubuntu 16.04, while we deliver builds for 18.04. A good sign of undermaintenance.

yeah

but i try to use from builder 18.04 it didnt work too

I also see, that OpenSSL's version is pre- important security fixes.

starting a new branch then ...

yeah we can upgrade some dependencies

i test with v17 also with some changes in the dockerfile

same readline problem

loshen66: I'm building the packages to try to reproduce. Gimme an hour or 2.

thats fine mj-xmr[m] thank you

loshen66: that error doesn't stop docker build, what is the final result of docker build ?

@wfaressuissia no the build success but without readline

monero-project/monero #3200 this commit replaced libreadline-dev with manual compilation and removed implicitly libtinfo-dev without any replacement

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

* .. it easier to use depends ...

yeah, would rather we quit with the separate dockerfile and just get everyone building with depends

i will try this thanks @wfaressuissia

will tell you if it work

does anyone know a platform for getting paid for software development work (freelancing) in crypto?

masterofdead4[m], probably better for #monero. But, if you want to work on monero, you can look into getting a CCS funded project