So far we have 3 pro and 2 con, not really decisive. I'll add an onjoin notice to the bot pointing to this thread and should it go through I'll replace it with a notification and the URL of the archive, so that everybody is warned 

I think we all agree that setting the system time is a no go, but why can't we just use an offset internally and just circumvent the whole issue? We already have ways to synchronize (approximately) the clients, so why not make use of that?

This is probably one of the best reasons we should switch the main client to a more restrictive license, that wouldn't allow to redistribute a closed source client based on the original client.

Anyway am I the only one who's wondering if the reported performance is actually what is going on under the hood? It doesn't take a lot of effort to just multiply the real number of khash/s by a constant factor, which would urge people to use the modified client which in turn sends part of the coins to the author, without providing actually any benefits?

Has anyone verfied the odds of generating coins with the theoretical number [1]?

[1] http://www.alloscomp.com/bitcoin/calculator.php

While I agree that reverse engineering is always a possibility, protocols can be licensed under different Intellectual Property regulations, that may or may not include licenses (see patents...)

There would of course be the way to simply redact all lines that contain the usernames that chose not to participate. There would be a limit above which the logs become completely useless but if there are a few people who decide they can't be hold to what they say in a public chat it could be a simple solution.

I'd go for a small server that returns a unix timestamp, the client fetches it, computes the clock drift (difference in time) and all the protocol related times are based on that drift. The clocks would still drift a little (they'd do it anyway on the system clock) and we would not get perfect synchronization (impossible in distributed systems), but it would solve our current problems.

The code is about 5 lines and some simple math (sums) when calculating the timestamps.

I still think we are talking about two different components:

• The clients
• The protocol

The protocol is open (not well documented but it's out there), while the clients do not have to abide to any special restriction AFAIK. Even if we were to enforce a license on the clients by adding a special clause to the protocol agreement, there would be users that modify an open source client, but then they don't sell it so that they can still keep it closed source.
In one of my projects we are using the RPL, which isn't open source in that sense, it specifies that any modifications to the project have to be shared with the original community, but still that doesn't avoid a client being kept closed source from the start.
Once the network has grown enough it'll get really hard for a single entity to ever tip over the balance like ArtForz because there are more people with the resources and they will compete for the top spot, and thus balance things out.

How about a bounty for both the best performing source enhancement and for the best performing community driven rig? Something like the Netflix 1'000'000$ bounty for code improvements?

While I'm not really concerned about the privacy of such a log site, since it's an open for everyone chat, I do understand people that are questioning whether it should be done. So before collecting the logs from previous months we should clarify whether the users want the archive and if we should extend it backwards in time (collecting logs).

For me personally I'd like to start from lets say the 01st September since then we'd all have a say in the issue, and we'd just forget about the logs that were created before this agreement

So please just tell us how you feel about the archive 

The Network as it is right now appears to be a random graph with fixed node degree (8 connections each host), this indeed will never scale, and we have to find a better structure. eDonkey and others fixed it with a two-hierarchy network with supernodes and nodes, while this might solve some issues I don't think it's perfect. I'd rather go with hypercubic networks as they are truly P2P and have no single points of failures.

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.

Just thought: why not create a poll? So here it is: https://spreadsheets.google.com/viewform?formkey=dDdnZmtuWTA2bnVhTy1sU2NNZjN1RGc6MQ
They should be pretty anonymous and I'll publish the results and the raw data

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 

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.

My point exactly, the protocol needs to be standardized and well documented. In its current state the Protocol would pass no standardization process anyway, variable headers with/without checksums, variable length size fields, 30% of all fields are just placeholders, ...

Anyway I'm trying to work on a python client that has no dependencies except the default python installation 

@lachesis: I started my own bitcoin client to play with the protocol and I have to say you did a great job with your Writer and Reader classes, I adapted them slightly as to have a socket writer/reader and a string writer/reader, they are just so much easier than to use pack and unpack all over the place ^^

Ok, some of you already know that we are trying to create an alternative client in order to play around with the network a bit, and try to diversify the way people build on top of the bitcoin network. Currently we are trying to create a python client that interacts with the network, but does not itself participate in the race for the next block.

Now we noticed that the whole protocol is layed out for only one client, so for example the client version is sent in the initial handshake as an integer. Out idea would be not to use that version number as the client version but as the protocol version the client is using (right now it's 310), this way clients could agree on which version of the protocol to communicate with. Another improvement would be an additional message that would simply list all the capabilities the client can understand. This way the underlying protocol would be decided by the version integer and then clients could allow or disallow extension. There are already many ideas for extensions on this forum, a broadcast mechanism for example that would alert old clients that there is an update, ...

All in all it would allow us to make a more effective use of the network and gradually add new feature, without having to go through a whole release cycle.

What do you all think?

It would be a great help for the packagers and people upgrading if there were a changelog in the repository itself. Right now it is extremely timeconsuming to scour the commit log and then try to find out what changes relate to what patch, contributed by whom and where to get more details.

Also a tasktracker or issue management which to refer to when talking about bugs, improvements and similar would be nice.

One simple solution would be to let the Client generate a new address but tell him not to use it, then transfer the coins to that address, and then send the details (pirvate key, address, ...) to the recipient, using whatever transport you want. The recipient then imports the data into his client and can receive the coins

I'm a huge fan of the Soekris Boards, and there is a new version coming out in autumn: 1 Ghz completely fanless

Yup, the real strength would be CUDA/OpenCL enhanced code making use of the Graphics Cards.