Regardless of the court's decision, CW will continue to claim that he is Satoshi, and people like you who, despite all the evidence that he is not, will continue to give him some incentive to continue to prove it. I mean, even if the court said he was Satoshi, it'd seem more plausible as a scenario that the juries were bribed, or that Craig found a loophole in the law. It is beyond my understanding how can one throw away all the forgeries and evidence of him being completely untrustworthy, and stick to insignificant details-- which ultimately can apply to every individual. In a couple of months we will have an outcome , i'll just wait till then to come to a conclusion . I don't like throwing heretics on fire without a fair trial ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif) . Who knows , maybe a surprise is coming . Seems to me like you really want him to be declared as Satoshi, no matter how you argue the opposite. If you didn't, you'd have focused on the evidence and forgeries that have ridiculed him years now. If your stance was neutral, you'd have looked on both that evidence and his "evidence", and reach the conclusion we've all had. You must be personally interested in him winning the case to support him as his unofficial lawyer.
|
|
|
What if you pay someone after mixing these funds, this someone goes into an exchange, deposits the coins and the exchange is triggered due some flagged coins? This person will then point at you as the source of the funds and now you are in trouble. How do you avoid this? You warn him that if he deposits your bitcoin in a centralized exchange, he might have his coins censored. I personally haven't experienced a situation where the merchant asked me for the source, or "pointed me" as the source, even though almost all of my bitcoin were mixed. When the merchant uses Coinbase or BitPay, I simply refuse to pay him on-chain. 2) In order to send the coins into the Android software, you have to transact from Bitcoin Core, into the mixer, then into the Android software address. This is a lot wasted in fees. There is no way to save some money in this process? You could swap BTC for XMR, and then back to BTC in separate addresses. Perhaps that's less expensive.
|
|
|
Just checked your other post in a discussion about buying wallet.dat files. These are scams. So, to clarify: You haven't locked yourself out of your bitcoin. You don't even know if the files you possess have any bitcoin if unlocked. You have simply put faith in some random stranger in the Internet who told you these files have bitcoin if you find the password. I strongly advice you to stop wasting your time!
|
|
|
My Friend need to create a public key in a secure environments where private key is not disposed and held offline for security. Great, so use one of the available methods above in an airgapped environment. All the online web wallet service requires private key to in order to create the public key and Address. None of the methods above talk about "web wallet service". When you use your private key to create public key your private key is taped by the web data collection service either with pingback or other method. I don't know what experience you have with web wallets. Please don't use web wallets, because they are less secure. Use reputable, open-source, peer-reviewed software like Electrum in a freshly Tails booted, airgapped machine. I want create a Public key and address generator completely without internet connection. A simple software need to build for the secure cold storage public key generation purpose. So use Electrum. To generate private key from your seed you do not need to depend on the seed word library designed by the software developers and hackers to limit your private key generating capacity. What hackers?? Electrum is open-source and reputable for years now. I have come to the conclusion that you have no idea what you're doing. Please be careful or you'll lose bitcoin.
|
|
|
Some activities of fraudsters in verious social media: Scammers in social media, what a surprise. But, it's these particular Facebook groups which tend to attract scammers. These posts don't exist in say, a Star Wars fan group. You need to have entered a specific group type with "making money out of crypto" as the main topic. Which you shouldn't have entered in the first place as they're fraud. Also, what bull run are we talking about? Price recovery in the Bitcoin land is like a morning coffee. Bull run will begin when we exceed the $70k.
|
|
|
Don't try to copy blocks, chainstate and indexes without making sure your external disk is error-free. Check its condition. There's a small chance it has bad sectors, which can lead to incomplete transfers (AKA, corrupted files). During transfer close any unnecessary programs. I'd use a freshly formatted disk for this purpose, if I were you. Speaking out of experience... ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif)
|
|
|
that somehow contradicts the previous statement You're doing the same mistake for pow, and that's why it appears to have tremendous difference in execution time.
Sorry if I have confused you. What I meant is that whether you keep the bitwise operation in the expression or not, it won't make a big difference in terms of time, because it is inexpensive. On the other hand, pow is more computationally expensive, and you can notice the difference if you remove it from the expression. The -O1 option doesn't mean anything to me, I had to google it to find out what it means. Thanks for pointing out to that optimization mechanisms. Compilers like GCC have developed overtime and come with optimization options. There are quite a lot. I don't know them all obviously, but I've used -O1, -O2 and -O3. As you explained, the -O2 or -O3 will only have effect if using "real work" within the loop clause. Here the results I achieved for the bit shifting operations and the particular optimization levels... I know, I'm not totally sure about what -O2 and -O3 do behind the scene, but due to them being more aggressive, I expect they ignore the empty loop. You mean long long int, right? So it means that the technical limitation of the default data types in C would be 2^64 for the for loop, regardless of whether you use the bit shifting method or another one? What about the data type "long double", shouldn't this support up to 2^128 ?
Yes, but double is... not integer. A double can take up to 2 128 values (hereby, 128-bit), but it cannot represent all the numbers between 0 and 2 128, if that was your goal. Read about double-precision in here: https://en.wikipedia.org/wiki/Double-precision_floating-point_format.
|
|
|
You are so right. Thank you very much for pointing this out and correcting the performance error. Removing the bitwise operation from the for loop expression won't have a significant difference in performance, because the bitwise operation is really computationally inexpensive. It has difference if you compare it with pow, if run for millions or billions of times. Nonetheless, it is good practice to not make operations in expressions. As you can clearly see, the initial (BEFORE:) code I used with the expression in the for loop is faster. But I lack any justification for this. Let's optimize during compiling. Append the usual command with -O1: (might pop a warning about scanf, ignore it) "After" program times without optimization: Enter the value of n: 36 Time taken for bit shifting method: 130.311547 seconds "After" program times with optimization: Enter the value of n: 36 Time taken for bit shifting method: 16.889529 seconds ("Before" program takes a little bit more with optimization, but it isn't always true; it can take less time sometimes) If you put something inside the for loop, then you could use -O2 or -O3 for more aggressive optimization.
|
|
|
There is one theory that he (or they) worked for three letter agency because he picked one encryption used in bitcoin that doesn't have a backdoor. You mean the secp256k1 elliptic curve? How do you know it doesn't have a backdoor?
|
|
|
First of all, I just saw your code, and you're adding an extra burden for no reason. This is how you've defined the for loop: for (long long int i = 0; i < (1LL << n); i++) Can you point out the problem without viewing the answer? Answer: The expression i < (1LL << n) is checked in every iteration. That means that the CPU will run the bitwise operation for 2 n times. Instead, to save time, you should define a constant that will be 2 n, without working it out every time: const long long int max = 1LL << n; for (long long int i = 0; i < max; i++) You're doing the same mistake for pow, and that's why it appears to have tremendous difference in execution time. Both 1LL << n and pow(2, n) should take about the same few milliseconds if run once. The difference is apparent only if you run them for millions of times. Check out yourself. I made this tiny difference in the code, and now both finish at about 2 seconds: #include <stdio.h> #include <stdlib.h> #include <math.h> #include <time.h>
int main() { int n;
printf("Enter the value of n: "); scanf("%d", &n);
clock_t start_bitshifting = clock(); const long long int MAX1 = 1LL << n; for (long long int i = 0; i < MAX1; i++) { } clock_t end_bitshifting = clock();
clock_t start_pow = clock(); const long long int MAX2 = pow(2, n); for (long long int i = 0; i < MAX2; i++) { } clock_t end_pow = clock();
double time_bitshifting = ((double) (end_bitshifting - start_bitshifting)) / CLOCKS_PER_SEC; double time_pow = ((double) (end_pow - start_pow)) / CLOCKS_PER_SEC;
printf("Time taken for bit shifting method: %f seconds\n", time_bitshifting); printf("Time taken for pow function method: %f seconds\n", time_pow);
return 0; }
so I don't see any advantage in prefering the suggested complex number method in terms of speed. I see the bitwise operation being the fastest so far. Please correct me if I'm wrong. This is what I get: Time taken for complex number method: 1.506799 seconds Seems like the fastest, or equally fast with the program above.
|
|
|
I don't believe with certainty , don't twist my words . Certainty has a specific meaning . I'm not 100% certain "I don't believe with certainty". Meanwhile: At this point i'm 95% certain that he is satoshi or was one of the architects behind the pseudonym In other words get outside of your echo chamber I think you should get outside your echo chamber. This isn't about the Bitcoin community or "Bitcoin maxis" as you keep calling everyone around here. It's common sense and a vast amount of evidence suggesting he is not who he claims to be. This person has made it blatantly clear that he is a fraudster to whom I wouldn't trust a single word coming out of his mouth. He has repeatedly lied and presented forgeries. I don't know what else counts as evidence of him being a scam. You choose to ignore all the evidence, and stick to insignificant details, like "both him and satoshi were smart!", "both were involved in cryptography!" or "what if he presents receipt for bitcoin.org?!", as if such a document couldn't be counterfeited given enough money. "But isn't there a chance?". Negligible. Judging by the facts, I'd rather bet franky1 for being Satoshi if I had to choose between the two. Do you disagree that we should have courts to solve cases like this or should we look at what twitter majority says to come to a conclusion ? We have courts which can hopefully notice the fraud in this case. However, a trial isn't the holy grail of truth. Bribery in judiciary is not so uncommon phenomenon. Just because a court says he's Satoshi doesn't mean the public has to unquestionably take this as true.
|
|
|
The limit of 2^64 is too small, it must be compatible up to 2^256 and thus with very large numbers.
You'll have to use specialized libraries, like GMP (GNU Multiple Precision Arithmetic Library). I just wrote a small program for you to play with. #include <stdio.h> #include <gmp.h>
int main() { // define a 256-bit integer mpz_t maxIterations; mpz_init2(maxIterations, 256);
// maxIterations = ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff mpz_set_str(maxIterations, "115792089237316195423570985008687907853269984665640564039457584007913129639935", 10);
mpz_t currentIteration; mpz_init(currentIteration);
while (mpz_cmp(currentIteration, maxIterations) < 0) { // print the iteration gmp_printf("Iteration %Zx\n", currentIteration);
// increment it mpz_add_ui(currentIteration, currentIteration, 1); }
mpz_clear(maxIterations); mpz_clear(currentIteration);
return 0; } If you run this, it will start printing all 256-bit numbers, from the start (0) to finish (2 256-1). It will obviously never finish, because 2 256-1 is astronomically huge. However, for the sake of simplicity, I suggest you use complex numbers instead of this. C supports 64-bit as a maximum integer, so a complex x + y*i, with x, y ∈(0, 2^64-1) can take up to (2 64) 2 = 2 128 values. That's enough for our purposes: #include <stdio.h> #define MAX __UINT64_MAX__
int main() { unsigned long long int x, y;
for(x = 1; x <= MAX; x++) for(y = 1; y <= MAX; y++) printf("%llu + %llu*i\n", x, y); return 0; }
You can define MAX to smaller values (like 2 10=1024) to see it finishing. If the last number printed is 1024 + 1024*i, then you can be certain it is the 2 20th.
|
|
|
[...] Just wow. I believed the answer to my question would be a "no", and that you just supported big blocks. I mean, we had our disagreements about block size and privacy in the past, but believing with certainty that CSW is Satoshi? That assertion goes beyond the extreme of the fallacies. I don't have anything in response. Just look at the mountains of evidence of Craig being a pathetic liar and actively submitting forgeries, which you must be ignoring.
|
|
|
int end_number = pow(2, n); pow returns a double, not an int. You should rather utilize bitwise operator <<. fprintf(output_file, "%d\n", i); Writing to the disk is going to slow this down. Why don't you just use printf? It will display the numbers in the terminal at faster rate than fprintf will write them in disk. Also, apogio is correct about overflows. C permits you to declaring up to 64 bit integers ( unsigned long long int is the largest it can get, up to 2^64 - 1).
|
|
|
I have maxconnections=20 set in the bitcoin-qt.conf file but it seems to ignore the setting. Have you tried disabling incoming connections temporarily and see how many connections you'll have? The default option is to accept 11 outgoing max. When i run it as bitcoind, instead of using bitcoin-qt, the maxconnections works fine, but that is in a different config file. What do you mean? How can you have more than one configuration file? Both Bitcoin-QT and bitcoind, if run with no datadir and conf parameters, read from the default data directory, where there's bitcoin.conf.
|
|
|
Tbh, it sounds like chatgpt or any AI text when you read it. That's because it is. I just checked two AI detectors, and both returned 100% score.
|
|
|
what do you think?
What we think about what? ChatGPT? It is impressive!
|
|
|
Anyone can claim , but only one in each case can prove it . That's the point we are now , proving in court . Either he is or he goes to jail for perjury and other things . Isn't that great ? Do you really believe he is Satoshi? Let's leave the court asides for a moment. Do you find the overall "evidence" convincing to you? If i steal your keys am i the owner of your coins ? Or am i a thief who illegally posses your coins ? And more importantly , if i steal your keys am i you ? No, but if you claim to be me, and you have no other ways to prove such a thing (like a drivers license), then a signed message from the PGP is at least required. You can't claim to be an anonymous person with no evidence apart from forgeries. Satoshi, whoever he is, posted a PGP key. This, along with the genesis public key, are the only elements which can certify his identity. Beyond that, not much else is known about him. You can't treat potentially everyone as Satoshi. Everyone is not Satoshi until proven otherwise. And as time goes by, these signed messages will count even less as solid evidence due to the development of quantum computing which will sooner or later be used to compromise his keys.
|
|
|
What I have tried in the past, and it worked, was to download the blockchain on my SSD using Windows 11 OS. I've considered doing that, but I don't have a terabyte of SSD, and I don't want to buy one just for that purpose. HDD satisfies my needs. Sure, Bitcoin Core would be less troublesome, but if it works, even slowly, then I don't care. Then I downloaded Core again and set it to look in the SSD again. It worked flawlessly. I guess it's a relevant situation, isn't it ? Hmm. Maybe if I used Bitcoin Core from my main computer without booting into Raspbian, and pointed to the Bitcoin data directory in the plugged HDD, then maybe it would reindex more rapidly. There are quite a lot of permission issues this way, though. (The datadir is read only, and I'll have to run Bitcoin Core as root)
|
|
|
Bitcoin Client Software and Version Number: Bitcoin Core 26.0 Operating System: Raspbian Lite OS (64-bit) System Hardware Specs: 4 GB memory, 2 TB external HDD. Description of Problem:
TL;DR: I switched disks, and somehow either the blocks or the chainstate got corrupted, and I had to reindex. I'm one week now, at progress=0.313028. It seems like it goes much slower now. Yesterday it was in 0.30. At this rate, it will take more than a month to reach the tip. I was thinking if it's possible to eject the HDD, plug it a computer with better specs, so it could finish... this month. It should be possible to do, right? The disk is loaded with Raspbian, so I could theoretically load it during boot in any other machine.
(Asking just in case I don't mess things up)
|
|
|
|