<1​0tus:monero.social> It seem not compatible, in that case adjustment to these features would be necessary to align with the new architecture

<1​0tus:monero.social> It would need to address the creation of small outputs l, better output aggregation, transaction mangement

<1​0tus:monero.social> Design a new emission model compatible with blockdag principles...

<1​0tus:monero.social> I wasn't even aware of merge mining...

<1​0tus:monero.social> Without collaborative development effort with other coins that merge mine with monero, this might not be compatible then

<1​0tus:monero.social> Transitioning monero to a blockdag might result in a extensive reshape of the project

ofrnxmr> "larger ringsize was discussed to bridge the time till fcmp is live" << this is retarded <--- it was discussed without knowing the timeline for FCMP. Once the optimistic timeline was given by kayaba it no longer made sense to have an additional hardfork that would be used for a few months b4 FCMP and the discussion of an extra hardfork went away

<1​0tus:monero.social> I understand your point

<1​0tus:monero.social> This kind of move would need to align with long term goals rather than a quick fix

<1​0tus:monero.social> The blockdag implementation should be carefully design to avoid the need of disruptive hard forks for a long term stability

<s​trawberry:monero.social> I think they're talking about adding a new type of tx for coinbase outputs, not blockdag

<1​0tus:monero.social> Oh sorry I mixed up

<d​ave.jp:matrix.org> Fcmp mainnet is years away realistically

certainly longer than the estimate that was given

nioCat, i still think increasing the ringsize arbitrarily would have been 🐒

<d​ancer:monero.social> I wonder how long people thought about the naming of MoneroKon

<d​ancer:monero.social> I know there's lots of conferences named ___con, but with crypto it seems particularly inadvisable to put the project name alongside the word con, including homophones

<s​trawberry:monero.social> 2.49% LTC is surprising too, litecoin usually does well in these stats <== LTC sees usage when BTC fees are high

although XMR sees more usage (: x.com/CoinCards/status/1736483739285250056

ltc has low #s everywhere, who are we kidding

Its xmr + btc = 70+%

explain this chart: bitinfocharts.com/comparison/transactions-ltc-xmr.html

💀

same way you explain this bitinfocharts.com/comparison/transactions-ltc-bsv.html#3y

merchants and swappers all know ltc is a distant #4 or 5

so when is serai coming

Doug thinks FCMPs are 1-1.5yr away: youtu.be/gATkzkZbeU8?si=mEPv6rtjTkCq-5rb&t=1883

<m​onerobull:matrix.org> i can explain it

<m​onerobull:matrix.org> it got most of its "usage" from a play2earn onchain game

<m​onerobull:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/xlkEqZVhnzpGamqXJZCvpNSQ

<m​onerobull:matrix.org> aka it's spam by farming bots. every single action in that game is a transaction.

<m​onerobull:matrix.org> of course the bigger spikes are likely because of high price fluctuations & high bitcoin fees but the "base load" is significantly inflated by this

<m​onerobull:matrix.org> mind you, i have not analyzed the ltc blockchain to confirm it, just heard one day that most transactions come from this game and today i checked when it was released

<m​rcyjanek0:matrix.org> S01E04 (final episode for S01)
- monero_c/monero.dart
- ios builds improvements
- ci for native arm64 macos builds (not cross compiling)
- ci for ios builds
- ci for sfos builds (i hate glibc)
- build xmruw as a part of monero_c/monero.dart ci, to allow easy testing of upgrades (i.e. if nothing breaks, or are bugs fixed) without manually recompiling entire app.
- and<clipped message>

<m​rcyjanek0:matrix.org> roid: drop dependency on libc++_shared.so and link against static STL, to make the library even more portable
- createWalletFromDevice call support
- port some patches to wownero
- [wip] add dummy device for ledger (to use it over BLE on iOS/android via dart - monero_c side is handled by me and dart side is being handled by Konstantin from Cake)
- xmruw
- updated all dep<clipped message>

<m​rcyjanek0:matrix.org> endencies and configured dependabot to ensure everything stays up to date
- add auto save feature
- refactor the way flavors are handled, use cpp (preprocessor, not the language) to create flavours for stealth/normal and xmr/wow wallets (note that wow support is at a very early and untested stage, I do not recommend using it yet)
- rewrite home screen to be more friendly to <clipped message>

<m​rcyjanek0:matrix.org> end users
- add prompt for online services, and routing them through tor or not (prices/exchanges) - no online services are added yet.
- both
- configure devcontainers to allow easy and fast onboarding for new contributors (and speed up review process for automatic PRs)

<m​rcyjanek0:matrix.org> NOTE: website is undergoing an update, so if you want to test latest release grab a nightly build - nightly.link/MrCyjaneK/unnamed_monero_wallet/actions/runs/9836790073

<m​rcyjanek0:matrix.org> repo.getmonero.org/monero-project/c…als/-/merge_requests/437#note_25299

<m​rcyjanek0:matrix.org> delayed last episode from milestone 1 in my CCS

<3​21bob321:monero.social> Luke said <1 year?

<m​onerobull:matrix.org> why do you think that?

Fcmp will likely take 6 months > 1 yr after audits to implement and hard fork, thata mt 2c

So if 6 months to develop, add 6 months > 1 yr for audit, integration, deployment

<m​onerobull:matrix.org> the audit and development is running in parallel

<m​onerobull:matrix.org> code for forks needs to be done 6 months in advance

<m​onerobull:matrix.org> so yeah, probably at least another year.

whenever you ask it will be in a year ( ͡° ͜ʖ ͡°)

<p​reland:monero.social> Hey, that’s 9 years earlier than useful nuclear fusion

<d​ave.jp:matrix.org> History repeats itself 😅 but this time it’s different 😂

<d​ave.jp:matrix.org> 2026 is realistic

<m​onerobull:matrix.org> Shut up, Kayaba actually delivers

7999 delivered too

<d​ave.jp:matrix.org> I don’t mind if he delivers it in 2025, but I don’t want to disappoint myself with unrealistic timeline

Mrl 109 was mostly completed as well. Getting the work done is never the issue around here

kaya literally delivered _already_ completed work in like may 2023

And it didnt even get merged til december

Imagine if we had merged it in may, and kaya spend may > december working on FCMP instead of patiently awaiting approval for 7+ months