01:06 <jberman[m]> I was planning to include more detailed figures on tx uniformity impact there within the next 8 hours <-- any update on this and your other message?

Sorry still working on 7798, nearing completion

The authors of the paper are getting back to me on the discrepancy of gamma shape, I don't have a timeline on that at this point. But I gave a harder look at the numbers, and the discrepancy is so small that I don't think that it should hold anything back. So that is good

no problem

thanks for the update

np :)

john_r366: yeah, automatic recurring payments are something I've been wanting, figured others might benefit from me taking a swipe at writing it, so I thought I'd ask

still need to work out a lot of details and edge cases though (what happens if a payment is missed if monerod was stopped, for instance)

selsta luigi1111 sech1 added my analysis to 7798 (monero-project/monero #7798#issuecomment-892293024). Basic summary: I think the fix of 7821 is good enough to select more recent outputs, and the risk posed by altering tx uniformity further in 7798 is unnecessary. So I'm still in favor of changing that PR

why is the simulation in 7821 so spiky? It kinda seems broken off-hand

Because the algo also factors in block density. When blocks have more outputs in them, they are more likely to be selected. It smoothens out over a wider block interval, but when simulating at a single height it’s expected to be spiky like that for that reason

Like for example: if block height 15 has 100 outputs, and block height 16 has 1, then block height 16 will have a very low y value, and block 15 will have a spike

I ran the simulation at 2412241, so you can go back starting from 2412231 and see that # of outputs in each block corroborates the spikes

ah ok

seems like it'd be better to run synthetically in that case, at least for the visual chart purpose

like plot on that chart the output count in each block?

like use smooth synthetic data so you can see how the distribution looks "on average" instead of at some particular block height

Ah ya. Agreed that would’ve been preferable, just would’ve taken a fair amount of time to implement correctly, and this seemed to do the trick to give the answers needed for the purposes of these PR’s. I want to implement a tool that does that (simulates get_outs over a block range), it would also be useful to give a better idea of how solid ring selection is/has been generally

Hi guys I really need help. My monero gui wallet on tails won’t connect to node. Says connecting/disconnected. I have transferred funds and realised after I sent that my daemon wasn’t connected. Please help

I’m using a remote node. I’m just afraid I might have lost my monero. Praying that I haven’t and can resolve this issue

Funds should only go to the destination address you pasted into your wallet, a remote node can’t modify where your Monero goes. Sounds like you’re good to me. Check #monero for support help, this channel is supposed to be for discussing the code

@luigi1111w Actually for PR 7821, it wouldn’t be preferable. I specifically chose that height to show that the client wasn’t selecting decoys from heights 10 and 11, to show that it would never be able to hide outputs spent from those blocks

Then you can see in the fix, it does select decoys from those blocks

If that chart in particular had been a smoothed average, you wouldn’t be able to see how the fix patches that issue

*to show that it would never be able to hide outputs spent from those blocks, if they are spent within 10-11 blocks

hmm, ok, but how do you know it doesn't hide problems with a different real set? ^_^

hide *other problems

because that chart shows it's behaving as expected (plus I've run it at different heights and sanity checked), and the logic below explains the math behind why it looks like that. I agree an additional chart would give more evidence, though. It would probably add a day or 2 of work, which I don't mind :)

yeah the first block is definitely the intuitive outlier.

oh one other thing: I agree distribution should start at tip, but it's not obvious to me that they should be dumped on the first available block vs smoothed in over n blocks, but maybe that's been considered and covered and I missed it

no not covered, starting with the first available block was my own assumption. Looking back to when outputs could be spent between 0-10 blocks, it just seemed to me like a user looking to spend that quickly would be looking to spend as quickly as possible today. Do you think alternatively it should be something like: if a user spent an output 8 blocks old, that indicates they would spend an output 18 blocks old today? Or that it should be

spread randomly over the block range 10-20? To me it just seemed most intuitive to go with the first available block

"If a user spent an output 8 blocks old back when it was possible, they're likely a user trying to spend ASAP today right at the unlock time" was my logic

also it actually doesn't dump on 1st available block, it does smooth it out based on density. If blocks 10, 11, 12 all have 40 outputs, then it would randomly pick between them with equal probability today

this way if block 10 is tiny, it doesn't just dump in there

I can kind of follow that reasoning. In other words, since decoys are supposed to model 'hypothetical real spends', anyone who 'hypothetically wants to spend in first 10 blocks' has to wait until block 10.

Right, yep

The gamma distribution is based on real spend data, from when people could and did actually spend in the first 10 blocks. So this seemed to me like the most intuitive way to account for that known data when choosing the 'hypothetical real spends'

but will the hypothetical user send their transaction "immediately" when it's unlocked? or just "soon"? I was thinking closer to 2 or 3 blocks vs 10 though

ya that I'm not sure. I could set up something like the paper to deduce the early spends from this issue, and perhaps there would be enough data there to give an answer to this question

