antonio@ubuntu:~/collider$ sudo ./LBC -V
[sudo] password di antonio:
0.899
antonio@ubuntu:~/collider$ sudo chown antonio *
antonio@ubuntu:~/collider$ ls -al *
-rw-r--r-- 1 antonio root 114 dic 19 22:41 bench.pst
-rw-r--r-- 1 antonio root 472 dic 19 22:43 FOUND.txt
-rw-r--r-- 1 antonio antonio 536870912 dic 19 17:36 funds_h160.blf
-rwxr-xr-x 1 antonio antonio 1074624 dic 19 17:10 gen-hrdcore-sse41-linux64
-rwxr-xr-x 1 antonio antonio 34671 dic 18 16:06 LBC
-rw-r--r-- 1 antonio root 50166 dic 18 18:56 LBCdiag.txt
antonio@ubuntu:~/collider$ sudo ./LBC -c 1 -t 1:0
Best generator chosen: gen-hrdcore-sse41-linux64
PAGE-TO: 0 PAGE-FROM: 0
Ask for work... Server doesn't like us. Answer: error 0x567.
Another error... |
|
|
|
My test is ok: antonio@ubuntu:~/collider$ sudo ./LBC -x
Will use 0 CPUs.
Best generator chosen: gen-hrdcore-sse41-linux64
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... done.
Your maximum speed is 204516 keys/s per CPU core.
PAGE-TO: 0 PAGE-FROM: 0
Test ok. Your test results were stored in FOUND.txt.
Have a look and then you may want to remove the file.
o2d17543d32448acc7a1c43c5f72cd5be459ab302:u:(hex)priv:000000000000000000000000000000000000000000000000000000000000005f
02e62151191a931d51cdc513a86d4bf5694f4e51:c:(hex)priv:0000000000000000000000000000000000000000000000000000000000000066
9d74ffdb31068ca2a1feb8e34830635c0647d714:u:(hex)priv:00000000000000000000000000000000000000000000000000000000000f9f8d
3d6871076780446bd46fc564b0c443e1fd415beb:c:(hex)priv:00000000000000000000000000000000000000000000000000000000000f9f8d
Ending test run.
antonio@ubuntu:~/collider$ ls
bench.pst FOUND.txt funds_h160.blf gen-hrdcore-sse41-linux64 LBC
but then: sudo ./LBC
Best generator chosen: gen-hrdcore-sse41-linux64
PAGE-TO: 0 PAGE-FROM: 0
Ask for work... Server doesn't like us. Answer: perm withdrawn.
antonio@ubuntu:~/collider$ sudo ./LBC -c 1 -t 1
Best generator chosen: gen-hrdcore-sse41-linux64
PAGE-TO: 0 PAGE-FROM: 0
Ask for work... Server doesn't like us. Answer: perm withdrawn.
antonio@ubuntu:~/collider$ sudo ./LBC -l 0 -c 1 -t 1:0
Best generator chosen: gen-hrdcore-sse41-linux64
PAGE-TO: 0 PAGE-FROM: 0
Ask for work... Server doesn't like us. Answer: malformed request.
antonio@ubuntu:~/collider$ sudo ./LBC -p 1000-1001
Loop off! Work on blocks [1000-1001] (2 Mkeys)
Will use 0 CPUs.
Best generator chosen: gen-hrdcore-sse41-linux64
PAGE-TO: 1001 PAGE-FROM: 1000
Estimated duration: infd NaNh NaNm NaNs
Too many requested pages [1000,1001]. Limiting work per iteration to 1 day.
New range: [1000, 1000].
oServer doesn't like us. Answer: perm withdrawn.
antonio@ubuntu:~/collider$ sudo ./LBC -q
Server answer to 'query' is:
{
"nil" : "malformed request"
}
'done' means we have delivered 0.000 valid Gkeys.
What is the problem? |
|
|
|
|
Primo acquisto effettuato, tutto liscio. Venditore disponibile e veloce.
|
|
|
|
Non c'è solo il rischio truffe ecc ma anche la quantità di tempo da dedicarci per essere sempre presenti, praticamente a tutte le ore, spiegare spesso da zero il funzionamento di bitcoin e mille altre domande varie ed eventuali, mantenere e bilanciare la liquidità in vari posti per venire incontro alle richieste e mille altri dettagli. Questioni legali, questioni fiscali da tenere d'occhio (e spesso "l'occhio" non basta).
Non è un lavoro semplice ed è molto time consuming, specialmente con volumi non "amatoriali" (certi venditori qui facevano fatica a trovare il tempo per uscir di casa o per mangiare). Nelle fees è incluso anche questo.
Magari non è immediatamente evidente a chi "non è del mestiere", ma non è come vendere il mezzo bitcoin ogni tanto all'amico, assicuro.
Quindi confermi la mia impressione: quando alcuni venditori giustificano le loro fee adducendo come elemento fondamentale i tentativi di truffe non stanno dicendo tutta la verità. Io pago x % di fee quando acquisto btc poiché sto pagando un contatto personale, molto spesso disponibile online, a cui posso fare domande varie. Inoltre pago il fatto che il venditore privato è un singolo che deve gestire in autonomia le questioni legali e fiscali. Solo una parte delle fee (e probabilmente neanche la maggior parte) va a coprire i costi per assicurarsi contro il rischio di truffa. |
|
|
|
Quasi nessuno accetta piu' ricariche online per via delle mille truffe e carte rubate o piene di fondi di dubbia provenienza che causano blocchi e casini vari.
il fatto è che fare la ricarica dal tabacchino/posta è una rottura, online è più comodo. Sì ma poi per il venditore andare a processo per qualche truffetta di merda è un po' scomodo. Aggiungo una cosa, senza alcun intento polemico: tante volte si dice che le fee dei venditori servono a ricompensare il loro lavoro e soprattutto il rischio a cui si espongono nello scambiare un mezzo di pagamento irreversibile come btc con uno reversibile come ricariche/bonifici ecc. Io dico anche però che btc nasce proprio per ridurre a zero o quasi il rischio di chargeback insito nei pagamenti online e/o a distanza tramite valuta fiat. Nel momento in cui una persona decide di intraprendere il lavoro di cambiavalute btc-fiat, che lavoro accetta di fare nella sostanza? Accetta di assumere su se stesso (e gestirlo) il rischio di chargeback/truffa, di fatto egli infatti acquista "rischio" (fiat) in cambio di "certezza" (btc). Con questo voglio dire semplicemente che in questo sta l'abilità di un venditore, di gestire il rischio riconoscendo caso per caso quando può concedere qualcosa in più (tipo la ricarica online) perché conosce il cliente o quando viceversa valutando una situazione particolarmente rischiosa sia il caso di astenersi dal concludere la trattativa. Nel caso di un servizio automatizzato come BitBoat non mi sorprende la decisione di sospendere le ricariche online, in quanto non adottando di fatto alcuna politica di riconoscimento dell'identità (almeno che io sappia, io ho fornito loro solo una mail) è molto difficile discernere i casi rischiosi da quelli meno rischiosi. Dai venditori privati come quelli qui sul forum invece, dove c'è un contatto un po' più diretto tra acquirente e venditore, è possibile secondo me aspettarsi una maggiore elasticità rispetto ai servizi automatizzati. D'altronde se non ci fosse il rischio di truffa, vendere bitcoin sarebbe un lavoro che potrebbe fare praticamente chiunque sappia cos'è il btc. Il valore aggiunto del venditore è dato proprio dalla capacità che ha e che si è costruito nel tempo (e a volte anche dalla fortuna) di prezzare accuratamente il rischio che sta correndo volta per volta. Alla lunga però è inevitabile che ogni tanto incapperà in problemi di truffe o tentate truffe, ognuno decide da sé se il gioco vale la candela. Riassumendo io posso accettare di pagare al tabacchino, se in cambio mi viene fornito un sostanzioso sconto sulle fee (perché sto facendo correre meno rischi al venditore); ma se il prezzo non cala il risultato è che per gli acquirenti le modalità sono sempre più scomode senza contemporaneamente avere un vantaggio sul prezzo finale: un po' come quelle assicurazioni di auto (anche loro gestiscono il rischio) che si lamentano per le truffe e fanno pagare comunque sempre un po' di più e mai un po' di meno, in quei casi non hai mai l'impressione di stare pagando il giusto prezzo del rischio che corrono ma che il rischio venga preso come pretesto per guadagnare sempre un po' di più. Certo è che se le modalità saranno sempre più scomode, e implicheranno in alcuni casi addirittura l'invio di documenti per il riconoscimento, a quel punto tanto vale acquistare direttamente da un exchange. Gli unici acquirenti qui sul forum rimarrano i newbie, e i cambiavalute diventeranno il loro primo contatto che li introdurrà nel mondo bitcoin. |
|
|
|
Quasi nessuno accetta piu' ricariche online per via delle mille truffe e carte rubate o piene di fondi di dubbia provenienza che causano blocchi e casini vari.
il fatto è che fare la ricarica dal tabacchino/posta è una rottura, online è più comodo. Condivido, anche se mettendomi nei panni del venditore di bitcoin, capisco che il rischio di truffa è troppo alto: di fatto non c'è possibilità di sapere con certezza se chi sta comprando è consapevole di acquistare bitcoin. Se si potesse aggiungere un messaggio nella ricarica online sarebbe tutto più facile (per entrambe le parti). |
|
|
|
|
Come non detto, dal loro sito risulta che adesso non accettano più ricariche online.
|
|
|
|
Non ho esperienza diretta di uso di questo wallet. Tempo fa però ho trovato delle informazioni sul Case Wallet in questo sito: https://techcrunch.com/2015/05/04/case-is-an-insanely-secure-hardware-bitcoin-wallet/Case also stores a key in its encrypted online database.
...
But what if you lose your Case wallet? As you need two signatures to send bitcoins using Case, you won’t be able to recover your bitcoins. But fortunately the startup has a backup plan. It also stores a third key in an offline vault. You can retrieve this key after proving your identity to the company.
In sostanza se perdi il case/si rompe, rischi di non avere più i tuoi bitcoin! Non c'è un modo indipendente di spostare i bitcoin, bisogna sempre affidarsi alla compagnia che l'ha prodotto (che potrebbe scomparire tra qualche anno!) Se ne è parlato anche qui -> https://www.reddit.com/r/Bitcoin/comments/3mhe5p/case_wallet_teardown/In generale penso che la prima cosa da guardare in un wallet hardware (ma anche software) sia: ho la piena disponibilità delle chiavi private? Se perdo il wallet posso recuperarle in modo autonomo senza dover contare sul supporto di terzi? Questo dato mi sembra così importante che lo aggiungerei direttamente nella lista del primo post per ogni wallet. |
|
|
|
come fare - scaricare il sorgente di https://github.com/samr7/vanitygen- scompattare e entrare nella dir - installare questo pacchetto -> pcre versione dev sulla vostra distribuzione (banalmente su debian-like apt-cache search pcre per cercarlo) - avviare il comando 'make' Per chi volesse usare vanitygen (versione per CPU) e non oclvanitygen (versione per GPU), segnalo che è anche possibile scaricare una versione ottimizzata con la libreria secp256k1 usata anche da Core. I comandi su Ubuntu sono: sudo apt-get install automake autoconf git sudo apt-get install libgmp3-dev git clone https://github.com/klynastor/supervanitygen.gitcd supervanitygen make e infine: ./vanitygen $PATTERN Si dovrebbe osservare (a me è successo) un incremento di velocità di circa il 200%/250%. Features:
•Runs under the x86, x86_64, arm, and arm64 (aarch64) architectures.
•Includes fast assembly versions of SHA-256 for Intel CPUs with SSSE3, AVX, AVX2, and SHA extensions.
Limitations:
•Currently only supports Bitcoin compressed public keys.
•Does not support combining private keys via addition/multiplication methods.
link --> https://www.reddit.com/r/Bitcoin/comments/4rubin/introducing_super_vanitygen_fast_vanity_bitcoin/Assolutamente non bisogna fidarsi di siti come quello, invece è possibile affidarsi tranquillamente a servizi come vante.me (vedi anche il relativo post su reddit) o come vanity.coin.dance (con l'opzione "split key" selezionata). Come distinguere i servizi affidabili da quelli che non lo sono? Semplice: se il sito utilizza il metodo " split-key address generation" cioè in pratica se vi richiede anche di inviare una vostra chiave pubblica, allora non c'è problema, poiché la chiave privata che vi restituiranno andrà ricombinata con la vostra prima chiave privata per poter ottenere l'effettiva chiave privata relativa all'indirizzo vanity generato (in pratica il sito non può in nessun modo ricavare la chiave privata effettiva dell'indirizzo che genera! Di fatto esso prende come nuovo punto base della curva la vostra chiave pubblica e partendo da lì ottiene quanti passi bisogna fare per raggiungere la chiave pubblica relativa a un indirizzo vanity; ma per ottenere il percorso totale rispetto al punto base G bisogna anche conoscere la posizione relativa della chiave pubblica iniziale rispetto a G, cioè la chiave privata che voi avete generato e avete conservato). Riassumendo si ha la stessa sicurezza che si avrebbe generando un indirizzo in locale. Per ulteriori dettagli su metodo "split-key address generation": https://bitcointalk.org/index.php?topic=81865.msg901491#msg901491 EDIT: ho ricevuto richieste via PM riguardo il metodo "spli-key address". I passi da fare sono: 1) leggersi almeno una volta questo post : https://bitcointalk.org/index.php?topic=1339031.0#post_introduzionepotrà sembrarvi inutile, ma vi assicuro che se non sapete a cosa corrispondono una chiave pubblica e una chiave privata nella curva secp256k1 e qual è l'operazione non invertibile che collega chiave privata a chiave pubblica, non riuscirete a fidarvi del tutto del metodo perché non lo capirete; una chiave privata è sempre un "collegamento" tra due chiavi pubbliche note, di cui la prima è il punto base G della curva secp256k1 usata per il bitcoin, mentre la seconda è la cosiddetta chiave pubblica corrispondente alla chiave privata 2) adesso che sapete che cosa sono, generate in locale una coppia: chiave privata ' a' - chiave pubblica ' a*G' (dove G è il punto base della curva secp256k1) utilizzando il tool keyconv che si trova nella stessa directory di vanitygen (non si trova però in supervanitygen che non supporta questo metodo) ./keyconv -G
Pubkey (hex): 0420ec63d02da16c5f1a368be87969eaa611148e78f926c44a599ced25d376ed26e0412af50e1e6b6be6e6903e0b0bf85c6c6f80ae905012fcd3405606074769da
Privkey (hex): 3A49649658A57BA9B18C6B2F583629E8B06D96BC229D1C8D9138253066554BA4
Address: 1LCD7PoC86dkJNSZU1TAar1x1iGeVynSBU
Privkey: 5JFxSHfPFAGCD6Fp3RvSN3s6RXrv8vX7kDpJiZVNYyoLHDJs2Wk
NB: non fatevi ingannare dall'ordine dell'output: il software prima genera in modo random a (Privkey), da cui calcola facilmente a*G = P (Pubkey corrispondente). L'operazione inversa è impossibile ( da a*G non si può ricavare a, pur conoscendo G! ). L'indirizzo che si ricava dalla chiave pubblica in questo caso non serve a nulla. Riassumendo: a = 3A49649658A57BA9B18C6B2F583629E8B06D96BC229D1C8D9138253066554BA4 (formato hex) a = 5JFxSHfPFAGCD6Fp3RvSN3s6RXrv8vX7kDpJiZVNYyoLHDJs2Wk (formato WIF) a*G = 0420ec63d02da16c5f1a368be87969eaa611148e78f926c44a599ced25d376ed26e0412........ ....05606074769da 3) questo è l'unico passo che dovrebbe fare un sito per voi; in questo caso però provate voi stessi ad eseguire vanitygen fornendogli la vostra chiave pubblica come base di partenza: vanitygen troverà una chiave privata b a partire dalla chiave pubblica a*G che voi gli fornirete (NB: vanitygen non conosce assolutamente la chiave privata a da cui avete ricavato a*G con il tool keyconv) ./vanitygen 1Pippo -P 0420ec63d02da16c5f1a368be87969eaa611148e78f926c44a599ced25d376ed26e0412af50e1e6b6be6e6903e0b0bf85c6c6f80ae905012fcd3405606074769da
Difficulty: 259627881
Pattern: 1Pippo
Address: 1Pippos3rYCrso1yQ79ACqaDW2gmurwPeP
PrivkeyPart: 5JdQf3z7eMswHxJKFCnRUeDqBcYNiaJRmxLbECGPUvemPP4vLX4
Osservate che vanitygen vi fornisce in output soltanto una chiave privata b 'parziale': b = 6aff09a31962bec0c7e8bb740f0ff357066feb1ca6cdd065007f6c3f47bfe79a (formato hex) b = 5JdQf3z7eMswHxJKFCnRUeDqBcYNiaJRmxLbECGPUvemPP4vLX4 (formato WIF) Come ha ottenuto quella chiave privata? E' partito da a*G e ha iniziato ad aggiungere + G + G + G + ... b volte: a*G + G + G + G + ... = a*G + b*Gfinché ha ottenuto la chiave pubblica finale a*G + b*G da cui si ottiene l'indirizzo che contiene la stringa da voi impostata. Questo è l'unico dato che conosce chi ha materialmente effettuato il passo 3) per voi, la chiave pubblica relativa all'indirizzo 1Pippos3rYCrso1yQ79ACqaDW2gmurwPeP, non la sua chiave privata. 4) Per ottenere infine la chiave privata relativa alla chiave pubblica a*G + b*G, si fa una semplice somma: chiave pubblica finale = a*G + b*G = (a+b)*G --> quindi la chiave privata finale sarà la somma a + bPer calcolare la somma riutilizzate un'ultima volta il tool keycon: ./keyconv -c 5JFxSHfPFAGCD6Fp3RvSN3s6RXrv8vX7kDpJiZVNYyoLHDJs2Wk 5JdQf3z7eMswHxJKFCnRUeDqBcYNiaJRmxLbECGPUvemPP4vLX4
Address: 1Pippos3rYCrso1yQ79ACqaDW2gmurwPeP
Privkey: 5K55WfCQp4a9F3ArFSFxkeLoPYaNeMxToN67iai1o2bTVywy
: 1) vi faccio osservare che nel passo finale bisogna dare in pasto a keycon le due chiavi private a e b in formato WIF, non in formato esadecimale; nel nostro caso, usando il formato hex, facciamo un controllo con python per verificare che si tratti effettivamente di una somma: python
Python 2.7.8 (default, Oct 20 2014, 15:05:19)
[GCC 4.9.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a=0x3A49649658A57BA9B18C6B2F583629E8B06D96BC229D1C8D9138253066554BA4
>>> b=0x6aff09a31962bec0c7e8bb740f0ff357066feb1ca6cdd065007f6c3f47bfe79a
>>> n=115792089237316195423570985008687907852837564279074904382605163141518161494337 #ordine della curva
>>> print hex((a+b) % n) #la somma va fatta modulo 'n'
0xa5486e3972083a6a797526a367461d3fb6dd81d8c96aecf291b7916fae15333e
Ora, se inserite quest'ultima chiave privata in formato hex (senza il prefisso 0x) qui o meglio ancora qui vedrete che tutto torna, si tratta di una "banale" somma di due chiavi private, una vostra personale e l'altra generata con vanitygen! Ovviamente NON inserite la chiave privata finale che intendete utilizzare sul serio in un sito online per controllare che funzioni ... 2) se ancora non vi fidate, provate a inserire la seconda chiave privata b = 6aff09a31962bec0c7e8bb740f0ff357066feb1ca6cdd065007f6c3f47bfe79a qui e verificate che si ottiene l'indirizzo 179RvzLmR3pyb9U9qHyz2D4jaLJ8NmLEYi che nulla ha a che fare con quello vanity 1Pippos3rYCrso1yQ79ACqaDW2gmurwPeP 3) il punto delicato di tutta la faccenda è il punto 2) del procedimento, ovvero la generazione della chiave privata a. Se non vi fidate di keyconv, potete utilizzare il tool che preferite o direttamente il vostro wallet, purché esso vi fornisca la chiave privata in formato WIF e la relativa chiave pubblica in formato hex non compressa (deve iniziare con 04). Sul resto del procedimento non ci sono problemi legati alla sicurezza. |
|
|
|
Purse.io mi ha mandato una mail per informarmi che è possibile acquistare bitcoin tramite blockchain.info (che si appoggia a sua volta a Coinify) utilizzando una carta di credito/debito: https://support.purse.io/how-to/buy-bitcoin-blockchain-info-europe/Dagli screen sembra che le fee siano solo del 3%, non del 3,9% come riportato nel primo post (ma non l'ho verificato in prima persona). |
|
|
|
Perchè BitBoat non le accetta più?
bitboat non l'ho mai usato, mi confermi che le accettano? In effetti sul sito non mi sembra ci siano divieti in tal senso. Io una volta ho fatto un acquisto, ricarica online mediante postepay (da postepay a postepay), servizio veloce e senza problemi. |
|
|
|
|
Perchè BitBoat non le accetta più?
|
|
|
|
Good point. Collision resistance comes from the fact that its uniformly distributed.
good distribution --> collision resistance ? No, example: SuperFastHash http://softwareengineering.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speedI think the more important takeaway is that there are two classes of algorithms when it comes to collisions:
collisions rare: FNV-1, FNV-1a, DJB2, DJB2a, SDBM
collisions common: SuperFastHash, Loselose
And then there's the how evenly distributed the hashes are:
outstanding distribution: Murmur2, FNV-1a, SuperFastHash
excellent distribution: FNV-1
good distribution: SDBM, DJB2, DJB2a
horrible distribution: Loselose
collision resistance --> uniformity but uniformity != random uniformity https://research.neustar.biz/2012/02/02/choosing-a-good-hash-function-part-3/A hash function ought to distribute its keys uniformly across its output range.
Now, uniformity is different from random uniformity.
|
|
|
|
Segnalo questo articolo su come fare a sbloccare una transazione bloccata: http://www.nasdaq.com/article/what-to-do-if-your-bitcoin-transaction-gets-stuck-cm717300e un altro più tecnico/generale: https://gist.github.com/roybadami/7bd2ea56a06984fedace#user-content-stuck-transactionsUn grosso ruolo lo svolge il proprio wallet, se infatti esso: 1) consente di controllare quali output si spendono 2) consente di (ri)spendere output non confermati allora in questo caso si può tentare a mano sia la strategia RBF** che la strategia CPFP; per quest'ultima, si può anche fare a meno della collaborazione del ricevente qualora nella transazione originale almeno un output sia stato indirizzato di ritorno al proprio wallet (indirizzo del resto). In tal caso infatti basta tentare di rispendere quell'output non ancora confermato reindirizzandolo di nuovo verso il proprio wallet con delle fee adeguate a coprire sia la nuova tx che quella precedente, in modo da invogliare i miner a inserire entrambe le transazioni in un blocco. NB: si dice che CPFP sia nata per difendere il ricevente dalla nuova possibilità di essere defraudato fornita al mittente da RBF: CPFP relates to RBF as a way for a merchant to fight fraud. If a merchant detects that a payment they were expecting has been rerouted, they can raise the priority of their preferred transaction using CPFP. This is a contentious solution to make RBF acceptable. Alcuni wallet come Electrum e GreenAddress dovrebbero avere una specifica opzione "Opt-In RBF" che segnala ai miner che una certa transazione potrebbe essere sostituita in futuro con una che paga più fee; ecco un' analisi di Peter Todd sulla situazione dei wallet riguardo questa opzione e su come fosse facile effettuare una doppia spesa a insaputa del destinatario (l'articolo è del gennaio scorso) **Oggettivamente c'è molta confusione attorno a queste nuove possibilità di formare transazioni, per esempio RBF può significare: a) posso sostituire una transazione qualsiasi solo con un'altra quasi uguale per quanto riguarda input/output (in sostanza si possono aggiungere input e output, ma non togliere gli output precedenti nè diminuirne il valore assegnato --> "higher fee with superset of outputs of first spend") e con fee maggiorate (first seen safe replace-by-fee "FSS-RBF") b) posso sostituire solo una specifica transazione che ho precedentamente flaggato con " Opt-In RBF" con un'altra qualsiasi (anche cambiando gli address destinatari) (questa dovrebbe essere l'opzione con più chance di successo perchè adottata ufficialmente in Core); il flag (che si può anche attivare a mano modificando il campo nSequence della tx --> "Transactions opt-in to transaction replacement by setting nSequence < maxint-1 on at least one input" ) permette da una parte al miner di sapere che chi ha creato la transazione era già disposto ad "aggiornarla" ed eventualmente a sostituirla sin dal momento della sua creazione, dall'altra permette a colui che riceve il pagamento di ricevere un segnale (dovrebbe visualizzare un messaggio di allerta sul pericolo di una doppia spesa e quindi dovrebbe aspettare che la tx sia inclusa in un blocco prima di considerarla come un pagamento effettivo). "Opt-in" da "Option In" vuol dire in inglese: "Express permission by a customer, or a recipient of a mail, email, or other direct message to allow a marketer to send a merchandise, information, or more messages". E' una specie di assenso firmato che in questo caso rende una tx ufficialmente sostituibile con il permesso del proprietario.c) posso sostituire una transazione qualsiasi con un'altra che spende gli stessi input ma con output completamente differenti ( "full RBF", e Core dovrebbe indirizzarsi in futuro verso questa possibilità) Core per adesso ha scelto la seconda opzione, Opt-In RBF + CFPC : https://github.com/bitcoin/bitcoin/blob/fc23fee690477828e84a7886dbf208e9a96e82e2/doc/release-notes/release-notes-0.12.0.md#opt-in-replace-by-fee-transactions
https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.13.0.md#user-content-mining-transaction-selection-child-pays-for-parentAlcune osservazioni sulle motivazioni: https://www.reddit.com/r/Bitcoin/comments/3urm8o/optin_rbf_is_misunderstood_ask_questions_about_it/
The Core devs want to use Opt-in RBF to "compress" transactions and FSS-RBF Doesn't allow that.
FSS-RBF (1) results in larger transactions because you must add a new input rather than just adjust your change output, and (2) is a wallet implementor's nightmare to get right because it involves merging coins to update a fee. If you care about privacy and/or keeping sources of coins separate to defeat block chain analysis, FSS-RBF requires keeping pools of UTXOs available to update fees
I critici di FSS-RBF affermano inoltre che non è scontato stabilire cosa vuol dire "vista per prima" (dopotutto la blockchain nasce proprio per stabilire un ordine temporale in una serie di eventi che avvengono a distanza, mentre le transazioni in mempool non hanno una cronologia definita e univoca per tutti i nodi della rete), ma questo succede già di norma con tutte le transazioni (solo quelle viste per prima vengono accettate da un nodo, le altre che tentano di spendere gli stessi output non vengono accettate). Peter Todd, che ha creato la patch con Opt-in RBF per Core, sostiene comunque FSS-RBF, qui spiega come funziona FSS-RBF e quali sono i vantaggi: http://bitcoin-development.narkive.com/NgSiQBmM/bitcoin-development-first-seen-safe-replace-by-feeRiassumendo ci sono almeno 3 variabili di cui tener sempre conto: 1) bisogna conoscere a fondo il proprio wallet e come esso si regola con le transazioni non confermate (e come si fa ad esempio a far sì che la smetta di continuare a ritrasmettere una tx che si è appurato che nessun miner intende includere in un blocco) 2) bisogna sapere quali sono le condizioni del mercato per le fee per "indovinare" una fee adeguata 3) bisogna conoscere quali sono le esatte regole utilizzate dai miner (FSS-RBF, Opt-in RBF, Full RBF, CPFP) per poter costruire una seconda tx che abbia successo nell'annullare/sbloccare la prima Da osservare che queste policy riguardanti la sostituzione di una tx nella mempool non fanno parte delle regole del consenso, cioè è a discrezione dei full node e dei miner impostare la propria politica, e tutto questo rende più difficile e fumosa l'intera questione. Il grosso problema che vedo in mezzo a tutto questo tecnicismo è che è facile che in queste situazioni incappino soprattutto i nuovi arrivati nel mondo bitcoin, e non è un bel modo di conoscere il btc, dall'altra parte quelli un po' più "esperti" in generale non sono per nulla esperti in problemi di questo tipo perchè magari sono più attenti con le fee e quindi alla fine non sono in grado di dare consigli pratici non essendo mai capitati in situazioni del genere. Faccio infine notare che inviare una transazione non vuol dire pagare, ma al massimo si dimostra l'intenzione di effettuare un pagamento, quindi si tratta a tutti gli effetti di una "proposta" di pagamento alla rete che deve poi accettarla. Finchè un pagamento non è confermato i bitcoin rimangono in possesso di chi detiene le chiavi private (anche se momentaneamente potrebbero apparire come "congelati"), ed è sua responsabilità far in modo che questo pagamento arrivi in qualche modo al destinatario (penso soprattutto alla situazione in cui uno ha dei btc depositati presso un exchange/siti vari e deve ricevere un pagamento in sospeso). |
|
|
|
Try a loop. Count from 1 to a billion. Hash those. Include a large random salt.
For example:
xxxxxxxxxxxxxxxxxxxxxxxxxx00000001
xxxxxxxxxxxxxxxxxxxxxxxxxx00000002
xxxxxxxxxxxxxxxxxxxxxxxxxx00000003
xxxxxxxxxxxxxxxxxxxxxxxxxx00000004
...
xxxxxxxxxxxxxxxxxxxxxxxxxx99999996
xxxxxxxxxxxxxxxxxxxxxxxxxx99999997
xxxxxxxxxxxxxxxxxxxxxxxxxx99999998
xxxxxxxxxxxxxxxxxxxxxxxxxx99999999
Ok, I took your advice. I picked a block (# 277316, hash 0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4) and I made a loop with the nonce from 0 to 2^20: #!/usr/bin/env python
import hashlib
nomefile="dist_hash"
maxnonce=2**20
version='00000002'
previousblockhash='0000000000000002a7bbd25a417c0374cc55261021e8a9ca74442b01284f0569'
merkleroot='c91c008c26e50763e9f548bb8b2fc323735f73577effbc55502c51eb4cc7cf2e'
timestamp='52be093a'
difficultytarget='1903a30c'
nonce=0
def byteswap(a):
b='';
for i in range(0,len(a)/2+1): b=a[2*i:2*i+2]+b
return b
header=byteswap(version)+byteswap(previousblockhash)+byteswap(merkleroot)+byteswap(timestamp)+byteswap(difficultytarget)
with open(nomefile, 'w') as f:
f.write("NONCE" + "\t\t" + "BLOCK HEADER HASH" + "\n")
for nonce in range(0,maxnonce) : #924591752 is the best
nonce_st = byteswap("{0:0{1}x}".format(nonce,8)) #format: hex (8 bytes), little endian
hash_result = hashlib.sha256((header+nonce_st).decode('hex')).digest()
hash_result = hashlib.sha256(hash_result).hexdigest()
f.write("{0:0{1}}".format(nonce,8) + "\t" + byteswap(hash_result) + "\n")
Output sorted by ascending hash: NONCE BLOCK HEADER HASH
00073675 00001161c27946bfbc99e631e5cfd1bf979c27bd68207991cb97e3d054c3192b
00563775 00001f485a9ad567aeb6a18a514f28b807f6a5c43a166debdc74b7ac46a765ea
00108164 000024a77201aaa21f86a43878bc50ef8be511105b403cad9c4b99e6f6b5563c
00172165 00002f3ea713eef6411ca3b2ead29ce859b1330d05df76a298bed3cf9807d666
00661616 000033f44a25e97b6dca43e4ba8dc9fe0e0b48777cc936f774433ce6244c71d4
...
...
00052351 ffffaa0a77c61b614e110c280bbb06c6d48561df1d6b064e4718a75ca97d509f
00845204 ffffc35f3b2a105c5a9d057b03e5eea26bb83f5d6482070be0eaa28a4dcb2f6b
00999281 ffffc4ee9128c730094017f32614562b434c3c782263b4adeb2a64fdc14a8584
00245490 ffffe3579d3529b5fe46b12db6eb472a6d5df707d4a738b7259ea7b2c62bae9b
00282384 ffffef1566a137349da9e6e02ecd638c7508933c08428f099a7f0808f10d7c6f
The last digit distribution: TOT = 2^20 = 1048576
last
digit fr. prob. unif. --> 1/16=0.0625
0 62401 0.062401
1 62764 0.062764
2 62608 0.062608
3 62638 0.062638
4 62465 0.062465
5 62695 0.062695
6 62351 0.062351
7 62706 0.062706
8 62093 0.062093 --> MIN = -0.000407 = -0.65%
9 62340 0.06234
10 (a) 62884 0.062884 --> MAX = +0.000384 = +0.61%
11 (b) 62412 0.062412
12 (c) 62455 0.062455
13 (d) 62204 0.062204
14 (e) 62220 0.06222
15 (f) 62764 0.062764
and the last 2 digits distribution: last 2
digits fr. prob. unif. --> 1/256=0.00390625
78 (4E) 3751 0.003751 MIN --> -0.00015525 = -3,97%
...........................................
...........................................
47 (8A) 4117 0.004117 MAX --> +0.00021075 = +5.40%
|
|
|
|
I have checked the last digit distribution of every block hash (16 possible values and 442034 blocks): BLOCKS : from 0 to 442033 (TOT = 442034)
last
digit fr. prob. unif. --> 1/16=0.0625
0 27520 0.0622576543886
1 27881 0.0630743336485
2 27952 0.0632349547772 MAX --> =+0.00073495777 = +1,16%
3 27892 0.0630992186121
4 27543 0.0623096865852
5 27339 0.0618481836239
6 27674 0.062606043879
7 27691 0.0626445024591
8 27428 0.0620495256021
9 27203 0.061540514983 MIN --> -0.000959485 = -1.54%
10 (a) 27594 0.0624250623255
11 (b) 27554 0.0623345715488
12 (c) 27863 0.063033612799
13 (d) 27616 0.0624748322527
14 (e) 27619 0.062481619061
15 (f) 27665 0.0625856834542
I think it's ok. |
|
|
|
quindi ci si allontanera' sempre di piu' dal concetto di valuta, (tipo dollaro)
e si avvicinera' sempre piu' al concetto di bene rifugio (tipo oro)
con un grosso vantaggio rispetto all'oro che il trasporto (transazione)
sara' sempre piu' economico, immadiato, sicuro, senza formalita'
rispetto al trasporto dello stesso valore in oro.
E anche l'utenza diventra' sempre piu' di holder ossia di gente che
lo usa come bene rifugio piuttosto che come valuta.
A proposito mi autocito: Non è neanche detto che bitcoin sarebbe adeguato per la conservazione del valore ("riserva di valore"), in quanto perdendo la sua proprietà di mezzo di pagamento che oggi gli si attribuisce (o sarebbe più corretto dire: la proprietà di mezzo di pagamento che molti scommettono che avrà in un futuro prossimo, in quanto ad oggi sono ancora pochi che lo accettano come pagamento) potrebbe perdere valore e basta.
Basti pensare, per esempio, che fra tot anni, quando la ricompensa del blocco sarà notevolmente diminuita, saranno solo le fee a ricompensare il lavoro di mantenimento della blockchain da parte dei miner. Se non aumenterà la dimensione dei blocchi, o aumenteranno notevolmente le fee per transazione (che diventeranno quindi una specie di tassa di deposito dei btc, che andrà pagata ai miner al momento della loro movimentazione) o il lavoro dei miner diminuirà di pari passo alla loro retribuzione, rendendo meno sicura la blockchain (e quindi meno sicuri i nostri btc, che per questo perderebbero comunque valore).
Non darei per scontato quindi che la strada vada per forza verso un concetto di bitcoin come riserva di valore, penso infatti che: 1) il suo valore rimanga legato comunque alla sua proprietà di mezzo di pagamento, per questo è nato (se fosse poco utilizzato come pagamento alla fine perderebbe interesse, con la discesa dei compensi per blocchi fra qualche anno e poche transazioni le fee non sarebbero sufficienti per i miner, quindi il sistema non reggerebbe e perderebbe di valore, alla fine i miner stessi voterebbero qualche cambiamento per non perdere soldi) 2) nel mondo ci sia forte richiesta di mezzi di pagamento liberi (vedi adesso India ma anche tanti altri) 3) nel confronto attuale tra le caratteristiche di bitcoin e quelle di molte monete tradizionali al momento bitcoin è già nettamente in vantaggio (nonostante esso sia ancora migliorabile), inoltre btc è la prima criptovaluta della storia, tutto ciò gli dà qualche vantaggio competitivo allo stato attuale (e spiega la lentezza nell'adozione di provvedimenti migliorativi). Ma questo vantaggio attuale non può continuare all'infinito, esiste sempre la possibilità di fork, contenziosi o meno, ci sono le altcoin, quindi rischia, se non nel brevissimo, ma nel medio termine di perdere terreno a vantaggio di qualche altra valuta. |
|
|
|
siccome nella vita ho imparato che sono i fatti che contano e non le parole,
e considerando che i miner segwit non l'hanno votato, XT non l'hanno votato, classic non l'hanno votato, unlimited non l'hanno votato...
il messaggio e' chiaro: a loro va bene cosi'.
Io la vedo così: astrattamente parlando utilizzerei sicuramente Unlimited, leggendo questo articolo e quest'altro mi pare evidente che sia il client che attualmente meglio interpreti lo spirito del bitcoin. Ma mettiamoci adesso per un momento nei panni di un miner: chi mina in questo momento sta guadagnando e i propri profitti sono legati indissolubilmente alla richiesta/giudizio del mercato, e qual è questo giudizio? Al momento l'andamento del prezzo ci dice che nell'ultimo anno la soddisfazione e le aspettative del mercato sono notevolmente cresciute, cioè al mercato così va bene (anche se forse potrebbe andare meglio). La base di utilizzatori bitcoin si sta ampliando, sono più le persone che entrano di quelle che escono, e il prezzo per entrare continua a salire. Perchè un miner dovrebbe cambiare regole, votando ad esempio per una svolta tecnicamente complessa da decifrare, soprattutto nelle sue implicazioni, come è segwit? Mettendo così a rischio un guadagno al momento sicuro? A me pare evidente che finchè io faccio soldi minando e il valore del btc continua a essere alto, non mi conviene cambiare, a meno che il mercato stesso (e lui per primo, non certo io!) non mi segnali che qualcosa non va (facendo diminuire il prezzo) e solo allora le cose potrebbero cambiare. Le prospettive sono talmente positive per i miner che nell'ultimo anno la potenza computazionale messa in campo da questi è quadruplicata, una cosa mai vista. Essi aumentano il loro rischio mettendo più soldi in un sistema che conoscono, non rischiano invece cambiando il sistema in qualcosa che non sanno come potrebbe evolvere. Dal loro punto di vista la situazione attuale è che si aspettano di fare un sacco di soldi (per questo stanno investendo tanto, è il loro mestiere), mentre il nostro di utenti dovrebbe essere quello di manifestare un certo dissenso facendo calare il valore del btc. Se nella realtà contano i fatti e non le parole: 1) i miner stanno investendo un sacco di soldi, ergo: scommettono su un andamento positivo del bitcoin e non vedono motivi per cambiare (a loro cosa interessa dei blocchi pieni e delle regole del consenso e del p2p? Finchè al mercato va bene, va bene anche a loro) 2) gli utenti a parole sono molto preoccupati: su questo forum e non solo molti sono preoccupatissimi per il futuro del bitcoin, per la decentralizzazione, ecc. ma cosa fanno in pratica? Continuano a holdare o a comprare nuovi bitcoin, cioè a investire sempre di più (altrimenti il prezzo non aumenterebbe). Secondo me chi è veramente preoccupato dovrebbe di logica vendere i propri btc, eppure in una fase di stallo sui vari fork tutti comprano. I "veramente" preoccupati sono solo una minoranza. Quindi la sostanza è che nei loro comportamenti concreti sia miner che utenti giudicano molto favorevolemente il bitcoin. Forse noi ci facciamo tanti problemi su libertà, p2p, decentralizzazione, magic number, altcoin varie, ecc. e ci dimentichiamo chi sono i concorrenti di btc e quanto sono messi male: basti pensare ad esempio che in quei paesi in via di sviluppo con monete nazionali ridicole quanto il nostro vituperato bitcoin con blocchi limitati a 1 mega rimanga di gran lunga più appetibile delle loro monete nazionali, ho letto che btc viene pagato anche a +30% del prezzo di mercato. Vogliamo veramente che si cambi? Auguriamoci allora un btc a 300 dollari (con reward a 12,5 btc, non a 25 come era qualche mese fa), vedrai che ci si muoverà in quel caso, e pure di fretta, ma non a 700/800 dollari * 12,5 btc a blocco ... |
|
|
|
Obviously block hashes from blockchain are not evenly distributed (because of difficulty and retarget): BLOCKS : from 0 to 442033 (TOT = 442034)
height hash
0 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
1 00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048
...
10000 0000000099c744455f58e6c6e98b671e1bf7f37346bfd4cf5d0274ad8ee660cb
10001 00000000f01df1dbc52bce6d8d31167a8fef76f1a8eb67897469cf92205e806b
...
50000 000000001aeae195809d120b5d66a39c83eb48792e068f8ea1fea19d84a4278a
50001 000000001c920d495e1eeef2452b6d1c6c229a919b28196c103ecffebabee141
...
100000 000000000003ba27aa200b1cecaad478d2b00432346c3f1f3986da1afd33e506
100001 00000000000080b66c911bd5ba14a74260057311eaeb1982802f7010f1a9f090
...
200000 000000000000034a7dedef4a161fa058a2d67a173a90155f3a2fe6fc132e0ebf
200001 00000000000002e3269b8a00caf315115297c626f954770e8398470d7f387e1c
...
300000 000000000000000082ccf8f1557c5d40b21edabb18d2d691cfbf87118bac7254
300001 000000000000000049a0914d83df36982c77ac1f65ade6a52bdced2ce312aba9
...
400000 000000000000000004ec466ce4732fe6f1ed1cddc2ed4b328fff5224276e3f6f
400001 000000000000000005421b1b2ee6d06d037557d7f5ec96852542413cfed40c22
...
442032 000000000000000000b6a5c60d2509768b29f4b49ceda2679bc6d33f99c8adba
442033 000000000000000000bf88951b0bd245474265cc6a2a1b38ac8ef78c8612158a
So I have checked the last digit distribution of every hash (16 possible values): BLOCKS : from 0 to 442033 (TOT = 442034)
last
digit fr. prob. unif. --> 1/16=0.0625
0 27520 0.0622576543886
1 27881 0.0630743336485
2 27952 0.0632349547772 MAX --> =+0.00073495777 = +1,16%
3 27892 0.0630992186121
4 27543 0.0623096865852
5 27339 0.0618481836239
6 27674 0.062606043879
7 27691 0.0626445024591
8 27428 0.0620495256021
9 27203 0.061540514983 MIN --> -0.000959485 = -1.54%
10 (a) 27594 0.0624250623255
11 (b) 27554 0.0623345715488
12 (c) 27863 0.063033612799
13 (d) 27616 0.0624748322527
14 (e) 27619 0.062481619061
15 (f) 27665 0.0625856834542
I think it's ok. Out of curiosity, I have checked the last 2 digits distribution (256 possible values) too: BLOCKS : from 0 to 442033 (TOT = 442034)
last 2
digits fr. prob. unif. --> 1/256=0.00390625
71 (47) 1891 0.0042779514698 MAX --> =+0.0003717 = +9,516%
...................................................
...................................................
...................................................
138 (8a) 1622 0.0036694009963 MIN --> =-0.000236849 = -6,06%
and the last 3 digits distribution (4096 possible values): BLOCKS : from 0 to 442033 (TOT = 442034)
last 3
digits fr. prob. unif. --> 1/4096=0.000024414
2686 (A7E) 147 0.000332553604474 MAX --> 0.00008841 = +36,21%
.................................................
.................................................
.................................................
3139 (C43) 75 0.000169670206364 MIN --> -0.000074470419 = -30,5%
How do you think about these results? These distributions are okay? |
|
|
|
|
Per poter prendere quei soldi (a patto di superare le problematiche relative all'accettazione di un miner di una tx non proprio standard) i passi sarebbero:
1) prima di broadcastare di nuovo la vecchia tx, bisogna importare la chiave privata dell'indirizzo di arrivo nel proprio wallet
2) creare a firmare una transazione che sposti quei btc dall'indirizzo ormai pubblico a un proprio indirizzo
3) eliminare la chiave dell'indirizzo 1GQrjuC59UuDv3LqbhPHX5mREDY4521f12 dal proprio wallet
3) quindi inviare contemporanemente le due tx (la vecchia e la nuova che spende gli output della prima) sperando che vengano incluse entrambe nello stesso blocco; in questo modo i btc non saranno mai legati neanche per un istante all'indirizzo 1GQrjuC59UuDv3LqbhPHX5mREDY4521f12. Da notare che la seconda tx può essere inclusa solo se viene inclusa la prima (ma non il viceversa).
|
|
|
|
|
Show Posts
