-
m-relay
<vtnerd:monero.social>
vtnerd/monero-lws #140
-
m-relay
<vtnerd:monero.social> Confirmed the bug, it would only occur when subaddresses were enabled. Will backport to master and release branches after checks pass
-
m-relay
<ofrnxmr:monero.social> Yes
-
m-relay
<kevino:tchncs.de> but with fcmp++ there will be new address types , so it would still use a polyseed ?
-
m-relay
<ofrnxmr:monero.social> Polyseed doesnt have anything 2do with address
-
m-relay
<ofrnxmr:monero.social> 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).
-
m-relay
<ofrnxmr:monero.social> Polyseed works today, though it was initially not planned to be released before jamtis.
-
m-relay
<hbs:matrix.org> yes I had, with a count of 10 if that matters
-
m-relay
<kevino:tchncs.de> i know sir , i was testing you 😅
-
m-relay
<kevino:tchncs.de> so jamtis is droppe?d
-
m-relay
<ofrnxmr:monero.social> for now
-
m-relay
<plowsof:matrix.org> we have jamtis or jamtis++ aka carrot and fcmp++ now right jeffro256?
-
m-relay
<plowsof:matrix.org> 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?
-
m-relay
<syntheticbird:monero.social> > jamtis++ aka carrot
-
m-relay
<syntheticbird:monero.social> JamtisRCT is not Carrot. They are different addressing protocol
-
plowsof
so Carrot is 'built' upon Jamtis, it will deprecate Jamtis should it be successful?
-
m-relay
<syntheticbird:monero.social> 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).
-
m-relay
<syntheticbird:monero.social> Carrot is based on JamtisRCT but yes it will be deprecated soon after by JamtisRCT
-
m-relay
<syntheticbird:monero.social> It's the goal at the moment.
-
m-relay
<syntheticbird:monero.social> 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
-
m-relay
<syntheticbird:monero.social> more info here:
-
m-relay
-
m-relay
-
m-relay
<kayabanerve:matrix.org> plowosof: There is a JAMTIS for FCMP++. It isn't Carrot. It isn't proposed to be done with FCMP++ at this time.
-
m-relay
<kayabanerve:matrix.org> 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).
-
m-relay
<kayabanerve:matrix.org> As SyntheticBird said
-
m-relay
<321bob321:monero.social> Clear as mud
-
m-relay
<ammortel:monero.social> How are miners incentivized to put more transactions into their blocks? If we want monero to scale, it has to be done right?
-
m-relay
<syntheticbird:monero.social> actually they are not incentivized to do so for the sole reason that there is a size limit
-
m-relay
<syntheticbird:monero.social> 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
-
m-relay
<ammortel:monero.social> 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
-
m-relay
<syntheticbird:monero.social> > 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 ?
-
m-relay
<syntheticbird:monero.social> 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.
-
m-relay
<syntheticbird:monero.social> > 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.
-
m-relay
<syntheticbird:monero.social> 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.
-
m-relay
<ammortel:monero.social> The blocks are communicated to the other peers faster if they are smaller.
-
m-relay
<ammortel:monero.social> 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
-
m-relay
<blurt4949:matrix.org> 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)
-
m-relay
<blurt4949:matrix.org> SyntheticBird: fees aren't negligible
-
m-relay
<blurt4949:matrix.org> 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
-
m-relay
<syntheticbird:monero.social> Ah ok I see. blocks are in order hundreds of kB. I think the propagation time (badnwith) is negligible.
-
m-relay
<syntheticbird:monero.social> how much does it represent for miners?
-
m-relay
<blurt4949:matrix.org> Without checking... 1% I'd guess?
-
m-relay
<blurt4949:matrix.org> Negligible means that they aren't worth consideration
-
m-relay
<blurt4949:matrix.org> but they are, even if small
-
m-relay
<blurt4949:matrix.org> hence why miners are incentivized to fill blocks up
-
m-relay
<blurt4949:matrix.org> okay well i was wrong its about 2% it looks like
-
m-relay
<hbs:matrix.org> 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
-
m-relay
<vtnerd:monero.social> @hbs I already fixed the bug in develop, master, and release 0.3 branches so just update your code and it should work now
-
m-relay
<hbs:matrix.org> 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.
-
m-relay
-
m-relay
<vtnerd:monero.social> There's a draft spec I could implement. Presumably it works as I think mymonero uses it
-
m-relay
<vtnerd:monero.social> I'm not sure if it lowers the load on LWS much though, the bulk of the wait is still probably the DB read
-
m-relay
<hbs:matrix.org> It will at least lower the load on the client side then since less JSON will have to be buffered / parsed.
-
Hikaru_
What are uncles?
-
Hikaru_
"Current Shared 5 blocks (+0 uncles)"
-
moneromooo
Orphans AFAIK.
-
moneromooo
Orphans that get some fraction of the block reward of the block they're orphaned from.
-
geonic
orphans who discovered they had a family