Non mi risulta che Bitboat non funzioni più, da qualche tempo hanno semplicemente sospeso le vendite nelle ore serali/notte.

Risolto in 2 passaggi:

1) configurato port mapping sul router
2) configurato firewall di McAfee

 

Nella configurazione della virtual macchine, dispositivo Network Adapter, alla voce "Network Connection" è selezionata la voce "NAT: Used to share the host's IP address"

Non ho settato nulla invece nella configurazione del router, dal momento che Bitcoin Core riusciva a sincronizzarsi con la rete ho dato per scontato che tutto andasse bene.

EDIT: con il comando "bitcoin-cli getinfo" ottengo l'informazione che il mio nodo ha 8 connessioni.

Non vedo il mio nodo. Se in fondo alla pagina alla voce

JOIN THE NETWORK
Be part of the Bitcoin network by running a full Bitcoin node, e.g. Bitcoin Core.

clicco su CHECK NODE ottengo

82:.:.:..:8333 is unreachable.

Eppure bitcoind sta girando e di default dovrebbe essere attivata l'opzione listen=1. 

Bitcoin Core è in esecuzione su Ubuntu 14.10 che gira su macchina virtualizzata (VMware Player), e il tutto gira a sua volta su un pc Windows 7.

Connessione VDSL Flat Telecom.

Finchè spammano inviandomi dei soldi mi sta anche bene, il problema è che molti rispondono inviando cifre ben più alte ...

I sell my C.A.T. Core License + Bter interface API. If you want to add another exchange, contact Sampey.

This program is very good, it lends itself to the job. I sell it just because I'm not longer interested in trading.

I will give you a good price.  

L'altro giorno mi è arrivato 0,0001 BTC mediante questa transazione:  

https://blockchain.info/tx/c1b3e699aa454ed0c31760d41393e47f95c0ca6bc78a674ec7802743021acb81

Come si vede in cima alla pagina di blockchain.info, è presente un'annotazione pubblica relativa alla transazione:


quindi il "pagamento" mi è arrivato da http://getxbtc.com/ .

Tralasciando ogni commento sulla tipologia di investimento proposta in questo sito, mi domando: da dove hanno preso il mio indirizzo?
Nel mio caso si tratta di un indirizzo del resto generato una ventina di giorni fa per un trasferimento di fondi effettuato dal mio wallet locale verso TRT (e utilizzato solo in quella occasione).
Avranno scelto a caso degli address dalla blockchain e io sono stato uno dei "fortunati"?

Quoto anch'io il Doodle.

La dimensione del database degli UTXO nell'ultimo anno è raddoppiata, attualmente siamo a circa 650 mega su disco (4 GB decompressi in RAM).
Questo fatto potrebbe pesare nel dibattito che coinvolge anche gli sviluppatori di Bitcoin Core sull'opportunità o meno di portare la dimensione massima di 1 blocco da 1 a 20 mega (la qual cosa verosimilmente accelererebbe il ritmo di crescita degli UTXO).

In un futuro non troppo lontano quindi la memoria di un pc normale potrebbe non bastare per contenere tutti gli UTXO, nel qual caso una parte di questi dovrebbe essere lasciata su disco fisso e questo rallenterebbe parecchio il processo di validazione dei blocchi e quindi di sincronizzazione con la block chain.

Fonte: articolo di Gavin Andresen.

Anche se usi sendfrom non si sa da quale address di quale account partiranno i btc. L'unica differenza con sendtoaddress è che nel primo caso almeno i bilanci virtuali di ogni account si aggiornano automaticamente in modo corretto.

Sì ma così di fatto è inutilizzabile per gli scopi di TheBomber999, 1 account = 1 wallet = 1 copia della block chain fanno 30 GB per utente.
Non che il metodo con l'opzione -walletfile sia comodo e particolarmente adatto allo scopo  



Ma se utilizzi il comando "sendrawtransaction" puoi scegliere sì l'UTXO ma non l'account, poichè quel comando, come succede per "sendtoaddress", addebita la spesa solo sul bilancio del default account indipendentemente dall'account a cui è associato l'indirizzo da cui si sceglie di muovere i btc.

