Per la seconda parte, è perchè la condizione non è presente nella TX stessa. Sarà oraclize a gestirla e inviare la TX quando questo si verifica.
Se per dire fosse presente nell'OP_RETURN lo vedresti sempre dal sito, tipo qui:
0100000001eb074d698689297deb402e21dbbb38c96db734ca38876ec43770e9d7a4e7e83b020000006c493046022100e406fd298b486ecf152e39e38a6b1b2bbf40943b117e61ba8ada62c1b896be9a022100cadcd8e5673f6a5612c5b068db65c269db10e27148dce12a8d6e4750d9e1bb5001210269dafaa957b4346c5436a70f0017d7e48b62ed97647503b2837017cf2db6108bffffffff0410270000000000001976a9143831d99f8ee7ae8f7a3986d83b89df03ca9e133c88ac58020000000000001976a9144a8f7f7b5129a52bbe21e94b7cc548bd019c967d88ac58474002000000001976a91414ec92b7e009786cdf1c2566746975111fc992c588ac0000000000000000166a144153435249424553504f4f4c524547495354455200000000
Se la metti vedi che, oltre i vari output, hai pure un OP_RETURN.
Credevo proprio che la condizione fosse registrata all'interno di uno script della transazione Grazie mille.
La condizione non e' registrata nell'OP_RETURN perche' i 40 bytes non basterebbero (e non a tutti potrebbe far piacere l'idea di includere "in chiaro" nella transazione la condizione che l'ha causata). In ogni caso su Oraclize il contenuto dell'OP_RETURN puo' essere definito dall'utente, che potrebbe per esempio includere un hash che rappresenti quindi in modo univoco il contratto in questione (se questo e' noto!).
Oraclize memorizza comunque una firma del contratto eseguita automaticamente client-side dall'utente in fase di creazione in modo tale da poter riverificare a posteriori che il contratto in questione non sia stato manipolato dal servizio (questo e' quello che accade quando si carica la pagina privata del contratto: viene riverificato client-side il matching del contratto e della sua firma, esempio di un contratto manipolato e non manipolato ; come potete vedere nel primo caso abbiamo un warning, nel secondo una conferma di integrita').