Oraclize.it - smart contracts, today

[Randagio]

  sei un grande!
Adesso mi mancano solo le condizioni multiple da applicare allo stesso url json e poi sono a posto 

[bertani]

Adesso mi mancano solo le condizioni multiple da applicare allo stesso url json e poi sono a posto 

[bertani]

La piattaforma e' stata lanciata ufficialmente oggi!

L'altra news e' che il 24 Marzo scorso ho costituito Oraclize srl (con l'assistenza di Stefano Capaccioli e alla presenza del notaio Giacomo Pieraccini), la prima società italiana (e seconda in Europa) con conferimento di capitale sociale in bitcoin (come visionabile dalla transazione con id 756ca57287aadcb2d332b45e27035a41d52aa802757f0e1210482208a39297c6, inclusa nel blocco 349007).

• Atto costitutivo
• Perizia di stima dei Bitcoin versati

[TheBomber999]

la prima società italiana (e seconda in Europa) con conferimento di capitale sociale in bitcoin

Complimenti per la scelta coraggiosa e rivoluzionaria.
Da ora in avanti quindi l'agenzia delle entrate dovrà forzatamente prendere dimestichezza coi bitcoin.

[Randagio]

Complimenti Bertani!

E grazie per aver esaudito tutte le mie richieste. Ci sto ancora giocando, anche se non sembra.
A beve ti scrivo per alcune info sulle eventuali API, per una piccola idea che ho in mente.

[arulbero]

I contratti creati su Oraclize sono visibili solo da chi li ha creati? Osservo che in "check status" si vede solo se le condizioni sono verificate o no, ma non si vedono le altre caratteristiche della transazione: indirizzi di input, indirizzi di output, quantità inviate.

Stavo pensando a un caso di questo tipo: voglio acquistare una quantità importante di btc da un mio venditore di fiducia del forum. Data l'entità della transazione (mettiamo 4000 euro) pago tramite bonifico. Il venditore ovviamente aspetterà gli 1-2 giorni canonici necessari per l'accredito prima di inviarmi i btc.
Io mi fido del fatto che sia una persona onesta (e che quindi non mi voglia imbrogliare) ma non posso/voglio fidarmi di qualcosa che nessun essere umano può garantire: del fatto che tra 2 giorni sarà ancora vivo/in grado (fisicamente/mentalmente) di adempiere alla sua promessa. So che può sembrare un caso molto improbabile, ma quando si tratta con un singolo individuo piuttosto che con un gruppo di persone, se succede qualcosa a questo chi può rispondere per lui? Soprattutto quando si parla di cifre così elevate, le precauzioni non sono mai troppe.

Allora le soluzioni sarebbero:

1) il venditore immediatamente mi invia una transazione firmata con nlocktime e sequence number modificati, in modo che qualunque cosa succeda tra 5 giorni io entrerò sicuramente in possesso dei miei btc; fino ad allora lui potrà spendere gli input della transazione che mi ha inviato (di fatto annullandola) se non riceve in tempo i soldi del mio bonifico
2) creare un contratto su Oraclize che faccia la stessa cosa

Nel caso 1) vedo due problemi: intervenire manualmente su una transazione non è semplicissimo per il venditore (è facile commettere errori) e soprattutto non è facile neanche per me cliente che ricevo la transazione verificare subito che sia tutto in ordine (non è banale leggere una raw transaction); inoltre a tempo debito devo trasmettere io la transazione alla rete (anche se questa è la parte più facile)
Nel caso 2) per il venditore c'è il vantaggio della costruzione guidata e quindi meno soggetta a errori della transazione, per me cliente c'è il vantaggio che è più facile leggere questo tipo di contratto e che non devo trasmettere io la transazione alla rete. Mi manca però da capire in che modo il venditore può mostrarmi questa transazione dal momento che "fisicamente" non possiede lui il file.

In sostanza ripeto la domanda: è possibile per il venditore creare un contratto e renderlo visibile a un proprio cliente nella forma chiara con cui compare nel sito?

EDIT:
Ho provato a creare un contratto su Oraclize mettendomi nella parte del venditore.
Contract ID dfaf064d71c994d6a8b556baab9754f6
Se inserisco questo ID visualizzo correttamente la condizione "[WolframAlpha] 'time in Rom' > 12:00" che al momento è falsa.
Se cambio idea posso rimuovere i fondi dall'indirizzo multisig fornitomi da Oraclize andando in "Tools -> Funds Recovery".
Durante la procedura di creazione del contratto è possibile visualizzare e copiare la transazione in formato hex, quindi è possibile eventualmente farla vedere a un'altra persona. L'unico modo che ho trovato però per visualizzarne i dettagli è inserire la transazione qui.

In pratica non mi sembra che sia possibile visualizzare in formato "più chiaro" possibile l'intero contratto su Oraclize, ma solo la sua condizione.

EDIT2: alle 12:06 è stato fatto un controllo e la domanda [WolframAlpha] 'time in Rom' dà correttamente come risposta "12:06:11 pm CEST | Wednesday, April 1, 2015" ma risulta ancora falsa la condizione espressa dalla disuguaglianza 'time in Rom > 12:00' (no match). Ho fatto qualche errore?  


EDIT3: ogni volta che accedo al sito o cambio pagina mi esce questo fastidioso messaggio

Ci si sta autenticando sul sito “www.oraclize.it” con nome utente “oraclized” ma il sito non richiede autenticazione.
Potrebbe trattarsi di un tentativo di truffa.
“www.oraclize.it” è il sito che si desidera visitare?

Mi pare che succeda solo quando ci arrivo tramite il link del primo post.

EDIT4: al momento (ore 18:00) il sito è down, vediamo se il nuovo contratto che ho fatto (bitcoin block height > 350250) funziona in ogni caso. Ha funzionato!! 

[HostFat]

Ho cambiato il link al primo post togliendo i dati di accesso

[alch1mista]

Figata, non ci credevo finché non l'ho visto che sarebbe esistita una società con capitale sociale interamente in bitcoin.

[jkoin]

Ma un possibile use-case potrebbe essere un sito di scommesse automatico su eventi sportivi?

[acquafredda]

Figata, non ci credevo finché non l'ho visto che sarebbe esistita una società con capitale sociale interamente in bitcoin.

In Italia poi!

[bertani]

I contratti creati su Oraclize sono visibili solo da chi li ha creati? Osservo che in "check status" si vede solo se le condizioni sono verificate o no, ma non si vedono le altre caratteristiche della transazione: indirizzi di input, indirizzi di output, quantità inviate.

I contratti creati su Oraclize tipicamente sono "pubblici", questo significa che le condizioni verificate sono visibili pubblicamente da qui. I contratti creati come "privati" non risultano invece in quella lista e il loro stato e' visibile quindi solo dalla pagina privata del contratto (conoscendone l'ID quindi), esempio: https://www.oraclize.it/contracts/checkstatus/dfaf064d71c994d6a8b556baabf6d025 .

Stavo pensando a un caso di questo tipo: voglio acquistare una quantità importante di btc da un mio venditore di fiducia del forum. Data l'entità della transazione (mettiamo 4000 euro) pago tramite bonifico. Il venditore ovviamente aspetterà gli 1-2 giorni canonici necessari per l'accredito prima di inviarmi i btc.
Io mi fido del fatto che sia una persona onesta (e che quindi non mi voglia imbrogliare) ma non posso/voglio fidarmi di qualcosa che nessun essere umano può garantire: del fatto che tra 2 giorni sarà ancora vivo/in grado (fisicamente/mentalmente) di adempiere alla sua promessa. So che può sembrare un caso molto improbabile, ma quando si tratta con un singolo individuo piuttosto che con un gruppo di persone, se succede qualcosa a questo chi può rispondere per lui? Soprattutto quando si parla di cifre così elevate, le precauzioni non sono mai troppe.

Allora le soluzioni sarebbero:

1) il venditore immediatamente mi invia una transazione firmata con nlocktime e sequence number modificati, in modo che qualunque cosa succeda tra 5 giorni io entrerò sicuramente in possesso dei miei btc; fino ad allora lui potrà spendere gli input della transazione che mi ha inviato (di fatto annullandola) se non riceve in tempo i soldi del mio bonifico
2) creare un contratto su Oraclize che faccia la stessa cosa

