allow triggering of dispensers by all tx outputs, not just the first output

[pataegrillo]

No description provided.

[jdogresorg]

Does this ignore the last output which is typically the change output?

We don't want to accidentally trigger a "dispense" on change returning to an address where a dispenser is setup.

IMO an output should be considered a change output, and ignored, if the output address matches any input address.

Thoughts?

[jdogresorg]

Dispenser Testing

• Create dispenser on mvThcDEbeqog2aJ7JNj1FefUPaNdYYGqHt - 7b6cd0b713a554a6cff8006bb06a976e39364f5527e6bff54040f3ea16c4d526
• Send BTC to 3 dispensers from mvThcDEbeqog2aJ7JNj1FefUPaNdYYGqHt- a41d0279b9743f715afc80c10e06aa892836e290b93a0a8e8f433480a860c42f
  • Verify 3 dispenses were triggered - OK
  • Verify 3 addresses were credited properly - OK
  • Verify change did not trigger dispenser - OK
  • Verify 3 records created in transaction_outputs table - OK
• Send BTC to a single dispenser from different address - 279125260c4bc68b5442b7e049baba0c9c09f218ad9ce751d4f688d37450f5d2
• Verify 1 dispense was triggered - OK
• Verify 1 address was credited properly - OK
• Verify 1 record created in transaction_outputs table - OK

counterparty-testnet_1      | [2023-10-09 18:53:39][INFO] Dispense: 1 MPMATEST from n4hpgJypngUAsLoLRXD9XMCDoGCoL7pxSY to mvThcDEbeqog2aJ7JNj1FefUPaNdYYGqHt (a41d0279b9743f715afc80c10e06aa892836e290b93a0a8e8f433480a860c42f)
counterparty-testnet_1      | [2023-10-09 18:53:39][INFO] Dispense: 1 MPMATESTTWO from mgwKj2k5G3kuuaM3oknmw5Y7aT1c5HGocT to mvThcDEbeqog2aJ7JNj1FefUPaNdYYGqHt (a41d0279b9743f715afc80c10e06aa892836e290b93a0a8e8f433480a860c42f)
counterparty-testnet_1      | [2023-10-09 18:53:39][INFO] Dispenser: n4ppuyTv5dafqbVdibFL8sYyJR4y7V6kgQ closed dispenser for QQQQQQQQQQ (dispenser empty)
counterparty-testnet_1      | [2023-10-09 18:53:39][INFO] Dispense: 1 QQQQQQQQQQ from n4ppuyTv5dafqbVdibFL8sYyJR4y7V6kgQ to mvThcDEbeqog2aJ7JNj1FefUPaNdYYGqHt (a41d0279b9743f715afc80c10e06aa892836e290b93a0a8e8f433480a860c42f)
counterparty-testnet_1      | [2023-10-09 18:53:39][INFO] Block: 2531551 (0.16s, hashes: L:41ee3 / TX:598eb / M:1c646)
counterparty-testnet_1      | [2023-10-09 18:58:47][INFO] Block: 2531552 (0.15s, hashes: L:c1ee0 / TX:925b9 / M:d67e3)
counterparty-testnet_1      | [2023-10-09 19:02:38][INFO] Block: 2531553 (0.17s, hashes: L:1365a / TX:9f482 / M:d5808) 
counterparty-testnet_1      | [2023-10-09 19:05:18][INFO] Dispense: 10 MPMATEST from n4hpgJypngUAsLoLRXD9XMCDoGCoL7pxSY to tb1q50kxp76j9l0k9jgwasvcz4mcz0v03fv2wj67a4 (279125260c4bc68b5442b7e049baba0c9c09f218ad9ce751d4f688d37450f5d2)
counterparty-testnet_1      | [2023-10-09 19:05:18][INFO] Block: 2531554 (0.15s, hashes: L:8ea15 / TX:5140e / M:eeafb)

[Jpja]

I have several concerns, some still unanswered,
https://github.com/CounterpartyXCP/counterparty-lib/issues/1148

The main issue being the cost of dispensing converging to zero. Everything else in Counterparty have implied BTC fees or explicit XCP fees. This is a significant tradeoff and should go through the CIP process.

NACK