00:12:50 @needmonero90 which plot did you ask for in the coffee chat? 00:13:05 Ohhh wait I remember 00:16:01 looks like an offset within the block reward 00:16:29 for some of them, and an overall offset for others 00:16:46 weird 00:18:12 I think it was fixed in the v5 hardfork 00:18:50 April 2017 coincides with block ~1290000 00:19:18 can you look backwards farther? maybe it started with a specific hardfork 00:23:59 https://usercontent.irccloud-cdn.com/file/Uomdbdxs/image.png 00:24:54 what happened at 1mill blocks? change of block time? 00:25:04 * Isthmus nods 00:25:44 lotta weird stuff there 00:29:10 Im guessing each hardfork makes the miners update their software, which leads to bug fixes 00:30:07 "99 little bugs in the code, 99 little bugs in the code. Take one down, patch it around. 117 little bugs in the code." 00:41:02 it's almost like pre-1mill a large amount of miners were just ball parking the block reward 00:41:46 Yea it looks like they picked the reward from a PRNG lol 00:42:22 I bet there's some in there where the [fees + theoretical emission + penalty = payout] equation does not balance 00:42:33 it could be a lot of altruisitic miners 00:48:26 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 00:48:41 rounding down to 0.0001 significant digits 00:50:09 Yeah, it seems to be correlated with size 00:50:34 Wow, voluntarily taking a penalty of ~95% of block payout with almost no income from fees 00:52:09 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) 00:52:24 so all the variability is due to penalty and fees 00:52:56 so rather than ballparking/underclaiming it was all altruism 00:54:52 Oh yea, forgot that underclaiming was added in v2. Made sense back when we had denominated outputs, but unnecessary now that we have RingCT 00:57:15 which confuses me since back then transaction volume was super low, so how were all these penalty zone transactions being made? https://bitinfocharts.com/comparison/size-xmr.html 00:58:42 can you do a color scale with 20kB instead? for the first 1000000 blocks that was the penalty zone 00:59:19 I think they're all over 20kB but give me a chance to reload the data and double check 00:59:26 Heh, I had a funny realization about allowing underclaiming - it opens a back door for miners to exert control over monetary policy. 00:59:31 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). 00:59:32 I think that ideally, that kind of major overhaul to our economics would require community consensus and modification of the codebase. 01:00:20 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. 01:00:26 Within the letter of the law, if not the spirit. 01:01:23 https://usercontent.irccloud-cdn.com/file/CI6NHlvo/image.png 01:01:32 Yellow is >= 20000 01:02:49 early stress test? 01:03:15 * Isthmus shrugs 01:03:19 way before my time. 01:10:07 nice to see modern blocks are pretty clean anyway 01:31:26 Isthmus: time series of X interval plots 01:31:43 Or maybe plot the distributions for each month in a different color 01:36:14 If we change it to not allow underclaiming, they can still do it since they have 51%. 01:36:52 (I assume you mean they'd rewrite the chain if anyone claims a non zero block reward) 01:41:26 Yea, but there's a nuanced reason for making the change. 01:41:31 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. 01:41:32 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. 01:43:02 A fairly simple change. It won't stop someone with halfway decent ability. 01:43:41 I think you mean "the monero team doesn't like it", in which case fair enough. 01:51:50 thankfully the argument in favor of tail emission is pretty strong, and it harmonizes with the dynamic block/fee system quite nicely 01:54:42 Agree, but if Bitcoin price goes 100x relative to Monero and media are evangelizing the 21M angle, I expect scarcity "cargo cults" to emerge. 01:54:48 Regardless of all of the research and evidence in favor of tail emission, it'd come down to greed and FOMO. xD 01:57:49 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 01:57:57 media* 03:20:24 miners are going to voluntarily reduce the reward to zero? sounds suspect 03:35:09 yeah... i mean, " 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 03:35:30 so it carries with it all the costs of a 51% attack. 03:36:39 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 03:37:14 you do some thing where the block reward gets pushed to the next block if unclaimed, the game theory takes over methinks 03:37:41 interesting 03:37:47 but if its done wrong, could probably introduce weird incentives for other behaviors 03:39:28 so current block reward = 'ideal' supply - actual supply + intended ideal reward for this block 03:41:27 ofc fixed block reward makes the most sense 03:43:05 yeah im thinking more for the tail emission. 03:44:40 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 03:45:24 e.g., you can legitimately mine a block with 0 total reward if you made the block so big that the penalties added up 03:46:05 at least in theory, afaiui 03:46:26 yes, I calculated its 3 to 4 times the base block reward to fill the penalty zone 03:46:46 depending on transaction sizes 03:47:14 in total fees 04:09:56 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.... 04:26:00 well in the current scheme they can claim any reward they want without stuffing a block... right? 04:30:08 right but why is it harder if they can't 12:37:58 is there a good ecc text book that focuses on modern implementations and their theoretical descriptions? 12:40:47 someone has had time to write a book on ECC already? 15:50:12 TheCharlatan look at the pdf here https://crypto.stanford.edu/~dabo/cryptobook/ 16:14:13 hey guys! 16:14:57 somebody just sent me this paper https://arxiv.org/pdf/2001.03937.pdf - i wanted to ask if you have seen it yet and what you think about it 16:15:09 and maybe if there is already an official statement from you 16:16:30 Yes, I read it when it was posted 16:17:39 Without more details on the model and exact dataset, it's not possible to examine their results in more detail 16:18:46 (the usual disclaimer, of course, that preprints are not peer-reviewed before posting) 16:20:25 thank you @sarang! 16:20:37 This isn't any kind of "official statement" (this is an informal workgroup) 16:20:44 to be honest, i am a little disappointed, that in the very first sentence of the paper they confuse RingCT with RingSignatures. 16:21:28 "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) 16:21:54 Ah I see, so that is correct 16:22:05 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" 16:22:39 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 16:23:03 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 16:23:45 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 16:23:59 It's not clear how their ShapeShift data differs from them (again, they don't really provide many details) 16:24:33 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) 16:25:12 just proved that CT works 16:25:38 their entire analysis works because they have a good source of labels. e.g. the shapeshift API 16:25:38 They have a follow-up preprint as well, talking about cross-input correlations (but again with very few details on the model or dataset) 16:25:53 I'd mainly like to know if/how the ShapeShift results would apply elsewhere 16:26:10 certainly the transaction records from an exchange like Kraken would also be a reliable source of labels 16:26:12 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) 16:26:35 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? 16:26:54 They were able to build correlations using labeled public data 16:26:56 Monero in isolation is uncrackable, I'd say 16:26:59 And even with the information they did gain, its not really a fault of monero, but more of shapeshift? 16:27:01 but we don't live in isolation 16:27:12 I don't think it's a "fault" in those terms, necessarily 16:27:27 It means that it's really, really hard to make transactions "completely uniform" 16:27:50 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) 16:28:09 However, those correlations don't break the underlying cryptography; they imply patterns of use with that particular data set 16:28:26 yes, reaffrims that anonymity comes from blending into a crowd. anything distinctive breaks that. 16:28:47 Right, even things like frequency of use or common times 16:28:56 but without a source of labels, they still would have nothing. 16:29:12 Sure, but it also shows that large entities like exchanges hold a lot of labels, so to speak 16:29:21 yes... 16:29:43 the fact that shapeshift accounted for 4% of monero transactions was an important data point 16:30:01 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. 16:30:10 moneromooo as well 16:30:24 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 16:30:55 What about me ? 16:31:18 enforce exact block rewards for next hardfork 16:32:02 Someone's doing it atm. If they don't do it in some reasonable amount of time, I'll do it if reminded. 16:32:07 ok 16:33:29 sarang: in section 5 they mention that they've already analyzed bitcoin, zcash, litcecoin and dash 16:33:46 Sure, but "Zcash" or "Tcash"? 16:33:47 =p 16:33:59 (Tcash = transparent Zcash)! 16:34:03 heh 16:34:34 I suppose shapeshift doesn't support sending to z addresses 16:34:46 no exchanges did for a long time, I'm not sure which ones do now 16:35:24 Well, and the preprint implies (if I'm reading their labeling correctly) that I/O structure was important to the analysis 16:35:31 and Zcash Sapling doesn't hide that 16:35:47 anyway, the title isn't too click-baity. they tried an ML model to determine txn values and failed. that's still worthwhile result. 16:36:17 in fact their accuracy was -0.1, which I find amazing. I mean, I would expect 0 to be the worst possible accuracy. 16:36:34 Yeah, my only qualm was that the title seems to imply they got results on transaction value, which is the opposite 16:36:44 fair point 16:36:56 Would be nice to have details on their model and results, but they're from a private company, not a university or anything 16:36:59 they got the furthest thing possible from a result ;) 16:37:24 I wonder if the research was intended to promote their analysis methods or something 16:37:34 in which case there's no incentive to provide results 16:37:43 *detailed results 16:38:45 well, if it was positive it would encourage more interest in the direction 16:39:20 I think uniformity of txns is a losing battle. people are always gonna have a random collection of inputs of varying amounts 16:39:34 just like people have a random assortment of coins and bill denominations 16:39:45 so the set of inputs will always be of varying size 16:40:24 aside from that, "applying ML" to a study is largely boilerplate these days 16:40:24 there's a long list of ways to improve uniformity 16:40:35 standardizing the extra field would be nice 16:41:00 I've always said the extra field should use a tag-length-value syntax 16:41:13 and have a registry of known tags 16:41:32 but really, the less it's used the better 16:42:41 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. 16:43:01 out to where? 16:43:07 Anyway, thank you very much @sarang for the prompt reply and your insights! 16:43:21 Maybe the output. 16:43:50 Though the output type system is very annoying to add to, so I won't. 16:44:07 heh 16:44:10 So the rct struct seems like the best place. 16:44:13 is it possible to encrypt so any of several output recipients can decrypt? 16:45:22 I suppose you could encrypt with a symmetric algorithm, and encrypt they key separately wiht an ECDH to each recipient. 16:46:14 makes sense 16:48:20 I want to say get rid of the field completely, but then some flexibility is lost e.g. with the janus mitigation 16:48:23 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. 16:48:33 i_a did you solve your sign problem yet? 16:49:04 TheCharlatan https://crypto.stanford.edu/~dabo/cryptobook/ 16:49:53 with sub addresses do we really need the tx_extra anyway? 16:50:17 it's always wise to leave yourself a hole for future expansion 16:51:31 ASN.1-style TLVs let you add arbitrary extensions without breaking older software 16:51:46 they just ignore extensions that they don't recognize 16:52:47 I'm pretty sure if we want to support cross-chain atomic swap we're going to need an additional tx field 16:53:19 Merge mining also needs one. 16:53:20 yeah enforced TLV would be a good first step 16:57:51 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. 18:20:30 @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. :- ) 18:21:55 I was looking at miner transactions last night 18:22:40 There's currently 7 different implementations in the wild 18:22:49 I could provide a list of blocks mined by each 18:23:31 Everybody seems to use the miner_tx differently, and len(unique(len(tx_extra))) gives it away 18:24:03 Up to 60 kB of null padding, lol https://xmrchain.net/tx/7dfcc4e5d8bd772e3373e51d4140052121503d9b4f3cb6587251292bf06ced9a 18:24:31 @Snipa mentioned some good reasons that mining pools use this for differentiating workers and whatnot, but perhaps we could standardize that? 18:25:37 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 18:26:04 Perhaps supporting up to 100 billion workers per pool or something big enough that nobody has an excuse to circumvent 18:26:31 I mean, I feel like we could support a bunch of pool-required features for less than 60kB of bloat per block 18:28:05 I'm not sure exactly what hooks should be built in, but I'm sure we could accommodate if we wanted to. 18:51:47 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. 18:51:49 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. 18:53:11 One pool does this to *every* tx ? 18:54:34 Is some pool bloating the blockchain? 19:14:39 How mining pool then spend it's reward? 19:14:54 then should spend* 19:16:04 explicitely control that no two inputs being used together? 19:25:33 weird I thought null padding was limited to 255 bytes per tx extra 19:25:52 You can have any number of chunks. 19:26:16 so is it just 255 consecutive padding bytes? 19:33:21 Up to. 19:33:22 I don't upload images into blockchain via tx_extra but anyway Should someone with old tx contained mining reward do something special? 19:37:07 what happens if there are more than 255 consecutive? tx rejected? 19:37:29 No. tx_extra is not parsed. 19:41:17 does main implementation not permit constructing tx with more than 255 consecutive? and there is no effect when reading extra field for received tx? 20:48:19 @cohcho ideally pools would churn the outputs or claim them in a series of transactions that fold in new coins. 20:49:43 Of course, multi-input transactions are a separate matter from leaving obvious fingerprints in tx_extra, but the two combined are extra heuristically deadly. 20:50:35 Though the former is a fundamental challenge of ring-signature based privacy, whereas the latter is something that can be addressed in code/consensus. 20:51:08 <@moneromooo> One pool does this to *every* tx ? 20:51:09 Looks like it 20:51:51 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. 20:56:19 What's the biggest coinbase transaction I could generate with oodles of outputs and maximum tx_extra spam? 20:56:34 Is it capped by blocksize, or outside of that? 20:57:46 Block size. 20:58:12 Oh goood. 20:58:15 *good 20:59:40 moneromooo: --prune-blockchain removes it anyway, right? 20:59:52 (it == tx_extra of miner transaction) 21:01:01 ah, no it's present 21:01:03 No.