Breaks over.
This little IC transceiver seems ideal for the purpose...
http://www.linxtechnologies.com/resources/data-guides/trm-xxx-lt.pdfThe chip doesn't impose any protocol of it's own on the dataset, so a simple form of 'gossip' mesh seems ideal for the dissimination of signed bitcoin transactions. Such as transmitting a transaction in the raw with a lead-in signal (a "hello, listen up I've got a transaction here" header, really) with a hop-number in the header that would be retransmitted by other devices after deducting 1 from the hop limit. Perhaps the hop limit would always be the same (say 7 max) but if a device hears the same transaction with a lower hop numer, it takes the lower hop number when it is it's own turn. Devices would only retransmit the transaction with a semi-random delay (this is how packet radio avoids collisions) and cancels it's own broadcast if it hears the same transaction again within it's wait time. The initial device transmits the transaction three times; once immediately (or as soon as the channel is clear), once about 5 minutes later (5 minutes plus a random anti-collision delay following the last transmission by others, again packet radio method) and again after about an hour. No listening devices respond with an ACK, but store this transaction for later transmission. The listening devices then wait about 7 minutes (6 minutes + a random wait of 0-100 seconds) but cancels the broadcast if it sees another transmission of the same transaction during that time frame. (i.e. it could still be near the original device, could be near another secondary device, either way there is no need to retransmit at this time) The secondary device then will attempt to retransmit again at about an hour (60 minutes + random delay of 0-100 seconds) but also cancels the transmission if it hears another first. All devices then go quiet about that particular transaction until in range of a wifi hotspot (if equipt) and dumps it's transaction pool onto the Internet. Since a mangled transaction would simply fail to pass the checks of a full client & a gossip protocol is very resilient otherwise, we don't need any additional error corrections or ACK packets.
This same device would work just as well as a p2p texting device, something like Jabber over the air, if hashing of the data & a directional bias for the gossip were used. For example, assuming that devices had a gps chip, and broadcast headers always included a MAC address for the originating device and the presently broadcasting device, and a (shortened) last known gps location for the presently transmitting device; all devices in the area could establish a short lived 'directional' routing table. A sending device could choose up to three of the devices that it calculates to be in the best general direction & best distance for it's destination (i.e. the 60 degree sector of the last known position of the intend recipient node) and name them via their mac addresses in the header. Since those same three devices know where they are & where the originating device is (generally, with a gps code intentionally reduced for accuracy) they can jude for themselves the direction intended, and (nearly) immediately rebroadcast the packet with three more mac addresses and one less on the hop variable. This continues in that direction until the hop count drops to zero. If the intended device recieves it, it sends back an ACK in the opposite direction. The package can be expected to proceed in teh general direction (assumeing that there is sufficient node density) and generally fan out as the hops progress, but no interferance in the opposite direction of the intended direction occurs, so the max hop number could be higher, say 15. With a standard range of about a klick, a hop limit of 15 has a max possible range of 15 kilometers in an urban area with optimum density, but due to line-of-sight losses and interference, teh practical limit would be closer to 10 klicks. Still not bad for infrastructure-less digital communications that doesn't cost anything.
The radio has decent range at a decent throughput, about a klick at 10kbps. Add an ecapselating mesh packet header protocol, and we're good to go there. I'm not sure how to handle in-person
initiations of transactions, however. In other words, I don't know how to get a POS device to request a payment amount from a device over the air.
EDIT: If a biased routing sceam, such as above, were used; a 'heartbeat' for devices that have not transmitted within a ten minute time frame would be required, so thta nearby devices could know that there still is a device in that direction. This would just be a very short burst, contianing only the devices's mac, the shortened gps code and (maybe) a basic vector. (I.E, moving 5 miles per hour NNW). If the device has another packet to broadcast, or is moving faster than 25 miles per hour, a heartbeat packet would be pointless. This same kind of biased gossip mesh could work well if the devices stored knowledge of fixed base nodes with Internet access and directed their transactions in that general direction. The obvious disadvantage would be that there would be no way to hide your location information.
