tx.origen para la fábrica

Quiero usar una fábrica para que la gente pueda crear un contrato estandarizado. Las personas deberían poder transferir dinero directamente mediante esta creación, lo que me llevó al problema del msg.sender durante la ejecución. Leí que tx.origin tiene algunas fallas de seguridad, pero me pregunto si esto también es cierto solo para la creación de contratos por parte de una fábrica. siguiente contrato de ejemplo:

 pragma solidity ^0.4.0;

    contract Factory {

     address[] public contracts;

       function createContract () 
          payable 
          public 
       {
          Con newCon = (new Con).value(msg.value)();
          contracts.push(newCon);
       }

    }


    contract Con { 

     address owner;
     uint256 valueOwner
;

     function Con() 
        payable 
        public 
     { 
        owner = tx.origin;
        valueOwner = msg.value;
     } 

       function withdraw () 
          public
       {
          if(msg.sender == owner)
             msg.sender.transfer(valueOwner);
       }

    }

No veo por qué tx.origin debería hacer algún daño aquí o me estoy perdiendo algún punto.

Respuestas (1)

El uso tx.origincreará problemas cuando se llame a la fábrica desde otro contrato.

Monedero (A) llamadas > contrato multisig (B) > que llama a tu fábrica (C) > subcontrato (D).

En este caso, el origen de tx es la billetera A. En la mayoría de los casos, los usuarios esperarán que el propietario sea en realidad el contrato multisig B, y no A.

Para evitar esto, solo use msg.sender en la fábrica C y páselo a la nueva instancia de contrato D, preferiblemente en una segunda llamada de método para que las personas puedan usar fácilmente el validador de código etherscan sin parámetros de constructor.

Esto no parece ser una falla de seguridad sino más bien un inconveniente para el usuario. Pero como menciona la verificación a través de etherscan, el usuario podría hacer una verificación de la función createContract() de la fábrica y el código constructor de Con, ¿no?
No es una falla de seguridad, está funcionando según lo previsto. La principal limitación a la hora de diseñar un nuevo "contrato inteligente" debe ser la coherencia. Sus usuarios no tienen idea de la diferencia entre tx.origin y msg.sender, y probablemente nunca la tendrán.