@needmonero90 which plot did you ask for in the coffee chat?

Ohhh wait I remember

looks like an offset within the block reward

for some of them, and an overall offset for others

weird

I think it was fixed in the v5 hardfork

April 2017 coincides with block ~1290000

can you look backwards farther? maybe it started with a specific hardfork

what happened at 1mill blocks? change of block time?

lotta weird stuff there

Im guessing each hardfork makes the miners update their software, which leads to bug fixes

"99 little bugs in the code, 99 little bugs in the code. Take one down, patch it around. 117 little bugs in the code."

it's almost like pre-1mill a large amount of miners were just ball parking the block reward

Yea it looks like they picked the reward from a PRNG lol

I bet there's some in there where the [fees + theoretical emission + penalty = payout] equation does not balance

it could be a lot of altruisitic miners

if you do implement theoretical emission and penalty keep in mind from v2 up to start of v4 it was common to chop off miner tx payment dust

rounding down to 0.0001 significant digits

Yeah, it seems to be correlated with size

Wow, voluntarily taking a penalty of ~95% of block payout with almost no income from fees

what's really interesting is prior to hardfork v2, in march 2016 (block ~1000000) you weren't allowed to take more or less than the true block reward (base - penalty)

so all the variability is due to penalty and fees

so rather than ballparking/underclaiming it was all altruism

Oh yea, forgot that underclaiming was added in v2. Made sense back when we had denominated outputs, but unnecessary now that we have RingCT

which confuses me since back then transaction volume was super low, so how were all these penalty zone transactions being made? bitinfocharts.com/comparison/size-xmr.html

can you do a color scale with 20kB instead? for the first 1000000 blocks that was the penalty zone

I think they're all over 20kB but give me a chance to reload the data and double check

Heh, I had a funny realization about allowing underclaiming - it opens a back door for miners to exert control over monetary policy.

For example, suppose some people wanted to switch Monero to a bitcoin-style emission curve (periodic halving, plus nixing the tail emission so that no more than 21 million Monero ever exist).

I think that ideally, that kind of major overhaul to our economics would require community consensus and modification of the codebase.

But actually, today, any coalition of [otherwise-independent] miners with more than 51% of the hashrate could impose and enforce that new ruleset, *technically* within the Monero consensus rules.

Within the letter of the law, if not the spirit.

Yellow is >= 20000

early stress test?

way before my time.

nice to see modern blocks are pretty clean anyway

Isthmus: time series of X interval plots

Or maybe plot the distributions for each month in a different color

If we change it to not allow underclaiming, they can still do it since they have 51%.

(I assume you mean they'd rewrite the chain if anyone claims a non zero block reward)

Yea, but there's a nuanced reason for making the change.

Right now, since miners are *allowed* to impose this kind of monetary policy, they would be within protocol and thus fairly in control of monetary decisions on the official chain. People wanting to bring back tail emission would have to make an unofficial fork.

If we fix the protocol to prevent underclaiming, then if a bunch of scarcity bros want to cap it at 21 million Monero, they have to make their own unofficial fork with different claiming rules.

A fairly simple change. It won't stop someone with halfway decent ability.

I think you mean "the monero team doesn't like it", in which case fair enough.

thankfully the argument in favor of tail emission is pretty strong, and it harmonizes with the dynamic block/fee system quite nicely

Agree, but if Bitcoin price goes 100x relative to Monero and media are evangelizing the 21M angle, I expect scarcity "cargo cults" to emerge.

Regardless of all of the research and evidence in favor of tail emission, it'd come down to greed and FOMO. xD

in a world where literally every government on earth inflates its currency, and inflation is the backbone of orthodox economics, I'd love to see a median evangelize limited supply even if it makes trouble for Monero

media*

miners are going to voluntarily reduce the reward to zero? sounds suspect

yeah... i mean, "<Isthmus> Regardless of all of the research and evidence in favor of tail emission, it'd come down to greed and FOMO. xD" ... the greed is what would drive the miners to still get a block reward. Regardless of the cabal of miners trying to push the policy, normal miners would still exist. Though I guess if they are truly 51%'ing the network, they just constantly try to erase the normal chain growth

so it carries with it all the costs of a 51% attack.

though it could be fun to try and devise a disincentive for this behavior. afaiu, the current block reward doesn't take into account whether the block reward was claimed in the previous block

you do some thing where the block reward gets pushed to the next block if unclaimed, the game theory takes over methinks

interesting

but if its done wrong, could probably introduce weird incentives for other behaviors

so current block reward = 'ideal' supply - actual supply + intended ideal reward for this block

ofc fixed block reward makes the most sense

yeah im thinking more for the tail emission.

but yeah, so the mining reward for the next block would keep increasing every block its pushed back by this money policy attack. though the penalty scenario would also need to be integrated

e.g., you can legitimately mine a block with 0 total reward if you made the block so big that the penalties added up

at least in theory, afaiui

yes, I calculated its 3 to 4 times the base block reward to fill the penalty zone

depending on transaction sizes

in total fees

yeah a miner can claim any reward he wants by stuffing a block. of course all miners doing that would make rather large blocks if they wanted to claim a low reward...but if they're supposedly colluding to set monetary policy....

well in the current scheme they can claim any reward they want without stuffing a block... right?

right but why is it harder if they can't

is there a good ecc text book that focuses on modern implementations and their theoretical descriptions?

someone has had time to write a book on ECC already?

TheCharlatan look at the pdf here crypto.stanford.edu/~dabo/cryptobook

hey guys!

somebody just sent me this paper arxiv.org/pdf/2001.03937.pdf - i wanted to ask if you have seen it yet and what you think about it

and maybe if there is already an official statement from you

Yes, I read it when it was posted

Without more details on the model and exact dataset, it's not possible to examine their results in more detail

(the usual disclaimer, of course, that preprints are not peer-reviewed before posting)

thank you @sarang!

This isn't any kind of "official statement" (this is an informal workgroup)

to be honest, i am a little disappointed, that in the very first sentence of the paper they confuse RingCT with RingSignatures.

"RingCT" usually is taken to mean the transaction protocol you get by applying Pedersen commitments to multidimensional ring signatures (in one of a couple of ways)

Ah I see, so that is correct

That being said, the idea that distinguishing transaction features could be used to build correlations is a good reminder of why transaction structure is hard to make "fully uniform"

So whether or not their particular data about ShapeShift would be generalized beyond that data, it's good to note that correlations are possible to build

They do note toward the end of the paper that standardizing the size of rings (which has been done) would reduce the effectiveness of the model; however, they don't provide details

Earlier they mention "number of rings" (or some wording like that), which could mean the number of inputs; that is not standardized, but the input-output distribution is pretty skewed to a few particular values

It's not clear how their ShapeShift data differs from them (again, they don't really provide many details)