Nel caso 1) vedo due problemi: intervenire manualmente su una transazione non è semplicissimo per il venditore (è facile commettere errori) e soprattutto non è facile neanche per me cliente che ricevo la transazione verificare subito che sia tutto in ordine (non è banale leggere una raw transaction); inoltre a tempo debito devo trasmettere io la transazione alla rete (anche se questa è la parte più facile)
Nel caso 2) per il venditore c'è il vantaggio della costruzione guidata e quindi meno soggetta a errori della transazione, per me cliente c'è il vantaggio che è più facile leggere questo tipo di contratto e che non devo trasmettere io la transazione alla rete. Mi manca però da capire in che modo il venditore può mostrarmi questa transazione dal momento che "fisicamente" non possiede lui il file.

In sostanza ripeto la domanda: è possibile per il venditore creare un contratto e renderlo visibile a un proprio cliente nella forma chiara con cui compare nel sito?

E' tutto corretto, per fare quello che dici basta fornire il link alla pagina privata di stato del contratto, come l'esempio sopra.

EDIT:
Ho provato a creare un contratto su Oraclize mettendomi nella parte del venditore.
Contract ID dfaf064d71c994d6a8b556baab9754f6
Se inserisco questo ID visualizzo correttamente la condizione "[WolframAlpha] 'time in Rom' > 12:00" che al momento è falsa.
Se cambio idea posso rimuovere i fondi dall'indirizzo multisig fornitomi da Oraclize andando in "Tools -> Funds Recovery".
Durante la procedura di creazione del contratto è possibile visualizzare e copiare la transazione in formato hex, quindi è possibile eventualmente farla vedere a un'altra persona. L'unico modo che ho trovato però per visualizzarne i dettagli è inserire la transazione qui.

In pratica non mi sembra che sia possibile visualizzare in formato "più chiaro" possibile l'intero contratto su Oraclize, ma solo la sua condizione.

Ho aggiunto questa mattina sulla pagina privata di stato del contratto una anteprima "a grafo" della transazione coinvolta, dovrebbe bastare   

EDIT2: alle 12:06 è stato fatto un controllo e la domanda [WolframAlpha] 'time in Rom' dà correttamente come risposta "12:06:11 pm CEST | Wednesday, April 1, 2015" ma risulta ancora falsa la condizione espressa dalla disuguaglianza 'time in Rom > 12:00' (no match). Ho fatto qualche errore?  

Avevo visto il tuo contratto, purtroppo non e' formalmente valido e non potra' mai verificarsi perche' il confronto numerico (">" e "<") funzionano solo con argomenti numerici ("12:00" non e' un numero, ma una stringa). Il form di creazione del contratto avrebbe dovuto accorgersi della cosa e avvertirti, ma c'era un bug (ora sistemato) che ti ha fatto continuare comunque..

ps: avresti dovuto scrivere "time in Rome", ma Wolfram ha capito lo stesso che intendevi Roma anche con "Rom".
ps2: per verificare l'orario ti consiglio di utilizzare o un confronto sul timestamp, o "hours from now to <date&time>" o con data-source blockchain puoi usare "bitcoin blockchain height" come faresti con nlocktime 

EDIT3: ogni volta che accedo al sito o cambio pagina mi esce questo fastidioso messaggio

Ci si sta autenticando sul sito “www.oraclize.it” con nome utente “oraclized” ma il sito non richiede autenticazione.
Potrebbe trattarsi di un tentativo di truffa.
“www.oraclize.it” è il sito che si desidera visitare?

Mi pare che succeda solo quando ci arrivo tramite il link del primo post.

Si' Hostfat ha corretto il vecchio url (che includeva i dati per la webauth) che avevo lasciato nel primo post, quindi non dovresti piu' avere alcun warning!

[bertani]

Giusto per riferimento:

• Post su reddit
• Thread sezione internazionale

[arulbero]

