Bitcoin Forum
June 21, 2024, 11:52:31 PM *
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]
161  Alternate cryptocurrencies / Announcements (Altcoins) / Re: ★★★ PandaCoin [PND] ★★★ New devs, old community. Updated links ! on: May 16, 2021, 10:49:11 PM
Should we move our Pandacoins from btcpop to a wallet?
162  Bitcoin / Development & Technical Discussion / Re: BitCrack - A tool for brute-forcing private keys on: May 16, 2021, 10:38:01 PM
Is there a reason why BitCrack is not under maintenance any more?

Should we create a new Fork, where we combine all the good patches?

I would be happy to take this job (and be the benevolent dictator it needs Cheesy).
163  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: May 16, 2021, 05:43:36 PM
Well if it starts with 02 then it is a compressed key. So when you uncompress it you will get x and y coordinates. You could put the x argument into sha256k1 and check if you get the right y-ordinate. If your calculated y is not the same as the y of the uncompressed pubkey, then you have your answer.
164  Bitcoin / Development & Technical Discussion / Re: BitCrack - A tool for brute-forcing private keys on: May 16, 2021, 05:31:07 PM
Well... there are "only" 16^10 permutations to check empirically if there is a correlation. Have fun Cheesy

counter-evidence:

3bd3536aea8ceb2b => 1DB6to5oCUJ3mLELL7M9JsMdhHQxfVLVHK 
165  Bitcoin / Development & Technical Discussion / Re: BitCrack - A tool for brute-forcing private keys on: May 16, 2021, 04:38:02 PM
You what propose?

You ask "How long time for bitcrack calculate form RIPEMD-160 and double sha256 then Base58"

Answer is 0

Because bitcrack not do calculate from RIPEMD-160 and double sha256 then base58

Bitcrack convert address legacy compress address to RIPEMD-160 and calculate till step 3 of http://gobittest.appspot.com/Address

bitcrack then compare calculated RIPEMD-160 with RIPEMD-160 address in bloom filter

you understand?
166  Bitcoin / Development & Technical Discussion / Re: BitCrack - A tool for brute-forcing private keys on: May 16, 2021, 03:18:54 PM
What you propose is already implemented in bitcrack.
167  Bitcoin / Development & Technical Discussion / Re: Need large amount of testnet bitcoin, can someone help me? on: May 16, 2021, 02:12:32 PM
Whats the point? Could you not just change the Genesis Block, hardcode it into your bitcoin core and basically create your own blockchain?

Then mine for few hours... you will have your own block chain with hundreds of your own tBTC. For free.
168  Bitcoin / Development & Technical Discussion / Re: BitCrack - A tool for brute-forcing private keys on: May 16, 2021, 01:52:00 PM
BitCrack is already transforming compressed and uncompressed BitCoin Addresses to RIPEMD-160 when loading the addresses. SegWit and MultiHash Addresses are not transformed and result in an invalid Argument Error in BitCrack. BitCrack is then putting the RIPEMD-160 hashes into a Bloom Filter and does not make a string based comparison. Because compressed and uncompressed RIPEMD-160 addresses are generated from the compressed or uncompressed EC-PubKey you can not optimize it at an earlier stage.

The only improvements/optimization you could do is:
- Implement SegWit and MultiHash-Addresses to RIPEMD-160 transformation.
- Implement a Public-Key only search (Write a Programm which searches the Blockchain for public-keys and modify BitCrack to use it as an input), then you could potentially speed up the process but keys without known pubKey will not be searched (tradeoff).
169  Bitcoin / Development & Technical Discussion / Re: BitCrack - A tool for brute-forcing private keys on: May 16, 2021, 11:30:39 AM
No, the puzzle is between 2^63 and 2^64 BUT:

https://github.com/brichard19/BitCrack/issues/223

(uint64_t)_points * _threads * _blocks;