I did find it interesting that even with the public ShapeShift data, they were apparently unable to obtain good results on amounts (which makes the title a bit odd)

just proved that CT works

their entire analysis works because they have a good source of labels. e.g. the shapeshift API

They have a follow-up preprint as well, talking about cross-input correlations (but again with very few details on the model or dataset)

I'd mainly like to know if/how the ShapeShift results would apply elsewhere

certainly the transaction records from an exchange like Kraken would also be a reliable source of labels

An exchange's transaction structure is likely very different from non-exchange users (but it would be interesting to see to what extent that's true)

so, if i understand you correctly, your opinion is that they were not able to "crack" monero and the title is really a dramatized, maybe to drum up attention?

They were able to build correlations using labeled public data

Monero in isolation is uncrackable, I'd say

And even with the information they did gain, its not really a fault of monero, but more of shapeshift?

but we don't live in isolation

I don't think it's a "fault" in those terms, necessarily

It means that it's really, really hard to make transactions "completely uniform"

and that with enough known data, you can apparently build correlations (under the assumption that these results are correct, which we can't currently confirm without more details)

However, those correlations don't break the underlying cryptography; they imply patterns of use with that particular data set

yes, reaffrims that anonymity comes from blending into a crowd. anything distinctive breaks that.

Right, even things like frequency of use or common times

but without a source of labels, they still would have nothing.

Sure, but it also shows that large entities like exchanges hold a lot of labels, so to speak

yes...

the fact that shapeshift accounted for 4% of monero transactions was an important data point

gingeropolous Isthmus going back to yesterdays conversation. It might be best to enforce exact block rewards, since anyone who accepts less is creating an anonymity puddle.

moneromooo as well

It'd be interesting to see the extent to which this analysis applies to shielded Zcash, where you have metadata on timing, etc. but not ring-based metrics

What about me ?

enforce exact block rewards for next hardfork

Someone's doing it atm. If they don't do it in some reasonable amount of time, I'll do it if reminded.

ok

sarang: in section 5 they mention that they've already analyzed bitcoin, zcash, litcecoin and dash

Sure, but "Zcash" or "Tcash"?

=p

(Tcash = transparent Zcash)!

heh

I suppose shapeshift doesn't support sending to z addresses

no exchanges did for a long time, I'm not sure which ones do now

Well, and the preprint implies (if I'm reading their labeling correctly) that I/O structure was important to the analysis

and Zcash Sapling doesn't hide that

anyway, the title isn't too click-baity. they tried an ML model to determine txn values and failed. that's still worthwhile result.

in fact their accuracy was -0.1, which I find amazing. I mean, I would expect 0 to be the worst possible accuracy.

Yeah, my only qualm was that the title seems to imply they got results on transaction value, which is the opposite

fair point

Would be nice to have details on their model and results, but they're from a private company, not a university or anything

they got the furthest thing possible from a result ;)

I wonder if the research was intended to promote their analysis methods or something

in which case there's no incentive to provide results

*detailed results

well, if it was positive it would encourage more interest in the direction

I think uniformity of txns is a losing battle. people are always gonna have a random collection of inputs of varying amounts

just like people have a random assortment of coins and bill denominations

so the set of inputs will always be of varying size

aside from that, "applying ML" to a study is largely boilerplate these days

there's a long list of ways to improve uniformity

standardizing the extra field would be nice

I've always said the extra field should use a tag-length-value syntax

and have a registry of known tags

but really, the less it's used the better

I had a start at encrypted extra payload. One obstacle was htat the tx keys are themselves in extra. Moving them out would fix this and fix the leeway in having a technically variable amount of them.

out to where?

Anyway, thank you very much @sarang for the prompt reply and your insights!

Maybe the output.

Though the output type system is very annoying to add to, so I won't.

heh

So the rct struct seems like the best place.

is it possible to encrypt so any of several output recipients can decrypt?

I suppose you could encrypt with a symmetric algorithm, and encrypt they key separately wiht an ECDH to each recipient.

makes sense

I want to say get rid of the field completely, but then some flexibility is lost e.g. with the janus mitigation

I've been of the opinion that a freeform/arbitrary extra might allow interesting applications from whoever else, but the only things I've seen so far seem to encourage spam.

i_a did you solve your sign problem yet?

TheCharlatan crypto.stanford.edu/~dabo/cryptobook

with sub addresses do we really need the tx_extra anyway?

it's always wise to leave yourself a hole for future expansion

ASN.1-style TLVs let you add arbitrary extensions without breaking older software

they just ignore extensions that they don't recognize

I'm pretty sure if we want to support cross-chain atomic swap we're going to need an additional tx field

Merge mining also needs one.

yeah enforced TLV would be a good first step

thanks koe , I've already made extensive use of their course, it's great! I've looked around a bit now and the "Handbook of Elliptic and Hyperelliptic Curve Cryptography" seems to be most in line with what I am looking for.

@Koe yea, we already started coding up a tweak so that consensus requires miners to collect all of the fees + emission. Should be done in the next week or two. And since miner_tx_amount will be a deterministic consensus value calculated independently by every verifier, it can be an implicit rather than explicit input for miner transaction validation. :- )

