|
Si può fare, ma il concetto è... che non dovresti. Per questo che non è reso semplice da fare.
Per rimanere nel tuo esempio, un conto corrente (un IBAN) portato nel mondo bitcoin è un intero portafoglio, non un singolo indirizzo. L'indirizzo dovrebbe essere, sempre parlando per sommi capi, l'equivalente di un CRO: ad ogni operazione ne crei uno.
Come regola generale, gli indirizzi bitcoin non andrebbero riutilizzati.
|
|
|
|
|
Quel sito, o meglio quella utenza, è feccia, siamo d'accordo. Ma se si vuole far conoscere il Bitcoin alle masse ci si deve sporcare le mani.
|
|
|
|
Ma ancora a parlare di questa cosa?  Se mai qualcuno mi vietasse di scrivere una cosa vera e incontestabile perchè "sembra migliore" di un'altra manderei a quel paese lui o il forum, a seconda che chi mi dice questa roba. Fammi capire, dovrei scegliere come riferimento il prezzo minore perchè quello maggiore non piace all'OP? E chi lo dice che il prezzo "giusto" sia quello minore, lui? E se io giudicassi il prezzo di bitstamp sottovalutato? Ma poi di che stiamo parlando? Vuoi fare un prezzo migliore? Fallo, e fai notare la differenza maggiore rispetto al prezzo di mtgox. |
|
|
|
|
Sono d'accordo, cerchiamo di non associare ideologie politiche o economiche discutibili ai bitcoin, la loro fama è già abbastanza dubbia così come è.
|
|
|
|
|
Alla faccia della mancanza nella fiducia nelle competenze del prossimo....
|
|
|
|
|
<Inserire qui copincolla di come e perchè sia assurdo minare con la CPU al giorno d'oggi>
|
|
|
|
|
Non sarebbe possibile fare una cosa del genere, perchè la maggior parte della potenza di calcolo generata dalla rete di hashing viene oggi dagli ASIC, che sono in grado solo ed esclusivamente di fare hashing di blocchi. Inoltre, la procedura per generare coppie di chiavi ECDMA e farne l'hashing richiede molti, molti più calcoli di quella necessaria per il proof of work, il numero di chiavi generate al secondo sarebbe molto minore del numero di hash al secondo.
Ma, ipotizzando per assurdo che la potenza di hashing possa essere convertita a questo compito e mantenga il ritmo intatto, alla potenza di 2.5 milioni di miliardi di chiavi generate al secondo, il tempio necessario per verificare la metà delle chiavi esistenti è di 2*128/2.5*10^15/2=7*10^22secondi, ovvero diversi miliardi di millenni.
|
|
|
|
Detto in parole povere: si è teoricamente possibile ma no, non è possibile. Per fare un paragone, è estremamente più verosimile vincere per dieci volte consecutive al superenalotto puntando sempre gli stessi 6 numeri che, generando continuamente nuovi indirizzi, trovarne uno che sia già stato usato da qualcun'altro. D'altra parte, la crittografia in generale si basa su probabilità infinitesime ma non nulle: nessuno può escludere che, ad esempio, una firma digitale apparentemente valida sia semplicemente stata "indovinata" da qualcuno che ha schiacciato a caso tasti sulla tastiera e ha avuto tanta, tanta fortuna. Per correggere i tuoi numeri: sono possibili circa 2 128 chiavi valide, ovvero circa 3.4*10 38. Se ogni persona della terra (7 miliardi) nella sua vita usasse un milione di indirizzi per altrettante transazioni, potremmo andare avanti centinaia di generazioni prima che la possibilità di generare un indirizzo già utilizzato in precendenza diventi una possibilità anche solo lontanamente verosimile. Io comunque quando calcolo questa difficoltà faccio un altro ragionamento sbagliato, ovvero utilizzo la chiave privata; l'indirizzo btc è un hash della chiave privata, quindi contiene meno entropia.
Infatti, l'entropia contenuta in un indirizzo bitcoin, ovvero in una coppia di chiavi ECDMA da 256 bit, è di 128 bit. Ma attenzione, l'indirizzo è un'hash della chiave pubblica, non di quella privata. Immagino sia una svista. |
|
|
|
|
Scusate, mi rendo conto ora lo smile non era sufficiente a far capire il tono della frase. E' innegabile che ci sia un limite alla difficoltà: per l'algoritmo di hashing attuale è di 2256, ovvero circa 1077, ma come dice Ermo è molto di più di quanto i limiti informatici e anche fisici possano permettere di lambire. In realtà è un limite più logico/filosofico che reale, dal punto di vista pratico si può tranquillamente pensare alla difficoltà come una variabile potenzialmente infinita. Tanto più che, qualora in un futuro remoto la difficoltà dovesse effettivamente arrivare da quelle parti, l'algoritmo di hashing sarà stato sostituito con uno più "capiente" molto, molto prima che questo possa diventare un problema
Anche la condizione di controllo da me riportata è più una formalità di programmazione dovuta al passaggio tra variabili di dimensioni diverse che un limite da applicarsi in servizio; non è previsto che si verifichi mai in condizioni normali.
|
|
|
|
|
"Bitcoin" e "vietare" sono due concetti che difficilmente vanno d'accordo.
|
|
|
|
|
Dalla storia di Stamina mi sono ripromesso di non guardare più un servizio delle iene, nonostante alcuni fossero moderatamente interessanti e/o divertenti. Va bene spandere FUD, ma farlo creando false speranze ai disperati, quello no.
Questo sula deepnet e sui bitcoin è, appunto, FUD. Oltre a generalizzazione e sovrasemplificazione.
|
|
|
|
Il codice che calcola il target che un blocco deve soddisfare, e quindi implicitamente anche il retarget, è nel file main.cpp nella funzione GetNextWorkRequired, attualmente alla riga 1285 Riporto le parti più interessanti: int64 nActualTimespan = pindexLast->GetBlockTime() - pindexFirst->GetBlockTime();
Qui viene calcolato il tempo effettivamente passato dall'ultimo blocco all'ultimo del periodo precedente, ovvero il tempo in cui sono stati trovati i 2016 blocchi if (nActualTimespan < nTargetTimespan/4)
nActualTimespan = nTargetTimespan/4;
if (nActualTimespan > nTargetTimespan*4)
nActualTimespan = nTargetTimespan*4;
Questo codice limita lo scostamento del tempo reale tra un quarto e quattro volte l'ideale, in modo che la variazione di difficoltà in un retarget non possa mai essere inferiore al 25% o maggiore del 400%. Detto questo, non mi è chiaro il ragionamento che motiva questo limite, sopratutto per quanto riguarda l'aumento. // Retarget
bnNew *= nActualTimespan;
bnNew /= nTargetTimespan;
Qui viene effettivamente calcolato il retarget moltiplicando il vecchio target per il rapporto tra tempo reale passato dall'ultimo retarget e il tempo ideale di 2 settimane. Se il tempo è stato maggiore il rapporto è <1 e la difficoltà diminuirà, e viceversa, in modo lineare: se il tempo è stato il 30% meno di 14 giorni, la prossima difficoltà sarà del 30% in più if (bnNew > Params().ProofOfWorkLimit())
bnNew = Params().ProofOfWorkLimit(); Questo ci ricorda che la difficoltà non è infinita.  |
|
|
|
|
Anche ammettendo che il 51% (o anche il 100%) della potenza di hashing si metta d'accordo per appropriarsi dei BTC fermi sui conti di silk road, non vedo come potrebbero, a meno di non fare un fork incompatibile, creare un nuovo client e fondare una moneta parallela. "Legalmente" parlando, in termini del protocollo bitcoin, tutto quello che possono fare è fare un gigantesco rewind che annulli le transazioni che hanno spostato moneta in quei conti, restituendoli agli originali proprietari.
Credo che molti erroneamente confondano l'avere il 51% della potenza di hashing con l'avere il controllo completo sul bitcoin.
|
|
|
|
Beh è banale, basta girare la formula del guadagno giornaliero dato l'hashrate: GigaHash/sec ~= (Bitcoin al giorno) * ( difficoltà in milioni) * 2 Quindi, ad esempio, per ottenere 1 bitcoin al giorno con l'attuale difficoltà (112,5 milioni) servono la bellezza di 225 gigahash al secondo di potenza di calcolo. Questo a meno di fee ed inefficienze varie, diciamo 250 gigahash/sec come valore reale. L'andamento della potenza necessaria e la difficoltà è lineare, quindi se vuoi mantenere il guadagno nel tempo devi far crescere la tua potenza di hashing di pari passo con la difficoltà, che al momento significa quasi raddoppiarlo ogni mese. Direi non verosimile. |
|
|
|
|
Quello che posso consigliarti è, prima di partire con l'inventiva, di approfondire di più l'argomento, la "storia" di ciò che è stato fatto sinora e lo stato dell'arte attuale per quanto riguarda le tecnologie che girano attorno al bitcoin, che sono tante e anche non banali. Un pizzico di ingenuità spesso fa bene all'inventiva, ma troppa ti porta a reinventare la ruota.
|
|
|
|
|
inb4 post di Pitchotto "aiuto mi hanno truffato nMila euro"
|
|
|
|
stavo anche pensando a vie alternative quali il javascript in client-side ma la potenza è troppo troppo bassa, dovrei aver bisogno di tutti gli utenti di fb collegati insieme!
ok sn arrivato troppo tardi, uff
Lo facevano già 2 anni fa. Mi ricordo di uno che aveva aperto un sito porno che si finanziava con un script di mining che girava in background mentre l'utente faceva...altro. |
|
|
|
Una SIM intestata a qualcuno per far funzionare il 3G serve, a meno che non ti connetti a scrocco (con tutti gli svantaggi del caso)
Negozio cinese e via. |
|
|
|
|
Per determinate applicazioni assolutamente si, perchè ti consentirebbe di mettere pannelli senza aver bisogno di nulla, senza chiedere niente a nessuno. Niente allacciamento, Niente contratto, niente identità. Solo bitcoin totalmente anonimi generati dal sole in posti anonimi.
Piccolo appunto: io parlavo di 2 batterie da 400 Ah, non 40.
|
|
|
|
|
Nessun rischio di attacco 51%, da quel punto di vista chi mina su P2Pool è a tutti gli effetti un minatore in solo.
|
|
|
|
|
Show Posts
