00:00:22 <cooldiggs[m]> Ive always wondered if there would be a way to enforce randomized output selection to mitigate potential attacks like this, but i dont really know how it would be feasible
00:01:27 <x3nu[m]> yeah to be honest this is why I had assumed that, just because monero is so focused on built in privacy 
00:01:36 <x3nu[m]> and fungibility
00:01:47 <Rucknium[m]> cooldiggs[m]: I have a sketch of a method: Enforce a particular probability distribution at the consensus level via hypothesis testing. Make the p-value 0.05 or something.
00:02:37 <moneromooo> So 1/20 rings will fail the random test ? How is that enforcing ? :)
00:03:09 <cooldiggs[m]> How would one determine the correct distribution though? That part seems to be the biggest hurdle in such a system I think
00:03:11 <x3nu[m]> because if there was a way to have built in randomized decoys, this would throw a wrench into the aforementioned attack
00:03:24 <x3nu[m]> which is arguably one of the strongest attacks against Monero, currently
00:03:30 <moneromooo> What attack do you have in mind ?
00:03:43 <Rucknium[m]> Yes, it would. The wallet would do the test, too, so it would know not to send a transaction that would fail. If a given selection of the wallet fails the test, just draw again.
00:04:01 <x3nu[m]> a poisoned output or a knacc
00:04:50 <Rucknium[m]> cooldiggs[m]: The Monero reference wallet already proposes a "correct" distribution: gamma with a certain specified rate and shape parameter.
00:05:39 <moneromooo> It does not. You could make a wallet that always chooses a predefined set of 10, plus the real input. It'll likely pass the test.
00:06:19 <Rucknium[m]> What does not do what?
00:07:28 <Rucknium[m]> I agree that ideally you'd do a pooled or joint test across, like, all the mxins that are going into all the transactions. Not sure how that could be done though.
00:08:10 <Rucknium[m]> The statistical power with 11 inputs is very low anyway. This will start to become important with larger ring sizes.
00:08:48 <moneromooo> It (The wallet would do the test, too, so it would know not to send a transaction that would fail.) does not (enforce random rings).
00:09:58 <moneromooo> FWIW the daemon does such a test (though a very lenient one) by default.
00:10:24 <moneromooo> If you reject too much, your distribution also changes from the one you started from.
00:10:55 <moneromooo> I suspect something like a gaussian would start decreasing its variance. Not sure what a gamma would do...
00:11:50 <moneromooo> Actually I might be wrong on that point, nevermind.
00:12:29 <moneromooo> I guess it depends on how exactly you reject.
00:14:02 <Rucknium[m]> I agree that a wallet that was deliberately coded to make its transactions stand out could repeatedly pull the same inputs as mixins  for every transaction (or, if not the same mixins, then the same mixin age relative to the time of each attempted transaction). I am thinking, though, that as the distribution becomes more important, there may be some way to enforce it at the consensus level just like ring size was enforced. Also, the lack
00:14:02 <Rucknium[m]> of minimum ring size enforcement in the past created an externality that harmed the privacy of other Monero users. I am very early in thinking about this, so there may be unsurmountable problems.
00:14:57 <Rucknium[m]> "If you reject too much, your distribution also changes from the one you started from." I'm not sure that this is true.
00:15:31 <Rucknium[m]> Ah, just had to read further on. Yes, well it may not be true.
00:32:01 <cooldiggs[m]> Is there any documentation on creating a raw transaction given you have the ingredients to transaction (i.e pub keys, priv keys, outputs etc) ? Im interested in trying to implement something like that in C++ for my own learning
00:32:33 <cooldiggs[m]> I know you can get the wallet to save a raw transaction for later use/sending, but to my understanding that just returns the tx_blob which is a hexadecimal string of an already generated transaction
00:48:50 <Rucknium[m]> I think you might be right about that, moneromooo  , although the effect seems small.
00:50:09 <Rucknium[m]> I wrote a simulation with 1 million transactions, 11 inputs each drawn from gamma with shape = 1. And then reject a tx if a K-S test gave p < 0.05
00:52:16 <Rucknium[m]> A pooled k-s test of all the tx inputs strongly rejects (p < 2.2e-16) that the resultant "sample" of inputs have an age distribution matching the original Gamma distribution. Hoever, when my sample size is smaller, the rejection isn't as strong....
00:54:24 <Rucknium[m]> The variance of this set is on the order of 0.99 (depending on the seed  set for the simulation), when it "should" be 1. Mean is about 0.997 when it should be 1. 
00:59:16 <Rucknium[m]> (For completeness, skewness of the sample is on the order of 2.01, when it should be 2)
01:07:12 <UkoeHB> cooldiggs[m]: are you trying to figure out how monero works by reading the codebase?
01:08:02 <Rucknium[m]> simulation code: https://gist.github.com/Rucknium/fc67e38b3ff8664d0f1cfe8a08c1eaad
01:08:31 <cooldiggs[m]> I have read the codebase for the most part as my guide, and its given me a lot of insight though I was just wondering if there was documentation I wasn't aware of involving constructing a tx from scratch
01:08:31 <cooldiggs[m]> construct_tx_with_tx_key function in cryptonote_tx_utils (i think its there) has a lot of helpful information regarding that though
01:09:29 <cooldiggs[m]> The original cryptonote papers/standards as well have been helpful but they are kind of old and somewhat outdated
01:19:00 <UkoeHB> cooldiggs[m]: https://web.getmonero.org/library/Zero-to-Monero-2-0-0.pdf
01:19:28 <cooldiggs[m]> Havent seen this before, thanks for sending, will take a look now
01:20:30 <UkoeHB> to make a tx from scratch... if you don't care about matching all of monero's serialization details it shouldn't be impossible
01:21:40 <cooldiggs[m]> serialization isnt really all that important, as this is just me trying to understand exactly how xmr transactions work and being able to implement it myself, sort of a learning exercise  
01:29:40 <luigi1111w> even if you care about serialization it's still not impossible :)
01:31:41 <luigi1111w> construct_tx_with_tx_key is probably going to be the most complete "documentation" that exists
01:41:44 <esk6v[m]> Looking for a wallet.keys file that had funds in the 2017-2018 time range to run some experiments re: the selection algo bug (attempting to reproduce j-berman's method https://github.com/j-berman/monero/pull/2 on a set of transactions from that time).
01:41:44 <esk6v[m]> Obviously it can & should be empty now, not trying to claim your Monero V / Classic, if that's a concern just claim it first.
01:41:44 <esk6v[m]> If anyone can donate an old wallet, I'd appreciate it!
01:46:35 <cooldiggs[m]> <luigi1111w> "construct_tx_with_tx_key is..." <- Haha fair enough, and being honest its a pretty complete function overall and you can tell what it does
01:47:11 <cooldiggs[m]> Its just when you get to the nitty gritty like generating key images among other stuff it gets a little hazy, although im sure someone experienced in cryptography + C would be able to pick it up easily
01:47:52 <luigi1111w> if you are wanting to dig into the EC side of things yeah that's a different story
01:48:18 <luigi1111w> best to treat it like a black box unless you are really interested :)
01:48:36 <cooldiggs[m]> I would hope one day to understand it enough to write documentation about it, though it'll likely take me a century ahaha
01:48:52 <luigi1111w> that stuff is mostly ref10 I think
01:49:07 <cooldiggs[m]> luigi1111w: Cryptography interests me in general so I love learning about it, but the C implementation of all that stuff is like an arcane language
01:49:16 <luigi1111w> the simple python stuff is probably a better place to start
01:49:26 <luigi1111w> instead of optimized C
01:49:51 <cooldiggs[m]> For sure, python is easier to get code out on but personally speaking Im more familar with C++ since it was the first language I learned and I love it dearly
01:50:02 <luigi1111w> no I mean to look at
01:50:04 <cooldiggs[m]> Python makes me angry sometimes haha but it has its many advantages
01:50:12 <cooldiggs[m]> luigi1111w: Oh right you make a good point there
01:50:28 <cooldiggs[m]> miniero or whatever its called is pretty easy to read and iirc its mostly python
01:50:45 <luigi1111w> yup
01:50:50 <luigi1111w> it's a little outdated though I think
01:51:00 <luigi1111w> but the EC stuff is unchanged
01:51:03 <luigi1111w> or mostly
01:52:35 <cooldiggs[m]> I would be suprised if its changed all that much since ed/ec curve stuff is mostly a standard to my understanding but it still gives a good baseline for what is actually happening
01:53:04 <luigi1111w> yes indeed
01:53:06 <cooldiggs[m]> Sadly the C code is filled with weird functions like ge_p1p1_to_dontthinkaboutit and it scares me haha
01:53:18 <cooldiggs[m]> But one day I hope to understand it and write some basic docs about it
01:53:27 <luigi1111w> yeah that's why I don't recommend starting there :P
01:54:30 <cooldiggs[m]> Aahhh but I love c/c++, your right though since I havent made much progress in terms of understanding, python will give me some of the divine knowledge so I can understand the other divine knowledge 
01:54:55 <cooldiggs[m]> I see it as a challenge though so its fun to waste time on it, Monero has such an interesting codebase
01:54:59 <luigi1111w> well a lot of it is optimization
01:55:28 <cooldiggs[m]> Its interesting as well to compare it to the cryptonote codebase since I remember that being the OG back in the day, seeing how its changed and improved really is a testament to the community and dev team
01:56:01 <luigi1111w> there are talented coders working on it for sure
01:56:05 <cooldiggs[m]> luigi1111w: Makes sense considering the implementation, ed curve stuff is supposed to be lightweight according to my understanding 
01:56:31 <luigi1111w> I believe "fast" is in the tagline
01:57:02 <UkoeHB> cooldiggs[m]: the weird ge_... functions are converting curve points between different representations
01:57:07 <cooldiggs[m]> edward you sneaky devil
01:57:07 <cooldiggs[m]> you made things fast but now all the code is scary LOL
01:58:55 <jberman[m]> > <@esk6v:matrix.org> Looking for a wallet.keys file that had funds in the 2017-2018 time range to run some experiments re: the selection algo bug (attempting to reproduce j-berman's method https://github.com/j-berman/monero/pull/2 on a set of transactions from that time).... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/0f94122c656ae90f260a949958ff9dc333b88adb)
01:59:49 <luigi1111w> I think the little comments (where they exist) like X = aG + cD or whatever is far more useful in understanding how the function relates to [constructing a transaction, or most targets] than trying to read the actual function
02:04:27 <esk6v[m]> <jberman[m]> "> <@esk6v:matrix.org> Looking fo" <- Suppose a user made a transaction in 2018 with the same applicable conditions (>=2 blocks from lock time expired & from a block with fewer than 100 outputs), would the real output be identifiable? 
02:25:39 <jberman[m]> No, doesn't look like the code from that time has the same issue
02:28:03 <jberman[m]> Here's the code I'm looking at: https://github.com/monero-project/monero/blob/eccb9b08c4ceb57e9db29a1fea3aaebb002c29c4/src/wallet/wallet2.cpp#L6845-L6887
02:29:49 <jberman[m]> It gamma-selects a block offset, which can end up 10 or higher just fine. It also has this line here that extends the window from which it can select an output, which would bring the window up to the 10th block: https://github.com/monero-project/monero/blob/eccb9b08c4ceb57e9db29a1fea3aaebb002c29c4/src/wallet/wallet2.cpp#L6876-L6877
02:44:58 <esk6v[m]> <jberman[m]> "It gamma-selects a block offset," <- Got it, thank you
02:53:59 <jberman[m]> More detail: the gamma was introduced circa Aug 2018 (https://github.com/monero-project/monero/pull/3528). Before then wallets used a different algo that could pull outputs from the whole chain, but a "guess newest heuristic" could work sometimes with that algorithm. This paper could give more insight on that: https://arxiv.org/pdf/1704.04299/
02:57:49 <esk6v[m]> jberman: can I PM you?
02:59:24 <jberman[m]> sure. the "guess newest" heuristic isn't definitive if that wasn't clear. it would still be a guess
04:52:08 <cooldiggs[m]> <moneromooo> "It can't be any value, it has to..." <- Hey, another dumb stupid question
04:52:48 <cooldiggs[m]> If the key_image is deterministic, is the value that determines the key image from key_image.data (which is a char[32] according to ec_point) since it borrows from ec_point?
04:53:43 <cooldiggs[m]> Im trying to understand where it gets its value from, since in cryptonote_tx_utils.cpp after generate_key_image I print the key image object and it returns a 64 character "string" (I know its likely not a string object, but it returns 64 character hex surrounded by < and >)
04:54:41 <cooldiggs[m]> Is key_image.data where it derives the actual key image? Im assuming since it borrows from ec_point that ec_point.data is essentially a representation of a valid point on the ed22156 curve (given the base point of course) 
04:55:20 <cooldiggs[m]> Im asking this silly question because if I print out the image object after generate_key_image in src/cryptonote_core/cryptonote_tx_utils.cpp I get this (around line 335):
04:55:33 <cooldiggs[m]> [wallet 448pHQ]: transfer 4AdUndXHHZ6cfufTMvppY6JwXNouMBzSkbLYfpAV5Usx3skxNgYeYTRj5UzqtReoS44qo9mtmXCqY45DJ852K5Jv2684Rge 2... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/9550ac3d96b90f35047eb60a826a464ee6161389)
04:55:48 <cooldiggs[m]> The code I used for this after generate_key_image is this simple rubber ducky code:
04:55:56 <cooldiggs[m]>       std::cout << "Tx key image is: " << img << " and the type of it is " << typeid(img).name() << std::endl;
04:55:56 <cooldiggs[m]>       std::cout << "Key image data is: " << img.data << std::endl;
04:55:56 <cooldiggs[m]>       std::cout << "Replace key image: " << std::endl;
04:56:00 <cooldiggs[m]> Very basic I know haha
04:56:54 <cooldiggs[m]> But since the key_image.data doesnt seem to be actual chars im guessing it is a representation of an elliptic curve point, which to my understanding would be either the pub key/priv key, and in essence is just a very long number when you break it down to its mathematical core
04:57:35 <cooldiggs[m]> That is, if key_image.data is where the actuual key image value is retained from, I can only guess it is from that considering Im not sure where else the key_image actual object would come from
04:58:54 <cooldiggs[m]> The key_image object confuses me because I realize it is deterministic, but Im not really sure what determines the final value
05:00:22 <cooldiggs[m]> I would assume the key_image.data is the integer value of the key image which is then converted to an actual key image after it is scalar multipled and converted into special bytes and such (as in generate_key_image), but Im not really sure why key_image.data is an array of chars, I mean if the chars are deterministic to the actual value I feel like it would make more sense if it was say a uint32_t or something like that
05:01:38 <cooldiggs[m]> I dunno, Im pretty stupid and easily confused by this implementation of key_image since thats primarily what I am stuck on if I were to use the current monero codebase and its functions, the paper someone linked me earlier is very helpful but it still is conceptual in a way and doesnt deal with the core implementation, which is one of the things I am interested in
05:03:02 <cooldiggs[m]> <cooldiggs[m]> "Im asking this silly question be" <- Also keep in mind, this is just info I generated on a private testnet, for testing purposes so I dont really know if that potentially effects how its calculated 
05:07:59 <luigi1111w> the key image is just a point
05:11:30 <cooldiggs[m]> Right, but what im asking is that point defined in the code as key_image.data? Or is it a different variable under key_image
05:12:02 <cooldiggs[m]> Since key image seems to only extend to ec_point to my understanding, and ec_point is just a char[32] array
05:12:36 <cooldiggs[m]> Unless there is something im fundamentally misunderstanding with the key_image object which is likely since I am a dumbass lol
05:13:09 <cooldiggs[m]> Though maybe im thinking about this the wrong way
05:13:31 <cooldiggs[m]> Because generate_key_image starts off with two ge_point variables, and then is manipulated by the pub/priv key
05:13:57 <cooldiggs[m]>   void crypto_ops::generate_key_image(const public_key &pub, const secret_key &sec, key_image &image) {... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/f578f39af591f1f0aa5c01a7b192252b56896c58)
05:14:30 <cooldiggs[m]> Now that I think about it, its probably all derived from the pub/priv key since before this function in cryptonote_tx_utils key_image is an object called img that isnt defined as anything
05:14:43 <cooldiggs[m]> I should stop drinking and do more thinking LOl
05:14:47 <cooldiggs[m]>  * I should stop drinking and do more thinking LOL
05:14:51 <luigi1111w> keyimage = xHp(P)
05:16:23 <cooldiggs[m]> Im just overthinking it, I think
05:16:58 <luigi1111w> yeah it only contains the result (the point), nothing else
05:17:24 <cooldiggs[m]> Ill look at the code and papers more before I ask more questions haha
05:18:05 <cooldiggs[m]> One last question, I still dont understand how key_image.data fits into this, well i can guess as I assume that is the curve point value itself, maybe
05:19:17 <cooldiggs[m]> Well actually maybe I should figure that on my own, since the code can probably tell me somewhere
05:19:31 <cooldiggs[m]> I just dont see it mentioned much within the implementation 
05:20:56 <luigi1111w> https://github.com/monero-project/monero/blob/master/src/crypto/crypto.h#L55
05:22:35 <luigi1111w> the value is just that 64 hex chars shown in your dump
05:22:36 <cooldiggs[m]> So to clarify, the actual point itself is represented by a an array of 32 chars? (char[32]?)
05:22:39 <luigi1111w> yes
05:22:59 <cooldiggs[m]> Ah ok, sorry for the long stupid walls of text I am tired and just wasnt sure haha
05:23:24 <cooldiggs[m]> luigi1111w: Got it, and since it is deterministic is entirely dependent on the ec point data
05:23:51 <luigi1111w> all the "mathy" stuff is done after decoding it
05:24:37 <cooldiggs[m]> Ah I see, ok, I understand how it is deterministic now, sorry for my excess of dumb questions and walls of text and such, I dont understand easily haha
05:24:42 <luigi1111w> it's deterministic, but it IS the ec point data
05:24:54 <luigi1111w> (at least in its encoded form)
05:25:40 <cooldiggs[m]> Right, so its deterministic based on the ec data just like the actual math function would be, just in moneros special cool kid format
05:25:40 <cooldiggs[m]> I think I understand now, this gives me enough information to test and play around
05:26:05 <cooldiggs[m]> Thank you luigi1111 and moneromoo for answering my questions, you guys are lifesavers and very helpful : D
05:26:54 <luigi1111w> it's not monero's format afaik
05:27:48 <cooldiggs[m]> Im guessing then its something borrowed from supercop or one of the other libraries used in monero?
05:28:11 <cooldiggs[m]> Supercop documentation is sparse so i cant really find much about it haha
05:28:19 <luigi1111w> yeah all the ed25519 libraries use the same encoding I think
05:28:27 <cooldiggs[m]> Or perhaps ref10, but that has lots of  comments thankfully
05:28:32 <cooldiggs[m]> luigi1111w: Ah good to know
05:28:48 <luigi1111w> maybe not all but it's standard
05:29:24 <cooldiggs[m]> a standard gives me a better starting point than say wild west C cryptography impl. haha
05:30:15 <luigi1111w> gl and gn
05:31:22 <cooldiggs[m]> Goodnight! Thanks for you guidance and such, hope you sleep well
05:31:34 <cooldiggs[m]> And hopefully I dont dream of bit shifts and encoding...scary stuff
11:18:46 <sech1> I'm finally very close to p2pool testing phase. Details on reddit: https://www.reddit.com/r/Monero/comments/p9apyd/psa_monero_decentralized_mining_pool_p2pool/
14:25:57 <Guest46> Hello, is there an eta for a new monero version? There were two bugs discussed recently. One related to the selection of decoy outputs and one related to some possible overflow if a certain average transaction count occurs. Will those be fixed in the new release?
14:33:45 <sech1> Yes, soon
14:37:43 <Guest46> nice, thx :)
14:47:01 <hyc> TM
15:06:54 <moneromooo> FWIW both are minor, you don't really need an update in a hurry.
17:28:14 <jberman[m]> May be a dumb question: why don't centralized mining pools include the payout outputs in the coinbase tx also?
17:36:57 <sech1> because monerod can't do this and they don't have qualified developers to make custom block template creation code
17:37:13 <sech1> but they could totally do this too
17:37:25 <moneromooo> Why cannot monero do this ?
17:37:58 <sech1> get_block_template creates miner reward with 1 output
17:38:09 <sech1> *Monero RPC API can't do this
17:38:14 <moneromooo> Oh. OK.
17:40:23 <jberman[m]> Seems that API should accept params to enable this. Saves KB's of data from payout tx's and prevents deducible spents making their way on chain, like here: https://xmrchain.net/tx/98f7f72e6ce347b20bb1d884166dece751813de984700e5e145a01265b0a1525/1
17:40:24 <UkoeHB> pretty sure the API doesn't support sending to a subaddress either
17:41:22 <sech1> yes, get_block_template doesn't allow subaddresses
17:41:42 <sech1> it's technically possible, but it will add additional 32 bytes per output, doubling the size
17:41:57 <sech1> so I don't allow it in p2pool as well
17:42:07 <sech1> 2160 outputs * 38 bytes = already ~80 Kb
17:43:49 <moneromooo> FWIW I'd consider having consensus rules for the share chain to not have the smallest payout threshold possible.
17:44:09 <sech1> It might sound like a lot, but these 2160 outputs would otherwise have been regular transactions, so...
17:44:25 <sech1> there is no smallest payout threshold
17:45:06 <moneromooo> Then "these 2160 outputs would otherwise have been regular transactions" seems false, no ?
17:45:33 <sech1> Not sure what you mean
17:45:44 <sech1> Regular pool would pay 2160 miners anyway, using regular transactions
17:45:54 <sech1> if these 2160 miners move to p2pool, they'll save space on the blockchain
17:46:01 <moneromooo> Paying dust 10 times vs paying quantized 1 time.
17:46:30 <moneromooo> Maybe I'm wrong, but I imagine miners are going to get paid more often with a share chain with no threshold.
17:46:38 <moneromooo> So back to dust outputs.
17:46:53 <sech1> they do get paid with every found Monero block
17:47:17 <sech1> minimum amount is 1/2160 of block reward. It could be a bit less if pool hashrate kept rising after miner found a share
17:48:01 <moneromooo> OK, the small length of hte share chain might fix that...
17:48:02 <sech1> btw transactions combining N inputs take less space than N 1input/2output transactions, so it's not that bad
17:48:49 <sech1> also, if a miner has a significant % of pool hashrate, he will get paid more in each payout, so it won't be dust
17:49:48 <moneromooo> Sure, the existence of non dust does not prive the non existence of dust though.
17:50:19 <mj-xmr[m]> From now on, my reports will only be available here:
17:50:19 <mj-xmr[m]> http://cryptog.hopto.org/monero/health/
17:50:28 <sech1> I think jberman can run some simulations to compare miners on a regular pool paid with 16 output transactions vs miners in p2pool... after he's done with gamma-distribution :)
17:50:51 <sech1> I have a feeling it's still more efficient in terms of used blockchain space
17:51:12 <moneromooo> It'll depend on the payout threshold for those pools.
17:51:25 <sech1> lowest I've seen on pools is 0.001 XMR
17:51:34 <sech1> so only 2 times more than on p2pool
17:51:46 <moneromooo> OK, that's not bad then.
17:52:25 <sech1> https://miningpoolstats.stream/monero
17:52:32 <sech1> you can sort pools by min payout there
18:37:59 <Lyza> I imagine most people take pool payouts much less frequently but Idk; maybe we could ask a pool operator
18:41:02 <sech1> well, p2pool can't pay out more than 1 block reward by design, so it has to pay with every block
19:04:42 <selsta> .merge+ 3672
19:04:42 <xmr-pr> Added
19:04:49 <selsta> .merge- 3672
19:04:49 <xmr-pr> Removed
19:29:52 <jberman[m]> sech1: would it not be possible for the share chain to keep state of which miners are owed what?
19:30:49 <jberman[m]> not that it's necessarily the better design choice, just curious
19:31:14 <sech1> what do you mean? Each share chain block has miner wallet address
19:32:09 <sech1> oh, you mean payout out only fixed number of "top earners" and remembering other balances?
19:32:19 <jberman[m]> ya
19:32:31 <sech1> I tried to do this but couldn't figure out the fair payout scheme - low hashrate miners were always underpaid in my simulations
19:34:15 <sech1> the simplest example - if some share goes out of PPLNS window without getting paid, you could remember this share difficulty and add it to another share of the same miner
19:34:26 <sech1> naive approach which makes low hashrate miners underpaid severely
19:34:54 <sech1> I tried several different payout formulas to fix this but didn't succeed
19:38:54 <jberman[m]> interesting, got it
19:41:07 <sech1> the requirement of paying out exactly the block reward every times complicates things even further
19:41:34 <sech1> which can't even be predicted beforehand because of transaction fees added to the base reward
19:50:34 <jberman[m]> ya I see the problem
21:27:12 <Guest62> hi I am new here . is it possible to view history 
21:34:21 <carrington[m]> On Matrix, yes
23:45:26 <monerodev880022[> How do I get in touch with Luigi or whoever pays out the CCS proposals? 
23:54:57 <luigi1111w> just message me