-
gingeropolous
hrm. could do a series of fast challenges that are somehow chained. Any latencies would be subsequently amplified
-
xmr-pr
ghdqh1515 opened issue #6904: Unknown CMake command "monero_crypto_autodetect".
-
xmr-pr
-
dEBRUYNE
Seeing a few reports of people being stuck on the fork block (v14). Any idea what could cause this?
-
dEBRUYNE
-
dEBRUYNE
-
ErCiccione
Lots of report in #monero as well.
-
ErCiccione
I just went out, cannot check my node now
-
sech1
what I know so far: block 2210720 has at least 2 MLSAG transactions which shouldn't be there. Nodes that were online at the time allowed it. Nodes that were offline and try to sync, don't allow it.
-
sech1
so they all get stuck at height 2210720
-
sech1
good news: all mining pools are fine, they just shouldn't pop blocks until the fix is issued
-
sech1
bad news: whoever was offline can't use Monero now
-
binaryFate
What's the fix? Allowing MLSAG transactions in block 2210720?
-
dEBRUYNE
<dEBRUYNE> I think the fix basically needs to make those two transactions seen as valid
-
dEBRUYNE
<dEBRUYNE> And use the MLSAG verification rules
-
dEBRUYNE
Think that would work
-
sech1
should work
-
rbrunner
Wonderful hack, but yeah, should work
-
sech1
so are we technically in chain split mode now?
-
rbrunner
A split with only 1 working chain?
-
sech1
one chain is stuck at 2210720, the other is at 2210941 now
-
sech1
well, makes it easy to choose
-
rbrunner
:)
-
sech1
things will get worse if some of those stuck nodes mines a block
-
sech1
and we'll have two alternative 2210720
-
dEBRUYNE
But 24/7 nodes synced properly through the fork
-
sech1
yes, so all miners should be fine, including solo miners
-
dEBRUYNE
So that would have to take someone syncing 'later' and then starting mining
-
sech1
well, someone might start their GUI wallet with mining on, sync to 2210720 and find a block
-
paulebert
stop_daemon
-
paulebert
my bad wrong window
-
dEBRUYNE
sech1: Difficulty would still be high though, so that would take some extraordinary luck
-
sech1
fingers crossed, but we're sitting on a ticking time bomb now
-
sech1
well, they'll just have to pop blocks after the fix then, but the less they have to do the better
-
rbrunner
Where would the MLSAG transactions come from to mine that block?
-
rbrunner
Or do I misunderstand?
-
sech1
they came from mempool
-
iDunk
The txpool
-
sech1
for some reason MLSAG were allowed to enter mempool and be mined after 2210000
-
sech1
which is a bad oversight
-
sech1
we wouldn't be here disussing it if they were banned from mempool after the 1st of 2 forks
-
dEBRUYNE
They were allowed due to the grace period
-
rbrunner
Ah, of course, it's a CLSAG block, not a MLSAG block, so no problems to get the necessary transactions.
-
rbrunner
But what if the decoys are too high? I think it wouldn't be easy to mine such a block.
-
sech1
grace period or not, but 0.16 wallets kept working all the way up to 2210720
-
moneromooo
So no node is mining in the right fork then ?
-
sech1
everyone is mining at 2210953 now
-
sech1
it's just 2210720 which is messed up
-
moneromooo
Looks fairly simple. The output check is done in check_outputs, which is called when adding a tx to the txpool, but not when checking a block that was mined.
-
moneromooo
So if hte rules change midway, it causes that...
-
moneromooo
I can add a v15 which adds the output check also when checking a block, and allow MLSAG in v14 I guess.
-
sech1
What's "the right fork" is a philosophical question now
-
moneromooo
And from v15, check outputs also after txpool.
-
sech1
everyone is on the strange chain now which shouldn't even exist
-
sech1
if you add v15, it should be announced in advance so all miners don't mine v14 blocks past the set height for it
-
sech1
not a quick fix
-
sech1
is it better to stay on v14 with an exception for these 2 tx?
-
rbrunner
A v15 seems pretty radical to me
-
sech1
I already see headlines "emergency hard fork"
-
sech1
it's not like everything is broken now, just syncing for old nodes
-
sech1
if having these 2 tx doesn't break anything but syncing for monerod <= v0.17.1.0, I don't see a need for v15
-
rbrunner
Maybe needs logic in quite a few places, to make those 2 tx fully normal, spendable, usable as decoys, etc.?
-
moneromooo
Well, any miner that adds a another MLSAG tx will cause this again, won't they.
-
sech1
this ^
-
sech1
so allowing MLSAG in v14 won't work
-
dEBRUYNE
Can't you allow it for a specific block only?
-
sech1
allowing MLSAG for 2210720 only seems like a good idea
-
iDunk
Has anyone checked if there are RCTv4 txes past 2210720 ?
-
moneromooo
Anyone from the core team has an opinion ?
-
sech1
then v15 is not needed at all
-
dEBRUYNE
Would personally prefer to avoid a HF
-
sech1
moneromooo you know better, if you can add exceptions for these 2 tx to make them spendable and syncable
-
rbrunner
binaryfate was in /monero about 10 minutes ago.
-
moneromooo
Yes, I could do that. It's simple.
-
» iDunk votes for v0.17.2.0 which should be marked as mandatory.
-
sech1
0.17.2.0 "bugfix" release is better than "hardfork" release
-
sech1
I guess they can be used as decoys already, so it's all about syncing and spending
-
sech1
and double check it's only 2 MLSAG tx in that block, I only did a quick look.
-
rbrunner
Did somebody check higher blocks for other such problematic tx?
-
sech1
I checked a few next blocks
-
sech1
I guess we'll find out once the fix is in and someone tries to sync with it
-
binaryFate
bugfix is definitely better than hardfork if possible
-
rbrunner
I guess it becomes pretty improbable quickly after the hardfork
-
rbrunner
To have such tx at hand at all to put them into blocks
-
moneromooo
Only if an asshole miner puts one in :)
-
sech1
mempool was cleared after 2210720 as far as I can see, so it's unlikely more MLSAG were added
-
aubergine
Hi, any news on monero php library?
-
aubergine
apparently most wallet RPC calls involving arrays fail
-
aubergine
an example:
-
binaryFate
would the fix allow for a possible alternative chain to be mined, where a different block but with similar issue would be mined at 2210720, without again having a fork butween 0.17.1 nodes and the bugfixed ones?
-
aubergine
Request have return error: Parse error. Request: {"jsonrpc":"2.0","method":"make_multisig","params":{"multisig_info":[null,null],"threshold":2,"password":"mypassword"},"id":14};
-
binaryFate
If not, we're effectively hardcoding that the current chain can't be rolled back past a specific number of blocks which is not great
-
moneromooo
How about we just allow MLSAG always for now ?
-
moneromooo
It protects against someone mining one later.
-
sech1
how can someone mine it later if nodes will reject it?
-
moneromooo
That's what happened.
-
dEBRUYNE
aubergine: Could you use #monero for a bit?
-
moneromooo
Ah wait.
-
moneromooo
It lonly got accepted by nodes that already hjad it in their txpool. So yes, very unlikely to happen again...
-
aubergine
dEBRUYNE ok no prob
-
sech1
handle_incoming_block or whatever it's called will reject any block with MLSAG
-
sech1
I've checked blocks up to 2210730 manually and I don't see any MLSAG tx there
-
sech1
a few of these blocks were empty, so mempool cleared
-
dEBRUYNE
If the assumption of a one-off is correct, there shouldn't be any more after 2210720
-
rbrunner
Maybe it's not one-off, but "tx still in mempool"?
-
rbrunner
And if that cleared, it should be over
-
sech1
As I understand from moneromooo's comments, it's about having MLSAG in the mempool by the time height hits 2210720
-
sech1
after that MLSAG won't be allowed into the mempool
-
rbrunner
That's also my understanding, yes
-
moneromooo
Anyone has the txids of those txes ?
-
moneromooo
I've got one.
-
sech1
yes
-
moneromooo
c5...
-
iDunk
6f2f117cde6fbcf8d4a6ef8974fcac744726574ac38cf25d3322c996b21edd4c
-
iDunk
c5151944f0583097ba0c88cd0f43e7fabb3881278aa2f73b3b0a007c5d34e910
-
sech1
-
moneromooo
ty
-
TheCharlatan
^ that's the two I identified as well
-
sech1
it'll be easy to verify the fix though - if some txid is missing from the exceptions, it won't sync
-
iDunk
I have a stuck daemon and one that's below v14 fork height so I can build and test.
-
moneromooo
Looks like I'm synced to ...963 now.
-
sech1
yes, that's the current height
-
sech1
I'm here to review your PR if it's coming soon
-
moneromooo
If would be here if debian.net oculd connect... One min..
-
moneromooo
-
moneromooo
I'll PR.
-
sech1
looks good for sync fix. No changes needed to make them spendable?
-
MoneroArbo
sorry if this is dumb but it seems cleaner to retroactively move fork height to 2210721 if possible
-
sech1
it won't work
-
MoneroArbo
got it
-
sech1
2210720 already has v14 version baked in
-
hyc
testing my export/import hacks now
-
TheCharlatan
sech1, no extra changes needed.
-
sech1
got it. If they can be used as decoys already, so they should be spendable since it's all decoys to a node
-
moneromooo
There's nothing special about them wrt spendable of anything else than they're not supposed to be accepted past v14.
-
sech1
no need for v15 hf then. Leaves one more scar in the code, but whatever... At least the fix is all in one place
-
moneromooo
So for next fork, we might need to check outputs in handle_block_to_main_chain, which might give a speed hit. I'll have to think about this.
-
sech1
Just don't allow old type of tx into the mempool right after the first fork height, but let them be mined until the second fork height?
-
binaryFate
so what will be required from users now then, either update to a newly-released 0.17.2 or keep their current 0.17.1 software but apply the export/import hack?
-
sech1
0.17.1 with export/import hack should also work
-
sech1
because it worked for me until I stopped my node and popped blocks
-
sech1
0.17.2 is certainly recommended update
-
selsta
v0.17.2.0 will lock Ledger users out, I guess they have to wait a couple day(s) then
-
» selsta still annoyed at the version lock
-
rbrunner
Can confirm the fix to work, my daemon syncs to top with the PR cherry-picked
-
sech1
on the positive side, 0.17.0.0/1 which have Dandelion propagation bug, will be replaced quicker
-
selsta
moneromooo: opinion on bumping out-peers a bit or not for this release?
-
rbrunner
Good idea
-
binaryFate
+1 more out_peers
-
sech1
+10 more out_peers
-
moneromooo
So every time we fix a bug, ledger stops working ?
-
rbrunner
Seems so, yes. If we bump the version number.
-
dEBRUYNE
or keep their current 0.17.1 software but apply the export/import hack? <= Should work as long as you already synced past the fork height I guess
-
dEBRUYNE
Or alternatively, the export/import hack
-
selsta
we can bump the patch number, otherwise it is hardcoded
-
xmr-pr
xiphon opened pull request #6907: [release-v0.17] wallet2_api: implement stop() to interrupt refresh() l...
-
xmr-pr
-
xmr-pr
moneromooo-monero opened pull request #6906: blockchain: fix sync at v14 boundary
-
xmr-pr
-
xmr-pr
moneromooo-monero opened pull request #6905: blockchain: fix sync at v14 boundary
-
xmr-pr
-
hyc
if that's fixed, do we need the export/import hack then?
-
hyc
I guess it may still be useful to have regardless
-
dEBRUYNE
No, would be easier for users to simply upgrade
-
dEBRUYNE
Also +1 here for bumping out_peers
-
rbrunner
Well, that import/export hack isn't a hack, just that the tools learned something new, no? Or did you hardcode the block number?
-
binaryFate
technically not a hard fork but it's still very similar if only option is "you must" update now
-
hyc
rbrunner: nothing hardcoded.
-
hyc
yeah just a new feature
-
hyc
and it would allow us to post incremental .raw files
-
iDunk
I doubt bumping out_peers will help much, but yes, +1 from me, too.
-
dEBRUYNE
binaryFate: HF would be 'messier' though as it requires pools to upgrade as well
-
Criispin57
isn't the cleaner approach to allow mlsag for a little longer in my opinion hardcoding those 2txs as exception seems kinda dirty
-
dEBRUYNE
Pools don't necessarily need to upgrade now
-
ffnopeg
what's the import/export commands I should use for this?
-
binaryFate
true still quite better than hardfork
-
sech1
Criispin57 that would require another hardfork to v15 if we allow MLSAG in v14. We can't just bump it to 2210721 height.
-
sech1
pools don't need to upgrade as long as they don't decide to pop 1000 blocks for some weird reason...
-
nssy
patch is working. All synced up.
-
Criispin57
sech1 yes i know
-
PatBoy
the patch is working here too, thx
-
rbrunner
Now we just inform the owners of those two outputs to spend them to finalize testing ... oh wait :)
-
iDunk
Works here on Linux and Windows.
-
sech1
moneromooo no CLI wallet update needed, I hope?
-
moneromooo
Shouldn't need to.
-
sech1
because I'm so paranoic with CLI wallet updates :D I check signatures/hashes 5 times or more...
-
sech1
and update once a year...
-
sech1
and use a canary wallet with small amount to check if anything gets stolen after I open it with new binary :D
-
dEBRUYNE
Any of the maintainers online btw? luigi1111, Snipa, fluffypony?
-
xmr-pr
90hacker opened issue #6908: There were 0 blocks in the last 90 minutes
-
xmr-pr
-
ffnopeg
did someone write up the workaround with import/export? I'd prefer that than getting a new release
-
sech1
import/export need to be rewritten a bit to make this work
-
iDunk
I just realised one of my daemons got eclipsed shortly after the fork. I'd expect the same to happen with, say, 16 out peers.
-
TheCharlatan
moneromooo checking the tx version in handle_block_to_main_chain should be easy enough right? Don't have to check validity again, since they are already in the pool.
-
iDunk
Feels like these... research... nodes are >50% of the network.
-
moneromooo
It should be enough for the MLSAG/CLSAG switch, but it'd have to be changed for every fork for whih we change output rules.
-
selsta
so could something like this has happened at every fork?
-
selsta
have*
-
TheCharlatan
the way I see it, yes for any fork that changes the tx format.
-
Inge-
iDunk: are the "research" nodes the same as "Troll" nodes?
-
iDunk
Well, Idk what they've been called elsewhere :)
-
iDunk
But probably, yes.
-
rbrunner
Think so. I also think they are more prevalent in Europe.
-
rbrunner
But not sure
-
Inge-
are they computationally inexpensive to set up? e.g. don't need the blockchain as they just report your own block height?
-
rbrunner
I am not sure somebody already checked how far they work, whether they are true (but doctored) nodes or something else
-
Inge-
maybe nodes need a handshake proving they actually hold the chain - ask each other for a few random blocks e.g.
-
xmr-pr
emesik opened issue #6909: Transfer back to same wallet shows up only in outgoing transfers
-
xmr-pr
-
iDunk
I guess privacy opponents are using, what I'd call, network smothering techniques against Monero.
-
hyc
Inge-: a fake node could always ask a real node for the answer
-
moneromooo
Alice connects to Bob, sending a tx she wants. Bob replies with a tx he wants. Alice sends that tx. Bob sends the tx Alice had asked for. Handshake done. Then you can't ask another node for a block if you don't have at least that much synced.
-
moneromooo
s/sending a tx she wants/sending the hash of a tx she wants/
-
hyc
PR#6910 pushed, export with --block-start=2210718 --block-stopp=2210721
-
hyc
if you've popped back to 2210719 you can import with --dangerous-unverified-import=1
-
hyc
and daemon will then sync past the problem
-
hyc
I can also upload a 3-block .dat file if anyone wants it
-
hyc
-rw-r--r-- 1 hyc hyc 137194 Oct 18 13:27 blockchain.raw
-
iDunk
cp blockchain.raw .
-
hyc
e7c0a70b5d0cc87fe2ffab07324d2246f63be98af4305700862d5242b03aa151 blockchain.raw
-
hyc
-
hyc
hmmm wait, permission problem
-
hyc
ok there it goes
-
ffnopeg
how can someone use this .raw file?
-
hyc
you must recompile monero-blockchain-import with PR#6910 applied
-
Snipa
Sup?
-
Snipa
dEBRUYNE
-
Snipa
?
-
Snipa
That insnaity being fun I assume?
-
sech1
we had a lot of fun this morning
-
sech1
nodes stopped syncing
-
sech1
block 2210720 is technically invalid and requires a code patch
-
Snipa
Ye, I saw a bit earlier
-
dEBRUYNE
Snipa: We basically need to do a release soon and some PRs need to be merged
-
dEBRUYNE
Would consult with moneromooo for the specifics though
-
Snipa
Releases, I've yet to do, merges, I'm gine with in general.
-
xmr-pr
selsta opened pull request #6911: build: prepare v0.17.2.0
-
xmr-pr
-
xmr-pr
hyc opened pull request #6910: Allow setting start block on export
-
xmr-pr
-
moneromooo
Yes, I got a couple patches you can merge, 690[56]. Thanks ^_^
-
Snipa
Gimme a sec, getting logged in, work auctually woke me up. :P
-
Snipa
Aha! I didn't bork it up. Delightful.
-
Snipa
690[56] merged.
-
moneromooo
ty
-
Snipa
Into their proper branches even.
-
Snipa
Any other changes that we want to get checked into this? I see 6911 contains the version and checkpoint update for .17.2 and I've verified the checkpoint block.
-
Snipa
I do see Xiphon's got 6907 ready to go in and approved, but less sure as we're sort of just patching this one issue, no?
-
Snipa
.merges
-
xmr-pr
6862 6875 6881 6882 6886 6891
-
xiphon
Snipa: "Any other changes that we want to get checked into this?"
-
xiphon
yep
-
selsta
would be nice if we could include GUI fixes else we will have to do another release soon
-
xiphon
will submit one
-
selsta
which is just extra work
-
xiphon
in a few
-
selsta
Snipa: will ping you once I have the merge lis
-
selsta
list*
-
Snipa
kk.
-
Snipa
I'll be here for a bit.
-
» Snipa gets some coffee.
-
sech1
is there a PR which bumps number of out_peers?
-
sech1
we discussed bumping it like an hour ago here
-
xiphon
sech1: "is there a PR which bumps number of out_peers?" -> seems not
-
hyc
Snipa: 6912 also
-
Snipa
kk, as soon as we get a proper review on it, will vacuum in.
-
hyc
cool
-
moneromooo
6912 in the .3 ?
-
hyc
are we on .3 already?
-
xiphon
-
hyc
but yeah I think it should go in whatever is the next point release
-
xmr-pr
xiphon opened pull request #6914: [release-v0.17] wallet2: wait for propagation timeout before marking t...
-
xmr-pr
-
xmr-pr
xiphon opened pull request #6913: wallet2: wait for propagation timeout before marking a tx as failed
-
xmr-pr
-
xmr-pr
hyc opened pull request #6912: Allow setting start block on export [release-v0.17]
-
xmr-pr
-
Snipa
Poor bot. :(
-
xiphon
Snipa: and would be great if you merge
monero-project/monero #6907 so we can use the fix in the GUI
-
dEBRUYNE
selsta: Would it perhaps be wiser to merge them after the release?
-
dEBRUYNE
Mitigates the surface for errors for the CLI release
-
dEBRUYNE
Which is kind of crucial
-
dEBRUYNE
We can simply set the submodule to the release branch for the GUI instead of the tag
-
Snipa
^ is the only reason I'm considering not merging more, but I'm open to whatever list we want to jam together as long as we get eyes on them to make sure we're all happy :)
-
xiphon
dEBRUYNE: Snipa: yep, that's okay to skip the PRs i recently sent for now
-
selsta
so we set the submodule to release-v0.17 for gui?
-
selsta
because I would like to include them in GUI release
-
dEBRUYNE
Yes
-
Snipa
:) Once we get final merges in for the .2 release, assuming proper reviews, I can merge the next ones in after.
-
dEBRUYNE
So basically merge mooo's fix, hyc's PR, your 'prep for release' PR
-
dEBRUYNE
Then we tag
-
dEBRUYNE
Then merge the PRs relevant for the GUI
-
dEBRUYNE
-> set submodule to release-v0.17
-
dEBRUYNE
<dEBRUYNE> So basically merge mooo's fix, hyc's PR, your 'prep for release' PR <= Plus the 'bump out_peers' PR I guess
-
xiphon
'bump out_peers' PR
-
xiphon
^ i don't see one
-
moneromooo
I'll make one then.
-
xiphon
cool
-
moneromooo
s/8/12/ seems ok ?
-
sech1
ok to me
-
selsta
yes
-
sech1
Although I'm running with 25 now, but it's better not to overload the network
-
selsta
fwiw CLI would also benefit from 6913, multiple people have asked why their tx gets marked as failed
-
binaryFate
16?
-
sech1
out_peers seems an arbitrary number, but high values will put more pressure on nodes
-
sech1
more bandwidth, more CPU
-
dEBRUYNE
selsta: I guess we could include that one then
-
dEBRUYNE
Wrt value, 16 seems appropriate
-
moneromooo
Done, still building though.
-
moneromooo
Seems to work fine.
-
moneromooo
The assholes seem to be reporting height 0 now.
-
gingeropolous
do seed nodes need to be updated with this patch? or is this mainly an IBD / sync bug?
-
xmr-pr
moneromooo-monero opened pull request #6916: bump default number of connections from 8 to 12
-
xmr-pr
-
xmr-pr
moneromooo-monero opened pull request #6915: bump default number of connections from 8 to 12
-
xmr-pr
-
moneromooo
Ah, back to my height.
-
moneromooo
If they're not on the right chain, yes.
-
moneromooo
Or I guess... if they're on the right chain, but not at the tip yet :)
-
selsta
out-peers should be fine with 12 for now, would not go to 16
-
M5M400
sech1: I'm running in64, out64 on muh public node and it rarely breaks a sweat on the 4core VM it runs on
-
M5M400
16 should be fine
-
sech1
bandwidth can be an issue with many peers
-
sech1
not CPU
-
sech1
not everyone is on 1 Gbit connection
-
selsta
we can increase it further in a later point release if necessary
-
M5M400
but you can limit bandwith seperately, no?
-
sech1
bandwidth limit is separate already and can be changed in command line, yes
-
selsta
my preferred list for this release would be: 6907 6911 6912 6914 6916
-
M5M400
my pub node never broke 3MBps daily avg in the past month lol
-
M5M400
maybe I'm doing it wrong
-
selsta
6914 and 6912 need an approval
-
xiphon
given that the only effect of raising out peers count is mitigating node complete isolation by *asshole* peers
-
xiphon
setting out peers 12 instead of 8 by default
-
xiphon
is 16 times better :)
-
xiphon
cause you only need at least one good peer
-
xiphon
IMO 12 is okay for now
-
M5M400
fair enough
-
sech1
xiphon are you assuming 50% of peers are *assholes*?
-
sech1
Ok, I'll increase my node to in/out 64 to be that one good peer :D
-
xiphon
i did some calculations with 50-70 and 90% of assholes
-
xiphon
but i an't simulate the peer list poisoning effect in the calculations
-
xiphon
^ that's what they actively exploit
-
xiphon
and that's what has a huge effect
-
selsta
sech1: in is unlimited by default
-
ak77
Hi. I switched my seed to monerujo, and when I tried to transfer my balance to another wallet, it gave me an error saying that I wasnt connected to the daemon. Then after closing the wallet and opening it again, my balance no longer appeared there and no transactions are shown. The seed is the right one since the address is the same.i switched to different wallets and nodes, but still nothing.
-
hyc
ak77: not a question for this -dev channel
-
selsta
#monero please, but try to set a good remote node, e.g. node.xmr.to 18081
-
ak77
Switched nodes, wallets, etc. Nothing
-
ak77
Ok sorry.
-
selsta
hyc: do you think we should include import / export fix in this point release?
-
selsta
it would not be necessary but you coded it already, so I guess depends on what you prefer
-
hyc
well, if no one else is testing/reviewing it, drop it
-
selsta
i can test it but would prefer if someone else reviews it
-
sech1
ok, here's an "unstuck" node python script I haven't tested yet:
paste.debian.net/hidden/f31701d6
-
moneromooo
I reviewed. One problem, but it might be an existing one, in which case we don't actually care.
-
luigi1111w
fun
-
xiphon
sech1: actually is a good regression test
-
dEBRUYNE
-
dEBRUYNE
cc M5M400
-
selsta
moneromooo: oki, only thing remaining would be 6914
-
M5M400
dEBRUYNE: thx
-
luigi1111w
I can tag in the next 20 minutes if stuff is ready
-
binaryFate
I can sign & publish on website whenever too
-
moneromooo
6914 seems plausible at first glance...
-
selsta
it would be a temporary workaround until vtnerd adds something else
-
luigi1111w
why not 17.1.1 ?
-
selsta
v0.17.1.1 would be fine for me too tbh, we would avoid ledger issues, and if someone has sync issues they will have to update anyway
-
selsta
any opinions?
-
hyc
moneromooo: ok, replied to your comment. the existing code already did that...
-
moneromooo
I'd use m_sent_time instead of m_timestamp.
-
moneromooo
OK, thnaks
-
selsta
xiphon: ^
-
xiphon
on it
-
M5M400
+1 on v0.17.1.1
-
selsta
binaryFate: are you available in the evening?
-
binaryFate
yes
-
luigi1111w
moneromooo> So for next fork, we might need to check outputs in handle_block_to_main_chain, which might give a speed hit. I'll have to think about this. <= I don't understand why ml/clsag is in the outputs check
-
selsta
okay, will be afk the next hours so can’t get bins ready now
-
selsta
but should have time in evening
-
moneromooo
That's a good point. I guess I put it there because similar chceks were there for outputs :D
-
binaryFate
would be great to have someone else build too
-
luigi1111w
let's give it a few more hours to see if any patches should go in
-
moneromooo
6914 looks fine
-
luigi1111w
we should probably "fix" it at some point besides just relying on network mempool state :P
-
selsta
I will change to v0.17.2.0 to v0.17.1.1 unless someone is against it
-
dEBRUYNE
selsta: If we want people to upgrade, I think v0.17.2.0 sends a stronger message than v0.17.1.1
-
rbrunner
Hmm, 0.17.2.0 would be easier to recognize as something new. Remember how some people confused 0.17.0.1 and 0.17.1.0
-
selsta
dEBRUYNE: but people will have to update anyway
-
dEBRUYNE
On the other hand, it basically locks Ledger Monero users out of their wallet again
-
selsta
if they are stuck
-
ffnopeg
I'm not sure I follow that, people are literally unable to use it right now
-
binaryFate
But they'll be forced to update anyway
-
ffnopeg
exactly
-
dEBRUYNE
Yes, good point
-
dEBRUYNE
I guess rbrunner's point still applies though
-
selsta
anyway, I will message ledger anyway and suggest them to remove the version lock
-
iDunk
selsta: I think v0.17.1.1 should be the minimum version for v14 in the table then.
-
binaryFate
dEBRUYNE: if we go with that you should update your reddit post to say 0.17.1.1
-
dEBRUYNE
Will repost then, yes
-
hyc
moneromooo: actually, this probably needs fixing. it looks like it won't read the entire struct
-
hyc
I thought it was only reading the length. lemme check again.
-
hyc
it's using bootstrap_serializer tho
-
Inge-
Will 17.2.0 break Ledger, while 17.1.1 will not? (assuming current ledger version should still work with todays upcoming release)
-
selsta
iDunk: done
-
selsta
Inge-: yes
-
hyc
ah never mind, the parsing is all good
-
selsta
merge list: 6907 6911 6912 6914 6916 6917
-
selsta
then tag
-
xmr-pr
selsta opened pull request #6917: README: update fork table recommended version
-
xmr-pr
-
dEBRUYNE
So we're going with v0.17.1.1?
-
selsta
yes
-
dEBRUYNE
Ok, will repost then
-
ErCiccione
Selsta will you make a blog post for this? I assume we want to spread this as much as possible. So mailing list message as well?
-
ErCiccione
I'll be back
-
ErCiccione
To my laptop in an hour or so
-
binaryFate
I think it's ok to wait for release and binaires to be ready before sending message to mailing list. Assuming this all happen today. Opinions?
-
dEBRUYNE
-
ffnopeg
yes it's less confusing to send the message after the binaries are out
-
dEBRUYNE
binaryFate: Why not two messages?
-
selsta
prepare v0.17.1.1 needs review / approval
monero-project/monero #6911
-
selsta
binaryFate: I will not get GUI bins ready today
-
dEBRUYNE
The first message can simply state that a release is following shortly
-
ErCiccione
binaryFate: yeah sure. Better to let people know when we have the solution
-
dEBRUYNE
You can copy the text from the Reddit PSA if you want
-
ffnopeg
you can see how large exchanges such as binance and huobi had 0 preparation for this even though it was a very simple upgrade in node terms
-
binaryFate
selsta: I think the mailing list is mostly for exchanges/services. So as soon as we have the new release of daemon it's fine
-
ffnopeg
I wouldn't want to make them even more confused
-
binaryFate
and we can just say GUI will follow shortly
-
ErCiccione
If the release is superclose, i would go for only one message
-
selsta
ok
-
luigi1111w
is Snipa or fluffypony around to do merges?
-
ErCiccione
Selsta if you are busy i can take care of that. No worries.
-
sech1
Confirmed, I was able to unstuck my 0.17.1.0 node with this script:
paste.debian.net/hidden/a94081ea
-
binaryFate
dEBRUYNE: let's see how we're doing on release later but I think it's fine to wait few more hours for mailing list message with release ready. It's not security critical and worse case people are just stuck, but most exchanges and services have deposits and withdrawals disabled anyway
-
haxx0r
dEBRUYNE is the best. hands up for him!
-
binaryFate
I'll be afk for an hour or two but available after that for bins or site update
-
dEBRUYNE
binaryFate: Yeah if we are going to release in a few hours it will be okay
-
gingeropolous
Height: 2211067/2211067 (100.0%) ???
-
M5M400
seems about right
-
gingeropolous
word
-
ffnopeg
-
fluffypony
luigi1111w: I am
-
selsta
6911 and 6917 require an approval then we can merge and tag
-
fluffypony
checking
-
selsta
also fluffypony can you check your seed nodes, two seem down
-
fluffypony
which IP addresses?
-
selsta
but that is less priority now
-
selsta
-
fluffypony
tks
-
sethsimmons
Can we put out a PSA on Twitter for this? Or do we want to wait for binaries for the official account to tweet it?
-
fluffypony
ok 6911 and 6917 are merged
-
selsta
wait
-
selsta
merge list: 6907 6911 6912 6914 6916 6917
-
selsta
that's the full list, all should be approved
-
fluffypony
ok
-
fluffypony
ok all merged
-
fluffypony
also fixed seed nodes, the LANG / LC_ALL issue strikes again
-
selsta
ty
-
selsta
will check if everything is good and then ping you if we can tag
-
selsta
fluffypony: ok, looks good you can tag v0.17.1.1
-
dEBRUYNE
sethsimmons: Probably best to wait until the binaries are available
-
fluffypony
just a note on release engineering is that it looks like tag annotations are incomplete for 0.16 and 0.17 point releases
-
fluffypony
also 0.15.0.5
-
fluffypony
not worth fixing retrospectively, but just a note moving forward
-
fluffypony
I think relevant to binaryFate
-
fluffypony
tag is pushed
-
selsta
afaik luigi adds annotations
-
fluffypony
ok whoever is tagging then :)
-
selsta
but maybe he forgot
-
selsta
a couple times
-
hyc
ok, I've fetched the tag and started a gitian build
-
selsta
thanks
-
luigi1111
what does incomplete mean
-
fluffypony
luigi1111: I'll pastebin
-
luigi1111
thx
-
fluffypony
-
fluffypony
that's from git tag -l -n9
-
fluffypony
it's just the extra bit in the annotation
-
luigi1111
ok got it. let me investigate when I'm home
-
sethsimmons
<dEBRUYNE "sethsimmons: Probably best to wa"> Understood.
-
luigi1111
at least I didn't release "Wolfram Worptangent"
-
hyc
lol
-
fluffypony
that ones on me lol
-
fluffypony
guess who copy-pasted
-
hyc
we should include in the announcement "rumors that this bug was due to nation-state attackers are fake news"
-
dEBRUYNE
Reverse psychology? :p
-
hyc
:D
-
fluffypony
LOL
-
dEBRUYNE
To be honest, wouldn't be surprised if someone sent those txes on purpose to mess with the network
-
ErCiccione
lol. i thought you were serious for a moment
-
fluffypony
it's due to Hunter Biden handing his Monero node in for repairs
-
hyc
lol
-
ErCiccione
good that you restored LAW & ORDER
-
PlasmaPower
When they send their ring sigs, they're not sending their best. They're sending ring sigs that have lots of problems. They're bringing MLSAGs.
-
sethsimmons
Is there an RCA on this? Curious to hear what caused the bug but have been out of the loop the past couple of days
-
hyc
can neither confrim nor deny
-
hyc
sethsimmons: yes the bug was simply that MLSAG txs were validly accepted into the txpool
-
hyc
and were still in the pool after v14 took effect
-
TheCharlatan
building binaries as well fwiw
-
sethsimmons
<hyc "sethsimmons: yes the bug was sim"> Ah ok, so the grace period bled over via the TX pool and borked nodes
-
sethsimmons
Odd that mine didn’t get stuck at that height and continued normally
-
sethsimmons
Even though it was running during the fork
-
hyc
only nodes that were running during the fork kept going
-
sethsimmons
Ahhh, I had it backwards.
-
sethsimmons
Thanks for the info
-
hyc
or: only nodes that already had the tx in their txpool kept going
-
hyc
(2 txs)
-
gingeropolous
do those 2 transactions actually verify?
-
sech1
Yes, I was able to unstuck my 0.17.1.0 node by manually filling mempool with TXs from block 2210720 in offline mode
-
sech1
those 2 verified fine because it wasn't v14 when they popped up
-
gingeropolous
i see the patch just effectively says "txs with these hashes ok". they are in a block, so presumably the miner did verify, but i know things can get noodly
-
sech1
so they were verified at v13 "era", but included in the first v14 block
-
kayabaNerve
I rather it just allow any MLSAG TX in the first v14 block, personally. That's a philosophical stance though.
-
gingeropolous
ok. makes sense. how'd you manually fill?
-
gingeropolous
yeah kayabaNerve i agree
-
sech1
I pasted a python script here before
-
sech1
-
kayabaNerve
-
gingeropolous
write a different patch yo
-
kayabaNerve
Or yeah, what sech1 posted
-
gingeropolous
lets watch the sparkles sparkle
-
hyc
are we having a dev metting today? it would be in about 8 minutes if so
-
hyc
meeting
-
hyc
kayabaNerve: the difference is mostly academic. Unless someone mines a longer chain and causes the current main chain to rollback all that way
-
hyc
otherwise, it's a situation that will never occur again, so makes no difference
-
gingeropolous
off the cuff it feels like "devs say tx ok" vs "previous protocol says tx ok"
-
TheCharlatan
I prefer it as is. Mistakes should be transparent.
-
TheCharlatan
hyc do you want to kick-off the meeting?
-
kayabaNerve
TheCharlatan: We can easily change the existing if statement and leave the same commentary to explain the history behind that exclusion. Then there's no need to have the Monero node specially recognize any transaction.
-
kayabaNerve
But yes, it's purely academic/philosophical.
-
MoneroArbo
+1 kayabaNerve's suggestion. also, this may be a dumb Q, but if somebody submitted a malformed transaction with the with the excepted hashes would, would they be allowed?
-
MoneroArbo
be the current fix that is
-
moneromooo
No.
-
MoneroArbo
cool
-
moneromooo
But if you can brute force keccak, you might be able to brute force something else that make a bad tx valid.
-
hyc
so we are meeting now?
-
hyc
no meta issue, no agenda
-
moneromooo
If people have things to say, they should feel free.
-
hyc
I guess the conv about the bug & patch can just continue then
-
sech1
"Unless someone mines a longer chain and causes the current main chain to rollback all that way" <-- then these 2 TXs wouldn't even appear again and the patch would just be dead code
-
sech1
other MLSAG TXs could appear in 2210720 though...
-
sech1
if it's a malicious attacker who has 51% and knows the details of this bug
-
sech1
but no
-
sech1
0.17.1.1 wouldn't accept new 2210720 block with different MLSAG TXs
-
sech1
so all good
-
ErCiccione
btw, thanks everybody for working on the issue so quickly. it's really amazing to see the quick reaction and the amount of people working together to fix this issue.. and on a sunday. You are the engine that makes this boat going. Thank you really much, folks. Keep being awesome
-
TheCharlatan
moneromooo I don't understand your hesitation for calling check_tx_ouputs from handle_block_to_main_chain
-
TheCharlatan
seems cheap enough to me.
-
iDunk
-
sech1
then we'd be all stuck at 2210720 - miners would just keep adding these 2 TXs and all mined blocks would be rejected
-
selsta
iDunk can you upload to mega?
-
moneromooo
I hesitate because it mgiht be too slow.
-
iDunk
I always understood that the grace period of one day was to allow older version txes that are already in the txpool to get mined, not to still allow them in the txpool. Otherwise, the grace period serves no purpose.
-
sech1
yes, that was an oversight
-
iDunk
selsta: I will soon. Can't right now.
-
moneromooo
I looked now, and it seems fast. I thought it'd do range proofs.
-
moneromooo
A better way might be to revalidate the txpool on fork switch.
-
moneromooo
That should catch everything.
-
hyc
yeah that sounds better overall
-
hyc
delete txs from pool if they're obsolete
-
hyc
one-time computation cost instead of on every block
-
moneromooo
Though that'll be a bit annoying, since if we at the block before a fork, the previous rules apply, but after the block gets mined, the new rules will apply to check it.
-
moneromooo
So some work will have to be done there.
-
gingeropolous
do we know which pool mined the block?
-
hyc
then expire the txs when block N-1 has been mined
-
hyc
it was a 24hr grace period. those txs shouldn't succeed anyway.
-
PlasmaPower
gingeropolous: I don't think the miner/pool was malicious. They just had the txs in their txpool too, right?
-
hyc
probably
-
hyc
so instead of a tx flooding attack, we have a dummy node flooding attack? and that's why number of outpeers is bumping from 8 to 12?
-
Inge-
in which case, if I was running the dummy nodes, I increase my node count by 50%
-
hyc
right
-
binaryFate
<sech1> so they were verified at v13 "era", but included in the first v14 block <-- following up on gingeropolous's concern, how would future users know these transactions were not blindly whitelisted?
-
PlasmaPower
I think the if checking for those hashes is only in the path where it's an MLSAG post-fork, so the only thing it's blindly whitelisting is allowing an MLSAG post-fork
-
PlasmaPower
it wouldn't allow a double spend or bad range proof, even if those hashes corresponded to one (which they don't)
-
binaryFate
Ok I guess I'm not clear on the grandfathering thingy
-
sech1
the "whitelisting" is not actually whitelisting, it only allow MLSAG format for these 2 tx after v14, that's all it does
-
sech1
everything else should be checked as usual
-
binaryFate
ok
-
binaryFate
TheCharlatan: you're merging the gitian PR usually right?
-
TheCharlatan
yes, but there are only my sigs posted vor v0.17.1.1 right now.
-
iDunk
I'll be at my PC in about 20 minutes.
-
hyc
my build just finished
-
hyc
-
hyc
if those hashes are good, I'll submt sigs shortly
-
moneromooo
-
hyc
ah ok
-
hyc
didn't see it
-
hyc
cool, matched
-
binaryFate
I thought it was a shit Sunday but then I discovered this repeated Worptangent tag
-
hyc
lol
-
hyc
could've been Worf Tangent
-
binaryFate
hyc can you PR your sigs soonish?
-
TheCharlatan
binaryFate hyc's and iDunk's are merged. I don't merge my own without at least one approval.
-
binaryFate
nice sorry I missed hyc's one. Please check scoobybejesus's one I think it's just fixed
-
selsta
I will not do reproducible builds today, busy with release notes and GUI later
-
binaryFate
selsta: ok
-
selsta
please feedback for release notes:
paste.debian.net/hidden/4e961fb6
-
TheCharlatan
binaryFate, yes merged his as well.
-
sech1
"Allow setting start block on export" maybe say monero-blockchain-export to avoid confusion
-
selsta
ok
-
ErCiccione
I would add a notice in bold to make people understand the it's important that they upgrade or they could have issues
-
binaryFate
selsta: I take it you took the hashes from someone and I do not assume you built yourself right?
-
binaryFate
Not that it changes anything for release, just for clarity
-
selsta
I took them from hyc, though they should match the ones posted on gitian repo
-
binaryFate
oki
-
sgp_
should we also include a more detailed explanation of the bug?
-
sgp_
-
sech1
this is only my understanding, I might miss some details
-
selsta
if someone uploaded the binaries please ping me
-
binaryFate
I'm on it, takes a while
-
gingeropolous
is this 0.17.2? oh i guess its already tagged. this version is now the only one that will sync right?
-
gingeropolous
well, not like the version numbering is tied to consensus i guess
-
selsta
make sure to use release-v0.17 branch and not master
-
selsta
master is kinda behind
-
binaryFate
gingeropolous: no it's 0.17.1.1
-
gingeropolous
right. in my head i've always wanted release #
-
gingeropolous
's to somehow be related to consensus compatibility
-
gingeropolous
but thats not the way it is so .... potatoes
-
gingeropolous
what i don't understand is why all my node are fine, but if i were to sync then they wouldn't make it past the block
-
binaryFate
the only way to pass that block is to be in a state where those 2 tws are in your mempool
-
gingeropolous
ah. so the daemon already verified in the mempool, so when it saw thme in the block it went "ok, i saw these before, all good" ?
-
binaryFate
if you sync you don't have a mempool with these 2 txs, so you're going to check them. And find out they're "illegal"
-
binaryFate
yeah exactly
-
gingeropolous
optimization strikes again!
-
hyc
seems like related to fluffy blocks then
-
gingeropolous
yeah
-
hyc
but mebbe it would have happened regardless
-
gingeropolous
could try. can run monerod with --no-fluffy-blocks still i think
-
binaryFate
mm I think fluffy blocks are about txs (non) propagation, but what the node decides to check/recheck/not check is independent
-
binaryFate
it's logic not to check a transaction twice when neither the transaction nor the protocol have changed.
-
binaryFate
But it fails when protocol changes in between
-
TheCharlatan
^ that's the best concise explanation I have heard today
-
binaryFate
dEBRUYNE: bins will be out in ~10mn if you want to post on reddit
-
dEBRUYNE
binaryFate: Here now, bins are up right?
-
binaryFate
no but within few minutes
-
dEBRUYNE
Oki
-
selsta
dEBRUYNE: though bins should be up on the downloads server
-
binaryFate
dEBRUYNE: ok website updated
-
binaryFate
great job everyone
-
binaryFate
I'll send a message on list
-
sech1
good to update my node then?
-
sethsimmons
Thanks for all the hard work tracking this down and fixing!
-
binaryFate
what a day
-
selsta
could have been worse like chain split or so lol
-
sech1
some solo miner could've synced to 2210720 and mined another block...
-
binaryFate
indeed lesson could have been way more painful
-
dEBRUYNE
selsta, binaryFate: Thanks, will create the thread in a bit
-
moneromooo
Can anyone connect to the node at 2a01:4f8:c0c:7b27::1 ? You need to have your machine setup for IPv6, which mine isn't.
-
moneromooo
Or at least I think it isn't :D
-
moneromooo
(P2P)
-
M5M400
wow - getmonero.org downloads are slow as ****
-
selsta
usually there is a CDN
-
dEBRUYNE
-
selsta
moneromooo: was not able to connect to it
-
moneromooo
Can't Download Nothing ?
-
moneromooo
And can you connect to IPv6 addresses from the same machine ?
-
selsta
added it as peer with --enable-ipv6, it showed as before_handshake and then vanished
-
moneromooo
OK, thanks.
-
moneromooo
Wait, not conclusive.
-
selsta
and with exclusive_peer it did not work
-
M5M400
yippie my backup node is syncing
-
moneromooo
Pretty cool though, I've got both in and our tor p2p connections.
-
» moneromooo likes
-
moneromooo
selsta: would you mind trying again please ?
-
selsta
"before_handshake" again
-
selsta
started with ./monerod --p2p-use-ipv6 --add-exclusive-node 2a01:4f8:c0c:7b27::1
-
moneromooo
Hrm. OK, thanks.
-
selsta
test-ipv6.com shows my ipv6 ip
-
selsta
should that be enough?
-
moneromooo
I don't know anything about IPv6 I'm afraid :/
-
moneromooo
The node's showing as listening on the v6 at the right port though.
-
moneromooo
Oh, there might be a firewall. Let's dig a bit...
-
selsta
moneromooo: any tutorial for setting up tor node with incoming connections?
-
selsta
ah it is in the readme
-
moneromooo
I did what's in ANONYMITY_NETWORKS.md
-
binaryFate
random thought: when we get a dandelion time out, could we drop the node that was selected to broadcast the tx as likely an asshole?
-
moneromooo
(and I managed to miss the part that the new onion address is auto generated in /var/lib/tor)
-
binaryFate
or maybe it's too harsh because the time out might not be because of the first peer
-
moneromooo
It might be any node along the way.
-
binaryFate
damn them
-
selsta
moneromooo: is there a known tor peer?
-
moneromooo
zbjkbsxc5munw3qusl7j2hpcmikhqocdf4pqhnhtpzw5nt5jrmofptid.onion:18083
-
selsta
cool now I have both i2p and tor on one node
-
selsta
moneromooo: the only issue we noticed with i2p / tor that peers seem to drop after a while, not sure if you noticed yet
-
moneromooo
I did not, but that's because I do not look.
-
selsta
I have 10 tor peers now (in / out)
-
selsta
will check later if they drop
-
selsta
At what point do Tor / I2P transactions get added to clearnet mempool?
-
selsta
Do they also go through hops?
-
selsta
AFAIK the transaction gets sent to 2 peers but don’t know further.