Recursive Address /r/address/:address

[elocremarc]

This PR will add the ability for an inscription to know runes balances, sat balances, Inscriptions and outputs for any address recursively.

Note:
This will need #3891 for an inscription to find an address to query this endpoint with.

[lifofifoX]

If we truly desire rune-aware inscriptions, it might be worth upgrading the Rune protocol to make them inscription aware and allow deposits/withdrawals of Runes to/from an inscription.

For example, add an inscription flag to the Edict struct, requiring it to be set for both deposits and withdrawals, indicating that the balance should go to the first inscription in the edict output. The balance could then be exposed via /r/inscription endpoint.

[ameenwire100]

Nice work

[raphjaph]

I don't think it makes sense right now because the address index is extremely new and untested. Creating a heavy dependency on it through a recursive endpoint would not be ideal. Have you built the address index and tried playing around with this endpoint?

[switch-900]

This should be looked at properly, the the possibilities of this are very valuable to the building community.

[matthewvollmer]

Hey, have you all considered if this makes sense, now that the address index has been out for a bit?
I have some use cases for this that I would love to use!

Currently, I have a collection (BTC Substance) that detects if the owning wallet owns multiple pieces in the collection, and updates the art to reflect this. Currently, I have to manually call /r/inscription/ on each inscription in the collection to get the address info, and compare it to the owner address.

The collection is only 100 pieces, so it's somewhat feasible to do 100 async calls while loading the art. But it seems infeasible to scale this approach for larger collections. For my 5k collection, I would love to just be able to call /r/address/ once to get this info!

I personally think that if this was available, other artists would find ways to incorporate ownership-awareness into their code.

I acknowledge that having inscriptions rely on the address inscription would increase the difficulty of people running their own node, and the strain on marketplaces. But I think it also offers a lot of opportunity in terms of art&tech.

Thanks so much for your consideration!
~MDV

[elocremarc]

@raphjaph

I don't think it makes sense right now because the address index is extremely new and untested.....Have you built the address index and tried playing around with this endpoint?

How about now?

When you wrote this originally I was struggling to sync it. However since that big index update I have been able to keep my address index at chain tip relatively easily no issues. Is there still more optimization you are working on for the address index or do you think we are finally ready?

[arik-so]

NACK. Address reuse is already excessively encouraged as it is, and I only see it exacerbating the privacy issues.