Extending the Alert messages in the protocol

[martin]

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.

[Gavin Andresen]

Here's a scheme that would work:

1. Exchange creates a special bitcoin keypair for each exchange rate it wants to publish.
  E.g. maybe there is a   1mtgxbtcusd9873919fp876...   address for mtgox btc/usd

2. Exchange funds that address with a bunch of bitcoins.

3. Every 10 minutes the exchange performs a send-to-self transaction FROM that address TO that address with the number of bitcoins that correspond to the current exchange rate.

Voila, exchange rate is broadcast to anybody who cares to listen. You know it is the exchange, because the exchange is the only entity that can spend bitcoins from the special exchange address.

You have to trust the exchange not to broadcast a bogus price...

[martin]

That's a good idea, which doesn't require any changes to the protocol, which is always a good thing

Of course you do have to trust the exchange, but such is the nature of a centralised exchange

[martin]

Apologies for the double post.

It occurred to me this morning, would there be transaction fees for these transactions to self? In which case broadcasting the exchange rate could become rather costly!

[jackjack]

It depends on the amount
No problem for MtGox $/BTC, but for bitparking BTC/NMC it can be costly indeed

[martin]

One way to overcome that problem would be for miners to accept these transactions into blocks for free, simply because they're providing a useful service. However, then smaller exchanges will probably get very "patchy" updates sent out for pricing since only a few pools would be accepting their transactions for free, which kinda sucks

[Pieter Wuille]

There is no need to put these in the block chain.

As the exchange is inherently centralized, you lose nothing by publishing the exchange rate data through http or whatever out-of-p2p protocol, possibly mirrored by those who find it interesting enough, if you care about availability.

The data itself can still be signed by a private key held by MtGox, whose address is publically known.

[Mike Hearn]

The Bitcoin protocol already has a meet-in-the-middle broadcast channel system.  AFAIK it was never used and I have no idea if it works, but it seemed complete enough when I looked over it.

That said, the network is already pretty busy. I'm not sure blasting exchange rates over it, even with a pubsub system, is the right way to go. There's no real advantage.

If you want to build a distributed exchange, having a separate chain that contains USDcoins or EURcoins is one way to do it. The chain would do merged mining with the Bitcoin chain, but coins would be created by transactions signed by pre-agreed keys owned by members of a consortium. They would issue USDcoins and keep the dollars backing them in full reserve. You can then trade Bitcoin for USDcoin cryptographically across chains using some of the contracts/cross-chain protocols described on the wiki.

Wanted trades can be broadcast on the alternative network using flood fill. Software could potentially auto-complete trades according to pre-set policies. When you want to cash out, a consortium member destroys the coins and wires you the dollars.