Bitcoin Forum
July 08, 2024, 08:44:38 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 [43] 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 ... 466 »
841  Bitcoin / Project Development / Re: fastest way in C to generate numbers on: February 10, 2024, 04:28:26 PM
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:
Code:
gcc -o foo foo.c -lm -O1
(might pop a warning about scanf, ignore it)

"After" program times without optimization:
Quote
Enter the value of n: 36
Time taken for bit shifting method: 130.311547 seconds

"After" program times with optimization:
Quote
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.
842  Bitcoin / Development & Technical Discussion / Re: Bitcoin Privacy Protocols on: February 10, 2024, 03:26:24 PM
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?
843  Bitcoin / Project Development / Re: fastest way in C to generate numbers on: February 10, 2024, 02:11:16 PM
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:
Quote
Code:
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 2n times. Instead, to save time, you should define a constant that will be 2n, without working it out every time:
Code:
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:
Code:
#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:
Quote
Time taken for complex number method: 1.506799 seconds

Seems like the fastest, or equally fast with the program above.
844  Bitcoin / Bitcoin Discussion / Re: Updates from the COPA v Craig Wright trial on: February 10, 2024, 11:08:18 AM
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.  Roll Eyes

"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.
845  Bitcoin / Project Development / Re: fastest way in C to generate numbers on: February 10, 2024, 10:38:01 AM
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.

Code:
#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 (2256-1). It will obviously never finish, because 2256-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 (264)2 = 2128 values. That's enough for our purposes:
Code:
#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 210=1024) to see it finishing. If the last number printed is 1024 + 1024*i, then you can be certain it is the 220th.
846  Bitcoin / Bitcoin Discussion / Re: Updates from the COPA v Craig Wright trial on: February 10, 2024, 08:57:25 AM
[...]
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.
847  Bitcoin / Project Development / Re: fastest way in C to generate numbers on: February 09, 2024, 10:39:34 PM
Code:
int end_number = pow(2, n);
pow returns a double, not an int. You should rather utilize bitwise operator <<.
Code:
int end_number = 2 << n;

Code:
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).
848  Bitcoin / Bitcoin Technical Support / Re: Bitcoin-Qt maxconnections ignored on: February 09, 2024, 09:24:32 PM
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.
849  Bitcoin / Bitcoin Discussion / Re: Limitations or scalability issues with the Bitcoin network on: February 09, 2024, 09:07:31 PM
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.
850  Bitcoin / Bitcoin Discussion / Re: Limitations or scalability issues with the Bitcoin network on: February 09, 2024, 07:56:19 PM
what do you think?
What we think about what? ChatGPT? It is impressive!
851  Bitcoin / Bitcoin Discussion / Re: Updates from the COPA v Craig Wright trial on: February 09, 2024, 07:49:09 PM
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.
852  Bitcoin / Bitcoin Technical Support / Re: Extremely slow reindexing on: February 09, 2024, 02:29:04 PM
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)
853  Bitcoin / Bitcoin Technical Support / Extremely slow reindexing on: February 09, 2024, 12:14:18 PM
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)
854  Bitcoin / Hardware wallets / Re: SeedSigner: Review on: February 08, 2024, 08:48:19 PM
Be careful with that, or you'll end up like coldcard user who used their dice generation feature with weak entropy and lost all his coins.
Let's just say that, fortunately, SeedSigner won't allow me to use a single dice result as an entropy!  Tongue

Same could be said for any generation that is not true random, and that means that it can be reproduced and cracked much easier.
Is it just me or is the phrase "true randomness" a bit of mixture of pleonasm and misleadingness? It kinda bothers me. If something is random, then people can't guess it; the outcome is totally unpredictable, and every possible outcome has the same probability. If that would be false, you wouldn't call it "fake randomness". You would simply call it non-random, or biased. In the case with generating entropy, both /dev/urandom and dice rolls are evidently random, hereby "truly random". But what matters in the end is being provably random.

Rolling dice is provably random, because you control the interface. /dev/urandom on the other hand requires some trust on the hardware.
855  Bitcoin / Hardware wallets / Re: SeedSigner: Review on: February 08, 2024, 07:51:22 PM
Is it me or you compare the disk (card) size the OS image file with the device's RAM capacity?
My bad! It doesn't have a RAM requirement, so it probably works with all models as displayed.
856  Bitcoin / Hardware wallets / Re: SeedSigner: Review on: February 08, 2024, 07:21:57 PM
You can install Linux on RPi Zero 2W which is the model I have. I have installed Raspbian Lite.
It is odd, though, because Raspbian Lite OS requires 520 MB of RAM, whereas Pi zero can handle up to 512 MB. Am I missing anything?

Anyway, SeedSigner is an OS, so we need to go deep into its code to check if we can use something like /dev/urandom. If SeedSigner is like a linux distribution, it could be possible, but I seriously have no idea if it is doable.
It is not a Linux distro. How do I know? Hint: 99.9% of the code is written in Python!  Tongue

