They seem to have stopped now - about a week ago, actually.

However, talking about the addresses, three of the bitcoin's DNS seeds seem to have been down for awhile already:

What I've learned about this, there are bots out there that feed this attack.
Here are some of their IPs:
But you can't connect to them - you have to wait for them to connect to you.

Such a fake node seem to be connecting to (all?) the known bitcoin nodes - somehow randomly.
Upon connecting, it does the versions handshake pretending to be bitcoin core (I've seen /Satoshi:0.21.0/ and /Satoshi:0.21.1/)
Then, without any delays, it start sending addr messages, each containing 10 records.
After sending 500 of such messages (so 5000 addresses total), it just disconnects, literally a few seconds from connecting.
Later it will come back, minutes or hours later, to do the same...

Thanks @vasild.
Yes, I'm running my own software and was asking people running core to tell me what they see at their nodes.
And I asked if the core had a limit, just to know what to expect or how it would handle the problem.
And with the 700k number, I just wanted to give you and idea on how big the problem was.
BTW, I cleared the DB exactly two days ago and now it has over 800k records. So its definitely still ongoing...

Anyway.
So, please correct me if I'm wrong, but the thousand 'new buckets' approach and each node being able to access only 64 of them, does not seem to be helping much, considering that all the nodes advertise incoming addresses without checking them.

That's basically what I'm seeing.


Now imagine scenario that you're starting a new node, with a brand new IP.
It is going to have a hard time getting incoming connections anytime soon, considering that it competes with hundreds of thousands of fake IPs.

Plus every node looses time trying to connect to these fake addresses.
Not sure what is the core's algo of choosing a new IP to connect to, but whatever it is, it will surely also have to deal with a lot of dead tries.

Any solutions?

Thanks. That's very helpful.
Will probably look into implementing something like this.


What is the core's algorithm for selecting addresses to return after receiving getaddr request?
Does it only pick those from the "tried" buckets?

Same for sending spontaneous addr messages: does it have to "try" it first, before it can route a new addr to its peeers?
I am not completely sure, but it seems like I'm getting (most of) those fake addresses from a legit bitcoin core peers.
I have a suspicion that because of the algorithm bitcoin core uses for routing new addresses, it's somehow facilitating this problem.

And I don't send any getaddr, FWIW.

Yes, they are still coming.

You will only see them in your node's peers database.

There are ~200k records with IPs starting with 255.255... and a random (not 8333) port number - these were advertised 15+ hours ago.

But the more recent ones (~500k of them) seem to be completely random IPs with port number 8333

It seems like there is some sort of attack going on - the network is advertising hundreds of thousands of non-working addresses via the addr messages.
All my nodes' peers databases are now over 700k records and seem to be still growing...

Do you see the same at your nodes?

Does bitcoin core have a limit of peers upon witch it won't accept new addresses into the database?
How to best handle that?

Apart from the extra resources consumption, it now takes much longer to connect to new peers, because there are so many non-working addresses in the db.

Are there any test vectors, but only for the new sighash algorithm?

Thank you, it helps me a lot.

Call me stupid, but I'm not quite enlightened by the way the BIP docs are explaining themselves.

So: try to collect the outputs being spent first and verify the scripts later - I'm on it.. thanks!

Thank you.

May I ask, out of curiosity, what purpose does it serve?
It kind of makes the taproot implementation quite much harder to make.

I'm starting this new topic because I'm trying to implement the taproot functionality in my code.
I hope people can help me to understand some of the taproot technicalities.

So my first question:

How does the new verify_script function use the spend_scripts of the inputs that it is spending?

When I will verify a specific input of a transaction, will I need to have amounts and spend scripts for all the inputs, or will it be enough to have just the one at a time?

Am I getting it wrong thinking that "schnorr" is just an improved way of doing EC signatures, while "taproot" is an extension to the scripts interpreter?

Because reading some publications (and this forum topic), one could get an impression that schnorr and taproot are synonyms, whilst for me they are two different features. Although, I understand that they are planned to be deployed and activated together.

I only found test vectors in bip340_test_vectors.csv - but they seem to be only checking sign_schnorr() and verify_schnorr() functions.

Are there any new test for entire scripts and transactions?

Will there be any taproot related tests added to the src/test/data ?

OK, thank you everybody.

I fixed it - my bad

Thanks. Must be something i screwed up with porting the code.

Perhaps you could help ma to figure it out.

At a beginning of the function BlockAssembler::addPackageTxs (in src/miner.cpp) it does:

It seems that at this point the inBlock variable shall contain a set of transactions.
Where is this set built? I can't find that place in the source code.

What I found so far.

I cant really find the relevant code in the current bitcoin core sources, but the code I am using myself was once based on what core was doing (at least that was the idea).

So the first stage of sorting is finding the packages.
A package is a child tx with all its (unconfirmed) parent txs.

What I am seeing now is mempool of 5851 transactions.
This comes down to 4142 packages...
But inside these 4142 packages there is a total of 5773388 parent txs.

I'd say that it is quite a lot and it takes my PC over one second to build the package list.
Either my function to look for the packages has suddenly turned out to be screwed up, or the recent content of the mempool has been deliberately engineered to cause such a behavior.
If it is the second, then bitcoin core (at least the mining nodes) might be suffering from it as well.

Someone please look into this.

I'm not sure if the sorting function is actually used if you're not mining on the node.

Eventually, it can be called when you exceed the mempool size limit, but that would not be a case recently.

Is it just a problem with my implementation, or is there some sort of attack going on, exploiting the Child-Pays-For-Parent sorting algorithm?

The sorting (of the existing mempool) takes far too long.

It's in the function called IsValidSignatureEncoding() in src/script/interpreter.cpp

https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L107

The rules from that function are being enforced since BIP66 was "activated", which was at (including) block #330776