Radical Suggestion: Rez Tax / 1L deposit

Warning: This is a very controversial idea, meant to stimulate discussion.

What if we had a rez tax - 1L for every object rezzed? It would work like a soda can deposit - you give 1L for the object rezzed, and if deleted, you get the 1L back. If an object is sold, it counts also as deletion, and if sold "original", the new owner pays the rez deposit.

Would it be possible to run a denial of service attack? Sure, but it'd cost a crapload of money to do. And at 1L, it couldn't possibly hinder the work of people - especially considering textures are already 10L.

Further, we could even say that the rez deposit / tax would only apply to more than 100 objects per day. So no casual users are likely to ever use it.

EDIT:

Agreed. I'll add it to the original post.

That's why we're discussing this - good input.

Note - I did suggest objects, not prims. I think prims would be harder to regulate.

Let's exclude owners / groups for private islands, and let's raise the minimum cap to be based on the size of the plot of land - if you are the landowner / in the group of the land.

So if it's your land, and you own half a sim, we'll say that your daily cap before deposit could be like ... 100 (base for everyone) + something like 1 object / m / day ON the land you owned or are group in. (Just to put a number out there to start.) - so you'd have roughly 32000 objects / day - far less than what could ever be a DOS attack, and plenty for you to do your work.


Ah... I think the solution would be a localized variable to the land ... so the # prims rezzed would be tied to the land.

not a bad idea. you get ur money back when u derez and have a daily "stipend" of rezzing. if it were to happen, I think sandboxes should be exluded (sure u can crash a sandbax, but thats it)

i also dont think we will have a snowballs chance in hell of having LL impement such coding

Nah. This would break the backs of several scripters that rely on free rezzing to get beneficial stuff done (myself included).


Consider it thusly: I own half a sim of land now (technically speaking). Primmies rezzes about 1-2k prims every time the board changes, and I only have the low five digits in L$ to work with. That would hamper the number of boards I could have, etc etc. And there would likely be leaks where ghosting and number of calls to the asset server are concerned.

So - ow.


Instead, I would prefer a cap on the number of prims/sim a user can have without owning tier in that sim, being a member of a group tiered in that sim, or it being a sandbox. 500 or even 1k seems fair.

I like that because it would also curb the "my land is not a sandbox" problem.

It was like that in 1.0, except it was L$10.
For various reasons it did not work out.

All you need to do is make llGiveInventory depend on the object's "energy budget" like llPushObject and every physical function.

Agreed. I'll add it to the original post.

That's why we're discussing this - good input.

Note - I did suggest objects, not prims. I think prims would be harder to regulate.

Let's exclude owners / groups for private islands, and let's raise the minimum cap to be based on the size of the plot of land - if you are the landowner / in the group of the land.

So if it's your land, and you own half a sim, we'll say that your daily cap before deposit could be like ... 100 (base for everyone) + something like 1 object / m / day ON the land you owned or are group in. (Just to put a number out there to start.) - so you'd have roughly 32000 objects / day - far less than what could ever be a DOS attack, and plenty for you to do your work.


Ah... I think the solution would be a localized variable to the land ... so the # prims rezzed would be tied to the land.

I'm aware, and L$10 is too high, and it didn't include a base free amount.

That was trying to tax all land ... this is more of a "deposit" where it's basically to reduce overuse, without stiffling large projects.

Gaffe, my part. In context, where the Primmies example concerned, objects == prims for most of it.

Believe me, that coding hurt.

Seconded, and thirded by my alternate personnality.

Also, why not hard-limit the number of physical entities on a server ? Since it seems Havok is the easiest and shortest way to crash sims, it should be looked more closely...

with o2o transfers nerfed across sims, this seems less radical.

The primary issue I have with this idea is it would affect Newbies & Basic account holders a lot more than those of us that are Premium, or have been around a while.

Excluding Sandboxes is a step in the right direction. But thinking of playing a good game of Primtionary makes me shudder a little.

Granted, there's always Lindex - but its somewhat of a creativity stifler, especially if you consider sandboxes.

I'm a little more partial to Eggy's idea, myself

i think the best way would be simply a dynamic scaling server side, the more a user try to pull pocessing power on a sim that is ALREADY slowed down, the less he get

IMO.

suck the average player dry, then wonder why they are not buying anything.

I think enough has been taken.

no

Yeah, i thought of that.

How about making the daily stipend high? I mean, how high do you have to be to really grief? In the tens of thousands? millions or objects?

I think we could safely put a cap at 1000 free object rezzes per day.

And remember - you'd still get your money back for objects that derez or that you take into inventory.

I think one of the better answers to this general problem - too much rezzing, too much outbound traffic over XML-RPC, and whatever other headaches LL is concerned about - is automated statistical controls.

