Topic: Issues with programming, Bitcoin, Private Keys, and Public Keys - page 2. (Read 4935 times)

http://www.cryptopp.com/

The only thing that appears to be incorrect in my application (as it stands) is the multiplicative inverse.  I've coded the majority of the rest of the ECDSA algorithm as I currently intend to implement it.  If you know of an ECDSA library in which all I have to do is give it the private key, and it'll kick back the public key, please let me know and give me a simple example of that. 

Like:

publickey = prvtkeytopublickey ( )

If you know of one that simple I would be very grateful if you could identify that for me.  I can even do these equations on sagemath.com but C++'s coding just doesn't work with the ECDSA equations as smoothly as one would hope.

Public keys are generated from the private key using ECDSA and secp256k1.

You have 3 options:

1. Simply use an ECDSA library (easiest)
2. Take a look an existing library and try to reimplement it. ( a bit harder)
3.  Code ECDSA from scratch (hardest).

If you want to go the hard way, start here:
http://en.m.wikipedia.org/wiki/Elliptic_Curve_DSA

And you'll need the curve bitcoin uses (secp256k1)
https://en.bitcoin.it/wiki/Secp256k1

You're right, but when I use the (a > 1) it doesn't produce even a single correct x or y coordinate. 

I'm not "mak[ing] bitcoin".  This is a small program that is supposed to calculate the x and y coordinates from one's private key.  these x and y coordinates are basically your "public key".

Poster is talking nonsense 

SHA1? I haven't read the bitcoin protocol in a while, but last I checked it was SHA-256.

your code
while (b != 0)

the rosetta code
while (a > 1)

your while loop will terminate for very different reasons.
The keys you got right you must have gotten lucky with
now mind telling me what the heck your doing?

calculating the modular multiplicative inverse, how does that make bitcoin?

I thought bitcoin took a big ulgy number and computed it's sha1.
if the sha1 was less then some other ulgy number called the merkle root then the mining program would say yea!

I really don't have much interest in bogging myself down in low level functions but
With a quick look , seems you are not using the same equation...they are staring off
Defining r as a mod b, and I don't see you doing that.

the gunpowder treason and plot, i can see no reason why the fifth of november should ever be forgot.

sorry, couldn't resist.

Appreciate the support.  Though I have provided a large portion of the necessary program for people to understand some of the bitcoin equations...  I wouldn't mind some additional input either. 

http://rosettacode.org/wiki/Modular_inverse

Supposedly shows the coding for C++ for modular multiplicative inverse (which is my "mul_inv" function).  Mine is basically the same equation but the results are not what they are supposed to be.  If anyone can gleen any insight on that and how, maybe, I need to modify it, I'd really appreciate it.  Once this is solved it could assist anyone in understanding this stuff....including (and, perhaps, especially) myself.

This whole dilemma arises because with the 512 int variables, one cannot divide them normally in C++ as C++ and these particular integers do not convert into decimals, so one has to work with them solely as integers (which is kind of a pain).

I agree... let him code it if he wants to!

Gotta say though, I don't agree at all about DeathandTaxes having any kind
of superiority complex.  I've been in several conversations
with him, and read many of his posts, and I've never seen him talk
down to anyone.

You'll have to excuse Death and Taxes's god complex, he likes to butt in conversations and push his own views onto people(i.e discourage them from reimplementing stuff).

Even if what I'm doing fully fits the definition of "reimplementation", It doesn't sound so bad due to the following:

All of us are trusting Bitcoin, the programming, the algorithms, etc.  I think it stands to reason that we have nothing to lose by better understanding the equations as fundamentally as we really can.  What if one in a million people notices something..."wrong" with it?  That's kind of one of the very points of "open source".  Anyone who wishes to verify the coding is permitted and able to do so.  Obviously understanding it is another matter, but with posts like mine, we may be able to assist people in doing just that.

If the man wants to reimplement something, let him. That is how he is going to learn.

Thanks jonald_fyookball, I checked that out.  Turns out that wasn't enough to get it fully going.  Currently researching how to do the modular arithmetic from scratch, its basically the next step.

see this:

http://stackoverflow.com/questions/17818092/unpacking-strange-commas-in-python

jonald_fyookball, I didn't say I had searched for that in particular.  I hadn't googled it at that time.  I hadn't considered that phrasing or consider the existence of something as simple as an "ECDSA library".

DeathandTaxes, I do not doubt the accuracy of your analogy, but to the extent I can piece things together, I intend to continue.  Your references to speed are accurate.  Though when my processing power is bottlenecked by my SSD I also have RAMDisk and can run the entire operation from RAM if I need too, though my bottleneck has actually been the processing.

If anyone can make sense of:

def inverse(x, p):
"""
Calculate the modular inverse of x ( mod p )
the modular inverse is a number such that:
(inverse(x, p) * x) % p == 1
you could think of this as: 1/x
"""
inv1 = 1
inv2 = 0
while p != 1 and p!=0:
inv1, inv2 = inv2, inv1 - inv2 * (x / p)
x, p = p, x % p
 
return inv2

Which is in Python, it would solve my dilemma.  The commas don't make sense to me (IE: "How can a comma work with the equal sign").  That seems to be the part of my program which doesn't function correctly.  Yes, my code has that as well; that's the only part of my code I don't understand piece for piece (as I had to copy and paste that part).  All I'm really trying to do is to get this code to work.  This code should just spit out the public key for addresses represented by the number 4 through the number 10.

If your programming skills are "not all that great" I would strongly recommend not trying to implement the nuts and bolts of low level crypto.  Even working with high level bitcoin specific libraries (like bitcoinj for java) can be a challenge and using libraries like that all the low level plumbing is abstracted away.   This isn't to say you shouldn't ever build a crypto library but to start there but it would be like someone deciding they want to make a video game and despite having limited programming skills accepting nothing less than writing it all in assembly language so it is optimized.

As for using OpenCL for acceleration I am pretty sure it would be a decelerator.  I would recommend a lot of reading (both wiki and the bitcoin core source code) about how Bitcoin works.  Verification of transactions and blocks is almost never CPU limited.   The disk (IO not capacity) and network bandwidth are more significant bottlenecks, after that is probably memory space (although luckily RAM is dirt cheap), far behind that would probably be disk capacity (especially for higher performance disks like SSD), and then way way way behind that would be processing power.

no offense but you need to work on your googling skills...

looks like plenty of options.

https://www.google.com/?gws_rd=ssl#q=ECDSA+library+C%2B%2B

Current theory is the only thing wrong with my code is something to do with the inverse function.  My programming abilities are not....all that great.  I would DEFINITELY like to implement opencl as it would run substantially faster to (at least that is my understanding) but I might trip over those ideas even harder than my current dilemmas.  Based upon your suggestions I will look into those things in the meantime though, thank you.