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? "  |
|
|
|
Posso fare bonifici a COSTO ZERO verso qualsisi iban.
La storia dei bonifici a costo zero è un po' più complicata di quello che sembra, i bonifici sono a costo zero solo se sei povero, e lo stesso discorso si può fare per i bassi costi di transazione col Bitcoin. Nel senso che le banche si ripagano i costi dei bonifici grazie alla riserva frazionaria che fanno con i soldi che affidi loro? Ribadisco comunque che al momento i costi di transazione dei btc sono "artificialmente" bassi perchè non è certo con quello che ciascuno di noi paga in fee in ogni transazione che si ricompensa il lavoro dei miner; queste fee molto basse servono soprattutto per evitare l'uso massiccio e improprio della rete bitcoin. Invece la vera ricompensa dei miner sono i 25 btc per blocco ( diviso il numero di transazioni del blocco), e se consideriamo quest'ultimo valore come il vero costo, scopriamo che ogni transazione ha un costo reale almeno dell'ordine dei millibtc (stima a spanne). Per sapere poi quanto/se l'invio di bitcoin sia più conveniente rispetto ad esempio a un bonifico, bisognerebbe conoscere allora anche i costi "occulti" di cui parla Ilsk relativi ai bonifici. |
|
|
|
Al momento le fee minime non sono di 0,0001 btc ?
al momento le fee minime sono 0.00001 btc o 1000 satoshi Ho confuso le fee minime con quelle che mi suggerisce di default Armory quando effettuo una transazione.  |
|
|
|
|
Al momento le fee minime non sono di 0,0001 btc ? Come mai nell'esempio di Bertani sono di 10 volte inferiori?
Comunque secondo me non é affatto detto che le commissioni d'invio dei bitcoin rimangano sempre così basse, la diminuzione delle ricompense dei blocchi ( fino alla loro scomparsa completa ) dovrebbe portare a un aumento delle stesse. Al momento mi sembra che le commissioni rappresentano in media circa lo 0,5% del guadagno dei miner per ogni blocco.
Se tutto il resto rimanesse uguale ( valore del bitcoin, numero transazioni,...) per compensare la perdita delle ricompense le fee dovrebbero aumentare di un fattore x 200, quindi arriveremmo a ordini di grandezza simili alle commissioni per le valute fiat. Chiaro che molto probabilmente il numero di transazioni dovrebbe aumentare ( ma non c'é un limite massimo per blocco? ).
|
|
|
|
|
Guardando le faq del sito sembrerebbe che sia possibile costruire dei registri per lo scambio di qualsiasi cosa che sia "misurabile"
"a ledger can be used to record anything that has a fixed number of units, for example shares in a company, vouchers, phone credit, or equity in a property"
senza bisogno di una blockchain che garantisca l'ordine (e quindi la correttezza) delle transazioni.
Questo permetterebbe transazioni senza miner e quindi senza fee? A questo punto sarebbe possibile costruire una moneta digitale alternativa al bitcoin senza più il problema delle enormi risorse computazionali necessarie per sostenere/controllare la rete?
Ma chi mi garantisce che nel momento in cui volessi "riscattare" ad esempio il mio credito telefonico "virtuale" registrato in questi registri/ledger, io trovi effettivamente qualcuno nel mondo reale disposto a convertirlo?
|
|
|
|
(...)
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. 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. 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 ..@KL......v....
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-------------------------------------------------------------------------------------------------------------------------------------------
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
-------------------------------------------------------------------------------------------------------------------------------------------
|
|
|
|
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. 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? |
|
|
|
(...) 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 .... 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 |
|
|
|
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 ) |
|
|
|
(...)
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. 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 ( d'origine o d'arrivo )". 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? |
|
|
|
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?
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? |
|
|
|
(...)
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? |
|
|
|
In ogni caso quando esegui una transazione l'indirizzo mittente viene interamente "svuotato", ed eventualmente (bad practice: address reusing, gli indirizzi BTC debbono essere pensati come "usa e getta") riempito di nuovo dal resto, ma se tu volessi effettuare una nuova transazione, non potresti usare gli stessi input della precedente.
Un input è composto, oltre che dalle sue componenti crittografiche e dalle istruzioni di esecuzione, dall'id transazione di provenienza dei fondi (è questa la cosa importante: ID transazione, non indirizzo).
All'interno della composizione di una transazione l'indirizzo sorgente non appare affatto!
Quindi, anche in presenza di "fondi sufficienti" (perché hai usato come change address della prima tx l'indirizzo stesso) la seconda tx non sarà valida, perché l'id transazione specificato nella precedente sarà già stato "impegnato" per il blocco successivo.
Vediamo se ho capito bene il meccanismo transazione/indirizzi : caso 1) se ho 2 BTC su un mio indirizzo A provenienti da una transazione x, allora devo spenderli tutti (non posso spenderne solo una parte, quindi si crea un resto) 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? |
|
|
|
Carino l'oggetto :-), non capendo di assembler ti chiedo, come generavi i numeri casuali?
https://github.com/bertani/piProject/blob/master/functions.inc#L163Rileggendolo, a parte lo shifting nell'intervallo I-J desiderato direi che facevo circa questo: "considera il contenuto preesistente del registro W, fa due left shifting di 1 bit, se il quarto bit e' 0 fa uno xor, se il terzo bit e' 0 fa un altro xor" Certo, così è chiarissimo  Ma la stima di pi greco si fermava solo alla prima cifra decimale? Quanti punti generavi per ottenere quella stima? Velocità (num punti al secondo) ? |
|
|
|
A quale definizione di probabilità fai riferimento?
Per come capisco direi quella soggettiva che, pur piacendomi, non ho mai approfondito a dovere, a pelle direi che e' quella che potrebbe dare maggiori soddisfazioni.
Mi fa strano pensare ad un evento che ha probabilità 0 (zero) ma si puo' verificare.
In probabilità si parla di evento quasi certo quando esso accade con probabilitá 1, di evento certo se esso accade sempre, sicuramente, e per gli eventi contrari vale lo stesso concetto. Esempio del tipo 1: se hai un generatore di una distribuzione uniforme di numeri reali tra 0 e 1, la probabilità che esca un numero qualsiasi, per esempio 0,458 é 0, nel senso che é minore di una qualsiasi altra probabilitá positiva ( é minore di 0,1, di 0,00001, di 0,00000000001 ... semplicemente perché c'é un solo caso favorevole su infiniti possibili ) ma non é certo impossibile che esca; quindi si dice che l'evento "esce 0,458" é un evento che quasi certamente non accadrá ( o che accadrá con probabilitá 0 ) Esempio del tipo 2: se lancio un dado l'evento "esce un numero maggiore di 6" é un evento che certamente non accadrá. Qui si sta usando la probabilitá in senso assiomatico, e in particolare si inquadra nel contesto della teoria della misura. I problemi nascono quando devi confrontare uno spazio degli eventi favorevoli discreto e finito con uno spazio degli eventi possibili infinito e/o continuo, oppure due spazi infiniti di diverse dimensioni. Di solito nel caso dell'esempio 1 non si calcola mai la probabilitá di un evento "0-dimensionale" se sei in uno spazio degli eventi 1-dimensionale ( il segmento ) ma si parla di densitá di probabilitá oppure di probabilitá che esca un valore all'interno di un certo intervallo. Dai un'occhiata qui https://it.m.wikipedia.org/wiki/Quasi_certamenteEDIT: ti ricorda qualcosa il bersaglio circolare? |
|
|
|
Certo al 100% forse no, ma con probabilità 1 sì (...) 100% è esattamente p(E)=1. Sì, 100% corrisponde a p(E)=1, ma io preferisco utilizzare quest'ultima notazione perchè mi sembra che quando si dice 100% lo si usi come sinonimo di "certo, sicuro" il che non è corretto. Se un evento non può accadare allora sicuramente ha probabilità 0, viceversa se un evento ha probabilità 0 non è detto che non possa verificarsi. Analogamente, se un evento accadrà sicuramente allora ha probabilità 1, ma se un evento ha probabilità 1 non è detto che si verifichi sicuramente. Nel nostro caso, in che senso la nostra successione di stime di pi greco converge con probabilità 1 a pi greco? Nel senso che fissato un epsilon piccolo a piacere, da un certo valore N in poi l'insieme dei valori della successione per cui la stima di pi greco esce dall'intorno di raggio epsilon di pi greco ha misura 0, cioè può benissimo capitare che per qualche valore dopo N punti la successione si discosti dalla sua direzione principale (direzione che la teoria ci assicura esistere e verso la quale la nostra successione deve puntare), ma il numero di questi valori è trascurabile rispetto agli infiniti altri valori per i quali la successione starà in quell'intorno di pi greco. Soprattutto quello che importa è che la nostra successione mostra chiaramente di localizzare in intervalli sempre più ristretti il suo "obiettivo", per cui è chiaro che se a un certo punto dovesse accadere (e ripeto, questo fatto può accadere solo con probabilità 0) che per qualche punto la successione smetta di convergere ed inizi a oscillare a caso, questo fenomeno sarebbe facilmente riconoscibile ed eliminabile, essendo il suo trend principale facilmente individuabile. |
|
|
|
Certo al 100% forse no, ma con probabilità 1 sì Tu dici che all'infinito potrebbe accadere che si presenti una successione che sconvolga il dato complessivo, io dico che più si va avanti più é improbabile che questo accada, e per improbabile intendo che é più facile indovinare una chiave privata da una chiave pubblica che dopo una successione di 1000 miliardi di punti ti trovi una stima di pi greco di 2,5! |
|
|
|
- ha senso parlare di convergenza del algoritmo parlando di numeri casuali? Al massimo si parla di probabilità di commettere un errore minore di x dopo n lanci. Un pochettino come il chi quadro ...
L'algoritmo dal mio punto di vista converge quasi come fosse un limite, da un certo punto in poi l'errore è "sempre" (con "sempre" intendo con probabilità 1) minore di un certo valore e così via, potremmo dire che la successione di stime di pi greco che si aggiorna dopo ogni lancio è una successione di Cauchy (fino al punto in cui subentrano gli errori dovuti alla precisione finita della macchina) che converge a pi greco. Hai dei riferimenti teorici in merito? Io non riesco a concepire se non una probabilità che sia "minore di" e non vedo come una sequenza casuale possa garantire che la successione sia convergente al 100%. Infatti, se uscissero infinite coppie (1, 1) stimeremmo pi con valore 0 e la sequenza con tutte coppie (1, 1) ha la stessa probabilità della sequenza casuale che usi ... allo stesso modo nessuno puo' impedire che si presenti una successione che per ad un certo punto presenti una serie di centri eccessiva che porterebbe il valore della stima fuori dal termine epsylon che ti sei prefisso a priori (anche qui' spero di essermi spiegato). Ossia: con il casuale non credo si possa ragionare come con l'analitico, che poi di veramente casuale non c'è modo di simularlo e che prima interviene la precisione delle macchine son d'accordo. Ma dal punto di vista teorico sei sicuro ci sia una dimostrazione matematiche che garantisce la convergenza? Allora cerco di spiegare meglio qual è il mio pensiero. Sicuramente la probabilità che esca una sequenza di infiniti (1,1) è uguale alla probabilità che esca una qualsiasi specifica altra sequenza casuale: questa probabilità è 0 (il che non vuol dire che non possa accadere). Quello che succede però è che la probabilità che esca una sequenza dall'insieme delle sequenze la cui proprietà è quella di convergere a pi greco è molto più alta (a occhio direi è una probabilità = 1, il che non vuol dire certezza assoluta ma quasi) della probabilità che esca una sequenza dall'insieme delle sequenze che convergono a 0. In altre parole se genero in modo casuale e uniforme miliardi e miliardi di punti con coordinate tra -1 e 1, appare evidente che i punti "dovrebbero" distribuirsi uniformemente sul quadrato e nel cerchio generando la proporzione di 3,14, mentre non avrebbe senso che tutti i punti andassero ad addensarsi in un angolo fuori dal cerchio generando il valore 0. Provo con un esempio più classico: se simulo il lancio di una moneta, all'aumentare dei lanci mi aspetto che la frequenza relativa di uscita della "testa" converga a 0,50 (cioè alla sua probabilità di uscita a ogni lancio come prevede la definizione frequentista di probabilità). Questo dice la teoria, non mi aspetto certo che la frequenza di uscita sia 0 perchè escono infinite "croci". In questo senso si dice un po' impropriamente che ha probabilità 0 la sequenza di sole "croci", poichè ha una proprietà (il tendere al valore di 0 teste) che va contro la definizione di probabilità (e infatti ce l'ha solo lei quella proprietà), mentre una sequenza che presenta un numero di "teste" e "croci" più equilibrate ha una "probabilità di uscita molto maggiore" - anche qui un po' impropriamente - semplicemente perchè è quella proprietà che è più probabile (nel senso che quest'ultima sequenza condivide questa proprietà con molte altre sequenze). E se uscissero improvvisamente 20000 croci di seguito? La teoria dice che potrebbero benissimo uscire, ma con una probabilità così bassa (1 volta ogni 2^20000 casi) che con ogni probabilità (quindi probabilità 1) questo accadrebbe solo dopo aver generato talmente tanti miliardi di punti, che questa sottosequenza speciale di uscite non sposterebbe di una virgola il dato complessivo. Sono invece d'accordo sul fatto che qui non si tratta di una convergenza proprio come quella dell'analisi, nel senso che non è possibile definire a priori, data una certa epsilon, un valore N della successione oltre al quale tutti i valori della successione sono localizzati in un intorno di raggio epsilon del valore limite. Immagina per finire di non conoscere il valore vero di pi greco: come faresti a stimarlo? Genereresti miliardi e miliardi di punti, i quali porterebbero a una successione di stime di pi greco che oscillerebbero (con oscillazioni sempre meno ampie) intorno a un valore limite, una specie di asintoto orizzontale che sarebbe per te il valore di pi greco. Più punti generi più ti avvicini (a meno di qualche ovvia oscillazione ma di decrescente ampiezza, come fanno anche le successioni dell'analisi peraltro) al valore limite. In questo senso intendo dire che l'algoritmo converge da qualche parte, perchè è proprio così, e più lo fai girare meglio è (con ogni probabilità ) |
|
|
|
- quando ho lanciato il programmino che ho fatto ho pensato anche io ad una moneta che ha come sistema di minig qualcosa collegato al numero pi greco, secondo me qualcuno ci ha gia' pensato ... se riesco provo a cercare ... non sarebbe male ...
Un'idea potrebbe essere : Difficoltà = numero di cifre del pigreco da "indovinare" (tipo 15 o 20) Parametro n = numero massimo di punti che si possono generare (tipo 10000) per ottenere una stima entro tale margine di errore A questo punto si genera l'hash di un blocco, che è il seed, e utilizzando una funzione random (uguale per tutti) si generano fino a 10000 punti. Se non si trova un'approssimazione di pi greco alla 15^ cifra, si modifica il blocco (come succede adesso), si ottiene un nuovo hash, a questo punto si prova la nuova serie (al massimo 10000 lanci) e così via. In questo modo sarebbe molto dispendioso trovare la soluzione, ma molto facile verificarla. EDIT: mi sono accorto che ormai l'argomento del thread è cambiato, ho chiesto a HostFat di spostare questo thread per non perdere i contributi di chi vi ha partecipato da una parte, e non utilizzare uno spazio inappropriato in quanto dedicato ai "Servizi" dall'altra |
|
|
|
- ha senso parlare di convergenza del algoritmo parlando di numeri casuali? Al massimo si parla di probabilità di commettere un errore minore di x dopo n lanci. Un pochettino come il chi quadro ...
L'algoritmo dal mio punto di vista converge quasi come fosse un limite, da un certo punto in poi l'errore è "sempre" (con "sempre" intendo con probabilità 1) minore di un certo valore e così via, potremmo dire che la successione di stime di pi greco che si aggiorna dopo ogni lancio è una successione di Cauchy (fino al punto in cui subentrano gli errori dovuti alla precisione finita della macchina) che converge a pi greco. - riflettevo anche su pi greco e blockchain e potrebbe essere interessante studiare un sistema che usa come generatore casuale gli hash dei blocchi e dia come risultato la stima di pi greco della chain. Si potrebbe applicare una griglia al quadrato 1*1 di k*k linee che danno luogo a k^2 punti nel quadrato, poi si conta dal primo a sinistra in basso verso destra salendo una volta arrivato alla x>=1 (non so se mi son spiegato ...), in sostanza si ottiene un intero per ciascuo degli k^2 punti. SI prende il primo hash della chain, si fa modulo k^2 e si determina il primo estratto. Questo e' il primo lancio. Poi si procede come al solito. Ogni blocco abbiamo un aggiornamento del valore.
La stima dipenderà ovviamente anche dal valore di k. Se ci sono idee su come sceglierlo, magari usando qualcosa legato alla difficoltà...
Se ho capito, riassumendo: 1) dividi il quadrato 1x1 in una griglia regolare di k^2 punti 2) si prende l'hash di ciascun blocco (modulo k^2) e si ottiene così quale è il punto estratto (che corrisponde a uno dei vertici di questa griglia e solo a uno di questi, ad esempio il numero 7512 che corrisponde a una certa posizione nel quadrato) 3) alla fine di tutti i blocchi si calcola la stima di pi greco (che si otterrà di fatto dividendo il numero di centri ottenuti per il numero di blocchi presenti nella blockchain fino a quel momento) 4) ora abbiamo ottenuto una stima di pi greco, e il fatto notevole è che ogni punto è stato generato usando un seed diverso (l'hash del blocco corrispondente) Ogni nuovo blocco "genera" un nuovo punto nel quadrato (con la limitazione che può essere sempre solo uno di quei k^2 punti). Bella idea! quando ho lanciato il programmino che ho fatto ho pensato anche io ad una moneta che ha come sistema di minig qualcosa collegato al numero pi greco, secondo me qualcuno ci ha gia' pensato ... se riesco provo a cercare ... non sarebbe male ...
Questa è la parte che mi intriga di più, la difficoltà sta nell'ideare un'operazione collegata ai blocchi difficile da effettuare in un senso ma facile da verificare nell'altro |
|
|
|
|
Show Posts
