Just 1st dispenser dispenses when batch-sending sats to multiple dispensers

[legalizemath]

This is the transaction (generated with a simple blue wallet)

https://blockstream.info/tx/11eb2b730e2e383a657c51d7b04bd55271d1e86ac9a2c74d3e3f6c78e88e23ff

where correct exact sats were sent to 5 different dispensers that all, even after tx confirmation, still had available assets to dispense

can see here just 1st issued https://xchain.io/tx/11eb2b730e2e383a657c51d7b04bd55271d1e86ac9a2c74d3e3f6c78e88e23ff

here are each of 5 dispensers in order of utxo output numbers (blockheight of tx = 719244):

• n0 https://xchain.io/tx/7ad422d7f74fa4fd8552ce50a295c48f4bf259bc3351d3a6482b24b7300829a7 (worked)
• n1 https://xchain.io/tx/b09ca2bd1e48a09b03bde25e91acbb250f4cdc43daae3942f8fc033b8b8c21fe (fail)
• n2 https://xchain.io/tx/8177deaaeb68ade1a099913a4d130f87cde02fdc6accba65dbf44660d0980793 (fail)
• n3 https://xchain.io/tx/ce04585fa2f377567564b21878bc1e132f39db37f8c84472f2349b62a9d79a62 (fail)
• n4 https://xchain.io/tx/4119116c715c1adebb4ae475515cda106e0a275d2f5447bb96dd1e80fb1515a3 (fail)

n5 is change

suggestion: as this might be current consensus rule if not just me misundersatnding, might suggest devs warnings not to batch as batching is now part of bluewallet and samourai wallet for starters and saves a lot on fees. it would seem obvious from address is same for each spend to dispenser that each would credit that address but it doesn't appear yet to be the case.

[jdogresorg]

bump... will get this fixed in the next release.

[jdogresorg]

This issue should be fixed with PR #1222

[Jpja]

Forum thread to discuss benefits, costs and risks of implementing this.

https://forums.counterparty.io/t/batch-sending-to-multiple-dispensers/6499

[jdogresorg]

closing.. update will be in upcoming release 9.60.3

[Jpja]

My concerns have not been answered. This is a new feature with tradeoffs, not a bug fix. Should go through the CIP process.

[jdogresorg]

IMO this is an improvement to CP which the community has been asking for quite a while, and should not be held up because we need more discussions and testing. This PR has been ready for 8+ months, so ample time has been given to do testing of this PR and raise any objections, performance or otherwise.

As to addressing your concerns / risks :

• Do classic sends trigger a dispense? - Unsure, but if so, its the same in 9.60.2, so not a change.
• Do issuance transfers trigger dispenses? - NO
• Do change outputs trigger a dispense? - NO
• Can address buy from own dispenser? - NO

Respectfully disagree that this should go through the CIP process. Simpler changes like this should not require a full CIP and lengthy discussions that last many months.

[Jpja]

Thanks for clarifying these concerns but several more factors need to be considered:

1. Block processing time. Counterparty looks at the 1st output only. This update will change that; all outputs must be checked against open dispensers. Bitcoin transactions with multiple outputs are commonly used by exchanges and mining pools. We should test how much extra time this adds to block processing.
2. "Gas" discount. One Bitcoin transaction equals one Counterparty instruction. This is the general logic. The btc transaction fee effectively serves as "gas" for CP. Exceptions are dividends, multi-send and sweep where multiple actions are initated by one btc transaction. XCP fees serve as additional gas in these cases. This update will make it possible to trigger multiple dispensers from one btc transaction without XCP fees. This is a concern because an extra output is very cheap.
3. Deliberate bloating. ORDIPEPE found a way trigger virtually unlimited dispenses from regular bitcoin transactions (not intended as CP txs). With this update, 2nd, 3rd, .. , nth outputs can be abused similarly. Even if we make it impossible to open dispensers on unused addresses, we should not ignore the risk of people finding ways to trigger dispensers from bitcoin transactions that would happen anyway (effectively getting the dispenses for free). For example, what if a mining pool decides to set up a dispenser for each payout address, triggered daily? For now, at least, this is limited to the first output.
4. Negative for CIP32. The "Dispenser Reservation" proposal is criticized for opening a potential attack vector. The attacker blocks dispensers by repeatedly reserving them. With this update, this attack will be cheaper to pull off.

I question whether those calling for batch-sending to dispensers have been aware of the tradeoffs. Since the effects on Counterparty are significant, a CIP is needed in my opinion.

[jotapea]

closing.. update will be in upcoming release 9.60.3

Why is a single person deciding this? We need MULTIPLE people agreeing to what should go into the next release. And even before the release, what gets actually MERGED to master.

[jdogresorg]

1. Block processing time...

This is a valid concern. I spent some time doing a quick parse of 1,000 blocks on 9.60.2 and 9.60.3 on the same machine, so we are looking at a fair parsing comparison.

