Topic: Bitcoin's implementations (Read 13619 times)

AFAIK helmut (nick on #bitcoin-dev IRC) is working on python implementation (based on Twisted). Personally I'm looking forward alternative python implementation...

That pybitcoin effort does not seem to have been updated since August 2010 (it is now the end of December 2010.)

What efforts (that one, or others I have not noticed yet) to reverse engineer the protocol and write other clients (C or Python being the languages I am fluent in) are currently active?

Such work seems to me to be critical to the success of bitcoin.

I think we can generalize the idea: having multiple currencies is an additional roadblock to the adoption when it comes to interchangeability. If on the other side you intend to create a parallel community that does not aim to be interchangeable world wide, it might be in fact advantageous to split from the main chain.
Having multiple currencies create problems since then you'd have to exchange what you have for the currency the seller expects, and if such exchangers that have the right amount available are scarce there is the opportunity to have a personal gain.
I'd stick to the main line as long as possible, to facilitate ease of use and attract more people.

There is one rather limited circumstance where I would like to create a second "Bitcoin" like currency that does make sense: within a MMORPG.

I'd like to create a game that uses a bitcoin-like currency (actually multiple "currencies") to be used as a means for "resource creation" within the game architecture itself.  I detailed my ideas on this thread here:  https://bitcointalksearch.org/topic/mmorpg-353

If anything, that is the exception that proves the rule, and I would have to agree that creating multiple currencies complicates the whole process.   The only other possible exception would be to establish different network rules, where there is a substantial community that doesn't agree with the policies being implemented that have at least so far been arbitrarily set.  The "right to fork" is always present, and if the community isn't happy with the rules there is always the possibility to set up different rules for say generating coins or for transaction fees.

I would hope that for now any sort of disagreements with policies and network rules could be resolved through a consensus process and a strong defense of why each of the current rules exist at the moment.  It would have to be a major schism of the community and a political act to create a separate coin network that would have a chance to compete on a substantive basis.  At the moment, I don't see that being too much of a problem and the concept of Bitcoins is so new that I don't see those kind of factions forming within the Bitcoin community that would warrant such a split.  There are philosophical differences, but not enough for a fork.

Great, thanks for the support guys. As for the aforementioned reverse engineering of the protocol, it's located on Google Code http://code.google.com/p/pybitcoin/wiki/BitcoinProtocol.

We were considering putting it on the Wiki on bitcoin.org, but we thought it important to have it as redundant as possible, and we'll try to contribute the details back to the mainstream client and the local wiki.

We are far from knowing all the details of the protocol, so every helping hand is welcome 

I am all for it.
Porting C++ code to a memory limited embedded environment is a pain.

I'm thinking about writing a minimal-dependency C library implementation of Bitcoin. There's the other thread here where people are reverse engineering the protocol for a python client. More and more alternative implementations will appear when Bitcoin gains more momentum, especially since the stock implementation can't possibly cover all the Bitcoin use cases (think of a laundromat that accepts Bitcoins for example). Alternative implementations will happen and decent protocol standardization is the only way to prevent potential problems with multiple implementations inter-operating on the network. Multiple implementations will make the network grow faster, standardization will make the network more robust. Both will dramatically increase security, as a lot more potential problems will be discovered.

Reverse engineering will occur and regardless of satoshi's desire to have dominant control over the one and only [multiplatform] client, this will seemingly and ultimately ruin some things.  I am not sure of the legality, but I do know that if there a kind of legality enforced, I would lose all interest in mainstream Bitcoin client and would expect a fork, if at all possible.

However, if things were to be more open and documentation were made available, that would truly help to establish the Bitcoin community much more exponentially and bring incentive for others to create clients for other architectures or environments, such as embedded devices, mobile/portable devices and everywhere and when that happens, Bitcoin client everywhere will be very helpful to increase adoption.

Right now, as it shows very well, there is very limited developer effort put into development of Bitcoin.  This is gradually increasing and there are very skilled/talented developers that are contributing a LOT and amazing code, but, more is better.  More eyes to examine the code, but more importantly, more eyes to understand how things work, e.g. documentation, is much more helpful than reverse engineering an understanding of how things work by looking at code.

We're trying to reverse engineer the protocol so we can create custom clients, that will work together on the main network, to create some competition, and to allow for lighter clients running on a wider range of devices.

I'm personally against forking the network for each client as it segments the network, in the meantime weakening the main network. I don't see the objection about failing clients to be actually to comply with the protocol to cause problems, because if we don't exercise all possible scenarios, someone sooner or later will come along and cheat the others. It's about strengthening the protocol by checking the boundaries, and it's better that we expose these issues to the developers of the various clients, than someone abusing and keeping the issue silent.

I've seen this mentioned before so it's not my idea, but I definitely agree with it.

It makes zero sense from a global perspective to have multiple Bitcoinesqe currencies. Each will be weaker than their combination would be. A small government could blast us away right now, or a medium sized corp for that matter. If all honest people work on the same currency we will be much stronger than if we are split.

But no one is looking out for the global benefit. On the individual side of things it makes no sense to start accepting a currency with all the same features as Bitcoin, but none of the places to spend or exchange. Bitcoin is transitioning right now from a great idea to an actual community and economy which will make it really useful. It has taken about a year to get this far, and a new currency would have the disadvantage of not getting the help of people already in Bitcoin's orbit. Additionally, a rational actor comparing two systems with the same features, one with huge backing and the other brand new, will always choose the widely used one.

Now if the new version has some totally great new features then that's a different story. But a new name and different generation rate probably isn't going to do it.

 

+1

Sorry, what are you proposing beyond what is already done? Seems like you were not paying attention. Block generation is already a background task on CPUs which would be idle otherwise.

If you wish to change the steady 6 blocks / hour production of the block chain you should consider all the implications carefully.

If you just want to have faster transactions consider something like www.mybitcoins.com banks which can allow instant transactions between members.


Maybe the reason it got so little attention was people did not understand what it was getting at.

This post needs more attention and replies!  Anyone?   Prease?


Perhaps upon their next appearance they can clarify better.  There seems to be something useful to come out of this thread.

The other currencies you listed (Pecunix, LR) are backed by gold and silver via the USD or EUR, so they are not really new currencies as much as more anonymous forms of paypal. Other e-currencies I have run into over the past couple years are also usually backed by gold or silver ultimately.

Bitcoin, in contrast, does not derive its value from gold and silver. Instead, bitcoin derives its value from the same things that give gold and silver its value. It:
1. is suitable for transactions
2. has limited quantity (scarce)
3. is not arbitrary: it is the currency that has the most widely recognized transaction history, measured by CPU time

I can imagine there being 2-3 different CPU-based currencies like bitcoin with exchange rates as you said, but it would be better for only one such currency to exist to preserve the non-arbitrary nature of the leading currency and promote its legitimacy, which everyone using bitcoinlike currencies will want. I would expect a self-perpetuating tendency toward only one CPU-based currency.

Multiple anonymous currencies already do co-exist. Operationally, there is nothing special about Bitcoin; it is just one more currency that can be used in the same way as Pexunix, LR, etc.. The only difference is that Bitcoin is distributed and not administered by a central authority, but that detail may not necessarily concern the average user.

If alternative distributed anonymous currencies spring up, there is no reason that they can't be exchanged for Bitcoin, just like traditional non-distributed currencies.  If the alternative currency has less CPU hours of proof-of-work than Bitcoin, then the exchange rate will reflect this.

I question whether multiple currencies could co-exist. Nobody wants to receive payment in a currency that has less CPU hours of proof-of-work. If the cryptographic math behind bitcoin makes sense, then people will want to be paid on the proof-of-work that represents the most widely-trusted transaction history, which will usually equate to the proof-of-work with the most blocks / CPU time.

Regarding multiple clients, this is inevitable. With the math behind Bitcoin being open, anyone can write a client. People can and will use the various available clients as long as they can trust the code and the client is following the rules to the satisfaction of the other clients that are building the longest proof-of-work chain at that time. Anyone holding bitcoins will want to support the bitcoin work with their CPU so their wealth stays legitimate. Others will only want to donate their CPU to a network that will acknowledge their work with payments in a legitimate currency.

Friends,
let me clarify my initial post.

I am *not* talking about parallel currencies, a suggestive topic, though, with notable derivatives, but not clearly related with initial post [Personally, I think if any P2P social-free-currency becomes clearly successful, the World's owners will react minting their own digital currencies; likely hard-linked with national physical currencies and promoted by their propaganda media].

I am *not* talking about another clients or a standarized API too. Although seemingly it is a quite sense proposal, may be the computational-logical machinery cannot be easily encapsulated within a library. Estimating such a proposal is beyond my present knowledge of the Bitcoin's application.

I am talking about another architectural implementations. Let me to put forward using two questions:

a) Fast generation of new blocks is key to time-stamp pending transactions and each new block is a heavy computational-statistical issue, Therefore, why not to distribute such a computational effort among idle CPUs?

b) Broadcasting of the block chain is other key aspect. Therefore, why use a single network/mechanism to communicate among peers?

