<p>Generally speaking, the SPV wallet receives the transaction and a merkle-proof from a validating full-node when funds are sent to an address controlled by the wallet.</p>

<p>The merkle-proof guarantees that the transaction with the output spendable by the wallet is committed to the header of its local (strong) header-chain. Since the wallet controls the private keys to this output, it indexes this as a local UTXO, without any knowledge of the full UTXO set found on the validating node.</p>

<p>When spending funds to another address, the local wallet will solve for an optimal set of local UTXOs for this transaction. Prevout Points, spendable by the wallet are indexed as mentioned before. All other transaction fields you describe are independent of the UTXO, or can be inferred from the indexed previous transaction (e.g. timelocks enforced by CSV/CLTV output script operations). The destination address will tell the wallet what output to spend to, as is the case with all other wallet types (P2PKH, P2WPKH,P2SH, P2WSH etc).</p>

<p>The SPV wallet described above necessarily reveals the addresses it is interested in to receive merkle-proofs from the validating node. There are several techniques for the SPV client to improve privacy and leak less information, at a certain bandwidth cost.</p>

<ul>
<li>Server side filters (e.g. Bloom filter (to be deprecated))</li>
<li>Client side filters (e.g. Neutrino)</li>
</ul>

CC BY-SA 4.0
2019-01-16T23:07:15.783Z
Bloom filters are server side, Neutrino is client side.
Claris
CC BY-SA 4.0
2019-01-17T13:20:33.063Z
@james Thanks a lot! That was greatly answered. I got everything I needed almost. If possible can you direct me to a codebase which does the above implementation.
Deb
CC BY-SA 4.0
2019-01-16T13:37:11.230Z
2019-01-17T06:31:44.817Z
2019-01-17T06:31:44.817Z
James C.
<p>As per my understanding, an SPV client only keeps a track of the block headers in its own database. So when a user tries to send bitcoins using that particular SPV client, how is the transaction constructed?</p>

<p>A user using that client will probably enter the amount he wants to send and the destination address. And he probably will be signed in using his private key.</p>

<p>So using these 3 data i.e. amount, destination and privateKey how will the SPV construct the whole transaction object.</p>

<p>Because I know that if I have to manually write a transaction by hand, I need:</p>

<ol>
<li>Previous Transaction Hash (Funding Transaction).</li>
<li>Sequence Number of the UTXO I am trying to spend.</li>
<li>ScriptSig or the unlocking key, which is constructed using the privateKey and the hash of the entire transaction body.</li>
<li>Output Value.</li>
<li>ScriptPubKey which is constructed using the destination address.</li>
<li>SigHash Code.</li>
</ol>

<p>So I am just supplying amount, destination and private key. How will the SPV client get the remaining values such as Prevout hash, sequence Number, how many UTXOs to be unlocked and how many new UTXOs should be formed?</p>

<p>It will be very helpful, if someone mentions a codebase where the implementation is given.</p>

<bitcoin-core><utxo><spv><thin-clients><utxo-set>
How does an SPV client forms a transaction which is then Broadcasted?
Deb
# How does an SPV client forms a transaction which is then Broadcasted?

(Asked by: username_0 on 2019-01-16)

As per my understanding, an SPV client only keeps a track of the block headers in its own database. So when a user tries to send bitcoins using that particular SPV client, how is the transaction constructed?

A user using that client will probably enter the amount he wants to send and the destination address. And he probably will be signed in using his private key.

So using these 3 data i.e. amount, destination and privateKey how will the SPV construct the whole transaction object.

Because I know that if I have to manually write a transaction by hand, I need:

1. Previous Transaction Hash (Funding Transaction).
2. Sequence Number of the UTXO I am trying to spend.
3. ScriptSig or the unlocking key, which is constructed using the privateKey and the hash of the entire transaction body.
4. Output Value.
5. ScriptPubKey which is constructed using the destination address.
6. SigHash Code.

So I am just supplying amount, destination and private key. How will the SPV client get the remaining values such as Prevout hash, sequence Number, how many UTXOs to be unlocked and how many new UTXOs should be formed?

It will be very helpful, if someone mentions a codebase where the implementation is given.

**Tags:** bitcoin-core, utxo, spv, thin-clients, utxo-set


---

## 1 answers

### Answer by username_1 on 2019-01-16. Score: 0 | Accepted answer

Generally speaking, the SPV wallet receives the transaction and a merkle-proof from a validating full-node when funds are sent to an address controlled by the wallet.

The merkle-proof guarantees that the transaction with the output spendable by the wallet is committed to the header of its local (strong) header-chain. Since the wallet controls the private keys to this output, it indexes this as a local UTXO, without any knowledge of the full UTXO set found on the validating node.

When spending funds to another address, the local wallet will solve for an optimal set of local UTXOs for this transaction. Prevout Points, spendable by the wallet are indexed as mentioned before. All other transaction fields you describe are independent of the UTXO, or can be inferred from the indexed previous transaction (e.g. timelocks enforced by CSV/CLTV output script operations). The destination address will tell the wallet what output to spend to, as is the case with all other wallet types (P2PKH, P2WPKH,P2SH, P2WSH etc).

The SPV wallet described above necessarily reveals the addresses it is interested in to receive merkle-proofs from the validating node. There are several techniques for the SPV client to improve privacy and leak less information, at a certain bandwidth cost.

* Server side filters (e.g. Bloom filter (to be deprecated))
* Client side filters (e.g. Neutrino)

> **Comments:**
> **username_2**: Bloom filters are server side, Neutrino is client side.  
> **username_0**: @username_1 Thanks a lot! That was greatly answered. I got everything I needed almost. If possible can you direct me to a codebase which does the above implementation.  

---