Quindi anche se si scegliesse specificatamente di spendere un UTXO di un indirizzo associato all'account Pippo, toccherebbe riaggiustare in seguito a mano con un "move" la situazione, altrimenti con "getbalance Pippo" (o "listaccounts") non si otterrebbe il bilancio corretto relativo all'account Pippo dopo la rawtransaction; in teoria il bilancio di Pippo non dovrebbe proprio essere toccato da una rawtransaction.

A tal proposito cito il seguente post di Andresen :

Dal mio punto di vista, per quanto non conosca a fondo tutti i dettagli della gestione della funzionalità account, il sistema mi sembra già completo così com'è. Perchè l'account Pluto dovrebbere effettuare un pagamento tramite "sendfrom" dal momento che il suo bilancio è a 0? C'è un motivo logico per cui il comando "sendfrom Pluto" nel primo caso non funzionerebbe.

Il comando "move" è utile in 2 contesti:
- se l'utente A vuole pagare l'utente B, entrambi clienti che si appoggiano allo stesso wallet, quindi si effettua una transazione virtuale tra account senza usare la blockchain e quindi senza fee
- se si vuole effettuare una transazione tra l'account di default e quello di un altro cliente (o viceversa), anche qui senza pagare fee

Ma ripeto se Pluto non ha fondi perchè dovrebbe effettuare un pagamento? Che senso ha sottrarre quei fondi allora dal bilancio dell'account di Pippo?




Secondo me come lo vuoi tu è impossibile (ma attendi il parere di qualche esperto tipo FaSan).

Se invece vuoi semplicemente usare un sistema multi-wallet, si può fare anche con Bitcoin Core ma non è proprio l'ideale (altri client come Armory hanno già integrata invece questa funzionalità mentre Bitcoin Core non è pensato per questo tipo di utilizzo). Con Bitcoin Core si possono usare più wallet tramite l'opzione -walletfile ma con qualche scocciatura tipo stoppare Bitcoin Core ogni volta che si fa lo switch tra un wallet e un altro e rilanciarlo con l'opzione -rescan --> vedi qui e qui.  
Il problema è che con Bitcon Core non si riesce, per quanto ne so, a lavorare contemporaneamente con più di 1 wallet alla volta.

Sto cercando anch'io di capire meglio questa storia degli "account".

Se ho ben capito un portafoglio può avere più account, più precisamente ogni indirizzo ( o gruppo di indirizzi ) di un wallet può essere associato a un account.
L'associazione funziona solo in ricezione però, nel senso che ogni volta che un indirizzo associato a un account A riceve dei bitcoin si aggiorna (in positivo) il bilancio dell'account A.
Il discorso cambia invece se si vogliono spendere dei btc, utilizzando il comando "sendfrom A indirizzo_destinatario 10.00" quei 10 btc vengono scalati dal bilancio di A ma non si sa da quali indirizzi vengano effettivamente prelevati i 10 btc, poichè l'algoritmo Coin Selection lavora a livello di wallet e non di account.

Quindi è chiaro che l'associazione indirizzo-account non è valida se mi serve stabilire il bilancio dell'account A, nel senso che il bilancio di A non è dato in generale dalla somma dei bilanci di tutti gli indirizzi associati ad A (ad esempio un indirizzo "di A" potrebbe essere stato svuotato a causa di un "sendfrom B", anche se gli indirizzi "di B" avevano fondi sufficienti, poichè in un indirizzo di A c'era un UTXO che corrispondeva esattamente alla somma che B doveva pagare, e l'algoritmo Coin Selection tenta sempre prima questa strada).

Il concetto di account serve evidentemente solo se una persona vuole istituire un wallet che funzioni come una specie di banca, che raccolga cioè i fondi di tante altre persone. Alla fine sapere "dove" sono esattamente i soldi, e soprattutto sapere con "quali" soldi si effettuano i pagamenti di un account non ha senso.

Per tornare alla domanda di TheBomber999, secondo me la transazione "sendfrom Pluto" parte senz'altro perchè la condizione "fondi sufficienti sull'account" è soddisfatta; questa transazione spende il btc dell'address associato all'account di Pippo poichè l'associazione address-account ripeto vale solo in ricezione, non per l'invio: in realtà "quel" btc non è mai stato "di" Pippo.  

Ulteriori informazioni si possono trovare in questo wiki Account explained. Tra le altre cose non ho capito se l'unico account che può andare in negativo è il Default Account (questo può succedere se si inviano dei btc con il comando "sendtoaddress" al posto di "sendfrom") o se possono diventare negativi (in quali casi?) anche gli altri account.

