Feature request for optional public withdrawals

[PaulRBerg]

Problem

I've recently demo-ed Sablier on a business call with Contango. I told them about our public withdrawal feature and why we have implemented it, and they said that they would like to be able to disable it for their streams.

The rationale was to eliminate the risk of 'accounting griefing' for their investors; i.e., someone intentionally claiming small amounts to clutter the transaction history for their investor accounts.

Solution

Add a new boolean in the stream struct that specifies if withdrawals are publicly available or not.

Feedback

My take on this is not to rush, and wait for more user requests before making any move.

1. There's no incentive for perfroming these public withdrawals. The only actors somewhat incentivized to do it are malicious competitors/enemies, but there are better ways to cause harm than through accounting griefing.
2. The size of the Lockup contract is a concern.

cc @sablier-labs/solidity and @razgraf and @maxdesalle for feedback

[maxdesalle]

Don't really have an opinion on how needed this is, and am generally in favor keeping the protococol minimal etc., but in any case this griefing "attack" is an expensive one given the attacker needs to pay gas fees. In worst cases it would cause minor discomfort for a specific user, but it's not the end of the world either.

[andreivladbrg]

I am in favor of this proposal (and have been since the beginning back in 2022 😆).

Re the added complexity, it’s just one boolean in the struct, and we could handle it in this function, which would make things smoother.

[smol-ninja]

I am not in favour of this feature but I’d also like to see more user requests before we move forward with implementing it. My rationale is below:

• I agree with Max that a "griefing attack" is unlikely due to the gas cost, which leaves "zero" incentive for anyone. Public withdrawals are only useful for users managing multiple streams across multiple addresses, and they want to withdraw from all of them without needing to switch between wallets or grant transfer approvals. And someone can only accidentally withdraw on an unknown stream.

• So, if griefing attacks are not incentivised, even though a small feature, it may be redundant or only useful to an Infinitesimal set of users, let's say.

If we make a decision to implement it, then:

• Senders should not have the ability to enable or disable this feature. Since it directly impacts recipients, they should be the ones deciding whether public withdrawals are enabled or disabled for their streams. This would mean managing a mapping for recipients (address => bool), which would apply globally to all their streams.

• Would it also need to be applied to the claim? The same "accounting griefing" argument applies there as well.