|
Title: Creare transazione con "ritardo" Post by: bit3000 on January 23, 2015, 10:30:26 AM Dunque, la mia domanda è questa:
è possibile effettuare una transazione da un indirizzo A a un indirizzo B imponendo però che i bitcoin ricevuti su B possano essere spesi solo oltre una certa data? Documentandomi in giro ho scoperto che sembra essere possibile, vedere i seguenti link: http://bitcoin.stackexchange.com/questions/5783/transactions-with-a-wait-time-using-nlocktime https://bitcointalk.org/index.php?topic=131443.0 In pratica bisogna impostare il parametro "time-lock" all'interno della transazione, ma tutti i client "standard" non permettono di farlo. Bisogna invece crearsi manualmente una transazione, tramite una "raw transaction". Quello che non ho ben capito è come si fa a creare questa "raw transaction". In un thread che ho linkato dicono di aver usato bitcoind, che da quel che ho capito è una versione su riga di comando del client standard. Dato che non ho voglia di scaricare tutta la blockchain volevo sapere se c'erano altri client in grado di effettuare una "raw transaction". Ah, avviso tutti quelli che vogliano cimentarsi in questa impresa che agire manualmente sulle transazioni è abbastanza pericoloso, ad esempio se si hanno 5 btc nel wallet e si prova ad inviare manualmente 1btc, se ci si dimentica di settare manualmente la txfee si rischia di spendere tutti i restanti 4btc come fee! Quindi insomma, stateci attenti 8). Io ad esempio pensavo di usare come prova un indirizzo con pochi mbtc. Sempre in uno dei due link qui sopra hanno usato invece una "test net", cioè una specie di blockchain parallela usabile per fare dei test, anche questa alternativa non sarebbe affatto male. Come ultima cosa volevo chiedervi se possono esserci dei pericoli nel fare una simile transazione, ad esempio in uno dei link qui sopra si parla di problemi nel caso di un eventuale hard fork. Bene, spero che ora qualche "esperto" del protocollo bitcoin mi risponderà 8) Grazie in anticipo per l'aiuto :) Title: Re: Creare transazione con "ritardo" Post by: gbianchi on January 23, 2015, 11:51:50 AM In pratica bisogna impostare il parametro "time-lock" all'interno della transazione, ma tutti i client "standard" non permettono di farlo. Bisogna invece crearsi manualmente una transazione, tramite una "raw transaction". Quello che non ho ben capito è come si fa a creare questa "raw transaction". In un thread che ho linkato dicono di aver usato bitcoind, che da quel che ho capito è una versione su riga di comando del client standard. Dato che non ho voglia di scaricare tutta la blockchain volevo sapere se c'erano altri client in grado di effettuare una "raw transaction". Io uso un'utility che si chiama sx che ti permette di comporre lo script della transazione, e poi firmarlo e infine farne il broadcast in rete. https://github.com/spesmilo/sx Il bello e' che puoi farci praticamente di tutto, i brutto e' che e' molto low level, quindi devi conoscere una marea di dettagli del protocollo. Title: Re: Creare transazione con "ritardo" Post by: bit3000 on January 23, 2015, 04:46:23 PM Io uso un'utility che si chiama sx che ti permette di comporre lo script della transazione, e poi firmarlo e infine farne il broadcast in rete. https://github.com/spesmilo/sx Il bello e' che puoi farci praticamente di tutto, i brutto e' che e' molto low level, quindi devi conoscere una marea di dettagli del protocollo. Molto interessante, ma forse un po' troppo complicato per me. Ho scoperto che si può fare la stessa cosa con la funzione "transaction" di brainwallet, basta modificare manualmente il campo "lock_time". Ho fatto una piccola transazione di prova: https://blockchain.info/it/tx/a2253887139157aff378db10bf10caca1797f6cf2358789d3771842499700181 dovrebbe essere inclusa nei blocchi non prima del blocco n.340205 (cioè tra circa un'ora). Title: Re: Creare transazione con "ritardo" Post by: FaSan on January 23, 2015, 06:02:55 PM Io uso un'utility che si chiama sx che ti permette di comporre lo script della transazione, e poi firmarlo e infine farne il broadcast in rete. https://github.com/spesmilo/sx Il bello e' che puoi farci praticamente di tutto, i brutto e' che e' molto low level, quindi devi conoscere una marea di dettagli del protocollo. Molto interessante, ma forse un po' troppo complicato per me. Ho scoperto che si può fare la stessa cosa con la funzione "transaction" di brainwallet, basta modificare manualmente il campo "lock_time". Ho fatto una piccola transazione di prova: https://blockchain.info/it/tx/a2253887139157aff378db10bf10caca1797f6cf2358789d3771842499700181 dovrebbe essere inclusa nei blocchi non prima del blocco n.340205 (cioè tra circa un'ora). Il problema di BrainWallet (e cmq di tutti i siti che offrono possibilità simili) è che, chiaramente, devi inserire la tua chiave privata. Già fare solo il "copia" crea un grosso buco di sicurezza, visto che la tua chiave diventa visibile a chiunque possa accedere al tuo pc, virus e trojan compresi. Se poi passiamo al secondo step, ovvero l' incolla su un sito web, qui diventa davvero da brivido. :) FaSan Title: Re: Creare transazione con "ritardo" Post by: bit3000 on January 23, 2015, 06:24:20 PM Il problema di BrainWallet (e cmq di tutti i siti che offrono possibilità simili) è che, chiaramente, devi inserire la tua chiave privata. Già fare solo il "copia" crea un grosso buco di sicurezza, visto che la tua chiave diventa visibile a chiunque possa accedere al tuo pc, virus e trojan compresi. Se poi passiamo al secondo step, ovvero l' incolla su un sito web, qui diventa davvero da brivido. :) In effetti ci avevo pensato anch'io, servirebbe qualcosa di più sicuro. Comunque sia sembra che il timelock non abbia funzionato :(, la transazione è stata inclusa nel blocco 340200. Però in uno dei post che ho linkato c'è scritto "if all the inputs have a UINT_MAX sequence number then lockTime is ignored". Avete idea di cosa sia UINT_MAX e di come settarlo? Title: Re: Creare transazione con "ritardo" Post by: FaSan on January 23, 2015, 06:31:58 PM Il problema di BrainWallet (e cmq di tutti i siti che offrono possibilità simili) è che, chiaramente, devi inserire la tua chiave privata. Già fare solo il "copia" crea un grosso buco di sicurezza, visto che la tua chiave diventa visibile a chiunque possa accedere al tuo pc, virus e trojan compresi. Se poi passiamo al secondo step, ovvero l' incolla su un sito web, qui diventa davvero da brivido. :) In effetti ci avevo pensato anch'io, servirebbe qualcosa di più sicuro. Comunque sia sembra che il timelock non abbia funzionato :(, la transazione è stata inclusa nel blocco 340200. Però in uno dei post che ho linkato c'è scritto "if all the inputs have a UINT_MAX sequence number then lockTime is ignored". Avete idea di cosa sia UINT_MAX e di come settarlo? cito : Quote Sequence numbers are intended to be used for replacement. Replacement is currently disabled, but how it would work is: - You send a transaction with a LockTime in the future and a sequence number of 0. The transaction is then not considered by the network to be "final", and it can't be included in a block until the specified LockTime is reached. - Before LockTime expires, you can replace the transaction with as many new versions as you want. Newer versions have higher sequence numbers. - If you ever want to lock the transaction permanently, you can set the sequence number to UINT_MAX. Then the transaction is considered to be final, even if LockTime has not been reached. This is useful in several cases. For example, two parties can use it to set up a "prepared transaction". Once the prepared transaction is created, the parties can move money between each other instantly, securely, and without fees. So you could set one of these up with an exchange and withdraw and deposit without waiting for confirmations. Since replacement is not used currently, all transactions Bitcoin creates have LockTime = 0 and Sequence = UINT_MAX. FaSan Title: Re: Creare transazione con "ritardo" Post by: bit3000 on January 23, 2015, 08:08:14 PM Capisco, quindi in pratica bisogna impostare un certo "sequence number", altrimenti la transazione viene subito confermata. E inoltre se ho ben capito, chi possiede la chiave privata del mittente può "revocare" la precedente transazione creandone un'altra con "sequence number" più alto. Quindi in pratica fino a quando la transazione arriva a destinazione è necessario tenere in sicurezza la chiave privata del mittente, e quindi utilizzare cose online tipo brainwallet non è il massimo della sicurezza in questi casi.
Title: Re: Creare transazione con "ritardo" Post by: gbianchi on January 23, 2015, 10:35:52 PM Ho scoperto che si può fare la stessa cosa con la funzione "transaction" di brainwallet, basta modificare manualmente il campo "lock_time". brrrrrrrrrrrrivido freddo Title: Re: Creare transazione con "ritardo" Post by: bit3000 on January 24, 2015, 01:27:00 PM brrrrrrrrrrrrivido freddo ;DComunque ho trovato una cosa simile che funziona bene anche offline: https://strongcoin.com/en/blog/the_easiest_way_to_create_secure_offline_bitcoin_transactions Dunque, alla fine ho capito come modificare il campo "sequence", però al momento di inviare la transazione compare un messaggio di errore che dice "The transaction is not final" (ed è giusto che non sia final, è proprio il risultato che volevo ottenere). Ho provato ad inviarlo sia con alcuni client (electrum e il client standard) che tramite https://blockchain.info/pushtx, ma ottengo sempre lo stesso errore. C'è modo di inviare la transazione senza che questa venga in qualche modo "verificata" prima dell'invio? Title: Re: Creare transazione con "ritardo" Post by: bit3000 on February 16, 2015, 09:37:13 PM Provo a fare un esperimento. La transazione è questa:
0100000002e8bfdc8d6a7c318926dcf312be9f270a94765931d9562afc6c2d494b8386f0a325000 0008c4930460221008e481b288a958629715f9f4ce24ac95ca64a04885f757f44681bccd271ae0d 28022100dbe7494844f8fd2b85960a8bff7955c82b9f5a6dcabd83cecf5f13070d171d04014104e 4da05e963255705ed524278005893cb7b95cd32ce009d8f7c8e88f28bdc35a12985086f434cc01b 0bb4fdf7aae9de1b46bbe301abdabd5d2412ebae3fe7cf04ffffffffa0193a457ca7b5aca27ba3a 5b8f3f57eab95ac530b0368d824922123740357ae330000008b483045022035e6c418fb045a5610 6ff4044c9db28027b624d302e09f186c53af08c63bac6c022100d073c28d2c0292460832fd71288 5f6e3e9d5208b5d70ded20e08e182763b918a014104e4da05e963255705ed524278005893cb7b95 cd32ce009d8f7c8e88f28bdc35a12985086f434cc01b0bb4fdf7aae9de1b46bbe301abdabd5d241 2ebae3fe7cf04ffff0fff01d41d0000000000001976a91492e7bae1123b7c58c954f4dfc32035a53fa6d8e788ac023f0500 anzichè ffffffff (che corrisponde al "fondoscala", cioè a infinito) ho messo ffff0fff, cioè un numero a caso. Ovviamente ciò va fatto prima di firmare la transazione. Ora mi dice "The transaction is not final", dovrebbe poter essere possibile inviare la transazione solo dopo il blocco 343810, vediamo se funziona... Title: Re: Creare transazione con "ritardo" Post by: bit3000 on February 16, 2015, 09:49:17 PM Comunque (ipotizzando che funzioni) c'è un'ultimo grande dubbio: nel caso di un hard fork, le transazioni firmate prima del fork e non ancora "spedite" rimangono valide oppure no? Parlo ad esempio di quel fork dei 20mb di cui spesso si vocifera.
Title: Re: Creare transazione con "ritardo" Post by: bit3000 on February 17, 2015, 12:58:44 PM Ha funzionato:
https://blockchain.info/it/tx/17ebb7816350215ba096e1a6ce054862db582caa469327dfaf32b7b82e75f209 comunque rimane quel dubbio legato all'hard-fork, sapete qualcosa in merito? Title: Re: Creare transazione con "ritardo" Post by: gdassori on February 17, 2015, 03:43:43 PM State parlando di transazioni che finiscono in mempool, e quindi inutili a meno che non si parli di blocchi prossimi, non essendo possibile confermarle prima del locktime, non vengono salvate da nessuna parte, se non nella memoria temporanea dei miners.
Quindi, parlando di transazioni con locktime a lungo periodo, che dovrebbero quindi farti preoccupare del fork, il tuo problema è un altro: dovrai rifare tu il broadcast della transazione a tempo debito, e quindi se gli input saranno al momento ancora non spesi, non avrai alcun problema. Title: Re: Creare transazione con "ritardo" Post by: bit3000 on February 17, 2015, 05:37:08 PM State parlando di transazioni che finiscono in mempool, e quindi inutili a meno che non si parli di blocchi prossimi, non essendo possibile confermarle prima del locktime, non vengono salvate da nessuna parte, se non nella memoria temporanea dei miners. Sì, in effetti documentandomi avevo scoperto anche questo, in pratica quindi anche inviando la transazione questa verrebbe comunque "dimenticata" dai miners dopo pochi blocchiQuindi, parlando di transazioni con locktime a lungo periodo, che dovrebbero quindi farti preoccupare del fork, il tuo problema è un altro: dovrai rifare tu il broadcast della transazione a tempo debito, e quindi se gli input saranno al momento ancora non spesi, non avrai alcun problema Sì, avevo scoperto anche questo, in pratica bisogna ri-spedire (o meglio, spedire per la prima volta, dato che spedirla molto tempo prima sarebbe inutile) la transazione a tempo debito. Ma quindi facendo così non c'è veramente nessun problema in caso di fork (a patto che gli input siano non-spesi ecc)? Io intendo una cosa di questo tipo: mi salvo la transazione raw, già firmata, e poi dopo 1 anno (tanto per dire un tempo a caso) la spedisco. Se fosse così sarebbe possibile utilizzare quella transazione come una sorta di assegno postdatato, mi sembra interessante come cosa.Title: Re: Creare transazione con "ritardo" Post by: gdassori on February 18, 2015, 09:59:56 AM Fintanto che gli inputs saranno disponibili, non avrai alcun problema.
Quindi, ipotizzando un fork nell'arco di tempo fra la firma e il broadcast della transazione, se questo fork non ha impattato sugli inputs (se quindi i tuoi inputs sono stati inclusi all'altezza della chain più lunga) tutto ok. Questo che vuol dire, praticamente? Che l'unica condizione in cui gli inputs non dovessero essere validi (assumendo che non siano stati spesi diversamente) è che tu abbia ricevuto quegli inputs che vuoi spendere in fase fork, quindi nell'arco di quei 5-6 blocchi (al max?) che poi verranno rifiutati dalla maggioranza della rete. Come verificare? A distanza di una decina di blocchi dalla firma della transazione, bisogna controllare che questa sia ancora valida (quindi verifichi che i prev_tx legati agli input contenuti nella tua tx prefirmata esistano). Se lo è una decina di blocchi dopo la firma, in futuro non dovresti avere alcun problema, passassero anche 10 anni. Title: Re: Creare transazione con "ritardo" Post by: bit3000 on February 18, 2015, 11:02:17 AM Perfetto, grazie mille della spiegazione :)
Title: Re: Creare transazione con "ritardo" Post by: Stemby on February 24, 2015, 05:10:23 AM L'alternativa è appoggiarsi ad un servizio esterno (oracolo) che firmi una transazione e la trasmetta (broadcast) solo quando una condizione dovesse diventare vera (nel tuo caso: today >= X).
Ci sono pro e contro con entrambi gli approcci. Ciao! Title: Re: Creare transazione con "ritardo" Post by: bertani on February 24, 2015, 08:33:44 AM L'alternativa è appoggiarsi ad un servizio esterno (oracolo) che firmi una transazione e la trasmetta (broadcast) solo quando una condizione dovesse diventare vera (nel tuo caso: today >= X). Esattamente, per esempio: https://oraclized:oraclized@www.oraclize.it/events/checkstatus/9010ebe86f02899a3e396f3b20e051cd ;) Title: Re: Creare transazione con "ritardo" Post by: bit3000 on March 21, 2015, 10:43:40 AM L'alternativa è appoggiarsi ad un servizio esterno (oracolo) che firmi una transazione e la trasmetta (broadcast) solo quando una condizione dovesse diventare vera (nel tuo caso: today >= X). grazie della segnalazione, in effetti è una valida alternativa. Diciamo però che utilizzando un oracolo si ha una soluzione meno decentralizzata e si va a dipendere dall'oracolo stesso (se il sito sparisce, che fine fanno i miei BTC?). Magari può andar bene per transazioni a breve termine (giorni/settimane), in questo modo si effettua la transazione velocemente senza dover smanettare su transazioni raw o cose simili.Ci sono pro e contro con entrambi gli approcci. Ciao! Title: Re: Creare transazione con "ritardo" Post by: bertani on March 21, 2015, 12:07:32 PM Diciamo però che utilizzando un oracolo si ha una soluzione meno decentralizzata e si va a dipendere dall'oracolo stesso (se il sito sparisce, che fine fanno i miei BTC?) In quel caso i tuoi BTC non si muoverebbero affatto visto che ci sarebbe alcuna transazione.. Title: Re: Creare transazione con "ritardo" Post by: arulbero on March 22, 2015, 04:59:17 PM Quote Sequence numbers are intended to be used for replacement. Replacement is currently disabled, but how it would work is: - You send a transaction with a LockTime in the future and a sequence number of 0. The transaction is then not considered by the network to be "final", and it can't be included in a block until the specified LockTime is reached. - Before LockTime expires, you can replace the transaction with as many new versions as you want. Newer versions have higher sequence numbers. - If you ever want to lock the transaction permanently, you can set the sequence number to UINT_MAX. Then the transaction is considered to be final, even if LockTime has not been reached. This is useful in several cases. For example, two parties can use it to set up a "prepared transaction". Once the prepared transaction is created, the parties can move money between each other instantly, securely, and without fees. So you could set one of these up with an exchange and withdraw and deposit without waiting for confirmations. Since replacement is not used currently, all transactions Bitcoin creates have LockTime = 0 and Sequence = UINT_MAX. Mi sfugge il vantaggio di una transazione con LockTime > 0. Se comunque, una volta preparata la transazione, non é possibile trasmetterla alla rete con troppo anticipo perchè verrebbe presto "dimenticata", non sarebbe allora la stessa cosa preparare una transazione standard con LockTime = 0, firmarla, tenerla sul proprio pc e inviarla poi alla rete quando si ritiene più opportuno? In che senso " le due parti potrebbero scambiarsi i bitcoin istantaneamente e senza fee, e senza aspettare le conferme? " ??? Title: Re: Creare transazione con "ritardo" Post by: arulbero on March 29, 2015, 09:12:40 PM Provo a fare un esperimento. La transazione è questa: 0100000002e8bfdc8d6a7c318926dcf312be9f270a94765931d9562afc6c2d494b8386f0a325000 0008c4930460221008e481b288a958629715f9f4ce24ac95ca64a04885f757f44681bccd271ae0d 28022100dbe7494844f8fd2b85960a8bff7955c82b9f5a6dcabd83cecf5f13070d171d04014104e 4da05e963255705ed524278005893cb7b95cd32ce009d8f7c8e88f28bdc35a12985086f434cc01b 0bb4fdf7aae9de1b46bbe301abdabd5d2412ebae3fe7cf04ffffffffa0193a457ca7b5aca27ba3a 5b8f3f57eab95ac530b0368d824922123740357ae330000008b483045022035e6c418fb045a5610 6ff4044c9db28027b624d302e09f186c53af08c63bac6c022100d073c28d2c0292460832fd71288 5f6e3e9d5208b5d70ded20e08e182763b918a014104e4da05e963255705ed524278005893cb7b95 cd32ce009d8f7c8e88f28bdc35a12985086f434cc01b0bb4fdf7aae9de1b46bbe301abdabd5d241 2ebae3fe7cf04ffff0fff01d41d0000000000001976a91492e7bae1123b7c58c954f4dfc32035a53fa6d8e788ac023f0500 anzichè ffffffff (che corrisponde al "fondoscala", cioè a infinito) ho messo ffff0fff, cioè un numero a caso. Ovviamente ciò va fatto prima di firmare la transazione. Ora mi dice "The transaction is not final", dovrebbe poter essere possibile inviare la transazione solo dopo il blocco 343810, vediamo se funziona... Ha funzionato: https://blockchain.info/it/tx/17ebb7816350215ba096e1a6ce054862db582caa469327dfaf32b7b82e75f209 Ho provato anch'io a effettuare una transazione simile con nlocktime modificato, mi esce sempre il messaggio "The transaction is not final" e poi non succede nulla. Guardando in rete ho trovato: The release notes for Bitcoin Core (Satoshi client) version 0.9.0 states "Accept nLockTime transactions that finalize in the next block" quindi comunque bisogna aspettare per inviare la transazione che questa diventi "finale", in pratica non é possibile inviarla in anticipo. Title: Re: Creare transazione con "ritardo" Post by: bit3000 on March 30, 2015, 07:52:58 PM Mi sfugge il vantaggio di una transazione con LockTime > 0. Se comunque, una volta preparata la transazione, non é possibile trasmetterla alla rete con troppo anticipo perchè verrebbe presto "dimenticata", non sarebbe allora la stessa cosa preparare una transazione standard con LockTime = 0, firmarla, tenerla sul proprio pc e inviarla poi alla rete quando si ritiene più opportuno? beh, se però si elimina la chiave privata dell'indirizzo del mittente, si ottiene una quantità di bitcoin "bloccati" che è possibile spendere solo dopo una certa data. Ciò può essere utile a vari scopi.Ho provato anch'io a effettuare una transazione simile con nlocktime modificato, mi esce sempre il messaggio "The transaction is not final" e poi non succede nulla. Guardando in rete ho trovato: The release notes for Bitcoin Core (Satoshi client) version 0.9.0 states "Accept nLockTime transactions that finalize in the next block" quindi comunque bisogna aspettare per inviare la transazione che questa diventi "finale", in pratica non é possibile inviarla in anticipo. Title: Re: Creare transazione con "ritardo" Post by: arulbero on March 31, 2015, 11:04:31 AM Mi sfugge il vantaggio di una transazione con LockTime > 0. Se comunque, una volta preparata la transazione, non é possibile trasmetterla alla rete con troppo anticipo perchè verrebbe presto "dimenticata", non sarebbe allora la stessa cosa preparare una transazione standard con LockTime = 0, firmarla, tenerla sul proprio pc e inviarla poi alla rete quando si ritiene più opportuno? beh, se però si elimina la chiave privata dell'indirizzo del mittente, si ottiene una quantità di bitcoin "bloccati" che è possibile spendere solo dopo una certa data. Ciò può essere utile a vari scopi.É proprio questo il punto che ancora non mi è chiaro, cioè i diversi meccanismi che si possono utilizzare per firmare le transazioni o subordinare una transazione a un'altra, i meccanismi che stanno insomma alla base dei contratti. Ho trovato questo esempio (che penso sia più o meno la spiegazione di come funziona GreenAddress) Quote Example 1: Providing a deposit Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day. The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them. We can solve this problem with a contract: The user and website send each other a newly-generated public key. The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site. User sends the hash of Tx1 to the website. The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero. Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot. The user broadcasts Tx1, then broadcasts Tx2. At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears. In questo caso il contratto ( che é la Tx2 che spende l'output della Tx1) è la transazione con nlocktime modificato e questa deve essere conservata dall'utente che può trasmetterla alla rete solo dopo sei mesi, se ho ben capito? L'output della Tx1 é bloccato per 6 mesi (a meno che le due parti non cambino entrambe idea prima e modifichino il contratto, cioé la Tx2). L'idea del nlocktime e del sequence number dovrebbe essere all'incirca: stabiliamo da quale momento in poi questi fondi saranno sbloccati, se cambiamo idea facciamo un altro contratto con il sequence number modificato; é comunque l'utente che deve ricordarsi di trasmettere al momento opportuno la transazione con il sequence number più alto dal momento che la rete non é in grado di stabilire se dato un contratto ne esiste una versione più aggiornata (a meno che tutte le versioni esistenti non siano inviate alla rete nello stesso momento, in tal caso la rete stessa sceglie quella con il sequence number più alto e scarta le altre versioni). |