Bitcoin Forum
November 09, 2024, 06:29:38 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Servizio per visualizzare le transazioni non trasmesse?  (Read 882 times)
arulbero (OP)
Legendary
*
Online Online

Activity: 1938
Merit: 2080


View Profile
April 01, 2015, 09:45:37 AM
 #1

Esiste un servizio che permetta di visualizzare in maniera chiara tutti gli elementi fondamentali di una transazione prima che questa venga inviata alla rete?

Finora ho trovato questo, ma è una decodifica secondo me ancora non alla portata di tutti.

La situazione a cui sto pensando: se io ad esempio creo una transazione un po' complessa, con nlocktime modificato, oppure con una condizione tipo contratto su Oraclize, e volessi farla vedere alla controparte perchè controlli che sia tutto in ordine, come faccio?
Almeno nelle transazioni già inviate in rete su blockchain.info si vedono chiaramente indirizzi di input, di output, e quantità inviate.

davvo
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500



View Profile
April 01, 2015, 09:49:40 AM
 #2

https://coinb.in/#verify

Vedi le TX di input, gli indirizzi di output e la quantità esatta, oltre al fatto che verifichi se è già firmata o no come transazione.
arulbero (OP)
Legendary
*
Online Online

Activity: 1938
Merit: 2080


View Profile
April 01, 2015, 09:58:04 AM
 #3

https://coinb.in/#verify

Vedi le TX di input, gli indirizzi di output e la quantità esatta, oltre al fatto che verifichi se è già firmata o no come transazione.

Grazie. Non vedo però 2 cose:

1) un controllo per vedere se l'input è già stato speso o no

2) se inserisco questa transazione che ho creato su Oraclize

01000000018e30d350f09f9c80d0b4c9b058fd58fb015cc6095e7ab1efed10b96e7a80e97a01000 000b500483045022100cf0a7582bd0995cef277d16633d757c4fccb3e9fbcf68e995f851788f896 98f5022021aa2bca14665d6d2745ca473262d96fa535fe582f70a3fed4e7f6a4c9c84d14014c695 221031ad3887e76f50116fec30ab6fc9b871d9e605db639cf3b0b23aa5b67863312b8210342f233 44876c627901d9d79674b1e127e224e9aace83239cfdc4d97fc17f5ff82103f8d58684c90844469 9d85f62bc2884f6104c6bc001ed19fa8902c6f171760b9953aeffffffff01803801000000000019 76a914a88324a4ac0d1f3c0d41f77bbee915fe68ba336488ac00000000

non vedo la condizione sotto la quale deve essere spedita --> "[WolframAlpha] 'time in Rom' > 12:00".
davvo
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500



View Profile
April 01, 2015, 10:28:20 AM
 #4

Per la prima parte è vero, il discorso è che è un controllo che viene fatto dai miner quando invii la TX, di per se nella TX in se non esiste, quindi tutti i decodifer non lo vedono. Sarebbe un controllo da fare lato programma che fa la decodifica, ma non conosco siti che lo facciano.

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:

Code:
0100000001eb074d698689297deb402e21dbbb38c96db734ca38876ec43770e9d7a4e7e83b020000006c493046022100e406fd298b486ecf152e39e38a6b1b2bbf40943b117e61ba8ada62c1b896be9a022100cadcd8e5673f6a5612c5b068db65c269db10e27148dce12a8d6e4750d9e1bb5001210269dafaa957b4346c5436a70f0017d7e48b62ed97647503b2837017cf2db6108bffffffff0410270000000000001976a9143831d99f8ee7ae8f7a3986d83b89df03ca9e133c88ac58020000000000001976a9144a8f7f7b5129a52bbe21e94b7cc548bd019c967d88ac58474002000000001976a91414ec92b7e009786cdf1c2566746975111fc992c588ac0000000000000000166a144153435249424553504f4f4c524547495354455200000000

Se la metti vedi che, oltre i vari output, hai pure un OP_RETURN.
arulbero (OP)
Legendary
*
Online Online

Activity: 1938
Merit: 2080


View Profile
April 01, 2015, 10:35:13 AM
 #5

Per la prima parte è vero, il discorso è che è un controllo che viene fatto dai miner quando invii la TX, di per se nella TX in se non esiste, quindi tutti i decodifer non lo vedono. Sarebbe un controllo da fare lato programma che fa la decodifica, ma non conosco siti che lo facciano.

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:

Code:
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 Roll Eyes  Grazie mille.

bertani
Legendary
*
Offline Offline

Activity: 1022
Merit: 1000



View Profile
April 03, 2015, 06:34:46 AM
 #6

Per la prima parte è vero, il discorso è che è un controllo che viene fatto dai miner quando invii la TX, di per se nella TX in se non esiste, quindi tutti i decodifer non lo vedono. Sarebbe un controllo da fare lato programma che fa la decodifica, ma non conosco siti che lo facciano.

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:

Code:
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 Roll Eyes  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').
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!