11:27:59 Cool! Thanks. Comparing with another transaction recently, I guess the "only" noticeable difference on the link are the number of zeros in the extra field (which I guess is the nonce?) 11:28:20 Sorry! Wrong chat window *embarrassed face* 16:19:25 19:24 Some wallet apparently started spending coins before 10 blocks, so we added a rule to slap it back down. It might well be that, since those txes are now invalid. <-- but that wouldn’t apply to normal wallets, right? 16:20:01 normal = unmodified 16:29:35 Unless bug. 16:33:58 Would logs show up on daemon side? 16:35:40 Yes. 16:38:39 Ok. Maybe people who run public nodes can check their logs if something unusual is showing up. 16:39:30 If they are on level 1. 18:10:54 binaryFate: can you set the xmr.to public node to log level 1? 18:11:00 maybe we can get logs this way 18:12:02 what log are you looking for? 18:12:37 can do tomorrow 18:12:44 pending transaction issue 18:13:05 we have a lot of reports of it but no logs 18:24:29 ah yes, ok can do in the morning, probably not this evening 18:35:12 ok thanks 18:48:49 running now level 1, I can post some logs after dinner 18:50:56 I would wait 24h with log level 1 or so 18:53:28 ok 19:43:26 Question for everybody, I am currently working on a project that "could" increase fungibility of Monero by axing the ability for miners to ask for anything less than the base_reward amount. My particular hurdle is working with C++ since I don't work with it alot. 19:44:40 I would be interested to see data on how common this is 19:48:03 what effect does it have on fungibility? if i decide to mine a block but not take the full reward 19:49:50 Your transaction has a distinguishing characteristic, which is generally good to avoid 19:57:43 What is the question ? 19:58:38 Are there good reasons to keep the current behavior? 19:58:49 (that's my question, at least) 19:59:03 Sorry, I was asking PRetailer, who left us hanging :) 19:59:27 haha sorry, i was talking with a fellow looking at the codebase. 19:59:27 luigi1111 said the quantization could be used to decrease the amount range and save space IIRC. 20:00:23 i was asking where the change would be in the codebase. Im looking at block validation in blockchain.cpp. Reason: i suck at C++ 20:01:20 and whether its better to just axe the field where the miner can ask for less or keep it there but add a verifier which throws an error if somebody does try to ask for less. 20:01:34 also, if anybody is against this, please say something. i like debate 20:01:54 why would the miner ask for less? 20:01:57 in blockchain.cpp, search for: // From hard fork 2, we allow a miner to claim less block reward than is allowed, in case a miner wants less dust 20:02:37 Replace "if (version < 2)" with "if (version < 2 || version >= HV_VERSION_FULL_COINBASE)" and add that new define to cryponote_config.h 20:03:14 You'll have to set quantization to 1 rather than 10k somewhere too. git grep quantiz. 20:03:30 I don't think it increases fingibility to any significant degree 20:03:31 That was to avoid getting idiotic 0.00000000002 outputs. 20:03:33 fun 20:03:50 Or 0.000000000732 20:03:50 anyway the decrease in size doesn't matter for bulletproofs 20:04:52 it's a kinda meh sure change it (for size reasons not mattering anymore) 20:05:17 that's quantizing though, there may be other considerations for fixing the amount 20:05:49 We could conceivably force the quantized amount too :) 20:10:33 hmmm can you explain why you would want to force quantizing too? (sorry for the questions, im newish to working with code in general) I focused more on economic stuff so this is basically new to me. 20:11:57 To get homogeneity for this, but still have quantized amounts. 23:42:50 Is coveralls still used? 23:45:20 It never was. Someone affiliated with them contributed some setup and left. I have no idea how to use it. It might be useful if we can work out how it works. 23:56:35 It stopped updating in 2016. Guess someone of the team has to login and check why. Not sure.