Kill AddrIndexRs

[adamkrellenstein]

Dependencies

Consensus-Critical

• Rollback the dispenser_origin_permission_extended protocol change so we can drop get_oldest_tx()

TX Creation

• Replace get_unspent_txouts()
• Get rid of searchrawtransactions()

For TX creation, wallets should either make a call either to bitcoind (if the address in question is in the wallet) or to a public API or electrs. Counterparty can't return BTC balances for arbitrary addresses, because Bitcoin Core won't do it.

Note this will only be possible once the v10.4.0 protocol change has actually gone into effect and we have had the opportunity to hard-code historical dispenser creations

Update: See #2245 for information on how to modify transaction construction to work without AddrIndexRs.

[warrenpuffett]

Leather wallet is using this API for getting utxos: https://github.com/Blockstream/esplora/blob/master/API.md#get-addressaddressutxo

We could use the rate limited public API or host an Esplora instance of our own.

[jotapea]

Is this suggesting making the reference protocol implementation dependent on third party / external services? Or am I misunderstanding something?

Shouldn't the only data dependency to counterparty-core be Bitcoin?

[B0BSmiths]

Please correct me if i am wrong but a counterparty node needs to know about the UTXOs in order to build the a TX hex due to the use of arc4 when it comes to encoding data

Requiring users to dox themselves to 3rd party APIs in order to use Counterparty is a privacy nightmare and a massive downgrade over current functionality

If we are encouraging wallets to not use the Counterparty API to build transactions then we are encouraging them to skip sanity checks the API provides

[adamkrellenstein]

It will be like every other Bitcoin wallet. If you have a local node, you use only that. If you don't, you have to rely on someone else's node (in which case the information shared is the same info as is shared where you broadcast the TX you just created.)

Using those sanity checks would still be encouraged in this proposal. But they are fundamentally optional.

[jdogresorg]

• Rollback the dispenser_origin_permission_extended protocol change so we can drop get_oldest_tx()

Can you point me to ANY documentation or discussion of removing this origin functionality... anything to indicate that there has been SOME discussions on this issue with community members.

Certainly there should be SOME discussions with the community before randomly deciding what features should and should not be included in Counterparty.... right?

Removing this origin functionality will have the following effects :

Opening Dispenser

• Force users to send BTC to new dispenser address before opening
• Force users to send ASSET tokens to new dispensers address before opening
• Force users to open the dispenser from dispenser address
• Force users to do at LEAST 3 on-chain transactions to open a new dispenser on a new address (currently 1 tx)

Closing Dispenser

• Force users to send BTC to dispenser address before closing (required for BTC tx fees)
• Force users to close the dispenser from dispenser address
• Force users to send ASSET tokens from dispenser address back to origin address
• Force users to send BTC from dispenser address back to origin address

From my perspective, Counterparty is losing functionality which makes opening/refilling/closing dispensers a single transaction easy, and replacing it with a solution which will require no less than 3 transactions to open a dispenser and 1-4 transactions to close.

Certainly a controversial change like this, going from a single tx to open a dispenser to 3+ txs to accomplish the same task is something that should be discussed at length with the community before even being considered to be implemented.... right?

[adamkrellenstein]

• Rollback the dispenser_origin_permission_extended protocol change so we can drop get_oldest_tx()

Can you point me to ANY documentation or discussion of removing this origin functionality... anything to indicate that there has been SOME discussions on this issue with community members.

Certainly there should be SOME discussions with the community before randomly deciding what features should and should not be included in Counterparty.... right?

You're commenting on the wrong issue. See #1785, which includes a screenshot from one of many extended discussions on Telegram.

Removing this origin functionality will have the following effects :

Opening Dispenser

• Force users to send BTC to new dispenser address before opening
• Force users to send ASSET tokens to new dispensers address before opening
• Force users to open the dispenser from dispenser address
• Force users to do at LEAST 3 on-chain transactions to open a new dispenser on a new address (currently 1 tx)

Closing Dispenser

• Force users to send BTC to dispenser address before closing (required for BTC tx fees)
• Force users to close the dispenser from dispenser address
• Force users to send ASSET tokens from dispenser address back to origin address
• Force users to send BTC from dispenser address back to origin address

From my perspective, Counterparty is losing functionality which makes opening/refilling/closing dispensers a single transaction easy, and replacing it with a solution which will require no less than 3 transactions to open a dispenser and 1-4 transactions to close.

Certainly a controversial change like this, going from a single tx to open a dispenser to 3+ txs to accomplish the same task is something that should be discussed at length with the community before even being considered to be implemented.... right?

This change would require one additional transaction for opening a dispenser on a new address, which itself is a niche use case. Zero additional transactions would be required for closing.