Dash7(Re: The Sound of a Bitcoin)

[jim618]

@MoonShadow - your idea to combine Dash7 radios + bitcoin to incentivise it into a mesh is brilliant.

Not only does it make banks irrelevant, it also sidesteps the stranglehold of the telcos.   It is *doubly* disruptive !

[EhVedadoOAnonimato]

Imagine that even a small percentage of smartphones had dash7 radios in an urban area such as NYC, and you wanted to send an encrypted text to your friend.  You know your friend's dash7 id (or rather your phone does) and you use bitcoin to pay very small amounts to the smartphones of those who "hop" the text to it's destination (or forwards it across the Internet on your behalf, if that is more efficient)

I've had a similar idea before, when I was thinking on possible ways to reward independent, anonymous routers. I was thinking of Tor relays first, but then I realized the same protocol could be used to pay for MANET independent routers like the ones you describe.

Such a thing would be wonderful, for the reasons jim618 describes above: you tackle both the banking industry and the telecoms, not to mention all governmental Internet censorship.

But it is not that easy to come by with such a protocol. The main problem I see is that the service of hoping a little amount of data has to have near zero costs. One would expect to pay something like what BitcoinTorrentZ charges for his downloads, that is, bitcents per gigabyte. But how do you do that in a no-trust scenario? Your routers would want the money right away, to route even little messages. But you can't pay with bitcoin like that, you would have a huge amount of microtransactions. Transaction fees would be much higher than the actual amount per packet you want to pay to each router, it's unfeasible. And also there's the fact that bitcoin transactions are a big chunk of data to be included in every data package you want to send to a network.

Unless scripts can somehow help with microtransactions. I wonder, is it possible to use scripts to create a transaction of, say, 1BTC, but which isn't yet redeemable, and then, together with each data packet, you send a little key which allows the receiver of that 1BTC to redeem a small fraction of it, like 0,1mBTC for example? If you ever route 10.000 packets through that router, it would be able to redeem the entire transaction, otherwise he can only redeem what you've authorized and the rest must be sent back to you. Maybe instead of a "little key" you send a new signature of the total amount the receiver can spend, I don't know. It's important that whatever you're sending isn't very big, because it will go together with every data package.
I'm totally ignorant on how powerful can transaction scripting be.

PS: Although answering to messages on the topic, I realize I'm getting off-topic here. Should we open a new one?

[EhVedadoOAnonimato]

PS: Although answering to messages on the topic, I realize I'm getting off-topic here. Should we open a new one?

Mike Hearn just opened a topic on this "rewarding independent routers" problem: https://bitcointalk.org/index.php?topic=53551.0

[MoonShadow]

Scripted transactions would be able to pay for intermediaries, but micropayments would still likely require a parrallel system.  I don't have the details worked out, but both Dash7 and the Jabber protocol are inherently location aware.  A modified jabber protocol that permits forwarding routers to add an address to the end of the text would allow the receiver to save up such addresses and then create a send-to-many transaction to micropay hundreds of routers.  Routers would either forward on the faith of payment, or simply not participate.  Alternatively, an echo text from the receiver back to the sender could tally the addresses for the sender to make the payment, which would also function as a confirmation of receipt of message, but would double the traffic, costs and number of addresses.  I'm open for suggestions, but even a modified Jabber client that can use the Dash7 network or the Internet at will would be a huge boon even if it's all voluntary and unpaid.  You can set your Dash7 radio to forward messages, or not, and the receiver can choose to tip, or not; at a later time.  Of course there will be many free riders, but there will also be many people who don't mind forwarding Dash7 frames so long as it doesn't drain the battery on their own phone, which it shouldn't.  Dash7 is so energy efficient that the hardware that allows your cell phone to turn off and on it's wifi radio via software would require more power.  But then, it's also slow by comparison.  Texting and bitcoin transactions to the local space (not forwarded, necessarily) would be okay, but downloading whole blocks would become oppressive in a successful bitcoin future.  More likely, the Dash7 radio would be always on, and the Bitcoin client could turn on and off the wifi radio for ad-hoc networking when it knows that a source of newer blocks came into wifi range.  If wifi access points started having Dash7 radios as well, your cell client would know it's relative position, any access issues, and it's relative vector (and thus an estimate of how long it would be in range) long before it was actually in range.  The same for other cell phones.  You could have a smartphone like device without a service, go to a ball game, and entirely bootstrap the device from zero without thinking about the device at all simply by letting the device use both Dash7 and wifi at it's own will to gather up the blocks it needs.  Transactions that travel over Dash7 would likewise be unstoppable, even though they could be delayed.  You could use such a serviceless device to board the commuter train, but on your way you walk past two blocks of other people,  unknown to you, your device passively gathers up a half dozen transactions from within listening range before you hit the train terminal.  The train has to have the infrastructure required to support bitcoin devices, so it has at least a wifi router that permits open access to bitcoin's port number.  When you connect to that in order to pay your fare, the device forwards the rest of the transactions to the network at large.