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