I contratti creati su Oraclize tipicamente sono "pubblici", questo significa che le condizioni verificate sono visibili pubblicamente da qui. I contratti creati come "privati" non risultano invece in quella lista e il loro stato e' visibile quindi solo dalla pagina privata del contratto (conoscendone l'ID quindi), esempio: https://www.oraclize.it/contracts/checkstatus/dfaf064d71c994d6a8b556baabf6d025 .

... per fare quello che dici basta fornire il link alla pagina privata di stato del contratto, come l'esempio sopra.

Ho aggiunto questa mattina sulla pagina privata di stato del contratto una anteprima "a grafo" della transazione coinvolta, dovrebbe bastare   

Perfetto, ora è molto più leggibile, grazie!

Avevo visto il tuo contratto, purtroppo non e' formalmente valido e non potra' mai verificarsi perche' il confronto numerico (">" e "<") funzionano solo con argomenti numerici ("12:00" non e' un numero, ma una stringa). Il form di creazione del contratto avrebbe dovuto accorgersi della cosa e avvertirti, ma c'era un bug (ora sistemato) che ti ha fatto continuare comunque..

Felice di aver contribuito a scovare un bug 

[bertani]

Post interessante riguardo alla verifica client-side dell'integrita' del contratto: https://bitcointalk.org/index.php?topic=1009253.msg10967820#msg10967820

[bertani]

Vi segnalo la mia partecipazione come speaker a Legal Tech Forum, parlero' di blockchain e smart contracts 

[arulbero]

... è 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.

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').

Ma la firma client-side è una firma effettuata con una delle due chiavi private dell'utente? Dov'è che viene conservata questa firma, sul pc del cliente o su Oraclize?

[bertani]

... è 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.

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').

Ma la firma client-side è una firma effettuata con una delle due chiavi private dell'utente? Dov'è che viene conservata questa firma, sul pc del cliente o su Oraclize?

La firma del contratto e' effettuata client-side durante la fase di creazione del contratto con la prima delle due chiavi privati dell'utente, la firma viene poi salvata server-side e ricomunicata (e quindi riverificata client-side!) ad ogni caricamento della pagina privata del contratto. In questo modo l'utente puo' verificare che il contratto visualizzato coincide con quello che aveva indicato nella fase di creazione dello stesso.

[arulbero]