v9.60.2 - 1,000 Block - Parse #1

counterparty_1              | [2023-10-13 14:10:23][INFO] Block: 811000 (1.91s, hashes: L:81879 / TX:8a846 / M:1d230)
counterparty_1              | [2023-10-13 14:10:26][INFO] Block: 811001 (2.51s, hashes: L:accb7 / TX:af3e1 / M:65f9d)
counterparty_1              | [2023-10-13 14:10:26][INFO] Block: 811002 (0.61s, hashes: L:17f75 / TX:d8d71 / M:ae6c7)
counterparty_1              | [2023-10-13 14:10:27][INFO] Block: 811003 (1.00s, hashes: L:ff8e0 / TX:bd760 / M:d4188)
counterparty_1              | [2023-10-13 14:10:28][INFO] Block: 811004 (0.61s, hashes: L:acbc8 / TX:ee661 / M:187a1)
counterparty_1              | [2023-10-13 14:10:28][INFO] Block: 811005 (0.47s, hashes: L:9fe14 / TX:a56de / M:ff805)
...
counterparty_1              | [2023-10-13 14:49:32][INFO] Block: 811995 (3.74s, hashes: L:3d660 / TX:f9ccb / M:606f2)
counterparty_1              | [2023-10-13 14:49:35][INFO] Block: 811996 (3.04s, hashes: L:b878e / TX:125b9 / M:7d00c)
counterparty_1              | [2023-10-13 14:49:38][INFO] Block: 811997 (3.55s, hashes: L:cf1fb / TX:501f8 / M:b2797)
counterparty_1              | [2023-10-13 14:49:42][INFO] Block: 811998 (3.52s, hashes: L:54f7e / TX:7303f / M:1a0c2)
counterparty_1              | [2023-10-13 14:49:44][INFO] Block: 811999 (2.55s, hashes: L:e4753 / TX:ddcbf / M:3eb2d)
counterparty_1              | [2023-10-13 14:49:47][INFO] Block: 812000 (2.24s, hashes: L:b3548 / TX:b53bd / M:8b2e3)

Total Parse Time : 2,362.03 Seconds (39.36 mins)

v9.60.3 - 1,000 Block - Parse #1

counterparty_1              | [2023-10-13 15:05:57][INFO] Block: 811000 (1.50s, hashes: L:81879 / TX:8a846 / M:e2594)
counterparty_1              | [2023-10-13 15:05:59][INFO] Block: 811001 (2.11s, hashes: L:accb7 / TX:af3e1 / M:69715)
counterparty_1              | [2023-10-13 15:06:00][INFO] Block: 811002 (0.47s, hashes: L:17f75 / TX:d8d71 / M:a1e62)
counterparty_1              | [2023-10-13 15:06:01][INFO] Block: 811003 (0.75s, hashes: L:ff8e0 / TX:bd760 / M:595c0)
counterparty_1              | [2023-10-13 15:06:01][INFO] Block: 811004 (0.67s, hashes: L:acbc8 / TX:ee661 / M:2cd35)
counterparty_1              | [2023-10-13 15:06:02][INFO] Block: 811005 (0.50s, hashes: L:9fe14 / TX:a56de / M:3d86e)
...
counterparty_1              | [2023-10-13 15:43:06][INFO] Block: 811996 (3.90s, hashes: L:b878e / TX:125b9 / M:fc34c)
counterparty_1              | [2023-10-13 15:43:10][INFO] Block: 811997 (4.32s, hashes: L:cf1fb / TX:501f8 / M:24818)
counterparty_1              | [2023-10-13 15:43:15][INFO] Block: 811998 (4.32s, hashes: L:54f7e / TX:7303f / M:95f41)
counterparty_1              | [2023-10-13 15:43:18][INFO] Block: 811999 (2.99s, hashes: L:e4753 / TX:ddcbf / M:e503e)
counterparty_1              | [2023-10-13 15:43:20][INFO] Block: 812000 (2.46s, hashes: L:b3548 / TX:b53bd / M:0050a)

Total Parse Time : 2,242.20 Seconds (37.37 mins)

The 9.60.3 release appears to parse blocks and transactions FASTER than 9.60.2.... Over 1,000 blocks, 2 minutes of parsing time was saved.

I'm re-running this test again to verify the results (and will post here), but it seems like enabling parsing of all outputs does not add any significant amount of processing time. I hope this addresses your performance concerns.

Update

v9.60.2 - 1,000 Block - Parse #2

