Bitcoin's implementations

[ruano]

This is my first post, my first impression on Bitcoin after prowling around during days.

I am impressed with the mathematical machinery, hardly impressed.

On the other hand, a recurring question strikes me.

Seemingly the Bitcoin's implementation was born as a stand-alone executable, a main loop driven GUI. Additionally, from 0.2.6 version, JSON-RPC events can be fed into the main loop allowing integration with a variety of environments; however the stand-alone nature remains.

I have seen some topics proposing Firefox plugins or a standardized API (likely as a C++ library). But, ... there could be one question beyond.

What about another Bitcoin's implementations? Of course, I am talking about conformant ones.

Particularly, interesting implementations could address disadvantages of the monolithic, stand-alone solution. Examples of such advantages could be distribution of the heavy computational effort, additional concurrent networks to boost broadcasting of Bitcoin's blocks, and so on.

I would like to know the position of Bitcoin's community regarding of several Bitcoin implementations working all together.

Make sense? Is it acceptable? Are any such initiatives out there?

[dwdollar]

I believe the best approach is to have completely independent currencies with completely independent chains.

Here are a few reasons...

1)  It's easier for developers concerning compatibility issues.
2)  It addresses deflationary concerns, by allowing more currencies to come online as demand increases and currency is lost.
3)  It compartmentalizes.  A weakness or exploit in one currency doesn't necessarily affect other currencies.
4)  It allows people to pick between competing currencies and choose the winners.

[dkaparis]

I believe the best approach is to have completely independent currencies with completely independent chains.

Here are a few reasons...

1)  It's easier for developers concerning compatibility issues.
2)  It addresses deflationary concerns, by allowing more currencies to come online as demand increases and currency is lost.
3)  It compartmentalizes.  A weakness or exploit in one currency doesn't necessarily affect other currencies.
4)  It allows people to pick between competing currencies and choose the winners.

Once the concept of P2P digital crypto currencies becomes mainstream, then yes, development of alternative currencies is desirable and inevitable, for the reasons you have pointed. But at this early stage I'd rather have people help the establishment of Bitcoin. The P2P currency economy is still very tiny as it is, it would do no good to fragment the minuscule market we have now.

[lachesis]

I think you mean fragment, not defragment.

Satoshi is strongly against other clients because if two clients on the network don't agree on something, there's no central judge to sort it out. It could create problems for both groups of users.

Also, Bitcoin is OSS. Why would we need another implementation?

I agree with dwdollar.

[dkaparis]

I think you mean fragment, not defragment.

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

Satoshi is strongly against other clients because if two clients on the network don't agree on something, there's no central judge to sort it out. It could create problems for both groups of users.

Also, Bitcoin is OSS. Why would we need another implementation?

I agree with dwdollar.

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.

[Gavin Andresen]

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)

[ruano]

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.

[lachesis]

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

Thank you sir.

[bitcoin1234]

I believe the best approach is to have completely independent currencies with completely independent chains.

Here are a few reasons...

1)  It's easier for developers concerning compatibility issues.
2)  It addresses deflationary concerns, by allowing more currencies to come online as demand increases and currency is lost.
3)  It compartmentalizes.  A weakness or exploit in one currency doesn't necessarily affect other currencies.
4)  It allows people to pick between competing currencies and choose the winners.

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.

[Timo Y]

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.

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.

[bitcoin1234]

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.

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.

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.

[mizerydearia]

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.

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

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

+1

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

[lfm]

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?

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.

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

Sorry, what "other" Internets are you thinking of? Seems to me that tcp/ip is ubiquitous.

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

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

[Insti]

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

+1

[FreeMoney]

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.

 

[Cdecker]

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.

[mizerydearia]

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.

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.

[Gespenster]

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.

[bootfast]

I'm thinking about writing a minimal-dependency C library implementation of Bitcoin.

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

[Cdecker]

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