<blockquote>
<p>Is the precise date and time of when a payment was sent attached to a transcaction and can it be retrieved?</p>
</blockquote>
<p>No</p>
<p>And it is useless information anyway. The transaction fee chosen by the sender can influence whether the transaction gets included in a block in 10 minutes, 10 hours or 10 days. If all you care about is that the sender broadcast their transaction proposal within 10 minutes of clicking a checkout button on a web-page they can just set a very low fee and not care how long it takes for the transaction proposal to be mined and included in a block.</p>
<p>But there's no way of measuring when the sender sent out their transaction proposal.</p>
<p>Miners timestamps in blocks are also pretty useless for your purpose. There's no guarantee that the timestamps are more accurate than an hour or two. There no guarantee that a block has a later timestamp than the prior block.</p>

CC BY-SA 4.0
2020-07-25T11:35:07.943Z
ok. In that case,  what would you propose for avoiding situations when a customer tries to gain the system using bitcoin price fluctuations? Namely, he sends me N bitcoins claiming that "I sent it yesterday and yesterday bitcoin costed that much, it's you who received it today", altough in reality a customer sent me bitcoin today
 Leloucha
CC BY-SA 4.0
2020-07-25T12:14:44.040Z
@Lelouch: If short-term currency exchange rate fluctuations are a concern, you should probably only accept currencies you are comfortable with. Either that or apply some hedging strategy separate from the transactional side. I see no way to transfer risk to the customer apart from getting them to perform the exchange into your target currency prior to purchase. If you are accepting BTC you need to agree with the purchaser (or just set) a BTC price that takes into account the cost to you of that exchange-rate risk, don't just use some third-party rate unchanged.
RedGrittyBrick
CC BY-SA 4.0
2020-07-25T10:55:18.450Z
2020-07-25T11:01:36.723Z
2020-07-25T11:01:36.723Z
RedGrittyBrick
<p>While Murch answers the technical side of it already, what you're trying to do is simply not possible. There is no provision in Bitcoin to know the exact time a transaction was broadcast (short of running several nodes that connect to enough of the network to attempt to deduce the first broadcast time).</p>
<p>If you're trying to protect yourself against price fluctuations, your best bet would be to have a system that requires a certain number of confirmations within a time window of your choosing (say, 30-60 minutes). If you have not received BTC in that time period, you can cancel the order. If you receive it after the window has closed, you simply refund the BTC back to the customer and ask them to place a new order (or let them use that BTC amount as a credit against their new order).</p>
<p>This ensures that you only have to sell BTC for fiat within a certain window of time, and if the BTC transaction occurs too far after the order is placed, you return the BTC, without touching fiat at all.</p>

CC BY-SA 4.0
2020-07-25T12:01:12.670Z
and if customer uses a low fee, even the first confirmation may take a long time to arrive
 Leloucha
CC BY-SA 4.0
2020-07-26T03:05:00.087Z
Precisely, which is why you wait for *at least* one confirmation, possibly more, depending on the value of the transaction
Raghav Sood
CC BY-SA 4.0
2020-07-26T03:18:41.747Z
Not precisely. Even one confirmation may arrive in a day, whereas a time window within which a customer has to pay is 30-60 minutes. He might pay in time, but the first confirmation, as I'll see it, will arrive in 24 hours.
 Leloucha
CC BY-SA 4.0
2020-07-26T03:52:00.773Z
Which is why you *wait until the first confirmation*. Most payment gateways require that the transaction be confirmed within a certain window, not just broadcasted, precisely to motivate users to put a high enough fee to confirm quickly
Raghav Sood
CC BY-SA 4.0
2020-07-26T04:47:12.430Z
**Even the first confirmation may arrive in a day** at the ealiest
 Leloucha
CC BY-SA 4.0
2020-07-25T08:43:05.717Z
2020-07-25T08:43:05.717Z
Raghav Sood
<p>The first-seen time is not usually tracked by Bitcoin wallets. You could log when a transaction was first seen by your wallet, but that would not necessarily be a reliable approach.</p>
<p>I would suggest something else though: generate a new unique address every time someone gets to the checkout of your sales portal. You would want to do that anyway since that would be how you can identify which invoices got paid. When you generate the invoice for the customer, store a timestamp and the exchange rate used in your invoice. Add a small markup to hedge against the currency risk.</p>
<p>Corollary, you will generally not be able to rely on people to pay within a certain amount of time. Statistically speaking there is at least one block per day that takes longer than one hour to get mined, so you will not be able to rely on getting the first confirmation within 15-30-60 minutes. Returning Bitcoin payments is non-trivial, so having an extremely short time frame in which you accept payments will likely turn into a frequent source of support issues.</p>