it probably does make sense to use a wider window than 1 block there, rather than dump it all early on. I do follow that reasoning

<jberman[m]> "ya that I'm not sure. I could se" <- this makes me want to throw up, but I'll get started on it and see how it goes

moneromooo FYI (tried to PM you but i think you are offline): haveno-dex/haveno #103

FWIW, it's probably not that easy to spend an output in the first block it can be, since there is some delay for a tx to be made once the wallet has refreshed to the block right before that, and that once that tx is relayed, it might not find its way into a block template for some seconds.

Yeah a 3 or 4 block window after the 10 block unlock makes sense to me for lumping all the "people in a rush" who would otherwise have spent in the first 10 blocks

I guess there is no systematic way of figuring this out though, which is why the distribution is based on empirical data in the first place

<wfaressuissia[m]> ""ccache: error: execv of /home/..." <- make depends target=x86_64-unknown-freebsd

and before:

sudo apt install clang-8 gperf cmake python3-zmq libdbus-1-dev libharfbuzz-dev

and of course remove the extra checks inf FindCCache.cmake. Just assume that ccache works and let the script it.

*let the script set it.

"monero-project/monero #6452#issuecomment-614670232", "travis-ci.org/github/monero-project/monero/jobs/675745041#L1575", can you google this error "Exec format error" ?

"make depends target=x86_64-unknown-freebsd"it was already tested and it works with proper fix.

wfaressuissia[m]: do you see if the ccache is really working after make clean and make?

Also selsta was reporting some problems under Mac OSX. It could have however sth to do with the superfluous ccache check.

ccache works everywhere without any extra steps

Then I think you're all set.

The last thing is to let the CI check it.

"duckduckgo.com/?q=Exec+format+error&t=h_&ia=web" the first link in search says how to fix the problem

there was no need to add any cmake workaround

I've recently been adding the ability for a sender to store 31.5 bytes of data in outgoing txes, recoverable by the sender only.

When I started, I thought the recipient could recover it, but it turns out not to be the case, but it's still useful probably.

However, I've hit a bit of a snag which requires discussion.

The basic system works, but it needs the recipient to know the tx secret key in order to derive all the values needed to decrypt those bytes.

So the tx secret key would need to be deterministically derived (I was thinking from spend secret key and key image of the first ring).

sarang mentioned such a change would need thorough discussion first to make sure this does not open a vuln somewhere.

So if people with a clue about crypto want to think about this, please do :)

The sender would also need the recipient public view key to derive the shared secret :(

That one seems to be a blocker. Maybe I should just abandon that and switch to the triptych one and hope it fits better...

What is the use case of this extra transaction data?

bloating the blockchain :D

I think the idea is to have a primitive form of messaging, similar to adding a description to a Zelle transfer so your friend can know why you sent the money (like "for pizza last Friday"). If my guess is correct, I'm interested in having this functionality too.

wfaressuissia[m]: are you planning to make a PR for this?

I think moooo is working on something like this for Townforge. Might be only to transmit messages, not coins, though.

I recall that he said that no one who is not party to the message will even know that a message has been sent.

BusyBoredom[m] my 2c is that sort of thing is better handled other ways instead of storing on the blockchain forever

mj-xmr[m]: the Mac problem was related to incorrectly calling the compiler in cmake ccache check

it's not directly ccache related

selsta: before we merge the improved the ccache script, I will ask you to check this locally.

nothing mac related will change but will test

That can't be used to send a message, only the sender can recover the data.

I did not realize it at the time though.

The secondary intent was to store the secret tx key, but this turns out to be impossible since retrieving the value needs that key.

And now it looks like it's not much use after all.

For TF hidden messages, I was also planning to use that, among other things.

But can't now for the same reason.

Maybe the triptych version will be actually usable.

Just opened an issue about the wagner attack on monero multisig about the wagner attack: monero-project/monero #7830

What is the Wagner attack? This is the first I'm hearing of it

selsta: When you find time, plz check under your OSX:

will do

"monero-project/monero #7832" it doesn't remove ccache detection test correctly

and since the test is correct and general purpose it isn't necessary to remove it

and there is no such as "under Freebsd" since it's cross compilation within ubuntu:18.04 for all target platformss, it isn't something specific to freebsd at all

wfaressuissia[m]: would you mind commenting on the PR directly instead of in IRC? Or are comments still restricted?

<wfaressuissia[m]> ""github.com/monero-..." <- The test was what actually caused selsta 's OSX build to fail.

no, we fixed that

that test was incorrect previously

I meant my version was wrong.

not really incorrect just some compiler didn't like calling directly

so cmake had to be use to set the compiler correctly

ok. I will check if everything works well in this form, and then bring back the better version of test.

(the 2nd one, that I've just removed)

"paste.debian.net/hidden/522b517e" double check completed, thanks for participation

"... Or are comments still restricted?" yes, so IRC is a bit less censored than github now.

it got turned off