Ho giocato un po' anche io con core patchato replace by fee negli scorsi giorni, in particolare ho tentato 9 double spend con somme da 0,01 a 1,11 btc mettendo zero fee nella prima tx.
Ebbene: 9 double spend riusciti su 9 tentativi.
Ho notato che quasi tutti sono stati confermati da btc china, il che penso indichi che ha adottato RBF, e considerando che ha il 7% del net hashrate direi che la probabilità di effettuare una doppia spesa non è così irrilevante anche con fee standard nella prima tx.
La seconda tx l'ho lanciata con un delay variabile a partire da pochi secondi, a qualche minuto, fino ad arrivare a circa 45 minuti da una tx all'altra.
per ora sono a 9 su 9, nei prossimi giorni farò qualche altro test, direi comunque che al momento considerare come buona una tx in ingresso a zero o basse fee è assolutamente da evitare.
Topic: Gangsta, double spend con replace-by-fee - page 2. (Read 10183 times)
(...)
Ma se faccio una transazione "normale", senza script particolari o informazioni codificate nascoste da qualche parte, la dimensione della transazione di fatto dipende solo dal numero di input e di output? Ogni banconota ha lo stesso peso in byte, indipendentemente dalla storia che ha alle spalle?
Prova a guardare qui': https://en.bitcoin.it/wiki/Protocol_documentation#tx a naso direi che circa meno quasi la dimensione è quella, il problema e' che a volte per spedire x BTC devi raggruppare n "banconote" e generarti il resto. Mi pare che il client nuovo stimi la dimensione e pertanto le fee da pagare.Ma se faccio una transazione "normale", senza script particolari o informazioni codificate nascoste da qualche parte, la dimensione della transazione di fatto dipende solo dal numero di input e di output? Ogni banconota ha lo stesso peso in byte, indipendentemente dalla storia che ha alle spalle?
EDIT: mi sa che la dimensione dipende dalla lunghezza della signature e in TxIn compare un ?, quindi non e' fissa.
Dal sito che mi hai linkato ricavo (se ho capito bene):
una transazione contiene 2 campi fissi da 4 byte ciascuno, uno per la versione e uno per il locktime. Poi contiene 2 campi variabili, uno per tutti gli input e uno per tutti gli output.
Ogni input è costituito da una parte fissa di 36 byte per il riferimento all'output della transazione precedente da cui proviene e da una parte di 4 byte per il sequence number, + una parte variabile per lo script che firma la transazione (ma perchè variabile? Forse perchè ci sono diversi modi di firmare una transazione, tipo multisig?)
Ogni output (sono più piccoli) occupa 8 byte per il valore della transazione + una parte variabile per lo script che controlla la chiave pubblica.
Quindi in sostanza la dimensione occupata da una transazione dipende dal numero degli input e degli output, con la complicazione della lunghezza variabile dei due script (come osservato già in un post precedente da picchio).
Da queste informazioni si può ricavare qualche indicazione pratica per la gestione del proprio portafoglio (quante banconote tenere in quante tasche)?
Per contenere le dimensioni di una transazione bisognerebbe effettuare transazioni con un unico input e due output (uno per il resto), ma per avere un solo input bisognerebbe periodicamente raggruppare le proprie banconote in un'unica e quindi sarebbe necessario fare in aggiunta delle transazioni periodiche di "riordino" da n banconote a una all'interno del proprio portafoglio. Non so se ne valga la pena.
Riporto qui sotto l'esempio della tx preso dal sito:
EDIT: su 282 byte totali, 139 byte sono occupati dallo script relativo all'unico input, 50 byte dai due script relativi ai due output, in totale 249 byte sono occupati dall'input e dai due output ( 180 byte dall'input e 69 byte dall'output). Inoltre ci sono i 24 byte dall'header del messaggio.
Code:
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 [email protected]....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......
Message header:
F9 BE B4 D9 - main network magic bytes
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command
02 01 00 00 - payload is 258 bytes long
E2 93 CD BE - checksum of payload
Transaction:
01 00 00 00 - version
Inputs:
01 - number of transaction inputs
Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00
8B - script is 139 bytes long
48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5
FF FF FF FF - sequence
Outputs:
02 - 2 Output Transactions
Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script is 25 bytes long
76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC
Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script is 25 bytes long
76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC
Locktime:
00 00 00 00 - lock time
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 [email protected]....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......
Message header:
F9 BE B4 D9 - main network magic bytes
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command
02 01 00 00 - payload is 258 bytes long
E2 93 CD BE - checksum of payload
Transaction:
01 00 00 00 - version
Inputs:
01 - number of transaction inputs
Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00
8B - script is 139 bytes long
48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5
FF FF FF FF - sequence
Outputs:
02 - 2 Output Transactions
Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script is 25 bytes long
76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC
Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script is 25 bytes long
76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC
Locktime:
00 00 00 00 - lock time
EDIT: altro esempio di transazione preso da questo interessantissimo sito http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html
Code:
-------------------------------------------------------------------------------------------------------------------------------------------
version 01 00 00 00
-------------------------------------------------------------------------------------------------------------------------------------------
input count 01
-------------------------------------------------------------------------------------------------------------------------------------------
previous output hash 48 4d 40 d4 5b 9e a0 d6 52 fc a8 25 8a b7 ca a4 25 41 eb 52 97 58 57 f9 6f b5 0c d7 32 c8 b4 81
------------------------------------------------------------
previous output index 00 00 00 00
input ---------------------------------------------------------------------------------------------------------------------------
script length
----------------------------------------------------------------------------------------------------------------------------
scriptSig script containing signature
----------------------------------------------------------------------------------------------------------------------------
sequence ff ff ff ff
-------------------------------------------------------------------------------------------------------------------------------------------
output count 01
-------------------------------------------------------------------------------------------------------------------------------------------
value 62 64 01 00 00 00 00 00
----------------------------------------------------------------------------------------------------------------------------
output script length
---------------------------------------------------------------------------------------------------------------------------
scriptPubKey script containing destination address
-------------------------------------------------------------------------------------------------------------------------------------------
block lock time 00 00 00 00
-------------------------------------------------------------------------------------------------------------------------------------------
version 01 00 00 00
-------------------------------------------------------------------------------------------------------------------------------------------
input count 01
-------------------------------------------------------------------------------------------------------------------------------------------
previous output hash 48 4d 40 d4 5b 9e a0 d6 52 fc a8 25 8a b7 ca a4 25 41 eb 52 97 58 57 f9 6f b5 0c d7 32 c8 b4 81
------------------------------------------------------------
previous output index 00 00 00 00
input ---------------------------------------------------------------------------------------------------------------------------
script length
----------------------------------------------------------------------------------------------------------------------------
scriptSig script containing signature
----------------------------------------------------------------------------------------------------------------------------
sequence ff ff ff ff
-------------------------------------------------------------------------------------------------------------------------------------------
output count 01
-------------------------------------------------------------------------------------------------------------------------------------------
value 62 64 01 00 00 00 00 00
----------------------------------------------------------------------------------------------------------------------------
output script length
---------------------------------------------------------------------------------------------------------------------------
scriptPubKey script containing destination address
-------------------------------------------------------------------------------------------------------------------------------------------
block lock time 00 00 00 00
-------------------------------------------------------------------------------------------------------------------------------------------
(...)
Ma se faccio una transazione "normale", senza script particolari o informazioni codificate nascoste da qualche parte, la dimensione della transazione di fatto dipende solo dal numero di input e di output? Ogni banconota ha lo stesso peso in byte, indipendentemente dalla storia che ha alle spalle?
Prova a guardare qui': https://en.bitcoin.it/wiki/Protocol_documentation#tx a naso direi che circa meno quasi la dimensione è quella, il problema e' che a volte per spedire x BTC devi raggruppare n "banconote" e generarti il resto. Mi pare che il client nuovo stimi la dimensione e pertanto le fee da pagare.Ma se faccio una transazione "normale", senza script particolari o informazioni codificate nascoste da qualche parte, la dimensione della transazione di fatto dipende solo dal numero di input e di output? Ogni banconota ha lo stesso peso in byte, indipendentemente dalla storia che ha alle spalle?
EDIT: mi sa che la dimensione dipende dalla lunghezza della signature e in TxIn compare un ?, quindi non e' fissa.
L' input di un address è l' output di un altro no ? L' input è certo (se hai bitcoin nel wallet), l' output non è detto, finchè non le spendi.
FaSan
Sono output della tx precedente. Diciamo che tutte le banconote sono prima output e se spese input della tx successiva.FaSan
Si, stiamo confondendo TX e address, vedi la mia correzione sopra. Arulbero diceva in entrata riferendosi all' address. Chiaramente l' entrata di un address è l' output di una TX
FaSan
Esattamente quello che volevo dire, in entrata dal punto di vista dell'address.
Credo che alla transazione si possano aggiungere dati che sono degli script nei quali puoi codificare informazioni, nella blockchain ci sono vari documenti inseriti nelle tx quindi la dimensione dipende da cosa ci metti come info accessorie. Ad esempio puoi mettere l'hash di un documento per dimostrare che lo possedevi alla data nella quale la tx viene inserita.
Ma se faccio una transazione "normale", senza script particolari o informazioni codificate nascoste da qualche parte, la dimensione della transazione di fatto dipende solo dal numero di input e di output? Ogni banconota ha lo stesso peso in byte, indipendentemente dalla storia che ha alle spalle?
Oppure bisogna utilizzare bitcoin-core via riga di comando? 
Si fà con le RAWTX via riga di comando. Nella blockchain la TX è valida solo dopo aver ricevuto la prima conferma dai nodi, prima di allora tutto può succedere
FaSan
L' input di un address è l' output di un altro no ? L' input è certo (se hai bitcoin nel wallet), l' output non è detto, finchè non le spendi.
FaSan
Sono output della tx precedente. Diciamo che tutte le banconote sono prima output e se spese input della tx successiva.FaSan
Si, stiamo confondendo TX e address, vedi la mia correzione sopra. Arulbero diceva in entrata riferendosi all' address. Chiaramente l' entrata di un address è l' output di una TX
FaSan
L' input di un address è l' output di un altro no ? L' input è certo (se hai bitcoin nel wallet), l' output non è detto, finchè non le spendi.
FaSan
Sono output della tx precedente. Diciamo che tutte le banconote sono prima output e se spese input della tx successiva.FaSan
Ok se parliamo di TX si parla di input e di output, se si parla di address allora in entrata ci stà.
FaSan
(...)
Allora perfeziono la mia definizione di banconota:
Banconota: transazione + indirizzo d'arrivo ( o più semplicemente TX in entrata
)
Premesso che non mi piace parlare di banconote ma se aiuta a capire meglio ....Allora perfeziono la mia definizione di banconota:
Banconota: transazione + indirizzo d'arrivo ( o più semplicemente TX in entrata
)Banconota: un input oppure un output di una transazione TX.
NB: ci sono transazioni senza input e sono le revenue per la generazione del blocco https://blockchain.info/it/tx/5f2a72ad2dc4d189742db3d686742d2b4caa8c7b53d3463c217d10bd11309a11
Tasca: indirizzo BTC direi che puo' andare ...
Per questo preferisco la definizione di banconota come output di una transazione TX, proprio perchè ci sono banconote che non hanno un indirizzo di provenienza.
Avrei altre due domande:
1) quando si effettua una transazione si pagano delle fee che dipendono da alcuni parametri (ad esempio da quanto tempo quei bitcoin non vengono spostati, ...) e in particolare dipendono anche dalla dimensione della transazione. La mia domanda è: la dimensione della transazione è determinata solo dal numero di input e numero di output (cioè dal numero di banconote che prende in input e dal numero di banconote che restituisce in output)? Cioè in pratica ogni banconota occupa lo stesso spazio in byte?
(...)
(...)
Allora perfeziono la mia definizione di banconota:
Banconota: transazione + indirizzo d'arrivo ( o più semplicemente TX in entrata )
Premesso che non mi piace parlare di banconote ma se aiuta a capire meglio ....Allora perfeziono la mia definizione di banconota:
Banconota: transazione + indirizzo d'arrivo ( o più semplicemente TX in entrata
)Banconota: un input oppure un output di una transazione TX.
NB: ci sono transazioni senza input e sono le revenue per la generazione del blocco https://blockchain.info/it/tx/5f2a72ad2dc4d189742db3d686742d2b4caa8c7b53d3463c217d10bd11309a11
Tasca: indirizzo BTC direi che puo' andare ...
Per questo preferisco la definizione di banconota come output di una transazione TX, proprio perchè ci sono banconote che non hanno un indirizzo di provenienza.
Avrei altre due domande:
1) quando si effettua una transazione si pagano delle fee che dipendono da alcuni parametri (ad esempio da quanto tempo quei bitcoin non vengono spostati, ...) e in particolare dipendono anche dalla dimensione della transazione. La mia domanda è: la dimensione della transazione è determinata solo dal numero di input e numero di output (cioè dal numero di banconote che prende in input e dal numero di banconote che restituisce in output)? Cioè in pratica ogni banconota occupa lo stesso spazio in byte?
2) questa domanda è più attinente all'argomento di questo thread: la questione del "double spending".
Finora ho sempre sentito parlare di questo argomento come di un problema da cui difendersi, ma non ho mai capito come sia possibile poi nella pratica effettuare una doppia spesa.
Mi spiego: se uso un client come Armory o GreenAddress, non appena comunico alla rete una transazione da un mio indirizzo bitcoin il client segnala come non più disponibili per la spesa i btc inviati (anche se la transazione deve essere ancora confermata ovviamente). A questo punto come sarebbe possibile (senza utilizzare la web app "gangsta") effettuare una doppia spesa degli stessi input?
Dovrei forse importare le chiavi private del mio indirizzo in due client diversi, e quasi contemporaneamente effettuare la spesa della stessa banconota dai due diversi client (in modo che nessuno dei due "sappia" cosa sta facendo l'altro)? Oppure bisogna utilizzare bitcoin-core via riga di comando?
Cercate di non essere eccessivamente tecnici nelle risposte
(...)
Allora perfeziono la mia definizione di banconota:
Banconota: transazione + indirizzo d'arrivo ( o più semplicemente TX in entrata )
Premesso che non mi piace parlare di banconote ma se aiuta a capire meglio ....Allora perfeziono la mia definizione di banconota:
Banconota: transazione + indirizzo d'arrivo ( o più semplicemente TX in entrata
)Banconota: un input oppure un output di una transazione TX.
NB: ci sono transazioni senza input e sono le revenue per la generazione del blocco https://blockchain.info/it/tx/5f2a72ad2dc4d189742db3d686742d2b4caa8c7b53d3463c217d10bd11309a11
Tasca: indirizzo BTC direi che puo' andare ...
Questo modo di vedere le cose é corretto?
E' corretto. Il mio "Transazione=Banconota" era da intendersi TX in entrata. Una TX in entrata è una banconota, se poi in origine fosse sempre una o mille è del tutto irrilevante dal tuo punto di vista.
FaSan
Bene, grazie mille! Finalmente ( dopo solo 1 anno e mezzo che uso i bitcoin ) penso di aver capito!
Allora perfeziono la mia definizione di banconota:
Banconota: transazione + indirizzo d'arrivo ( o più semplicemente TX in entrata
)Questo modo di vedere le cose é corretto?
E' corretto. Il mio "Transazione=Banconota" era da intendersi TX in entrata. Una TX in entrata è una banconota, se poi in origine fosse sempre una o mille è del tutto irrilevante dal tuo punto di vista.
FaSan
(...)
nel caso 2) ho una banconota da 2 BTC nella tasca A e 3 BTC nella tasca B (che sono il frutto però del cambio di un'unica banconota da 5 BTC, visto che provengono da un'unica transazione), e quindi posso ancora spenderli separatamente
(..)
Non necessariamente, quello che devi immaginare che ogni transazione ha n input e k output, quelle due transazioni potrebbero arrivare da 100 input che danno luogo 300 output due dei quali sono le due alle quali tu ti riferisci. nel caso 2) ho una banconota da 2 BTC nella tasca A e 3 BTC nella tasca B (che sono il frutto però del cambio di un'unica banconota da 5 BTC, visto che provengono da un'unica transazione), e quindi posso ancora spenderli separatamente
(..)
Ad esempio: https://blockchain.info/it/tx/eaf0404075adb9c9f10d4640affa368bcb44ebb9af3e7b2966c104e77ed46b6c ha parecchi input e parecchi output.
Lì infatti stavo usando la similitudine di FaSan "transazione=banconota" che però secondo me risulta ambigua.
Allora ripropongo la mia pseudodefinizione:
"banconota": "coppia formata da una transazione e un indirizzo (
In una transazione con n input e k output, vengono prelevate n banconote ( da n address o meno, posso prelevare 2 banconote diverse dalla stessa tasca/address) e convertirle in k banconote ( che finiscono in k address o meno, 2 banconote diverse possono finire nella stessa tasca/address ).
Ognuna delle n banconote di partenza sono costituite da una transazione precedente a quella attuale e da un indirizzo di partenza, ognuna delle k banconote di output sono costituite ( cioé univocamente determinate ) dalla transazione attuale e dall'indirizzo d'arrivo.
In linea di massima tutte le banconote di partenza provengono da address di un unico wallet ( tasche di un unico portafoglio ) in modo che sia possibile firmare la transazione per ogni banconota di partenza. Il caso a cui allude FaSan di transazioni che possono mettere insiemi indirizzi di partenza di più wallet non lo conosco, ma immagino che il concetto sia che ci deve essere un modo di importare le chiavi giuste relative ai vari address per poter firmare la transazione.
Riscrivo allora il caso 2)
Ho una banconota da 2 BTC nella tasca A e una da 3 BTC nella tasca B, le ho ottenute mettendo insieme delle banconote provenienti da un'unica transazione ( quindi la banconota da 2 BTC e quella da 3 BTC condividono solo uno dei due elementi che le caratterizza, la transazione che le ha prodotte, ma non l'indirizzo d'arrivo). Quindi essendo due banconote distinte posso spenderle separatamente.
Ma a questo punto un'altra osservazione: nel caso 3), in cui ho due banconote, una da 2 BTC e una da 3 BTC entrambe nella tasca A, se le spedissi entrambe a un indirizzo C, avrei generato da due banconote distinte una sola banconota da 5 BTC ( univocamente determinata dalla nuova transazione e dall'indirizzo d'arrivo C ).
Per concludere il ruolo di una transazione allora é duplice:
- da una parte cambiare il "proprietario" di bitcoin ( spostare i bitcoin da delle tasche ad altre tasche )
- dall'altra parte é quella di prendere una quantitá totale x di bitcoin e trasformarla in una quantitá x (- fees) cambiando peró il numero di banconote, cioè la distribuzione dei tagli mantenendo costante la quantità totale x; in questo senso una transazione "distrugge" delle banconote e ne "ricrea" altre al loro posto in tagli più adeguati all'utilizzo che si deve fare di quella quantità di bitcoin in quel dato momento
Questo modo di vedere le cose é corretto?
(...)
nel caso 2) ho una banconota da 2 BTC nella tasca A e 3 BTC nella tasca B (che sono il frutto però del cambio di un'unica banconota da 5 BTC, visto che provengono da un'unica transazione), e quindi posso ancora spenderli separatamente
(..)
Non necessariamente, quello che devi immaginare che ogni transazione ha n input e k output, quelle due transazioni potrebbero arrivare da 100 input che danno luogo 300 output due dei quali sono le due alle quali tu ti riferisci. nel caso 2) ho una banconota da 2 BTC nella tasca A e 3 BTC nella tasca B (che sono il frutto però del cambio di un'unica banconota da 5 BTC, visto che provengono da un'unica transazione), e quindi posso ancora spenderli separatamente
(..)
Ad esempio: https://blockchain.info/it/tx/eaf0404075adb9c9f10d4640affa368bcb44ebb9af3e7b2966c104e77ed46b6c ha parecchi input e parecchi output.
Quindi più precisamente si potrebbe dire che una transazione non è una banconota, ma lo è l'accoppiata transazione-indirizzo di destinazione (mentre mi pare di aver capito che gli indirizzi d'origine non contino in questo tipo di ragionamento).
Così è tutto corretto?
Così è tutto corretto?
E' sempre una banconota, indipendentemente da dove la metti. Quando è il momento di pagare puoi mettere la mano in una sola tasca, ma anche metterle in più tasche se con la prima non copri l' importo che intendi muovere. Se usi un wallet le tasche (address) devono essere nello stesso wallet, ma ci sono sistemi un pelino più complessi che ti cito appena per non incasinarti ulteriormente, che ti permettono di usare anche address che hai altrove.
FaSan
Se metti una banconota in due tasche non é piú una banconota, ma sono almeno due!
Da come ho capito io una transazione unisce piú input ( piú banconote ) in un'unica banconota solo per poi risuddividerle di nuovo in altre banconote ( una per ogni indirizzo di output ), o no?
Quindi più precisamente si potrebbe dire che una transazione non è una banconota, ma lo è l'accoppiata transazione-indirizzo di destinazione (mentre mi pare di aver capito che gli indirizzi d'origine non contino in questo tipo di ragionamento).
Così è tutto corretto?
Così è tutto corretto?
E' sempre una banconota, indipendentemente da dove la metti. Quando è il momento di pagare puoi mettere la mano in una sola tasca, ma anche metterle in più tasche se con la prima non copri l' importo che intendi muovere. Se usi un wallet le tasche (address) devono essere nello stesso wallet, ma ci sono sistemi un pelino più complessi che ti cito appena per non incasinarti ulteriormente, che ti permettono di usare anche address che hai altrove.
FaSan
(...)
caso 2) se ho 2 BTC sul mio indirizzo A e 3 BTC sul mio indirizzo B provenienti dalla stessa transazione x, allora se voglio spendere 2 BTC posso spendere i 2 BTC dell'indirizzo A senza toccare i 3 BTC dell'indirizzo B (non importa che tutti e 5 provengano dalla stessa transazione, sono in qualche modo "separati" dagli indirizzi su cui sono stati "indirizzati")
caso 3) se ho 2 BTC sul mio indirizzo A provenienti dalla transazione x e se ho altri 4 BTC sempre sul mio indirizzo A provenienti da un'altra transazione y, allora sono obbligato a spendere tutti i 6 BTC in blocco (non posso ad esempio spendere solo i 2 BTC provenienti dalla transazione x, dal momento che i 2 BTC della transazione x e i 4 BTC della transazione y sono "legati" perchè sono finiti nell'indirizzo A, quindi anche qui si crea un resto)
E' tutto giusto?
caso 2) se ho 2 BTC sul mio indirizzo A e 3 BTC sul mio indirizzo B provenienti dalla stessa transazione x, allora se voglio spendere 2 BTC posso spendere i 2 BTC dell'indirizzo A senza toccare i 3 BTC dell'indirizzo B (non importa che tutti e 5 provengano dalla stessa transazione, sono in qualche modo "separati" dagli indirizzi su cui sono stati "indirizzati")
caso 3) se ho 2 BTC sul mio indirizzo A provenienti dalla transazione x e se ho altri 4 BTC sempre sul mio indirizzo A provenienti da un'altra transazione y, allora sono obbligato a spendere tutti i 6 BTC in blocco (non posso ad esempio spendere solo i 2 BTC provenienti dalla transazione x, dal momento che i 2 BTC della transazione x e i 4 BTC della transazione y sono "legati" perchè sono finiti nell'indirizzo A, quindi anche qui si crea un resto)
E' tutto giusto?
Secondo me il 3) è sbagliato. Puoi spendere sia i 2 che i 4 proprio perche' di due transazioni differenti anche se dirette allo stesso indirizzo.
Esatto. Vedi le singole TX come singole banconote a cui chiaramente non puoi strappare pezzi, ma devi darla intera e ricevere un resto.
FaSan
Certo che la distinzione è sottile. A prima vista mi sembrava che i casi 2) e 3) dovessero essere per forza o entrambi giusti o entrambi sbagliati.
Se sono le transazioni che contano, come dice FaSan, non dovrei poter spendere separatamente i 2 BTC dell'indirizzo A e i 3 BTC dell'indirizzo B, in quanto provenienti da una stessa transazione (ma questo sarebbe illogico, in quanto se l'indirizzo A e l'indirizzo B appartenessero a due persone diverse, una delle due potrebbe spendere i btc dell'altra). Da questa ovvia considerazione avevo erroneamente dedotto che "contassero" di più gli address che le transazioni.
Quindi riassumendo le singole TX sono le singole banconote e gli address sono le tasche, quindi:
nel caso 3) ho una banconota da 2 BTC e una da 3 BTC entrambe nella tasca A, e quindi posso spenderle separatamente
nel caso 2) ho una banconota da 2 BTC nella tasca A e 3 BTC nella tasca B (che sono il frutto però del cambio di un'unica banconota da 5 BTC, visto che provengono da un'unica transazione), e quindi posso ancora spenderli separatamente
Quindi più precisamente si potrebbe dire che una transazione non è una banconota, ma lo è l'accoppiata transazione-indirizzo di destinazione (mentre mi pare di aver capito che gli indirizzi d'origine non contino in questo tipo di ragionamento).
Così è tutto corretto?
(...)
caso 3) se ho 2 BTC sul mio indirizzo A provenienti dalla transazione x e se ho altri 4 BTC sempre sul mio indirizzo A provenienti da un'altra transazione y, allora sono obbligato a spendere tutti i 6 BTC in blocco (non posso ad esempio spendere solo i 2 BTC provenienti dalla transazione x, dal momento che i 2 BTC della transazione x e i 4 BTC della transazione y sono "legati" perchè sono finiti nell'indirizzo A, quindi anche qui si crea un resto)
E' tutto giusto?
caso 3) se ho 2 BTC sul mio indirizzo A provenienti dalla transazione x e se ho altri 4 BTC sempre sul mio indirizzo A provenienti da un'altra transazione y, allora sono obbligato a spendere tutti i 6 BTC in blocco (non posso ad esempio spendere solo i 2 BTC provenienti dalla transazione x, dal momento che i 2 BTC della transazione x e i 4 BTC della transazione y sono "legati" perchè sono finiti nell'indirizzo A, quindi anche qui si crea un resto)
E' tutto giusto?
Secondo me il 3) è sbagliato. Puoi spendere sia i 2 che i 4 proprio perche' di due transazioni differenti anche se dirette allo stesso indirizzo.
Esatto. Vedi le singole TX come singole banconote a cui chiaramente non puoi strappare pezzi, ma devi darla intera e ricevere un resto.
FaSan
(...)
caso 3) se ho 2 BTC sul mio indirizzo A provenienti dalla transazione x e se ho altri 4 BTC sempre sul mio indirizzo A provenienti da un'altra transazione y, allora sono obbligato a spendere tutti i 6 BTC in blocco (non posso ad esempio spendere solo i 2 BTC provenienti dalla transazione x, dal momento che i 2 BTC della transazione x e i 4 BTC della transazione y sono "legati" perchè sono finiti nell'indirizzo A, quindi anche qui si crea un resto)
E' tutto giusto?
caso 3) se ho 2 BTC sul mio indirizzo A provenienti dalla transazione x e se ho altri 4 BTC sempre sul mio indirizzo A provenienti da un'altra transazione y, allora sono obbligato a spendere tutti i 6 BTC in blocco (non posso ad esempio spendere solo i 2 BTC provenienti dalla transazione x, dal momento che i 2 BTC della transazione x e i 4 BTC della transazione y sono "legati" perchè sono finiti nell'indirizzo A, quindi anche qui si crea un resto)
E' tutto giusto?
Secondo me il 3) è sbagliato. Puoi spendere sia i 2 che i 4 proprio perche' di due transazioni differenti anche se dirette allo stesso indirizzo.
Jump to: