Bitcoin Forum

The other day I was sitting in the break room, watching a co-worker vainly try over and over to get the vending machine to accept his wrinkly old dollar.  This got me to thinking about a vending machine accepting bitcoins, which would not have that particular problem.

So what would a bitcoin vending machine be like? Let me describe my idea:

You walk up to the machine, press a button labeled something like "Pay with BitCoins" and a screen lights up with a QR code. You then scan the code with your mobile phone app, which sends bitcoins to the machine's address. Since prices are so low for vending machines, it probably doesn't even have to wait for confirmations, as soon as it sees the 0.14 BTC transaction it lets you pick your item.

Sounds easy enough, right?

The limitation to that system is this only works for somebody who has a mobil phone with a bitcoin app. (There a few in the Android Marketplace for free, has anybody used them? Please let us know if they work)

On the back end, the vending machine would have to connect to the bitcoin network (Could it have a cell signal to connect?), I am not sure if it would be easier to have each machine running the bitcoin protocol, or to have a central server running a large number of machines and sending a signal to each machine when it has been paid?

Lets hear your thoughts!

-Peter-

Would a payment propogate through the node quickly enough to make it practical for something like this?

Otherwise, with increased acceptance of bitcoins as a payment method, I could see this becoming very viable.

http://forum.bitcoin.org/index.php?topic=423.0

Some relevant discussion here.

I had one take about 30 seconds to show up, and then 5 minutes for the first verification last night.  I've seen it much faster before though.

It should work. You only have to look for double spends too and reject the transaction if any are seen. Here is another thread about it: Bitcoin snack machine (fast transaction problem) (http://forum.bitcoin.org/index.php?topic=423.20)

And better yet, is there a way to trace through the nodes from endpoint to endpoint to see how many "jumps" a transaction has to make before it reaches from one end to another?

It would be something like X = N/(8^X)... I think.  Where X = number of hops and N = number of nodes.

So say we have 50,000 people with nodes running.

X = 50,000/(8^X)
X(8^X) = 50,000
Uh...

It's been a while since I took a math class.  :P

The shortest number of paths would be approximately log( N )/log( 8 ).  So about 5.2 hops for 50,000 nodes of which each are connected to 8 non-repeating nodes.  I talk to 8, they talk to 64, they talk to 512, they talk to 4096, and they talk to 32,768, and 20% of them talk to the rest.

But with a mesh network, there would be a lot of overlap (I talk to a peer, who talks to a peer, who talks back to me, for instance).  There's probably a formula, and it's probabilistic, probably.  :)

I'd guess it's would average around 2x the above figure, so 10.4 hops. to reach everybody, on average, in a 50,000 node mesh network.


PS, the math is:
8 ^ X = N
log ( 8 ^ X ) = log ( N )
X log ( 8 ) = log ( N )
X = log ( N ) / log ( 8 )

I think Stefan timed this a few weeks ago and found tx propagation was only a few seconds to reach nearly all of the network.

It'll start to slow down a lot if we begin reaching the limits of what a single machine can do, as it'll take a while for those nodes to get kicked off the network and be replaced by distributed supernodes. But we're a long way from that day yet, if it ever arrives at all.

X=4.481

No math necessary....   http://goo.gl/L2LOK