counterparty_1              | [2023-10-13 16:02:01][INFO] Block: 811000 (1.73s, hashes: L:81879 / TX:8a846 / M:1d230)
counterparty_1              | [2023-10-13 16:02:03][INFO] Block: 811001 (2.11s, hashes: L:accb7 / TX:af3e1 / M:65f9d)
counterparty_1              | [2023-10-13 16:02:04][INFO] Block: 811002 (0.59s, hashes: L:17f75 / TX:d8d71 / M:ae6c7)
counterparty_1              | [2023-10-13 16:02:05][INFO] Block: 811003 (0.79s, hashes: L:ff8e0 / TX:bd760 / M:d4188)
counterparty_1              | [2023-10-13 16:02:05][INFO] Block: 811004 (0.43s, hashes: L:acbc8 / TX:ee661 / M:187a1)
counterparty_1              | [2023-10-13 16:02:06][INFO] Block: 811005 (0.73s, hashes: L:9fe14 / TX:a56de / M:ff805)
...
counterparty_1              | [2023-10-13 16:40:45][INFO] Block: 811995 (4.25s, hashes: L:3d660 / TX:f9ccb / M:606f2)
counterparty_1              | [2023-10-13 16:40:48][INFO] Block: 811996 (3.14s, hashes: L:b878e / TX:125b9 / M:7d00c)
counterparty_1              | [2023-10-13 16:40:52][INFO] Block: 811997 (4.16s, hashes: L:cf1fb / TX:501f8 / M:b2797)
counterparty_1              | [2023-10-13 16:40:56][INFO] Block: 811998 (3.74s, hashes: L:54f7e / TX:7303f / M:1a0c2)
counterparty_1              | [2023-10-13 16:40:59][INFO] Block: 811999 (2.76s, hashes: L:e4753 / TX:ddcbf / M:3eb2d)
counterparty_1              | [2023-10-13 16:41:02][INFO] Block: 812000 (2.79s, hashes: L:b3548 / TX:b53bd / M:8b2e3)

Total Parse Time : 2,339.86 Seconds (38.99 mins)

v9.60.3 - 1,000 Block - Parse #2

counterparty_1              | [2023-10-13 17:26:38][INFO] Block: 811000 (2.03s, hashes: L:81879 / TX:8a846 / M:e2594)
counterparty_1              | [2023-10-13 17:26:40][INFO] Block: 811001 (2.68s, hashes: L:accb7 / TX:af3e1 / M:69715)
counterparty_1              | [2023-10-13 17:26:41][INFO] Block: 811002 (0.37s, hashes: L:17f75 / TX:d8d71 / M:a1e62)
counterparty_1              | [2023-10-13 17:26:42][INFO] Block: 811003 (1.32s, hashes: L:ff8e0 / TX:bd760 / M:595c0)
counterparty_1              | [2023-10-13 17:26:43][INFO] Block: 811004 (0.84s, hashes: L:acbc8 / TX:ee661 / M:2cd35)
counterparty_1              | [2023-10-13 17:26:43][INFO] Block: 811005 (0.46s, hashes: L:9fe14 / TX:a56de / M:3d86e)
...
counterparty_1              | [2023-10-13 18:04:10][INFO] Block: 811995 (3.47s, hashes: L:3d660 / TX:f9ccb / M:886d4)
counterparty_1              | [2023-10-13 18:04:13][INFO] Block: 811996 (2.71s, hashes: L:b878e / TX:125b9 / M:fc34c)
counterparty_1              | [2023-10-13 18:04:16][INFO] Block: 811997 (3.12s, hashes: L:cf1fb / TX:501f8 / M:24818)
counterparty_1              | [2023-10-13 18:04:19][INFO] Block: 811998 (2.79s, hashes: L:54f7e / TX:7303f / M:95f41)
counterparty_1              | [2023-10-13 18:04:21][INFO] Block: 811999 (2.29s, hashes: L:e4753 / TX:ddcbf / M:e503e)
counterparty_1              | [2023-10-13 18:04:23][INFO] Block: 812000 (2.04s, hashes: L:b3548 / TX:b53bd / M:0050a)

Total Parse Time : 2,264.44 Seconds (37.74 mins)

Second parse confirms 9.60.3 still parses a bit faster than 9.60.2

[Jpja]

Thank you for doing this test. Can conclude that parsing won't slow down.

I'm still concerned of bloating due to low marginal cost though. I checked tx sizes on testnet:

Now it takes 222 vbytes to trigger a dispense from a classic address, and 141 vbytes from a segwit address (assuming one input and two outputs; for dispense and for change).

With the upgrade the marginal cost will drop to 31 vbytes for either address type.

Another concern comes to mind - multiple dispensers on the same address. This is a useful feature for selling a bundle of cards. However, it also means that a 141 vbytes send can trigger N dispenses. With the upgrade the cost drops to 31 vbytes. I don't think there's currently a limit to N. A limit should be considered whether or not we implement batch-sending.

One more concern - if you send from address A and change is returned to A, will this trigger dispenses from A?

[jdogresorg]

One more concern - if you send from address A and change is returned to A, will this trigger dispenses from A?

No, change outputs do not trigger dispenses. Dispenses can not be triggered by the dispenser address.... we explicitly ignore any outputs (change or otherwise) where the address == dispenser address.