CC BY-SA 4.0
2020-07-25T07:00:25.380Z
`You would want to do that anyway since that would be how you can identify which invoices got paid. When you generate the invoice for the customer, store a timestamp and the exchange rate used in your invoice.` --> how would that help solve my problem of "precise timestamp when payment was sent" ?
 Leloucha
CC BY-SA 4.0
2020-07-25T07:02:45.033Z
`Statistically speaking there is at least one block per day that takes longer than one hour to get mined, so you will not be able to rely on getting the first confirmation within 15-30-60 minutes. ` --> how is that relevant? even if that block took a whole day to get minned, what matter is, **date-time** when a transcaction of a customer **was sent from his wallet**
 Leloucha
CC BY-SA 4.0
2020-07-25T19:49:15.970Z
@Leloucha: You would have an exact time when the invoice was generated and use that for determining the price. You'd get an estimated time when the transaction got sent by logging when your full node sees the transaction. If the payment arrives more than <timewindow> after the invoice was generated, the trade is void and the customer can either use their balance towards a new invoice or have their funds returned (possibly minus the transaction fee).
Murch
CC BY-SA 4.0
2020-07-26T04:49:09.600Z
I've already determined the price in BTC at the checkout step. That's before a customer even sees a BTC address to send bitcoins to
 Leloucha
CC BY-SA 4.0
2020-07-26T04:49:58.703Z
I don't run a full node, not yet
 Leloucha
CC BY-SA 4.0
2020-07-25T05:47:46.970Z
2020-07-26T16:55:30.290Z
2020-07-26T16:55:30.290Z
Murch
<p>I'm a developer. I'm not really knowledgeable in bitcoin development, yet.</p>
<p>Say, I'm using Electrum wallet. I share an address with someone. The thing is that I need this someone to pay a certain amount of BTC within a certain time-window, 15-30-60 minutes. It's because I have products that are priced in fiat money.</p>
<p>That person will send me BTC. I may open my wallet not right away but in 12-30 hours, to check incoming payments. Or, even if I open it sooner, there may also be delays in BTC network and I won't see a payment, right?</p>
<p><strong>Goal</strong>: to prevent a customer from taking a potential advantage of fluctuation of BTC/FIAT prices.</p>
<p>I don't consider handling my payments via 3rd-party crypto-coin payment providers or their APIs.</p>
<p>Is the <strong>precise date and time</strong> of <strong>when</strong> a payment was <strong>sent</strong> attached to a transcaction and can it be retrieved? How, where?</p>
<p>Can it been seen in Electrum?</p>

<transactions><electrum><development><timestamp><receiving>
Is there a way to see the precise time of when a transaction was sent out?
 Leloucha
# Is there a way to see the precise time of when a transaction was sent out?

(Asked by: username_0 on 2020-07-25)

I'm a developer. I'm not really knowledgeable in bitcoin development, yet.

Say, I'm using Electrum wallet. I share an address with someone. The thing is that I need this someone to pay a certain amount of BTC within a certain time-window, 15-30-60 minutes. It's because I have products that are priced in fiat money.

That person will send me BTC. I may open my wallet not right away but in 12-30 hours, to check incoming payments. Or, even if I open it sooner, there may also be delays in BTC network and I won't see a payment, right?

**Goal**: to prevent a customer from taking a potential advantage of fluctuation of BTC/FIAT prices.

I don't consider handling my payments via 3rd-party crypto-coin payment providers or their APIs.

Is the **precise date and time** of **when** a payment was **sent** attached to a transcaction and can it be retrieved? How, where?

Can it been seen in Electrum?

**Tags:** transactions, electrum, development, timestamp, receiving


---

## 3 answers

### Answer by username_1 on 2020-07-25. Score: 2 | Accepted answer

> Is the precise date and time of when a payment was sent attached to a transcaction and can it be retrieved?

No

And it is useless information anyway. The transaction fee chosen by the sender can influence whether the transaction gets included in a block in 10 minutes, 10 hours or 10 days. If all you care about is that the sender broadcast their transaction proposal within 10 minutes of clicking a checkout button on a web-page they can just set a very low fee and not care how long it takes for the transaction proposal to be mined and included in a block.

But there's no way of measuring when the sender sent out their transaction proposal.

