These numbers are all totally unverifiable. 

Who would loan money to a geographical location?  lol 

I'd like to clarify this terminology a bit. 

When I think of your three examples, yes the word irrelevant comes to mind.  The issuer of the paper, the spell checker, and the short name of the curve, are all things which I don't even need to know to use bitcoin or to write my own client.  One might even say "provably" irrelevant for that reason, in that the relevance in question here implied by the forum in which we are using.  However I personally would avoid using that terminology, perhaps because of my mathematics background.   

However the G points are hardly irrelevant in this context, please correct me if I am wrong.  If I don't know them I can't validate TXs, can't sign TXs, and so I can't use bitcoin at all.  Every ECC operation in bitcoin requires every bit of G to be exactly right.  When you say G is provably irrelevant, I can only assume (and I'd rather not hence this reply) that you mean a choice of G cannot effect the ability of an attacker to brute force a private key.  While there are convincing arguments of that in this thread, I wouldn't call any of them a proof.  AFAIK the difficulty of discrete logs, on elliptic curves, or even the difficulty in factoring large numbers, has not been proven and probably a proof that these things cannot be done in polynomial time would be equivalent to a proof that P!=NP. 

   

   

I understand how the choice of G can be irrelevant.  However this fact is irrelevant to my question: why were they chosen as such?  My argument here is for better marketing.  I'm sure you understand the "nothing up your sleeve" motivation..  sure having something in your sleeve is not going to have relevance to ECC but the idea is to still show that there is nothing in your sleeve. 

My question stands:  where did those numbers come from?  The probable answer is that they came from a random number generator that was lying around at the time, probably initialized by the date.  It's too bad this wasn't documented.     

 

Thanks, if you mean me yes I was not talking specifically about the bada55 curves, though thanks for explaining how they are badass   I was looking for some insight into whether any of the vulnerabilities mentioned by Daniel J. Bernstein and Tanja Lange are serious and why nobody has added more curves to the openssl default list. 

I'm not too concerned with the 977 parameter but to the untrained eye of for example an investor the presence of unexplained numbers in the generator could still be troubling.  Earlier in the thread we heard: 
 
SECG chair Dan Brown: 

3. The base point G is something I cannot explain, [snip]...   I strongly doubt that G is malicious, [snip]

OK so I took him a little bit out of context but you can see how someone researching the security of the DSA of bitcoin might not feel 100% satisfied.   It's a pity we can't do better and determine where they really came from but I guess whoever picked those points probably had no idea they would one day secure millions of people's finances.

Shall we offer a bounty? 

For normal usage I am considering a signature verification operation which just for fun is:

sig = ((HashOfThingToSign + EccMultiply(Gx,Gy,RandNum)%N*privKey)*(modinv(RandNum,N))) % N

If I stare at this long enough I can convince myself you are right..  and the more I deal with really big numbers like these
the more I think it is bulletproof.   


 but I'd still love to hear some story about where these lovely numbers Gx and Gy come from,

0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798,
0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8

or

55066263022277343669578718895168534326250603453777594175500187360389116729240,
32670510020758816978083085130507043184471273380659243275938904335757337482424

I've heard:  "value of G should be generated canonically (verifiably random)."

"a year-old U.K. company that specializes in secure Bitcoin storage"

Great they can store my bitcoin for me!  I'm pretty sure that's what Satoshi had in mind.  This can only end well.   

Nice post thanks!  I am hoping that the silence from bitcoin core devs on cryptonote will end soon.  I hope they are all trying to break it right now.

Don't forget also that there has been decentralized money for thousands of years in the form of precious metals.  Whats new is the ease of assay and public triple entry accounting system.   

What, no slides about their revenue from malware advertisement and scam shilling? 

I would go with jester.  Or perhaps disposable ambassador. 

Short answer:  no.

Long answer:  if the wallet is running on an offline machine in a faraday cage then yes

You are missing something fundamental about the mining here.  If bitcoin is worth X in 2020 that means miners will spend 12.5X on electricity every 10 minutes in 2020.  It will be worth it for miners to spend that much on power; that's what we mean by "worth X".  No technological improvements can change that, it is the fundamental algo of bitcoin that miners get new coins.  If coins are worth more they will spend more on power.       

I can't help but notice that not one of the safecurves.cr.yp.to families are implemented by openssl:

$ openssl ecparam -list_curves
  secp112r1 : SECG/WTLS curve over a 112 bit prime field
  secp112r2 : SECG curve over a 112 bit prime field
  secp128r1 : SECG curve over a 128 bit prime field
  secp128r2 : SECG curve over a 128 bit prime field
  secp160k1 : SECG curve over a 160 bit prime field
  secp160r1 : SECG curve over a 160 bit prime field
  secp160r2 : SECG/WTLS curve over a 160 bit prime field
  secp192k1 : SECG curve over a 192 bit prime field
  secp224k1 : SECG curve over a 224 bit prime field
  secp224r1 : NIST/SECG curve over a 224 bit prime field
  secp256k1 : SECG curve over a 256 bit prime field
  secp384r1 : NIST/SECG curve over a 384 bit prime field
  secp521r1 : NIST/SECG curve over a 521 bit prime field
  prime192v1: NIST/X9.62/SECG curve over a 192 bit prime field
  prime192v2: X9.62 curve over a 192 bit prime field
  prime192v3: X9.62 curve over a 192 bit prime field
  prime239v1: X9.62 curve over a 239 bit prime field
  prime239v2: X9.62 curve over a 239 bit prime field
  prime239v3: X9.62 curve over a 239 bit prime field
  prime256v1: X9.62/SECG curve over a 256 bit prime field
  sect113r1 : SECG curve over a 113 bit binary field
  sect113r2 : SECG curve over a 113 bit binary field
  sect131r1 : SECG/WTLS curve over a 131 bit binary field
  sect131r2 : SECG curve over a 131 bit binary field
  sect163k1 : NIST/SECG/WTLS curve over a 163 bit binary field
  sect163r1 : SECG curve over a 163 bit binary field
  sect163r2 : NIST/SECG curve over a 163 bit binary field
  sect193r1 : SECG curve over a 193 bit binary field
  sect193r2 : SECG curve over a 193 bit binary field
  sect233k1 : NIST/SECG/WTLS curve over a 233 bit binary field
  sect233r1 : NIST/SECG/WTLS curve over a 233 bit binary field
  sect239k1 : SECG curve over a 239 bit binary field
  sect283k1 : NIST/SECG curve over a 283 bit binary field
  sect283r1 : NIST/SECG curve over a 283 bit binary field
  sect409k1 : NIST/SECG curve over a 409 bit binary field
  sect409r1 : NIST/SECG curve over a 409 bit binary field
  sect571k1 : NIST/SECG curve over a 571 bit binary field
  sect571r1 : NIST/SECG curve over a 571 bit binary field
  c2pnb163v1: X9.62 curve over a 163 bit binary field
  c2pnb163v2: X9.62 curve over a 163 bit binary field
  c2pnb163v3: X9.62 curve over a 163 bit binary field
  c2pnb176v1: X9.62 curve over a 176 bit binary field
  c2tnb191v1: X9.62 curve over a 191 bit binary field
  c2tnb191v2: X9.62 curve over a 191 bit binary field
  c2tnb191v3: X9.62 curve over a 191 bit binary field
  c2pnb208w1: X9.62 curve over a 208 bit binary field
  c2tnb239v1: X9.62 curve over a 239 bit binary field
  c2tnb239v2: X9.62 curve over a 239 bit binary field
  c2tnb239v3: X9.62 curve over a 239 bit binary field
  c2pnb272w1: X9.62 curve over a 272 bit binary field
  c2pnb304w1: X9.62 curve over a 304 bit binary field
  c2tnb359v1: X9.62 curve over a 359 bit binary field
  c2pnb368w1: X9.62 curve over a 368 bit binary field
  c2tnb431r1: X9.62 curve over a 431 bit binary field
  wap-wsg-idm-ecid-wtls1: WTLS curve over a 113 bit binary field
  wap-wsg-idm-ecid-wtls3: NIST/SECG/WTLS curve over a 163 bit binary field
  wap-wsg-idm-ecid-wtls4: SECG curve over a 113 bit binary field
  wap-wsg-idm-ecid-wtls5: X9.62 curve over a 163 bit binary field
  wap-wsg-idm-ecid-wtls6: SECG/WTLS curve over a 112 bit prime field
  wap-wsg-idm-ecid-wtls7: SECG/WTLS curve over a 160 bit prime field
  wap-wsg-idm-ecid-wtls8: WTLS curve over a 112 bit prime field
  wap-wsg-idm-ecid-wtls9: WTLS curve over a 160 bit prime field
  wap-wsg-idm-ecid-wtls10: NIST/SECG/WTLS curve over a 233 bit binary field
  wap-wsg-idm-ecid-wtls11: NIST/SECG/WTLS curve over a 233 bit binary field
  wap-wsg-idm-ecid-wtls12: WTLS curvs over a 224 bit prime field
  Oakley-EC2N-3:
   IPSec/IKE/Oakley curve #3 over a 155 bit binary field.
   Not suitable for ECDSA.
   Questionable extension field!
  Oakley-EC2N-4:
   IPSec/IKE/Oakley curve #4 over a 185 bit binary field.
   Not suitable for ECDSA.
   Questionable extension field!

What's the consensus here.. should we not be using openssl?  Should we use openssl and add the safecurves by hand?  Or just ignore the supposed vulnerabilities listed by the safecurves website and continue to use one of the above curves like secp256k1? 

Gold is valuable because the annunaki used it as money on nbiru and continue to steal it from earth in giant spaceships, or perhaps because bodies encased in it can be smuggled out of the Earth's galactic quarantine.  Or maybe it is the health benefits of mother earth's essence.  

OK sorry but my point is we need some more creative stories about bitcoin.  Get to work please church of satoshi founders!!  

This looks like a beautiful synergy of a premined coin which exists because it's founders think more currency in their control will make them real friends and a "are you trying to raise money?  let us make that more difficult for you and take some of it" public service.  Straight from fiat mordor.  Am I missing something? 

Interesting.  This type of mining collusion seems more applicable to chains where the reward is tied to difficulty (e.g. PPC, XPM).  This kind of collusion on mainnet bitcoin appears to me as a very unstable position in game theory space as non-colluding miners will be even more incentivised to do real hashing once the collusion begins.

+1   

Entropy should always at least be visible in an editable field, though it could be initially filled with PSRNG output.

Cards, dice, free association, it doesn't matter.  Let the user decide.  That way as a wallet dev you will never be the one that blew it.   

 

Please publish your paper so we can read it, thanks.

Thanks for your reply.  
Well I don't think there is anything we can really do about that.  After all, you are welcome to declare illegal in your jurisdiction anything you like no matter what authority I claim to have.  However with bitcoin there is nothing really to declare illegal because we are dealing with an informatics primitive.  Every number is a private key.  Trying to prevent people from using this kind of communication is really like trying to prevent people from using any communication or using symbols to convey meaning.  Of course I shouldn't underestimate the insanity of those who feel they have the right to make laws...  if you have a way we could avoid that kind of problem I'd sure like to hear it  
  

What aspect could a legal authority improve on?  Currently we know exactly when and how many newly issued coins there are, exactly what the money supply is, and the rules are strictly enforced by all parties in records auditable publicly forever.  How would this "official authority" you suggest improve on this strictest regulation scheme ever devised by man which is already in place?