So instead of checking all keys you are basically ignoring alot of keys. If you have e.g. 512 blocks and 1024 threads (doesnt matter if those are valid inputs) you would basically jump over 512*1025 = 2^19 keys.

So thats why you are faster finished.
Yeah not sure where you get your info from.  Bitcrack doesn't ignore keys. Unless you are speaking of a bug with the CL version, but the program does not skip/ignore keys unless you use the stride option, on purpose.

Please reread what I wrote: The buggy line results in skipping keys.

170  Bitcoin / Development & Technical Discussion / Re: BitCrack - A tool for brute-forcing private keys on: May 16, 2021, 04:20:24 AM
If you take care of the chunking I guess it will work fine.

I think if you combine following Forks you get a good head start

ByLamacq has implemented the Vectorization Patch
https://github.com/ByLamacq/BitCrack/commits/master

BoGnY and his OpenCL Fix
https://github.com/BoGnY/BitCrack/commits/master

Fishpeppers Base58 Patch
https://github.com/fishpepper/BitCrack/commit/af2aa3e2df798453338b71f619f2596620a600a5

And you would just have to apply the changes manually without knowing that much of c++.
171  Bitcoin / Development & Technical Discussion / Re: BitCrack - A tool for brute-forcing private keys on: May 16, 2021, 04:07:40 AM
Tbh, If i would try to crack the puzzle I would fix the OpenCL Bug and implement the various optimizations from different forks of BitCrack. Then I would modify the code and instead of incrementing the key, i would decrement the key. I mean... there are alot of people scanning the whole 2^63 - 2^64 Range and they already scanned about 10-20% of it from the beginning already. So scanning it again makes no sense. But I did not see a modification of BitCrack which implements decrementing the keys. So you would have a better chance to find the solution if you begin from the middle and increment the key or from the end and decrementing the key. Picking some random ranges in the big range as some people mentioned gives imho no actual benefit. In contrary: The Key could be in any subrange. And if you do it randomly, you would have to store the information which ranges you already scanned in your statusfile (--continue FILENAME). This file would just consume more of your VRAM and depending on the amount of subranges could reduce your speed. But if you would decrement the key you could still use the statusfile-logic as it would only store the information about where you stopped the last time and you could pick up from there very fast and continue decrementing the key. Especially because you mentioned you like to hold the search now and then for gaming and watching TV.

------------------

Regarding Code Optimizations:

I tried the whole night to understand how i can get more performance.

I have a Vega 56 and a Quadro P620 in my PC.

Under Linux my Vega56 has about 45 MKeys/s (with buggy clBitCrack) and my P620 has about 26 MKeys/s with cuBitCrack

Under Windows I have about 54 MKeys with cuBitCrack and clBitCrack did not really run...

So... I dont know why I have poor performance under Linux. I am not interested to further investigate this. So Windows it is.

On the other hand, It seems, that NVidia is also suggesting that lto is improving the performance

https://developer.nvidia.com/blog/improving-gpu-app-performance-with-cuda-11-2-device-lto/

I tried alot to get it compiled in Linux, but I guess I would need to further investigate into this as I was getting compilation errors. But as I said, I will use Windows... So maybe there I can improve it.
172  Bitcoin / Development & Technical Discussion / Re: BitCrack - A tool for brute-forcing private keys on: May 16, 2021, 03:27:14 AM
No, the puzzle is between 2^63 and 2^64 BUT:

https://github.com/brichard19/BitCrack/issues/223

(uint64_t)_points * _threads * _blocks;


So instead of checking all keys you are basically ignoring alot of keys. If you have e.g. 512 blocks and 1024 threads (doesnt matter if those are valid inputs) you would basically jump over 512*1025 = 2^19 keys.

So thats why you are faster finished.
173  Bitcoin / Development & Technical Discussion / Re: BitCrack - A tool for brute-forcing private keys on: May 15, 2021, 08:56:26 PM
You can try it but I would not recommend it.

