You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Similar to what's described on https://www.reddit.com/r/JungleTV/comments/onnut1/crowd_funding/ minus some of the limits. Rate-limiting for enqueuing proposals coming from the same user can be implemented by increasing the down-payment with every successive simultaneous attempt, instead of hard-limiting to one proposal per user. In fact, it would be an interesting idea to make the down-payment amount increase with the number of active proposals, regardless of who made them - this means the number of active proposals can increase indefinitely, but at a cost to those wanting to increase it beyond reasonable points, much like what happens with the queue length factor in the main media queue.
Each active proposal gets a fixed payment address from the pool. Active proposals would need to be stored in the DB as to not lose track of their funds/state/address. The addresses would need to be taken from the pool again on start-up (this represents a change to how the address pool works, since right now it is kind of a "free list" that contains addresses that were once used and are free to use again. We'd need to introduce the concept of taking a specific address from the pool instead of just asking it for an arbitrary one.)
For reference in case the post is deleted:
The text was updated successfully, but these errors were encountered:
Similar to what's described on https://www.reddit.com/r/JungleTV/comments/onnut1/crowd_funding/ minus some of the limits. Rate-limiting for enqueuing proposals coming from the same user can be implemented by increasing the down-payment with every successive simultaneous attempt, instead of hard-limiting to one proposal per user. In fact, it would be an interesting idea to make the down-payment amount increase with the number of active proposals, regardless of who made them - this means the number of active proposals can increase indefinitely, but at a cost to those wanting to increase it beyond reasonable points, much like what happens with the queue length factor in the main media queue.
Each active proposal gets a fixed payment address from the pool. Active proposals would need to be stored in the DB as to not lose track of their funds/state/address. The addresses would need to be taken from the pool again on start-up (this represents a change to how the address pool works, since right now it is kind of a "free list" that contains addresses that were once used and are free to use again. We'd need to introduce the concept of taking a specific address from the pool instead of just asking it for an arbitrary one.)
For reference in case the post is deleted:
The text was updated successfully, but these errors were encountered: