Bitcoin Forum

Bitcoin => Bitcoin Discussion => Topic started by: bitcoin2 on February 01, 2011, 10:45:29 PM



Title: another elliptic curve implementation to spread the risk of total loss?
Post by: bitcoin2 on February 01, 2011, 10:45:29 PM
I would like send a part of my bitcoins to a wallet which private key is not generated by openssl. In my worst case scenario there could be an openssl bug like the openssl-debian bug in May 2008. Another elliptic curve implementation would spread the risk of a total loss. What do you think?


Title: Re: another elliptic curve implementation to spread the risk of total loss?
Post by: davout on February 01, 2011, 11:05:24 PM
That sounds like an interesting idea


Title: Re: another elliptic curve implementation to spread the risk of total loss?
Post by: grondilu on February 01, 2011, 11:31:08 PM
What about XMPP for network communications ?
And a NoSQL database for storing blocks ?


Title: Re: another elliptic curve implementation to spread the risk of total loss?
Post by: Nefario on February 01, 2011, 11:40:01 PM
What about XMPP for network communications ?
And a NoSQL database for storing blocks ?


sqlite is probably the best client database to use. There are many object frameworks to use with it if you don't like sql.


Title: Re: another elliptic curve implementation to spread the risk of total loss?
Post by: jib on February 01, 2011, 11:52:54 PM
Using XMPP would make the protocol more complex and harder to implement, and has no real advantages.


Title: Re: another elliptic curve implementation to spread the risk of total loss?
Post by: grondilu on February 01, 2011, 11:53:08 PM
database, is a matter of taste and developer preferences really, I personally would use riak and definitely would not touch any of mysql/postgress/sqlite and ko .


Riak is not even in the debian repo :/


Title: Re: another elliptic curve implementation to spread the risk of total loss?
Post by: Nefario on February 02, 2011, 12:07:53 AM
database, is a matter of taste and developer preferences really, I personally would use riak and definitely would not touch any of mysql/postgress/sqlite and ko .


I am talking about a db to use on a client. sqlite works very well on windows,osx,linux etc. It also has excellent bindings for all popular languages. So if you had to choose a db for a client, then I would recommend it.


Title: Re: another elliptic curve implementation to spread the risk of total loss?
Post by: markm on February 02, 2011, 03:14:34 AM
I am thinking of doing "BotCoin", because I need to do at least one currency anyway for Galactic Milieu.

I would start from the existing BitCoin codebase though not a whole 'nother language.

One idea I have for it is to offer "Your own BotCoin-based currency!!!" that instead of forking the chain is DIRECTLY based on BotCoin, being implemented as cosmetics of the client (theme / skin type idea). Peg "your" currency to BotCoin simply by fixing (not floating!) the conversion rate directly in "your" currency's client.

I have to hack the code anyway to make the currency the Hacker nation in the Galactic Milieu should be using. So if this could also lead to national currencies for all the nations featured in Freeciv each being able to have their own national theme/skin that'd be great too.

Not having to have multiple chains would be handy for game currencies, but for the game version I would probably have the currencies able to float their conversion rate since foreign exchange rates and forex trading would be important part of the game. Fixed conversion rates wouldn't be useful for that but not having to have multiple chains would be.

-MarkM-


Title: Re: another elliptic curve implementation to spread the risk of total loss?
Post by: Cdecker on February 02, 2011, 11:18:58 AM
Well the client actually is pretty easy to reimplement. The problem is the protocol which is much harder to change. The SHA1 algorithm and Elliptic Curve algorithms are in fact anchored in the protocol. So my wishlist should the protocol be designed from scratch:

  • Pluggable algorithms, that can be replaced once a vulnerability is found (with a transition time, and reaggregate all bitcoins with the new algorithms by sending them to a new address)
  • Network Byte ordering (Big Endian!!!)
  • Not a binary protocol, or the possibility to use another transport, like JSON (right now we hash the binary content of the transaction to get the transaction hash, same for Blocks)
  • Not relying only on TCP (other transports such as HTTP, SMTP and UDP would allow more people to participate and it would be harder to filter)
  • Better structured network to be able to detect network partitions
  • Better structured networt to scale together with the network (I already proposed dynamic degree hypercubes in another thread)

And many more to come :)


Title: Re: another elliptic curve implementation to spread the risk of total loss?
Post by: markm on February 02, 2011, 11:29:16 AM
Hacker Nation needs *you* !

Makes sense the Galactic Hackers should have something a tad more advanced than these Earthlings have, lets see what can be done!

-MarkM-