The only unsolved part for now, is what to do with older hashes, and merkle tree of the blockchain ? But maybe community can help here.
Spoken like a true manager.  |
|
|
|
Thus instead of probability of 1/3.4028×10^38 to find an account, you now have 1/1.7014×10^29.
Good - you did some calculations... In this scenario you still won't be able find it easily but with increased probability and advancement in computer technology which let's say able to churn out approx one million of balance checks per second in 20 years time, how feasible would that be to find a seed that contain fund in it?
... but why did you stop? |
|
|
|
|
Ah yes! You are right. I used the wrong modulus.
|
|
|
|
|
I got confused. As I said earlier, r = 0 isn't the same as the point at infinity.
If you can have X=n, you can have x=0.
y2 = ax3 + 7 (n) => y2 = 7 (n)
However, I don't know if you X=n is possible. Not all X are on the curve in Fp.
s = 0 is avoided because you can find the private key as you said.
|
|
|
|
|
Ah ok. R can't be 0 if k is in the right range. S can be 0 but should be retried per ecdsa algorithm. The odds are so low though.
|
|
|
|
|
I think you got something confused. k = 0 isn't the same as r=0 or s=0. The point at infinity has no X,Y but cannot be generated if k is between 1 and n-1 simply because kG <> 0.
|
|
|
|
|
It's still ok if you don't release the master public key but to be extra careful, you could use hardened keys.
|
|
|
|
|
To me it sounds like the title is "The next step in going against "conventional wisdom" - Create your own rocket!
|
|
|
|
Well - then the receiver has to carry a database of nonces with him wherever he wants to be able to decrypt a message. Otherwise, you just described a stream cipher - it's definitively not a new crypto  Edit: http://en.wikipedia.org/wiki/Stream_cipher |
|
|
|
This raises a lot of red flags. OTP is used as an example of perfect secrecy cipher. Mainly to introduce the more advanced concepts because it only works if the pad is perfectly random, used once and as long as the text to encrypt. All of which makes it impractical. I don't know how you produce your OTP but anything short of the previous is not a OTP.
Okay - these are very good points and it is not a "true OTP" at all (for the obvious reason you pointed out) but is instead a PRNG key stretcher (starting with a shared secret). In order to never re-use the same "pseudo OTP" (is that term acceptable?) a message nonce is combined with the shared secret (the nonce itself would be sourced from /dev/random or equivalent). Of course the "shared secret" could also be determined using ECDSA key pairs (as an alternate to using GPG or some other method of communicating the shared secret). This looks fairly subject to chosen ciphertext attacks. The nonce has to be sent with the encrypted message. I craft a new message with the same nonce and modify the body of the cipher text. Since I know they are XORs, I can change the decoded content or retrieve the message little by little by sending several attempts and seeing how the receiver reacts. |
|
|
|
Yes, but first you code the general case, and then you can simplify.  I'm not about to stretch out their implementation to accommodate all curves and implementations just so I can test their implementation (which by that point would be mostly my re-implementation) against the test vectors in the RFC. However, it is obvious if you follow the RFC6979 test case that they "re-generate T" which includes the extra V = HMAC_K(V) that I included in my pull request. As for the BIP32 case, I do believe most places account for out of bounds private key results... but there are so many implementations of BIP32 compared to RFC6979... x.x I meant you as the impersonal pronoun - not you per say. If I remember correctly, the only shortcut is regarding tlen=qlen. Everything else had to be implemented and it was tricky at a few places. |
|
|
|
Good points - I am not inventing a new type of cypher.
The idea of a OTP is at least hundreds of years old.
The only idea I would ask anyone to accept is that "secure hashes are secure" (as many other crypto algos work upon that assumption I don't think I have violated any sacrosanct idea).
If SHA256 is not secure then Bitcoin should have already been destroyed (and that is the OTP method that I use).
This raises a lot of red flags. OTP is used as an example of perfect secrecy cipher. Mainly to introduce the more advanced concepts because it only works if the pad is perfectly random, used once and as long as the text to encrypt. All of which makes it impractical. I don't know how you produce your OTP but anything short of the previous is not a OTP. "secure hash are secure" have to be framed in a particular context. What is the attack model? CPA, CCA, RO, etc. I could go on and on but the point is that these sentences don't give much confidence to start with. |
|
|
|
@dabura667: did you test it against that example?
They didn't have any secp256k1 test vectors  Yes, but first you code the general case, and then you can simplify. Btw, BIP32 has a similar rule. It may be worth checking their implementation of it too. |
|
|
|
|
I thought the RFC had an example of such a case in section A1. Am I mistaken or they didn't test it?
|
|
|
|
|
It kinda depends on how convenient vs secure you want it. If it's for pure storage, a multisig paper wallet seems the way to go.
|
|
|
|
Then do what Danny told you. Essentially I use 'blockchain.info' to debug me own code, so matching their 'interpretation' of the output script signatures is really what I'm trying to do.
I wouldn't use a buggy implementation as a reference for my own code but it's your call. |
|
|
|
|
I don't see why you want to decode these bogus pub keys. They are obviously invalid. It's just someone who wanted to put a text message into the blockchain. OP_RETURN is the right way to do it. The client can drop them from the UTXO set.
4d6573736167653a20687474703a2f2f692e696d6775722e636f6d2f735a3864302e6a7067 in ascii is "Message: BitcoinPara.de Dividendenzahlung 1 vom 07.09.2012".
PS: the clue is that they begin with the same bytes and 65 is 'e', 61 is 'a' in ascii.
|
|
|
|
|
Thanks for your quick response, another question - is there support for the maintenance of the mempool and the set of unspent outputs? I couldn't find where transactions are checked for double spends for example.
|
|
|
|
|
Is it possible to run it as a full node implementation? Basically with tx relay and wallet maintenance.
|
|
|
|
|
Show Posts
