Can you please explain the method you were using to accomplish this magic? 2^55 - 2^54 = 1.8 x 10^16, that's a lot of private keys to check by brute-forcing them. What you are claiming doesn't make sense at all.
Getting the private key from a public key is known as "the elliptic curve discrete logarithm problem". There are several algorithms to solve this problem: 1) brute force attack (roughly p steps, you mean this method) 2) Pollard Rho (roughly sqrt(p) steps, based on birthday paradox) 3) Baby Step - Giant Step ( roughly sqrt(p) steps if you have enough memory space to store sqrt(p) points) (p = number of points = number of private keys ) Take a look at: http://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/http://www.cs.umd.edu/~gasarch/COURSES/198/Su14/baby.pdfI used the Baby Step - Giant Step applied to a search space of 2^54 points --> 2^27 steps (more or less). It took about 18 seconds to retrieve the private key. Obviously if I had to search the private key in the entire search space of 2^256 points, I couldn't perform the 2^128 required steps (this is computationally infeasible). If you don't believe me, pick a random 55 bit private key (below 0x00000000000000000000000000000000000000000000000000 80000000000000), then generate a public key (you can use http://gobittest.appspot.com/Address), post the public key here --> I will retrieve your private key |
|
|
|
You lost me here. You were asked about the private key, and you are saying you got it from transaction information?!? What am I missing here? From the transaction I got the public key related to the address 1LzhS3k3e9Ub8i2W1V8xQFdB8n2MYCHPCa. You can get the private key from a public key only if you know already that the private key lies in a very limited range (in this case from 2^54 to 2^55) |
|
|
|
The private key is 0x6abe1f9b67e114 Private key : 000000000000000000000000000000000000000000000000006abe1f9b67e114
Public key : 85a30d8413af4f8f9e6312400f2d194fe14f02e719b24c3f83bf1fd233a8f963 eb400323654cec63999b56f4ba44e8b21ab92d9d697fabe4666df3678585669
PrKey WIF c.: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjidyYKE5NcJQZYvknA
Address c. : db53d9bbd1f3a83b094eeca7dd970bd85b492fa2
Address c. : 1LzhS3k3e9Ub8i2W1V8xQFdB8n2MYCHPCa
I am assuming that you found out the private key yourself? I mean how did you get this info? No, I didn't find the key. I just got this info from this transaction https://blockchain.info/it/tx/ecc8c09284a6f9e6d52cccf7f8f4aef1d0c4a33984375dea4cea70923066078d on blockchain that moved for the first time funds from that address. |
|
|
|
I just noticed 1LzhS3k3e9Ub8i2W1V8xQFdB8n2MYCHPCa has just been found recently! on May 29thHowever LBC site still show the task for finding its key  Did someone else find it? or was LBC site just slow on updating its stats page? LBC will search any key in sub-55 bit space, its main goal is not related to the puzzle transaction. |
|
|
|
Nobody admitted the find, so private key is unknown.
The private key is 0x6abe1f9b67e114 Private key : 000000000000000000000000000000000000000000000000006abe1f9b67e114
Public key : 85a30d8413af4f8f9e6312400f2d194fe14f02e719b24c3f83bf1fd233a8f963 eb400323654cec63999b56f4ba44e8b21ab92d9d697fabe4666df3678585669
PrKey WIF c.: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjidyYKE5NcJQZYvknA
Address c. : db53d9bbd1f3a83b094eeca7dd970bd85b492fa2
Address c. : 1LzhS3k3e9Ub8i2W1V8xQFdB8n2MYCHPCa
|
|
|
|
Parecchio interessante grazie per la spiegazione dettagliata, stavo provando a rispondere nell altro thread, ma non era chiaro neanche a me nel dettaglio il funzionamento e mi sono perso per strada  Prego, ma è spiegato molto meglio su Mastering Bitcoin. Lì ci sono molti più dettagli. |
|
|
|
Innanzitutto ti consiglio caldamente di leggerti questi: https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06.asciidochttps://github.com/bitcoinbook/bitcoinbook/blob/develop/ch07.asciidochttp://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.htmlPartiamo dalla tua transazione in formato hex: https://blockchain.info/tx/7edb32d4ffd7a385b763c7a8e56b6358bcd729e747290624e18acdbe6209fc45?format=hex0100000001c8cc2b56525e734ff63a13bc6ad06a9e5664df8c67632253a8e36017aee3ee4000000 0009000483045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33b f88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b7900145514 1042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea 6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51aefeffffff0120f40e0000000 0001976a9141d30342095961d951d306845ef98ac08474b36a088aca7270400
https://blockchain.info/it/decode-tx : {
"lock_time":272295,
"size":229,
"inputs":[
{
"prev_out":{
"index":0,
"hash":"40eee3ae1760e3a8532263678cdf64569e6ad06abc133af64f735e52562bccc8"
},
"script":"00483045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001455141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51ae"
}
],
"version":1,
"vin_sz":1,
"hash":"7edb32d4ffd7a385b763c7a8e56b6358bcd729e747290624e18acdbe6209fc45",
"vout_sz":1,
"out":[
{
"script_string":"OP_DUP OP_HASH160 1d30342095961d951d306845ef98ac08474b36a0 OP_EQUALVERIFY OP_CHECKSIG",
"address":"13fLLox43yXYvfoZadXpGbkTUXkW8bhqut",
"value":980000,
"script":"76a9141d30342095961d951d306845ef98ac08474b36a088ac"
}
]
}
Guardiamo solo allo script di input: "script":"00483045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001455141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51ae"
lo decodifichiamo con http://chainquery.com/bitcoin-api/decodescript : {
"result": {
"asm": "0 3045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001 5141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51ae",
"type": "nonstandard",
"p2sh": "3PDibfe9au3sruD1ZmwbMh7fMsYG9aL9nr"
},
"error": null,
"id": null
}
Osserviamo che ci sono due blocchi di istruzioni: la prima parte 3045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001 è una firma (sequence 30, length 45, integer 02, length 21, X = ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf883, … vedi tabella "pushdata47" di qualche risposta fa) Selezioniamo la seconda parte, che è uno script : 5141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51ae
e quindi la decodifichiamo a sua volta http://chainquery.com/bitcoin-api/decodescript : {
"result": {
"asm": "1 042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf 1 OP_CHECKMULTISIG",
"reqSigs": 1,
"type": "multisig",
"addresses": [
"1Fz5s6qVFwP3MDGeNav4ESQXFMpm8ELzUw"
],
"p2sh": "3P14159f73E4gFr7JterCCQh9QjiTjiZrG"
},
"error": null,
"id": null
}
da qui si vede che è uno script multisig 1 su 1 della forma: 1 <pubKey> 1 OP_CHECKMULTISIG dove la pubKey è 042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6 eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf Riassumendo: nella transazione precedente abbiamo lo script di output della forma HASH160 PUSHDATA(20) e9c3dd0c07aac76179ebc76a6c78d4d67c6c160a EQUAL
che contiene l'hash di uno script a questo stadio ancora sconosciuto alla rete; nella transazione attuale, nello script di input abbiamo: la firma + lo script in chiaro che corrisponde a quello il cui hash è contenuto nell'output della precedente tx: <1 pubKey 1 OP_CHECKMULTISIG>
Dunque si procede così: <1 pubKey 1 OP_CHECKMULTISIG> HASH160 <e9c3dd0c07aac76179ebc76a6c78d4d67c6c160a> EQUAL
Se l'hash160 dello script inserito nell'input coincide con l'hash fornito dalla transazione precedente, allora viene eseguito il controllo finale sulla firma: 0 signature 1 pubKey 1 OP_CHECKMULTISIG
si realizza così la verifica e si autorizza lo sblocco dei fondi collegati all'UTXO. |
|
|
|
|
Gli scritpSig sono gli unlocking script, gli script di output sono invece i locking script. Tu hai scritto il contrario.
Ogni transazione sblocca momentaneamente dei btc (mediante firma e chiave pubblica per esempio) per rivincolarli immediatamente dopo con un altro "lucchetto" (tipo un address di destinazione)
La transazione 40eee... che stai guardando non è P2PKH ma P2PSH, si capisce dallo script di output (gli opt code sono diversi da quelli di un output verso un address) e infatti l'indirizzo di destinazione inizia con un 3 anzichè con il classico 1. L'hash di uno script è di 20 byte esattamente come l'hash di una chiave pubblica, ma ovviamente non sono la stessa cosa.
|
|
|
|
Ciao per essere sicuri che ho capito bene, se leggo P2PKH scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>
Oppure P2PK scriptPubKey: <pubKey> OP_CHECKSIG
scriptSig: <sig>
In entrambi i casi la parte relativa a scriptPubKey si riferisce ovviamente alla trx precedente? Questo a livello di funzionamento di verifica della trx rispetto al ricevente cioè la rete Mentre a livello di creazione della trx la parte con scriptPubKey viene creata con i dati del ricevente Corretto? Sì. I due script (quello di output della tx precedente e quello di input della tx attuale) sono due facce della stessa medaglia, il primo è il "locking" script, il secondo l'"unlocking" script. Ma appartengono sempre a 2 transazioni distinte. Invece quando crei una transazione, il locking script della transazione potrebbe essere anche di una tipologia diversa rispetto all'unlocking script della stessa transazione. Per esempio se vuoi spendere l'output non speso di una tx P2PK verso un'indirizzo standard, creando quindi una tx P2PKH, questa transazione avrà come script di input (unlocking script): (poichè per svincolare i bitcoin vincolati dalla tx precedente con la condizione <pubKey> OP_CHECKSIG è sufficiente fornire solo la firma) e come script di output (locking script): scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
La tipologia di una transazione (P2PK, P2PKH, multisig, P2SH) si ricava dalla condizione che viene posta nello script di output che vincola i bitcoin. |
|
|
|
Non va lo stesso
Io ho appena provato e funziona. Stai usando il sito che ti ho linkato? |
|
|
|
Chiaro anche che tipo di chiave pubblica estesa o compressa non dipende dal tipo di script.
In particolare i 32 byte della chiave pubblica compressa corrispondono ai primi 32 byte della chiave pubblica o c'è qualche altro sistema di derivazione?
Una chiave pubblica è un punto di una curva ellittica, la sua forma è (X,Y), dove X e Y sono valori di 256 bit che soddisfano l'equazione Y^2 = x^3 + 7 modulo un certo numero primo p. Per questo motivo, se conosco anche solo la X, posso derivare facilmente la Y dall'equazione. Più precisamente, per ogni valore di X ci sono 2 valori di Y possibili:  Link utili: https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch04.asciidochttps://bitcointalk.org/index.php?topic=1339031.0Al 99% hai considerato la chiave 04bc3ee049bebf27e6e29403aeb61a1c48acee5d4c3b687252a99add1b7dbe38272e42882747493 f2d2e6c92e22dc46567491f3cd5a25259e269ac66649ef6d871
come una stringa di caratteri anzichè come una sequenza di byte rappresentati in formato esadecimale, prova https://www.fileformat.info/tool/hash.htm usando "Binary Hash" anzichè "String Hash" e otterrai i valori corretti come in http://gobittest.appspot.com/Address |
|
|
|
1. Nello schema mensionato da me si fa riferimento ad una prima versione di bitcoin in cui si pagava direttamente alla chiave pubblica. In questo caso nella transazione di A verso B, A firma hash di tx precedente e chiave pubblica di B e la rete per verificare la firma, e che quindi sia stato veramente A ad emettere la transazione, recupera la chiave pubblica di A dalla transazione precedente di A, transazione precedente linkata nella transazione attuale 2. Nella versione attuale c'è un doppio controllo in quanto non si paga piu alla chiave ma alla sua hash. Quindi A che fa una trx verso B, firma sempre hash della trx precedente e la chiave pubblica di B, in piu aggiunge la sua chiave pubblica alla transazione. La rete fa una doppia verifica in questo caso, dalla transazione precedente verifica che effettivamente la chiave pubblica sia di A e ottenuto questo verifica che la firma sia corretta. Penso che questo sia su per giù quello che hai tentato di raccontarmi Sì, tutto corretto. Nella parte script input trovo solo la firma di 71 byte corretto?
Mentre nell'output la chiave pubblica di 65 byte?
La chiave pubblica nello script di ouput della transazione P2PK è di 65 byte (il byte 04 + 64 byte). In quella transazione P2PKH, come si usa fare solo nelle transazioni più recenti, si usa invece un formato compresso della chiave pubblica (33 byte, il byte 02 o 03 + 32 byte) che si trova nello script di input (per il discorso già fatto chiave pubblica vs. address). Nella parte di input della transazione P2PK non si trova solo la firma (la firma da sola è di 64 byte, non 71 byte), ma altre informazioni per formattare il messaggio. Guarda questo scritpSig, preso da http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html, che riguarda una transazione P2PKH del 2014:  la prima parte (che inizia con PUSHDATA 47) corrisponde ai 71 byte che hai visto tu (47 hex = 71 ). Oltre ai 64 byte della firma vera e propria (X e Y) ci sono altri 7 byte che informano dove iniziano e dove finiscono i vari campi. Come vedi nell'input di una transazione P2PKH c'è anche una parte con la chiave pubblica (PUSHDATA 41, 41 hex = 65 byte), chiave che invece nelle vecchie P2PK era posizionata nell'output della transazione precedente. Nell'esempio in tabella, trattandosi di una transazione del 2014, si usa ancora il vecchio formato non compresso della chiave pubblica di 65 byte (formato compresso/non compresso non c'entra con P2PK / P2PKH) |
|
|
|
Ciao, grazie mille per la risposta, la parte di script ancora la devo approfondire per bene, ma da quello che capisco, correggimi se dico una fesseria, il ricevente di una trx verifica la firma quando deve effettuare lui una transazione verso un altro soggetto e non nel momento in cui la riceve.
No, la verifica della firma viene fatta immediatamente dalla rete, non appena la transazione viene "proposta" pubblicamente. Che il ricevente la verifichi personalmente o no non c'entra, in un certo senso è la rete stessa il ricevente. Una transazione non può essere trasmessa nè tantomeno inserita in un blocco se non è prima verificata. Ciao grazie ancora, almeno sul fatto che la figura sia di non facile comprensione siamo d’accordo Ricapitolo: Nello script di output trovo hash dell indirizzo corretto sto facendo riferimento alla trx che mii hai linkato prima? Quando dici facendo riferimento alla txid precedente ce quindi un puntutatore alla trx di prima dove posso facilemente reperire le info di verifica? Ogni transazione non spende mai "direttamente" i btc di un indirizzo, bensì spende un output (o più output) non speso (UTXO) relativo a una transazione precedente. Cioè ci si riferisce a un indirizzo di partenza solo in modo indiretto, mai direttamente. L'indirizzo A di partenza non c'è esplicitamente nella transazione che spende i suoi fondi. Nella seguente immagine la transazione C spende 2 output non spesi delle transazioni A e B:  E tornando alla transazione che ti ho linkato prima: {
"lock_time":524944,
"size":226,
"inputs":[
{
"prev_out":{
"index":0,
"hash":"ecc8c09284a6f9e6d52cccf7f8f4aef1d0c4a33984375dea4cea70923066078d"
},
"script":"483045022100d1dd9918d3b94a2ed5694f405340c153ddcba746309356366d7f30ac5483865002200b655cd3aeaff1f7c127708b3516ff2374f3c9991afdbca2282c6240d91d9ecd012102cced963cdc06b1881a355f4094a03ef208a9368c2096fb1f6b568508acae973e"
}
],
"version":1,
"vin_sz":1,
"hash":"2757cdab2acc9f11f32d45c9db9d3bdf23787304ed06a43d3c4ccf15e5def075",
"vout_sz":2,
"out":[
{
"script_string":"OP_DUP OP_HASH160 db53d9bbd1f3a83b094eeca7dd970bd85b492fa2 OP_EQUALVERIFY OP_CHECKSIG",
"address":"1LzhS3k3e9Ub8i2W1V8xQFdB8n2MYCHPCa",
"value":5000000,
"script":"76a914db53d9bbd1f3a83b094eeca7dd970bd85b492fa288ac"
},
{
"script_string":"OP_DUP OP_HASH160 7ea3c6d706587efc37b78f8886aa613459e2af92 OP_EQUALVERIFY OP_CHECKSIG",
"address":"1CYcLaSSu7RqndeoW27H36uRfpyVJpTuxh",
"value":50009400,
"script":"76a9147ea3c6d706587efc37b78f8886aa613459e2af9288ac"
}
]
}
guardando alla parte "inputs":[
{
"prev_out":{
"index":0,
"hash":"ecc8c09284a6f9e6d52cccf7f8f4aef1d0c4a33984375dea4cea70923066078d"
},
nello script di input c'è il chiaro riferimento al primo (index 0) output non speso di una transazione già presente nella blockchain (hash = txid della transazione), non è presente invece esplicitamente l'indirizzo di partenza 1AqEgLuT4V2XL2yQ3cCzjMtu1mXtJLVvww In sostanza c'è quindi proprio un puntatore alla transazione precedente, in questo modo le informazioni contenute in questa transazione precedente vengono utilizzate per interpretare anche la transazione attuale (che non avrebbe senso da sola, ma va pensata inserita in una catena di transazioni --> "chain of digital signatures"). EDIT: ho aggiornato anche la risposta https://bitcointalk.org/index.php?topic=4313499.msg39156123#msg39156123 con una versione aggiornata dello schema di Satoshi |
|
|
|
mi potete spiegare questa parte
"We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the
next by digitally signing a hash of the previous transaction and the public key of the next owner
and adding these to the end of the coin. A payee can verify the signatures to verify the chain of
ownership."
in merito allo schema subito dopo riportato?
Non riesco a capire come il payeer possa verificare la firma visto che nella transazione ? presente, oltre alla quantita di valore da trasferire, un hash della precedente transazione e chiave pubblica del nuovo proprietario tutto firmato dal vecchio proprietario.... il nuovo proprietario dove pu? reperire la chiave pubblica del vecchio proprietario per verificare la firma?
 Tento un altro post, quello precedente mi è venuto troppo tecnico. L'immagine che hai postato l'ho sempre trovata di non facile lettura, comunque provo a commentarla. Guardando alla transazione centrale, quella dalla chiave pubblica 1 alla chiave pubblica 2: Owners'2 Public Key: è la chiave pubblica 2 (l'indirizzo 2 invece non è presente da nessuna parte, poichè all'epoca le transazioni erano P2PK, non P2PKH). Questa chiave si trova in una sezione detta ScriptPubKey (script di output). Utilizzando quindi la txid della transazione precedente e la chiave pubblica 2 a cui sono destinati i fondi, si ottiene mediante una funzione di hash la Owners'1 Signature : è la firma che garantisce l'immutabilità della transazione e la sua autenticità. Essa si trova nella sezione detta ScriptSig (script di input). NB: per realizzare la firma serve ovviamente anche la chiave privata 1, per verificarne l'autenticità serve la chiave pubblica 1 (Owners'1 Public Key) presente nello ScriptPubKey della transazione precedente. Quello che è cambiato oggi rispetto a quello schema: 1) nello ScriptPubKey è presente l'hash della public key (l'address) invece della public key (per maggiore sicurezza, da P2PK a P2PKH) 2) per il motivo precedente, nello ScriptSig adesso oltre alla firma si aggiunge qui la chiave pubblica 1 che non si trova più nella transazione precedente. In questo modo la chiave pubblica 1 viene esposta solo nel momento in cui si spendono i fondi dell'indirizzo associato ad essa. Questo è lo schema attuale:  La freccia che va dalla transazione 1 alla 2 sta a indicare che tra i dati che vengono firmati nella transazione 2 compare anche la txid della transazione 1 (in modo analogo a quello che succede con i blocchi della blockchain). |
|
|
|
Prova per un attimo a resettare tutto quello che conosci sul funzionamento del bitcoin e leggi quanto ti riporto sotto e guarda la figura :
"We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the
next by digitally signing a hash of the previous transaction and the public key of the next owner
and adding these to the end of the coin. A payee can verify the signatures to verify the chain of
ownership."
…
Ora in base a quanto vedi nella figura questa frase "A payee can verify the signatures to verify the chain of...." come si concretizza, cioè il beneficiario come verifica la firma?
Per verificare una firma devo conoscere la chiave pubblica del firmatario, questa chiave in base a quello schema dove la recupero?
Non so se è chiaro il dubbio, non voglio conoscere l'attuale funzionamento, ma sto analizzando i concetti da cui sono partiti. E' questo wp o manca qualcosa o ne da per scontato altre... come ti dicevo prima c'è un puntatore alla trx precedente da cui posso leggere la pk.
Un paio di precisazioni: a) nella transazione con cui io invio dei btc dal mio address A a un nuovo address B, è presente una parte, detta "scriptSig" (lo script che i nodi della rete - e in un questo senso anche il ricevente, ma solo in questo senso - devono eseguire per verificare che la transazione sia legittima) che contiene esattamente la chiave pubblica dell'indirizzo A e la firma di A. E' così che si verifica la firma. Ad esempio, guarda questa transazione: https://blockchain.info/it/tx/2757cdab2acc9f11f32d45c9db9d3bdf23787304ed06a43d3c4ccf15e5def075L'indirizzo di partenza A è 1AqEgLuT4V2XL2yQ3cCzjMtu1mXtJLVvww, la sua chiave pubblica: 02cced963cdc06b1881a355f4094a03ef208a9368c2096fb1f6b568508acae973e la trovi facilmente in fondo allo scritpSig. Se vuoi capire in profondità il funzionamento di una transazione, ti consiglio vivamente http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html b) L'hash dell'indirizzo B (in questo caso 1LzhS3k3e9Ub8i2W1V8xQFdB8n2MYCHPCa in base 58 = db53d9bbd1f3a83b094eeca7dd970bd85b492fa2 in formato esadecimale) lo trovi facilmente nello scriptPubKey (script di output) sempre della transazione che ti ho linkato. Questo script sarà eseguito dalla rete solo nel momento in cui il proprietario dell'indirizzo B immetterà in rete una transazione '2' da B verso un indirizzo C. In quel caso lo script di output (scriptPubKey) presente nella transazione '1' verrà eseguito utilizzando la public key inserita nello scriptSig della nuova transazione '2'. Breve nota storica: Satoshi parla di pagamento a una public key invece che a un hash di una public key Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key
solo perché all'inizio le transazioni erano P2PK (pay to public key, pagate direttamente a una chiave pubblica) invece delle attuali P2PKH (pay to public key script hash, cioè pagate agli address consueti). Puoi verificarlo facilmente andando a guardare una qualsiasi transazione in uno dei primi blocchi: https://blockchain.info/it/tx/7f1f0cbd84a06c073c3164b463eda189fe3f98a9744e553380c23e41d6125c60Lì si paga direttamente a questa chiave pubblica (non compressa): 04bc3ee049bebf27e6e29403aeb61a1c48acee5d4c3b687252a99add1b7dbe38272e42882747493 f2d2e6c92e22dc46567491f3cd5a25259e269ac66649ef6d871 non all' hash della chiave pubblica (address). EDIT Riassumendo: ogni transazione da A a B contiene la chiave pubblica di A e l'indirizzo di destinazione B. ScriptSig: chiave pubblica di A e firma ScriptPubKey: indirizzo di destinazione B in formato esadecimale La verifica viene fatta controllando che la chiave pubblica di A e la firma presenti nello ScriptSig della transazione attuale siano consistenti con l'indirizzo di destinazione A presente nello ScriptPubKey della transazione precedente, quella che ha rifornito A. Quindi data una transazione, il suo ScriptSig viene eseguito immediatamente, mentre il suo ScriptPubKey verrà eseguito solo nel momento in cui verranno spesi i fondi presenti in B. Ogni ScriptPubKey viene eseguito insieme allo ScriptSig di una transazione successiva, mai insieme allo ScriptSig della stessa transazione. |
|
|
|
Noto poi una certa ipocrisia intellettuale in chi crede che i bitcoin siano solo fuffa (mi riferisco ai mass media genaralisti) ma si lamenta di quanto consumano e soprattutto di quanto potranno consumare in futuro.
Visto che l'hashrate segue il prezzo, per chi crede che i bitcoin siano solo una bolla destinata a scoppiare a breve, il problema del consumo non si pone visto che anche il mining andrà a zero presto se ci andrà il prezzo.
Questo è vero, tieni conto però che l'energia (elettrica e non) viene considerata ormai da tutti una risorsa limitata e fondamentale del pianeta, e quindi si tende a considerare sempre uno spreco l'impiego di energia (anche se per un periodo limitato di tempo) per qualcosa che non ha valore. Chi crede che bitcoin sia una bolla ritiene del tutto inaccettabile che per altri 2-3-5 anni si continui a sprecare così tanta energia, poiché l'impatto ambientale è in qualche modo sempre irreversibile. Paradossalmente se il mining si potesse fare solo manualmente, e quindi invece di sprecare energia elettrica si sprecasse solo tempo e energia "umana", penso che ci sarebbe molta meno preoccupazione. In fondo se uno vuole sprecare il suo tempo chi può dire qualcosa? Ma l'energia elettrica invece è di tutti, e ciò costituisce un ottimo pretesto per sentirsi in diritto di intervenire e dire la propria sul suo utilizzo. |
|
|
|
|
Show Posts
