Creare transazione con "ritardo"

[bit3000]

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 . 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à Grazie in anticipo per l'aiuto

[1714749494]

1714749494

[1714749494]

1714749494

[1714749494]

1714749494

[1714749494]

1714749494

[1714749494]

1714749494

[1714749494]

1714749494

[gbianchi]

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.

[bit3000]

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

[FaSan]

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

[bit3000]

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?

[FaSan]

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 :

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

[bit3000]

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.

[gbianchi]

Ho scoperto che si può fare la stessa cosa con la funzione "transaction" di brainwallet, basta modificare manualmente il campo "lock_time".

brrrrrrrrrrrrivido freddo

[bit3000]

brrrrrrrrrrrrivido freddo

Comunque 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?

[bit3000]

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

[bit3000]

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.

[bit3000]

Ha funzionato:
https://blockchain.info/it/tx/17ebb7816350215ba096e1a6ce054862db582caa469327dfaf32b7b82e75f209

comunque rimane quel dubbio legato all'hard-fork, sapete qualcosa in merito?

[gdassori]

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.

[bit3000]

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 blocchi

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

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.

[gdassori]

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.

[bit3000]

Perfetto, grazie mille della spiegazione

[Stemby]

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!

[bertani]

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

 

[bit3000]

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!

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.

[bertani]

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