<p>You can simply send the signed transaction to the other entity (e.g. via Bluetooth) who then can send it to the Bitcoin network. The transaction doesn't need to be sent to the Bitcoin network by you, it just needs to somehow get to a miner to be included in a block. Even if you print it out, send someone a letter via snail mail, they type it in, and send it to the Bitcoin network, it'll still work.</p>

CC BY-SA 3.0
2017-01-28T01:59:34.080Z
So, the transaction can be broadcast either by sender or receiver of a transaction? Is this because receiver can't spoof the transaction as the private keys are secure with the sender?
cogitoergosum
CC BY-SA 3.0
2017-01-28T02:22:16.423Z
It can be broadcast by anyone who by any means got hold of it. Some people seem to have the notion that a transaction is something that's *secretly* transmitted through the network. It's not. Everyone can read it once it's broadcast. A transaction doesn't say: "Here is my password, please send those funds I have access to with this password to those addresses and be so kind to not send them to yourself." That wouldn't work. People would steel your money. Instead – through the magic of cryptography – a transaction only allows with your funds to happen, exactly what you specified in it.
UTF-8
CC BY-SA 3.0
2017-01-28T02:36:03.213Z
I know that, the transaction is not transmitted securely. I was referring to fact that, a transaction can be created by the owner of the private keys only; it is a different matter how the ownership was gained (genuine, malevolent, etc.).
cogitoergosum
CC BY-SA 3.0
2017-01-28T02:40:21.833Z
Consider this scenario. Suppose the transaction is persisted on both the sender's and receiver's devices. Once the transaction is sent to the receiver device via Bluetooth, then it is possible that both the sender and receiver come online at different times without the other party's knowledge. I would think that, the later transaction would be rejected because that would mean double spending of UTXO. Correct?
cogitoergosum
CC BY-SA 3.0
2017-01-28T02:59:37.877Z
Yes, that's correct. Well, kind of. It would be rejected but 2 times the same transaction doesn't mean double spending.
UTF-8
CC BY-SA 3.0
2017-01-28T03:55:33.900Z
Thanks! One last thing. Could you please elaborate this, "2 times the same transaction doesn't mean double spending"?
cogitoergosum
CC BY-SA 3.0
2017-01-28T14:46:47.720Z
Every full node typically has several peers. Transactions go around the network and after validating one, a node sends the transaction to its peers it didn't receive the transaction from, except if it already sent this transaction to them in the past. This is necessary because otherwise, a single transaction would clog the entire network as it would multiply until it existed trillions of times. Therefore, if you send one a second time, it's just ignored.
UTF-8
CC BY-SA 3.0
2017-01-27T17:41:41.270Z
2017-01-27T20:40:18.147Z
2017-01-27T20:40:18.147Z
UTF-8
<p>This Android <a href="https://play.google.com/store/apps/details?id=de.schildbach.wallet&amp;hl=en" rel="nofollow noreferrer">application</a> for Bitcoin wallet, claims offline payment as a feature. It says, </p>

<blockquote>
  <p>When you're offline, you can still pay via Bluetooth.</p>
</blockquote>

<p>A payment is concluded only when the transaction is broadcast to the network and confirmations are made for the transaction in a certain block as mined. So, how does one "pay" via Bluetooth?</p>

<wallet><payment><offline-transactions>
Offline payments with Android wallet
cogitoergosum
# Offline payments with Android wallet

(Asked by: username_0 on 2017-01-27)

This Android [application](https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en) for Bitcoin wallet, claims offline payment as a feature. It says,

> When you're offline, you can still pay via Bluetooth.

A payment is concluded only when the transaction is broadcast to the network and confirmations are made for the transaction in a certain block as mined. So, how does one "pay" via Bluetooth?

**Tags:** wallet, payment, offline-transactions


---

## 1 answers

### Answer by username_1 on 2017-01-27. Score: 3 | Accepted answer

You can simply send the signed transaction to the other entity (e.g. via Bluetooth) who then can send it to the Bitcoin network. The transaction doesn't need to be sent to the Bitcoin network by you, it just needs to somehow get to a miner to be included in a block. Even if you print it out, send someone a letter via snail mail, they type it in, and send it to the Bitcoin network, it'll still work.

> **Comments:**
> **username_0**: So, the transaction can be broadcast either by sender or receiver of a transaction? Is this because receiver can't spoof the transaction as the private keys are secure with the sender?  
> **username_1**: It can be broadcast by anyone who by any means got hold of it. Some people seem to have the notion that a transaction is something that's *secretly* transmitted through the network. It's not. Everyone can read it once it's broadcast. A transaction doesn't say: "Here is my password, please send those funds I have access to with this password to those addresses and be so kind to not send them to yourself." That wouldn't work. People would steel your money. Instead – through the magic of cryptography – a transaction only allows with your funds to happen, exactly what you specified in it.  
> **username_0**: I know that, the transaction is not transmitted securely. I was referring to fact that, a transaction can be created by the owner of the private keys only; it is a different matter how the ownership was gained (genuine, malevolent, etc.).  
> **username_0**: Consider this scenario. Suppose the transaction is persisted on both the sender's and receiver's devices. Once the transaction is sent to the receiver device via Bluetooth, then it is possible that both the sender and receiver come online at different times without the other party's knowledge. I would think that, the later transaction would be rejected because that would mean double spending of UTXO. Correct?  
> **username_1**: Yes, that's correct. Well, kind of. It would be rejected but 2 times the same transaction doesn't mean double spending.  
> **username_0**: Thanks! One last thing. Could you please elaborate this, "2 times the same transaction doesn't mean double spending"?  
> **username_1**: Every full node typically has several peers. Transactions go around the network and after validating one, a node sends the transaction to its peers it didn't receive the transaction from, except if it already sent this transaction to them in the past. This is necessary because otherwise, a single transaction would clog the entire network as it would multiply until it existed trillions of times. Therefore, if you send one a second time, it's just ignored.  

---