At some reasonable interval, you take a population sample of all of the activity that you want to watch at intervals. Alternately, you build this check in at the time the action is performed. (Or, you could use a mix of these two techniques.) Some of it could be done at the sim level (which would have shut down Ol's physics balls pretty damn quick) and some could be done at the global level (i.e. a device watching the XML-RPC traffic - hardware solutions for this are on the market as pointed out by someone in another thread about XML-RPC.)

Anything that deviates from the baseline for acceptable activity by more than x number of standard deviations can then be addressed in a number of ways. For example, if a sim sees that you are rezzing waaaaaaay more physical objects than a normal user would, it might halt rezzing activity coming from you and send an IM to all online liaisons or other LL staff. If a traffic shaper watching XML-RPC packets saw that an inordinate amount of them were tagged with your username, it could throttle the number of packets it forwarded on your behalf, and raise an admin flag so that they could contact you about it. (Some people might have legitimate high-volume needs, whereas others might be trying to do something nefarious.)

To my way of thinking, this is a lot more effective solution than nerfing things that have legitimate uses, or putting in script delays that can be defeated anyway.

Griefsphere 4.0, Social Engineering Version:

I cook up something marginally amusing with a barebones legitimate function (fliptitles come to mind as an example, if the Grid weren't already saturated with them), and then give them out as fast as I can to newbies, folks in the WA, what have you.

On some magic day each active copy of my fliptitle drops a little pellet, which waits for the owner to be out of sensor range (or not) and then starts The Viral Boogie as fast as it can.

Multiple owners, multiple rezzes, multiple accounts hit for the $1L/rez tax when the daily limit is hit.

So...what about a system-level dialog that has to be answered by an avie before the first taxable (or "rented" rez of the day is permitted?

-- jj

You mean a trojan?

Fortunately, that's more complicated than the simple "on changed inventory rez the inventory a little bit offset, then give the inventory to the new object" technique.

And fortunately, any decent scripter wants to stay in SL so far.

But yeah, I've considered the day when that becomes real, and I'm sure a lot of other scripters have ... it's a scary thought, and the only protection for the grid is to have:
(a) As the grid gets bigger, the attitude has to shift from "wee, free stuff!" to "okay, is this script reliable and safe"?
(b) distributed servers for assets and WWW-like router / DNS redundancy
(c) mechanisms in place for sims to shut down Scripts Gone Wild (tm)

Right now we're discussing methods to enact (c). I'm not sold that my idea is the best, either. If it were possible for a sim to simply see that there are too many things going on, to enqueue them, and then intelligently time-share (limit CPU hog use) that would certainly be most optimal.

That, and locking up some of these eff-tards who are grid-crashers.

EDIT:

But what really worries me is not the sim-crashing trojans, but the privacy trojans ... trojans that might steal a couple L$ from each person in slow intervals ... or that tracks peoples' movement or contact with people, monitoring them. In other words, I'm worried abou the trojans that never "explode", but do the damage silently.

You know, like your web plugins on your toolbar that tracks your website usage.

Just another thing to think about hiro-san.

Per-object? Or per prim?

Per-object: I rez a large linkset (a building), and unlink (maybe I'm making mods, maybe I'm gaming the per object tax). I now have...Oh, a hundred objects. When do they get paid for, if they do?

Per-prim: I rez a bunch of prims, and link them together and take them back into my inventory, or delete them. System has to make sure I get credit for each one.

I smell tricky code-paths. Oh, and maybe a wumpus! No...it's just a bat.

Yay! If everyone can keep posting their ways of defeating the latest nerfing to create virii, as they seem to enjoy doing in this and the various other threads about it, then hopefully we can get every other feature nerfed in typical LL knee jerk style when someone decides to use it!

Yes, yes. We can ALL crash the whole grid in a second in half a dozen different ways if we want to. We're all very clever. But please quit giving people nice fat hints on how to go about it, eh?

It's yourselves you're shooting in the foot, ya know. Because it isn't the (sometimes) responsible scripters who are discussing the various options and solutions who are gonna use it for mischief. It's the morons who read it and think it'd be fun to test your theory. But then it's us scripters who suffer for it when LL decide to ruin businesses and screw months and years of work with their over the top reactions (despite having known about the problem forever and done fuck all about it).

Of course, ordinarily I'd never want to supress people talking about implementations etc. But knowing what LL are like, can we, like, not?

That's how Frame-Relay ensures Quality of Service in the real world. This is an excellent suggestion, and in fact I think QoS policies and algorithms might be a good place to start devising a solution to the problem at hand. I'll be emailing Kelly right now to support your suggestion.

There is only one logical answer. If LL are to provide sims capable of supporting 15000 prims, and those prims can be set physical, then the sim should either be able to run with 15,000 physical prims or have a failsafe mode to prevent grid crashing.

As others have pointed out there are 1001 ways to bring down the grid if any of the half decent scripters put thier minds to it. The only solution is to make the grid more stable and not reduce the feature set that most people have come to rely on.

YES Surina!

My sentiments exactly.

Look, I fully intend, when I have some extra cash, maybe after Christmas or so, to upgrade to the premium account and maybe buy some land. But let's say I never intend to buy land, and why should I be forced to? I will forever be fucked with this retarded llGiveInventory nerf. I'm a pretty good scripter too, so I could feasibly sell my services to people and only ever work in a public sandbox. Now I can never even TEST any products I may devise that could legitimately use llGiveInventory. And I can easily think of a few.

So now LL has crippled me, and many many other free account people. Now we have to pay more to get the full feature set of the platform. So on the home page of their website they can no longer state that accounts are "absolutely free", or at least they should put an asterisk next to it stating that free accounts have limited capabilities.

Code up some prim rezzing velocity detector systems. Limit the number of prims rezzed by any one person at a time (but make it for EVERYONE). Limit the number of prims allowed in a sim at any one time (some large, scalable number just below the crash point for that particular sim). Before an object can become physical, have it ask the system for permission to do so, then the server determines if it can handle the added load and grants or denies physical status, giving an error message if denied.

Point is, don't ever limit functionality based on land ownsership status on things that should be globally available to all users. Create better defense systems, not smaller feature sets. Knee jerk reaction is right, Kris!