Bene, almeno ad una persona è servita la traduzione!  



I 5 casi sono forse un po' estremi ma sicuramente esemplificativi. La situazione più probabile è quella descritta nel paragrafo "Perdita parziale di fondi", se uno fa una copia di backup del wallet di Bitcoin Core e dopo effettua più di 100 transazioni che generano nuovi indirizzi, almeno una parte dei fondi rischia di perderli davvero qualora dovesse ripristinare quella copia di backup ormai datata. Comunque ho la sensazione che molti utenti (anche non alle prime armi) abbiano perso dei btc a causa degli indirizzi dei resti.

L'algoritmo di selezione degli UTXO dal proprio portafoglio (Coin Select Algorithm), almeno per Bitcoin Core dovrebbe funzionare così:

1) Se uno degli UTXO del wallet corrisponde esattamente al pagamento da effettuare, viene selezionato quello

2) Se la somma di tutti gli UTXO minori del pagamento corrisponde esattamente al pagamento, vengono selezionati quelli

3) Se la somma di tutti gli UTXO minori del pagamento è inferiore al pagamento, viene selezionato allora il minore tra gli UTXO che eccede il pagamento ( generando così un resto più piccolo possibile )

4) Come ultima opzione viene effettuato un ciclo di 1000 combinazioni casuali degli UTXO presenti nel wallet, se una di queste combinazioni corrisponde esattamente alla cifra da inviare, il ciclo si interrompe e viene scelta quella combinazione di UTXO, altrimenti viene scelta la minore tra
    - la minore, all'interno del gruppo di 1000, tra le combinazioni che eccedono la cifra da inviare
    - il minore tra i singoli UTXO che eccedono la cifra da inviare

I vantaggi di questo criterio di selezione sono che spesso si hanno transazioni con pochi UTXO ( quindi basse fee), ogni tanto vengono riuniti molti piccoli UTXO, c'è un minimo di protezione della privacy perchè non è facile capire dall'esterno quali indirizzi appartengono allo stesso wallet. L'algoritmo, che è stato concepito per minimizzare l'entità dei resti, come svantaggio produce però alla lunga molti UTXO "piccoli".

Per avere una descrizione più precisa di questo algoritmo con l'aggiunta di qualche esempio basta leggersi la seguente spiegazione.

Da notare che l'intero processo è applicato prima solo all'insieme degli UTXO che hanno almeno 6 conferme (oppure 1 conferma per i btc che sono stati "mossi" all'interno dello stesso wallet), e in seguito, se questo insieme è vuoto/insufficiente a coprire il pagamento,  l'insieme degli UTXO su cui l'algoritmo va a cercare i fondi viene allargato in 2 passaggi successivi. I dettagli si trovano implementati nel codice sorgente in wallet.cpp nella funzione SelectCoins.

Segnalo questo thread in inglese in cui è stato osservato che la dimensione dell'insieme degli UTXO (output non spesi delle transazioni) cresce in maniera molto più marcata la domenica rispetto agli altri giorni della settimana.

Trovo in generale sempre interessanti le analisi dei dati della blockchain (come quelle effettuate ad esempio anche dal nostro gbianchi). Per chi fosse interessato segnalo anche questo articolo sull'età dei bitcoin in circolazione  (cioè da quanto tempo sono fermi in un indirizzo).

Altra transazione senza problemi con ghibly79!

Esatto!

Ecco il pezzo che mi mancava, allora adesso torna tutto. Da notare che l'utente "DefaultTrust" mi compare con trust rosso -4 


Infatti ho provato e verificato che è proprio così 

Allora ho fatto una prova: ho inserito nella mia trustlist solo la parola chiave "DefaultTrust" e ho monitorato i trust relativi all'utente Rassah.

Quindi, variando il parametro depth, ho ottenuto:

depth 0  --> trust 0 0 0 (0)

depth 1 --> trust  38 0 16 (16)

depth 2 --> trust 38 0 16 (16)

depth 3 --> trust 53 0 22 (22)

depth 4 --> trust 53 0 22 (22)

In effetti, avendo Rassah ottenuto trust positivi dall'utente theymos della default list, mi sarei aspettato che già con depth 0 comparissero questi trust.
In conclusione serve depth 1 per "abilitare" i giudizi della trustlist come fatto notare da redsn0w.