This is a new one on me

The problem with that one is that if the servers could truly, reliably track the deliveries, we wouldn't need to check it in LSL in the first place.
Unless the LSL part was just the top of the iceberg for a major overhaul of the transaction system, the LSL "confirmation events" would be nothing but false sense of security, and possibly an even worse point of contention.

So many times in this forum, posters write that the majority of buyers are honest, which they are, but we've heard a few cases in this thread where people have tried to scam sellers - and I find it to be a refreshing change It's also good to know these things, in case it happens to us.

Yeah, I've puzzled over just how useful this may be. According to http://lslwiki.net/lslwiki/wakka.php?wakka=changed, the CHANGED_OWNER flag is raised:

* in the original object when a user buys the object.
* in the original object when a user buys a copy of the object.
* in the original object when a user takes the object or a copy of the object.
* in the newly-rezzed copy when the user rezzes the object for the first time. (on_rez() is still triggered first.) This occurs whether or not the object was copied or purchased.
* when an object is deeded to a group.

and *not* raised:

* in the original object when the user buys the contents of an object. It is still triggered in the copy when the new owner rezzes it.

So in this last scenario, the problem (already mentioned) of rezzing on no-script land could prevent report of "unpacking", making it seem the object wasn't delivered from something that gives its contents when "bought". For that matter, a scammer could just delay rezzing until the scam was over.

Even for the scenarios involving a simple "Buy" of an object, I'm really not sure if the event is triggered after possession is really taken (as one would hope) or if the event could possible be generated before a failure.

But it's my sense anyway that buying objects directly leads to a lot fewer non-delivery problems than Paying a scripted vendor that then does an llGiveInventory()--which is currently incapable of confirmation. (I haven't actually tried getting this event from vendor-delivered objects--I'm guessing the event would be raised in the delivered object when rezzed--the last scenario mentioned above. I'm hoping somebody will just tell us from experience; if not, I can hack something and get my alt to test.)

Thank you Qie.

It might have possibilites for cutting down on scams, as Kyoko's did for her, but she did it differently, and I think it needs to be used in boxed items.

It's interesting. If you don't cobble something for testing, I will, but I can't do anything for a few days as I'm busy as hell - unfortunately.

If this refund scam, is becomming a mainstream scam, then I would think it would be due to an influx of roving bands of professional online game farmers. seeing easy targets. Which seems the inevitable fate of Second Life as it is.

With so many SL errors and weaknesses, it's a perfect environment for scammers.

Confirmed. My shiftless alt bought something from an llGiveInventory vendor I made, and the CHANGED_OWNER event triggers only when that purchased item is rezzed.

That's a very good piece of information - thank you Qie. It can be useful to some extent, as people generally rez the stuff they bought quite quickly - at least with furniture. And, if the item has been rezzed, it sure as hell got delivered.

Say it isn't so!!

http://www.youtube.com/watch?v=YvJKV2f-yqA&feature=related

That was Electrifying! It gave me chills, and they are multiplying!

OMG! LOL! They (and I) were so young then.

lol my mom was telling me she had seen him way back in the late 70's at woodfield mall in illinois..i guess he was having some concert in the mall and the people went so crazy they rushed the stage tearing and ripping at his Elvis fringe suit..my mom got knocked down and said she was pretty mad that someone burnt her arm with a cigarette and that after all that she didn't get any part of the suit..he went on tv the next day saying he was sorry to everyone that got hurt..
did anyone else every hear about this back then?

It's possible to ensure that the entry gets added. It could be duplicated, but timestamps can sort that out.

In that case, the money can be misdelivered. Whatever happens last can be lost (either that, or duplicated).

