-
ooo123ooo1234[m]
s/cencorship/censorship/
-
elizabeth[m]
hey all, are there any companies/people recommended for audits? wondering if there's any gotos for Monero stuff
-
selsta
elizabeth[m]: you can look at the bulletproof and randomx audits
-
selsta
-
selsta
i think for bulletproofs quarkslab did the most extensive work
blog.quarkslab.com/security-audit-of-monero-bulletproofs.html
-
merope
ooo123ooo1234[m]: relevant xkcd:
xkcd.com/1357
-
ooo123ooo1234[m]
endor00[m]:
xkcd.com/2548 also relevant
-
elizabeth[m]
selsta: thanks!
-
selsta
.merges
-
xmr-pr
8318 8324 8325 8326 8328 8330 8331
-
selsta
luigi1111w: ^ and gui too please
-
rolodondo34[m]
anybody here use the monerujo wallet?
-
spirobel[m]
is it okay to make integrated addresses with subaddresses? the wallet-rpc tells me no:
-
spirobel[m]
-
spirobel[m]
and also it seems like the payment id needs to be specified when I use the primary address
-
spirobel[m]
-
spirobel[m]
even though the docs says it is optional
-
moneromooo
No.
-
spirobel[m]
moneromooo: why not? is there anything I can read to understand why this limitation exists?
-
moneromooo
Deemed too confusing.
-
spirobel[m]
moneromooo: for the user or the implementor?
-
moneromooo
IIRC there's some discussion about this on the github PR for the patch that added subaddresses.
-
moneromooo
The user.
-
spirobel[m]
moneromooo: for me it is important. I want people to login to websites with their subaddresses similar to how metamask does it. Then I want to create integrated addresses for these users so they can sell stuff in a non fiduciary way on my website.
-
moneromooo
-
moneromooo
Only the default background refresh uses the chunked method atm.
-
spirobel[m]
<moneromooo> "spirobel:
github.com..." <- wow this is interesting! The refresh method is the method that will fetch new blocks and see if there was money for the wallet holder in the transactions, right? and because it would fetch lots of blocks at the same time it would get stuck in this loop and the rpc wouldnt be responsive until this loop got unstuck, right?
-
moneromooo
Yes and yes.
-
moneromooo
I expect wallet refresh to slow down, as this will preempt the overlap between processing blocks and fetching the next blocks.
-
moneromooo
Maybe fetching fewer blocks at once, and/or making at least N loops, will mitigate if it proves too much.
-
moneromooo
In any case, wallet concurrency is very basic now anyway.
-
spirobel[m]
<moneromooo> "In any case, wallet concurrency..." <- I like that monero-javascript has webworkers, so it is essentially like a multi threaded program.
-
Elijah[m]
elizabeth: hey when you do find an auditor for the xmr-eth swap, could you make sure they talk about how they audited the contract verification part done by Bob? I was looking at the code yesterday and I couldn't wrap my head around the part where event is used and how the parsing of the deployed contract is done. My concern for the swap is that a bad actor can deploy a fraudulent contract with the same parameters/attributes but the body
-
Elijah[m]
of the contract functions are rigged. Was this concern of mine already accounted for?
-
Elijah[m]
s/Was/Is/
-
elizabeth[m]
<Elijah[m]> "elizabeth: hey when you do..." <- hey yeah for sure, I implemented a check for that which checks that the on-chain contract code matches the compiled bytecode, but the problem is it's kind of janky right now since the compiled code isn't exactly the same as what ends up on chain (there's extra instructions in the compiled code) the current check *should* work, but it's a bit too hard-coded for my liking since it checks that
-
elizabeth[m]
specific parts of the bytecode match
-
elizabeth[m]
but definitely something really important
-
rbrunner
.merges
-
xmr-pr
8318 8324 8325 8326 8328 8330 8331
-
sethforprivacy
Friendly reminder we have an open PR from Trezor that will need to be merged before binary release:
monero-project/monero #8299
-
sethforprivacy
And we have a check-list to make sure we don't miss any important steps in the network upgrade:
monero-project/meta #690
-
selsta
sethforprivacy: it doesn't have to be merged before binary release
-
selsta
there can be a second release with wallet updates to support hardware wallets, we have done this in the past
-
selsta
seeing that there is no reply from ledger at this point, it will likely require second release
-
sethforprivacy
selsta: Good to know, thanks!
-
selsta
also we have to think what we will do about ledger
-
selsta
jberman[m] might have to help here with the integration :D