Bitcoin Forum

Bitcoin => Bitcoin Technical Support => Topic started by: khandakersajjathossen on May 24, 2020, 07:51:39 AM



Title: Bitcoin confirmation API
Post by: khandakersajjathossen on May 24, 2020, 07:51:39 AM
Hello,

Can i know some API providers who gives the opportunity to check how many confirmations a bitcoin transaction have with HASH ID. I If the request limit is or over 3 req/sec will be better!

( i tried sochain api but getting this https://imbt.ga/k7U0pKZ4ih when running curl https://sochain.com/api/v2/is_tx_confirmed/BTC/9f8c30b1070e5a62981b8b45df3e25be6caaf9b670ad8464610a047d502e2b00 on console,,,,,,

blockcypher api limit is too low,

bitaps api giving wrong TRANSACTION NOT FOUND error when giving valid hash
https://api.bitaps.com/btc/v1/blockchain/transaction/f00120799e54e093bc1aae712f907afd1ad7246d590fa5f8d3205ab428c9a5dd
https://blockchain.info/tx/f00120799e54e093bc1aae712f907afd1ad7246d590fa5f8d3205ab428c9a5dd,,,,

on coinbase i can see confirmations for outgoing transactions not incoming ones,,,,,,,)

Thank You.


Title: Re: Bitcoin confirmation API
Post by: OmegaStarScream on May 24, 2020, 08:32:21 AM
Have you tried Blockchain or BTC.com API? They don't give you the transaction confirmation count but you can calculate it using the blockcount:

