Remove the AddrIndexrs dependency in the dispenser.

[ouziel-slama]

Unless you figure out why the protocol needs it, there's no point adding dependencies that make it harder for everyone to install Counterparty. Bitcoind is normally sufficient for the protocol, adding heavy dependencies can only make adoption of an application more difficult.
Once a transaction is in the database we should not need the backend to parse a message! We cannot consider the Blockchain as a whole as the Counterparty database. This makes no sense.

[adamkrellenstein]

Ah I thought that this was necessary! 🤯

[ouziel-slama]

I thought so too! but the only reason to have something like addrindexrs is if we need to retrieve all Bitcoin transactions for a given address. And I can't find this functionality used anywhere except in an API endpoint.

[ouziel-slama]

I found: https://github.com/CounterpartyXCP/counterparty-lib/blob/master/counterpartylib/lib/messages/dispenser.py#L195
Again the dispenser who breaks the design of Counterparty without thinking about the consequences.
I'm leaving this ticket open because this horror needs to be removed. Once a transaction is in the database we should not need the backend to parse a message! We cannot consider the Blockchain as a whole as the Counterparty database. This makes no sense.

[Jpja]

For context; the cannot open on another address if it has any confirmed bitcoin txs rule was added with 9.61. It was a response to dispensers put up on exchange hot wallets. These addresses keep receiving BTC over and over, triggering thousands of dispenses. I believe addrindexrs was modified for this update alone.

A limit of 1000 dispenses was also introduced with 9.61, addressing the same problem.

[adamkrellenstein]

uh can we roll that back so we can fix the core architecture? @ouziel-slama is right, this kind of thing breaks the whole transaction model and will have significant consequences for performance optimization

[ouziel-slama]

For context; the cannot open on another address if it has any confirmed bitcoin txs rule was added with 9.61. It was a response to dispensers put up on exchange hot wallets. These addresses keep receiving BTC over and over, triggering thousands of dispenses. I believe addrindexrs was modified for this update alone.

A limit of 1000 dispenses was also introduced with 9.61, addressing the same problem.

Sorry I'm not sure I understand! either the dispenser is still full and open and several thousand dispenses should not be a problem. Either the dispenser is empty or closed and this should not create a "dispense" in the base.
If there are performance problems with only a few thousand dispenses, it is most likely because of the underlying problem of the dispenser which is not using messages. By persisting in wanting to keep a function that makes no sense we inevitably end up putting in patches which make the problem worse...

[ouziel-slama]

A limit of https://github.com/CounterpartyXCP/counterparty-lib/pull/1264 was also introduced with 9.61, addressing the same problem.

@Jpja @adamkrellenstein the limit of 1000 sounds enough to resolve the problem for now, right ? if yes then let's remove "cannot open on another address if it has any confirmed bitcoin txs" as quickly as possible.

[adamkrellenstein]

Kill it with fire 🔥

[Jpja]

the limit of 1000 sounds enough to resolve the problem for now, right

Yes, agree. Let's remove "cannot open on another address if it has any confirmed bitcoin txs"

[ouziel-slama]

Ah I finally (re)found why we need an addrindex and I remember now :) here https://github.com/CounterpartyXCP/counterparty-lib/blob/master/counterpartylib/lib/backend/__init__.py#L224 for the pubkeyhash_to_pubkey function.
However, we should never use this function inside a contract! I renamed the issue and edited the OP.

[jotapea]

the only reason to have something like addrindexrs is if we need to retrieve all Bitcoin transactions for a given address

This is what dispensers do. While open + units remaining, any source address that sends enough bitcoin to a dispenser destination address will trigger a dispense. It is logically simple, but I understand it might break previous assumptions like all Counterparty transactions must have the CNTRPRTY message...

Will the "retrieve all Bitcoin transactions for a given address" functionality be moved to counterparty-lib? This is what needs to happen in order to continue supporting dispensers as they exist now...

Or what are people thinking about how to move forward with dispensers?

[adamkrellenstein]

See https://github.com/CounterpartyXCP/counterparty-lib/issues/1331

[adamkrellenstein]

See #1764