No, thanks.
Because I have no good way to do an actual mining, so I wouldn't be able to maintain it with an acceptable quality.

I did add some simple mining API to cheat-mine testnet coins with the old GPU miners, but that's not something I want to advertise or encourage people to use.
One cyberpunk already fucked up testnet3 trying to impress people with his testnet hacking skills and I would like testnet4 to stay useful for a bit longer.

It's never going to have identical features as Bitcoin Core - that was never the point.

There are some BC features that will likely never be implemented (e.g. bloom filters)
And there are some original Gocoin features the BC will likely never implement (e.g. trusted peers)

At the other hand, there are some feature BC has that are still supposed to be added (e.g. IP v6 support), although there is no roadmap for them.

The mining API is certainly a big missing feature, but since there is nobody interested in mining with Gocoin, it's pointless to add and then maintain it.

It is being actively maintained, occasionally some new features are added.

See the changelog.txt for the recent changes.

Never mind, already figured it out.

There is a variable length filed between the amount and the script.

I've been struggling to reproduce the hashing procedure used by the RPC command dumptxoutset (for the latest release 28.0).

I was hoping that maybe someone could give me a hint what I am doing wrong.

I am assuming that it is using the HASH_SERIALIZED type (not the mysterious MUHASH)

In which case, is should be just a simple SHA256 of all the "Coin" records, ordered like in the file created by dumptxoutset.

Looking at the source code, I think each record is like this:


So all he records go one-after-another and at the end I do another SHA256 on the result.

Unfortunately, this does not work, because I don't get the value from the "txoutset_hash" filed returned by dumptxoutset.

I wonder whether there is some kind of script_length filed between the Amount and the script itself?

WTF happened with Vaultoro?

They seem to be involved in some dodgy practices these days.

I swapped some BTC to Gold with them, at the very beginning (in 2015) and always thought they were a trustworthy business.
I even exchanged some private emails with Joshua and he seemed like a decent and trustworthy guy.
So I have kept my gold in there for many years now, paying them a fair storage fees, trusting that it was safe.

But suddenly, about two weeks ago, after logging in there, I see the message that my account it blocked "for security reasons" and that I should contact customer support.
So I did contact the customer support and they tell me that my a/c was blocked not really for security reasons, but because I have to show them documents proving the source of funds.
I'm saying that I don't deposit any funds and I only hold some gold there which I bought many years ago.
They answer "OK, but you deposited some BTC in 2015 - 2017, to buy this gold, so show us the source of that funds".
So I sent them some old emails from mtgox, confirming purchase of bitcoins in 2011 and 2012.
It took them over a week to process those, but it still wasn't enough.

Now they want to see a proof of my "current income"!
I ask: why do I need to show you my current income if I have not deposited anything into your exchange since 2017 and I am not going to?
No answer, just: show us the current statements from your bank, so we can see that you have an income, otherwise we won't unblock your a/c.

I ask them to refer me to a government institution that supervises their business, where I could maybe file an official complaint (suggesting that maybe it would be https://www.financial-ombudsman.org.uk/ )
The customer support answers that no, they are not based in UK, but in Lithuania, although still not referring my to any supervising institution.
Only adding that "the registration number is on the website in the footer."

The problem is that the only registration number I see in the footer is "CIF B54835301", that points to a company in neither Lithuania nor UK, but in Spain. https://www.axesor.es/Informes-Empresas/8143356/BITCOINFORME_SL.html

These people are holding millions of euros worth of people's assets and there is no way to even figure out which country they are based in.
WTF?

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 wait, it start sending addr messages, each containing 10 records.
After sending 500 of such messages (so 5000 addresses total), it just disconnects, after literally a few seconds from connecting.
Later it will come back, minutes or hours later, to do the same...

Thanks @vasild

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 the 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.

Thanks. That's very helpful.

Will probably look into implementing something like this.


And 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?

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 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?

This one is more of a wallet side question...

Since the (compressed) public keys don't have the even/odd attribute anymore, is there some new way of calculating them?

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?

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

So my first questions:

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 spend scripts for all the inputs, or will it be enough to have just the one at a time?

Is there any advantage to use taproot type address for a single key addresses?

Would it be any better than bech32 encoded P2WKH?

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.