|
Looks like "version", "time", "bits", and "nonce" are correct.
hashPrevBlock and hashMerkleRoot have to be little endian.
Maybe there's a problem with switching endianness, i.e. reversing the string representation instead of bytes.
What is the previous block header, and the merkle tree?
|
|
|
|
Using bitcoin core 0.21.0 on RegTest. Block #101 with the default RegTest target of 0x207fffff Full header is 00000020c21aa3b43d104b5db7eb46d90430308b668b4edebdd23d72ba6cfc685601f1666769ae0d507824c9b1220f02db880618240a6b5dff17c1319a443eadd4b218e7a76c3360ffff7f2000000000
Hash versus target: 6f295fbd976fd8dd1668bf4ba82b8e7b2089c3497cf3f9dc4a61beb519992958
7fffff0000000000000000000000000000000000000000000000000000000000
50279827699679515341806937817482573096355300064251967888806579886749916932440
57896037716911750921221705069588091649609539881711309849342236841432341020672
This block is being rejected by core with a short message only saying "high-hash". The hash should be big-endian, what you showed is little-endian. The hash of the header you presented is: 58299919b5be614adcf9f37c49c389207b8e2ba84bbf6816ddd86f97bd5f296f Investigating further, looks like you represented both previous block hash and merkle tree hash as little-endian. Proper block header would be: 0000002066f1015668fc6cba723dd2bdde4e8b668b303004d946ebb75d4b103db4a31ac2e718b2d4ad3e449a31c117ff5d6b0a24180688db020f22b1c92478500dae6967a76c3360ffff7f2000000000 with hash: 809aaeb27a59de0964d3990c5e4a9f7476af154aa6acc8371fcf7571fc9b7f30 EDIT: Got it wrong. Still think endianness is the reason somehow. |
|
|
|
The MOV Attack is from 1993: A. J. Menezes, T. Okamoto and S. A. Vanstone, "Reducing elliptic curve logarithms to logarithms in a finite field," in IEEE Transactions on Information Theory, vol. 39, no. 5, pp. 1639-1646, Sept. 1993, doi: 10.1109/18.259647. |
|
|
|
You'd have to ask Satoshi about this. Code snippet from v0.1.0 (or 0.1.3): bool CBlock::CheckBlock() const
{
// These are checks that are independent of context
// that can be verified before saving an orphan block.
// Size limits
if (vtx.empty() || vtx.size() > MAX_SIZE || ::GetSerializeSize(*this, SER_DISK) > MAX_SIZE)
return error("CheckBlock() : size limits failed");
|
|
|
|
Just how to get Bitcoin Addresses in (P2WPKH) format from ripemd160 hash?
You need the public key in order to generate P2PKH or P2WPKH. So if the address is spent from, or signed with, then you can generate the corresponding P2WPKH. No public key - no way. EDIT: Got a bit confused here. The hash is the same so one only has to change the encoding. |
|
|
|
That is 12*11*10*...*1 or 12! = 479,001,600 and it is not at all hard to check 479 million mnemonics within reasonable times.
Moreover in 12 words BIP39 there's 4-bit checksum, so the number of valid combinations is ~29,937,600. |
|
|
|
Non-invertable means the inverse of a function does not exist ...
By this definition sha-256 could be non-invertible as well, depending on its input. And double sha-256 is non-invertible (as used in bitcoin), since half of the possible outputs of the second sha2 are unreachable, and 1/4th have more than one pre-image. |
|
|
|
I tried to solve the first and the second signature respectively dU = (1 - s2-1e2 + s1-1e1) * (s2-1r2 - s1-1r1)-1 (mod n)25041906913603492912629482838603148556953877974558690311897389474403233806170* 87836391163832050037286569637948589985039867162624287225605962431632613849975= 109121978011525909088360135908868503435418230507773857531730397075033675637267 The correct result: 74071287274168731384314914382498140270634658281328726941106265589917762050271I certainly did something wrong ... I forgot to mention that I am not good at modular equation, but thanks for trying to help me. I will try to solve this equation until I get the correct result  In decimal, modulo n (the group order):
r1: 99935505760319748698811422354322418311203851828465328908708024011195996180829
s1: 14810718830809274529170993651437030466460552688297005873719201854608653306524
e1: 84635513758865831094131084311208775267495704821994249663954751780286420288259
r2: 115035229747891778996889965749694763606205313739267493174821202115705061416296
s2: 56412229366601912356674994073152925730313351483910294670205660420888695151902
e2: 711922952377524543467576566144169816136170490747613227449590530659320692002
s1-1: 49589235156255394867995584868850296899036724345858375131186053009052960413985
s2-1: 75860710922369590624024015031955497020040967297713867268831531011990818769063
s2-1e2: 24319896032458654235859288439366790171987421552616806414321622974227628294346
s1-1e1: 33373073398809441106621025265904429856170478887328914010434069704980389675914
s2-1r2: 102756882304321902845902604711749179835279156262963247575454606290129811589248
s1-1r1: 109263722787838616791900575947640359553086907200677310074463510255775504782173
1 - s2-1e2 + s1-1e1: 9053177366350786870761736826537639684183057334712107596112446730752761381569
s2-1r2 - s1-1r1: 109285248753799481477573013772796728135029813341360841883596259175872468301412
(s2-1r2 - s1-1r1)-1: 88597492899895469960154264896435952736065060080234931949365434864574123803941
dU: 74071287274168731384314914382498140270634658281328726941106265589917762050271
|
|
|
|
|
Only non-hardened child with leaked private key, and leaked parent extended public key makes finding the parent private key easy.
kpar = ki - parse256(IL) (mod n)
I = HMAC-SHA512(Key = cpar, Data = serP(Kpar) || ser32(i))
Hardened derivation uses the parent private key, which is unknown.
I = HMAC-SHA512(Key = cpar, Data = 0x00 || ser256(kpar) || ser32(i))
Bitcoin Core uses only hardened keys.
Non-hardened keys could be useful, when a system needs to generate new addresses, without having access to their private keys.
|
|
|
|
If quantum computers ever work, then by using Groover's algorithm mining difficulty would be square root of the usual one. Let's say that mining difficulty is 80 bits. Then QC difficulty would be equivalent to 40 bits. Usual miners would do 2 80 operations, while QC would do 2 40 quantum operations. But, IMO, unfortunately QC wouldn't work for any task other than generating enormous amounts of noise. |
|
|
|
Vanitygen searches for specific prefix. Pairgen searches for matching prefixes. The difficulty of finding a pair is suqare root of the difficulty finding a specific prefix. This is known as Birthday Paradox. Finding a 40-bit matching pair is 1,000,000 times faster than finding 40-bit prefix. Well, to be more precise, 890,578 times faster. |
|
|
|
Still, according to this counting argument it's absurdly unlikely for there to be an unreachable output ... just not quite as much as your figures suggested.
Since bitcoin generally uses double sha-256, there are in fact unreachable outputs. It's expected, that half of the output values are unreachable (when using dSHA256). Theoretically it might become a problem in the future, when difficulty is insanely high, no combination of nonce/extranonce would produce a number below target. This might not be true though, it's possible that all low values are reachable. Long before this happens there will be a hardfork, since sha-256 wouldn't be secure anymore, or a softfork adding additional hash commitment, using something stronger than sha-256. |
|
|
|
Your private key is not a valid point. A point is supposed to start with "02" or "03" but yours starts with "e3". Wait. Why should a private key start with "02" or "03"? A public key start with these prefixes to define if y is odd or even. A private key is any number between 1 and 2 256 - 2 32 - 2 9 - 2 8 - 2 7 - 2 6 - 2 4 - 1. No? No. A private key is between 1 and 2 256 - 432420386565659656852420866394968145599. |
|
|
|
Say someone was giving you clues to their private key. For each character they gave you a couple of options eg, for the fifth position is either 1, 3, f or a. How many options would they have to give you per position for it to be crackable by brute force?
Assuming known legacy address, wif private key contains 85 characters, first is always "5", second one of "H", "J", "K", leaving us with 83 characters. Let's assume the second character is know. When we have 4 possibilities for each character, there are 2 166 possible combinations. Direct brute forcing has been solved for private keys with 2 63 possibilities up to now. We could accelerate the calculations a bit, by dropping the checksum characters (last 5), and doing checksum on the rest. This drops the complexity to 2 156. If the public key of the address is known (i.e. spent from, or signed with), then it's "easier" to do Pollard Rho on it - complexity is only 2 128. With 2 possibilities per character, the complexity is 2 78, so few billions of dollars, many years, and giga-watt-hours later it could be cracked. |
|
|
|
|
If we search for a curve y2 = x3 + d passing through (1000,2000) then d = -996,000,000. Such big d would give enormous coordinates very fast. Well, small d would grow almost as fast too. Elliptic curve security is based on this effect to a large extent.
A "smaller" curve would be y2 = x3 + 12 with G=(-2,2). The curve is of rank 1, isomorphic to secp256k1 curve mod p, G being the point with smallest height.
2*G = (13, -47)
3*G = (-74/225, 11674/3375)
4*G = (27313/8836, -5352937/830584)
5*G = (14932678/8994001, 109819305542/26973008999)
...
The numbers grow very fast, n*G needs at least 2n bits to represent just the numerator of x coordinate. y grows even faster.
To some extent this could be mitigated by using curves of rank > 1. This means a curve with more than one rational generator. One could relatively easy find a curve of rank 8, the smallest one (in absolute value) is d=−2520963512. The average x would need at least 273 bits to just represent its numerator (when multiplying by <2256).
The highest rank of publicly known curve, isomorphic to secp256k1, is 16. The x coordinate numerator (~245 bits) would fit the RAM of modern supercomputer.
There's no known (easy) way to lift a point mod p to a rational numbers one. It is at least as hard as ECDLP.
|
|
|
|
I have much more questions to step 9.
As we see there's checking leading to point doubleing or to infinity.
When the input is sanitized there are no infinity points. Step 9 is skipped. |
|
|
|
I missed something from J+A point addition - step 14 in 3.22. There should be additional 256-bit-add-minus-p & 256-bit-mux, for 1280 more gates. It doesn't change the outcome much. Since there are many multiplexers, it might be beneficial to allow the Transmission gate. A 256-bit multiplexer would be 512*TG + 1*NOT. This is 3 times less transistors. Perhaps it would be better to count transistors instead of logic elements.
NOT - 2
NOR - 4
NAND - 4
AND - 6
OR - 6
XOR - 8 (6 with PTL)
XNOR - 8
TG - 2
|
|
|
|
I still can't understand how You optimizing gates count by combining bits.
The most naive point addition is with memory 1 point (G). Then we double the generator and add points appropriately. However all doubled points are constant, hence we could precompute all 255 doublings. The result is 256 points memory, no doubling. Since point addition is more expensive compared to implementing memory through multiplexers, we could go further. Split the private key in groups of 2 bits, precompute for each group the four combinations (resulting in 4*128 points memory), and feed the appropriate points to 127 point adders. i.e. at lsb position bits 00 - 0*G 01 - 1*G 10 - 2*G 11 - 3*G next group would be 00 - 0*G 01 - 4*G 10 - 8*G 11 - 12*G and so on. If we use groups of 4 bits - 2 4 points memory per group. It turns out that with affine points best is to use groups of 11 bits, plus 3 bits for the last group. For Jacobian+affine point additions best is groups of 10 bits, plus 6 bits for the last group.
Some more questions.
1) what is Your formulae for affine point addition with only two multiplications ?
the most optimized version I found has multiplication+multiplication+squaring=3multiplications.
2) what is Your formulae for Jacobian point addition with only 11multiplications ?
the most optimized version I found has 17multiplications.
Also I would like to note that by test-runs for affine we have +-384iterations, but not +-760.
1. It is quite possible, that I have a mistake here, missing one multiplication. Anyway Jacobian+affine performs better. 2. "Guide to Elliptic Curve Cryptography", Algorithm 3.22. It has 8 multiplications, 3 squares, 6 subtractions. For binary euclidean gcd I get 760 iterations, when running with input 0x8000...00 and p. |
|
|
|
|
You could have fun the other way as well. For every y there are 3 possible x values. You could even combine both strategies.
For any number in range (0, p), 1/2 are valid x coordinates, 1/3 are valid y coordinates.
The probability any y coordinate is valid x coordinate is 50%.
There are (n-1)/3 y coordinates (n being the group order) ≈1.33*2254.
The average number of child points is 1. Any child point has 3 parents.
The longest chain could be in the order of 2128 points.
Most probably there are cycles, specially when the chain approaches 2127 points.
|
|
|
|
|
Show Posts
