Trian.G.bit.R is a program to search for patterns in three groups of RSZ and determine the private key
I have been working on security in the field of cryptography and vulnerabilities in the Bitcoin and other cryptocurrencies network for quite a long time. As is known, with a sufficiently high entropy selection of private keys and ECDA signatures, it is not possible to find or determine private keys and/or nonce signatures. But do all one-time signatures on the bitcoin network, for example, comply with these conditions? There are widely known cases when no measures of secure signing of outgoing transactions were observed at all and nonce signatures had the same public R(x nonce) coordinates. This made it possible to easily identify the private key from two such signatures. But what about the more complex relationships between signatures of more than 2 nonce keys with different public R coordinates? I came across a program that, judging by the description, deals with exactly such cases (the program can be downloaded for free on this telegram channel: https://t.me/Trian_G_bit_R).
It is proposed to pre-check the effectiveness in demotest mode using the generated RSZ groups using a given private key. Moreover, the key can be either from the blockchain or its own "special" key. As indicated in the description, the generated 3 RSZ groups will have a fairly close bit symmetry. I have tried to generate hundreds of such groups and they are all always different even for one private key. I tested them through my RSZ signature relationship analyzer and analyzed the degree of their mutual entropy, which was quite simple, because I knew the private key and therefore it was possible to establish the exact ratio of all three nonce-R multipliers relative to the starting G. The analyzer showed that the relationship between the three nonces is always different and collectively tends to a common average value of n/3. Well, then the total entropy of all three RSZ is equally high among themselves. But maybe they have something in common with the common private multiplier?
In this case, the analyzer showed a lower but still quite high entropy. But considering that these groups are being prepared specifically for the test mode of the program, I made a small discount on this. OK, now go directly to the program. The program is claimed to be a triangulator for searching for a private key through the search for mutual relations of exactly 3 RSZ groups. That's obviously why it's called a triangulator. It is well known that, regardless of the number of output signatures in the ECDA standard, it is not possible to determine the common private multiplier through a complex discrete logarithm. How then does the triangulator work with only three RSZ outputs for analysis? Here, the developers hide the main part of the algorithm, and indicate that in order to avoid hacking, they physically divided the algorithm into two levels. Costly in terms of computing and working with CPU and RAM, it is proposed to perform the subscriber for the highest percentage of the reward from the found BTC value.
To connect to such calculations, you are asked to make a deposit in USDT to an individual address on the ETH network - we will consider this separately below. Now we are interested in the sequence of the program and its fundamental chances of success. As already described above, this is possible under certain conditions, but let's talk about everything in order. So, the subscriber is invited to receive the individual activation codes of the program at his BTC address to which the subscriber wishes to receive the found BTC volume. In three of my four tests, the private key was detected quickly enough, and in one case the program stopped and issued a warning that in demotest mode its triangulation depth is limited. Ok, this is in test mode, the result is generally expected in advance, but what about searching for private keys from the Bitcoin blockchain. For all the already quite long history of the oldest cryptocurrency, to put it mildly, many cases of non-sanctioned transfer of BTC volumes have been known.
The reasons can always be different. I have identified three main reasons:
Taking possession of a private key with the help of third-party programs or viruses due to the user's carelessness.
Software holes that made it possible to obtain or compromise private keys.
Compromise of the private key due to public signatures of output transactions in the case of low or almost 0 mutual entropy of signatures and the private key.
Obviously, this program was created to analyze signatures and determine the private key in accordance with option 3. It is quite possible to assume that there may be mutual hidden relationships between ECDA output signatures that are not visible to both ordinary users and external analyzers. We will not write about the reasons for such relationships here, there may be many of them. Let's talk about the possibility of finding such relationships. As I managed to understand from the description, the developers know the complexity of searching using a discrete logarithm.
Therefore, they either do not use it or use it partially. In any case, there are no open source codes for analysis yet. What can be said for sure is that the program refuses to work with RSZ groups that have different private keys. Also, in 3 cases out of three, the program could not determine the private key in the demo mode if I mixed RSZ groups from the same private key but took them from different groups. Ok, obviously the developers have made a print on the screen of the minimum amount of information. I managed to determine the output of three public coordinates, which obviously represent some intermediate values in the calculations. The private key itself, when found, is output in all formats and all possible public addresses of all variants of the hash of the public key are determined, obviously to verify further verification of the balance in all variants.
Ok. It was in the demotest mode of the program. The result can be said to be expected. But let's go back to finding the private key through triangulation of RSZ groups from the blockchain. Here, as I managed to understand, the approach is as follows. The developers have already prepared dedicated RSZ groups for triangulation. The principles of preparation and my thoughts on this matter will be discussed below. Now these groups of signatures are transferred to subscribers, one for each dedicated process. I received 4 activation codes and started working with 4 parallel processes. With the help of a copy paste, I took out the downloaded RSZ signatures and determined which addresses in the bitcoin blockchain they belong to. Of course, I will not specify the addresses themselves here, but I can inform you that these are quite large volumes of hundreds of BTC. Next, I set up a screen recording, especially since I have the power to do it.
Yes, by the way, the program has a feature, if you run too many processes in parallel, it can issue warnings about low performance and even temporarily suspend work. This happened to me when I was running more than 16 processes in parallel. The program used 64 Gb of RAM in total of all processes, which is expected if it needs 4 Gb per process to form the so-called R-matix (whatever that means). With 128 Gb of RAM, this obviously didn't bother her much, but when the number of running triangulation processes began to approach the number of threads on my processor, failures and rollbacks began to occur. Which, in principle, was easily fixed when closing several windows with running processes.
So, I have 4 processes + screen recording started easily. From the external attributes, the string "search" or "triangulation process", apparently it can be called that, turned blue (in test mode it was white). The intermediate coordinates themselves are displayed in yellow and green. I transferred 900usdt to the deposit to receive activation codes, but I am more interested in the result. If there are a sufficiently large number of RSZ groups in the blockchain that can be triangulated in this way, and judging by the video there are such groups, then it is possible to put a certain volume of BTC into circulation.
By the way, about the selected RSZ groups. Of the 4 processes that I started, all the S/R ratios are the largest in terms of the number of matching bits in the map of the number in the final field n, which is obvious and is a condition or one of the conditions in choosing suitable groups, which is logical. The more matches there are, the fewer differences the r/S multipliers have in the formula - PublicKey*R/S add Z/S = R and its derivative. Obviously, with this selection, the developers make it easier for the triangulator to work as much as possible.
Of course, it is wrong to conclude that these conditions may be enough to successfully determine the private key, but the fact that the r/s multiplier is essentially a bitmap in a sample of sequentially doubled elements according to the formula Pub(n)=-(Pub(n-1))/4*(9* a/((Pub(n-1))^3+a)-1) for addition according to the well-known formula X=-(X1+X2-((Y1-Y2)/(X2-X1))^2) The elliptic curve is indisputable. Therefore, the approach itself as a whole may deserve attention, and its effectiveness can only be established in practice. The developers themselves respect confidentiality and work with their subscribers only through mutual Bitcoin and ETH addresses to fix deposits in USDT. But on the telegram page I found information that they offer each of their subscribers an additional payment of 2500 USDT for recording the process of the program at the time of discovery of the private key and the formation of an outgoing transaction with two proportional outputs.
And this approach deserves special attention. In fact, the difference in the behavior of the program in demotest mode and in working with a server over the Internet is cardinal. Part of the claimed work is displayed according to the description on a separate remote process. Obviously, this process is not very expensive because it can use GPU calculations to calculate "shift points" (whatever that means). When working with me, the program makes a request about once every 5 minutes and receives some 256bit variables, obviously additional coordinates that are used for displacement in the triangulation process. I doubt that large computing power is needed for these calculations, but judging by the description, this part of the algorithm was specially derived so as not to transfer the entire program to the public in its entirety. I will assume that these "shift points" are necessary for the program when working with the ratio between the three RSZ in a wider entropy.
From the material provided by the developers, it is clear that you can independently search for the private key for different signatures belonging to the same public address, but it is obvious that according to the calculations of such capabilities, some preliminary work is needed. Apparently, for this work they ask for a part of the deposit that the developers receive when issuing activation codes. My experience shows that in any case, the cryptography of ECDA signatures remains quite resistant to all types of attacks, subject to certain conditions. Time will tell how well these conditions are met in the selected signatures on the Bitcoin blockchain. In any case, the developers receive a part of the found BTC value and, obviously, the main calculation is made on this.
Usually, such methods do not go beyond a limited range, but in this case, the developers decided to take the path of attracting third-party computing power. From a certain point of view, this may be justified. For example, I am quite well aware of cases when thousands of users are interested in searching for private keys through a seed random generator and private keys directly, although as mentioned above this has no prospects, at least until the first sufficiently powerful quantum machines are launched. Such launches may primarily affect the increase in complexity in bitcoin mining, therefore, this relatively simple mining will be inaccessible to most users even with powerful ASIC devices.
In conclusion, I would like to remind you that ECDA signatures and cryptography may soon give way to more promising multidimensional vector signatures, before which even quantum calculations are still powerless.