[CALL FOR OPINIONS] Physical Bitcoin Trackers ? Do we need them ? If yes, how ?

[yogg]

So, last year I made that tool to track Satori Coins which is currently down. (http://www.satoritool.site)

It broke sometime in January. I understood what happened : it is because of some changes they made on the blockchain service provider side.
They decreased the quantity of queries you can make, per second, to their service.
The Satori Tool Site was refreshing the state of the each Satori Coin every day.

I realized all that when I was working on some BTCC Chips & Coins tracker, and well, this is a problem.
I could make it in a way so it doesn't query a coin that has been redeemed anymore in the future, but that won't solve the core issue.

I will most certainly make a tracker for Coldkey, but that tracker could also have Satori, BTCC, and why not most of the documented physical bitcoin releases.
Which would make the volume of addresses to update every day massive .. Potentially 100's of thousands of addresses to scan periodically.

Satori itself has 50k addresses, and BTCC has a bit more from what I recall when I formatted the addresses.
If I am to make that "Tracker to track them all", the previous issues will kick in.

There are solutions :
- Pay for an un-throttled access to a blockchain service API.
- Host a copy of Bitcoin Core and some internal explorer, and have the tracker code to check balance against this setup.
- Rent multiple servers (so multiple IPs to query blockchain APIs) that will have their own, different, set of addresses  to query each day and feed result in a database.

The tracker website would display the result of the daily updates.

Please, can you share your opinions on the project, and also as collectors, on :

- What data would you like to see displayed ?
- Should public addresses be displayed ?
- What features would you like to see ?

[1715384069]

1715384069

[1715384069]

1715384069

[1715384069]

1715384069

[1715384069]

1715384069

[1715384069]

1715384069

[JUPITYR]

This is a great idea.  As to your questions:

Data:  Maker/Year Issued/Material of the coin (if known)/Denom/

Public Address:  Honestly I think this is going to be hard to hide anyway, so wouldn't spend a lot of time trying to hide them.

Features:  Some may disagree, but I like the blocktrail explorer that shows you the current value of all the forks your coin contains.  Certainly would help in establishing the true value of each coin, especially those funded pre-shit forks. 

Also, if the coin is known to be in a 3PG holder, the name of the 3PG and grade would be a nice feature. 

[Lauda]

- Host a copy of Bitcoin Core and some internal explorer, and have the tracker code to check balance against this setup.

This is sufficient. You don't need third party services or multiple servers. You can query the Core via the RPC for all those addresses.
We need 1 tool for all physical Bitcoin, not 1 per manufacturer.

[ChiBitCTy]

Well first of all, if you'd like a Mr Robot to help code this puppy up right away I'm your guy!     I would love to see as much as you're willing to do Yoggy...I loved the satori tool as well as Rusbit's Casascius tracker...I think they are awesome to have around and we're lucky to have you Mr Robots around coding these things up! The more the merrier for me!  Thx!!

[Agrawas]

They decreased the quantity of queries you can make, per second, to their service.

Can you do something like update the address data in batches instead of hitting all together. I recently did that in one of our project, it reduces the execution time by many times..

[krogothmanhattan]

Great idea as always Mr Robot Yogg!!

  - What data would you like to see displayed ?

  Show the amount swept...still loaded, unloaded...dates etc etc...the more info the merrier. To a certain extent

- Should public addresses be displayed ?

 I am against that

- What features would you like to see ?

   As many features as you can....especially a graph with Bitcoins price alongside the amount of coins swept to give an idea how BTC price influences people to peel their coins.

[owlcatz]

There used to be a free web service that you could input your own addresses and I would get an email if any balance moved back or forth. It allowed you to give a nickname to the address like "Cas Goldie XXXX" etc etc....

I would pay for a service like that, as I haven't found one as simple and straightforward - free or cheap!

Thanks Yogg either way!

[krogothmanhattan]

There used to be a free web service that you could input your own addresses and I would get an email if any balance moved back or forth. It allowed you to give a nickname to the address like "Cas Goldie XXXX" etc etc....

I would pay for a service like that, as I haven't found one as simple and straightforward - free or cheap!

Thanks Yogg either way!

    I have an app that does the same thing.

    I did suggest this app last year and perhaps creating one for us thru a Mr Robot on our forum. I believe I discussed making such an app with Yogg too!

    Perhaps an app would be the way to go?

[yogg]

Thanks everyone for your replies. I have noted your suggestions.

- Host a copy of Bitcoin Core and some internal explorer, and have the tracker code to check balance against this setup.

This is sufficient. You don't need third party services or multiple servers. You can query the Core via the RPC for all those addresses.
We need 1 tool for all physical Bitcoin, not 1 per manufacturer.

Totally agree. We need one tracker for all.

Yes, this would work, but hosting a full node today is quite hefty.
Also, Bitcoin Core has no RPC method to query the "balance" of an address that isn't local to the wallet.
I do not see iquidus or abe running smoothly on top of Bitcoin Core, and being regularly queried by the tracker, on an infrastructure that is affordable for the project at least.
(Nope, I'm not NATing a port )

So this solution would imply to code such middleware that tracks "balances" of all addresses, analyzing all inputs and outputs to impact the balances on the database ..
It still feels hefty to run.  

Some may disagree, but I like the blocktrail explorer that shows you the current value of all the forks your coin contains.  Certainly would help in establishing the true value of each coin, especially those funded pre-shit forks.  

Shit forks values is interesting indeed. Will do that in some way.

There used to be a free web service that you could input your own addresses and I would get an email if any balance moved back or forth. It allowed you to give a nickname to the address like "Cas Goldie XXXX" etc etc....

I would pay for a service like that, as I haven't found one as simple and straightforward - free or cheap!

Thanks Yogg either way!

That's also something that can be done in the context of a tracker !
Pfew, so many stuff to do/can be done !

- Should public addresses be displayed ?
 I am against that

I understand completely the concerns about dusting.

There can be no list of aggregated addresses publicly displayed on the tracker, just data and stats, but these will always be in the wild somehow.
For Satori Coins, Raimu still hosts on their website the PDFs with all public addresses that have been generated.
Same goes with most of the physical bitcoins. So I am still a bit uncertain about what to do with this.

[Lauda]

Yes, this would work, but hosting a full node today is quite hefty.

Depends.

Also, Bitcoin Core has no RPC method to query the "balance" of an address that isn't local to the wallet.
I do not see iquidus or abe running smoothly on top of Bitcoin Core, and being regularly queried by the tracker, on an infrastructure that is affordable for the project at least.
(Nope, I'm not NATing a port )

So this solution would imply to code such middleware that tracks "balances" of all addresses, analyzing all inputs and outputs to impact the balances on the database ..
It still feels hefty to run.  

The simplest way to do this with the least functionality is to mass import all those addresses to create a super-watch-only wallet. That would keep track of everything.

[yogg]

There is yet another solution I thought of .. that will make it many easy, much simple, such tracker.

What about ... updating each address once per week, instead of once every 24hr ?
The point is to know, roughly which % of the total run has been redeemed.

A few 100's of 1000's of addresses can easily be scanned and tracked on a weekly basis.
Doing so every day starts to be challenging.

Is daily accuracy something we need ?

[Lauda]

Is daily accuracy something we need ?

It is not, no.