Miners timestamps in blocks are also pretty useless for your purpose. There's no guarantee that the timestamps are more accurate than an hour or two. There no guarantee that a block has a later timestamp than the prior block.

> **Comments:**
> **username_0**: ok. In that case,  what would you propose for avoiding situations when a customer tries to gain the system using bitcoin price fluctuations? Namely, he sends me N bitcoins claiming that "I sent it yesterday and yesterday bitcoin costed that much, it's you who received it today", altough in reality a customer sent me bitcoin today  
> **username_1**: @Lelouch: If short-term currency exchange rate fluctuations are a concern, you should probably only accept currencies you are comfortable with. Either that or apply some hedging strategy separate from the transactional side. I see no way to transfer risk to the customer apart from getting them to perform the exchange into your target currency prior to purchase. If you are accepting BTC you need to agree with the purchaser (or just set) a BTC price that takes into account the cost to you of that exchange-rate risk, don't just use some third-party rate unchanged.  

---

### Answer by username_2 on 2020-07-25. Score: 3

While username_3 answers the technical side of it already, what you're trying to do is simply not possible. There is no provision in Bitcoin to know the exact time a transaction was broadcast (short of running several nodes that connect to enough of the network to attempt to deduce the first broadcast time).

If you're trying to protect yourself against price fluctuations, your best bet would be to have a system that requires a certain number of confirmations within a time window of your choosing (say, 30-60 minutes). If you have not received BTC in that time period, you can cancel the order. If you receive it after the window has closed, you simply refund the BTC back to the customer and ask them to place a new order (or let them use that BTC amount as a credit against their new order).

This ensures that you only have to sell BTC for fiat within a certain window of time, and if the BTC transaction occurs too far after the order is placed, you return the BTC, without touching fiat at all.

> **Comments:**
> **username_0**: and if customer uses a low fee, even the first confirmation may take a long time to arrive  
> **username_2**: Precisely, which is why you wait for *at least* one confirmation, possibly more, depending on the value of the transaction  
> **username_0**: Not precisely. Even one confirmation may arrive in a day, whereas a time window within which a customer has to pay is 30-60 minutes. He might pay in time, but the first confirmation, as I'll see it, will arrive in 24 hours.  
> **username_2**: Which is why you *wait until the first confirmation*. Most payment gateways require that the transaction be confirmed within a certain window, not just broadcasted, precisely to motivate users to put a high enough fee to confirm quickly  
> **username_0**: **Even the first confirmation may arrive in a day** at the ealiest  

---

### Answer by username_3 on 2020-07-25. Score: 1

The first-seen time is not usually tracked by Bitcoin wallets. You could log when a transaction was first seen by your wallet, but that would not necessarily be a reliable approach.

I would suggest something else though: generate a new unique address every time someone gets to the checkout of your sales portal. You would want to do that anyway since that would be how you can identify which invoices got paid. When you generate the invoice for the customer, store a timestamp and the exchange rate used in your invoice. Add a small markup to hedge against the currency risk.

Corollary, you will generally not be able to rely on people to pay within a certain amount of time. Statistically speaking there is at least one block per day that takes longer than one hour to get mined, so you will not be able to rely on getting the first confirmation within 15-30-60 minutes. Returning Bitcoin payments is non-trivial, so having an extremely short time frame in which you accept payments will likely turn into a frequent source of support issues.

> **Comments:**
> **username_0**: `You would want to do that anyway since that would be how you can identify which invoices got paid. When you generate the invoice for the customer, store a timestamp and the exchange rate used in your invoice.` --> how would that help solve my problem of "precise timestamp when payment was sent" ?  
> **username_0**: `Statistically speaking there is at least one block per day that takes longer than one hour to get mined, so you will not be able to rely on getting the first confirmation within 15-30-60 minutes. ` --> how is that relevant? even if that block took a whole day to get minned, what matter is, **date-time** when a transcaction of a customer **was sent from his wallet**  
> **username_3**: @username_0: You would have an exact time when the invoice was generated and use that for determining the price. You'd get an estimated time when the transaction got sent by logging when your full node sees the transaction. If the payment arrives more than <timewindow> after the invoice was generated, the trade is void and the customer can either use their balance towards a new invoice or have their funds returned (possibly minus the transaction fee).  
> **username_0**: I've already determined the price in BTC at the checkout step. That's before a customer even sees a BTC address to send bitcoins to  
> **username_0**: I don't run a full node, not yet  

---

