-
Shvandrew
Hey everyone, I'm a journalist at Cointelegraph, I was looking to ask a few questions about Tryptych if anyone's available.
-
selsta
Shvandrew: sarang/surae are in US timezone so it’s still early there.
-
selsta
Best to wait in this channel.
-
Shvandrew
Yeah make sense, thanks selsta
-
selsta
Or you can write them an email.
-
Shvandrew
I was never able to find one for MRL members, only core.
-
moneromooo
I'm sure there's an encryption joke in there somewhere...
-
sarang
Hi, I'm one of the authors of the paper
-
sarang
(our emails are listed on it, FWIW)
-
ErCiccione[m]
sarang: would you be ok with putting your emails on getmonero as it is for core?
-
sarang
I thought they were listed
-
ErCiccione[m]
they are not. Only reddit and github
-
sarang
Hmm I see
-
sarang
Shvandrew: how may I help you
-
ErCiccione[m]
i think could be useful in these kind of situaations. Maybe a general "research lab" address instead of multiple single addresses?
-
ErCiccione[m]
or whatever you guys prefer
-
sarang
I could have sworn our getmonero dot org emails were listed... oh well
-
sarang
I prefer protonmail dot com anyway, since it plays more nicely with encryption (something something PGP is bad)
-
Shvandrew
sarang thanks, we actually spoke before for the 0x OpenZKP stuff, you've been a great help. Anyway, for Triptych I was curious about the more practical matters since we do have a fairly lay audience. Specifically: How realistic is it to see Triptych implemented live, and in how long? You've mentioned you're working on even better stuff, does that
-
Shvandrew
involve logarithmic verification or it's minor upgrades?
-
sarang
I can't reasonably speculate on the likelihood of projects implemented Triptych, since it's still early work that has not undergone any formal review (preprints do not need any kind of review before being submitted to preprint archives)
-
sarang
The other version of Triptych that we're working on would allow for signing with multiple keys in the same proof, while also directly including a balance test, leading to even smaller overall transactions
-
sarang
However, verification is still linear (up to multiscalar multiplication optimizations and batching, which help this)
-
sarang
That version of Triptych is not quite ready yet due to some technical questions that aren't answered yet
-
Shvandrew
Thanks. So as I understand the point of Triptych is to reduce size of ring signatures to be able to increase the anonymity set. You need to strike a balance between anonymity, verification speed and size here, right?
-
sarang
Yep, that's the idea. Triptych is one of several newer constructions with such a goal.
-
Shvandrew
How important do you think this goal is? Would you say that the current ring size is at least partially inadequate in providing a good anonymity set? I'm especially curious for another article of mine on privacy coins in general. Basically I'm looking for a reply to fireice's claims that A. churning is ineffective and B. metadata leaks are a huge
-
Shvandrew
issue.
-
sarang
That's a subtle question that depends highly on particular threat models, and doesn't have an easy answer
-
koe
lol fireice
-
sarang
There's network-level metadata floating around, which may or may not affect a particular user depending on their threat model (and is tricky to reduce)
-
sarang
There's on-chain metadata floating around (including things like timing, input/output structure, non-standard transaction data, etc.)
-
sarang
Reducing exploitable metadata is important, but eliminating it entirely is impossible
-
koe
I liked what surae mentioned in his konferenco speech, that different levels of anonymity/plausible deniability have different meanings depending on who the 'adversary' is
-
sarang
Yeah, it's very important to keep the threat model in mind; and this can vary
-
koe
some adversaries will only act with high levels of certainty, while others aren't as concerned with making mistakes
-
sarang
The downside is that it's difficult to convey this subtlety
-
sarang
Some things, like fixing the ring size, are relatively easy ways to mitigate distinguishability
-
sarang
Other things, like trying for a completely uniform transaction structure or getting rid of network-level metadata, are extremely challenging (or likely not possible in their entirety)
-
sarang
That being said, being able to increase the size of the input anonymity set in a big way would be a great step in the right direction
-
sarang
Hence research by many people that's led to constructions like Lelantus, Omniring, RingCT 3.0, Triptych, et al.
-
sarang
Each of these comes equipped with different tradeoffs and security models
-
sarang
I'm sure this is an entirely unsatisfying answer, Shvandrew!
-
koe
Isthmus likes to talk about anonymity puddles within the anonymity system. Different groups that use Monero have different distinguishing features, that is leads to metadata patterns. If someone can be identified as member of one group, it reduces plausible deniability and so on.
-
sarang
Yeah, it's the curse of default-but-not-mandatory aspects to transaction structure
-
koe
The biggest puddle is everyone using the standard implementation, probably
-
Shvandrew
sarang no worries it still works just fine for the article(s). Thanks a lot, should be enough for now. Do you prefer email or IRC for future contact? And can i quote you directly?
-
sarang
Either IRC or email are fine
-
ErCiccione[m]
sarang: ok, so protonmail it is. SuraeNoether could you let me know if it's fine for you as well?
-
sarang
ErCiccione[m]: there are {sarang,surae} at getmonero addresses too, but I happen to like protonmail for its security
-
sarang
I've been inconsistent about which email has gone onto preprints
-
Shvandrew
Although actually one more thing, if you could elaborate on fireice's claims against churning that'd be great. Is it really so easy to trace transactions with his proposed attack?
-
sarang
ErCiccione[m]: I assume the address won't be directly included on the site without some kind of masking, to avoid spam scraping
-
koe
which attack?
-
ErCiccione[m]
Sure, whatever you prefer is fine. I agree better to keep them consistent
-
Shvandrew
-
sarang
Like most aspects of using distributed digital assets, there are better and worse ways to use them; this includes churning
-
koe
final nail, very dramatic!
-
sarang
We're presently working on a graph-theoretic and statistical formalization that tries to address this
-
ErCiccione[m]
sarang: core team have theirs unmasked, but we can change them all to something a bit more soam resistant
-
sarang
Similar to how to choosing decoy inputs poorly can lead to heuristics about what is more likely to be the true signer, churning "badly" could lead to heuristics trying to identify the process
-
sarang
This also depends on what your threat model is, and what the hypothetical adversary is assumed to know
-
Shvandrew
Interesting. What constitutes bad churning though? Like is there a wrong way to send transactions to oneself?
-
sarang
For example, transactions tend to follow certain statistical distributions on inputs that are selected (and this idea has appeared in research for a few years now), so churn transactions should ideally follow this as well to reduce distinguishability
-
sarang
If you were to presume that some hypothetical adversary has additional data on transaction information for whatever reason (ISP, remote node, etc.), then that could change the picture as well
-
sarang
If your transactions bring in additional inputs that could have been identified to you (from an exchange, perhaps), then that could be an additional piece of data
-
sarang
I am not saying that any particular piece of information renders a particular transaction or churn process "broken" or "optimal" here
-
sarang
The point of doing more formalized analysis and simulation is to take these ideas and use them to build models about what information such an adversary could reasonably gain, and how different types of churning help or hurt
-
sarang
It's research that is still very much ongoing
-
Shvandrew
Well I guess it's always easier to deanonymize transactions if you have additional information. Thanks Sarang, now I'm fully satisfied :)
-
sarang
What does "deanonymize" mean in this context?
-
sarang
Even if you were to gain or possess enough information to identify the true signing input(s) of a transaction, this doesn't inherently link to wallet addresses
-
sarang
Once again, back to threat models
-
sarang
Someone who is concerned about an ISP colluding with an exchange probably has a much different threat model than someone just buying coffee
-
sarang
Designing for all possible threat models is exceptionally difficult
-
Shvandrew
I would guess that the primary threat model one thinks about is against government investigations. That is bound to pose the biggest threat level.
-
koe
It's the 'really big gang' threat, who can obtain the records of ISPs and exchanges passively, or interact with you directly in different ways. And also has the technical expertise or financial capability to investigate the blockchain.
-
sarang
What's the goal of the piece you're doing on privacy Shvandrew?
-
koe
Im skeptical about this churn analysis.. isn't churn where you take all your outputs and turn them into one output? Not multiple new outputs? The 'ring' analysis only works if the change output is non-zero, so it actually makes a lot of sense for NON-churn transaction behavior. If you solve the metadata problem I don't see churn being problematic
-
koe
if used properly.
-
sarang
Two outputs is the new minimum
-
koe
right but one can have 0 amount
-
koe
afaik
-
sarang
yep
-
koe
0 amounts never get spent
-
sarang
but they appear in rings
-
sarang
and therefore have an ideally ambiguous "spend state"
-
koe
sure, I'm saying they can't be used for a new branch in a ring analysis (ring in the sense fireice uses it, a ring between transactions)
-
sarang
One reason I like the idea of very large ring sizes is that the use of fixed contiguous output sets means you're more likely to use multiple outputs from a transaction even if they aren't the true signers
-
sech1
unrelated question: if you look in the mempool right now, someone issued 200+ transactions, 120 inputs each. Is it safe to assume they all come from the same wallet?
-
koe
seems weird, someone owns 25000 outputs?
-
sech1
I think block size limit will increase today, look at recent block sizes
-
koe
maybe a big miner? quick go see if there are 25000 unique coinbase inputs spread between them!
-
sech1
how to find coinbase inputs?
-
Shvandrew
@sarang it's a general overview of privacy coins. Specifically I highlight that coinjoin has been already compromised and that stuff like monero and zcash have various compromises on performance or anonymity that make it difficult to say which one is best
-
sarang
I'm curious if you can say (or if we must wait for the article)... what tradeoffs do you see with Zcash? Do you mean that shielded operations are optional?
-
koe
can probably find them from the offsets, using rct_offsets
-
sarang
I thought that the earlier research on using amount data to track "temporary shielding" was a fascinating example of how practical use of shielded operations could lead to data leakage
-
Shvandrew
Centralization, large transactions, the conversion step between shielded and unshielded that can introduce vulnerabilities.
-
Shvandrew
I think we're referencing the same research paper for that data leakage
-
sarang
The word originally done with Quesnelle?
-
sarang
*work
-
Shvandrew
Not sure. The paper is from University College London
-
sarang
Hmm, do you have a link? There was early work by Jeff Quesnelle that examined transactions that put funds into the shielded pool and then removed them... a simple amount linking (accounting for fees) could give unique links for a very large fraction of them
-
sarang
I recall someone at UCL mentioned wanting to look into a more recent version of this, but I don't recall seeing results
-
sarang
Also, what parts of transactions are large, in the tradeoff sense you mean?
-
sarang
Sapling proofs are very small, but of course Zcash transactions are not just composed of a Sapling proof
-
Shvandrew
Well shielded transactions are physically just as large as Monero's. Lighter than before but still way bigger than BTC's
-
Shvandrew
-
sarang
Ah, Heuristic 5 in that paper seems to capture the idea of what Quesnelle did
-
sarang
I wonder what data they're using to get the claim I found about a shielded txn being 2 kB
-
sarang
That would depend on the transaction structure
-
sarang
But that's very interesting to see
-
koe
interesting, it looks like these transactions are spending pre-ringct outputs (amounts are in cleartext)
-
koe
apparently max tx size is 100kB, which implies max weight clawback factor is 1.5; does that sound right?
-
sarang
Shvandrew: did you have any other questions, or things to be clarified?
-
Shvandrew
For now no, I'm just keeping the page open for some reason. Article will be published soon
-
sarang
Glad to help
-
suraeNoether
sarang: i'm having a numerical problem with matching and i want to pick your brain
-
sarang
Sure
-
suraeNoether
okay, so originally I was weighting edges of this graph with log likelihood, running from -infty to 0
-
suraeNoether
but the algorithm i use to find maximal matching has to assume all edges exist and the ones that we don't care about have weight 0
-
suraeNoether
so i switched, with 2 weeks of effort, from weighting using sums to weighting using products, and assuming edges that don't exist really are edges with weight zero
-
suraeNoether
or a week i guess
-
sarang
Does this mean the graph is complete?
-
suraeNoether
implicitly; i don't track all edges, but i assume any pair of nodes can count as an edge, and if i'm not yet tracking it, then it has weight 0
-
sarang
Doesn't that blow up immediately?
-
suraeNoether
what do you mean?
-
suraeNoether
do you mean time until matching is complete?
-
sarang
Oh, you're not tracking the zero edges as part of the graph structure
-
suraeNoether
right
-
suraeNoether
otherwise it would be huge yes
-
sarang
No, I meant complete graph in the sense of edges
-
sarang
ya
-
suraeNoether
but likelihood is a number between 0 and 1, and is formed by the products of such numbers, and i'm getting likelihoods smaller than 10^-9 for most edges, and it's getting to the point where i'm concerned about numerical stability in computing these likelihoods.
-
suraeNoether
now that i've talked it out i know what i need to do. :P
-
sarang
-
suraeNoether
so... sarang, thanks for rubby ducking me
-
suraeNoether
yass
-
suraeNoether
we rub ducks here at mrl
-
sarang
o_0
-
sarang
Reminder: research meeting is today at 18:00 UTC (90 minutes from now)
-
sarang
-
sarang
One mistake is that there are 10 per-input decoys, not 24
-
sarang
And users cannot alter this value
-
sarang
I would also not call it a "major innovation"
-
sarang
There have been other logarithmically-scaling proposals that came before
-
sarang
And other solutions have comparable performance
-
sarang
And heck, I'm happy to talk about the technical questions surrounding the other variant of Triptych: it has to do with an equivalence between proof relations
-
midipoet
Triptych: just another logarithmically-scaling proposal to add to the list
-
midipoet
;-)
-
sarang
Hmm, the 100 ms estimate quoted in the article is for Omniring, but with a 2-in-16-out transaction, which isn't really a fair comparison to the info that I gave in the reddit comment
-
sarang
If anyone knows how to contact the author, it'd be nice to clarify these errors
-
sarang
I think it's important to put all this different research into the right context and give credit where it's due
-
sarang
I do, however, still consider Triptych to be a badass name
-
sarang
If the author is on twitter, can someone see if he can get in touch for clarification? I don't see an email listed on the cointelegraph site
-
sarang
(I am not on twitter)
-
binaryFate
sarang I can try to shoot him a PM, provided it is actually him
twitter.com/shvandrew
-
sarang
Cool
-
sarang
The parameter errors are fairly minor, but I think it's important to give accurate credit to the other constructions he mentions in the article
-
binaryFate
But "major innovation" is subjective so I wouldn't bother trying to correct him, that's what journalists need to throw out there. Can correct the factual stuff you mentioned though :)
-
binaryFate
I mean as long as he is not misquoting anyone
-
sarang
Plus the estimates that I gave are very rough and not based on full implementation
-
sarang
He's not misquoting, but I think misinterpreted some data
-
sarang
It makes Triptych look great, but isn't really fair to other work
-
binaryFate
this is cointelegraph not IEEE-telegraph
-
binaryFate
not surprising... Hopefully he can correct the most glaring mistakes or misrepresentations
-
sarang
I want to be technically correct, the best kind of correct
-
sarang
=p
-
sgp_
sarang: what's a better estimate?
-
gingeropolous
triptych is great. will bring us ringsize 1 bajillion
-
sgp_
ah, probably 67
-
sarang
For Omniring (which doesn't support batching), a better number is to use the 2-2 N=128 value of 67.2 ms
-
sarang
And RCT3
-
sarang
Which is 44 ms, basically the same as Triptych for N=512
-
binaryFate
Sarang, from author: "Still, on average confirmation times are higher for other solutions, right?"
-
sarang
The benefit there is size, if you use the non-aggregated (and therefore not input-padded) RCT3
-
sarang
Does he mean verification time, which is not the same as confirmation (as it's usually used)?
-
sarang
RingCT 3.0 has very comparable verification performance for ring sizes of interest
-
sarang
Since those numbers are from a single machine's operation-count test data, the estimates should be considered very rough; drawing precise comparison conclusions from them isn't a good idea
-
sarang
At best it shows they're comparable in expensive group operations
-
sarang
(also note these are only for 2-2 transactions, the most common type)
-
sarang
In case this background is useful, RCT3 is based on the underlying Bulletproofs proving system (with modifications), while Triptych is based on a Groth/Bootle proving system (with modifications)... so while performance is similar, the math is quite different
-
sarang
I find that fact fascinating
-
sarang
I'm also going to update the preprint to make the size and time comparisons more clear, in case that could lead to any confusion
-
sarang
That being said, I appreciate that the article highlighted the research being done in this area :)
-
sarang
Thanks for reaching out binaryFate
-
binaryFate
np. He said he will fixed it (not sure what/how) as soon as he can.
-
binaryFate
*fix
-
sarang
Cool, thanks
-
sarang
He is welcome to stop by this channel or email me with any questions on the data
-
sarang
sarang dot noether at protonmail dot com
-
sarang
Speaking of other constructions... suraeNoether if you're bored later, let me know; I'm trying to hunt down the effects of a possible Omniring math issue using some test code
-
sarang
Trying to avoid doing all the vector algebra by hand since it blows up really quickly
-
sarang
and I'd like to make sure I can reliably pinpoint the issue before asking the authors
-
sarang
Looks like it's time to get started
-
sarang
pinging suraeNoether
-
sarang
GREETINGS to everyone
-
almutasim
Hi.
-
binaryFate
hi hi
-
» Isthmus waves
-
sarang
Let's start with ROUNDTABLE
-
sarang
The preprint for Triptych, a new linkable ring signature construction that can be extended for use in transactions, is on the IACR archive
-
sarang
-
sarang
CoinTelegraph just released an article about it (but note there are some errors in the data presented there, that I'm told will be fixed)
-
sarang
I plan to make an update on the size and time data, to properly account for batch verification and ensure fair comparison
-
sarang
More work was done on the multi-index version of Triptych, fixing soundness in exchange for a separate proof relation that we need to show is equivalent to another proof relation
-
sarang
This would allow even better performance
-
sarang
I worked out an MPC for that version of Triptych as well, which would be useful for multisig
-
sarang
And I'm presently working on some questions relating to Omniring math that I've brought up with that paper's authors
-
sarang
Does anyone else wish to share interesting research work?
-
almutasim
When the time is right, at a key juncture, we could have a press release on Triptych. Monero Outreach could support that. Maybe when it is established that it is going into a release.
-
sarang
To be clear, there are no guarantees that Triptych, or any presently-known construction, is fit for deployment
-
almutasim
Right.
-
Isthmus
I've got some fingerprinting stuff, and n3ptune just completed a pretty cool network analysis
-
sarang
Ooh
-
sarang
Isthmus: what sort of data have you uncovered?
-
Isthmus
Ah my fingerprinting notes are nothing new or exciting, just an idea that might make data presentation more intuitive. So, I tend to think about wallet fingerprinting in a kind of abstract way - every transaction sits at some corner of a hypercube in a high-dimensional space made of different heuristics yadda yaddaaa yadda
-
Isthmus
So even though I work with sets of boolean features on the backend, wanted a good way to show results
-
Isthmus
-
sarang
What, you can't accurately present visualizations of high-dimensional hypercubes? =p
-
Isthmus
llol
-
Isthmus
This is somewhat by @suraeNoether adding human-interpretable output to the graph matching
-
sarang
I like the idea of enumeration like that
-
Isthmus
thanks! It figure it's also an easy way to pass around data in a 2-column CSV chart, and researchers can do substring matching on portions that they find relevant to a given analysis
-
suraeNoether
Ack sorry! I'm here! Time change got me unawares
-
sarang
Isthmus: is there anything to share about the network analysis you mentioned?
-
n3ptune
Re: questions on block propagation timing asked last month, I've collected and analyzed block receipt timing data from our global nodes recorded during the past 6 months
-
sarang
Nice!
-
sarang
What conclusions?
-
n3ptune
Isthmus has notes about interpretation and I have more to write but you can look at the graphs here
github.com/noncesense-research-lab/…network/wiki/Block-propogation-time
-
Isthmus
This was RE a question that @moneromooo asked, right?
-
Isthmus
Units are size in bytes and timestamps in milliseconds, right?
-
suraeNoether
that was my question ^
-
n3ptune
we used this formula where NRT is Node Received Timestamp: prop_time_lower_bound(h) = MAX[NRT(h,1), NRT(h,2), NRT(h,3)] - MIN[NRT(h,1), NRT(h,2), NRT(h,3)]
-
sarang
What are the changing indices there?
-
sarang
Different nodes?
-
sgp_
hello
-
n3ptune
yeah, that goes up to 3 but there are 4 nodes total
-
sarang
got it
-
suraeNoether
so block prop time is reliably at least 0.1s. interesting.
-
Isthmus
Oh scatter heatmap is height from dark=old to light=new
-
Isthmus
^ color scale
-
sarang
And those are the differences between the miner-reported timestamp and the node's wall clock upon receipt?
-
Isthmus
Miner reported timestamps are not considered anywhere in this study
-
Isthmus
But we did that elsewhere
-
» Isthmus digs around github
-
suraeNoether
hm then what is being measured for prop time?
-
sarang
So these are blocks only passed between your nodes?
-
sarang
Where you look at local times on send and receipt?
-
Snipa
^ Was going to ask that, as the min propogation time seems particularly low, as 100msec is quite low in our experience to cross the globe.
-
sarang
Or better question: how is NRT computed
-
n3ptune
it's the difference in timing between different nodes receiving the same blocks
-
sarang
Ah, ok
-
Isthmus
Yea, not passing between our nodes, but passing through our nodes
-
n3ptune
NRT is recorded from the node system time when a block arrives
-
sarang
Independent of the peer from which they receive
-
sarang
(which would differ)
-
sarang
Seeing the difference between miner-reported time (which could be inaccurate) and wall-clock receipt time would also be interesting
-
suraeNoether
hmmmm
-
endogenic
o/
-
Isthmus
-
Isthmus
@sarang just for you
-
sarang
So what we're really seeing here is not propagation time directly, but variability in one layer of propagation time
-
sarang
here = the initial plots, not this one
-
Snipa
I'll have to check pool log data, as I might be able to give some extra data points if you're interested. We started to log the time in which a pool node finds a block, versus when that block is stored into our database, which means it's been processed by the local node, as we skip all monerod timings on the pool itself.
-
suraeNoether
oooop
-
suraeNoether
that's cool
-
sarang
Very high times
-
Isthmus
@Snipa very nice!
-
Isthmus
"So what we're really seeing here is not propagation time directly, but variability in one layer of propagation time" < can you elaborate?
-
suraeNoether
isthmus well it's how long it takes for the block to propagate from one of your nodes to another of your nodes; not time it takes to propagate from a miner to one of your nodes
-
sarang
I mean that for the initial plots you showed, you can't directly interpret the time for the block to reach your node after it's mined
-
sarang
suraeNoether: no
-
suraeNoether
no?
-
Isthmus
Yea, we very deliberately labeled all of the axes "prop time lower bound" for that reason
-
Isthmus
Also, we could always posit that there is an old PC on dialup somewhere in Nebraska with a 4 minute prop time, but that's not meaningful
-
sarang
suraeNoether: it's looking at the difference in receipt time, whichever path the block took in total propagation
-
Snipa
Hrm, auctually, I can provide a data stream of our global block propgations, as every node has a local reporter that we can hook.
-
Isthmus
@Snipa yes please!
-
suraeNoether
sarang that's true also
-
n3ptune
that data would be awesome to work with
-
Isthmus
I'll posit something that might be wrong:
-
Isthmus
It's a hacky data science way of thinking -
-
Snipa
Hit me up a bit later and we can discuss how to get it to you, and go over data formats.
-
Isthmus
Shoot, I gotta get off the bus
-
suraeNoether
isthmus: you have two sensors set up to detect propagation time. but you need 3 to triangulate, ala seismic detection of epicenters
-
» Isthmus sticks a pin in it, and will be back in 3 - 6 min
-
sarang
Don't leave us with that cliffhanger Isthmus!
-
suraeNoether
i'm on the edge of my seat
-
suraeNoether
i spilled my tea
-
suraeNoether
i'm so upset at isthmus right now i could just light myself on fire
-
sarang
Stay on the bus Isthmus... it'll loop back around to your stop eventually
-
sarang
In the meantime, any other interesting tidbits on this work?
-
sarang
This is very interesting data
-
suraeNoether
while we are waiting on Isthmus, I'll give my super-brief update: after some discussions with endo, my matching code has been made significantly more efficient, easy to understand, and easier to debug; i'll be making a push later today. my two categories of work today are re-reviewing CLSAG and working on matching
-
n3ptune
that's it for now, we will update
-
endogenic
his pseudocode now fits onto one sheet of notepad paper..
-
suraeNoether
isthmus and i also technically had a conversation about writing up a proposal to encrypt and enforce all lock times, but we haven't gotten details worked out yet
-
sarang
You mean using DLSAG-style commitments?
-
sarang
We'd discussed it earlier in a meeting
-
suraeNoether
yep, last meeting iirc. but i actually had a call with isthmus about it. i view this move as a very good boost in privacy in the sense that it covers up a source of non-randomness in the large data sets that isthmus likes to comb through.
-
sarang
I can work out the size and time implications on that if you like
-
suraeNoether
i'm not convinced it is worth the additional cost to our txn sizes, but we'll see how it shakes out
-
sarang
Since it could be bundled into the existing bulletproof
-
suraeNoether
^ ah
-
sarang
Yeah, size is not the issue here due to the logarithmic scaling
-
suraeNoether
yeah, and verification times are speedy as a cheetah's balls
-
suraeNoether
pardon me, this is a public meeting, i should be less vulgar. please accept my apologies.
-
sarang
Right... there's a linear increase in verification time, but with the benefits of multiexp that's reduced a bit
-
sarang
-
sarang
Thanks to the author for taking care of that so quickly
-
almutasim
A press release could get more coverage, when and if it is desired.
-
sarang
suraeNoether: interestingly, due to bulletproof padding, for many transactions there would be no size increase aside from the space taken up by the commitment data
-
suraeNoether
good on cointelegraph
-
sarang
(as opposed to a smaller plaintext representation)
-
suraeNoether
sarang: could a similar approach be used to include a ciphertext of a message?
-
suraeNoether
ie moneroMail
-
Isthmus
Sorry somebody got in a fight with the bus driver right before my stop
-
sarang
Not really... there's some spare space in bulletproofs that could hold something 1-2 proof elements of arbitrary data by controlling randomness (I'd need to check the details)
-
Isthmus
Sigh San Francisco
-
sarang
Welcome back Isthmus
-
Isthmus
Ok lemme whiteboard some stuff 1 sex
-
Isthmus
n3ptune: do you want to share the padding?
-
Isthmus
In the blocks
-
n3ptune
sure
-
suraeNoether
sarang so enough for a key exchange but unlikely enough for a ciphertext?
-
sarang
Well, you're limited by space
-
n3ptune
Is there a known purpose for the null padding tag in tx_extra?
-
sarang
I don't remember if Poelstra and friends found 32 or 64 bytes of space
-
sarang
n3ptune: good question for moneromooo et al.
-
sarang
While we await Isthmus' continued update, anything else of interest to share?
-
sarang
Or ACTION ITEMS, according to the agenda?
-
suraeNoether
i want to provide final comments to you on clsag but i'm very unlikely to get that finished today
-
suraeNoether
but it's on my mind for this week
-
Isthmus
Back
-
suraeNoether
Front
-
sarang
Mine are to get CLSAG submitted (after review), to hopefully nail down this Omniring issue and pass it to the authors, work on a few EC curve library updates for proof of concept code, and get preprint stuff taken care of via monero-site MR
-
sarang
Isthmus: please go ahead
-
sarang
(oh, and update the Triptych preprint performance data with better clarity)
-
Isthmus
-
sarang
wat dis
-
Isthmus
So let's say that we have 100 of n3ptune/NRL's archival nodes running
-
Isthmus
If we have only 2 nodes, then our propagation envelope will have a lot of variability, be topology dependent (assume archival nodes don't connect to each other), and just t_second - t_first
-
Isthmus
As we add a 3rd node, it has the possibility of increasing the measured prop time (since it could hear before or after) but can't decrease the prop time since it's max-min
-
Isthmus
As we get up to 100 nodes, the variability will probably smooth out and we approach the true reasonable prop time (from miner to global nodes with broadband internet)
-
sarang
Doesn't prop time depend on max/min among all nodes? So the third node could fall outside the envelope of the other two and affect the value?
-
Isthmus
Yeah, that's the point
-
sarang
OK, I must have misinterpreted
-
sarang
Oh, can't _decrease_
-
Isthmus
Painting very broadly, when we adad the 3rd node there's a 2/3 chance that it'll fall outside the N=2 and increase the prop time, and a 1/3 chance that it'll be between the first 2 nodes.
-
sarang
nvm
-
Isthmus
Sorry, I'm giving a kind of scattered description cuz I just realized this on the bus
-
almutasim
Max-Min is a very sensitive metric, sensitive to outliers.
-
Isthmus
Hmm lemme ponder on that
-
Isthmus
Skipping over that for now
-
Snipa
How're you pulling the time in which the block is received? Tweaked monerod/using it's logs or polling on the RPC interface to determine when it's auctually viably added to the box?
-
Isthmus
That's a n3ptune question, they do all the DevOps and data engineering. All ended up in a SQL database by the time I got to it
-
n3ptune
tweaked monerod
-
Snipa
On P2P receive then?
-
Isthmus
So for each height we have epsilon (green line) which our many-node approximation of global prop time
-
n3ptune
you can also use monerod --block-notify, if you point that to a shell script that writes the timestamp
-
Snipa
--block-notify waits until the block is committed, which is why I ask, because nodes that do not use NVMe have much slower propagation times in general, as you're waiting on disks to write.
-
n3ptune
i like that better because then you can use the stock daemon. but we don't use that yet
-
sarang
OK, so using the max-min metric, assuming relatively even node placement across the network topology?
-
Isthmus
Yeah, though after @almutasim I'm considering a few other less sensitive metrics
-
Isthmus
slap all those epsilons into a histogram, and that's the plot on the right.
-
sarang
The outliers being nodes close to the miner and far from it, topologically
-
Isthmus
Uhm, the outlier might be only 2 hops away but one of the hops is really slow
-
n3ptune
P2P Receive: no it happens when it adds it to the blockchain, after it determines whether or not it's an alt block. this was because we had another original goal to capture alt blocks data. the daemon patch is shared here
github.com/neptuneresearch/monerod-archive
-
Isthmus
@sarang so it depends if topological distance definition is just the p2p connectivity graph or takes into account time between vertices
-
sarang
right
-
Isthmus
And that epsilon plot is basically what n3ptune shared earlier except instead of "max-min with 4 nodes" it is "asymptotic approximation of global prop time"
-
Isthmus
^talking about x-axis of histogram
-
n3ptune
--block-notify waits until the block is committed >> oh then i guess this method of doing it in blockchain::add_new_block() at least occurs before block-notify would. but yes it isn't *immediately* on receive
-
sarang
Since we're just about out of time, any last bits of information before adjourning (discussion can of course continue) for log purposes?
-
Isthmus
Oh yea
-
Isthmus
just a quick note that tx_padding is used in the wild, but unclear why
-
Isthmus
In the scatter plot showed earlier, the vertical bands from left to right are empty blocks and then N=1,2,3... transaactions
-
sarang
That's a question for someone like moneromooo
-
Isthmus
Of course there's variability in the horizontal width of the vertical bands due to transaction size differences, but the variability in coinbase-only blocks was straange
-
Isthmus
-
Snipa
Not really, coinbase only blocks are quite common due to pool design.
-
Isthmus
No no, the size*variability* in coinbase-only was strange
-
Isthmus
Turns out some (now fingerprinted) miners are using lots of null padding, check out the tx_extra for this coinbase
-
sarang
gadzooks
-
Snipa
Not super surprising.
-
Isthmus
Looks like bloat to me
-
Isthmus
Bunch of blocks waste space with nulls in tx_extra
-
Snipa
Possibly, it's also something that can be requested by a pool.
-
Snipa
As that's the block padding that we use for extra nonce storage space.
-
Isthmus
"As that's the block padding that we use for extra nonce storage space." block nonce or transaction nonce? This is padding in the coinbase transaction
-
Snipa
Oh sorry, txn, my bad.
-
Isthmus
Do you know why some miners use the padding and some don't?
-
» Isthmus is very naive about practical mining stuff
-
Snipa
Lemme look through some of my decoding code I wrote for that.
-
Isthmus
I'd been comparing:
-
Isthmus
-
Isthmus
and
-
Isthmus
-
Isthmus
Since they seem to be exactly the same besides different padding
-
» Isthmus wraps up that train of thought
-
Isthmus
Anyways, thanks for letting me ramble and shifting meeting time
-
Snipa
For quick reference: The block's CB TXN contains an "extras" section, which is requested from Monerod as the extra space in which arbitary data can be written. This data is used by pool implementations to implement the per-pool nonces as well as any custom nonce data used by more advanced techniques.
-
Isthmus
"extra space in which arbitrary data can be written"
-
» Isthmus cringes
-
Snipa
You can use this data in a number of ways, particularly with knowledge of pool design, as the two main pool implementations use this space similarly, but have different sizes based on various addon support.
-
Isthmus
Ooh, what are the current use cases?
-
Snipa
You also can identify what pool instances are submitting blocks, as pools use unique identifiers in particular bytes.
-
Isthmus
(I have no knowledge of pool design)
-
Snipa
-
suraeNoether
For those of you who are interested in helping out with Monero Kon 2020 in Berlin, there is a meeting happening right now for prospective volunteers. This is research related, but otherwise off-topic, so I'm just dropping this here.
-
Snipa
^ is the implementation you'll find on pools that support the XNP extensions I wrote awhile ago.
-
sarang
Yeah, we can formally adjourn the meeting, but carry on the conversation
-
sarang
Thanks to everyone for attending
-
Snipa
And yes, we're bad on the pool development side and write stuff directly into the blobed out buffers at fixed offsets. My new code is slightly better about auctually implementing the parsing that Monerod does internally for safety.
-
Snipa
In particular, the minerNonce is the pool's internal counter for the miner. The instanceID is used as a unique data point for the pool thread.
-
Isthmus
Ooh very interesting
-
ErCiccione[m]
suraeNoether: don't know if you already answered and i missed it. Would you be ok with putting yur email address on getmonero like it is for core team members?
-
Snipa
The current NodeJS implementations use one thread per CPU core, so it's not an ideal map of block <-> server, but can identify common threads.
-
Isthmus
Oh yea, the "implications" portion of this article mentions why I care about block fingerprintability:
hackernoon.com/utter-noncesense-a-s…-the-monero-blockchain-f13f673a0a0d
-
Isthmus
@Snipa cool, I'm taking notes on all of this
-
Snipa
If we can figure out how to get you data from our feed, I can provide block find information w/ the pool region it came from, so that might be useful too.
-
Isthmus
@ErCiccione[m] if you're making updates, could you add my email too? Isthmus⊙go
-
suraeNoether
ErCiccione[m]: yeah, although put both surae⊙go and surae.noether⊙pc
-
Snipa
At least, for our blocks.
-
sarang
ErCiccione[m]: as mentioned before, please mask to avoid obvious spam scraping
-
ErCiccione[m]
will do isthmus suraeNoether
-
ErCiccione[m]
sarang: yes, no problem :)
-
sarang
thanks
-
Isthmus
@Snipa are you usually around on IRC? I have to scoot soon, but we'd love to chat more.
-
Isthmus
@almutasim still pondering your comment, and I agree with your observation that (max-min) is probably more sensitive than we want.
-
Isthmus
What do you think about (t_95% - t_first), in other words, how long it takes for 95% of nodes to hear the block.
-
Isthmus
(this is probably close to what we mean when talking about meaningful "global propagation time")
-
Snipa
I'm around most of the time (GMT-8) during the workday/evenings.
-
Snipa
If you've got specific pool/mining related stuff, I'm always glad to help.
-
Isthmus
:- )
-
Isthmus
And actually, using dt95% allows us to formulate the question slightly differently:
-
Isthmus
How many nodes do we need so that the dt95% measured by our archival network adequately approximates dt95% for the whole network (including unobserved)
-
moneromooo
No known purpose for padding.
-
sarang
^ Isthmus
-
moneromooo
net.psp.msg:INFO will give timestamps of message received in the p2p layer.
-
moneromooo
Why are coinbase only blocks quite common due to pool design ?
-
Snipa
Sxmr is somewhat bad about it in particular, though we do it mostly to avoid monerod. The functional implementation that we utilize doesn't rely on Monerod block propogation, as it's a little too slow.
-
Snipa
The functional implementation takes advantage of a secondary overlay network that talks directly to pools from the daemon that submits the BT to the network, as it confirms first, and broadcasts the BT out through a dedicated sub-network. If that node has no txns at that point in time, then the pools will not receive any txns as part of that broadcast. Mix that with the pool's default handling of "Once I get a BT for a new height, don't
-
Snipa
accept another BT and reset miner work."
-
moneromooo
Sxmr is the name of some pool software ?
-
Snipa
SupportXMR, which uses my software.
-
Snipa
The other main implementation does similar block-template blocking work, to avoid messing with miners.
-
sarang
suraeNoether: I've updated Triptych (iacr.tex) on Overleaf to include batching and fix some typos; notably, I made a slight error in size computations as well, based on how I was trying to compare Triptych with the modified version of old-RCT3
-
sarang
The size computations apply only to the signature/proof portions, not complete transactions (which depend on implementation, as I discuss in my markdown writeups on the sublinear branch)
-
sarang
Please review suraeNoether
-
sarang
Proposed changes are in this commit if that helps:
SarangNoether/skunkworks 946dd65
-
sarang
I'll hold off on revising on IACR until I get your thumbs-up
-
xmrmatterbridge
<learninandlurkin> Did anyone look into thos pre-ringct giant sweep transactions that were mentioned earlier? Does anyone have a link to them in a block explorer?
-
hyc
gingeropolous pasted a link before
-
hyc
-
sarang
suraeNoether: it would also be helpful if you can first give a quick review of the title/abstract change on CLSAG, so I can update the monero-site language file strings
-
sarang
even before reviewing the paper itself
-
xmrmatterbridge
<learninandlurkin> Thanks hyc, veru strange indeed
-
xmrmatterbridge
<learninandlurkin> I assumed it would be a larger amount in the clear from that long ago
-
hyc
looks like mostly dust