Okay well updating

- i have the nonce (validated)
- Have the message hash (validated)
- Have 2 sets of DER S R validated.
- Pretty much have the entire model required .. BUT 2 odd things...

Im having issues on the back end, its not matching for some reason, no its not the data..  The main issues are in the signature verification and key recovery methods.  IT did verify just came out with incorrect results which IT could be the point verification but have changed this out more times than i can count...

The P2SH address deviation differed on a data resolve ... but the main compressed address remained the same.  IT still would be a hit and relevant but dont know why it would change.

I want to get this over with and concluded. So any hints would be appriciated. Wish i could specify what and this or that, but i cant. I wouldnt trust my own mom with this one... but whoever helps will be tipped and can be glad they set something right from before...
I really am wtf over it... its something trival...

Okay im not sure how to progress with this .. or what the margin of error if any exisits ..

Both recoveries were verified successfully with their respective signatures, though with different error margins:
First key: ~4.08% relative error
Second key: ~24.6% relative error

They both validate against Sig-R ..  Do i just lattice it down to 0% or how would i go about this ?..


- nonce validates
- hash comes out the address
- etc etc... computes Z .. so on and so forth..

IT was not a txn... .but some malformed result that was being inserted...
that said i stripped it and am trying to compile it .. but comes out malformed..

I have the RS i can sign its shows valid and resolves to the pubkey.  -- this result is GOOD,.

Its the rest i have an issue with ... Can someone recommend a buillder a compiler for the signature data..  ive widdled it down to a few inputs

maybe i should just do 1  and test it?
Ask a real coder..yeah like who? cuz last time i did that on here... i got burned and my stuff stolen.   not looking for a repeat of that.

What do you do.... if there is a missing txn you cannot locate?   Which is not allowing the VALID CURRENT txn from not being accepted.

I made a txn  and everything is good..it checks out validates etc.... BUT when i go to push it i get a missing or spent txn warning...   This should be the one that is missing but how do i  adjust for it ?   dfb11825bc3c1dd1c0004fcbc70c900d91c70da90f19b3206a2cfcb645d0f646

Any help would be appriciated...  or are you all just going to hate instead?  lol

Thank you.

IS there a way to adjust for the missing item?
IS there a way to parse the data since its not on the chain 
i cant locate it... only thing left...argh.... figures.

ok someone ......  here just argh
i wish i could show values...

SO i looked over it all and restarted and saw i had values from back in December .. so i used those and ...


verified two Bitcoin ECDSA signatures with their known nonce (k) values:
Signature 1:
Signature 2:
Both signatures were successfully verified - meaning when we multiply k by the generator point G, we get points whose x-coordinates match the r values in the signatures. This confirms the k values are correct and can be used for private key recovery.


DEBUG: Scalar multiplication took 8.10ms
INFO: R.x matches r value!
INFO: Signature 1 verified successfully
INFO:
Testing signature 2:
DEBUG: Scalar multiplication took 8.42ms
INFO: R.x matches r value!
INFO: Signature 2 verified successfully
INFO: Success! Results: {'success': True, 'method': 'Signature verification', 'result': 'All signatures verified successfully'}


Now I can show you all the points used in the ECDSA verification:
  Public Key Point Q:
Q.x =
Q.y =d
    Generator Point G (the base point of secp256k1):
G.x =
G.y =
    For Signature 1, the R point (k*G):
R.x =
R.y =
    For Signature 2, the R point (k*G):
R.x =
R.y =

The logs show that for both signatures, the x-coordinate of the R point (R.x) exactly matches the r value in each signature, confirming the signatures are valid
Success! Results: {'success': True, 'method': 'Signature verification', 'result': 'All signatures verified successfully'}
Based on the verification results for address MONDO, the signature has been successfully verified on the secp256k1 curve. Here's what was confirmed:

    The signature coordinates are valid on the secp256k1 curve
    The nonce k =  was verified
    The R point (k*G) calculation matches the signature's r value
    Both the curve point validation and signature verification passed successfully

this isnt available anywhere so dont bother looking...


OKAY - it shows the addy block and everything is cool...  but im not seeing it and got another result for sig 2 ...  
wtf... like really.... and its not whatever this guy is talking about......

ok ok whatever... if i have RSK valid i should be able to sign and add a Z ...  any script that works id appriciate it.
Question ... K changes value from sig1 to sig2 ... so the addage if you have K you have PK inst correct? otherwise K would be the same value? .. or it shifting is normal?

Not a scam   just something i made and seems to work.  Granted i had a issue with the publick key logic, i think i fixed it..
What i dont get is why it would validate 2 sigs with the key but then be off on the publickey translation... so ill have to run it again ..
Just python with advanced lattice methods..

So i hit a PK which validated R on the sig i was running for a whale...
I have the following...   sorry i omitted relevant numbers but i think you get the idea...


My issue is... i dont see the address when i try dumping a bip44 1000adddy dump...
and while it validates the R to the currect signatrure ... i dont know what to do beyond that...

Can someone point me in the right direction... ?   yes i understand there is a margin of error and that lattice throws out blurps at times.. wasnt a standard lattice either..  
Thanks

