|
TL;DR: because 1+1=2
doubling in secp256k1 is equal to x/4 * (1 - 63/(x^3+7)) = x/4 * (x^3 - 56) / (x^3 + 7)
since p is very close to 2256 using small number for x ensures patterns
x=1 : 1/4 * (1-56)/(1+7) = -55/32
x=2 : 2/4 * (8-56)/(8+7) = -8/5
x=3 : 3/4 * (27-56)/(27+7) = -87/136
|
|
|
|
maybe you should use a library. For that particular function? For modinv only? Looks like for all. One more mistake is using ^2 for square. In C# (and C, C++, etc.) this is XOR with 2. Do you really know C#? When translating code you should first understand what it does, both original and translated. Anyway, this must be a good learning experience for you. Maybe check what it does step by step and consult manuals more. |
|
|
|
|
When in ruby there are multiple assignments in one line, they are done in parallel, yes? Then your modinv is very wrong. If you need a forum post to find such mistake... maybe you should use a library.
|
|
|
|
|
You are missing an important point - the one at infinity (0,0).
So three important cases are missing:
- doubling (0,0)
- adding to (0,0)
- adding (x,y) and (x,-y), which produces (0,0)
|
|
|
|
Percentage of recently (last 144) signaling blocks is 86.8% = 125/144 https://taproot.watch shows the percentage of current period (73.5% right now) above red/green blocks at the right, but for some reason only before it's clear that current period couldn't lock-in (before 202 non-signaling blocks). |
|
|
|
You are gravely mistaken. Satoshi mined just one block for no more than six days. Furthermore that block cannot be spent, so in effect he premined 0 coins. But (s)he did mine lots of blocks during the first month, while it was still under development and only known by those (s)he was emailing that time. Didn't (s)he? I remember reading the whitepaper beginning of December 2008. Nobody emailed me anything, it was all public info. The news got out to the ones looking for new stuff. Then the software appeared in January, v0.1.0 alpha. I mined (and threw away) some block in February. It was a windows executable, sounded very fishy to me. It was worthless thing, making the laptop fan buzz all time. Satoshi didn't mine lots of blocks, just made sure that blocks are still mined. Almost nobody was interested. For a whole year the difficulty was the lowest possible - 1, and the hash power couldn't produce blocks fast enough to even reach it. There was once more than 24 hours between two blocks. In retrospect this was the correct way to do it. Too much marketing, and it would be crushed at the beginning. It was just at the edge, and managed to survive so far. |
|
|
|
“Premining” is actually a made-up word, that we've defined it as a creation of some coins, before the cryptocurrency gets launched. Almost all cryptos are premined, even Bitcoin. Satoshi was mining for a month, before he/she announced it on bitcoin.org. I just wanted to point you that, let's move on.
You are gravely mistaken. Satoshi mined just one block for no more than six days. Furthermore that block cannot be spent, so in effect he premined 0 coins. |
|
|
|
You wish, but the reality says no. In the paper they look at 14, 20, and 32 bit elliptic curves. The corresponding weights storage is 2 13, 2 13.5, 2 14.2. Theoretically the storage would be in the order of 2 7, 2 10, and 2 16. So all looks good, no breakthrough. To even learn the secp256k1 weights you'd need at least 2 128 examples. Good luck executing that. |
|
|
|
|
Using NN for cracking cryptographic functions is pointless. NN can capture only simple dependencies.
I expect the number of weights needed for capturing one bit with bigger than insignificant probability to be in the order of 2128.
|
|
|
|
Most success in ECDLP has been in Pollard-Rho, like a '6' character you following the tail until find the point of entry into a circle, but this method requires memory storage, but this method only works on TOY problems because there is not enough memory on earth to store the history.
You are mistaken. Pollard Rho & Kangaroo both use the same amount of memory (the same order of magnitude). In the original rho the whole memory is only two points and two numbers mod curve order. Parallelizing multiplies the needed memory, but it still remains insignificant compared to the number of point additions. The amount of memory needed is linearly dependent on the number of parallel computations. |
|
|
|
A soft fork must restrict the transactions that are valid. Your proposal increases the transactions that are valid. How? Currently transactions sending from zero coins to zero coins have no restrictions at all (except matching signatures of course). In the new format, they would be valid only if new amounts would match. There are no UTXOs containing zero coins. These are pruned, and cannot be used as an input. The whole discussion is pointless. There's no need of sub-satoshi values on layer one. |
|
|
|
When someone spends outputs that have a fraction of a satoshi, the transaction will appear to be invalid because it violates consensus rules. If you can send a fraction of a satoshi, you can also send 1.5 satoshi in an output. Spending zero satoshi is backward-compatible. New amounts will be visible only by new clients, the old ones will see moving zero satoshis from some inputs to zero satoshis to some outputs. It is similar as in Segwit: if you run some old client, you see no signatures in Segwit inputs. Unfortunately it's not backward-compatible. Let the new amounts be 1.9 and 1.9, the old will be 1 and 1. Adding the new amounts we have 3.8, the old ones see only 2. Let the new outputs be 3.1 and 0.7. What about the old outputs? We cannot put 3 and 0, the old ones can spend only 2. The new outputs diverge further and further from old ones. In fact old amounts become fake. One could avoid this by separating it into real satoshis and micro-satoshis, without overflow from micro to real. But then where would micro-sats come from? The earliest point would be after the tenth halving, maybe in year 2048. This looks too late. Another way is to introduce a new, smaller unit, decoupled from sats. Something like a built-in altcoin. It could be soft forked using one of the nops, i.e. <amount> OP_SEND OP_DROP. On the other hand why one would need such small units on layer 1? Doesn't make sense. |
|
|
|
What exactly do you prove once you mine a genesis block? That you can achieve it with a certain target? As I said, you'd do that after to maintain the longest chain. What difference would it make if Satoshi had picked the first hash with nonce=1? There's nothing to be proved in the genesis block.
The genesis block was likely mined with difficulty 4000. This makes it hard to mess up the beginning of the chain, giving a head start of a week for bitcoin. Nowdays mining with difficulty one is easy, just do it on a GPU. It should take about a second or less. |
|
|
|
There are 1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976 possible Bitcoin addresses (someone correct my number if it's wrong). There are this many P2PKH addresses. Once you include P2SH and P2WPKH addresses, the number is 3 times larger. P2PKH and P2WPKH are equivalent, so all three give a number 2 times larger. What is missing is P2WSH, which adds 2 256 more addresses. And soon P2TR, which adds another ~2 255 addresses, with at most 2 128 security.
P2(W)PKH: 1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976
current P2PKH record: 9,223,372,036,854,775,808
P2SH: 1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976
collision: 1,208,925,819,614,629,174,706,176
P2WSH: 115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936
collision: 340,282,366,920,938,463,463,374,607,431,768,211,456
P2TR security: 340,282,366,920,938,463,463,374,607,431,768,211,456
current ECDLP record: 144,115,188,075,855,872
|
|
|
|
Didn't know this website thank for sharing. Do you know what format are MESSAGE and SALT? I thought parameters must be in binary but inside github :
All is binary. If you are interested in PBKDF2 and HMAC, it's explained in details in wikipedia. password:
636f6e6475637420636f72616c20656e72696368206c6f63616c20736372697074206d6f756e7461696e2072656d61696e206672696e6765206c6174696e207468726f7720776f6f6420776562
salt for pbkdf2:
6d6e656d6f6e6963
salt for the first hmac:
6d6e656d6f6e696300000001
|
|
|
|
So PBKFD2 is HMAC-SHA512 with two parameters :
1) password as "mnemonic sentence"
2) salt as "mnemonic sentence + passphrase".
PBKDF2 is not HMAC-SHA512 (in this case it uses it): https://en.wikipedia.org/wiki/PBKDF2#Key_derivation_processHMAC-SHA512 with key="conduct coral enrich local script mountain remain fringe latin throw wood web", and salt="mnemonic"+00000001 gives the correct result. |
|
|
|
This function is used to compute the next kangaroo hop (just insert the current kangaroo in it and you're done). It would be interesting to see if any research has been done to find the optimal hop function!
For Pollard Distributed Kangaroo (close enough to) the optimal is powers of two plus the last one making the mean jump value correct. |
|
|
|
It doesn't. The second R & S differs. Yours are: r2: b0c147a4046a541d051fa5f17906bc01aeb46fbe273ef9226610d2e0579dad88s2: 7c9f48333e7ad71c9fc66c28efaa4032954bba147feb8f08664e3fce4619a75cThe signature from 523c3a9aa8f69af7a5b0491eeb4e49be3fb20ca5e5b0a9114e0bbdf273c1a690: 3044022070aee9c959607de56c500a2aefeaed489aab151daf42299df564106367c296e10220755799de9564d2968ceac7f8a3678d1d7b47e41fadb24ba6c694fc11eae6bcc901
040b8a0382802e12fc345e9bace8b99f6aed6b90fbfd796e8027ca9bb5f472778db863952bdb6e9 e399e34f941cab2fa6c244e65af2d15244fee2d795b3f6e222d
Didn't bother to check the hashes provided. |
|
|
|
|
Looks like it fails when you include transaction other than coinbase. Witness commitment must be wrong.
|
|
|
|
|
Show Posts
