1

I looked into using a thin client but even thin clients implement SPV (Simple Payment Verification). What if you just wanted a client that only listens for transactions/pending transactions, doesn't store the blockchain, and only uses memory.

1

When receiving a payment, it is critical to know whether or not the transaction that makes that payment is a legitimate Bitcoin transaction (or not).

This is determined by checking if the transaction is valid according to the network's rules- and a crucial part of this is determining whether or not the transaction's inputs are valid. In order to determine the validity of the inputs, the client must have some way of knowing the current state of the network. Generally this is accomplished in two ways:

  • Full node: this is software that will independently download and validate every transaction and block, thus verifying what the current state of the network is. As such, any transaction can (and will) be checked for validity.
  • Thin/Lite/SPV client: this is software that will download the longest chain of block headers, but not the entire block. The client can thus check the validity of transaction by requesting proof of the transaction's inclusion in a block from full nodes on the network, this is accomplished via the merkle root included in the block header. This method of transaction verification requires more trust (that miners are in fact creating valid blocks), so the thin-client must trust that this verification is being performed by other nodes on the network.

If you are not performing verification of incoming transactions in one of these ways, then you will be easily defrauded, since you will be unable to differentiate between a valid and invalid transaction, without fully trusting someone else to supply this info to you.

| improve this answer | |
  • That makes a lot of sense. Is it true that this lite client does not have access to the mempool? – foba Dec 19 '19 at 5:30
  • @foba There is no 'the mempool'. Rather, each node may choose to keep a mempool (or not), it is simply a local database of unconfirmed transactions. To receive info about transactions relevant to the wallet, a thin-client will generally communicate with a full node via BIP 37/157/158. – chytrik Dec 19 '19 at 6:17
  • @foba One issue I can see with a thin-client keeping a mempool, is that without validating all blockchain data, it is difficult to prove that an unconfirmed transaction's inputs have not already been spent (making the transaction invalid). I think doing so would require some sort of cryptographic UTXO-set commitment to be included in blocks, but the protocol does not currently include such a thing. This is probably worth posting as a new question. – chytrik Dec 19 '19 at 6:20
  • yeah good points, thank you for your help! It looks like you really can't get around running a full node if you want to get pending transactions. – foba Dec 19 '19 at 6:35
  • BIP37 (bloom filtered) clients today can receive unconfirmed transactions from the nodes they are connected to, but there is essentially no way for them to do any validation on those. A well-known block explorer that used this approach once accepted and showed on the site an unconfirmed transaction that paid someone 21M BTC. – Pieter Wuille Dec 19 '19 at 7:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.