Condivio in pieno rendere il sistema di rank piu complicato per salire. Pero tecnicamente i newbie non hanno conoscenza e per prendere merito dovrebbero condividere qualcosa di qualita, ma la qualita viene con l'espereinza. Quindi non e` un po un paradosso il fatto che i newbie devono condividere qualita per ricevere merito?
Non vedo il paradosso. La qualità viene con lo studio e il tempo dedicato. Non c'è scritto da nessuna parte che uno deve ottenere merit entro 1 settimana dalla sua iscrizione. All'inizio uno scrive al massimo per fare qualche domanda (per informarsi e capire meglio il funzionamento di bitcoin) e di solito (non sempre) ci vuole tempo prima che possa portare qualche contributo utile al forum, quindi perchè dovrebbe ottenere subito dei merit? |
|
|
|
Le ricompense scendono, in effetti nel sistema bitcoin esse costituiscono un incentivo ulteriore per creare nella prima fase della storia di bitcoin un'offerta di sicurezza da parte dei miner superiore a quanto la domanda degli utenti possa sostenere. Mi spiego meglio: i miner offrono un servizio di garanzia che le transazioni nella blockchain siano corrette e immutabili; gli utenti pagano questo servizio mediante le fee che permettono loro di includere le proprie transazione nella blockchain. La sicurezza delle transazioni (l'immutabilità e quindi la "garanzia" di ritrovare il proprio denaro anche in futuro) è legata alla spesa che i miner fanno per produrre l'hash rate, più spendono per l'hash rate, più sicura è la blockchain. L'incentivo economico si basa proprio sul fatto che violare la blockchain riscrivendo i blocchi sia costoso, o meglio più costoso che comportarsi in modo corretto. Nei primi tempi della storia di bitcoin (e siamo ancora in quella fase) gli utenti sono troppo pochi e troppo poco disposti (ancora) a pagare fee alte, ci troviamo quindi nella paradossale situazione di avere una blockchain molto sicura (i miner attualmente ricevono complessivamente una cifra dell'ordine di 4 miliardi di dollari all'anno solo di ricompense, quindi è ragionevole supporre che dello stesso ordine di grandezza siano i costi sostenuti dai miner stessi per far funzionare la rete di mining, e mining costoso = blockchain sicura). A fronte di questa sicurezza "costosa" (sia che la si misuri in dollari, sia che la si misuri in TWh all'anno) qual è il prezzo realmente pagato da noi utenti? Estremamente basso, infatti la percentuale di fee media per blocco è circa l'1% delle ricompense https://www.blockchain.com/it/charts/transaction-fees-usd. Di fatto paghiamo poco e abbiamo in cambio un servizio molto sicuro. E' chiaro che questa situazione con il tempo andrà a cambiare, man mano che le ricompense scenderanno. Se oggi un miner ricava circa 80k dollari di ricompensa da un blocco, allora tra 10 o 20 anni (se vogliamo avere un servizio dalla sicurezza equivalente) dovremo pagare 80k dollari di fee. Con la capacità attuale di un blocco (circa 2000 tx in media) fanno l'equivalente di 40 dollari a transazione. Guardando al dato complessivo dei 4 miliardi di dollari all'anno, quando quella spesa sarà pagata per intero dagli utenti, e supponendo una base di utilizzatori di 200 milioni di utenti, saremo a 20 dollari l'anno in media per ciascuno (ovviamente chi farà più transazioni pagherà di più). Quest'ultimo dato prescinde da innovazioni tipo LN o aumento di dimensione dei blocchi, a parità di domanda di sicurezza da parte degli utenti il prezzo in fee (visto che la sicurezza della blockchain in ultima analisi è data dai costi sostenuti dai miner più efficienti) offerto di conseguenza dai miner deve rimanere grosso modo lo stesso (se anche l'efficienza degli asic aumenterà, aumenterà l'hash rate, se il prezzo dell'energia diminuirà, aumenterà l'uso di energia). Questo discorso vale sia per bitcoin che per bitcoin cash (sul lungo periodo). Se invece la domanda di sicurezza aumenterà, vorrà dire che gli utenti saranno disposti a pagare di più (daranno più valore) alla sicurezza e alla possibilità di registrare una propria transazione nella blockchain. Tutto questo per osservare che l'idea ingenua che si possa avere la possibilità di effettuare transazioni libere, senza censure, pseudoanonime, sicure senza pagare un corrispettivo è destinata a scontrarsi con la realtà. Come si fa da una parte a dire che spostare bitcoin costa poco o nulla, e al contempo dire che consuma tantissimo? Qualcosa non quadra. In questi 10 anni, a parte pochi momenti di aumento di domanda diretta (fee) dettata dall'euforia irrazionale per l'aumento del valore del bitcoin, il calo delle ricompense è stato più che abbondantemente compensato dall'aumento del prezzo del bitcoin (12.5 btc oggi valgono molto di più di 50 btc di 8 anni fa), pertanto le fee sono potute rimanere artificialmente basse, ma tutto questo non può durare. Qualcuno deve pagare la sicurezza costosa della blockchain, e chi se non gli utenti? Trovo anche ingenuo concentrarsi solo sull'aumento della capacità dei blocchi e più in generale sul problema dello scaling delle transazioni: la questione vera è che si deve aumentare la base degli utenti effettivi per poter risparmiare veramente, ma il numero degli utenti può fare al massimo un x10, già un x100 mi sembra fuori discussione (stime varie parlano di 30 - 50 milioni di utenti bitcoin oggi nel mondo). Se io facessi anche una sola tx all'anno, comunque dovrò pagarla tantissimo se i 4 miliardi di costo l'anno andranno in qualche modo distribuiti tra pochi utenti. Proprio l'altro giorno ho effettuato una transazione pagando l'equivalente di 2 centesimi di dollaro, allora ho pensato a questo thread, ai 1000 KWh che stavo pagando con soli 2 centesimi e quindi ho scritto questa riflessione  |
|
|
|
Forse mi manca un pezzo, mettiamo che invio dei btc, il wallet full verifica il mio bilancio in base alla lista degli UTXO e crea la transazione, mentre nel caso di un wallet SPV come si comporta nel momento di creare una transazione?
Il wallet SPV non ha l'intero database di tutti gli UTXO della blockchain, ma ovviamente ha il sottoinsieme degli UTXO relativi ai propri indirizzi. Altrimenti in base a che cosa ti farebbe vedere il suo bilancio totale? Più nel dettaglio come funziona l'uso del bloom filter nel colloquio tra un nodo SPV e uno full (qui per "peer" si intende un full node a cui il nodo SPV chiede informazioni): Bloom filters are used to filter the transactions (and blocks containing them) that an SPV node receives from its peers, selecting only transactions of interest to the SPV node without revealing which addresses or keys it is interested in.
An SPV node will initialize a bloom filter as "empty"; in that state the bloom filter will not match any patterns. The SPV node will then make a list of all the addresses, keys, and hashes that it is interested in. It will do this by extracting the public key hash and script hash and transaction IDs from any UTXO controlled by its wallet. The SPV node then adds each of these to the bloom filter, so that the bloom filter will "match" if these patterns are present in a transaction, without revealing the patterns themselves.
The SPV node will then send a filterload message to the peer, containing the bloom filter to use on the connection. On the peer, bloom filters are checked against each incoming transaction. The full node checks several parts of the transaction against the bloom filter, looking for a match including:
The transaction ID
The data components from the locking scripts of each of the transaction outputs (every key and hash in the script)
Each of the transaction inputs
Each of the input signature data components (or witness scripts)
By checking against all these components, bloom filters can be used to match public key hashes, scripts, OP_RETURN values, public keys in signatures, or any future component of a smart contract or complex script.
After a filter is established, the peer will then test each transaction’s outputs against the bloom filter. Only transactions that match the filter are sent to the node.
In response to a getdata message from the node, peers will send a merkleblock message that contains only block headers for blocks matching the filter and a merkle path (see [merkle_trees]) for each matching transaction. The peer will then also send tx messages containing the transactions matched by the filter.
As the full node sends transactions to the SPV node, the SPV node discards any false positives and uses the correctly matched transactions to update its UTXO set and wallet balance. As it updates its own view of the UTXO set, it also modifies the bloom filter to match any future transactions referencing the UTXO it just found. The full node then uses the new bloom filter to match new transactions and the whole process repeats.
The node setting the bloom filter can interactively add patterns to the filter by sending a filteradd message. To clear the bloom filter, the node can send a filterclear message. Because it is not possible to remove a pattern from a bloom filter, a node has to clear and resend a new bloom filter if a pattern is no longer desired.
The network protocol and bloom filter mechanism for SPV nodes is defined in BIP-37 (Peer Services).
|
|
|
|
Caso Full Node/Wallet: il nodo/wallet all'inizio scarica e verifica tutta la blockchain facendosi una lista delle UTXO.
Nel momento in cui gli il wallet crea/genera una transazione verifica che l'input faccia parte delle UTXO in quel caso accetta la transazione la propaga a tutti i nodi della rete tra cui anche il nodo ricevente che aggiorna il suo bilancio ( caso in cui wallet ricevente sia un full node), bisogna attendere che la transazione venga minata e inclusa in un blocco al fine di essere considerata valida. Al nodo arriveranno cosi i nuovi blocchi che verificherà, aggiornera la UTXO e cosi via.....
Domanda se mi scollego dal mio wallet full e lo riaccendo dopo 2 giorni partirà da capo a scaricarsi la blockchain o solo la parte mancante?
Solo la parte mancante. Il database degli utxo si aggiorna in maniera incrementale, man mano che arrivano i blocchi. Quando il nodo è in funzione il database si trova in Ram, quando si spegne il nodo salva il database sull"hard disk e al riavvio parte da lì. Caso SPV: il wallet scarica solo gli header della blockchain e verifica hash. Nel caso in cui deve verificare una transazione chiede ad un full node di inviargli il ramo del merkle tree contenente quella transazione per ricostruire il merkle root. Non capisco pero come possa accettare/scartare transazioni visto che a differenza di un nodo full non ha la lista delle UTXO.  Non si basa sugli utxo ma semplicemente sul numero di conferme (depth) della tx. E' una conferma a posteriori, in base a quello che succede dopo la comparsa della tx, di fatto il wallet SPV si fida del giudizio degli altri full nodi che accettano e propagano questi blocchi e ne aggiungono altri sopra quello contenente la tx. I full node fanno viceversa, controllano innanzitutto il passato della tx (height), solo quello ti può garantire al 100% la validità di una tx. La garanzia a posteriori data dal solo numero di conferme fornisce invece solo un'indicazione probabilistica (seppur importante). Ti avevo già quotato la risposta alla tua domanda: SPV verifies transactions by reference to their depth in the blockchain instead of their height. Whereas a full blockchain node will construct a fully verified chain of thousands of blocks and transactions reaching down the blockchain (back in time) all the way to the genesis block, an SPV node will verify the chain of all blocks (but not all transactions) and link that chain to the transaction of interest.
For example, when examining a transaction in block 300,000, a full node links all 300,000 blocks down to the genesis block and builds a full database of UTXO, establishing the validity of the transaction by confirming that the UTXO remains unspent. An SPV node cannot validate whether the UTXO is unspent. Instead, the SPV node will establish a link between the transaction and the block that contains it, using a merkle path (see [merkle_trees]). Then, the SPV node waits until it sees the six blocks 300,001 through 300,006 piled on top of the block containing the transaction and verifies it by establishing its depth under blocks 300,006 to 300,001. The fact that other nodes on the network accepted block 300,000 and then did the necessary work to produce six more blocks on top of it is proof, by proxy, that the transaction was not a double-spend.
|
|
|
|
Grazie ad entrambi per le risposte, sempre molto gentili. Vorrei capire meglio però un passaggio relativo alla transazione e successiva conferma, riporto per semplicità un esempio: Bob possiede nel suo wallet 3 btc derivati da transazione precedenti, per la precisione 1 btc dalla transazione X 1 btc dalla transazione Y e 1 Btc dalla transazione Z. Ora Bob paga un caffe al bar dal costo di 1.4 btc + 0,4 di fee Bot accede al suo wallet e nel caso di full wallet : - il wallet prepara come somma 2 btc dalla transazione X e Y con resto di 0.2 da ritornare a lui
- il wallet verificherà che la somma non è stata effettivamente spesa controllando con una ricerca in tutta la blockchain le transazioni degli indirizzi presenti nella transazioni X e Y o fa altro? e nel caso di light wallet?
- appurato che la somma sia presente e la transazione passi indenna il controllo degli script questa viene accettata e propagata a tutti i nodi della rete, tra cui anche qualche nodo miner che l'inizierà a minare
- il wallet del proprietario del BAR se ha un wallet full vede aggiornarsi il suo bilancio anche se questa non è stata confermata in quanto deve essere ancora minata, se è di tipo light cosa succede? Non vede il suo bilancio aggiornarsi fino a quando anche lui ad intervalli regolari non chiede ad un nodo full se ci sono nuove transazioni per i suoi indirizzi? Poi quando la transazione sarà minata il wallet potrà verificarla scaricando l header del nuovo blocco e verificando che la transazione sia nel merkel tree???
Un full node man mano che riceve i blocchi aggiorna l'insieme degli output non spesi detti UTXO. Quindi non deve ogni volta che riceve una tx ricontrollare tutte le tx che costituiscono la storia dei bitcoin che sta ricevendo, gli basta controllare che stia ricevendo degli output non spesi guardando all'insieme degli utxo. Tutto lì. Quindi il suo bilancio si aggiorna subito, quando la tx ricevuta non è stata ancora confermata. Per quanto riguarda gli SPV wallet, essi scaricano solo gli header dei blocchi, quindi verificano che la catena dei blocchi sia corretta, ma non conoscono le tx contenute nei vari blocchi. Quando una tx che lo riguarda raggiunge un full node, il nodo SPV tramite il merkle tree (che deve richiedere al full node) può solo verificare da sè in quale blocco quella tx è effettivamente inclusa. Da ciò si capisce perchè un nodo/wallet SPV deve aspettare almeno una conferma (in genere almeno 6) affinchè possa fidarsi, non essendo in alcun modo in grado di valutare da sè se un certo output che sta ricevendo non sia effettivamente mai stato speso. Sul tempo minimo necessario, non esiste, io anche usando wallet su smartphone (quindi evidentemente SPV) ricevo di solito subito l'avviso di ricezione di una transazione quando ancora non è confermata. Il wallet SPV fa una richiesta permanente ai nodi a cui si collega (tramite bloom filter), e riceve di norma immediatamente la comunicazione di una tx che coinvolge un suo indirizzo. Guarda questa risposta che è molto chiara: https://bitcoin.stackexchange.com/questions/79075/light-clients-transaction-verificationHow does a light node know which block its transaction got included in?
Most SPV wallets use BIP 37. The protocol defined in BIP 37 is roughly as follows:
Wallet sends to a full node a bloom filter which, when applied to transactions, indicates whether a transaction applies to that wallet.
Full nodes, for every block and transaction, applies the filter to see if there is a match.
If there is, relay the transactions to the wallet.
If there is a match for a transaction in a block, generate a merkle proof and send the proof with the transaction to the wallet.
Update the filter on matches.
When blocks are received, send the block header to the wallet.
This is generally how all SPV wallets work too, even ones that don't use BIP 37. They may not use bloom filters, but they use some kind of filter and rely on a full node to check things against the filter and then send along the things that match.
For privacy reasons, the filters do not match exactly. They have a false positive rate (but not a false negative rate) so some things are sent to the wallet that do not apply to it. The wallet just ignores those things.
Also, say a wallet program was loaded after a month of inactivity. Now the wallet needs to know the balance of its address? How does it go about reconstructing its balance after downloading the latest block headers?
It connects to a full node, sends it the filter to use, and then asks the node to send all of the transactions that match that filter that are in all blocks since block X where X is the latest block header the wallet has.
Sul funzionamento in generale di un SPV wallet, da "Mastering bitcoin" https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch08.asciidocSPV nodes download only the block headers and do not download the transactions included in each block. The resulting chain of blocks, without transactions, is 1,000 times smaller than the full blockchain. SPV nodes cannot construct a full picture of all the UTXOs that are available for spending because they do not know about all the transactions on the network. SPV nodes verify transactions using a slightly different method that relies on peers to provide partial views of relevant parts of the blockchain on demand.
As an analogy, a full node is like a tourist in a strange city, equipped with a detailed map of every street and every address. By comparison, an SPV node is like a tourist in a strange city asking random strangers for turn-by-turn directions while knowing only one main avenue. Although both tourists can verify the existence of a street by visiting it, the tourist without a map doesn’t know what lies down any of the side streets and doesn’t know what other streets exist. Positioned in front of 23 Church Street, the tourist without a map cannot know if there are a dozen other "23 Church Street" addresses in the city and whether this is the right one. The mapless tourist’s best chance is to ask enough people and hope some of them are not trying to mug him.
SPV verifies transactions by reference to their depth in the blockchain instead of their height. Whereas a full blockchain node will construct a fully verified chain of thousands of blocks and transactions reaching down the blockchain (back in time) all the way to the genesis block, an SPV node will verify the chain of all blocks (but not all transactions) and link that chain to the transaction of interest.
For example, when examining a transaction in block 300,000, a full node links all 300,000 blocks down to the genesis block and builds a full database of UTXO, establishing the validity of the transaction by confirming that the UTXO remains unspent. An SPV node cannot validate whether the UTXO is unspent. Instead, the SPV node will establish a link between the transaction and the block that contains it, using a merkle path (see [merkle_trees]). Then, the SPV node waits until it sees the six blocks 300,001 through 300,006 piled on top of the block containing the transaction and verifies it by establishing its depth under blocks 300,006 to 300,001. The fact that other nodes on the network accepted block 300,000 and then did the necessary work to produce six more blocks on top of it is proof, by proxy, that the transaction was not a double-spend.
An SPV node cannot be persuaded that a transaction exists in a block when the transaction does not in fact exist. The SPV node establishes the existence of a transaction in a block by requesting a merkle path proof and by validating the Proof-of-Work in the chain of blocks. However, a transaction’s existence can be "hidden" from an SPV node. An SPV node can definitely prove that a transaction exists but cannot verify that a transaction, such as a double-spend of the same UTXO, doesn’t exist because it doesn’t have a record of all transactions. This vulnerability can be used in a denial-of-service attack or for a double-spending attack against SPV nodes. To defend against this, an SPV node needs to connect randomly to several nodes, to increase the probability that it is in contact with at least one honest node. This need to randomly connect means that SPV nodes also are vulnerable to network partitioning attacks or Sybil attacks, where they are connected to fake nodes or fake networks and do not have access to honest nodes or the real bitcoin network.
|
|
|
|
Salve a tutti ragazzi, grazie per le risposte dei post precedenti, ho ripreso lo studio del sistema bitcoin ed ho un po di dubbi che elenco di seguito: - Che controlli applica un nodo per bloccare una transazione che utilizzi un importo già speso ma non ancora confermato?
... 3)Si, in particolare una transazione instradata ma non confermata finisce nella mempool (memory pool) da dove poi il miner che ha "vinto" la proof of work la preleva e la include nel blocco appena minato . Usualmente i miner danno la precedenza alle le transazioni con fee più alte (in modo da incrementare la loro ricompensa) 4)In base al wallet che usi l'aggiornamento è immediato nel saldo anche se per il momento non spendibile fino ad un numero sufficiente di conferme (di solito 6) 5)Anche qui dipende dal wallet. Una transazione trasmessa ma non ancora confermata in teoria può essere "doppio spesa" inviando un uguale ammontare a se stessi con una fee più alta in modo che i miners la accodino alla blockchain prima della transazione originale. Ma molti wallet impediscono questa azione. Aggiungo che non solo è possibile spendere gli output non spesi di una transazione non confermata, ma in diversi casi l'operazione si rende proprio necessaria. Quando la mempool è piena, e si vuole sbloccare una transazione non confermata a causa delle fee troppo basse, ci sono sostanzialmente 2 metodi: CPFP (Child Pays for Parents) e RBF (Replace by Fee). Il metodo CPFP (accelerazione della ricezione*) consiste proprio nello spendere gli output di una tx "sospesa" (non confermata) con una seconda tx. Se sto attendendo un pagamento, e questo non viene confermato causa le fee troppo basse, posso spendere gli output non spesi della prima tx (la tx "madre") con una seconda (la tx "figlia"), inserendo in quest'ultima fee sufficienti a rendere appetibile ai miner l'introduzione della coppia di tx in un blocco (nota bene che non sarebbe possibile inserire solo la seconda tx senza la prima). Così si sblocca il pagamento. Il metodo RBF (accelerazione dell'invio) si applica quando si vuole accelerare la conferma invece di una tx inviata, non ricevuta. In quel caso si invia una seconda tx uguale alla prima eccetto il fatto che ha una fee maggiorata. Il miner che vede 2 tx uguali tranne che per le fee scarta la prima tx dalla mempool e utilizza la seconda. RBF (nella variante "Opt-in RBF" -> https://bitcoincore.org/en/faq/optin_rbf/) può essere utilizzata solo se la prima tx era stata taggata da chi l'aveva inviata come "replaceable" nel momento in cui era stata creata, non si può fare insomma a posteriori. Ci sono comunque diverse varianti di RBF -> https://en.bitcoin.it/wiki/Replace_by_fee. Esempio di wallet che permette entrambe le opzioni (e dal cui sito ho preso la mia spiegazione): https://support.conio.com/hc/it/articles/360008901213-Come-faccio-a-fare-arrivare-i-Bitcoin-più-velocemente-*EDIT: a ben vedere il metodo CPFP può essere utilizzato anche da colui che invia i bitcoin, a patto che tra gli output della transazione ci sia almeno un output da lui controllato (di solito il famoso indirizzo del resto): https://data-dive.com/unconfirmed-bitcoin-transactions-electrum |
|
|
|
No, non siamo ancora a quel punto, almeno a livello globale. A livello locale alcune aree, come il Quebec, hanno fatto campagne di promozione per attirare miners in modo da vendere i surplus energetici di quella regione causati dalla sovrapproduzione di energia idroelettrica. Comunque ci arriveremo fra non molto se la potenza di calcolo della rete continuerà ad aumentare al ritmo degli ultimi anni.
Quale sarebbe il costo-opportunità del mining in Quebec? In altre parole, l'energia elettrica che invece di utilizzare in altro modo viene dedicata al mining non riuscirebbe a generare per loro un valore maggiore del mining? Questo mi sembra interessante, sarebbe un indicatore indiretto dell'efficienza del processo di mining (dove per efficienza intendo generare più valore possibile a parità di risorse impiegate). Ok grazie della specifica! (Quante cose mi sfuggono :/ )
Questo post spiega un po' perchè il costo necessario per produrre bitcoin tende al suo valore: https://bitcointalk.org/index.php?topic=5052177.msg47008407#msg47008407 |
|
|
|
|
Dati aggiornati al blocco numero 547944 del 30/10/2018 (percentuali rispetto al blocco numero 544748 del 07/10/2018)
Tipo di output Numero di indirizzi Totale bitcoin
P2PKH 18.453.794 (+0,70%) 10.541.332 ( -0,70%)
P2SH 3.865.985 ( -1,33%) 4.906.667 (+2,28%)
P2PK 38.678 ( -0,07%) 1.759.927 -
P2WPKH 62.643 (+26,30%) 126.738 (+3,99%)
P2WSH 18.662 (+1,88%) 11.812 (-3,08%)
MULTISIG 1-1 357 - 0.05586261
MULTISIG 1-2 142.354 (+0,04%) 23.24 -
MULTISIG 1-3 205.226 (+0,11%) 17.85 (+0.06%)
TOTALE 22.787.699 (+3,92%) 17.346.536 (+0,23%)
Gli indirizzi totali stanno aumentando a un ritmo leggermente superiore rispetto alle rilevazioni precedenti, da sottolineare l'incremento percentuale del numero degli indirizzi P2WPKH.
|
|
|
|
Ovviamente questa immane differenza è dovuta anche al numero di transazioni gestite, che per quanto riguarda i dollari è enormemente superiore al numero delle transazioni in BTC. Allora conviene calcolare il consumo per singola transazione.
Più o meno per Bitcoin si consumano in media 5 kWh per transazione. La rete Visa invece consuma 3 kWh per transazione, quindi il 40% in meno. Però, paradossalmente, più aumenta il numero delle transazioni, più dovrebbe diminuire il consumo medio per singola transazione (pur aumentando quello totale), e con Lightning Network, che non necessita di continue scritture sulla blockchain, il consumo medio per transazione di Bitcoin si ridurrà significativamente. Non è pertanto da escludere che nei prossimi anni possa scendere sotto i 3 kWh per transazione. Edit PS —-> Domanda: nelle pagine precedenti di questo 3d leggo “...320 KWh (il costo di una transazione) ...” ??....
Another point to note is the following: Each Bitcoin block contains 2000 transactions. The Block reward is currently 12.5 BTC. This goes towards the manufacturing of Bitcoin and give it the intrinsic value much like the cost of mining gold give gold its value. The transaction fees are 0.1 BTC per block which works out to be $0.22 transaction fee per transaction which works out to be about 5 kWh per transaction. This is on par with the Visa network which consumes 3 kWh per transaction. I’ve seen people estimate about 1000 kWh per transaction but this is wrong because people wrongly assign the cost of “Creating Bitcoin” to the transaction fee. The proper way of looking at this is to separate out the power cost to create the BTC from the transaction fees which is the portion of the power needed to process the transactions.
Replacing the banks with Bitcoin or some other crypto currency will actually save a lot of resources. La risposta alla tua domanda sta nell'articolo, che dal mio punto di vista erroneamente considera solo le fee. Al momento il costo energetico complessivo per trasmettere una tx è effettivamente di circa 1000 kWh. Considerare solo il "costo" energetico delle fee e non quello della ricompensa dei blocchi non è corretto poichè nel sistema bitcoin la creazione di bitcoin e la scrittura nella blockchain delle tx fanno parte di un'unica procedura. Non a caso con il calare delle ricompense (rispetto ai 50 btc iniziali) le fee (espresse in dollari) sono ovviamente salite. Detta in altro modo, se domani terminassero le ricompense dei blocchi, il sistema potrebbe reggersi continuando a far girare gli attuali 17 milioni di btc solo con le fee attuali? No, mai e poi mai. Potrebbe farlo ma solo al prezzo di una fortissima riduzione dell'hash power e di conseguenza della sicurezza stessa delle tx. Non sarebbe certo la stessa cosa. Altrimenti non si capirebbe il dibattito sulla necessità di aumentare la capacità di effettuare transazioni (scaling) per abbattere le fee. Se si vuole mantenere alta la sicurezza e visto che le ricompense dei blocchi, che al momento pagano in gran parte questa sicurezza, per il protocollo andranno a diminuire con il tempo, senza scaling dovrebbero aumentare di molto le fee. Questo fatto è ineludibile, anche supponendo che la platea degli interessati al mondo bitcoin non cresca. Se 10 milioni di persone oggi si scambiano bitcoin in un regime di ricompense di 80k dollari a blocco, non si può pensare che le stesse potrebbero scambiarsi bitcoin a fee immutate in un regime di ricompense di soli 10k dollari a blocco. |
|
|
|
L'articolo parla di "denaro speso per l'elettricità impiegata per produrre bitcoin" vs " denaro speso per le risorse impiegate dal sistema bancario". Quindi non si tratta di consumo energetico, ma di consumo di risorse in generale (tempo delle persone, spostamenti, ...). Lo preciso solo perchè il consumo attuale di energia elettrica di bitcoin è stimato nell'ordine dello 0,3% del consumo totale elettrico, quindi niente potrebbe consumare 10000 volte quella quantità. Certo se fosse vero che il 9% del prodotto interno lordo degli USA viene impiegato solo per mantenere operativo il sistema bancario e dei pagamenti, viene da riflettere sulla cosiddetta non efficienza delle criptovalute. |
|
|
|
Uno degli aspetti più affascinanti dell'universo Bitcoin che solletica la mente di migliaia di individui consiste nell'esistenza di centinaia di indirizzi di cui molto probabilmente nessuno possiede più la chiave privata, i cosiddetti "zombie address" o indirizzi dormienti che contengono patrimoni milionari.
Per chi non ne avesse mai sentito parlare, qui si può fare un'idea di quante siano queste vere e proprie miniere d'oro a cielo aperto:
....
Al di là di queste piacevoli considerazioni oniriche, tornando con i piedi per terra, possiamo attribuire un ruolo importante a tali indirizzi zombie che contengono immani ricchezze:
questi indirizzi rappresentano le sirene di allarme del sistema Bitcoin, il canarino nella miniera la cui morte ci avvisa della presenza di gas venefico.
Finche questi indirizzi rimarranno inespugnati continuando a custodire inalterato il loro prezioso carico, potremo continuare ad essere ragionevolmente confidenti sul fatto che il sistema Bitcoin non è ancora stato violato.
Concordo in pieno con il tuo post. Aggiungo solo che ci sono canarini nella miniera più sensibili rispetto ai mega address dormienti; qualora infatti quest'ultimi dovessero essere svuotati, sarebbe già troppo tardi: il sistema sarebbe irrimediabilmente andato prima che uno possa uscirne (e in tal caso il canarino avrebbe perso la sua funzione premonitrice). L'alternativa più sensibile a cui alludo è la famosa "puzzle transaction": https://blockchain.info/tx/08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15https://bitcointalk.org/index.php?topic=2141947.msg21464880#msg21464880che è stata costruita inviando a 160 indirizzi diversi quote crescenti di bitcoin (all'indirizzo 50 -> 0.50 btc, all'indirizzo 100 -> 1 btc, all'indirizzo 160 -> 1.60 btc). Ciascuno di questi indirizzi è stato generato a partire da una chiave di lunghezza (e quindi "entropia") crescente: la chiave dell'indirizzo 1 ha una lunghezza di 1 bit, quella dell'indirizzo 2 ha una lunghezza di 2 bit, e così via. Al momento sono state scoperte le prime 56 chiavi private, e si sta cercando di violare la numero 57. Questo fatto fornisce un'idea della capacità dell'insieme degli attaccanti alla rete di bitcoin di generare address e di violarli. Al momento sappiamo che una chiave con più di 60 bit di entropia non è rinvenibile (almeno nel breve periodo, diciamo 1 anno). Ricordo che, essendo gli indirizzi sequenze di 160 bit, è questo il numero che quantifica la sicurezza di bitcoin. Ogni chiave privata controlla in realtà 2^96 indirizzi distinti (limitiamoci agli indirizzi P2PKH). Per questo sarebbe sufficiente utilizzare 2^160 chiavi (circa) per poter accedere a qualsiasi bitcoin esistente in qualsiasi indirizzo P2PKH. Per farsi un'idea delle grandezze in gioco e del loro ordine, guardiamo alla potenza computazionale della rete di mining che ha raggiunto un hashing power (potenza relativa solo allo sha256, senza il calcolo del passaggio chiave privata -> chiave pubblica e senza ripemd160) di circa 2^90 hash all'anno. E questo avviene a fronte di incentivi potentissimi quali sono i 12.5 bitcoin x 144 blocchi al giorno x 365 giorni all'anno = 657000 bitcoin all'anno. Ora pur assumendo che si costruiscano delle macchine che effettuino alla stessa velocità anche le operazioni mancanti per ottenere gli address (e come notava rrupoli gli incentivi naturali ci sarebbero), saremmo ben al di sotto delle 2^100 chiavi private "provate" all'anno. Meno di 1/2^60 di quelle necessarie per accedere a tutti i bitcoin. Il discorso cambia invece per le chiavi P2PK e per tutti gli indirizzi P2PKH che hanno già esposto la loro chiave pubblica. Come già osservato nel primo post di questo thread, in quel caso sarebbero sufficienti 2^128 passi (anche se ciascuno più complesso rispetto alla semplice generazione "consecutiva" di chiavi pubbliche) per poter violare un address specifico. Ma al momento non ci sono macchine degne di nota specializzate nel calcolo chiave privata -> chiave pubblica. |
|
|
|
Using libsecp256k1+sipa's ec grind commit(which uses endomorphism) I get at most 13 million public keys per second(per core) using a batch of 4096. Which means 4 cores would equal roughly 52 million keys per second on my 8700k. If we use both compressed and uncompressed, I guess it automatically goes to ~104Mkeys/s.
Very good speed! It took months to me to get my current 45 million points (only x) per second (per core) on my mobile Xeon. On my laptop if I use 4 cores the speed is less than 4x. I compute three points: x, beta*x, beta2*x. With "45 million points per second" I mean 15 million of (x, beta*x,beta2*x). Do you compute the y coordinates too? From these 3 points you can get 6 compressed public keys: "02x", "03x", "02beta*x", "03beta*x", "02beta2*x", "03beta2*x". If you have the y coordinate too, you can get the uncompressed keys: "04xy", "04beta*xy", "04beta2*xy", "04x(p-y)", "04beta*x(p-y)", "04beta2*x(p-y)" Then in 1 second I could get about 90 million compressed public key per core, and at least 170 million compressed and uncompressed public keys per core. |
|
|
|
Should I assume that you do not wish to make the math available? Or is it already implemented in libsecp256k1? Cause millions of combos per second is pretty good, on a CPU too.
The math is available https://bitcointalk.org/index.php?topic=1573035.msg17676647#msg17676647not the code. I think that almost everything is implemented in libsecp256k1 already, but my software does only one thing: it generates consecutives keys. |
|
|
|
I wrote that answer. The current speed of the public keys generation on my laptop is 185 MKeys/s (I compute only compressed keys, only the "x" coordinates). It's real. If I computed "y" coordinates too I could exploit the fact that (x,y) and (x, p-y) (that is the "symmetrie") are 2 valid points and maybe I would get more speed. I'm talking about public keys generation, not addresses generation. The performance of addresses generation is obviously lower, about 12.7 MAddresses/s (always on cpu) If we compare vanitygen and my library on writing addresses speed (not only generation) the difference is even bigger: --> https://bitcointalk.org/index.php?topic=25804.msg23710724#msg23710724Secp256k1 library too is using optimizations to get more speed: https://bitcointalk.org/index.php?topic=2934774.msg30174356#msg30174356 |
|
|
|
Il passaggio della transazione tra un pc e l'altro potrebbe avvenire attraverso una di quelle app/software che leggono il testo da un immagine, una volta che trovi la configurazione/contrasto giusto non dovrebbe creare troppi problemi. Copiare manualmente c'è sempre il rischio di commettere errori, ma sembra quantomeno interessante calcolarsi la chiave privata a mano. Tra l'altro nei passaggio tra pc offline / pc online tutto ciò che viene scambiato può essere pubblico, infatti né l'impronta digitale della tx non firmata né la firma sono dati riservati, ma finiranno tutti nella blockchain. Si cerca di tenere separati però i 2 dispositivi solo per evitare che passi anche altro oltre a questi dati. EDIT: esempio di sistema di protezione delle chiavi private: https://medium.com/square-corner-blog/open-sourcing-subzero-ee9e3e071827 |
|
|
|
Per generare una sequenza casuale di 256 bit sarebbe teoricamente meglio usare un TRNG (true random number generator) piuttosto che un PRNG (pseudo random number generator). In sostanza sarebbe preferibile utilizzare una fonte analogica esterna piuttosto che un software "chiuso" all'interno di un pc. A questo punto tanto vale provare una soluzione a mano nel vero senso della parola: https://www.swansontec.com/bitcoin-dice.htmlGiusto per avere un'idea di cosa voglia dire 256 bit di entropia: https://medium.com/@kerbleski/a-dance-with-infinity-980bd8e9a781Sul concetto di entropia applicato alla generazione di una chiave privata spiegato in poche parole:
Entropy (more accurately known as Shannon entropy) in information theory is a measure of randomness.
A private key (in the bitcoin protocol) is a number between 1 and 115792089237316195423570985008687907852837564279074904382605163141518161494336.
Since numbers can be represented in many forms, you can also say that a private key is a number between 0x01 and 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4140
When choosing which number you want to use as your private key, it is important (in the interest of security) to have enough entropy (randomness) in your selection. While any number in that range IS a valid private key, your method of choosing a private key might not have an equal probability of generating any of the numbers in the range. This is where "entropy" becomes important. You need enough entropy to make any number in the valid range nearly equal in probability of being selected.
If you roll a cube die 3 times and use the resulting digits as your private key, you will only be capable of generating one of 216 possible private keys. There isn't enough randomness in this. Another person could roll a cube die a few thousand times and they would almost certainly get the same private key as you at least once. Since there are 216 possible results, and all of them are equally likely to occur, the entropy can be described as approximately 7.7 bits of entropy.
If you roll a cube die 100 times and use the resulting digits as a base 6 representation of your private key, you will generate one of:
6.53 X 1077 possible private keys. This has enough randomness. Another person could roll a cube die continuously for the rest of the time that the earth will exist and they still won't have even a 0.000000000000001% chance of generating the same private key as you. Since there are 6.53 X 1077 possible results, and all of them are equally likely to occur, the entropy can be described as a bit more than 256 bits of entropy.
|
|
|
|
Comunque in generale penso sia importante avere una "scatola nera" disconnessa da internet con un rigido protocollo di comunicazione, la quale si occupi di firmare internamente le transazioni senza esporre chiavi private, per poi semplicemente buttarle fuori. Poi che questo sia un pc o hardware dedicato se ne può discutere In effetti serve una scatola che 1) generi sequenze pseudocasuali di 256 bit 2) sia in grado di calcolare una chiave pubblica da una privata (curva ellittica) 3) sia in grado di firmare una transazione, cioè di generare una coppia (r, s) di sequenze di 256 bit che dipendono dalla chiave privata e dalla transazione Sarebbe interessante verificare quanto di questo processo si possa fare a "mano", non letteralmente ma utilizzando strumenti su cui si abbia il controllo massimo possibile. Generare "s" da "r" è relativamente semplice, si tratta di 3-4 operazioni algebriche modulo n, per generare "r" invece bisogna lavorare con la matematica delle curve ellittiche. Il punto 1) rimane un punto intrigante, e cioè riuscire a costruire una sorgente di sequenze pseudocasuali che abbia un'entropia sufficiente. Per quanto riguarda la comunicazione scatola <-> pc connesso a Internet, dal pc bisogna importare lo sha256 della tx non firmata nella scatola che deve restituire solo la firma (r, s) al pc connesso, dove infine viene formata la tx finale firmata e inviata. La cosa più facile che mi viene in mente sarebbe quella di utilizzare come scatola un vecchio pc in disuso (senza scheda di rete, wifi, microfono, scheda audio, videocamera, ovviamente quindi non connesso a Internet), sul quale utilizzare una distro live minima con un paio di programmini in Python che assolvano alle funzioni 1) 2) e 3). Per quanto riguarda la comunicazione scatola <-> pc connesso, bisognerebbe trovare un modo di trasportare i dati tra i due dispositivi. Io utilizzerei la seguente procedura: ogni stringa di 256 bit viene convertita in un insieme di 12 (o quante ne servono) parole prese da una lista precaricata. In questo modo l'operatore umano può copiare abbastanza agevolmente i dati a mano, eliminando ogni contatto diretto tra i due dispositivi. Poi la sequenza di 12 parole viene automaticamente riconvertita nella stringa a 256 bit (64 cifre hex) ed eventualmente si controlla a mano di non aver fatto errori (ma se la firma è sbagliata in ogni caso la procedura si bloccherebbe da sola). Sulla carta è tutto abbastanza facile da realizzare (anche se non praticissimo, ovvio) tranne il punto 1), cioè costruire in maniera autonoma un generatore pseudocasuale con tutta quella entropia. Questo sarebbe il punto più intrigante di tutta la faccenda. EDIT: per chi volesse iniziare a implementare da solo (o capire meglio) il funzionamento di queste funzioni essenziali: https://medium.com/coinmonks/introduction-to-blockchains-bedrock-the-elliptic-curve-secp256k1-e4bd3bc17d |
|
|
|
|
Show Posts
