-
vtnerd
jeffro256[m]: just responded
-
luigi1111w
.merges
-
xmr-pr
8348 8513 8519 8534 8538 8547 8548 8551 8552 8553 8554 8555 8556
-
luigi1111w
yes
-
vtnerd
ukoehb: for 8329 Im just confused about the removal of some of the checks that I commented on
-
vtnerd
couldn't issues arise with intermediate messages too? or I am missing why the kludge specifically for the post-kex message was added
-
UkoeHB
vtnerd: the only check removed was 'is the multisig account done with kex?' if you pass in messages when kex is done then there will be a downstream error
-
UkoeHB
we need some way to get the post-kex message when an account is done with kex
-
UkoeHB
sorry: the only check removed was 'is the multisig account done being set up?' (includes kex and the post-kex verification check)
-
UkoeHB
if you think we should bite the bullet and add an rpc endpoint for the post-kex message, I can do that
-
UkoeHB
although without
monero-project/monero #7852, it's hard to actually test if the post-kex message is available at the end of kex (i.e. the round before `wallet2::multisig(&ready) -> ready == true;`)
-
jeffro256[m]
Is there a way to stop a CI build in the middle without force pushing?
-
MeowingCat
-
MeowingCat
./gitian-build.py -j 4 -o android --detach-sign --no-commit --build $GH_USER $VERSION
-
MeowingCat
this is failing with
-
MeowingCat
cp: cannot stat 'base-bionic-amd64': No such file or directory
-
user01cs98
has anyone had time to check this out?
pastebin.com/0ectpHLs
-
elucidator
user01cs98: not sure about the answer but paste is expired in case you didn't realize
-
user01cs98
-
elucidator
user01cs98: did you realize when you use 127.0.0.1 and localhost you used different ports
-
elucidator
sorry not 127.0.0.1 but 10.10.1.105 and localhost
-
sech1
also both monerod and monero-wallet-rpc bind port 18089 for some reason, of course there will be problems
-
elucidator
sech1: small thing : i just started compiling xmrig on a fresh fedora box, dependency installation line doesn't have some of the fundamentals like automake and tar :D
-
elucidator
the very minimal installation of fedora doesn't even have tar lol
-
elucidator
something like suggesting sudo dnf groupinstall "C Development Tools and Libraries" may have more coverage. ofc somebody who can't figure this out by himself is in much bigger trouble
-
selsta
jeffro256[m]: yes, but only in your repository
-
selsta
MeowingCat: you have to use the docker commands
-
rbrunner
selsta: IMO #8076 is ready for merge to master now, after jberman signed off the rebase and the latest (quite small) changes. Can you please have a look?
-
selsta
rbrunner: I was mostly curious how this patch works with large mempools
-
selsta
or txpool
-
vtnerd
yeah there should be an option in the dropdown
-
vtnerd
oops, I was scrolled up sorry, ignore
-
selsta
-
selsta
oh, it actually exists
-
moneromooo
I think it's a windows specific daemon replacement.
-
moneromooo
Because windows always special.
-
luigi1111w
.merges
-
xmr-pr
8348 8513 8519 8534 8538 8547 8548 8551 8552 8553 8554 8555 8556
-
hyc
right it just tells windows to auto-start a process as a headless service
-
dEBRUYNE
Anyone, by chance, tested whether the daemon automatically pops block off the wrong chain (and subsequently syncs to the correct chain) if a user forgot to upgrade and used 0.17 to sync?
-
sech1
this should happen automagically because 0.18 chain is longer now
-
moneromooo
Does it use old fork rules to pop ? I doubt it.
-
moneromooo
If not, it has the potential to bork the chain.
-
dEBRUYNE
moneromooo: Could you elaborate? Not sure I understand the question correctly
-
moneromooo
This is about the system that will pop blocks with the wrong version on startup.
-
moneromooo
I was asking whether, when popping these blocks, which happens with the new code, the consensus rules applied to the popped blocks were using the version from the blocks (old) or the new one.
-
moneromooo
The blocks were added with the old rules, so in order for the popping to properly revert, they should be reverted using the old rules.
-
moneromooo
So I was asking which rules version was used to pop.
-
moneromooo
If anyone knows offhand.
-
moneromooo
I know monerod will decide which rules to use based on height, which suggests the wrong version would be used, unless special care was taken.
-
moneromooo
(which it might have)
-
moneromooo
The difference between old code and new code is that, based on height, thy'll select differemt rules for blocks with height past the fork that got added in the new version, which the old version doesn't know about.
-
moneromooo
Quite often, there'll be no relevant difference in block popping, but it's not a given.
-
moneromooo
And if there are differences, pushing with old verison nad popping wit hnew version will not be idempotent.
-
moneromooo
If you'll forgive the spelling.
-
dEBRUYNE
Thanks for clarifying, I understand now (though don't have a proper answer)
-
dEBRUYNE
I asked in the first place because I was assisting two users where it seemed the daemon was not popping blocks
-
moneromooo
Is it trying and failing, or just not doing ? I think it should say so on default log settings.
-
moneromooo
In any case, "pop till before the fork height using the old version, then update" will always work.
-
moneromooo
(hopefully)
-
selsta
dEBRUYNE: users were able to just run the v0.18 daemon after updating too late and it worked correctly
-
dEBRUYNE
moneromooo: I will have to check my conversations with them, will get back to you on that