<p>Why not require the merchant to have a unique address and not allow reuse? They could give you an xpub so you can generate them yourself if that's easier. You don't care if the buyer reuses her address.</p>

<p>I'd be careful with depending on time frames. That sounds fragile. </p>

CC BY-SA 3.0
2015-10-03T18:37:44.213Z
2015-10-03T18:37:44.213Z
Jannes
<p>On my site I want to allow two parties to trade between each other without me posing as a middle man. That means that vendor would provide his own address to which a negotiated amount would be deposited. My site would only scrape the public bitcoin transaction list for given address to find out if the payment was done to trigger post processing on my site.</p>

<p>Since people generally reuse bitcoin addresses, checking an immediate balance will not give me a proof that transaction really came through, thus I want to parse all transactions for a given address, filter out those transactions that are older than defined time frame (assume I have timestamp of offer's creation time) and calculate the sum from the rest.</p>

<p>Is this a valid solution or am I missing something?</p>

CC BY-SA 3.0
2016-02-01T07:13:14.743Z
Transactions as such have no timestamp. Only blocks have a timestamps in their headers, which is not accurate. Maybe you should check the payment protocol (bip70).
Stefan
<payment>
Payment confirmation (3rd's party point of view)
immersiveD
# Payment confirmation (3rd's party point of view)

(Asked by: username_0 on 2015-10-03)

On my site I want to allow two parties to trade between each other without me posing as a middle man. That means that vendor would provide his own address to which a negotiated amount would be deposited. My site would only scrape the public bitcoin transaction list for given address to find out if the payment was done to trigger post processing on my site.

Since people generally reuse bitcoin addresses, checking an immediate balance will not give me a proof that transaction really came through, thus I want to parse all transactions for a given address, filter out those transactions that are older than defined time frame (assume I have timestamp of offer's creation time) and calculate the sum from the rest.

Is this a valid solution or am I missing something?

**Tags:** payment

> **Comments:**
> **username_1**: Transactions as such have no timestamp. Only blocks have a timestamps in their headers, which is not accurate. Maybe you should check the payment protocol (bip70).  

---

## 1 answers

### Answer by username_2 on 2015-10-03. Score: 2

Why not require the merchant to have a unique address and not allow reuse? They could give you an xpub so you can generate them yourself if that's easier. You don't care if the buyer reuses her address.

I'd be careful with depending on time frames. That sounds fragile.


---

