00:41:02 https://github.com/vtnerd/monero-lws/pull/140 00:42:44 Confirmed the bug, it would only occur when subaddresses were enabled. Will backport to master and release branches after checks pass 01:33:50 Yes 02:38:21 but with fcmp++ there will be new address types , so it would still use a polyseed ? 04:47:57 Polyseed doesnt have anything 2do with address 04:49:46 Seeds are just a way of encoding your private keys. Polyseed was initially thrown in the pot with seraphis and jamtis (jamtis being the new addresses). Were now going the route of fcmp++ and carrot (carrot being the addresses). 04:50:50 Polyseed works today, though it was initially not planned to be released before jamtis. 05:04:57 yes I had, with a count of 10 if that matters 06:54:31 i know sir , i was testing you 😅 08:07:20 so jamtis is droppe?d 09:08:03 for now 09:57:18 we have jamtis or jamtis++ aka carrot and fcmp++ now right jeffro256? 10:00:17 kayabanerve mentioned if carrot would delay FCMPs launch it would be done without it, Carrot would then be added later. could you clarify if that is the same for "jamtis"? is Jamtis optional for FCMP the same way Carrot is? 10:02:24 > jamtis++ aka carrot 10:02:25 JamtisRCT is not Carrot. They are different addressing protocol 10:03:52 so Carrot is 'built' upon Jamtis, it will deprecate Jamtis should it be successful? 10:04:01 Jamtis is for Seraphis. JamtisRCT is an adaptation of Jamtis over RingCT addresses. Carrot is a whole new addressing protocol attempting to most features of Jamtis on the RingCT address protocol (old address will still work). 10:04:41 Carrot is based on JamtisRCT but yes it will be deprecated soon after by JamtisRCT 10:04:47 It's the goal at the moment. 10:08:38 Apologizes to be more clear plowsof. JamtisRCT will require you to generate new addresses but people can still send you money on your old RingCT address. As opposed to Carrot which will offer its features without migrating to a new address format 10:09:59 more info here: 10:10:01 https://gist.github.com/tevador/d3656a217c0177c160b9b6219d9ebb96#67-legacy-addresses 10:10:03 https://github.com/jeffro256/carrot/blob/master/carrot.md 11:35:15 plowosof: There is a JAMTIS for FCMP++. It isn't Carrot. It isn't proposed to be done with FCMP++ at this time. 11:37:02 Carrot is the portion of JAMTIS for FCMP++ for sending to existing addresses. It doesn't define a new address format. In the future, we can still adopt JAMTIS (introducing a new format). 11:37:15 As SyntheticBird said 12:34:36 <3​21bob321:monero.social> Clear as mud 15:43:30 How are miners incentivized to put more transactions into their blocks? If we want monero to scale, it has to be done right? 15:44:36 actually they are not incentivized to do so for the sole reason that there is a size limit 15:45:10 dynamic block size don't mean the block have no size limit. But that over time it will grow enough and adapt to the transaction volume 15:56:45 Even with a size limit, will transaction fees be enough for the miners to try to put more than only one transaction in each block ? Their main goal is to get the block reward. And they might have better chances getting it with smaller blocks than bigger, as smaller blocks get transmitted faster. So the bigger blocks could have more chances of being orphaned 16:00:02 > Even with a size limit, will transaction fees be enough for the miners to try to put more than only one transaction in each block ? 16:00:03 Miner's dont give a f*ck about fees because it doesn't represent even a quarter of what they earn with the block reward. 16:00:05 > Their main goal is to get the block reward. And they might have better chances getting it with smaller blocks than bigger, as smaller blocks get transmitted faster. 16:00:07 I don't get what you mean by *smaller blocks are transmitted faster*. The difficulty is adjusted so that in average a solution is found in around 2 minutes. This is independent to the number of transactions put within a block. 16:05:56 The blocks are communicated to the other peers faster if they are smaller. 16:05:57 If two miners find two different blocks at the same time, they will propagate them in the network at the same time and I guess that everybody will add the first block they hear of into their chain. So you want to propagate the fastest possible so that more people hear about your valid block first. And it's quicker to send 1M of data than 1G of data 16:06:00 IIUC the fee + dynamic-block-size algorithms are designed to mesh with one another so that high tx volumes will push above the blocksize median by a small amount (10%? 5%? I don't recall) 16:06:36 SyntheticBird: fees aren't negligible 16:08:05 ammortel: yeah but a 1G block doesn't actually mean you have to broadcast 1G to each peer once a block is mined, b/c of fluffy blocks 16:08:07 Ah ok I see. blocks are in order hundreds of kB. I think the propagation time (badnwith) is negligible. 16:08:26 how much does it represent for miners? 16:08:54 Without checking... 1% I'd guess? 16:09:13 Negligible means that they aren't worth consideration 16:09:16 but they are, even if small 16:09:19 hence why miners are incentivized to fill blocks up 16:10:10 okay well i was wrong its about 2% it looks like 17:44:48 I confirm the issue was due to the use of --max-suaddresses 10 as an option to monero-lws, I removed it and I could see the 0 conf messages in 0MQ 18:36:38 @hbs I already fixed the bug in develop, master, and release 0.3 branches so just update your code and it should work now 18:43:17 Great thanks! Another question, is it or would it be possible to specify a start block height when calling get_address_txs? This would be useful to lower the load on monero-lws when the tx are kept track of incrementally elsewhere. 19:00:44 https://github.com/monero-project/meta/pull/603/commits 19:01:29 There's a draft spec I could implement. Presumably it works as I think mymonero uses it 19:02:18 I'm not sure if it lowers the load on LWS much though, the bulk of the wait is still probably the DB read 19:58:04 It will at least lower the load on the client side then since less JSON will have to be buffered / parsed. 21:03:08 What are uncles? 21:03:31 "Current Shared 5 blocks (+0 uncles)" 21:05:39 Orphans AFAIK. 21:05:57 Orphans that get some fraction of the block reward of the block they're orphaned from. 22:12:12 orphans who discovered they had a family