Bitcoin confirmation API | Bitcointalksearch.org

ABCbits

legendary

Activity: 2870

Merit: 7490

Crypto Swap Exchange

Quote from: bob123 on May 25, 2020, 06:50:12 AM

Quote from: mocacinno on May 25, 2020, 05:08:12 AM

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)

Quote from: ABCbits on May 25, 2020, 06:01:50 AM

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

You guys are obsessed with storage space Grin

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.

I only mentioned chainstate size for clarification sake. If i were obsessed with storage space, i wouldn't run full node or complain to Bitcoin Core dev for not using best compression algorithm Tongue

But i agree with you, with pruned node, there's serious limitation of self-hosted API features that you could use.

Quote from: mocacinno on May 25, 2020, 07:18:13 AM

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.

IMO even though the low end VPS use SSD, the RAM capacity usually is low and it has to be shared VPS which hinder request could be handled by Bitcoin Core.

mocacinno

legendary

Activity: 3584

Merit: 5243

https://merel.mobi => buy facemasks with BTC/LTC

Quote from: bob123 on May 25, 2020, 06:50:12 AM

--snip--

Quote from: mocacinno on May 25, 2020, 05:08:12 AM

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)

Quote from: ABCbits on May 25, 2020, 06:01:50 AM

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

You guys are obsessed with storage space Grin

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)

bob123

legendary

Activity: 1624

Merit: 2481

Quote from: mocacinno on May 25, 2020, 05:08: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".

Quote from: mocacinno on May 25, 2020, 05:08:12 AM

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)

Quote from: ABCbits on May 25, 2020, 06:01:50 AM

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

You guys are obsessed with storage space Grin

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.

ABCbits

legendary

Activity: 2870

Merit: 7490

Crypto Swap Exchange

Quote from: mocacinno on May 25, 2020, 02:55:17 AM

Quote from: ?? on ??

--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.

Quote from: mocacinno on May 25, 2020, 05:08:12 AM

Quote from: bob123 on May 25, 2020, 03: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).

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.

mocacinno

legendary

Activity: 3584

Merit: 5243

https://merel.mobi => buy facemasks with BTC/LTC

Quote from: bob123 on May 25, 2020, 03: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).

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)

bob123

legendary

Activity: 1624

Merit: 2481

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).

mocacinno

legendary

Activity: 3584

Merit: 5243

https://merel.mobi => buy facemasks with BTC/LTC

Quote from: ?? on ??

--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)

khandakersajjathossen

newbie

Activity: 2

Merit: 4

Quote from: ?? on ??

You might want to use paid API (such as 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

Quote from: OmegaStarScream on May 24, 2020, 03: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 - The block your transaction was included in (block height) + 1
631516 - 631509 + 1 = 8 confirmations

on blockchain api documentation 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 [email protected]

Quote from: OmegaStarScream on May 24, 2020, 03: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 - The block your transaction was included in (block height) + 1
631516 - 631509 + 1 = 8 confirmations

Blockcount - The block your transaction was included in (block height) + 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 Roll Eyes

Quote from: OmegaStarScream on May 24, 2020, 03: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 - The block your transaction was included in (block height) + 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]

OmegaStarScream

staff

Activity: 3500

Merit: 6152

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 - The block your transaction was included in (block height) + 1
631516 - 631509 + 1 = 8 confirmations

khandakersajjathossen

newbie

Activity: 2

Merit: 4

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.

Topic: Bitcoin confirmation API (Read 226 times)