I was looking at miner transactions last night

There's currently 7 different implementations in the wild

I could provide a list of blocks mined by each

Everybody seems to use the miner_tx differently, and len(unique(len(tx_extra))) gives it away

Up to 60 kB of null padding, lol xmrchain.net/tx/7dfcc4e5d8bd772e337…52121503d9b4f3cb6587251292bf06ced9a

@Snipa mentioned some good reasons that mining pools use this for differentiating workers and whatnot, but perhaps we could standardize that?

Right now everybody has their own ad hoc implementation in the extra field, so it might be safer to provide an actual space for that

Perhaps supporting up to 100 billion workers per pool or something big enough that nobody has an excuse to circumvent

I mean, I feel like we could support a bunch of pool-required features for less than 60kB of bloat per block

I'm not sure exactly what hooks should be built in, but I'm sure we could accommodate if we wanted to.

This has implications for privacy of all users. For example, I have a list of blocks mined by the pool that added 60 kB null to each miner transaction. When this person creates multiple-input transactions to claim the reward, ring signatures offer them no protection.

Multi input + miner fingerprint is statistically noisy, soo we know when those outputs are really spent, and can rule them out as decoys in other transaactions.

One pool does this to *every* tx ?

Is some pool bloating the blockchain?

How mining pool then spend it's reward?

then should spend*

explicitely control that no two inputs being used together?

weird I thought null padding was limited to 255 bytes per tx extra

You can have any number of chunks.

so is it just 255 consecutive padding bytes?

Up to.

I don't upload images into blockchain via tx_extra but anyway Should someone with old tx contained mining reward do something special?

what happens if there are more than 255 consecutive? tx rejected?

No. tx_extra is not parsed.

does main implementation not permit constructing tx with more than 255 consecutive? and there is no effect when reading extra field for received tx?

@cohcho ideally pools would churn the outputs or claim them in a series of transactions that fold in new coins.

Of course, multi-input transactions are a separate matter from leaving obvious fingerprints in tx_extra, but the two combined are extra heuristically deadly.

Though the former is a fundamental challenge of ring-signature based privacy, whereas the latter is something that can be addressed in code/consensus.

<@moneromooo> One pool does this to *every* tx ?

Looks like it

Though if we want to be extra pedantic, the hypothesis that "they have mined at least one block without this anomaly" cannot be disproven from my perspective.

What's the biggest coinbase transaction I could generate with oodles of outputs and maximum tx_extra spam?

Is it capped by blocksize, or outside of that?

Block size.

Oh goood.

*good

moneromooo: --prune-blockchain removes it anyway, right?

(it == tx_extra of miner transaction)

ah, no it's present

No.