Blockcount  (https://blockchain.info/q/getblockcount)- The block your transaction was included in (block height (https://blockchain.info/rawtx/f00120799e54e093bc1aae712f907afd1ad7246d590fa5f8d3205ab428c9a5dd)) + 1
631516 - 631509 + 1 = 8 confirmations


Title: Re: Bitcoin confirmation API
Post by: khandakersajjathossen on May 25, 2020, 07:21:10 AM
You might want to use paid API (such as https://blockchair.com/api (https://blockchair.com/api)) which don't have such limit.

If you have fixed list of addresses, where you want to see transaction related to those address, you could run Bitcoin Core (and enable transaction indexing/txindex).
You only need to add list of addresses to watch only addresses, then use this command to get total confirmation of a transaction.

Code:
gettransaction [your_tx_id]

Blockchair api too much expensive, From $250 / mo for only 25000 req/day, But i need min 2req/sec



Have you tried Blockchain or BTC.com API? They don't give you the transaction confirmation count but you can calculate it using the blockcount:

Blockcount  (https://blockchain.info/q/getblockcount)- The block your transaction was included in (block height (https://blockchain.info/rawtx/f00120799e54e093bc1aae712f907afd1ad7246d590fa5f8d3205ab428c9a5dd)) + 1
631516 - 631509 + 1 = 8 confirmations

on blockchain api  documentation (https://blockchain.com/api/q) i see this
Please limit your queries to a maximum of 1 every 10 seconds.,

and on btc.com api getting this while browsing the page once every second from my browser,(a file is being downloaded and in the file have this)
Don't abuse the API. Please contact webmaster@btc.com





Have you tried Blockchain or BTC.com API? They don't give you the transaction confirmation count but you can calculate it using the blockcount:

Blockcount  (https://blockchain.info/q/getblockcount)- The block your transaction was included in (block height (https://blockchain.info/rawtx/f00120799e54e093bc1aae712f907afd1ad7246d590fa5f8d3205ab428c9a5dd)) + 1
631516 - 631509 + 1 = 8 confirmations


Blockcount  (https://blockchain.info/q/getblockcount)- The block your transaction was included in (block height (https://blockchain.info/rawtx/f00120799e54e093bc1aae712f907afd1ad7246d590fa5f8d3205ab428c9a5dd)) + 1

This Helped Too Much Thanks,,,,, i can now store block_height from starting and just call one req to get current block and do the easy math......

Thank You Soooooo Much  ::) ::) ::)



Have you tried Blockchain or BTC.com API? They don't give you the transaction confirmation count but you can calculate it using the blockcount:

Blockcount  (https://blockchain.info/q/getblockcount)- The block your transaction was included in (block height (https://blockchain.info/rawtx/f00120799e54e093bc1aae712f907afd1ad7246d590fa5f8d3205ab428c9a5dd)) + 1
631516 - 631509 + 1 = 8 confirmations


Can u please tell me usually after how much time currentblock count increases? an estimate pls

[moderator's note: consecutive posts merged]


Title: Re: Bitcoin confirmation API
Post by: mocacinno on May 25, 2020, 07:55:17 AM
--snip--

Can u please tell me usually after how much time currentblock count increases? an estimate pls

On average, there's ~10 minutes between blocks. If this average time between blocks is < 10 minutes, at the next difficulty retarget, the diff will increase so the time between 2 blocks is once again ~10 minutes (or vice versa).

Do note the word "AVERAGE"...
It's perfectly possible to see a time of 20 or 30 minutes between 2 blocks... As long as the average time is 10 minutes for the current retarget period, everything will stay the same.

By the way, i notice you're new here...
Some tips:
* don't post several replies after eachother. If you want to reply to several people, do so in one post.
* the emoticon of rolling eyes is considered impolite. I use it (for example) when a scammer is using the same old excuses for his scam technique (i roll my eyes at them)


Title: Re: Bitcoin confirmation API
Post by: bob123 on May 25, 2020, 08:09:13 AM
If you need at least 2 requests per second, you might want to consider setting up your own node.
It's not that hard and doesn't need too much disk space, since you can simply enable pruning and only save the last few blocks (e.g. 50 MB of blocks).

I don't know what of software/service you are building, but it might be better to not rely on a 3rd party (keyword: availability).


Title: Re: Bitcoin confirmation API
Post by: mocacinno on May 25, 2020, 10:08:12 AM
If you need at least 2 requests per second, you might want to consider setting up your own node.
It's not that hard and doesn't need too much disk space, since you can simply enable pruning and only save the last few blocks (e.g. 50 MB of blocks).

I don't know what of software/service you are building, but it might be better to not rely on a 3rd party (keyword: availability).

The bare minimum is prune=550 (IIRC), keeping little over 550 Mb block data.
Next to this, there are other datafiles, config files, log files and binaries,... So a pruned node will still need a lot more than 50 Mb (even the minimum size on disk of the blocks of a pruned node alone are > 50 Mb)

And, as a sidenote, a pruned node will still need to download, parse and verify every single block... So pruning will only save diskspace, not initial sync time or system load. And if, for some reason, a rescan is required, the pruned node owner needs to repeat the complete initial phase of downloading, parsing and verifying every single block.

That being said: you are correct that a pruned node will benefit people with a bottleneck regarding their diskpace (like people using VPS's)


Title: Re: Bitcoin confirmation API
Post by: ABCbits on May 25, 2020, 11:01:50 AM
--snip--

Can u please tell me usually after how much time currentblock count increases? an estimate pls

On average, there's ~10 minutes between blocks. If this average time between blocks is < 10 minutes, at the next difficulty retarget, the diff will increase so the time between 2 blocks is once again ~10 minutes (or vice versa).

On reality, average block size is about 9.4 minutes since mining hashrate/difficulty is increasing most of the times.

If you need at least 2 requests per second, you might want to consider setting up your own node.
It's not that hard and doesn't need too much disk space, since you can simply enable pruning and only save the last few blocks (e.g. 50 MB of blocks).

I don't know what of software/service you are building, but it might be better to not rely on a 3rd party (keyword: availability).

The bare minimum is prune=550 (IIRC), keeping little over 550 Mb block data.
Next to this, there are other datafiles, config files, log files and binaries,... So a pruned node will still need a lot more than 50 Mb (even the minimum size on disk of the blocks of a pruned node alone are > 50 Mb)

Don't forget chainstate which store all UTXO, which is about 3.8GB in my case.


Title: Re: Bitcoin confirmation API
Post by: bob123 on May 25, 2020, 11:50:12 AM
The bare minimum is prune=550 (IIRC), keeping little over 550 Mb block data.

Thanks for the heads up. I missed a "5".



Next to this, there are other datafiles, config files, log files and binaries,... So a pruned node will still need a lot more than 50 Mb (even the minimum size on disk of the blocks of a pruned node alone are > 50 Mb)
Don't forget chainstate which store all UTXO, which is about 3.8GB in my case.

You guys are obsessed with storage space  ;D

A 500 GB HDD costs ~25$.
Whether a pruned nodes needs 2 or 20 GB is pretty much irrelevant (IMO).

If someone is doing 2 requests per second, thats more than 7k requuests per hour. I would guess that he should be able to run a full node and give up on 2-20 GB on storage space in this case.


Title: Re: Bitcoin confirmation API
Post by: mocacinno on May 25, 2020, 12:18:13 PM
--snip--
Next to this, there are other datafiles, config files, log files and binaries,... So a pruned node will still need a lot more than 50 Mb (even the minimum size on disk of the blocks of a pruned node alone are > 50 Mb)
Don't forget chainstate which store all UTXO, which is about 3.8GB in my case.

You guys are obsessed with storage space  ;D

A 500 GB HDD costs ~25$.
Whether a pruned nodes needs 2 or 20 GB is pretty much irrelevant (IMO).

If someone is doing 2 requests per second, thats more than 7k requuests per hour. I would guess that he should be able to run a full node and give up on 2-20 GB on storage space in this case.

This might seem like an obsession, but in reality, it could very well matter. For example, i've seen low end VPS providers offering LXC containers with a quota of 10 Gb or less. If you think you'll be able to run a pruned node with 50 Mb of diskspace (or 550 Mb for that matter), such a cheap, low end box will suffice. However, if you take into account all data, log, binary and 500 extra Mb for the blocks, a 10 Gb SSD quota will be cutting it very close.

You're right tough: if the op is going to make thousands of requests per hour, he should just buy a 500 Gb disk and run his own node (i would advice him to run a non-pruned full node), and he'll be much better of than if he's using a (free or paying) api.

So, in conclusion, i agree with the general conclusion of your post, i only had some side remarks that migh (or might not) be relevant (depending on the usecase)