-
m-relay
<oronuevo:nope.chat> Somewhat of a dumb question but I am trying to wrap my head around the "protocol abstraction" change proposed in the Seraphis paper. The closest analogy I can think of is to picture protocol abstraction as a refactoring project where the outcome is cleaner, easier to work with codebase. How far off am I?
-
m-relay
<oronuevo:nope.chat> And assuming the above is somewhat accurate, wouldn't this mean protocol abstraction could still be beneficial to implement post FCMP upgrade?
-
m-relay
<jeffro256:monero.social> A protocol abstraction is this case is more a set of requirements that a real, concrete protocol more follow. There's not necessarily one single, definitive way to do Seraphis, which is why it's an "abstraction". For example, you can have Seraphis with Grootle proofs as posited by Ukoe in their implementation paper OR you can have Seraphis with full-chain membership proofs. A good<clipped message>
-
m-relay
<jeffro256:monero.social> abstraction lets you swap out different modules and still be compatible
-
m-relay
<jeffro256:monero.social> FCMP++ also has this same notion of abstraction in the sense that different proofs in the transaction have different purposes and can be swapped out as "drop-in" replacements
-
m-relay
<jeffro256:monero.social> Also, just FYI, FCMP++ != Seraphis, they are completely separate flavors of protocols. Seraphis was dropped in favor of FCMP++. FCMP++ is short for Full-chain membership proofs + spend authization + linkability, since all those components were replaced in RingCT
-
m-relay
<sushis:matrix.org> has it been actually dropped? at one point there were talks that it could be both eventually but fcmp++ first type thing
-
m-relay
<sushis:matrix.org> i mean, regarding seraphis
-
m-relay
<sushis:matrix.org> oh right nvm i guess CARROT and other things were the alternative so it didnt went forward on that seraphis thing, my bad
-
m-relay
<jeffro256:monero.social> Yeah, AFAIK it isn't a priority for anyone working on Monero at the moment. I doubt Seraphis + FCMPs will materialize before a large push for post-quantum or blinding CSV or something else along those lines. FCMP++ and Seraphis are feature complete. Seraphis is somewhat more performant but the cost is that it breaks existing addresses and the anonymity set must be restarted.
-
m-relay
<jeffro256:monero.social> CARROT is an addressing protocol on top of FCMP++, not an alternative protocol to FCMP++. Both are live on the stressnet right now
-
m-relay
<sushis:matrix.org> right, i like my vanitygen address, wasnt really onboard with seraphis just cause of that lol
-
m-relay
<jeffro256:monero.social> CARROT could be considered a FCMP++-friendly analougue to JAMTIS
-
m-relay
<rbrunner7:monero.social> I wonder how an unfriendly analog of JAMTIS for CARROT would look ...
-
m-relay
<rbrunner7:monero.social> But I get the point :)
-
m-relay
<rbrunner7:monero.social> I try to compile the `release-v0.18` branch on the most recent version of OpenBSD, version 7.8 that is about 1 month old. It compiles, but when linking the very first binary there are linker errors, and make stops. The errors can be seen here:
paste.debian.net/1409580
-
m-relay
<rbrunner7:monero.social> The version of *libunbound* that is installed is 1.24
-
m-relay
<rbrunner7:monero.social> My main system on Debian has that at version 1.17, and I have no problems to compile the release branch.
-
puffybuf
lost power last night, now I get "Failed to query m_blocks: MDB_BAD_TXN: Transaction must abort, has a child, or is invalid"
-
puffybuf
I can't even pop blocks or salvage my monero db... it gives that error first thing
-
m-relay
<rbrunner7:monero.social> How do you usually investigate the cause of such linker errors, like I have now with *libunbound*?
-
puffybuf
oh this is the -dev channel, oops
-
m-relay
<rbrunner7:monero.social> puffybuf: Yes. I think if you don't have a copy of the blockchain at some state where it still worked, you probably have to sync from scratch again.
-
puffybuf
I would think it could just start verifying from first block and recover where the error is??
-
m-relay
<rbrunner7:monero.social> The blockchain file is not linear where it only appends. It has a complicated internal structure, a database with several tables, indexes, and so on, that are constantly modified as new blocks and transactions are added. You can't just cut the last GB from the file and restart from there
-
puffybuf
now I have to start making backups of the DB
-
m-relay
<rbrunner7:monero.social> Or, better still, of your whole system, no? Would you like to install everything from scratch if bad luck leads to installation corruption?
-
m-relay
<rbrunner7:monero.social> By the way, if I try to compile current Master on that OpenBSD 7.8 system the compiler thinks it sees some syntax error in a Trezor related file. Very strange. I did not yet investigate that further ...
-
puffybuf
couldn't it just remake all those tables, indexes starting from the first block
-
puffybuf
monerod on OpenBSD has a lot of problems
-
m-relay
<tobtoht:monero.social> @rbrunner7:monero.social: How are you building Monero? It shouldn't link to the static libunbound archive. On OpenBSD, unbound is built with libevent, which our CMake config does not look for / link (resulting in the error you're seeing).
-
m-relay
<rbrunner7:monero.social> Well, with just the standard Makefile in the source, and `gmake`, because `make` sees some syntax errors in the make file and doesn't go anywhere.
-
m-relay
<rbrunner7:monero.social> You mean I would have to add `libevent` as a new dependency?
-
m-relay
<tobtoht:monero.social> One sec, I'll spin up a VM.
-
m-relay
<tobtoht:monero.social> @rbrunner7:monero.social: Did not run into any issues building `master` or `release-v0.18` with `cmake -S . -B build && cmake --build build --parallel n` on OpenBSD 7.1
-
m-relay
<tobtoht:monero.social> Did you build Monero using `(g)make release-static`? That would explain why you're running into this issue.
-
m-relay
<rbrunner7:monero.social> I didn't use any argument, simply `gmake`, assuming there is a sane default.
-
m-relay
<rbrunner7:monero.social> I had built Monero on OpenBSD 7.4, maybe 1.5 or 2 years ago, which had worked as well.
-
m-relay
<tobtoht:monero.social> Oops, I meant to say I'm on 7.8.
-
m-relay
<tobtoht:monero.social> I can't reproduce using just `gmake`.
-
m-relay
<rbrunner7:monero.social> Thanks for testing! Maybe just to be sure I will clone the whole repo again as my next step then.
-
m-relay
<tobtoht:monero.social> Maybe the CMake `STATIC` cache var got set somehow. Doing a clean build or invoking cmake as I mentioned above should fix that.
-
m-relay
<0007sayon:matrix.org> Who is founder monero
-
m-relay
<0007sayon:matrix.org> There are so many privacy focused coins like Bitcoin and then there is Monero. Whoever is behind it must be very talented people.
-
m-relay
<0007sayon:matrix.org> Hello
-
m-relay
<0007sayon:matrix.org> Those who mine Monero coin suffer a lot of losses because the amount of electricity consumed for mining and the amount of transaction fees the miners receive are much less. Is this true?
-
m-relay
<modul8:matrix.org> Why sell it if you are going to the trouble to mine it.
-
m-relay
<0007sayon:matrix.org> If a security expert wants to hack the Monero network, how successful will he be?
-
plowsof
wrong room 🥱
-
m-relay
<sushis:matrix.org> mining is a good way to have "very clean monero", some people do it at a loss, just in case blockchain analysis companies would be able to see through the whole ring signature thing
-
m-relay
<sushis:matrix.org> transaction fees shouldnt be a bother in monero compared to bitcoin, since tail emission is a thing here
-
m-relay
<sushis:matrix.org> botnets, fantatical miners mining at a loss, people on solar are what's making the network less attractive to speculative miners tho
-
m-relay
<sushis:matrix.org> but some people actually do need the "cleanest moneros possible"
-
m-relay
<sushis:matrix.org> and yea, this the dev channel, for more general talks, #monero:monero.social would be more fitting
-
m-relay
<0007sayon:matrix.org> Right brother
-
m-relay
<sushis:matrix.org> mining is a good way to have "very clean monero", some people do it at a loss, just in case blockchain analysis companies would be able to see through the whole ring signature thing
-
m-relay
<sushis:matrix.org> transaction fees shouldnt be a bother in monero compared to bitcoin, since tail emission is a thing here
-
m-relay
<sushis:matrix.org> botnets, fanatical miners mining at a loss, people on solar are what's making the network less attractive to speculative miners tho
-
m-relay
<sushis:matrix.org> but some people actually do need the "cleanest moneros possible"
-
m-relay
<0007sayon:matrix.org> Well, let me ask a logical question, monero is a privacy focused wallet. Whoever puts money in it will definitely be safe. I think if I buy 1xmr, then I will definitely have to buy from bainance, Coinbase, bybit. Maybe I bought bitcoin and then exchanged it for monero, but then what is the benefit? The first time I bought bitcoin, I had to submit KYC. If a government agency asks f<clipped message>
-
m-relay
<0007sayon:matrix.org> or information from the company, it will definitely provide the information. So where did the security go?
-
m-relay
<plowsof:matrix.org> continue elsewhere. sushis do not edit your messages
-
m-relay
<sushis:matrix.org> was edit for typo "fantatical" -> "fanatical"
-
m-relay
<0007sayon:matrix.org> Well, let me ask a logical question, monero is a privacy focused wallet. Whoever puts money in it will definitely be safe. I think if I buy 1xmr, then I will definitely have to buy from bainance, Coinbase, bybit. Maybe I bought bitcoin and then exchanged it for monero, but then what is the benefit? The first time I bought bitcoin, I had to submit KYC. If a government agency asks f<clipped message>
-
m-relay
<0007sayon:matrix.org> or information from the company, it will definitely provide the information. So where did the security go?
-
m-relay
<sushis:matrix.org> smh
-
m-relay
<plowsof:matrix.org> Sayon continue this conversation elsewhere, #monero.social:monero.social for example
-
m-relay
<0007sayon:matrix.org> Did I say anything wrong? What kind of talk should I have in this chat?
-
m-relay
<gingeropolous:monero.social> monero development related talk. like, improving and developing on the software itself Sayon
-
m-relay
<0007sayon:matrix.org> Brother
-
m-relay
<0007sayon:matrix.org> Add stronger privacy Face recognition Fingerprint recognition Extra two layers of password protection A password In the second stage, the answer to the security question must be given and then he will be able to access the wallet
-
m-relay
<goattron33:matrix.org> I have a question, and perhaps this is not the place, but what time horizon can it be seen that Monero is quantum resistant, I understand FCMPs are a step forward, but what is it gonna take for it be fully resistant
-
m-relay
<321bob321:monero.social> This question needs to be added to FAQ on site. Gets asked every other week..
-
DataHoarder
-
m-relay
<rbrunner7:monero.social> tobtoht: With a fresh clone of the repo I could finally successfully compile the release branch. Not that much of a surprise after your own successful test, but still nice :)
-
Cindy
hey vtnerd, can lws take in spent key images to update the amount accordingly?
-
Cindy
for an address
-
m-relay
<goattron33:matrix.org> feel like my IQ rose +33 simply by reading this
-
Cindy
well if i make a spend from a wallet, lws won't have an accurate balance :P
-
Cindy
because it only has the view key
-
Cindy
so i was wondering if the accuracy could be improved by providing key images
-
m-relay
<sashimi.:matrix.org> would it be worth to spend dev resource on a temporary fix for that? while if i not mistaken outgoing viewkeys will be working with fcmps so wont be an issue coming forward, well i think...
-
Cindy
it's actually carrot that'll introduce outgoing viewkeys
-
Cindy
not FCMP++
-
Cindy
but yeah, true
-
m-relay
<sashimi.:matrix.org> 👍️
-
Cindy
but there's still a LOOONG way for either to be adopted into mainnet
-
Cindy
so the temporary fix could be worthwhile
-
Cindy
(and i'll be up to implementing it into monero-lws if the feature does not exist yet)