Difference between revisions of "Talk:LlTransferLindenDollars"

From Second Life Wiki
Jump to navigation Jump to search
Line 16: Line 16:


:I've moved it to [[Simple Piggy Bank]]. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 18:18, 5 January 2013 (PST)
:I've moved it to [[Simple Piggy Bank]]. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 18:18, 5 January 2013 (PST)
Example was bad as it had a hidden race condition flaw, prior to me adding the NULL_KEY check to the touch_start event, nothing prevented the user spamming clicks (spamming the touch_start event) and initiating a ton of transactions.  Since TransactionID was replaced on every transaction, as long as you can click faster than the responses come back (transactions with keys that dont match are ignored) you could drain the entire account.  Would obviously be best done via a bot avatar as you really want to get in "one click per frame" and hope you beat the speed of the transaction server.  Regardless of wether that situation is practically achivable leaving that possible account-emptying exploit in the program made this a very bad and dangerous example :(    (further note, due to event queue size I query how guaranteed you are to see the response, if the script is under attack, but this would just leave the modified script in a broken stuck state) [[User:Iain Maltz|Iain Maltz]] 10:14, 23 August 2013 (PDT)

Revision as of 09:14, 23 August 2013

corrected

<lsl>listOfTransactionRecords += [llTransferLindenDollars(id, amountGivenAwayOnClick) + id + amountGivenAwayOnClick];</lsl> should be <lsl>listOfTransactionRecords += [llTransferLindenDollars(id, amountGivenAwayOnClick) , id , amountGivenAwayOnClick];</lsl> and same a few lines after Sigma Avro 07:36, 11 April 2012 (PDT)

Concerns

I am concerned about the content of the llTransferLindenDollars page. There should be a simple example focussing on the subject of this page. The long application-style example may have a place elsewhere on the Wiki, but here? I'll try and produce such a sample later today, time permitting.

I'm also concerned about the comment "- because weird things happen in LSL when using more than one state". This needs substantiation or should be removed. I am not personally aware of any "weird things happening".

Is it appropriate for example scripts in the Wiki to be annotated with author's name, or editor's name. If we need to know that, we can always look in the page history. The Wiki should not be an advertising platform, even for individuals. While on that subject, is it appropriate for any scripts on the Wiki to have copyright statements? Surely all are covered by the standard Wiki terms. Some additional (c) clauses scattered around the Wiki are surely untenable and misleading, even on people's own pages on the Wiki. Omei Qunhua 02:41, 5 January 2013 (PST)

The original idea for that example script was to demonstrate how to retrofit an existing example from llGiveMoney. Course it would have helped if I had written that in description. -- Strife (talk|contribs) 18:10, 5 January 2013 (PST)
I've moved it to Simple Piggy Bank. -- Strife (talk|contribs) 18:18, 5 January 2013 (PST)

Example was bad as it had a hidden race condition flaw, prior to me adding the NULL_KEY check to the touch_start event, nothing prevented the user spamming clicks (spamming the touch_start event) and initiating a ton of transactions. Since TransactionID was replaced on every transaction, as long as you can click faster than the responses come back (transactions with keys that dont match are ignored) you could drain the entire account. Would obviously be best done via a bot avatar as you really want to get in "one click per frame" and hope you beat the speed of the transaction server. Regardless of wether that situation is practically achivable leaving that possible account-emptying exploit in the program made this a very bad and dangerous example :( (further note, due to event queue size I query how guaranteed you are to see the response, if the script is under attack, but this would just leave the modified script in a broken stuck state) Iain Maltz 10:14, 23 August 2013 (PDT)