Well if there's one thing I fear more than little old men, it's hundreds of skript kiddies going at it with LOIC (such unsofiticated tool isn't it?). I guess if MyBitcoin does not want to be associated with Wikileaks that's fine by me, but we do not want Bitcoin being associated with censorship and closed mindedness.

I think we should definitely add a warning not to use MyBitcoin addresses until the problem has been found.

I guess whether or not Wikileaks will adopt Bitcoin as a way to collect donations is out of our hands, it might be a huge popularity boost, but it may also bring the system to it's knees (speaking as a major critic of the current network topology, and as one that fears the wrath of little old men from Capitol hill).

I think we should make it clear that just because Bitcoin may be used by some shadowy figures we do not want to be solely attributed to them, we work for the great positive aspects that are coming out of Bitcoins. That's the beauty of an open system, it may be adopted by whoever wants to and no one will be disallowed from using it.

I'm currently working on a Java implementation of the Protocol, which in the end should end up in an Android client. I'm however not planning on releasing the Android app as open-source since I quite like the Ad supported software, but I'd be willing to open source the Protocol implementation with all it's hooks to add it to an application. Benefits would be a clear interface on which other people could build their clients, a peer reviewed Protocol core, for better quality.

I guess with that I'm not eligible to claim the Bounty?  

Just a minor correction, the name Bitcoin (or bitcoin) is used threefold and should be clearly stated:

• There's Bitcoin the Protocol: the underlying communication agreements and mechanisms that are platform and software independent, well sort of, as soon as we get alternative clients.
• There's Bitcoin the Software implementation, what I like to call the main stream client, written by Satoshi and maintained by the community on this Forum
• There's bitcoins the actual currency unit managed by the clients in the network.

So before starting the wikipedia article I think we should be clear about what we are writing for. I'd say the network as such is more important than any single implementation, and we should write about Bitcoin the Software as a section in there, and not make it the main character in our narration.

Here we are with the Language war once again. Please just stop!

As for the topic, yes please get an alternative implementation started, the more the merrier
Maybe some good code actually makes it out there, helping future generations of clients to build on top of your code.

+1 on the D implementation (I'm starting a Java one in the holidays)

That was on purpose :-)

Yes off course the reference ID would have a fixed size. Therefore comment might be the wrong choice for a name, I chose the title mainly to catch the eye of all interested people. Hashes would be one way to go, but as stated above I think UUIDs is the way to go, because Hash always implies something else being hashed, question is "of what?" whereas a UUID is easy to generate, there is no attempt to associate it with anything else.

Sad but true, it's gotten incredibly hard to generate coins, which can be frustrating to new users. I think the Pooled mining effort is a really good idea :-)

Actually no, I believe the problem is more likely that the library is linked against a different version of the Sun JVM. The headless problem can be easily solved using

-Djava.awt.headless=true

Since GeForce are buggy I will wait for them to work before having another go

It should be possible, but since we're linking statically I'd rather have it as an intree version as to not give people the impression that we provide a fully functional wxWidgets build.

I haven't had a shot for some time, I might try again these holidays

Well a reference is part of the transaction, so it should be in the main chain. There is no "reference chain" to add references and comments to the transactions in the main chain is there? I agree that the main chain should only be used for the main Bitcoin purpose which is tracking and exchanging Bitcoins, but IMHO the comment/reference is just as important as the amount being spent. Using an address per transaction is actually more of a hack than adding a comment would be.

So I guess you'd vote against it on behalf that it opens the discussion for a lot of other "nice to have" data in the transactions?

Ok, right now there's a huge discussion going on in http://bitcointalk.org/index.php?topic=2162.0 and I would support the changes to accepting only standard transaction would it not disallow exactly what I've been looking for: the ability to reuse a BC Address for multiple transaction and being able to distinguish their purpose.

Admittedly it's a hack, but a rather clever one, it was possible to insert a comment to a transaction followed by an OP_DROP which would remove it when checking the TX on the clients.

Why would one do this? Right from the terminology it's clearer, I wouldn't create a new bank account just to receive a single payment from someone, what I'd do is give him a payment slip, with a reference ID, and I'd later check if I have received a transaction with that ID.
And for the more practical minded people, it's safer! Why? Because if you generate a new address for each transaction, and you then loose the wallet, but have an old backup, in which the new keypairs aren't, you will be able to recover the Coins that you have received for keypairs in your wallet but the new ones will be lost forever.

You see it's rather more logical to separate transactions and accounts (as the new name suggests for addresses).

I therefore put it to a vote to include an official means to add a reference ID into transaction should one be supplied. To keep it simple and to keep the block chain small we could agree on allowing UUIDs in their 16 byte representation as IDs.

Any comments?

Basically this is duplicating the work we are doing on the bitcoin URI scheme. Since we can encode the URIs can easily be represented using QR codes I think we should stick with the bitcoin:-URI Scheme 

Just my 0.02 BTC

Actually the openSuse Build Service is more meant for packages that have to be reliably built for a multitude of systems and updated consistently across all of the distros, but adding a small cron job can pull SVN and push the changes to the Build Service, kicking off a recompile. I wouldn't abuse it though.

I think we should sooner or later add a continuous integration tool, to check code submissions against the (until now inexisting) unit tests. That would also be able to create nightly builds ^^

I have got access for a limited time to a small cluster running some Geforce cards, and I'm wondering if I can get your miner to work on them at night. Problem is they are debian machines and they are headless. The headless is not so much a problem since I can run Java in headless mode, what is a problem is this:


Any idea as to why?

If you're interested in getting a few bitcoins right now there's the faucet https://freebitcoins.appspot.com/, it isn't much but you can use the bitcoins to start playing with them.

Also if you prefer having a few bitcoins distributed more or less evenly over shorter periods you might want to try joining a generation pool, where all users contribute to one client which then divides the 50 coins according to who contributed what. http://www.bluishcoder.co.nz/bitcoin-pool/

HTH

I guess we have the first official release that is disputed by the majority of computation power, Bitcoin's coming off age :-)

I do however like that the changes are communicated in an open and unbiased way. One thing that would be nice is to have links to the particular Threads, Checkins, whatever to be able to track/understand changes more easily.

That's why we need moderators. The discussion about a unified URI schema for bitcoin now is spread over 7+ threads and it's getting really hard to follow the overall discussion.

Please continue discussing the bitcoin URI scheme here: http://bitcointalk.org/index.php?topic=55

We are currently having a discussion on how to make the BitCoin protocol extensible here http://bitcointalk.org/index.php?topic=894.msg27723#msg27723 .

I personally don't have anything against extensions to the protocol, and services built on top of it, but it has to be clear that they are extensions that may not be implemented by all nodes in the network. The goal I think should be to keep the core protocol small and easy to implement, and then give people the ability to add their functionality on top.

However I think distributed storage would be a stretch, and it would certainly slow down the network as a whole.

One idea I can actually see happening is a decentralized DNS replacement as discussed here http://bitcointalk.org/index.php?topic=1790

Well making the network extensible is a way to allow evolution while keeping things backward compatible.