I'll release a currency (not a bitcoin fork, no premining etc..., there will be a beta period) mixing proof-of-work and proof-of-stake early 2012, many problems have been solved, i'm working alone for the moment but i'll open once implementation is stable, stay tuned.

Designing and implementing a completely new protocol takes some time, especially if it needs some major breakthroughs.

I'm pretty sure future will bring you something you'll enjoy 

Yes, i won't trick the users, there will be a public beta on a test chain, we'll choose the distribution scheme then launch the official chain.

I'm going to release a new currency in few month and the distribution is a real problem, need to find the perfect balance.
For the moment i choosen to give a reward (near)proportional to the target, maybe i'll give a ~4% per year for 20years instead then decrease slowly if there is enough
early adopters.

The best way would be to find investors to back a bit the currency at launch, but it'll be hard (despite some technical breakthrough done recently) and all need to stay free and open

I'm still working in the shadows and looking the community point of views on this kind of subjects, protocol specifications and implementation (win7/Linux/Mac, iOS/android a bit later once Qt will be stable on these platforms) will be release all at once, the public review will then start and many tweaks will be done

It's a new client that uses "old"("official") bitcoin blockchain.

Main difference is that bitdollar-bc have more flexibility with wallet keys management.


I use c++/qt, i'm not used to work with svn/github but i'll put project on it if there are requests.

Bitdollar is a p2p currency protocol similar to bitcoin, a client of the same name is currently in development.
(more info: http://www.bitdollar.org/forum/viewforum.php?f=8)

Bitdollar-bc is a client for the bitcoin protocol.

Some people asking me if bitdollar is a fork of bitcoin or not, to make things clear:
-bitdollar-bc is a reimplementation of the bitcoin protocol, it'll always follow official client(bitcoin.org) rules and won't try to fork the chain or impose changes in the protocol.
-bitdollar is another project of protocol.

Both projects are distincts.

As i got few requests, i'm creating a topic on the bitcoin implementation in bitdollar.

I have renamed the implementation bitdollar-bc to prevent confusion with the bitdollar protocol.

Windows binaries: http://www.bitdollar.org/download/bitdollar-bc_1.0b2_win32.zip
Source code: http://www.bitdollar.org/download/bitdollar-bc_1.0b2_src.zip

Any questions are welcome.

UPDATE:
beta 2 released: http://www.bitdollar.org/forum/viewtopic.php?f=3&t=18

meme souci, oblige de passer par un proxy.

Sorry i hadn't read all your document in depth, it's done.

I would join you unfortunately i'm already working on the implementation of another protocol,
here the differences between the issues you point in the document, and how i handle that:

Higher transaction fees lead to slower transactions:
That's right, but it is a problem only if a large majority of nodes do that and if some does:
Since transactions are spread all over the network, only the transactions' hash are transfered in blocks.
Nodes are supposed to already have the transaction in inventory, if they dont have, they wont validate
the block until they have received all.
Low block spread is bad for all nodes, but the block of someone that kept some transactions will be transfered
over the network slowly compared to others and could lose race.

(there is also a system to extend the transaction fee of an emited transaction, which could be used to
"award" nodes having it, if client see that transaction has been correctly spreaded)

Your way to solve that problem is good but each transaction would need to access to more accounts which have a cost in disk IO
also i use a one time signature scheme (using hash chains) which can't do that, an emited transaction can't be modified.

Enforced limits are not optimal and Not truly decentralized:
i haven't put limits, limits means doubts in the protocol capacity.

Unmanageable storage requirements:
Huge storage needs also means huge bandwidth needs.
By reducing this, we increase the network number of nodes, strenght
and reduce the transactions fees.

The way i manage accounts and transactions is different, but final result is similar (transactions are only stored 3month, all is kept in a list containing all accounts).
I differenciate account and addresses (address = public key, used to create an account).
Very old accounts without activity also have a small fee each year (these will be mostly account of users that have lost their private key)

I also think storage is a problem since it is the easiest way for someone to attack the network.
For example, without being paranoid, someone could use 1million $ to create transactions that will
take the most possible definitive storage in the chain, that could make serious problem to nodes.
And it could be far more, mass storage capacity is part of the network security.

(Assuming the network is a real p2p network and that nodes have average user disk storage, if there was only
few hundred nodes maybe they could handle, but the currency would not be "p2p" anymore)

No unnecessary difficulty:
I have keep the way bitcoin manage the block race, but with some optimizations and more challenge
between nodes that spread the block.

Proof-of-work as ’currency’:
the way b$ is done, i could not handle a non fixed number of units.
instead i have made the award proportional to the target a of block

Most of these issues are what make me start a new protocol.

Any change can't be done easily and each design decision (protocol or implementation) can be source of conflict.
I had so much change to do that it was impossible to merge them with the current implementation, the main source of problem
was to make a client only version (that was the early goal of the bitdollar client)
Instead i started working on a different protocol (i have posted the main differences with the bitcoin protocol http://www.bitdollar.org/forum/viewtopic.php?f=8&t=14 )

due to lack of interest for this implementation i haven't worked a lot on it
i have added sighash and script support, but scripts are not yet handled exactly like bitcoin does
since i used my own big integer implementation, instead of the openssl big integer (minor issue)
this is only a problem for those who would like to solve blocks, but none tried afaik

no problem noticed using b$ as simple client, except the main view which display too much informations on transactions

for the moment i'm focusing on the bitdollar protocol (very different by design), but if i feel
more interest in the bitcoin implementation, i'll rework it

as said without wallet, coins are lost
if wallet file is corrupted, i can take a look into it to move the address contained into another wallet

a backup of the wallet can be done safely but new address created won't be in the backup wallet
that's why bd give the choice to the user to create a new address for the change or not, creating new
address make your transaction less traceable, but force user to rebackup his wallet

bd creates a temp backup of the wallet before updating it, if computer restart
when the program is writing into the wallet, the temp backup file should be here
the file name is something like : youwalletfilename.XXXXX.bak (where XXXX are numbers)

but if both application and wallet was gone, maybe an external program erased them

do you have the destination address that should have received the btc? i will check the transaction in the block
if you rescue your wallet but coins are not still received, i'll take a look into it

minor differences would be fixed quickly, and chains automatically merged
one good point is that it could detect irregular tx that try to use an exploit in bitcoin client

but that problem is only for users that try to solve blocks, and solving blocks with bd is really not effecient
at all

wallet is always wiped and always encrypted on the disk using a default pwd "" (if no pwd set)

i'll be aware of futur bitcoin changes, it can still be used safely as simple client (well except it's a beta for the moment but it's not the same problem)
i think bd is more restrictive than bc, it should not accept a tx that is rejected by bc
so i could tests it with bitcoin client and check if it is accepted

rollbacks are managed

sighash is not used but it could be, i'll support it
nlocktime is ignored in bitcoin too isn't it?

i've reuploaded packages for small fixes (systray, sendmoney window size and tx are now sent correctly on the network)

i think script support is the only thing missing to be fully compatible with bitcoin client
i'll add it (that was my last thing "todo") but that kind of scripting is quite dangerous

i've noticed two small bugs:
-when reducing program in systray, no icon appears (./res folder is missing, i'll add ressource into the program directly)
-downloading blocks at first launch can be stopped before the last block, need to disconnect/reconnect

my goal is to manage bitcoin protocol exactly like bitcoin client