DEBUG:lattice_recovery:Relative error: 0.0408481761
INFO:lattice_recovery:Successfully recovered private key: 0x6xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
INFO:main:Successfully recovered private key: 6xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
INFO:main:Verifying signature...
DEBUG:lattice_recovery:Verification details for k=0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, r=0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:
DEBUG:lattice_recovery:Direct error: some numbers
DEBUG:lattice_recovery:Wrapped error: same as above
DEBUG:lattice_recovery:Relative error: 0.0408481761
INFO:main:✓ Signature verified successfully

Great news! We've successfully recovered and verified the private key for signature 1234. Here are the details:
Private key: 6xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
The recovery process was successful with:
    Found a candidate private key in the initial lattice reduction
    Verification passed with ~4.08% relative error (within our threshold)
    Successfully verified the signature after recovery

INFO:main:Validation details:
INFO:main:Reconstructed k: 0xcxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
INFO:main:Negated k: 0x49xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
INFO:main:Original r: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
INFO:main:Direct error: some numbers
INFO:main:Wrapped error: some numbers
INFO:main:Relative error: 4.08481761%
INFO:main:Signature validated within acceptable error margin
INFO:main:✓ Private key successfully validated!
INFO:main:The recovered private key correctly reproduces the signature.

Not what i was asking... but nevermind i think its was a parsing error why that occured.
when checked didnt come out valid... so bleh...

So...  IF i have a matching R on "the lattice" (not any formula in here) against the signature is that enough to say its valid?   It does display a key but im trying to confirm the results before i bother converting it.
It seems the lattice doesnt like adding in the publickey into the formula and fails on add and inverse functions..    was attempting cross validation but after tending to a dozen flags i dont think that option will work lol

That all being said, i did it to 2 sigs and they both came back with a matching R ... then went to test on something else which failed... so that proofs it half way i guess..
Just want to know if the R matching is enough or if there is another method to confirm the result... ??

Riddle me this batman...

I was parsing some RSZ to review ... and i found the following..

RSZ with a short S .. used on 2  SEPERATE wallet addresses.. IDENTICAL RSZ ..    
Does this indicate a problem with the signing process? Its recoverable in regards to keys but i fall short of that...

So just wondering if anyone else has seen this before...
thx,

ps - dont really want to release the sigs..  and they are from the chain.


edit :  looking closer at it .. there are 2 sets like this for the same addreses.

Not the best choice .. i have it and it blows... ill give it to him just because.

Pass-ware which would be a better util ..   

Hey,

Just wondering if there is another way to calc for S and rewrite this and remove X if applicable

s1=(((x*rr)+z1)%N)

Thanks

Just wondering if anyone knows about this X=0 ?  How to finalize it etc..  

I dont want to say too much about it, as i dont know what to say... but wont be which sigs i have with that value.

Thank you.  

thank you.

your twitter link proves nothing.  and it wasnt circumstance on MY SHARED K data which moved 4 days later... and wasnt public data either.... In addition the attorneys agree and pundits who are smarter than us both... so could careless what nonsense you try to assert.  Its clear who stole it where else did he get the 100+ btc from cant even account for it.  So well see when the exchanges are subpoenaed, more so it was not MTGOX as all the funds were accounted for prior to this and marked.  
More so who do you think pointed it out to tokenview    but their assessment is incorrect.  That being said you being his friend i could careless what you say which my claim was legit so realize that and stop trying to say otherwise. What else are you going to try and be biased on? oh ya everything.... Mixers are money laundering maybe you need to look it up yourself ... and the cases of which the owners who were convicted of  doing that .. coinninja just to name one ... go do your own research.
More nonsense i see.. but opinions are like assholes everyone has one.. good thing there are lawyers to straighten things out.

So what if i was helping someone with this...better than spouting nonsense.

Anyways im done with this nonsense...       again thanks to everyone besides stalker which seems like a fitting name.  
Have a nice day.

Well its fake.. so not the 1st person to crack it .. figured such by the char count
Didnt know the address as the file was misplaced... so only had the hash..

Anyways thanks to the people who answered it who wernt trolls

Just as others crack wallets... and there are lists... this one makes no difference than those which are allowed in other threads.
38 chars is not a easy thing to do overall and just happened... so if its around great.. if not then oh well.. not holding my breathe on it.

yes i agree 99% of them are just fake overall... not here to discuss the morality over it... just wanted to know if someone had the file granted its most likely fake due to the char count..
Pretty simple question.  The owner was running it for over 1 year and had lost the file hence why im asking for it.

funny.. as the entire forum condones such behavior.  Its claiming and am looking on behalf of the owner anyways. Never said it was mine ...

you want to open that can of worms... then  what about my 10k which was stolen .... some people have short memories and biased perceptions i see...

Also let me point out to you  what about the mixers condoned on here which is money laundering...or the countless threads on hashes like this so give me a break......  

i digress.. save the troll comments.

No like the actual wallet.   i know its a core dat already.

Does anyone know what wallet this hash goes too?

$bitcoin$64$8701c2734f8cfd16b14a9d22165d7acb4275ee46a3b28e4f3c1b22900e7796d8$16$d5fbf738dd9c8922$113073$96$a51b29d430e980f3e493f0a0713f55fae91b708d07460b7856110dfda7ae85850223e32f897a61bd4e752ff1e36bdb61$66$03faf62cf99b86878abcd0321e191841428e290dffdd824942df087c3b94933794

cracked it 38chars but cant locate the wallet.  Does anyone have it?

Thanks