-
nioc
*wallat
-
nioc
diego ^^
-
m-relay
<diego:cypherstack.com> what? me? who's there?
-
nioc
meow
-
nioc
wallat
-
nioc
dopewallat
-
m-relay
<diego:cypherstack.com> A Monero-only Stack Wallet should be named what? Comment below (and like and subscribe)
-
nioc
wutwallat
-
m-relay
<syntheticbird:monero.social> Overflow Wallet
-
nioc
what wallet should I use?
-
nioc
yes
-
nioc
wutwallat
-
m-relay
<syntheticbird:monero.social> 💎
-
m-relay
<user2570:unredacted.org> [@diego:cypherstack.com](https://matrix.to/#/@diego:cypherstack.com) Check DM!
-
m-relay
<gingeropolous:monero.social> the MRR rentals look idle right now
-
m-relay
<gingeropolous:monero.social> what the shit. its advertised at 15M, but its 200k.
miningrigrentals.com/rigs/325185/?currency=BTC
-
m-relay
<orange_horizon:matrix.org> zoom out a bit.
-
m-relay
<gingeropolous:monero.social> oh bah its not even monero
-
m-relay
<jeffro256:monero.social> My general opinion on this is that you miss the point of AI in the Qubic attack. The implications for Monero have very, very little to do with AI actually. It has to do with tokenomics and social attacks. AI is only relevant as a marketing term to funnel funds into what is essentially a tokenized mining pool ponzi scheme using a strategy of "selfish" mining. If protein folding or <clipped message>
-
m-relay
<jeffro256:monero.social> some other CPU-intensive computation problem attracted as much VC greed as AI, we wouldn't even be discussing AI. Also, people have already tried to use AI to break ring signature tracability with little to no luck. After FCMP++, it is utterly pointless at try to apply AI to constructing transaction graphs. I like the idea of AI as a gloried clippy for OPSEC tips though
-
m-relay
<liberlion:matrix.org> Firstly, the published article does not refer exclusively to Qubic, but rather takes a general tone with the arrival of AI.
-
m-relay
<liberlion:matrix.org> The claim that AI is “irrelevant” ignores two things:
-
m-relay
<liberlion:matrix.org> 𑁋AI is increasingly used in optimizing selfish-mining and adaptive attack strategies, even if Qubic itself is mostly tokenomics hype.
-
m-relay
<liberlion:matrix.org> 𑁋Dismissing AI’s role in tracing Monero oversimplifies—AI may not break FCMP++ today, but advances in graph neural networks or pattern recognition could still pose future risks.
-
m-relay
<liberlion:matrix.org> Anyway, see this post related to my recently published article, **here is a real-world use case of AI in Monero.**
-
m-relay
-
m-relay
<syntheticbird:monero.social> serious_hat.png
-
m-relay
<plowsof:matrix.org> Meeting time
monero-project/meta #1257
-
m-relay
<plowsof:matrix.org> greetings
-
m-relay
<lordx3nu:matrix.org> Hi
-
m-relay
<hbs:matrix.org> Hello
-
m-relay
<4rkal:monero.social> Hello hello
-
m-relay
<plowsof:matrix.org> RIAT with this "No 51% attack has happened" debunking
riat.at/qubic-attack-on-xmr-monero-no-51-attack-proven
-
m-relay
<plowsof:matrix.org> eddie has been tracking miningrigrentals stats available via their api, rigs / hashrate available , rigs / hashrate rented and last rent price , a chart of some of that is here
i.imgur.com/hWQUiFN.png
-
m-relay
<plowsof:matrix.org> veridises' twitter account shared some FUD and apologised 😅
-
m-relay
<plowsof:matrix.org> hi everyone, have something to bring up? please do
-
m-relay
<lordx3nu:matrix.org> Yeah im looking to move the "monero defense fund" into a community initiative. I think it would work much better that way.
-
m-relay
<plowsof:matrix.org> DataHoarder and sech1 have been working overtime recently 🫡
-
m-relay
<rucknium:monero.social> Hi. I am reading papers about hardening PoW and general permisionless blockchain consensus protocols. moneroconsensus.info is up and running. Since last community meeting, I added line charts on blocks mined by each mining pool.
-
sech1
yep
-
m-relay
<plowsof:matrix.org> x3nu it remains unclear if renting hashes from rig rentals is effective at increasing the amount of honest hashes on the network
-
m-relay
<plowsof:matrix.org> hopefully their api which eddie is tracking could prove if extra hashes are being added to the network
-
sech1
Even had to run around with open laptop while boarding a plane :D
-
m-relay
<plowsof:matrix.org> thank you for your service
-
m-relay
<lordx3nu:matrix.org> Yeah totally understood. I'd love to hear more info on that
-
DataHoarder
sech1: twice!
-
m-relay
<rucknium:monero.social> I agree it is unclear. More investigation is a good idea. I think gingeropolous is looking at renting Amazon servers at scale.
-
sech1
yeah
-
m-relay
<ofrnxmr:xmr.mx> Oh i almost forgot. Hi
-
m-relay
<plowsof:matrix.org> 👋
-
m-relay
<lordx3nu:matrix.org> I do have funds still available and have been reached out to about donating more so there is interest
-
m-relay
<ofrnxmr:xmr.mx> Interest doesnt mean its a good thing
-
m-relay
<lordx3nu:matrix.org> Yeah
-
m-relay
<ofrnxmr:xmr.mx> Need to ensure the hash isnt active before renting it. It seems almost all of it is active when qubic is doing their marathons
-
m-relay
<rucknium:monero.social> If the MRR rigs are mining while not rented, their pricing does not make sense to me. If they are mining while not rented, they would be wiling to switch to mining for someone else if they get just a small premium over mining for themselves. However, the premium is large. IMHO.
-
m-relay
<ofrnxmr:xmr.mx> which means, were not adding any net hash to the network, and are either funding qubic or simply redistributing the hashes
-
m-relay
<plowsof:matrix.org> vik of cake wallet has rented over 200mh per a tweet i read, such an amount should reflect as extra hash rate on the network otherwise, a solo miner is now earning more mining to someone elses address momentarily 😄
-
m-relay
<ofrnxmr:xmr.mx> The premium swings between 0.4ltc to 0.95
-
m-relay
<ofrnxmr:xmr.mx> per mh per day
-
m-relay
<lordx3nu:matrix.org> Of course vik had to one up me 😅
-
m-relay
<ofrnxmr:xmr.mx> Rucknium, when they are _not_ mining, the rates are about 0.4ltc per daily mh. When they are mining, it goes to 0.7-0.95
-
m-relay
<rucknium:monero.social> "they" = the rigs or Qubic?
-
m-relay
<ofrnxmr:xmr.mx> the rigs
-
m-relay
<plowsof:matrix.org> retraction on 200mh x3nu no idea where i got that number from ,,, 3MH*
xcancel.com/vikrantnyc/status/1955693226284781980 sorry
-
m-relay
<ofrnxmr:xmr.mx> It only makes sense to me that they are mining qubic during the marathons (before being rented)
-
m-relay
<ofrnxmr:xmr.mx> renting them pulls the HR away from qubic, but funds the qubic miners directly at 2-3x paid in ltc or btc
-
m-relay
<plowsof:matrix.org> if they are mining cubic during idle time then renting teir hashes is effective, however, these greedy miners will convert that moneys into more moneys by adding more hashes for the qubic side :D
-
m-relay
<lordx3nu:matrix.org> I don't think they are "qubic miners", they are just mercenaries looking for profit
-
sech1
What I observed during the Qubic marathons, is that they have 1.8-2 GH/s baseline, and get more hashrate in bursts (probably rented from AWS/Google cloud/similar). They can't sustain hashrate above 2 GH/s for more than a few (6-8) hours
-
m-relay
<ofrnxmr:xmr.mx> Plowsof - its nor effective if we are paying 2-3x the rates directly
-
m-relay
<plowsof:matrix.org> but it makes you feel good if you donate
-
m-relay
<ofrnxmr:xmr.mx> It means qubic is gaining power without having to cover bill with qubic token
-
m-relay
<ofrnxmr:xmr.mx> It means monero is funding the future attacks
-
m-relay
<plowsof:matrix.org> no good deed goes unpunished etc
-
m-relay
<ofrnxmr:xmr.mx> Sorry. I didnt read the "however". Yes
-
m-relay
<plowsof:matrix.org> infinite money glitch - until .....
-
m-relay
<ofrnxmr:xmr.mx> I think they are qubic miners
-
m-relay
<ofrnxmr:xmr.mx> Otherwose, why would they be idle right now?
-
m-relay
<4rkal:monero.social> Could just be botnets no?
-
m-relay
<ofrnxmr:xmr.mx> turning on _during_ marathons is less helpful than increasing the difficulty
-
m-relay
<plowsof:matrix.org> mining tari only? or some other randomx coin? i guess you'd have to track global hash of these other coins too,. maybe there are patterns
-
m-relay
<ofrnxmr:xmr.mx> They are minibg when _not_ being rented_ during marathons. So its obg they arent being _rented_ by qubic
-
m-relay
<4rkal:monero.social> That want to earn a specific amount for a short amount of time. Probably more stable income than mining to a pool (and more profitable)
-
m-relay
<ofrnxmr:xmr.mx> Definitely monero.. they are only active during marathons
-
m-relay
<lordx3nu:matrix.org> So should we only target miners active during marathons?
-
m-relay
<ofrnxmr:xmr.mx> They atent mining zephyr or some other rx coin right now. they are mining rx during marathons though
-
m-relay
<ofrnxmr:xmr.mx> I think we shoukd only rent _inactive_ miners
-
m-relay
<ofrnxmr:xmr.mx> If youre renting active ones, youre either a) not increasing the net hash or b) youre funding qubic directly
-
m-relay
<ofrnxmr:xmr.mx> Paying qubic miners 3x to "stop mining qubic" is a cure that is worse than the cancer imo
-
m-relay
<plowsof:matrix.org> for FCMP++ goings on, pls do follow the no wallet left behind and MRL meetings (latest one here)
monero-project/meta #1256
-
m-relay
<lordx3nu:matrix.org> Yeah inactive should be prioritized.
-
m-relay
<lordx3nu:matrix.org> Or finding ways of getting new hashrate
-
m-relay
<ofrnxmr:xmr.mx> On another note: monerotime / superquantum posted on twitter and in monero-research-lab, offering developers 65xmr from vthors xmrsigner ccs. i just want it to be very clear, that ccs's arent canceled or repurposed without community discussion and approval, after working with the proposer. ccss are not bounties
-
m-relay
<plowsof:matrix.org> he is banned matrix side for sharing AIDrig - a closed source xmrig miner
-
m-relay
<plowsof:matrix.org> and his irc is muted here and #monero for that spam^
-
m-relay
<plowsof:matrix.org> this monstrosity
github.com/AIDStudio/AidRig , and putting red alerts in MRL to some baseless tweet ehhh
-
m-relay
<plowsof:matrix.org> News: [Monero Observer](
monero.observer) - [Revuo Monero](
revuo-xmr.com)
-
m-relay
<plowsof:matrix.org> can move onto CCS updates unless something else to touch on? v0.18.4.2 to be tagged soon
-
m-relay
<plowsof:matrix.org> if i had a penny for every anti selfish mining strategy ive seen this week i'd have at least several :)
-
m-relay
<ofrnxmr:xmr.mx> 18.4.2 probably today
-
m-relay
<plowsof:matrix.org> tradeogre still dead, kraken is being racist to canucks i read, disabled monero deposits
-
m-relay
<ofrnxmr:xmr.mx> yeah, kraken disabked deposits with no notice
-
m-relay
-
m-relay
<ofrnxmr:xmr.mx> And is disabling trading on sept 2
-
m-relay
<plowsof:matrix.org> 💢
-
m-relay
<plowsof:matrix.org> 4. [CCS updates](
ccs.getmonero.org)
-
m-relay
<ofrnxmr:xmr.mx> Coincards, operates out of canada, added fees to monero purchases, because they have to use other avenues to sell the xmr
-
m-relay
<plowsof:matrix.org> thank you for sharing, i had no idea
-
m-relay
<ofrnxmr:xmr.mx> Personally, since all of these services typically dump the xmr on a cex
-
m-relay
<deverickapollo:matrix.org> We have an update on the btcpay side when ready
-
m-relay
<plowsof:matrix.org> pls do share deverickapollo
-
m-relay
<ofrnxmr:xmr.mx> I started to swap the xmr our before buying cards
-
m-relay
<ofrnxmr:xmr.mx> Deverick, floors yours. I'll shut up now
-
m-relay
<deverickapollo:matrix.org> We completed our refactor on the dockerfile to handle those permission issues we’ve seen. Nicolas merged this week and we are finishing testing. All looks good there.
-
m-relay
<deverickapollo:matrix.org> We have a quick PR open on the ccs adding those support channels at your request plowsof - there was a build failure on your pipeline. Lmk if I need to action on anything there
-
m-relay
<deverickapollo:matrix.org> napoly can comment on some vendor support he’s been providing.
-
m-relay
<plowsof:matrix.org> the support links shld be added to the proposal when luigi can handle merges next, do not worry about pipelines for none ccs proposals
-
m-relay
<plowsof:matrix.org> thanks for the update and progress 💪
-
m-relay
<deverickapollo:matrix.org> We’re moving onto migrating away from wallet file to viewkey now. All work from m1 should be complete from our end. Will need to provide some methods for migrating existing users.
-
m-relay
<napoly:matrix.org> yeah.. i'm in touch with DarkPrague.. but the response is slow so far
-
m-relay
-
m-relay
<plowsof:matrix.org> right lets touch on the open ideas
-
m-relay
<plowsof:matrix.org> a. [hinto-janai full-time development (3 months)](
repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/591)
-
m-relay
<plowsof:matrix.org> rates where changed later, just wating for luigi to merge when available
-
m-relay
<plowsof:matrix.org>
ccs.getmonero.org/funding-required , the general fund contirbuted to vtnerds only 27~ as that was all that bF had on hand accessible
-
m-relay
<plowsof:matrix.org> e. [j-berman full-time development (4 months)](
repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/600)
-
m-relay
-
m-relay
<plowsof:matrix.org> new* proposals , to be merged xD
-
m-relay
<jeffro256:monero.social> I can answer if anyone has questions about my CCS
-
m-relay
<4rkal:monero.social> I’m also here to answer any questions regarding MoneroOS
-
m-relay
<plowsof:matrix.org> 4rkal will circle back
-
m-relay
<plowsof:matrix.org> thank you
-
m-relay
<btclovera:matrix.org> I can put a USB with HiveOS and start mining as well. Why we need MoneroOS?
-
m-relay
<rucknium:monero.social> jeffro256: You misspelled your name in the proposal title.
-
m-relay
<jeffro256:monero.social> ah damn lol
-
m-relay
<plowsof:matrix.org> jeffro256: have you had any interest from hardware wallet manufacturers yet? will the existing low powered devices still work with FCMP++ , iirc the device will not have to do much heavy lifting still - that can be offloaded to the device with the view wallet?
-
m-relay
<btclovera:matrix.org> Or MMP OS.. don't know if RaveOS also has compatibility with MONERO
-
m-relay
<ofrnxmr:xmr.mx> +1 for berman256
-
m-relay
<rucknium:monero.social> jeffro256: How many/which hardware manufacturers are you targeting for your outreach and support?
-
m-relay
<4rkal:monero.social> Not sure what hiveOS is but MoneroOS will be a fully open source live OS specifically designed and optimized for mining monero
-
m-relay
<ofrnxmr:xmr.mx> software wallets that use wallet2_api shouldnt have to do much, if anything, to switch onto fcmp
-
m-relay
<syntheticbird:monero.social> actually im against because jeffro is a significant developer and would help monero survive, but i want monero to die so no
-
m-relay
<4rkal:monero.social> MMPOS seems to be paid and you have to purchase credits after some point
-
m-relay
<plowsof:matrix.org> 4rkal maybe research the competition
-
m-relay
<syntheticbird:monero.social> and jberman
-
m-relay
<syntheticbird:monero.social> jeffro and jberman
-
m-relay
<plowsof:matrix.org> surely theyre doing something good
-
m-relay
<syntheticbird:monero.social> im against the two
-
m-relay
<plowsof:matrix.org> while awaiting jeffros response, can move back onto
-
m-relay
-
m-relay
<plowsof:matrix.org> from 4rkal
-
m-relay
<jeffro256:monero.social> I haven't aggressively reached out yet, tbh. But yes, existing low powered devices will absolutely work FCMP++. I don't know of an existing general-purpise hardware wallet on the market right now which can't easily prove SA/L proofs.
-
m-relay
<ofrnxmr:xmr.mx> Solution in search of a problem, imo.
-
m-relay
<4rkal:monero.social> This proposal has been pending for quite a while now. With the support it has gotten on Reddit and all the Qubic drama (to which it provides somewhat of a solution) I don’t see why it shouldn’t be merged
-
m-relay
<jeffro256:monero.social> I would have to check, but SA/L may use less memory than current ring signatures
-
m-relay
<ofrnxmr:xmr.mx> moneroos isnt going to create 500mh of new monero miners
-
m-relay
<ofrnxmr:xmr.mx> And reddit isnt a good measuring stick for anything, really
-
m-relay
<jeffro256:monero.social> Doing FCMPs on-device is a bit trickier, I don't have the stats for that, but it's also not as useful if the hot device is inititing the transaction proposal since they will know the true spend and there's not really a point to that device not doing it
-
m-relay
-
m-relay
<jeffro256:monero.social> Ledger, Trezor, Keystone at the moment
-
m-relay
<ofrnxmr:xmr.mx> A lot of comments with no responses
-
m-relay
<plowsof:matrix.org> maybe it would effect the DIY offline signers like ANON+NERO and CUPCAKE.. FeatherWallet -
-
m-relay
<ofrnxmr:xmr.mx> I dont think so 🤔
-
m-relay
<plowsof:matrix.org> sizes of unsigned tx in FCMP++ which have to be transferred via the animated QR?
-
m-relay
<plowsof:matrix.org> maybe its the same size or a bit bigger 🤷 🙏
-
m-relay
<ofrnxmr:xmr.mx> We can test this now, probably
-
m-relay
<ofrnxmr:xmr.mx> Just need one of these wallet users to build against fcmp branch
-
m-relay
<ofrnxmr:xmr.mx> Wallet devs*
-
m-relay
<jeffro256:monero.social> This is a good question, I should check the sizes. You can test with:
seraphis-migration/monero #52 which already implements hot/cold wallets in FCMP++
-
m-relay
<plowsof:matrix.org> tobtoht had already played around with fcmp++ in feather a while ago
-
m-relay
<jeffro256:monero.social> An signed FCMP++ tx without membership proofs (what's transferred from the cold wallet to the hot wallet) is going to be smaller than a CLSAG tx
-
m-relay
<plowsof:matrix.org> nice
-
m-relay
<plowsof:matrix.org> will be going over the hour a bit , lets discuss the others
-
m-relay
-
m-relay
<hbs:matrix.org> Available to answer questions
-
m-relay
-
m-relay
<4rkal:monero.social> We’ve already been through what MoneroOS solves on previous meetings. I’m sure you can find the logs for that
-
m-relay
-
m-relay
<ofrnxmr:xmr.mx> I was there
-
m-relay
<4rkal:monero.social> *sorry if that came off a bit mean
-
m-relay
<ofrnxmr:xmr.mx> No need to apologize
-
m-relay
<btclovera:matrix.org> The idea is not bad, but to be honest, 40XMR for an OS, that already we can find "for free" like HiveOS and with support of GPUs. I don't sure if we need to pay for it.
-
m-relay
<btclovera:matrix.org> And maybe we change to a PoS
-
m-relay
<btclovera:matrix.org> 🤣
-
m-relay
<4rkal:monero.social> Why would you need GPU support for XMR?
-
m-relay
<4rkal:monero.social> MoneroValidatorOS
-
m-relay
<4rkal:monero.social> Soon ™️
-
m-relay
<ravfx:xmr.mx> PXE support would be great
-
m-relay
<ravfx:xmr.mx> Turn on the MoneroOS VM.
-
m-relay
<ravfx:xmr.mx> Turn on all the miners and they just boot and start to mine, no need to move usb key around or install ssd in them
-
m-relay
<btclovera:matrix.org> When you build a GPU rig (yes, you can still mine in some regions), you need a motherboard and a CPU. That's when you take advantage of the opportunity to mine GPU + CPU.Well, if the USB MoneroOS is not to be use "as a hacker tool" to put in any device 😅
-
m-relay
<plowsof:matrix.org> hbs the monero wallet side of things - this is for the user to handle (sending of transactions?)
-
m-relay
<hbs:matrix.org> The Monero side is indeed handled by the user, the CLI (and the UI subject of the CCS) provides a QR Code to configure a view only wallet in the first phase, then a full wallet in the last stage of settlement, and a payment URL for the XMR side to send the required amount.
-
m-relay
<4rkal:monero.social> Is that some sort of network booting?
-
m-relay
<hbs:matrix.org> So a Browser and a Monero wallet (mobile or desktop) are the only required pieces of software
-
m-relay
<ravfx:xmr.mx> Yes
-
m-relay
<plowsof:matrix.org> spirobel can fix this so its all in the browser ? ^ but not ready yet
-
m-relay
<plowsof:matrix.org> whats hiveos, whats pxe, where do i get an xmrig config
-
m-relay
<hbs:matrix.org> That could be a possible option in the future, to be studied later I guess
-
m-relay
<4rkal:monero.social> So all machines boot to a specific image on the network? How does storage work there? I mean for stuff like xmrig.json etc
-
m-relay
<ravfx:xmr.mx> load kernel and initrd from tftp (information about that is to be provided by the dhcp server)
-
m-relay
<ravfx:xmr.mx> as for mining, the miners only need xmrig really so you can make a mini environement in the initramfs, that contain the xmrig and parameter so it just start to mine from the configured p2pool or whatever
-
m-relay
<plowsof:matrix.org> the dhcp server -could- be a moneroNodo attatched to a network switch, or a pi, or one of those open source WRT router thingies
-
m-relay
<ravfx:xmr.mx> You can use NFS for storage, you can also have extra configuration tagged with the clients NIC mac address
-
m-relay
<4rkal:monero.social> That would be pretty useful for a farm like setup
-
m-relay
<hbs:matrix.org> Any other questions?
-
m-relay
<plowsof:matrix.org> seems not, thank you for joining
-
m-relay
-
m-relay
<4rkal:monero.social> Could add to the proposal if I can wrap my head around the setup
-
m-relay
<plowsof:matrix.org> for monero python maintenance, lets get the monero-cpp additions upstreamed to
github.com/woodser/monero-cpp/pulls everoddandeven
-
m-relay
<4rkal:monero.social> Would it be possible to have one device boot from USB and be the master or “MoneroOS VM”
-
m-relay
<plowsof:matrix.org> g. [Add proposal: MoneroSwap.ai — Privacy-First, Instant Monero Swap (80 XMR initial funding)](
repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/603)
-
m-relay
<plowsof:matrix.org> close?
-
m-relay
<4rkal:monero.social> You know it’s good when it contains “Global SEO strategy to increase Monero’s visibility”
-
m-relay
<ofrnxmr:xmr.mx> Mergr moneroswap.slop
-
m-relay
<jeffro256:monero.social> Close
-
n1oc
[CCS Proposals] plowsoff closed merge request #603: Add proposal: MoneroSwap.ai — Privacy-First, Instant Monero Swap (80 XMR initial funding)
repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/603
-
m-relay
<ofrnxmr:xmr.mx> Sorry, moneroslop.llm
-
m-relay
-
m-relay
<plowsof:matrix.org> i shared a book from zcash but it seems we can not parasite off of everything
electric-coin-company.github.io/tfl…ml#a-proof-of-stake-transition-path
-
m-relay
<kayabanerve:matrix.org> 👋
-
m-relay
<ofrnxmr:xmr.mx> I don't like the idea (tfl), i think the cost for book for something w/o consensus is a bit ehh. but i'm not against research funding. So, i abstain
-
m-relay
<kayabanerve:matrix.org> jeffro256: They should use less mem than current ring signatures.
-
m-relay
<kayabanerve:matrix.org> The resulting proof is smaller
-
m-relay
<kayabanerve:matrix.org> There's more points, which have a larger repr in memory, but you can buffer those one at a time in 'scratch space' so long as you have enough space for the output buffer _and_ the scratch space
-
m-relay
<kayabanerve:matrix.org> Which should fit within current clsag mem use
-
m-relay
<kayabanerve:matrix.org> I've read through the meeting and am here :)
-
m-relay
<kayabanerve:matrix.org> This is solely to explore and better establish the topic to encourage informed opinions. It isn't to adopt a TFL at this time.
-
m-relay
<plowsof:matrix.org> thanks for joining!
-
m-relay
<kayabanerve:matrix.org> It's hard to be for or against an idea which is effectively just a name and a vibe. I've personally explained some premises multiple times but it's clear if the community at large is to properly weigh in, they need a resource to educate themselves on the proposals and trade-offs IMO.
-
m-relay
<kayabanerve:matrix.org> The end result, while covering a recommendation which could be targeted for deployment, will aim to be widely accessible (unlike the FCMP++ paper) and comprehensive to multiple proposals in a largely modular fashion.
-
m-relay
<kayabanerve:matrix.org> Then, even those who disagree with me may find value in their pieces being represented, even if not my recommendation.
-
m-relay
<kayabanerve:matrix.org> I'll note the idea of a finality layer is quite generic. DNS checkpoints would qualify. Bitcoin could qualify. A system which uses PoS to decide validators could qualify. A system which uses PoW to decided validators could.
-
m-relay
<kayabanerve:matrix.org> Hence the 'book' covering these topics :)
-
m-relay
<kayabanerve:matrix.org> Please note the actual technical depth is what I've, as a rule of thumb, said would be equivalent to the FCMP++ paper. This will not be a college textbook. The emphasis is on the styling and accessibility seen in various online 'books'.
-
m-relay
<kayabanerve:matrix.org> Zcash's is a good example.
-
m-relay
<plowsof:matrix.org> so the persons who will throw their monerokon tshirt in the bin should monero be forced into turning PoS by this CCS have nothing to fear. you will explore / compare available options?
-
m-relay
<kayabanerve:matrix.org> It won't be a survey of all solutions to 51% attacks. It will be a survey of ideas which could instantiate a finality layer. Some non-PoS ideas will be included although I cannot claim they'll be good idea nor my recommendation.
-
m-relay
<plowsof:matrix.org> it seems the enforce dns checkpoint is to be the immediate path forward, i've no clue if this can be effective, Rucknium was looking into this
-
m-relay
<ofrnxmr:xmr.mx> dns checkpoints is a bit scary atm
-
m-relay
<ofrnxmr:xmr.mx> Not going int0 1842
-
m-relay
<kayabanerve:matrix.org> But even if I didn't, this book isn't to become our gospel for the next two years of developers. Me writing this, even if I solely discussed PoS, doesn't mean we'll be forced into PoS.
-
m-relay
<kayabanerve:matrix.org> DNS checkpoints are an example of a non-PoS finality layer.
-
m-relay
<kayabanerve:matrix.org> It's _bad_ because _centralized_
-
m-relay
<kayabanerve:matrix.org> But it exists
-
m-relay
<plowsof:matrix.org> would dns checkpoints be similar to top pools colluding together? or , does dns checkpoints require more than just the "monerods" who are mining blocks to work?
-
m-relay
<plowsof:matrix.org> that was a thought i had reg that
-
m-relay
<elongated:matrix.org> Centralised finality layer
-
m-relay
<ofrnxmr:xmr.mx> top pools would have to, essentially, collude with core
-
m-relay
<kayabanerve:matrix.org> plowsof @plowsof:matrix.org: Order now for just $19.95 and get the book answering all your questions! /s
-
m-relay
<gingeropolous:monero.social> lol
-
m-relay
<kayabanerve:matrix.org> DNS checkpoints, in theory, are distinct from top pools colluding.
-
m-relay
<plowsof:matrix.org> yes collusion seems odd.. you could just cut the middle man out and let them join forces and 51% instead :P
-
m-relay
<kayabanerve:matrix.org> For a few reasons.
-
m-relay
<elongated:matrix.org> Or top pools can all collude together
-
m-relay
<ofrnxmr:xmr.mx> Would need >50% of honest hash to follow the checkpoints to reject wubic reorgs _and_ reorg the rest of the network back onto the checkpointed chain
-
m-relay
<plowsof:matrix.org> thats ofc if the dns checkpoints are collusion, someone has to decide what the chain is
-
m-relay
<kayabanerve:matrix.org> It's core directing 'honest hash power' and users following 'honest hash power' *even if a minority of hash power'
-
m-relay
<kayabanerve:matrix.org> Where honesty is defined as if they listen to core or not
-
sech1
Yeah, let's 51% the network ourselves :D
-
m-relay
<ofrnxmr:xmr.mx> Dns checkpoints with minority dont work unless everyone enforces them
-
m-relay
<kayabanerve:matrix.org> Yep, it can soft fork if a majority is achieved
-
m-relay
<elongated:matrix.org> Temp solution ok 👍
-
m-relay
<plowsof:matrix.org> time to attack monero proper ! join my pool and lets do this!
-
nighteous
im in, where do we attack from
-
m-relay
<plowsof:matrix.org> thanks for providing an overview on the finality layer proposal kayabanerve
-
m-relay
<kayabanerve:matrix.org> Of course :)
-
m-relay
<plowsof:matrix.org> is this spacekitty420s proposal?
-
m-relay
<gingeropolous:monero.social> would you be open to expanding the scope of the book beyond finality layers re: 51% etc? or does that just get too much
-
m-relay
-
m-relay
<plowsof:matrix.org> kayabanerve you are mentioned in it ^^
-
m-relay
<ofrnxmr:xmr.mx> Kayabaya is mentioned in this a few times
-
m-relay
<kayabanerve:matrix.org> gingeropolous @gingeropolous:monero.social: That'd increase the amount of work by an order of magnitude and cause it to lose its scope for the infinite.
-
m-relay
<gingeropolous:monero.social> yah
-
m-relay
<ofrnxmr:xmr.mx> I tried readind rawr a few times but im not sure what the proposal is
-
m-relay
<ofrnxmr:xmr.mx> Seems unhealthy
-
m-relay
<plowsof:matrix.org> i left a comment, but overall - lets get it condensed and cite any smol contributions made to monero and clearly link how placing top in a really really really difficult game can help propell monero - and dispel my idea that people giving you money is going to make your health worse (playing a game without sleeping)
-
m-relay
<ofrnxmr:xmr.mx> Maye they could twitch stream w/ xmrchat
-
m-relay
<plowsof:matrix.org> j. [v1docq47 - monero konferenco 2025 voice-over and working on xmr.ru](
repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/607)
-
m-relay
<plowsof:matrix.org> v1do messaged that he couldnt make it today, but its a renewal proposal for his translation work
-
m-relay
<plowsof:matrix.org> yeah could get them to look at
xmrchat.com and/or kuno
-
m-relay
<plowsof:matrix.org> can leave it there if no one has any comments as we're well over , AOB?
-
m-relay
<nighteous:matrix.org> yo, any proper idea what happened with xmrsigner? I don't understand exactly what happened with.
-
m-relay
<nighteous:matrix.org> So what my understanding is that some guy Thor came up with a proposal, then Thor was working on it? and then its been abandoned for a while? but there has been an active funding for the project so what happens to the funding/
-
m-relay
<nighteous:matrix.org> ?*
-
m-relay
<spirobel:kernal.eu> he is still working on it. i think there was just someone talking about it on twitter.
-
m-relay
<nighteous:matrix.org> I know x dot com/MoneroTime did put out a post for the developers which intrigued me to go deeper into the rabbit hole of the code base and I was just trying to understand what exactly happened
-
m-relay
<spirobel:kernal.eu> maybe talk to vthor if you are interested in learning more about the project. there is a process that happens to abandoned proposals. the seedsigner is not in this process. the information on twitter is sometimes concerned with a slightly different version of reality
-
m-relay
<everoddandeven:monero.social> Hey guys, I take this opportunity to remind you that my proposal for the python library could be helpful for the development of XmrSigner
-
m-relay
<nighteous:matrix.org> actually a good idea. will search for vthor and his communication address and talk to him directly.
-
m-relay
<nighteous:matrix.org> I wasn't aware of the process for abandoned proposals so its cool that this isn't part of it
-
vthor
I'm still working on in but "part time" not half a day but junks in between.
-
m-relay
<nighteous:matrix.org> Oh makes sense, github dot com/xmrsigner/xmrsigner had the last activity 8 months ago, atleast in the master branch so I assumed it was abandoned, I couldn't see any other branches thus my assumption
-
vthor
everoddandeven, not really how I will use the OTS library...
-
m-relay
<nighteous:matrix.org> do you think I could drop into your DMs to nag you with a lot of questions? Just to not contaminate this chat
-
vthor
nighteous: yes you can, but I think that does not work from matrix to irc.
-
nighteous
Joining from IRC :)
-
vthor
8)
-
m-relay
<jack_ma_blabla:matrix.org> are cex informed about 0.18.4.2 checkpoints ?
-
vthor
thanks for tagging spirobel, have a great (....hm...) time! :)
-
plowsof
The 200Mh number earlier was what some requested the general fund to rent, there we go
-
m-relay
<rottenwheel:unredacted.org> > Hey guys, I take this opportunity to remind you that my proposal for the python library could be helpful for the development of XmrSigner
-
m-relay
<rottenwheel:unredacted.org> vthor can you confirm above? ^^ 😁
-
vthor
unfortunately negativ, although I think that the library is a great idea - even I think it will be a headache/monster, too. For XmrSigner is the biggest challenge ahead to cross-compile randomX for pi0. So if it is essentially a wrapper around the monero wallet, there come the same challenges... Back in time if it had existed I had probably used it even if I had been unhappy with the solution (unhappy because IMO too much unnecessary code for a security
-
vthor
related device, I'm still unhappy what is left in OTS although I got ripped out a lot - only to relativate my statement).
-
m-relay
<ofrnxmr:xmr.mx> 18.4.2 is not shipping checkpoint updates
-
m-relay
<elongated:matrix.org> Ah, when checkpoint update ?
-
m-relay
<ofrnxmr:xmr.mx> 18.4.3
-
m-relay
<elongated:matrix.org> So October?
-
m-relay
<ofrnxmr:xmr.mx> could be in less than a week or 2
-
m-relay
<ofrnxmr:xmr.mx> Its just that {i} am not confident in the results of the testing yet
-
m-relay
<ofrnxmr:xmr.mx> Some changes like reducing ban time, have to be on board with mining pools, and the intentional chain split has to heal itself reliably
-
m-relay
<ofrnxmr:xmr.mx> The testing worked ok, and i'll probably try to test some more tonight or tomorrow, but we shouldnt risk fracturing the network if it might lead to breakage.
-
m-relay
<ofrnxmr:xmr.mx> its an all or nothing solution. If we dont create checkpoints until after a reorg, it will cause nodes to be broken. If we create checkpoints regularly, that means we are essentially rejecting reorgs
-
m-relay
<ofrnxmr:xmr.mx> The good thing, is regular checkpoints arent "core choosing", they would be automatically set every few mins.
-
m-relay
<ofrnxmr:xmr.mx> Worked pretty good tbh, just the instant-bans are off-putting
-
vthor
rottenwheel: I think I gave a thumbs up on last(?) weekend, but it was unrelated to be useful for XmrSigner, there the path is already clear, but I need to check my own todo list....
repo.getmonero.org/monero-project/c…als/-/merge_requests/495#note_29994 so, 5 is in the meanwhile done, (except some unit tests and go over again
github.com/MoneroSDK/ots-python/blob/master/TODO.md), so left really left is 2 and 4 the rest are low
-
vthor
hanging fruits. So nothing except compiling randomx/ots will help me to finish. But still, I think it should be easiert o develop something monero related and a functioning python library would be a good thing with docu, quickstart and so on, also to make quick a PoC of something...