One account rejecting respect aborts the whole respect distribution transaction.
This has already happened, see description of this proposal: https://eden.frapps.xyz/proposals/0xefe4128bd92ccb3becdbdbb66ac4b378a5526aaf62c9e050d9590ed87275cdef?txHash=0xacb4d66c8c11685e0dc4675c14740d343a77712d9cbd9416c5da0c5f176e3f7a
Attack vector
Attacker could join with fake account, participate with EOA. Then before executing respect distribution he could set code to their account that rejects the Respect transfer. What would happen later is that community would typically create a new proposal without him. But what if he had another slot in the breakout-room and can now set code for that EOA? Furthermore he could repeat it for every meeting.
The problem here is that anyone without any respect can perform this attack and he has nothing at stake (he has no Respect yet). He does need to fake genuine participation in Respect game though.
Some ideas for a solution
Simulate transactions before making proposals
Additionally could simulate before execution.
This would not solve things fully. Attacker could set code later and simulating before execution only helps in rare cases where user is not an attacker and is available to change his code
Fix at the contract level
Change Respect1155 contract so that it would not fail the whole tx if one receiver rejects.
This is the cleanest solution (and what should have probably been done from the beginning), but for existing deployments it would require changing address of new Respect and either starting new respect distribution or migrating it.
Distribute for new people in separate proposal
Decouple distribution (as separate proposals) for new people and distribution for established respect-holders, so that new people cannot mess up the distribution for the old.
This is significant deviation from the existing processes, but it could become viable with sufficiently sophisticated fractalgram and / or legislative branch (firmchain?).
Reverse proxy pattern
Abstract pattern: deploy a wrapper over owned contract that would sit between this contract and his owner. Set this wrapper as an owner. Owner would communicate with a wrapper as it did before with an owned contract. Wrapper could patch functionality of an owned contract this way.
In this case the wrapper would wrap Respect1155 contract. It would simply forward all the calls from OREC (real owner) to respect contract, except for mintRespectGroup calls. For these calls it would instead iterate through mintRequests and call mintRespect for each continuing in case of receiver rejection error (skipping mints for those receivers).
The downside is that gas consumption will probably increase significantly this way (1 external call for each recipient of respect instead of 1 call per whole mint group). But the current cost is typically only 1-2 cents, so it might still be a viable solution.
One account rejecting respect aborts the whole respect distribution transaction.
This has already happened, see description of this proposal: https://eden.frapps.xyz/proposals/0xefe4128bd92ccb3becdbdbb66ac4b378a5526aaf62c9e050d9590ed87275cdef?txHash=0xacb4d66c8c11685e0dc4675c14740d343a77712d9cbd9416c5da0c5f176e3f7a
Attack vector
Attacker could join with fake account, participate with EOA. Then before executing respect distribution he could set code to their account that rejects the Respect transfer. What would happen later is that community would typically create a new proposal without him. But what if he had another slot in the breakout-room and can now set code for that EOA? Furthermore he could repeat it for every meeting.
The problem here is that anyone without any respect can perform this attack and he has nothing at stake (he has no Respect yet). He does need to fake genuine participation in Respect game though.
Some ideas for a solution
Simulate transactions before making proposals
Additionally could simulate before execution.
This would not solve things fully. Attacker could set code later and simulating before execution only helps in rare cases where user is not an attacker and is available to change his code
Fix at the contract level
Change Respect1155 contract so that it would not fail the whole tx if one receiver rejects.
This is the cleanest solution (and what should have probably been done from the beginning), but for existing deployments it would require changing address of new Respect and either starting new respect distribution or migrating it.
Distribute for new people in separate proposal
Decouple distribution (as separate proposals) for new people and distribution for established respect-holders, so that new people cannot mess up the distribution for the old.
This is significant deviation from the existing processes, but it could become viable with sufficiently sophisticated fractalgram and / or legislative branch (firmchain?).
Reverse proxy pattern
Abstract pattern: deploy a wrapper over owned contract that would sit between this contract and his owner. Set this wrapper as an owner. Owner would communicate with a wrapper as it did before with an owned contract. Wrapper could patch functionality of an owned contract this way.
In this case the wrapper would wrap Respect1155 contract. It would simply forward all the calls from OREC (real owner) to respect contract, except for
mintRespectGroupcalls. For these calls it would instead iterate throughmintRequestsand callmintRespectfor each continuing in case of receiver rejection error (skipping mints for those receivers).The downside is that gas consumption will probably increase significantly this way (1 external call for each recipient of respect instead of 1 call per whole mint group). But the current cost is typically only 1-2 cents, so it might still be a viable solution.