<p>This is not currently possible nor is it secure at all whatsoever.</p>

<blockquote>
  <p>So, as the customer at the counter, what if I could prepare a transaction of the required amount, from my wallet-app on the phone, somehow approve it/sign it/authenticate it, but not send it to the bitcoin network yet.</p>
</blockquote>

<p>This is possible, but only if the customer knows what address to send the Bitcoin to. If he does not, then this won't work.</p>

<blockquote>
  <p>Instead, I send the transaction to the shop owner, via bluetooth, QR-Code, NFC whatever. The shop owner takes this transaction, validates it against the current amount on the contained address/es. The idea is that this should guarantee to the shop owner that he or she will actually be able to retrieve the amount on a later time.</p>
</blockquote>

<p>Doing that does not guarantee that the shop owner will receive any money. All that guarantees is that the shop owner has seen the transaction and can broadcast it himself. However the customer could perform a double spend attempt and have it occur successfully if the shop owner does not immediately broadcast the transaction. This is because the customer still has the information necessary to create a conflicting transaction (i.e. the private keys) and just broadcast that to the network. Simply handing over a transaction does not mean that it is suddenly impossible for that person to create a new transaction that sends the money elsewhere.</p>

<blockquote>
  <p>At the end of the day, the shop owner takes all collected transactions, blends them into an new single one (to save bytes) and now sends this transaction to the bitcoin network. This single transaction should be cheap and more efficient compared to single transactions from all day's clients.</p>
</blockquote>

<p>That is not possible. No one can modify those transactions except the people who own the private keys. They cannot be "blended" with each other unless the person doing that "blending" controls all of the private keys associated with those transactions. "blending" would require creating a new transaction that spends the same outputs and creates a different output. It is an entirely new transaction which requires the customers' private keys in order to create.</p>

CC BY-SA 3.0
2017-11-11T23:01:25.713Z
Thanks for addressing each point well. Too bad this will not work.
nulldev
CC BY-SA 3.0
2017-11-11T21:36:36.107Z
2017-11-11T21:36:36.107Z
Ava Chow
<p>I am quite new to the idea of bitcoin but I have understood one of the main problems:</p>

<p>Sending money with Bitcoin takes approximately 10 minutes, by design. For use at the counter in a shop this is very much too slow, also the amount of transactions in 10 minutes (about 2000) is not suitable for planet-wide in-shop use.</p>

<h1>My idea. Would this be feasible?</h1>

<h2>1. Create a signed, pre-approved transaction</h2>

<p>So, as the customer at the counter, what if I could prepare a transaction of the required amount, from my wallet-app on the phone, somehow approve it/sign it/authenticate it, but not send it to the bitcoin network yet.</p>

<h2>2. Hand out the transaction</h2>

<p>Instead, I send the transaction to the shop owner, via bluetooth, QR-Code, NFC whatever. The shop owner takes this transaction, validates it against the current amount on the contained address/es. The idea is that this should guarantee to the shop owner that he or she will actually be able to retrieve the amount on a later time.</p>

<h2>3. Collection of the transaction's value</h2>

<p>At the end of the day, the shop owner takes all collected transactions, blends them into an new single one (to save bytes) and now sends this transaction to the bitcoin network. This single transaction should be cheap and more efficient compared to single transactions from all day's clients.</p>

<p><strong>Is such transaction bundeling feasible? Or already in place somehow?</strong></p>

<transactions><wallet><blocksize><bundler>
Improving transaction handling in shops: Is sending "prepared/approved/signed" transactions to a shop owner possible?
nulldev
# Improving transaction handling in shops: Is sending "prepared/approved/signed" transactions to a shop owner possible?

(Asked by: username_0 on 2017-11-11)

I am quite new to the idea of bitcoin but I have understood one of the main problems:

Sending money with Bitcoin takes approximately 10 minutes, by design. For use at the counter in a shop this is very much too slow, also the amount of transactions in 10 minutes (about 2000) is not suitable for planet-wide in-shop use.

# My idea. Would this be feasible?

## 1. Create a signed, pre-approved transaction

So, as the customer at the counter, what if I could prepare a transaction of the required amount, from my wallet-app on the phone, somehow approve it/sign it/authenticate it, but not send it to the bitcoin network yet.

## 2. Hand out the transaction

Instead, I send the transaction to the shop owner, via bluetooth, QR-Code, NFC whatever. The shop owner takes this transaction, validates it against the current amount on the contained address/es. The idea is that this should guarantee to the shop owner that he or she will actually be able to retrieve the amount on a later time.

## 3. Collection of the transaction's value

At the end of the day, the shop owner takes all collected transactions, blends them into an new single one (to save bytes) and now sends this transaction to the bitcoin network. This single transaction should be cheap and more efficient compared to single transactions from all day's clients.

**Is such transaction bundeling feasible? Or already in place somehow?**

**Tags:** transactions, wallet, blocksize, bundler


---

## 1 answers

### Answer by username_1 on 2017-11-11. Score: 1 | Accepted answer

This is not currently possible nor is it secure at all whatsoever.

> So, as the customer at the counter, what if I could prepare a transaction of the required amount, from my wallet-app on the phone, somehow approve it/sign it/authenticate it, but not send it to the bitcoin network yet.

This is possible, but only if the customer knows what address to send the Bitcoin to. If he does not, then this won't work.

> Instead, I send the transaction to the shop owner, via bluetooth, QR-Code, NFC whatever. The shop owner takes this transaction, validates it against the current amount on the contained address/es. The idea is that this should guarantee to the shop owner that he or she will actually be able to retrieve the amount on a later time.

Doing that does not guarantee that the shop owner will receive any money. All that guarantees is that the shop owner has seen the transaction and can broadcast it himself. However the customer could perform a double spend attempt and have it occur successfully if the shop owner does not immediately broadcast the transaction. This is because the customer still has the information necessary to create a conflicting transaction (i.e. the private keys) and just broadcast that to the network. Simply handing over a transaction does not mean that it is suddenly impossible for that person to create a new transaction that sends the money elsewhere.

> At the end of the day, the shop owner takes all collected transactions, blends them into an new single one (to save bytes) and now sends this transaction to the bitcoin network. This single transaction should be cheap and more efficient compared to single transactions from all day's clients.

That is not possible. No one can modify those transactions except the people who own the private keys. They cannot be "blended" with each other unless the person doing that "blending" controls all of the private keys associated with those transactions. "blending" would require creating a new transaction that spends the same outputs and creates a different output. It is an entirely new transaction which requires the customers' private keys in order to create.

> **Comments:**
> **username_0**: Thanks for addressing each point well. Too bad this will not work.  

---

