DUPING solution MINIMALIST    OK  Nayte  - roughly this is it.. I suggest transportable containers instead of weapons, to cut down the lists overhead - but this system seems to me to work and requires the manipulation of ONE extra byte only for the object instances concerned. This will not burn out the server IMO or slow down the software or the game  =  In My View.  
Difficulty of programming.. ??  Maybe I can leave that open ?  There may be something I have NOT noticed that would make this difficult or impossible to implement ? it goes like this:
    *  *  *
       each object-X instance that spawns on the map has a definition. This is already the case - Central Loot Economy  
 definition =    {object} {condition} {coordinates}{..etc} that is : each instance of an object had "qualities" attached to it.. =  "where it is "- is it "pristine/damaged, etc"' - "how many bullets in the mag" - other "qualities" depending on the object that is instanced. ALL DayZ object instances that a player can interact with have a series of such qualities attached to them. This system of "qualities" is pretty robust.. maybe your .45 has vanished when you log in  or your whole pack has disappeared (that's a different problem) , but you never find that your "worn" kitchen knife is suddenly "pristine", & etc.. "qualities" stick pretty well with the instance they define, they don't get lost. If the instance is there, the "qualities" are there.   Now suppose we want to stop Duping.   Leave aside the CLE and public/private hives (we don't need to worry about those)   We can assign serial numbers to all transportable containers - backpacks, sea-chests, barrels - that can be carried by players between servers. How to do it simply is explained below.
 
   Add another term to the definition when the object-X instance spawns     =   {code}
   So that object-X instance definition becomes =  {object} {code} {condition} {coordiates} {..etc}    the "code" is made up from one word (64 bits should do it). Easy to parse. It contains :        =time (spawn-date/hour/second)=        =server number (or server IP)=        =serial number=        generating the time stamp and server number is trivial  (right?)
       the "serial number" is generated sequentially for each object that spawn on a single server, by the server.
       There is NO requirement for cross-referencing of any element withing the {code} integer, with other servers or with a central registry,  
 
       The "serial" can be assigned as many digits as convenient. When the server reaches the max serial number it begins again with zero.
       The time stamp and server number guarantee the string is unique and can never be confused with any other string generated on that server or   any other server - even if one single object-X instance stays "live" in play and moves between servers for years.
       There is no need to cross check with other servers as you have already included the server number and the time stamp with the serial number  {code}. So each {code} is KNOWN to be unique without verification, and cannot be duplicated
       On a single server, two object-X instances cannot be generated with the same serial number at the same moment.
             Whenever an object-X spawns it receives instance definition =  {object} {condition} {coordiates} {code}
       This {code} is only needed for transportable containers -IMO- as containers are used in Duping.        It could be extended if necessary, from this simplest structure. But I do not see that this is required.  
       *
              A player carrying object-x instance logs in to a server :        Say, he carries an instance of "backpack A" (plus maybe an oil-drum - or more than one container)
      
       We already have the list of object-x instances  on the server.  
       (we know the CLE already handles the math of instance in play & spawn, this information is locally available)
       Each instance on the server is listed at present as < object-X instance plus {coordinates} .. etc >  - this is true at present.        However, at instance spawn we have extended this list to < object-X instance plus {coordinates} plus {code} .. etc>
      The player logs in to a server with object-x instance  (backpack A) + (Sea-chest) ..       We KNOW what the player carries.
     
      We KNOW what object-x instance (backpack A) are already on this server
       
      Compare serial numbers       If two serial numbers match for object-x instances (backpack A)  - the instance held by the player is removed from the game.
      If two serial numbers match for object-x instances (oil-drum)        - the instance held by the player is removed from the game.    Even suppose player Alpha logs out with his backpack AND leaves his backpack on the server (dupes it) so that a friend  can pick it up for him and move it off that server .. thise two backpacks can never meet on any given server ever ..   And who's to say that BI use this system on backpacks.. maybe they could use it on automatic weapons instead..   So that would seriously mess woth duping as it exists - 100% - and would grtavemy HINDER and discourage more complex duping maneuvers.   I expect ti would end them. The simplicity of the system is that two servers never have to communicate with each other to check serial numbers. They only ever have to check the serials (case suggested) on containers carried by a player as he logs in to one server, against containers already on that server.
      One Question :
 
      From player login to completing a true/false numerical comparison of {code}s in the server's object-x instance list {codes} - only concerning containers carried by the player
      - how many clicks are required ?             xxp
@ImpulZ  ?