I would recommend to use the --continue FILE option and just switch the OS if you want to play or continue with cracking. Maybe using the CudoOS and instead of mining using bitcrack can also improve performance if you are not a native linux user.
174  Bitcoin / Development & Technical Discussion / Re: BitCrack - A tool for brute-forcing private keys on: May 15, 2021, 08:03:10 PM
Maybe this fork is working for you

https://github.com/ZenulAbidin/BitCrack-3000

But you would need to compile it yourself. I am Linux-User, so I cant help you there with compiling it. THere is also a sp version precompiled for windows fork, it is somewhere linked. I did not save the link as it was uninteresting for me.
175  Bitcoin / Development & Technical Discussion / Re: BitCrack - A tool for brute-forcing private keys on: May 15, 2021, 07:39:38 PM
According to the github-repo the openCL version is buggy and does not find all keys.

Test it by checking the already known keys. If you dont find all keys (e.g. you find keys but you are missing some in between) then you can assume that you are effected by the openCL-Bug and you wasted your time.

Edit:
Also this
https://bitcointalk.org/index.php?topic=4453897.msg56053911#msg56053911
176  Bitcoin / Development & Technical Discussion / Re: How many of you check the code of open source software? on: May 15, 2021, 12:22:48 PM
I am a professional software developer and tbh I am always checking the code if I want to use it in my product. You can't imagine how much crap people are publishing and how much crap is included in other packages. My colleagues sometimes use multiple megabyte big packages to use a functionality which are one liners in native code - and we use alpine docker baseimages to have smaller docker images. Ironic

Or as uncle Bob said it once:
The amount of programmers doubles every 5 years. So every second programmer has less than 5 years of coding experience. So don't expect much code quality at all.
177  Bitcoin / Development & Technical Discussion / Re: BitCrack - A tool for brute-forcing private keys on: May 15, 2021, 12:02:53 PM
I will test my proposed modifications tonight and I'll report. On my other PC at least the binary files are noticibly smaller (less bitcode = less instructions = faster?)
178  Bitcoin / Development & Technical Discussion / Re: BitCrack - A tool for brute-forcing private keys on: May 14, 2021, 11:14:24 PM
Does your speed improve if you replace
Code:
CXXFLAGS=-O2 -std=c++11

with

Code:
CXXFLAGS=-O2 -std=c++11 -flto -fno-semantic-interposition
LDFLAGS="-Wl,--strip-all -fno-semantic-interposition -flto"

?

I usually compile python with these modifications to get about 30 % more performance from it. Maybe this helps you too?
179  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: May 13, 2021, 07:33:39 PM
He used a deterministic wallet.
180  Bitcoin / Development & Technical Discussion / Re: ECDSA math questions on: May 09, 2021, 12:43:35 AM
Leaving here the code for typescript/javascript as it is maybe useful for others. Thx arulbero for the python code.

Code:
export function retrieve(publicKeyCompressed: bigint): string {
const yOdd = publicKeyCompressed.toString(16).substring(0, 1) === "3";
const x = BigInt("0x" + publicKeyCompressed.toString(16).substring(1));
const p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2Fn;
const x3 = modPow(x, 3n, p);
const y2 = modPow(x3 + 7n, 1, p);
let y = modPow(y2, (p + 1n) / 4n, p);
if (yOdd) {
y = p - y;
}

return "0x04" + bigIntToHex(x) + bigIntToHex(y);
}

function bigIntToHex(value: bigint): string {
var hex = value.toString(16);
if (hex.length % 2) {
hex = '0' + hex;
}
return hex;
}

/** taken from npm package bigint-mod-arith */

/**
 * Modular exponentiation b**e mod n. Currently using the right-to-left binary method
 *
 * @param b base
 * @param e exponent
 * @param n modulo
 *
 * @throws {RangeError}
 * Exception thrown when n is not > 0
 *
 * @returns b**e mod n
 */
