Topic: Bitcoin over Jabber (Read 2366 times)

I'm trying to think along the lines of the Dash7 networking, which doesn't use sessions like wifi, so there is no LAN per se.  Even though IP6 is supposedly possible over an ad-hoc Dash7 net, I doubt that would be the ideal solution.  Something a bit more native than just IP over Dash7, and as I already mentioned, Dash7's topology is already very Jabber friendly.  I don't doubt that a Bitcoin protocal to run natively on Dash7's stack is also possible, perhaps prefered, but I was also looking at cloaking the Bitcoin traffic into the (assumed) Jabber traffic, making it more difficult to 'sniff' out Bitcoin users in a crowd.  Mostly because I don't want to add a reason to make cellphone theft profitable, not because I'm particularly concerned about govco snooping; although that would be a positive side effect.

You don't have to log in. I just meant that you and the recipient need to be on the same TCP/IP network. Then just -connect to each other. You could also do this over the Internet, though I don't know why you wouldn't just use the Bitcoin network if you have Internet access.

My x-btc URI scheme supports encoding transactions, which would work for sending them over Jabber. Like this:
"-b60..." is a Bitcoin network "tx" message encoded in base64url. X-btc is just a specification, so you can't actually use this format for anything right now.

Jabber also presents another interesting opportunity:  anonymous exchanges via Jabber.

Someone sets up an exchange at [email protected] jabber address, and publishes an API.

Users send and receive PGP-signed Jabber messages at [email protected], instructing the software to buy and sell BTC for Pecunix / Paypal / etc.

Interesting.  But really do you actually have to logon to another computer on the LAN, or could you possibly do the transaction directly on the physical computer of the chatter who wants to receive the money?  Example: ssh logon as a guest, scp your wallet.dat over to your encrypted guest session temporary directory, the guest session runs bitcoind on port 8333 or 8332 while the host (i.e. receiver) runs on the opposite port, then when the transaction is sent, the local router would simply reroute the transaction back to the same computer that that transaction was sent from .  Or another example: use a computer running on a virtual machine hypervisor, setup a guest VM for the sender, and then send the coins from one VM to the other VM on the same physical machine, in which case the hypervisor would simply route the bitcoin transaction without actually leaving the network controller?

creighto:

You can do something like that right now without even modifying the client. Just connect to someone's Bitcoin client over a LAN and send them a transaction. Both sender and recipient will broadcast the transaction when they get back to the Internet. A double-spending attack is also easily possible without modifying Bitcoin when you do that -- the sender just has to create a wallet.dat backup beforehand and get to the Internet first.

I asked this question related to the 'Bitcoin & Dash7' thread, because Dash7 is a xml technology, and a peerdevice to peerdevice implimentation of that messaging protocal seems almost trivial, and I have reason to believe that such an extension of the protocal is already underway.


Think of it as a 'reciept' of sorts.  The buyer's client provides the seller's client a copy of the transaction record, so that the seller can be certain to re-submit the transaction if the buyer fails to do so.  I was thinking of such a transaction occurring in the absence of mobile Internet access.  Could be during an outage, while camping 40 miles beyond the last cell tower, between parties wherein one or more doesn't have a respectable data plan, or simply an in person transaction between two parties that do not wish the event to be broadcast openly at the exact time of the event.  I think that any means of using common tech (a smartphone) to conviently perform a timely Bitcoin transaction between two, in person, parties would be a huge boon for Bitcoin adoption, and doing so over the Jabber protocal would make Bitcoin transactions indistingishable from any other encrypted message.  So if Bitcoin could make use of the Jabber protocal as it is today, I can think of no reason that it couldn't be quickly adapted to use over that same protocal adapted to peerdevice messaging over Dash7.  This kind of transaction would require that the two parties have some kind of prior, in person, contact; in order to have already exchanged contact information such as Jabber ID's and Bitcoin addresses.  But that describes the vast majority of daily business, and any business that involves cash.

They aren't common at all these days so it's really no point in respecting others transacrtions. But most of the network play by the rules so this shouldn't be a problem.

Transaction fees...

Moreover, there is no reason to include ANY transactions in block at all, except the first one with 50BTC.
Hovewer, there is also no incentive in dropping received (and valid) transactions either.

Got it. So the transaction may be delayed for some blocks if those who generated them weren't aware about it. Thanks for explanation.

You don't get old transactions. You don't need them. Someone who knows about the old transaction will generate a block with it eventually.

If the entire network forgets about the transaction, the sender and receiver will rebroadcast it.

What are the cases when they don't? BTW how do recently connected nodes get all transactions that should be included in the block even that which were broadcasted before these nodes connected? Do they ask their peers or are there periodic rebroadcasts?

Not always.

When you send the transactions the recipient will see the unconfirmed transaction almost immediately. Transaction broadcasting is done using the realtime messaging but it's only for notifying the nodes about the transaction. And the block generations after it is confirmations you see in your client.

How difficult would it be to send a transaction report over Jabber/IM network?  The idea is that, I'm sending someone money, and I want them to have a "receipt" of that intention immediately, rather than having to wait for 10 minutes for the block to provide one.