Ancora una domanda (lo so, sono un po' rompiscatole).

Io posso quindi verificare in ogni istante che il contratto non sia stato manipolato da Oraclize, ma c'è un controllo automatico che verifichi che sussista la condizione principale affinchè una qualsiasi transazione possa essere eseguita?  Per condizione principale intendo qui ovviamente non quella monitorata dal servizio ma il fatto che una qualsiasi transazione, per essere non solo trasmessa alla rete ma anche accettata, deve presentare un corretto riferimento agli output non spesi della transazione che in precedenza ha portato i btc dal mio portafoglio all'indirizzo fornito da Oraclize.

Mi spiego meglio: quando ho effettuato qualche prova, ho notato che per impostare il tutto il sistema Oraclize si basa su una transazione A non confermata che muove dei fondi dal mio personale portafoglio a un indirizzo multisig proposto da Oraclize. Ipotizziamo che io crei un contratto B su Oraclize che prevede di spendere gli output della mia transazione A non confermata, e che, subito dopo, un buontempone modifichi leggermente la mia transazione originale non confermata A in modo da modificarne solamente l'hash (transaction malleability) e che invii quindi alla rete anche questa transazione A'. Se per sfortuna la rete dovesse includere in un blocco e confermare prima la transazione A', la transazione A non verrà mai più confermata. I miei fondi saranno comunque trasferiti dal mio personale portafoglio sull'indirizzo multisig di Oraclize, quindi io probabilmente non mi accorgerei che questi fondi, pur essendo effettivamente stati inviati all'indirizzo corretto, non sono in realtà spendibili mediante il contratto B poichè il contratto B non è in grado di riferirsi a essi e quindi non potrà mai essere eseguito.

In poche parole, se ho capito bene, il servizio mi garantisce solo che una certa transazione verrà trasmessa alla rete al verificarsi di un determinato evento, ma non mi garantisce che al momento in cui si verificherà quell'evento quella transazione avrà effettivamente a disposizione i fondi stabiliti al momento della stipula del contratto.
Quest'ultimo fatto va bene finchè lascia la libertà all'utente di ripensarci e ritirare in anticipo i propri fondi senza dover annullare manualmente il contratto (lo annullerebbe così in modo implicito), ma di certo non va bene se l'intera procedura si basasse su una transazione non confermata.

Ovviamente voglio capire se le cose stanno veramente così, o magari ho capito male io.

[bertani]

Ancora una domanda (lo so, sono un po' rompiscatole).

Io posso quindi verificare in ogni istante che il contratto non sia stato manipolato da Oraclize, ma c'è un controllo automatico che verifichi che sussista la condizione principale affinchè una qualsiasi transazione possa essere eseguita?  Per condizione principale intendo qui ovviamente non quella monitorata dal servizio ma il fatto che una qualsiasi transazione, per essere non solo trasmessa alla rete ma anche accettata, deve presentare un corretto riferimento agli output non spesi della transazione che in precedenza ha portato i btc dal mio portafoglio all'indirizzo fornito da Oraclize.

Mi spiego meglio: quando ho effettuato qualche prova, ho notato che per impostare il tutto il sistema Oraclize si basa su una transazione A non confermata che muove dei fondi dal mio personale portafoglio a un indirizzo multisig proposto da Oraclize. Ipotizziamo che io crei un contratto B su Oraclize che prevede di spendere gli output della mia transazione A non confermata, e che, subito dopo, un buontempone modifichi leggermente la mia transazione originale non confermata A in modo da modificarne solamente l'hash (transaction malleability) e che invii quindi alla rete anche questa transazione A'. Se per sfortuna la rete dovesse includere in un blocco e confermare prima la transazione A', la transazione A non verrà mai più confermata. I miei fondi saranno comunque trasferiti dal mio personale portafoglio sull'indirizzo multisig di Oraclize, quindi io probabilmente non mi accorgerei che questi fondi, pur essendo effettivamente stati inviati all'indirizzo corretto, non sono in realtà spendibili mediante il contratto B poichè il contratto B non è in grado di riferirsi a essi e quindi non potrà mai essere eseguito.

In poche parole, se ho capito bene, il servizio mi garantisce solo che una certa transazione verrà trasmessa alla rete al verificarsi di un determinato evento, ma non mi garantisce che al momento in cui si verificherà quell'evento quella transazione avrà effettivamente a disposizione i fondi stabiliti al momento della stipula del contratto.
Quest'ultimo fatto va bene finchè lascia la libertà all'utente di ripensarci e ritirare in anticipo i propri fondi senza dover annullare manualmente il contratto (lo annullerebbe così in modo implicito), ma di certo non va bene se l'intera procedura si basasse su una transazione non confermata.

Ovviamente voglio capire se le cose stanno veramente così, o magari ho capito male io.

Quanto dici e' esatto, in particolare l'utente deve/puo' prendersi cura di assicurarsi che gli input che sta spendendo nella partially unsigned tx abbiano sufficienti conferme.
Se si decidesse per esempio di far possedere 1 sola delle 3 chiavi del wallet 2-of-3 all'utente in questione, non ci sarebbe alcun rischio che i fondi in questione non ci siano piu' presenti in quanto l'utente non potrebbe (con la sua sola chiave) spostarli.

[picchio]

Ciao
credete che oraclize possa essere utilizzato per offrire un servizio aggiuntivo a indiegogo per le campagne di crowdfunding? Magari c'e' gia' ... in caso datemi info in merito....

Provo a spiegarmi, parallelamente alla campagna si da la possibilità di offrire BTC con due opzioni (due address differenti ad esempio), in uno si lega la donazione all'ottenimento del finanziamento su indiegogo e l'oracolo controlla che la campagna sia stata finanziata, in caso negativo i fondi tornano indietro, altra opzione, se un tot di tempo prima della scadenza la campagna non ha oltrepassato la soglia si cambiano i btc e si finanzia la campagna fino all'ottenimento del fondo.