First off, yes miners only send blocks to their eight neighbor nodes, I don't know of any attempts by pools to broadcast more aggressively their blocks, though that may happen in the future. (Since it can lower the -small- chance of another block coming out simultaneously.)

Bitcoin itself doesn't really assume or require low latency in the network. It can handle even a full network split gracefully in most circumstances. And yes, as theymos says, the future is probably a network with larger nodes serving multiple users.

I'd consider PHP my bread and butter language as well, now taking a liking to Node.js for certain applications.

See http://bitcoinjs.org/ and http://twitter.com/bitcoinjs

Accepting a transaction instantly is possible, however there is a risk of a double spend, i.e. a different transaction may make it into the block chain if your customer is trying to rip you off.

The chance should be small enough that an insurance company could come along and offer to guarantee your incoming transactions for a fee.

Such an insurance company would have several strategies available to lower their costs:

• Require a 2-second or so delay before guaranteeing a transaction
• Connect to a large number of nodes and make sure that during the aforementioned delay, no other transaction appears on the network
• Contract with and pay miners to guarantee they only have the transaction you got and will include it if they generate the next block

They could then offer an API to merchants that allows them to automate the process.

Theoretically merchants could do this themselves and carry the risk themselves, but it'll likely be much, much cheaper to have specialized companies do it.

Very good point. Added.

Those aren't actually their members. They are just listing what payment providers there are. Their members are listed on this page:

http://www.bvdw.org/der-bvdw/mitgliedschaft/mitgliedsunternehmen.html

The payment providers that are actually members of BVDW are:

• eBay (owners of Paypal)
• deal united
• Giropay
• Hi-media Deutschland
• Deutsche Telekom
• SafetyPay
• Payback GmbH

Edit: Added eBay/Paypal - Thanks Nick!!

There may be others that are not on the list of payment providers or are on there under a different name.

You're right. I suppose if you were talking about an entirely new system (i.e. not Bitcoin) you could design rules that require a transaction to be to publicly disseminated for a certain period of time before it can be included in a block.

Interesting. Voting with existing Bitcoins would essentially amount to using past hashing work (Bitcoins) for security instead of or in addition to present hashing work (mining). Reminds me of HashCash and the concept of "reusable proof-of-work" which is one way of looking at Bitcoins. That would strengthen the network against an attacker, but as Nick points out there are a lot of practical and theoretical challenges associated with it.


To add to that list:

* number or value of transaction fees as payor, payee, or both by a key

Note that this is not the same as the third list item as fees are not always proportional to the transaction amounts. In fact it is fairly cheap to rack up high transaction amounts artificially, whereas it is just as costly to rack up fees artificially as it is to incur them normally. Edit: Actually, miners can rack up fees for free, see ByteCoin's message below.

It's not accounted for. But it shouldn't affect the block chain download. (Addresses aren't used in the p2p protocol.)

Maybe "crypto" instead of cryptography. The latter makes the phrase a bit clunky.

Hey if you have too much money, just send it over - you know I have a 100% win rate so far, right?

---

Heads up to everyone wanting to try out node-bitcoin-p2p at the moment. The current HEAD of Node.js breaks module compilation: https://github.com/joyent/node/issues/1102

Please wait until fixed or use joyent/node commit 9a3dd754be6531b01c0e when installing Node.

I considered jetting over there and jetting back in time for my Bitcoin talk in Zurich at 7pm. But knowing me it just sounds like such a recipe for disaster.

Have fun! Hopefully there will be a next time some day. 

When you're trying testnet, are you doing so with booo's patch or with vanilla node-bitcoin-p2p? The current master does not contain the necessary changes to the genesis block at all. Booo's patch does contain them but that's still where I'd be looking for problems. booo's error log looks like the blocks he's downloading don't connect with the chain.

https://github.com/bitcoinjs/node-bitcoin-p2p/issues/8


Some random recommendations: ack is awesome tool for searching source code. I use  Wireshark for debugging the Bitcoin P2P connection as well as the database backend. The latest version even has a filter for MongoDB's protocol, making it a lot easier to debug MongoDB-related problems.

And of course BitcoinJ is great when you need another client to run against that is easy to change and customize.

When doing Weusecoins we considered designing a new logo for Bitcoin, but eventually decided it was best to stick with what people were already used to. I'm usually not a fan of crowdsourcing design, but when a logo/symbol emerges victorious again and again whenever the discussion comes up, maybe it's time to chill out and roll with it. 

Hehe, you seem to be on a mission to re-report all the bugs from our issue tracker:

https://github.com/bitcoinjs/node-bitcoin-p2p/issues/15

Or perhaps you're just posting here to make me aware - I've now tried to comment on all bugs. At the moment I don't have muchany time to develop, as soon as I do though this stuff will all get fixed swiftly. Unless somebody beats me to it.



Please refer to the bug tracker:

https://github.com/bitcoinjs/node-bitcoin-p2p/issues/13

Right now, we're using a hack for adding binary support to mongoose. I've created the necessary classes for a datatype "Buffer" that base64 encodes and decodes everything.

In the future we should implement proper support for Buffers to node-mongodb-native and mongoose, i.e. without conversion to base64 since MongoDB itself actually has excellent support for binary types.

See: https://github.com/bitcoinjs/node-bitcoin-p2p/issues/6


Right now I'm focused on my own development. I want to launch Webcoin, mainly to prove to myself and the world that BitcoinJS is actually a viable alternative, after that I'll be focusing more on building a community. If you want to start and moderate an IRC channel, feel free to start one and let me know. I'll gladly join whenever I'm on, but please don't expect too much, it's all a lot to handle for me atm.



Testnet is not supported yet, please use mainnet. (It shouldn't be difficulty to fix, I've just never needed testnet. It's hash rate is too unstable, ironically making it unsuitable for testing imho.)

See: https://github.com/bitcoinjs/node-bitcoin-p2p/issues/8

Link fixed!


Yep. I just made this as a flashier version that I can show after my talk as a little gimmick.

Hey everyone, in preparation for my talk at KPMG on Wednesday I've created a 3D globe showing Bitcoin nodes.

Link:

To view, you need a WebGL compatible browser. That is Firefox 4 or Chrome 9+ I think. Also your drivers etc all have to be in order. So for a lot of you this won't work. For the rest:

LAUNCH 3D GLOBE


Credits:

• Idea: Mike Hearn
• Data: dump.bitcoin.it (thanks to.. MagicalTux, I think?)
  
• Globe: Google
  
• Texture: Planet Earth Texture Map
  

Screenshot (click to enlarge):




The globe shows the Bitcoin nodes by city. The height and color of the bars denotes the number of nodes from that city.

Source code (the part that I wrote) will be posted shortly.

Enjoy.  

Roger asked us to give it a go:


Let us know what you think, if we get no feedback or positive feedback we'll have Chris record it on Monday. (He's the voice from the video as well.)

Brilliant idea.

In the far future, these pools might not be competitive though due to the costs from every miner having to verify signatures. Maybe there is a solution for that?

Still, that's a ways away and for now it sounds like a great idea.

Doesn't need to be, the block also contains the pool's Bitcoin address in the coinbase. That already makes the hashes pool-specific.