-
luigi1111w
.merges
-
xmr-pr
7873 7874 7886 7890 7891 7911 7917 7923 7925 7928 7929 7930 7933 7934 7942 7945 7952 7961 7964
-
luigi1111w
vtnerd would you mind approving 7873 if your comments have been addressed sufficiently?
-
selsta
they were addressed
-
selsta
or wait, hmm
-
selsta
yes, they were addresses
-
selsta
github ui seems buggy
-
luigi1111w
I demand rubber stamp
-
selsta
...
-
selsta
ok
-
luigi1111w
-
luigi1111w
should 7910 be merged?
-
selsta
let's do it next time
-
luigi1111w
hello it's me, next time
-
selsta
still want to check something with 7910 so I removed it for now
-
luigi1111w
ok bye
-
selsta
q.q
-
luigi1111w
<3
-
selsta
zoomer loogi
-
luigi1111w
zoomer whisperer
-
tauntaum
hello
-
tauntaum
-
tauntaum
wfaressuissia here?
-
sech1
7803 and 7891 conflict only in cryptonote_core.cpp (lines 1066-1067)
-
sech1
the other conflict is with something else
-
sech1
cryptonote_core.cpp conflict seems to be easy to solve
-
tauntaum
why 7803 is not inserted yet
-
sech1
don't ask me
-
tauntaum
strange because is very important
-
tauntaum
src/wallet/wallet2.cpp line 2967 conflict too
-
hyc
is there going to be another 0.17 release?
-
hyc
if so, some PRs recently merged to master prob should also be in release branch
-
rbrunner
I try to get an understanding of the high-level structure and working of wallet2::refresh, and run into a number of puzzling questions, like this one:
-
rbrunner
The method first get the pool transactions from the daemon, but does not yet process them
-
rbrunner
Then it fetches blocks from the blockchain that it does not yet have
-
rbrunner
Finally it processes the pool transactions that it got in the first step
-
rbrunner
The question that pops up: Assuming that fetching and processing blocks from the blockchain can take any amount of time, because there are many to fetch
-
rbrunner
Aren't the pool transactions from the first step pretty outdated when the method finally gets around to process them?
-
rbrunner
Maybe they are, but it does not matter because soon we will refresh again, and get again pool transactions?
-
rbrunner
Or is my assumption wrong that the second step may take a long time, because that will always be an incremental refresh with a small number of blocks, say single-digits?
-
BigmenPixel[m]
hi. is there any plans to support wayland protocol?
-
BigmenPixel[m]
?
-
BigmenPixel[m]
* hi. is there any plans to support wayland protocol?
-
moneromooo
IIRC there was a timing issue that required reordering things. Improve if you can.
-
moneromooo
Wayland is in... windowing server ?
-
moneromooo
If so, doesn't apply to monero. Might apply to various Monero using programs, ask them.
-
rbrunner
There is also an interesting comment there concerning a privacy leak if the pool transactions are processed right away, yes
-
BigmenPixel[m]
moneromooo: yes
-
rbrunner
I am on the way with an attempt to improve things, by implementing a new RPC call that basically fetches the pool *and* blocks together, in one go
-
rbrunner
But it proves tricky to find out how this will influence and change current structure of wallet2::refresh
-
rbrunner
And without having a basic grasp what the thing does it's probably pretty hopeless :)
-
rbrunner
I think I will have a look using log outputs how many blocks the second step I mention typically has to get, to further my understanding.
-
Rucknium[m]
rbrunner: Does the issue you are looking at affect mixin selection for construction of transactions?
-
rbrunner
Most probably not. It's the syncing part of the wallet, nowhere near any tx construction.
-
rbrunner
Speeding up syncing by compressing 4 RPC roundtrips to the daemon into one:
monero-project/monero #7571
-
Rucknium[m]
rbrunner: A wallet cannot construct a tx until it is fully synced up to the current block height, right?
-
rbrunner
Think so, yes.
-
rbrunner
Well, technically it could of course, but it does not, as far as I know, and insists on syncing to top first
-
Rucknium[m]
But the reference wallet enforces this? If the wallet doesn't wait, then the mixins will effectively come from older blocks than they should come from.
-
rbrunner
Yes, it is enforced as far I know. Just could not point you the exact lines in code just like that ...
-
rbrunner
Exactly because of the problem that you mention
-
Rucknium[m]
Of course, other wallets are not necessarily constrained in this way.
-
rbrunner
Quite in general, I better not mess wallet sync with anything I do. I plan to do some careful testing after implementing.
-
rbrunner
I would suspect that check in wallet2 already, and that's pretty hard to avoid.
-
jerfo
Hey is anyone having problems with some monerod log messages not showing up, especiialy when built in debug mode ?
-
Rucknium[m]
We suspect, based on some evidence, that there are "rogue wallets" operating out there.
-
Rucknium[m]
We being jberman, myself, isthmus, probably others.
-
rbrunner
Yeah, I just synced my daemon half an hour ago, and what do I get somewhere on the way? "Transaction spends at least one output which is too young"
-
rbrunner
I see what you mean. Would of course be quite easy to doctor wallet2, compile, and have fun.
-
Rucknium[m]
That's the 10 block restriction?
-
rbrunner
Think so, yes.
-
jerfo
rbrunner: blocks w/ txs that have outputs that are too young are invalid, correct?
-
rbrunner
Hmm, suddenly not sure. Maybe that tx is only in the pool, somehow hard to believe that we would have invalid blocks because of this.
-
rbrunner
By the way, can't wait to read details about the results of the tx flood analysis :)
-
jerfo
Oh yeah, who's doing that?
-
rbrunner
Or such a tx *tried* to enter the pool but was rejected by my daemon.
-
rbrunner
Can't let such a thing get very far, right?
-
Rucknium[m]
jerfo: The tx flood analysis? Isthmus, Neptune, myself, jberman, and Carrington
-
Rucknium[m]
gingeropolous helped too, mostly with hardware support.
-
jerfo
rbrunner: yeah I assume the message is generated when the tx enters the pool, and the daemon is effectively warning that it will have to sit in timeout until the outputs mature
-
jerfo
Ruckinum: that's awesome! What hardware support was needed?
-
rbrunner
That will be better than CSI on TV :)
-
Rucknium[m]
jerfo: It's gigabytes of data. Need to extract certain data from the blockchain and manipulate it
-
rbrunner
jerfo: After some quick glance at the code it does look like it's not rejected, yes. But as Rucknium[m] said, makes one wonder who constructed that tx, and how, and why
-
Rucknium[m]
gingeropolous hosts a server, neptune pulls relevant data via
github.com/neptuneresearch/ring-membership-sql I think
-
Rucknium[m]
In fact, gingeropolous is planning to put together a CCS for a more powerful, fully-featured server for greater statistical analysis and so forth.
-
tauntaum
this 2 monero-project/monero #7803 monero-project/monero #7891 has small conflicts
-
Rucknium[m]
If I put a colon in my CCS proposal title, is it going to break something? I suppose I could test by trial and error.
-
luigi1111w
might need to quote the title
-
Rucknium[m]
Backticks or normal ""?
-
luigi1111w
normal
-
luigi1111w
but keeping special stuff out works too
-
luigi1111w
people like to put their name in the title but there's an author field too...
-
Rucknium[m]
My title shall be "OSPEAD: Fortifying Monero Against Statistical Attack"
-
Rucknium[m]
What is OSPEAD, you may ask? You'll have to read the proposal once it is posted :)
-
luigi1111w
k
-
luigi1111w
if it doesn't show up in fr if/when merged we'll figure it out
-
Rucknium[m]
Ok great. Thanks for the tips.
-
gingeropolous
Operational Statistics for Proactive Enhanced Anonymity Development
-
UkoeHB
+1
-
Rucknium[m]
gingeropolous: Wow, that's a pretty good "backronym" 🤔
-
Rucknium[m]
I am actually tempted to change it lol
-
Rucknium[m]
My intended acronym is "Optimal Static Parametric Estimation of Arbitrary Distributions", which doesn't sound as cool as "Operational Statistics for Proactive Enhanced Anonymity Development"
-
gingeropolous
lulz.