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 cyber punk 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, before another genius decides to shit all over it.  |
|
|
|
|
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.
EDIT:
That said, all the blockchain consensus/verification rules are 100% implemented and up to date, and there are no known compatibility differences there between gocoin and bitcoin core. All the differences are not consensus related (e.g. P2P protocol or UI features).
|
|
|
|
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. 32 bytes of TxID (in the same order as stored in memory)
4 bytes of VOut (little endian)
4 bytes of 2*block_heigh+coinbase (little endian)
8 bytes of Amount (little endian)
var_len byte length of the following script
the spending script (uncompressed, variable length, as stored in memory) |
|
|
|
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 written to the hasher like this: 32 bytes of TxID (in the same order as stored in memory)
4 bytes of VOut (little endian)
4 bytes of 2*block_heigh+coinbase (little endian)
8 bytes of Amount (little endian)
the spending script (uncompressed, variable length, as stored in memory) 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? |
|
|
|
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: dnsseed.bitcoin.dashjr.org
seed.bitcoinstats.com
seed.bitcoin.jonasschnelli.ch |
|
|
|
What I've learned about this, there are bots out there that feed this attack. Here are some of their IPs: 103.107.198.132
104.149.35.146
104.200.131.120
139.5.177.224
141.98.103.172
144.48.37.76
152.89.163.172
165.231.253.44
172.104.10.187
173.244.211.90
174.127.84.12
176.107.184.136
176.113.74.253
176.222.34.111
178.175.133.100
180.149.231.156
185.104.185.164
185.106.102.204
185.122.168.248
185.130.184.115
185.156.175.109
185.169.233.205
185.189.114.27
185.191.204.131
185.203.122.18
185.216.34.99
185.225.28.44
185.236.201.133
185.236.201.230
185.240.244.5
185.93.2.199
185.99.3.105
189.1.168.147
192.145.125.36
193.148.18.28
193.27.12.46
193.32.210.165
194.150.167.78
194.36.110.182
195.158.248.4
195.206.104.157
195.206.105.93
196.245.151.4
2.58.46.236
208.78.41.68
217.138.197.76
217.146.92.233
31.13.191.132
37.221.112.62
43.249.36.137
45.141.153.237
45.144.113.44
45.249.222.252
45.34.7.4
45.83.91.196
45.89.174.116
46.102.153.68
5.101.145.47
5.101.145.50
64.120.88.150
68.232.180.194
77.81.191.3
86.105.9.92
87.239.255.38
89.164.99.107
89.249.64.171
91.132.136.238
91.205.230.194
92.119.18.253
93.190.143.97
94.46.223.22
95.174.66.28 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?
|
|
|
|
Here's the reply I got from Pieter Wuille about this subject Each group of source IPs (/16s etc) selects a subset of just 64 buckets (salted using a host-specific secret key), and inserts the newly received IPs in a position in a bucket in one of those, if certain criteria are met (the position was empty, or it held an IP address that also occurs elsewhere in the table already). This limits the impact an attacker can have, because they cannot under any circumstances affect IPs in buckets outside of the 64 their group maps to. 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. |
|
|
|
I am still not seeing anything out of the ordinary. So either they are hitting specific IPs / Nodes or my SonicWall is blocking them for some reason.
I do have the sonic configured to block botnets, so if the connections are coming from known bad IPs they might never make it in. But other then that I have no idea.
@piotr_n are you still seeing the attack?
-Dave
Yes, they are still coming. You will only see them in your node's peers database. |
|
|
|
Are they all coming from 1 IP block or from everywhere?
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 |
|
|
|
|
Show Posts
