Author

Topic: another elliptic curve implementation to spread the risk of total loss? (Read 1613 times)

legendary
Activity: 2940
Merit: 1090
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-
hero member
Activity: 489
Merit: 504
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 Smiley
legendary
Activity: 2940
Merit: 1090
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-
hero member
Activity: 602
Merit: 512
GLBSE Support [email protected]
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.
legendary
Activity: 1288
Merit: 1076
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 :/
jib
member
Activity: 92
Merit: 10
Using XMPP would make the protocol more complex and harder to implement, and has no real advantages.
hero member
Activity: 602
Merit: 512
GLBSE Support [email protected]
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.
legendary
Activity: 1288
Merit: 1076
What about XMPP for network communications ?
And a NoSQL database for storing blocks ?
legendary
Activity: 1372
Merit: 1007
1davout
That sounds like an interesting idea
newbie
Activity: 32
Merit: 0
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?
Jump to: