Topic: Elliptic curve math question - page 3. (Read 14045 times)
https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses This explains how the bitcoin address is created from the public key.
What Mike is getting at is that if you go to bitaddress.org today you get a private key and a public key address.
Currently there is no way to get the actual public key printed out at that web site.
In order to do the operation (public key 3) = (public key 1) + (public key 2) we need the actual public keys not the public key addresses.
The public key address (called the Bitcoin address on the paper wallets from bitaddress.org) is a number that is calculated from the public key. But you cannot calculate the public key from the public key address.
Also since public keys are very long compared to even public key addresses we would need the public key in a QR form so we don't have to type in the whole thing. Here is an example public key to show you what I mean:
This also shows you why we use public key addresses instead of public keys because they are so much shorter than the actual public keys.
Currently there is no way to get the actual public key printed out at that web site.
In order to do the operation (public key 3) = (public key 1) + (public key 2) we need the actual public keys not the public key addresses.
The public key address (called the Bitcoin address on the paper wallets from bitaddress.org) is a number that is calculated from the public key. But you cannot calculate the public key from the public key address.
Also since public keys are very long compared to even public key addresses we would need the public key in a QR form so we don't have to type in the whole thing. Here is an example public key to show you what I mean:
Code:
G = 04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8
This also shows you why we use public key addresses instead of public keys because they are so much shorter than the actual public keys.
I believe you have just enlightened me to another layer of bitcoin-y-ness. So there is a think called the public key address which is not the same as the public address. And it is not something that is easily reversible to?
Ok, now it is time for me to actually read the initial paper. It is obvious I am more clueless than I should be.
What Mike is getting at is that if you go to bitaddress.org today you get a private key and a public key address.
Currently there is no way to get the actual public key printed out at that web site.
In order to do the operation (public key 3) = (public key 1) + (public key 2) we need the actual public keys not the public key addresses.
The public key address (called the Bitcoin address on the paper wallets from bitaddress.org) is a number that is calculated from the public key. But you cannot calculate the public key from the public key address.
Also since public keys are very long compared to even public key addresses we would need the public key in a QR form so we don't have to type in the whole thing. Here is an example public key to show you what I mean:
This also shows you why we use public key addresses instead of public keys because they are so much shorter than the actual public keys.
Currently there is no way to get the actual public key printed out at that web site.
In order to do the operation (public key 3) = (public key 1) + (public key 2) we need the actual public keys not the public key addresses.
The public key address (called the Bitcoin address on the paper wallets from bitaddress.org) is a number that is calculated from the public key. But you cannot calculate the public key from the public key address.
Also since public keys are very long compared to even public key addresses we would need the public key in a QR form so we don't have to type in the whole thing. Here is an example public key to show you what I mean:
Code:
G = 04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8
This also shows you why we use public key addresses instead of public keys because they are so much shorter than the actual public keys.
Current Bounty On Javascript Code For This:
RobKohr - 2BTC
Edit: It must be complete and easy to use. Must be able to do the public key combination as well as the private key combination (for end users).
RobKohr - 2BTC
Edit: It must be complete and easy to use. Must be able to do the public key combination as well as the private key combination (for end users).
What RobKohr wants, I think, is a version of Bitaddress.org that also gives him access to the 65 public key bytes (0x04 + x[32] + y[32]), potentially in place of the Bitcoin address, potentially on the QR code as well. Am I right Rob?
In other words, just a checkbox that exposes ECKey.PubKey in hex (if I recall correctly), rather than going on to compute the full bitcoin address.
I am not sure I understood your interpretation of my question.
Given Priv1, and Pub1, from me, and let say Priv2 and Pub2 from you, a function would be:
function makeCombinedPublicKey(Pub1, Pub2){... return Pub3}
and there would be
function makeCombinedPrivateKey(Priv1, Priv2){... return Priv3}
This would be for the consumer to use to get after removing protective seals on both private keys. Priv3 would be the private key for Pub3.
The generation of Pub1, Priv1, Pub2, Priv2 could be provided by some other utility such as bitaddress, and could be independent from this pair of functions. Though if it was bundled up in a nice little module that included a function like:
function generateKeyPair(optional_seed){return [private, public]}
that would be a good inclusion.
I could see using this in the pdf printing script I created and adding something where the script will just print the additional keys on the bill (perhaps being smart enough to use a scan of an uncut sheet to extract the public keys for input and then printing to that sheet).
I have also not been able to find a citation for this exact thing (yet) I think mainly because it is such a basic fundamental algebraic concept. I expect no one is going to get a PHD (and therefore have published a paper) from such a simple concept.
I think you guys should seriously review the literature on this before (re)inventing more EC math. I'm not saying your workings are incorrect, just that there is already a lot of research into what you can do with ECC and a citation is more useful than a reinvention.
That's sound advice. I've not been able to find relevant citations. I'd actually be a bit surprised if anyone has studied techniques for multiple parties to agree on a private key that none of them can use. Is there a standard name for such protocols? As I understand it, neither verifiable secret sharing nor threshold signatures are what we want.
I think you guys should seriously review the literature on this before (re)inventing more EC math. I'm not saying your workings are incorrect, just that there is already a lot of research into what you can do with ECC and a citation is more useful than a reinvention.
I for one would be hesitant to implement any cryptographic technique that wasn't published in the relevant journals. Cryptography, especially this type, is subtle and subject to unintuitive failure modes. A paper published via the usual mechanisms carries a lot more weight than a forum post. This is also one reason why using scripts can be more attractive than other techniques - it's less efficient but much easier to convince yourself of its correctness.
For example, see: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1562272
Could you please read post #32 on this thread and see if you can see anything missing there - besides a citation, which I am working on. I think the proof is almost self evident. Since the two key system proposed is a natural group theory extension of the already accepted one key system it can only be broken to the extent the one key system can be broken. I for one would be hesitant to implement any cryptographic technique that wasn't published in the relevant journals. Cryptography, especially this type, is subtle and subject to unintuitive failure modes. A paper published via the usual mechanisms carries a lot more weight than a forum post. This is also one reason why using scripts can be more attractive than other techniques - it's less efficient but much easier to convince yourself of its correctness.
For example, see: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1562272
I think you guys should seriously review the literature on this before (re)inventing more EC math. I'm not saying your workings are incorrect, just that there is already a lot of research into what you can do with ECC and a citation is more useful than a reinvention.
I agree with you, though I will point out that the purpose of the math in question is to come up with a methodology that reduces the possibility that one person - the person who manufactured a physical bitcoin (me, for example), would be able to steal it by keeping the private key. In other words, reducing the risk profile from "can be stolen by one person" down to "can be stolen only by collusion by two (or more) specific parties".
Sure, there may be some theoretical exploit that causes this scheme to fail, but if only one person in the whole world is in a position to exploit it (me), and finding the exploit requires very rare expertise found only among mathematicians (definitely not me), it's probably not a big deal. A random attacker has nothing to work with - no private keys, no public keys - because all of these keys are going into a physical object. At best, he can attack an object he has or had in his possession. For every person who can attack the object mathematically, there's probably 1000 who can attack it physically, or can counterfeit it... that is to say, I think the community, in a sense, is already prepared for the possibility that they might one day hear they need to be cautious in some way about receiving physical coins from strangers.
Though I won't turn down the citation if someone can provide one (I cannot). I would not be opposed to more formal and rigorous analysis of the math, especially for the benefit of the bitcoin community at a future time when there are numerous producers of physical bitcoins, not just me.
I think you guys should seriously review the literature on this before (re)inventing more EC math. I'm not saying your workings are incorrect, just that there is already a lot of research into what you can do with ECC and a citation is more useful than a reinvention.
I for one would be hesitant to implement any cryptographic technique that wasn't published in the relevant journals. Cryptography, especially this type, is subtle and subject to unintuitive failure modes. A paper published via the usual mechanisms carries a lot more weight than a forum post. This is also one reason why using scripts can be more attractive than other techniques - it's less efficient but much easier to convince yourself of its correctness.
For example, see: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1562272
I for one would be hesitant to implement any cryptographic technique that wasn't published in the relevant journals. Cryptography, especially this type, is subtle and subject to unintuitive failure modes. A paper published via the usual mechanisms carries a lot more weight than a forum post. This is also one reason why using scripts can be more attractive than other techniques - it's less efficient but much easier to convince yourself of its correctness.
For example, see: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1562272
Current Bounty On Javascript Code For This:
RobKohr - 2BTC
Edit: It must be complete and easy to use. Must be able to do the public key combination as well as the private key combination (for end users).
RobKohr - 2BTC
Edit: It must be complete and easy to use. Must be able to do the public key combination as well as the private key combination (for end users).
What RobKohr wants, I think, is a version of Bitaddress.org that also gives him access to the 65 public key bytes (0x04 + x[32] + y[32]), potentially in place of the Bitcoin address, potentially on the QR code as well. Am I right Rob?
In other words, just a checkbox that exposes ECKey.PubKey in hex (if I recall correctly), rather than going on to compute the full bitcoin address.
Current Bounty On Javascript Code For This:
RobKohr - 2BTC
Edit: It must be complete and easy to use. Must be able to do the public key combination as well as the private key combination (for end users).
RobKohr - 2BTC
Edit: It must be complete and easy to use. Must be able to do the public key combination as well as the private key combination (for end users).
See, math can be fun 
You guys are making my head hurt. It sounds cool though
What I think would be interesting is to verify:
y^2 mod p = ( x^3 + 7 ) mod p for G:
1) Calculate y^2 mod p, get answer
2) Calculate ( x^3 + 7 ) mod p, get answer
I believe that answer from 1) should equal answer from 2)
Yeah, this pans out.y^2 mod p = ( x^3 + 7 ) mod p for G:
1) Calculate y^2 mod p, get answer
2) Calculate ( x^3 + 7 ) mod p, get answer
I believe that answer from 1) should equal answer from 2)
Code:
y^2 = 1067362225016502275772194909503713869376985974142797512091458491530306631211206623652669436957676354343630306950631573032330832513385319878364322508915776
y^2 mod p = 32748224938747404814623910738487752935528512903530129802856995983256684603122
x^3 + 7 = 166977061698153803977729810299616665720111080589888563362701662779994291659333477169534477572723704285154275133397811778652651956291844366636068483203593094558427352525126936769086968791554813695916119291254705683450242657305024007
(x^3 + 7) mod p = 32748224938747404814623910738487752935528512903530129802856995983256684603122
What I think would be interesting is to verify:
y^2 mod p = ( x^3 + 7 ) mod p for G:
1) Calculate y^2 mod p, get answer
2) Calculate ( x^3 + 7 ) mod p, get answer
I believe that answer from 1) should equal answer from 2)
y^2 mod p = ( x^3 + 7 ) mod p for G:
1) Calculate y^2 mod p, get answer
2) Calculate ( x^3 + 7 ) mod p, get answer
I believe that answer from 1) should equal answer from 2)
X = 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798
Y = 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8
Y = 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8
so in decimal
x=55066263022277343669578718895168534326250603453777594175500187360389116729240
y=32670510020758816978083085130507043184471273380659243275938904335757337482424
p=115792089237316195423570985008687907853269984665640564039457584007908834671663
y^2 = x^3 + 7 - p * 1442042049659660869506300006036683750029629333882594701370927246876626245108435 922902327776681700708714008192087431130951749952236093997894375239788520937
The equation of the curve is y^2=x^3+7 mod p
ByteCoin
G = 04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8
Bitcoin only uses the uncompressed form. It's worth pointing out that this number is actually a structure, because it represents a "point", not just a scalar value.
A "point" has an X and Y coordinate. The first byte, 04, means this uncompressed format, and can be considered a constant. The next 32 bytes are X, and the next 32 bytes are Y.
Constant = 04
X = 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798
Y = 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8
G is a public published value.
In compressed form it is:
G = 02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798
and in uncompressed form it is:
G = 04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8
Each private key is secret but even if you have all but one of them you cannot calculate the last one you need to get to the final public key.
In compressed form it is:
G = 02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798
and in uncompressed form it is:
G = 04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8
Each private key is secret but even if you have all but one of them you cannot calculate the last one you need to get to the final public key.
Was anything secret that might be easier to compute with multiple public addresses, for example this 'G' value that is common among all key calculations?
* or was the G (base point) necessarily public anyway?
* or was the G (base point) necessarily public anyway?
Just to answer your specific question about multiple key pairs. You can add together as many public keys as you want to and the corresponding private key will be the sum of all the private keys. I (and some others) are trying to come up with a way to use this property in a little side project we are working on. In our project, depending on how popular it gets, we may be adding together hundreds or even thousands of public keys and the private key would then be the sum of all the corresponding hundreds (or thousands) of private keys.
Jump to: