I've recently been in another discussion which led to talking about broadcasting exchange rates through the network (which reduces the load on exchanges).

I know bitcoin has some kind of alert built in but what are the restrictions on it? Specifically, what would need to be changed to allow addressed to broadcast exchange rates and then clients to pick this data up and display it in client? What would be the scalability implications of this?

The biggest problem I can see is that if anyone is allowed to broadcast then people can flood the network. I think this is easily solvable by having nodes only retransmit messages from sources they recognise, and then allowing users to add a set of public keys to verify sources. This way the network as a whole decides which messages are valid to retransmit, simply by if enough peers add the public key as a valid broadcast source.

I threw this little market monitor together a while ago, mostly for fun and as an exercise in learning a bit more about google appengine. I guess it might come in handy to someone. This application has been monitoring prices on mtgox and bitcoin market for the last few months, at 1 hour intervals. I recently updated it to check every minute, it has all of this data stored and available to download, you can view a graph of the last 10000 data points here (ignore the weird web address, it was just an address i happened to have spare on appengine from an old project):

http://nosoperor-internal.appspot.com/market-history

If anyone wants to download the raw data, you can pull the market data in JSON format here:

http://nosoperor-internal.appspot.com/market_data

By default, this will return only the last 10000 data points, if you set the option fetchall=true then it will fetch every single data point ever collected.

So, it's got some basic functionality at the moment. It would be cool to add some more stuff, feel free to make suggestions of things which would be useful and I'll probably implement them

I've been looking at the markets for Bitcoin recently (specifically MtGox, but I suspect this applies to all markets) and I've been a little confused by the terminology. I can take guesses at what most of the terms means, but I'd like to be certain.

The MtGox ticker shows six pieces of information, what do they all mean?

high
low
vol
buy
sell
last

There has been a discussion going on elsewhere about using protocol buffers for bitcoin. To summarise the advantages:

-> Small encoding
-> Very fast
-> Implementations in loads of languages (So writing new clients become a lot simpler)
-> Forwards compatible (indeed, this is most of the point of protocol buffers)
-> Extremely simpleto use in code

So initially I would suggest storing the wallet file using protocol buffers, this isn't a breaking change and immediately makes the wallet file easier for other programs to parse. Eventually I would hope that bitcoin could use protocol buffers for networking.

Some people have been suggesting that protocol buffers might be larger than the custom written packet layout. I suspect that actually it would be *smaller* due to some of the clever encoding used in protocol buffers. To resolve this, I think a test is in order, I shall encode a wallet file/network packet using protocol buffers and compare the size the packets in the current scheme. However, I have no idea what's in a packet, what data is stored in a packet, and in what format?

[This is the wolf game!]

There has been some discussion about building a game which uses bitcoins as an in game currency. The current directions the designs are taking is a version of the good old forum game "The wolf game". I thought it would be fun to play some game, so here goes:

This is the wolf game!
The year is 2024. A group of bitcoin users has gathered together to celebrate, tonight Satoshi releases Bitcoin 10.4 which will be adopted as the official currency of 3 countries. A huge party is had, everyone has fun. However, government agents have infiltrated the celebrations and will stop at nothing, during the night Satoshi is murdered! A mob gathers in the hotel foyer, regarding one another suspiciously...

The aim of the game is simple
Some players are "wolves", every night they send votes to the GM (me) on who they want to murder this night (only humans can be murdered). Wolves all know who each other are.
During the day the mob discusses who the murderer(s) is(are), the wolves pretend to be innocent humans and try to accuse other innocents - at the end of the day the vote is tallied up and the someone is lynched.
If you are a wolf, you must try and steer the daytime voting to get innocent humans killed.
If you are a human, you must try and deduce who is a wolf (bear in mind, people killed during the night must be human - that's the only solid information you have)

Special Roles
There are 4 special roles:
The Medic can autopsy a body that has been lynched and find out if they were human or wolf.
The Guardian Angel can guard one player every night, if the wolves try and murder that person they will fail. The angel may guard themselves.
The Seer will be told the identity of one wolf at the start of the game.
The Moderator is a well respected member of the forums and thus his votes can count double on one single day of his choice.

Special roles are revealed privately to players, the GM will never confirm any player as a special role publicly.

Gameplay
The game starts during the day, players can post and vote on who to kill, votes should be in BOLD AND GREEN, if you changed your mind and make another vote, then please go back and remove the first vote (make it normal text and I'll ignore it). Obviously voting will go back and forth, I will post warnings when the day is ending. One game day will be a couple of real days to allow everyone in different time zones to post.
The game then swaps over to the night, wolves and specials should send their actions to the GM (me) by PM, at the end of the night (when I've received votes off everyone, or when I don't have the patience to wait any long) the day will start with a big post by me explaining the events of the night.

Other rules
1. Private messaging is allowed between living players
2. Private messaging from dead people is NOT allowed, please report it to me and ignore that PM.
3. Dead people should make only one post after they die, and it should not reveal *anything* relevant to the game, it is merely for role-playing an impressive death
4. No posts should be made by anyone during the night. Anyone breaking this rule risks getting struck by lightening when out on the hotel roof having a sneaky cigarette Wink
5. In the event of a tie during the wolf voting then I will choose a random one to kill
6. In the event of a tie during the human voting then NO ONE is killed during that day
7. Any player inactive for too long will be replaced or killed
8. Sharing PMs from the GM is strictly NOT ALLOWED. If someone sneds you a copy of any GM message, then please tell me - they will be punished but you might get a reward Wink
9. Any rules may change slightly as the game progresses (special powers especially may be modified to be slightly more or less powerful) - you won't be punished for rules that didn't exist when you broke them.

Prize Fund
We are playing for a 13.5 Btc prize fund

Surviving players
mizerydearia
EricJ2190
Kiba
Freemoney
Brre
awwright
rokh

Dead players
Satoshi - Assassinated by government agents night 0
Quantumplation - sleeping with the money day 1

I've seen a few topics recently (arbitrary precision bitcoins, breaking of SHA256) which would require a large change to how bitcoin works. What kind of upgrade path is in place for these sorts of things?

For a gradual change I suppose a client could be released which understand both the old and new ways, but only uses the old way, then after some time (perhaps take some measurements and estimate what perentage of the network is running the new version) release a version which uses only the new version, and all the old versions would get kicked off the network?

Are there any small changes which could be made to the client to make it more change proof, would they be worth considering implementing?

[http://www.google.co.uk]

I've been working on a project inspired by a suggestion (and the offer of bounty ) over from another thread. I thought I should stop derailing that thread and start my own project thread.

Basically, the idea of the project is an easy way for websites to integrate bitcoin payment. How it works is the user runs a website on their local machine, which is only accessible to them, then when the shop wants a user to pay some money, they simply send them to this local site, which handles sending the money and then redirects back to the shop site to finish the transaction.

So at the moment, I have a test of this running on my PC, visiting this URL:

http://127.0.0.1:8080/BitcoinSalepoint/LandingPage?continue=http://www.google.co.uk&paymentname=testaddress&address=1DoMXge6kToHZN8m4B2my43anCPbD4rJgE&amount=0.25

will simply send 0.25BC to my laptop from my PC, and then redirect me to google.

My todo list:
-> Add some stylesheets for prettiness
-> Add a confirm/deny button
-> Add a way to communicate to the shop if the transaction succeeded or failed (mostly done)
-> Look into packaging the program up into a simple executable which you can run instead of bitcoin, and it will run in the background and kill itself when the bitcoin process dies.

Suggestions (and donations) very welcome

A simple question which I can't find the answer to, and I'm not at a computer with a bitcoin client at the moment so I can't test - does the windows bitcoin client (with GUI) run the Json Rpc Api, or is that only run from the headless client?