02:28:03 <kayabanerve[m]> I asked a week ago about an IM way to contact emesik and just wanted to ask again in case anyone has talked to him. I sent an email about a week ago yet no response yet so trying to follow up :/
02:28:23 <kayabanerve[m]> And no, not a social call, I know #monero-offtopic exists. This is about development
02:57:48 <kayabanerve[m]> *emesik is the monero python dude and I believe he has a couple different nicks 
10:02:25 <drflashd[m]> why moner-blockchain-export if data.mdb copy could suffice?
10:04:21 <moneromooo> So that data may be verified by the recipient.
10:05:43 <drflashd[m]> moneromooo: regards? since it is a hashed chain bits would be discovered anyway
10:06:49 <moneromooo> I do not understand.
10:09:41 <drflashd[m]> moneromooo: the 'Previous Block Hash' ensures data integrity, what 'verify' u talkin?
10:10:36 <moneromooo> This is self contradictory, I think.
10:11:16 <moneromooo> If I give you a file and a hash, which I claim is a hash of that file, are you going to bet millions it is a hash of that file without verifying ?
10:11:49 <moneromooo> If no, why do you think it'd be different here ? If yes, I can send you a file and hash now.
10:12:24 <moneromooo> Unless I misunderstood your point.
10:16:06 <drflashd[m]> moneromooo: i can hash copy of data.mdb as well as the export, there is no difference. 
10:16:06 <drflashd[m]> in both cases the chain can be walked and hashes calculated
10:16:34 <drflashd[m]> > <@moneromooo:libera.chat> If no, why do you think it'd be different here ? If yes, I can send you a file and hash now.
10:16:34 <drflashd[m]>  * i can hash the copy of data.mdb as well as the export, there is no difference.
10:16:34 <drflashd[m]> in both cases the chain can be walked and hashes calculated
10:17:24 <moneromooo> I think I understand. If Alice gives Bob a copy of data.mdb and its hash, and if Bob trusts Alice, then Bob can verify the hash to check no error was made in the copy.
10:17:35 <moneromooo> But the export tool is made for use when Bob does not trust Alice.
10:18:49 <moneromooo> ie, it matters whether the errors are random chance (in which case a simple hash of the binary blob will pick it up with ~100% certainty) or malicious (in which case Alice will supply the hash of the malicious data).
10:19:33 <drflashd[m]> how does the export tool counter a forged chain/hash from malice then?
10:19:35 <moneromooo> So that's why Bob has to "walk the chain" as you say.
10:20:00 <moneromooo> By putting the data in a format where it can be verified by the importer.
10:21:12 <drflashd[m]> moneromooo: if the exporter can do the transformation, so can the importer himself do the export/import. 
10:21:12 <drflashd[m]> what transform is done via export rlly?
10:21:40 <moneromooo> Mainly, dump all data except block and tx blobs.
10:22:37 <moneromooo> Technically, you could verify from an untrusted data.mdb, but it'd involve a massive amount of extra code and complexity.
10:22:40 <drflashd[m]> do you mean: the exporter need not be trusted using the export tool?
10:23:05 <moneromooo> The exported does not need to be trusted. The imorter does need to be,
10:23:10 <moneromooo> The exporter does not need to be trusted. The imorter does need to be.
10:23:47 <moneromooo> The exporter exports the minimum of data that's needed (basically the same format you'd get via the network, but framed).
10:24:24 <moneromooo> All the extra sorted/duplicated/databased stuff is dumped, and the importer will recreate it - correctly.
10:24:53 <moneromooo> Hence eschewing the need to verify all data extra data.
10:25:03 <moneromooo> all *that* extra data.
10:26:08 <moneromooo> I don't know if you know it, but data.mdb contained not only the tx/block data, but a number of tables with sorted/indexed data derived from those, in a way that's easy/fast to lookup.
10:26:56 <moneromooo> And that can be recreated from the tx/block blobs.
10:26:58 <drflashd[m]> is that index correlated to local wallet (tx of interest prio sorting eg) ?
10:27:04 <moneromooo> No.
10:46:06 <drflashd[m]> is xmr post quant secure? have seen  https://www.youtube.com/watch?v=j02QoI4ZlnU
10:47:37 <moneromooo> Depends what parts. There was a stocktake, and a report about it. I don't have a link though.
10:47:58 <moneromooo> IIRC some parts are good and some have varying degrees of not good.
11:04:03 <drflashd[m]> <moneromooo> "IIRC some parts are good and..." <- can transaction graph be deanon?
11:04:35 <drflashd[m]> A sent B and not the other 10 ring members. 
11:07:11 <moneromooo> I don't remember which parts have which flaws. Try looking up: monero quantum plus the nick of the person who did this, escapes me right now....  I'll tell you if I remember.
11:08:13 <moneromooo> Ah: isthmus
11:09:11 <drflashd[m]> where the heck is the paper https://ccs.getmonero.org/proposals/research-post-quantum-monero.html
11:09:21 <drflashd[m]> you only have CCs but where the f is the linked result
11:09:26 <drflashd[m]> this is retarded design
11:14:32 <nikg83[m]> https://github.com/insight-decentralized-consensus-lab/post-quantum-monero
11:24:17 <drflashd[m]> <nikg83[m]> "https://github.com/insight-..." <- specific this https://github.com/insight-decentralized-consensus-lab/post-quantum-monero/blob/master/writeups/semitechnical_summary.MD
11:24:46 <drflashd[m]> alias wrecked. 
11:24:47 <drflashd[m]>  * alias  privacy wrecked. 
15:48:50 <isthmus> Updates were posted to the CCS as research progressed. Since then, the CCS UI has been updated so that the update comments are no longer on the main landing page. The results are here:
15:48:50 <isthmus> Nontechnical abstract: https://github.com/insight-decentralized-consensus-lab/post-quantum-monero/blob/master/writeups/nontechnical_abstract.MD
15:48:50 <isthmus> Semitechnical summary: https://github.com/insight-decentralized-consensus-lab/post-quantum-monero/blob/master/writeups/semitechnical_summary.MD
15:48:50 <isthmus> Technical notes: https://github.com/insight-decentralized-consensus-lab/post-quantum-monero/blob/master/writeups/technical_note.pdf
17:43:31 <M8guru[m]> is there simple documentation/a place for discussion about the expected effects of the emissions change in a few months?
17:46:04 <hyc> what emissions change?
17:46:13 <moneromooo> I was trying to express... that :D
17:47:39 <moneromooo> Is it when the block reward gets stuck at .6 maybe ? Shouldn't be too long now.
17:48:04 <sech1> https://p2pool.io/tail.html
17:48:04 <moneromooo> If so, given it's going down slow, it should not change anything really.
17:50:04 <hyc> let's discuss the effects of the lack of change in emissions in a few months ...
17:51:05 <M8guru[m]> sech1: thank you! so the effect won't be large, I did not know the gap was so small with the current block reward.
17:51:51 <M8guru[m]> hyc: what is the status of developing an alternative reward mechanism? is it related to the quantum resistance docs above?
17:52:12 <moneromooo> There is no alternative reward mechanism.
17:53:34 <M8guru[m]> that was my understanding so far too, thank you. so in May, Monero will become the first widely distributed PoW blockchain to be in its tail emission stage. is that right?
17:53:45 <hyc> june
17:54:01 <M8guru[m]> due mainly to a much shorter block time compared to the comparables?
17:54:13 <hyc> doesn't doge or something already have perpetual emission?
17:54:23 <moneromooo> IIRC dogecoin has a tail emission, and it's an old cryptocurrency, so it might be there already ? If not, I think monero would be the first, yes.
17:54:53 <moneromooo> Though I believe Grin has a constant emission, so you could consider this a tail emission from 0.
17:55:31 <moneromooo> Oh wait. Ducknote! :D
17:55:37 <moneromooo> I loved that name.
17:55:45 <moneromooo> IIRC they had a tail at 300. Years ago.
17:56:05 <moneromooo> The downward slope was wheeeeee IIRC.
17:56:07 <hyc> block 300? interesting choice
17:56:27 <moneromooo> No, 300 ducknotes. I think. Maybe.
17:56:33 <hyc> ah
17:56:43 <moneromooo> From a start of 300k or 600k I think.
17:57:04 <moneromooo> Within a few years. Maybe 2. My memory's super hazy, but it was fast.
17:57:16 <moneromooo> The name was rad though.
17:57:28 <hyc> ducknote? sounds like a bunch of quacks
17:57:51 <moneromooo> Might be right :D
18:01:39 <moneromooo> Two months till tail emission. It always seemed so far away...
18:02:13 <moneromooo> Well, we survived ^_^ Congrats everyone :D
18:02:40 <hyc> :)
18:02:56 <moneromooo> if rfree and tewinget are around, cheers to you guys also :D
18:07:00 <hyc> rfree? doesn't ring any bells
18:07:28 <hyc> must be before my time
18:11:03 <jeffro256[m]> selsta regarding rebasing #8223 and #8228, did you mean squash them both individually, or combine the PRs?
18:11:30 <selsta> jeffro256[m]: squash both individually, not rebasing
18:12:01 <selsta> so that it's a single commit, the others are just review related that don't have to be separate commits
18:12:43 <jeffro256[m]> Ok cool that's what I thought you meant, just wanted to make sure 
18:23:39 <rbrunner> Isn't the CLI wallet `sweep_unmixable` command supposed to produce a tx with a rct output?
18:28:20 <selsta> .merge+ 8223
18:28:20 <xmr-pr> Added
18:47:21 <rbrunner> I tried to arrange and test spending pre-RingCT outputs, but failed somehow, as for me `sweep_unmixable` resulted again in a transaction with many outputs with denominations
18:47:38 <rbrunner> Which then again are not spendable in the "normal" way
18:48:16 <rbrunner> But if that command is known to work I probably did something work in preparing my wallets and doctoring fork heights for my offline daemon
18:48:25 <rbrunner> *did something wrong
18:48:26 <UkoeHB> is there sweep_mixable or something? iirc there are 2 transition points
18:49:15 <rbrunner> I see only `sweep_unmixable` in the current CLI wallet
18:50:24 <UkoeHB> my guess is sweep_unmixable turns non-denominated outputs into denominated outputs, which then have to be converted to ringct outputs
18:50:31 <moneromooo> IIRC, sweep_unmixable makes a v1 tx, but will not create dust.
18:50:41 <moneromooo> So its ouputs are spendable in a v2 tx.
18:52:00 <rbrunner> Well, if I try to spend the outputs of `sweep_unmixable` with the normal `transfer` command, it balks and tells me to use `sweep_unmixable` again
18:52:08 <rbrunner> Would you say that's expected?
18:52:09 <moneromooo> And... I forget why non dust outs are spendable in v2 but dust aren't...
18:52:36 <moneromooo> Could be because the value is too small to pay for the fee ?
18:52:49 <rbrunner> Er, no, I try to spend over 50 XMR
18:53:11 <moneromooo> Then maybe it tells you more and you omitted that ?
18:53:23 <rbrunner> It had to produce so many denominations exactly because the amount was so "strange" after deducting the fee :)
18:54:22 <rbrunner> https://paste.debian.net/1236190/
18:55:09 <moneromooo> It tells you: not enough outputs for specified ring size = 11:
18:55:19 <rbrunner> Despite that small height I am already at V14 because of "doctored" fork heights
18:55:28 <moneromooo> You seem to have at least one output of uncommon denomination.
18:56:15 <rbrunner> Isn't that exactly one of the problems that this special command is supposed to solve?
18:56:25 <moneromooo> And it then tell you which one: 50, 2 found.
18:56:56 <moneromooo> Yes. Bug maybe.
18:57:00 <moneromooo> Oh.
18:57:14 <moneromooo> It spends unmixable, but creates unmixable too :D
18:57:29 <moneromooo> It's just very unlikely in actula mainnet.
18:57:34 <rbrunner> Yeah, that's also what I believe to see.
18:58:20 <rbrunner> Why does it not simply create a single RingCT output and be over it all?
18:58:22 <moneromooo> Fixing this would be... a bit hairy. You'd have to split an arbitrary amount into a set of denominations, each of which has >= 10 amounts on hte chain.
18:58:35 <moneromooo> I do not remember.
18:58:49 <moneromooo> Oh, I do now:
18:58:59 <moneromooo> v2 txes do need a ring with > 1 size.
18:59:19 <rbrunner> Alright. So the "trick" would be to spend smaller amounts, that find their "necessary partners" in the chain somewhere? Because common enough?
18:59:20 <moneromooo> So it *might* work with the output has more than 1 and fewer than 11 instances.
18:59:38 <moneromooo> But most unmixable outputs have just themselves for that amojunt.
18:59:58 <moneromooo> So not worth the bother I guess.
19:00:16 <moneromooo> But I think it could theoretically be done.
19:01:26 <rbrunner> It's on testnet, and with a low blockheight, so there may well be damned few outputs with particular amounts.
19:02:09 <rbrunner> Not a very realistic test, then.
19:02:29 <rbrunner> Unimportant edge case :)
19:03:30 <rbrunner> I wonder how much effort it will take to make such outputs spendable with Seraphis ...
19:04:15 <rbrunner> Maybe UkoeHB did already brainstorm about that?
19:05:11 <UkoeHB> can't be done with seraphis directly, but you could do this https://github.com/monero-project/research-lab/issues/59
19:05:31 <UkoeHB> err well I guess you could do it with seraphis too
19:06:00 <UkoeHB> it's just treating those outputs as generic ringct outputs, so a ringct -> seraphis tx could spend them
19:08:42 <rbrunner> From your linked issue: "In protocol v1 output amounts were communicated in clear text, much like the class of Bitcoin-esque currencies."
19:08:47 <rbrunner> Is that true?
19:09:11 <rbrunner> This is a V1 tx: https://xmrchain.net/tx/4e033b4209eb7e209739d02454480a45356a12e6d8bf0e0b6c98b72f93540ab6
19:09:57 <UkoeHB> look at the amount column
19:10:02 <rbrunner> I also have to quote the next sentence: "Then in v2-v3 these output amounts were split into denominations with a separate output for each chunk, say for 
19:10:23 <rbrunner> I mean, we have here a V1 tx which is already split into denominations, as far as I can see
19:10:39 <UkoeHB> that says tx version 1, I was referring to hardfork v1
19:10:46 <UkoeHB> isn't there a tx version 0?
19:11:13 <moneromooo> We just have v1 and v2.
19:11:16 <moneromooo> no 0 nor 3.
19:11:21 <UkoeHB> hmm
19:11:29 <rbrunner> Hmm, now I am fully confused. I went well below the v1 hardfork height with a block height of around 20,000
19:12:02 <moneromooo> Oh. If you mean block versions, not tx versions, we have 1-15 or so.
19:12:08 <UkoeHB> maybe I made a mistake in my research
19:12:37 <rbrunner> But that does problably not invalidate your idea, right?
19:13:06 <UkoeHB> it doesn't
19:13:17 <rbrunner> Alright :)
19:13:47 <rbrunner> By the way, nothing wrong or so, I am just poking around a bit in an effort to learn, caused by a review of jberman's ringsize 16 PR
19:15:08 <rbrunner> It's amazing how much "cruft" already accumulated, and the system can still produce those txs with denominations, surprising in a way
19:15:52 <UkoeHB> the genesis block doesn't have denominations, were denominations really around from the very start?
19:16:04 <moneromooo> Yes.
19:17:11 <rbrunner> I saw today block rewards of over 34 XMR, at height 20,000, and got jealous: Why I did not stumble over Monero earlier, I would probably be rich now :)
19:18:13 <UkoeHB> lol there are definitely some monero wales out there...
19:18:19 <UkoeHB> whales*
19:18:32 <moneromooo> I would rather have found Bekshire Hathaway at the start.
19:18:54 <rbrunner> Or knowing how successful Apple would become ...
19:19:19 <moneromooo> Bitcoin might actually be even better than Bershire...
19:19:32 <monerobull[m]> I want access to the medallion fund 
19:19:51 <monerobull[m]> moneromooo: Highest percentage gain in the past decade wasnt actually Bitcoin
19:20:12 <moneromooo> Hopefully it wasn't a scamcoin, but I wouldn't bet on it...
19:20:29 <monerobull[m]> https://csgoskins.gg/items/sticker-titan-holo-katowice-2014 it's these 
19:21:05 <monerobull[m]> This isn't for Dev though, let's stop
19:21:44 <rbrunner> Ok :)
19:21:51 <moneromooo> You're right, sorry :D
19:54:15 <jeffro256[m]> Hey EPEE Sections can be nested with the type code SERIALIZE_TYPE_OBJECT right?
23:34:30 <selsta> .merges
23:34:30 -xmr-pr- 7936 7937 8053 8166 8177 8179 8180 8195 8196 8197 8205 8207 8211 8212 8213 8215 8222 8223
23:49:34 <upp> i think the block reward right now is moneros biggest weakness
23:50:16 <upp> only people motivated to mine are enthisiasts willing to take a loss, malware perveyors, and attackers like big governments
23:50:30 <upp> thats equation does not balance out in our favor i think
23:50:53 <upp> enthusiasts*
23:52:30 <upp> if only could think things through more thoroughly and start over at the beginning
23:52:41 <merope> upp: then you need to study the economics a bit more. Also, this topic is better suited to #monero:monero.social :) This channel is for actual development work
23:53:00 <merope> Oh, you're on libera
23:53:06 <merope> #monero then
23:53:27 <upp> yeah, i saw block rewards mentioned like 5 comments ago
23:53:57 <upp> but i know that freenode/libera people are more than happy to spend > 50% of the chat content on telling people that their one or two sentences shouldnt be said here, they should be said in another channel
23:54:01 <upp> keep wasting time on that
23:54:54 <upp> im sure it helps
23:57:35 <upp> im also sure it engenders respect and community among the handful of people interested in a particular subject
23:57:51 <upp> clearly you are sure of that also
23:58:34 <merope> It actually does, especially when people don't spam in response to that :) Either way, you need to understand the concept of mining profitability, and that the block reward is a fixed parameter for a good reason
23:59:02 <upp> i know im not an expert
23:59:08 <upp> just saying what it seems like
23:59:09 <merope> Bumping up the block reward would screw with the economics of the coin big time in several ways
23:59:11 <upp> am i really that far off?
23:59:24 <merope> Yes