Anyways, I don't believe that users should put trust on a CSPRNG that is not tested enough (as we wouldn't go with /dev/urandom). Besides, the spirit of the project is to trust none, including your RNG!  Smiley
857  Bitcoin / Hardware wallets / Re: SeedSigner: Review on: February 08, 2024, 06:43:38 PM
However, I dislike the "enter your own randomness" idea. Therefore I don't really use it.
I disregard the "take a seed picture" for generating entropy too. However, using coin / dice results as the entropy is the single most provable way to generate randomness. I agree that /dev/urandom is sufficient for the most part, but not for the paranoid (AKA, those who don't trust their device).

Do you believe it would be a good idea to slightly change the code to generate entropy using some CSPRNG source?
Raspberry Pi zero isn't designed to run Linux, as far as I'm concerned. It has 512 MB RAM, and almost all distros I know require more than that. How do you suggest we utilize such a source without having e.g., /dev/urandom?
858  Bitcoin / Development & Technical Discussion / Re: Bitcoin Privacy Protocols on: February 08, 2024, 10:54:10 AM
My take on it is that he understood that absolute privacy of transactions - be it BTC, fiat, or whatever - naturally opens the doors to a myriad of illicit uses.
I just don't get how you've reached to this conclusion. There is no message of him discouraging the use of absolute privacy tools. To me it rather seems as he saw it as "private enough".

The possibility to be anonymous or pseudonymous relies on you not revealing any identifying information about yourself in connection with the bitcoin addresses you use.  If you post your bitcoin address on the web, then you're associating that address and any transactions with it with the name you posted under.  If you posted under a handle that you haven't associated with your real identity, then you're still pseudonymous.
You could use TOR if you don't want anyone to know you're even using Bitcoin.

He even talked about key blinding and group signatures long before Monero and other privacy protocols were introduced in concept:
Crypto may offer a way to do "key blinding".  I did some research and it was obscure, but there may be something there.  "group signatures" may be related.

There's something here in the general area:
http://www.users.zetnet.co.uk/hopwood/crypto/rh/

What we need is a way to generate additional blinded variations of a public key.  The blinded variations would have the same properties as the root public key, such that the private key could generate a signature for any one of them.  Others could not tell if a blinded key is related to the root key, or other blinded keys from the same root key.  These are the properties of blinding.  Blinding, in a nutshell, is x = (x * large_random_int) mod m.

When paying to a bitcoin address, you would generate a new blinded key for each use.



In my experience, the simple answers are usually the correct ones. Satoshi simply lacked the competence to do that. It wouldn't be surprising. The very first Bitcoin version was quite simple in concept, and if you read the source code, you could tell it was just above the average. He did some mistakes, like the value overflow or reorganizing based on block height instead of chainwork. Maybe he ignored privacy enhancing techniques on purpose, but that's because it would be more difficult to explain to the public. Another guess: Maybe he didn't ignore them on purpose, but simply because it was too late to introduce them at the date he revealed interest about them.
859  Bitcoin / Bitcoin Discussion / Re: Is it okay for Bitcoin Core development to be funded by Banks? on: February 08, 2024, 10:12:00 AM
To find an optimised solution in an NP-hard problem computational power is needed
And as I've already demonstrated, miners choose to go with the "good enough" solution, rather than the ideal. It is simply not worth the effort to find the ideal solution with the given cost.

Do you think your rapspi will be able to handle a massive amount of paths and liquidity if/when LN is implemented ?
Lightning is implemented. The algorithms used are as I've already said optimized not for the cheapest, but for the cheap enough fee. It will work on even larger network, likely less accurately.

But still people in here claim that it will work
There is a variety of opinions about LN in this board, and I highly doubt we all believe it will work flawlessly. There are tradeoffs, just as with everything.

LN is even more centralised than mining . Have a look at how much liquidity and channels belong to the top 10
Now, who's arbitrarily using the word "centralized"?  Wink
860  Bitcoin / Bitcoin Discussion / Re: Is it okay for Bitcoin Core development to be funded by Banks? on: February 08, 2024, 09:29:24 AM
Good luck with your LN trying to solve an NP hard problem Smiley .
Transaction selection is NP-hard, but the software isn't trying to find the ideal fee; just one that is cheap enough. That's why they use variations of Dijkstra and A*, and not these algorithms per se. In LND, for instance, you can check yourself how optimized it is, comparably to a simple Dijkstra algorithm implementation: https://github.com/lightningnetwork/lnd/blob/master/routing/pathfind.go#L494-L504.

But, I don't understand why you focus on routing algorithm being NP-hard, and ignore mining which is NP-hard itself. The typical way to resolve this, is just to select a "good enough solution" rather finding the ideal. This is why you can find cases of blocks which could include higher paying transactions instead. System works pretty fine after all.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 [43] 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 ... 466 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!