Adding a confirm event in LSL would increase the complexity of scripts without (IMHO, and I'm not 100% sure) reducing the probability of this problem. This is why transaction journals exist. If it was possibly to code a solution for for this problem, banks would do it that way.

Well i've bought a few things where the unboxer contacts "home" first to obtain the item in question, maybe that's the way to go?

Why not just make it so that anything bought requires the user to accept it, even if from an object, and send back a blue notice that so and so has accepted your item?

OK, I'll try this one more time.

No matter how many levels of acknowledgement you have, the last one can get lost, or the one before it (in the opposite direction), and you can't ever, ever, ever, tell which.

You can find out if the last *round-trip* exchange failed (for example, things like question & answer, or money posted & object delivered). But you can't find out whether the question got dropped or the answer got dropped. Not possible. Not in theory, not in practice.

So, no matter how many levels of "assurance" you try to build in, there's always the *same* chance that the last one (or the one before it in the opposite direction) got lost, and you can't tell which.

So, adding more levels of acknowledgement doesn't increase robustness, and increases complexity.

If you want a way to fix this, ask for a means of retrieving that part of someone else's recent transaction history involving exchanges with you. Then you can find out, for sure, whether someone's pulling your leg or not.

(OK, the "for sure" is not 100%, because there's always the possibility of a catastrophic failure ... but it's to a very high degree of confidence, unlike the current system where you simply can't tell.)

This can help avoid certain these problems. If the person buys one and doesn't get it, you can give him another -- but then manually make sure that the delivery system doesn't honor more than one request from that buyer. Normally it would, in the case that they bought two copies. Of course, this would only protect you if your delivery system only delivers to the original buyer. If the delivery system allows xfer, then it would be harder to avoid the problem.

The problem with that is that the entry is usually added to the buyer's transaction history when the delivery fails.

When you hand someone an object directly, you get a $0 transaction on your Transaction History page. Couldn't LL add that for items delivered by objects? Have one transaction listed for the money transfer, and another for the object transfer. Then the Lindens should be able to review based on transaction numbers and see where the problem is. It would suck for a month or so until the scammers got caught and word got out that this method of stealing wasn't worth it anymore. Increased calls to support to look into potential fraud/nondelivery cases would highlight to LL how bad the asset server problem really is.

Right Phil, and the transaction history would need to be adjusted similarly to how Argos mentions to compensate for that. Ideally, the two entries for a single transaction (for money and object exchange) are both present, the normal transaction history should show them as a single exchange. The entry for object exchange would need to be posted only after successful object exchange. In this case, it would be possible to give the object but not post the transaction record, and in that case someone could ask for another object. But note that the recipient can't *force* that to happen, so it wouldn't be a viable means of trying to get something for nothing. Every now and then a very diligent theif might notice the missing transaction entry for an object they bought and received, but only in that case could they swindle you. As it is now, they can try any time they want, and that's what we want to avoid.

In other words, we can't make the system foolproof. But we can make it so that this kind of theft isn't practical, and that's what we should focus on.

And it shouldn't take a call to Lindens to sort out. Fankly, it wouldn't even require being able to see the other party's transaction record, as long as object transfers *from* you are logged reliably (reliably in the technical sense used in communications, meaning, you're notified if it succeeds, but if it fails you can't tell exactly which part failed: the history addition or the confirmation of the history addition).

To my way of thinking, something like this would work ...

Receive an instruction to transfer the item form person A to person B, and to deduct an amount of L$ from person B.

Get person B's L$ balance, and the date-time of the newest identical item in person B's inventory. Then take B's L$.

Get B's L$ balance and, if it is reduced by the right amount, put the item into B's inventory.

Get the date-time of the newest identical item that is in B's inventory and, if it's newer than the previous newest, send a message to B according to the result. Record the success or failure of the transaction for the seller (A).


It's checking B's inventory before and after the operation that is different. Something like that would check the buyer's inventory for the item, which is where the success or failure is. If the record shows a success, then the system found the item in the buyer's inventory, and non-delivery scams would be decimated. The system already shows whether or not the money was taken and received - it's only whether or not the item made it into the buyer's inventory that's in doubt. It could also work for the giving of items, with the L$ part skipped.

It could fail after the item has been confirmed to be in B's inventory, and before the message is sent to A, or before the record is made for B, but it would enable sellers to check the success/failure of deliveries for enough of the transactions to treat the records as gospel.

A simple addition to the existing way of doing transactions could be added easily...

In many cases, the buyer is informed that something went wrong, even though their money is taken. So the system knows that it didn't go through, and a record of the failure could be made for the seller. That simple measure would confirm many of the failed deliveries for sellers, so that they need have no doubts in those cases.

So many people are scamming out there. I would send her another couch set to no copy and transfer enabled. Then tell her to sell it in a yard sell if she no longer wanted it.
This doesn't sound like a customer you'd retain anyway.