export function modPow(b: number | bigint, e: number | bigint, n: number | bigint): bigint {
if (typeof b === 'number') b = BigInt(b)
if (typeof e === 'number') e = BigInt(e)
if (typeof n === 'number') n = BigInt(n)

if (n <= 0n) {
throw new RangeError('n must be > 0')
} else if (n === 1n) {
return 0n
}

b = toZn(b, n)

if (e < 0n) {
return modInv(modPow(b, abs(e), n), n)
}

let r = 1n
while (e > 0) {
if ((e % 2n) === 1n) {
r = r * b % n
}
e = e / 2n
b = b ** 2n % n
}
return r
}

/**
 * Finds the smallest positive element that is congruent to a in modulo n
 *
 * @remarks
 * a and b must be the same type, either number or bigint
 *
 * @param a - An integer
 * @param n - The modulo
 *
 * @throws {RangeError}
 * Exception thrown when n is not > 0
 *
 * @returns A bigint with the smallest positive representation of a modulo n
 */
export function toZn(a: number | bigint, n: number | bigint): bigint {
if (typeof a === 'number') a = BigInt(a)
if (typeof n === 'number') n = BigInt(n)

if (n <= 0n) {
throw new RangeError('n must be > 0')
}

const aZn = a % n
return (aZn < 0n) ? aZn + n : aZn
}

/**
 * Absolute value. abs(a)==a if a>=0. abs(a)==-a if a<0
 *
 * @param a
 *
 * @returns The absolute value of a
 */
export function abs(a: number | bigint): number | bigint {
return (a >= 0) ? a : -a
}
/**
 * Modular inverse.
 *
 * @param a The number to find an inverse for
 * @param n The modulo
 *
 * @throws {RangeError}
 * Exception thrown when a does not have inverse modulo n
 *
 * @returns The inverse modulo n
 */
export function modInv(a: number | bigint, n: number | bigint): bigint {
const egcd = eGcd(toZn(a, n), n)
if (egcd.g !== 1n) {
throw new RangeError(`${a.toString()} does not have inverse modulo ${n.toString()}`) // modular inverse does not exist
} else {
return toZn(egcd.x, n)
}
}
export interface Egcd {
g: bigint
x: bigint
y: bigint
}
/**
 * An iterative implementation of the extended euclidean algorithm or extended greatest common divisor algorithm.
 * Take positive integers a, b as input, and return a triple (g, x, y), such that ax + by = g = gcd(a, b).
 *
 * @param a
 * @param b
 *
 * @throws {RangeError}
 * This exception is thrown if a or b are less than 0
 *
 * @returns A triple (g, x, y), such that ax + by = g = gcd(a, b).
 */
export function eGcd(a: number | bigint, b: number | bigint): Egcd {
if (typeof a === 'number') a = BigInt(a)
if (typeof b === 'number') b = BigInt(b)

if (a <= 0n || b <= 0n) throw new RangeError('a and b MUST be > 0') // a and b MUST be positive

let x = 0n
let y = 1n
let u = 1n
let v = 0n

while (a !== 0n) {
const q = b / a
const r: bigint = b % a
const m = x - (u * q)
const n = y - (v * q)
b = a
a = r
x = u
y = v
u = m
v = n
}
return {
g: b,
x: x,
y: y
}
}

You can test it:

Code:
console.log(retrieve(0x02a521a07e98f78b03fc1e039bc3a51408cd73119b5eb116e583fe57dc8db07aean));

results in 0x04a521a07e98f78b03fc1e039bc3a51408cd73119b5eb116e583fe57dc8db07aea6fb15c871dd 7cf7d287390acd4e09d41f705081a98d5fe3a930ca032525dbcdc

Code:
console.log(retrieve(0x0378D430274F8C5EC1321338151E9F27F4C676A008BDF8638D07C0B6BE9AB35C71n));

results in 0x0478d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71a1518063243 acd4dfe96b66e3f2ec8013c8e072cd09b3834a19f81f659cc3455
Pages: « 1 2 3 4 5 6 7 8 [9]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!