From my modest point of view, implementations based on stand-alone executables cannot address above questions or similar ones.

However, I have not got a clear idea if the Bitcoin's community will accept several Bitcoin architectural implementations working all together.

I think bittorrent would be a really good model to follow.

But it's not the only path to success; Perl is a good example of a successful technology with One True implementation and no specification beyond the One True implementation.

Then again, development of Perl 6 seems to be going really slowly.

And I think breaking up the functionality is a really good idea.  For example, if the algorithm for signing transactions and the format for public and private keys were standardized it would be possible to create a Bitcoin iPhone app that stored the private keys (wallet) on the phone and submitted signed transactions to a proxy that was connected to the p2p network.

I see the functionality broken out into these pieces:

1. p2p nodes that are constantly connected and relay blocks and transactions
2. transaction monitoring ("tell me when there are new transactions that match some set of criteria")
3. new block monitoring ("tell me when there are new blocks that match some set of criteria")
4. transaction validation (answers question "is this transaction valid, and how many validations does it have?")
5. block validation ("is this block valid, and how many validations does it have?")
6. bitcoin mining: race to generate a new block and earn ฿
7. wallet storage (generate new addresses, and store their public/private keys and any transactions that correspond to them)
8. generate new transactions (sign ฿ with private key(s) and submit to p2p network)

And you get 12 coins, to round your sum to 64


I didn't mean necessarily creating other clients. Ruano's concern about the monolithic structure of the software is justified, though. It would be worthwhile to separate the functional code in some form of API library because it is cleaner design, if for nothing else. As for useful applications of such a library, Ruano has already mentioned some. Precisely because it is OSS, people will improve and build upon it. Better provide them with a way to do it properly.