Innanzittutto non si dovrebbe mai fare l'import ma solo lo sweep di una chiave privata, in quanto la logica della sua creazione è estranea a quella con cui sono stati creati gli altri indirizzi del proprio portafogli, poichè in caso di perdita del wallet quell'indirizzo non sarebbe recuperabile con il seed.

In ogni caso, importare una chiave privata "pubblica" come quella di cui si sta parlando non ha senso, a meno che non si sposti immediatamente il suo contenuto in un altro indirizzo.  Quindi in ogni caso poi andrebbe eliminata (esattamente come fa lo sweep).

Non credo che la gestione degli indirizzi del resto sia così stramba per cui un portafoglio assegni il resto a "caso": ad esempio Armory (che cito perchè lo conosco)  genera sempre un nuovo indirizzo per il resto a ogni transazione. Alcuni wallet invece hanno preimpostato come indirizzo per il resto semplicemente l'indirizzo di partenza, in generale ripeto però dubito che i resti vengano rispediti a caso in un indirizzo già posseduto, soprattutto se si tratta di un indirizzo 'spurio' perchè importato dall'esterno e quindi estraneo alla logica di creazione del proprio wallet.

Certo se non si conosce il principio con cui il proprio wallet gestisce gli indirizzi dei resti, basta importare la chiave per i 3 minuti necessari a firmare una nuova transazione e quindi eliminare la chiave dal portafoglio, non mi sembra un pericolo così grave.  


EDIT:
Riprendendo la transazione oggetto di questo thread:



1) provando a trasmettere la tx con coin.b -->  https://coinb.in/#broadcast
si ottiene come previsto il messaggio di dust:




2) provando a trasmettere la tx mediante https://blockchain.info/it/pushtx si ottiene invece il seguente messaggio di errore:

Non-canonical signature: High S Value  --> quindi bisognerebbe anche estrarre la firma e modificare la sua seconda parte così: s = n-s dove n è l'ordine della curva secp256k1  
(n = 115792089237316195423570985008687907852837564279074904382605163141518161494337)

Premetto che per dare consigli pratici bisognerebbe aver provato almeno una volta ad utilizzare uno di questi metodi, e io non ne ho utilizzato finora neanche uno.

Guardando alla sezione internazionale, ci sono vari suggerimenti:

1) aspettare che la rete si dimentichi della tx e poi reinviarla normalmente con fee maggiorate
-->  https://bitcointalk.org/index.php?topic=232979.0  (strategia Wait & Resend)

2) Replace By Fee (RBF) (ogni miner poi la utilizza come vuole, mi pare di aver capito che di default Bitcoin Core richieda che solo le transazioni marcate in modo speciale possono essere sostituite: "A transaction must be marked replaceable (sequence number below MAX-1) in order for the opt-in RBF implementation to treat it as replaceable." , quindi se uno ha inviato in modo "normale" una transazione che poi si blocca, come fa poi a sostituirla? Non mi è chiaro)

3) Child Pays for Parent (CPFP)  (Already implemented in Android Wallet and Eligius mining pool): mai usata

Da notare comunque che si può sempre creare una seconda transazione (deve farlo il ricevente) a mano, senza bisogno di altro:

"You can create a transaction which spends the output to yourself, attaching a fee to that transaction. In order for miners to grab the transaction fee on that transaction, they would have to also mine the original transaction. Likely, you'd have to do this by hand, but software could be written to simplify doing it. No protocol changes needed"

4) Qui si trova un programmino open source che permette di creare una transazione sfruttando RBF o CPFP (Bitcoin Transaction Fee Booster - mai usato)

5) se proprio si è disperati si può contattare qualcuno come macbook-air che ha accesso a una pool --> https://bitcointalk.org/index.php?topic=700411.0 pregandolo (dietro compenso immagino) di includere la propria tx in un blocco

La cosa più semplice a livello pratico sarebbe l'opzione 5) (ma anche la meno pulita), anche la 3) non è male, ma deve essere il ricevente che si occupa di rendere effettivo il pagamento che riceve in modo "non confermato".
Per dare consigli più pratici, ripeto, bisognerebbe avere usato in prima persona uno di questi metodi e fare un piccolo how-to, altrimenti rimangono ragionamenti un po' teorici e poco utili soprattutto per i nuovi arrivati.

Alcune considerazioni teoriche su CPFP : https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008232.html

Data una transazione bloccata a causa di fee insufficienti che sposti fondi da A --> B (indirizzo di partenza e indirizzo di arrivo), ci sono almeno due modi previsti per sbloccarla:

1)RBF -  replace by fee : ho pagato troppo poco, aggiungo altri soldi

2)CPFP - Child pays for parent: ho pagato troppo poco, paga per me colui che è destinatario della transazione

Oltre a RBF di cui si è parlato nel primo post esiste quindi un altro metodo, CPFP,  per sbloccare delle transazioni, supportato da Core 0.13.0 in poi  --> http://bitcoin.stackexchange.com/questions/49723/replace-by-fee-vs-child-pays-for-parent
https://bitcoincore.org/en/faq/optin_rbf/#what-is-child-pays-for-parent-cpfp

Questo metodo è utile nel caso in cui, dopo aver inviato la transazione che rimane bloccata, si perda la chiave privata relativa all'indirizzo A di partenza. In questo caso infatti non è più possibile rifare un'altra transazione da A a B con più fee e firmarla (metodo RBF). In questa particolare situazione i fondi rimarrebbero vincolati per sempre all'indirizzo A, senza poter essere più spesi, pur esistendo una tx regolarmente firmata che potrebbe sbloccarli (se solo un miner decidesse di includerla in un blocco).

Con CPFP si può creare allora una seconda transazione da B -> C che muove i btc dall'indirizzo B fornendo fee sufficienti a indurre i miner a includere nel blocco sia la transazione bloccata A -> B che la successiva B -> C (che da sola ovviamente non sarebbe valida senza la prima transazione).
L'onere dello sbloccaggio quindi ricade su colui che possiede la chiave dell'indirizzo di arrivo B della prima tx.



A me questo link non funziona, non so se sia solo una questione temporanea. Sulla situazione di diffusione di questa patch (la cui adozione è quantificata a maggio scorso nel 20% dell'hash power) qui c'è un articolo fatto molto bene (non parla solo di GreenAddress)-> https://bitcoinmagazine.com/articles/greenaddress-is-first-bitcoin-wallet-to-launch-replace-by-fee-bitcoin-transactions-miner-adoption-slow-1463516896.



Ma mi pare ci sia comunque un minimo di fee, sarebbe bello se ci fosse invece un modo per indirizzare direttamente ai miner qualche tx con fee insufficienti per sbloccarle, non mi sembra questo il caso.

Dunque la transazione dall'indirizzo 1FWY5DxbgVSBbCwCDMwsgSPUCKQKWfjYWa invia:

     0.01299300 btc              a 1GQrjuC59UuDv3LqbhPHX5mREDY4521f12
     0.00000000 btc indietro a 1FWY5DxbgVSBbCwCDMwsgSPUCKQKWfjYWa
     0.00001000 btc    di fee al miner


Qual è il problema della transazione, perchè non è stata accettata?

1) la fee di 1000 satoshi era sufficiente nel 2015
2) il fatto di rimandare il resto all'indirizzo di partenza è ovviamente una situazione standard
3) è il secondo output che vale 0 il problema? Sì

infatti --> https://github.com/bitcoin/bitcoin/blob/0.10/src/primitives/transaction.h#L137


Da notare che la funzione IsDust è un metodo della classe TxOut, cioè è riferito agli output.
(la sua introduzione è dovuta a Mike Hearn che la propose a fine 2013 -> https://github.com/bitcoin/bitcoin/commit/6a4c196dd64da2fd33dc7ae77a8cdd3e4cf0eff1#diff-279f95e952b2c1cff13bdfbcd7bc36eeR151)

e quindi la tua tx fa parte delle cosiddette "transazioni non standard" --> https://bitcoin.org/en/developer-guide#non-standard-transactions

Cosa vuol dire? La soglia sotto la quale il valore di un output è considerato "dust" è pari a 3 volte le fee in satoshi necessarie affinchè un nodo trasmetta la transazione (secondo la sua policy). Output che spendano valori inferiori a quella soglia faranno sì che la transazione non verrà inclusa in un blocco dai miner.

Ad esempio se il nodo trasmette transazioni che abbiano un minimo (minRelayTxFee) di 1000 satoshi per kilobyte (1 satoshi per byte), e un output standard è di 36 byte e necessita di un input standard di 148 byte per essere speso, la soglia minima di valore per l'output sarà : (1*36+1*148)*3=546 satoshi.
Se invece la minRelayTxFee è di 5000 satoshi per kilobyte (5 satoshi per byte), allora: (5*36+5*148)*3=2640 satoshi di valore minimo che deve avere un output.  

In ogni caso quindi, qualsiasi sia il valore di minRelayTxFee (purchè maggiore di 0), la transazione di cui si parla in questo thread contiene un output "dust", quindi essa non viene inclusa in un blocco (tra l'altro in periodi di forti intasamento della rete come questo il parametro minrelaytxfee è uno dei primi su cui si agisce alzandone il valore per non intasare la mempool).

Per quanto riguarda come fare a sbloccare i btc (che sono ancora associati a un indirizzo di cui l'OP ha perso la chiave privata), se non si trova un miner disposto a non fare il controllo di cui si è detto sopra, non vedo proprio come si potrebbe fare.
Forse si potrebbe tentare con il nuovo servizio di viabtc, che permette di inviare 100 tx gratis entro un'ora
-->  https://www.viabtc.com/tools/txaccelerator/ (anche se non ho capito se è free solo il servizio di "accelerazione" oppure se viene concesso proprio l'invio di tx senza fee, nel primo caso ovviamente non cambierebbe niente per il problema sollevato in questo thread).

EDIT: non accettano fee minori di 0,0001 btc, quindi non va bene.

Le soluzioni per tx bloccate di solito sono:

1) RBF (replace by fee), ovvero inviare una nuova transazione con maggiori fee (duoble spend), ma in questo caso non è possibile poichè non c'è più la chiave privata di partenza

2) Child-Pays-For-Parent (CPFP), ovvero creare una seconda transazione che spenda i bitcoin dell'indirizzo 1GQrjuC59UuDv3LqbhPHX5mREDY4521f12  ;  se un miner usa questa patch, le fee della seconda transazione contano anche per la prima, e quindi verrebbe invogliato a introdurre entrambe nel blocco; il vantaggio è che non è necessario avere più la private key del primo indirizzo di partenza, dubito però che l'output della prima transazione venga per questo non considerato più "dust"

3) contattare direttamente un miner affinchè la propria tx venga inclusa in un blocco (questa tx a conti fatti non mi pare irregolare, anche se va a incrementare inutilmente il database degli UTXO). Non so come sia possibile contattarli, qui si parla di casi recenti di transazioni a zero fee incluse in un blocco, testimoniando il fatto che i miner sono liberi di decidere quali tx includere e quali no.

A me dispiace solo che la pubblicità bitcoin passi spesso attraverso attività paralegali (pagare per scaricare cosa?)

Solo una nota "tecnica" relativa a un passaggio dell'articolo linkato:

"Dotcom risolverà inoltre alcune limitazioni, dette blockchain, del sistema di microtransazioni bitcoin"  

I found out some interesting information about hash function:

http://www.denimgroup.com/know_artic_secure_hash_functions.html

http://crypto.stackexchange.com/questions/12822/are-the-sha-family-hash-outputs-practically-random

Pseudo-Random Number Generator using SHA-256:
https://www.stat.berkeley.edu/~stark/Java/Html/sha256Rand.htm

But in general randomness is not the same as collision avoidance:  http://softwareengineering.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speed

I rephrase my question:

1) given arbitrary inputs, does the SHA-256 function really generate outputs that are evenly distributed?

2) given block headers** as inputs, does the SHA-256 function really generate outputs that are evenly distributed?

**block header = Version (4 bytes) + Previous Block Hash (32 bytes) + Merkle Root (32 bytes) + Timestamp (4 bytes) + Difficulty Target (4 bytes) + Nonce (4 bytes) = 80 byte = 640 bit  --> fixed length

block hash = block header hash = SHA256(SHA256(Block_Header))


In your case, what were your inputs? What kind of number sequences? Fixed length (more or less than 256 bit) or not?

Un attimo, la Coca Cola è un'azienda privata, non ha senso se parliamo di un'azienda privata pensare in termini di oligarchia / democrazia, questo è ovvio. Un conto è poi la struttura decisionale (chi prende le decisioni su come deve lavorare l'azienda e su che tipo di prodotti immettere sul mercato), un conto è il fatto che alla fine l'azienda deve misurarsi con la risposta del mercato e con i suoi competitori.

Bitcoin invece non è un'azienda privata, è nato più come un protocollo di intesa attorno al quale si è costituita una specie di comunità e quindi è lecito chiedersi in questo caso come funziona l'organizzazione/comunità e chi detiene il potere di prendere le decisioni di indirizzo (tipo segwit) all'interno di essa.
Il fatto poi, come ricordi sempre tu, che alla fine c'è il mercato che premia o meno certe decisioni non toglie il fatto che le scelte di indirizzo le fa qualcuno e non qualcun altro.

Se per te invece bitcoin è alla stregua di una qualsiasi organizzazione privata (leggi azienda) che opera sul mercato, allora è chiaro che questi discorsi su oligarchia e forme di governo non hanno alcun senso. Anzi, a dirla tutta, a me cliente della Coca Cola o della Volkswagen che cosa mai dovrebbe interessare di come funziona il processo decisionale all'interno di quelle aziende? Io mi limito ad usufruire dei loro prodotti.  Se invece bitcoin è qualcosa di più o di diverso da un'azienda, una comunità all'interno della quale chiunque può essere più che un semplice utente/cliente, interrogarsi sulla sua forma di governo è ben più sensato.

Come ha puntualizzato gbianchi, l'accesso al sistema bitcoin è assolutamente libero, nessuno lo ha mai messo in discussione (e ovviamente nessuno è obbligato a usare i bitcoin), quello che si sta dicendo in questi ultimi post però è che alcune caratteristiche che il sistema sembrava avere (caratteristiche per le quali molte persone sono state attirate in questo mondo) a conti fatti non le ha.

EDIT: ho ripescato un mio vecchio post in cui cercavo di esprimere che cos'era bitcoin per me, ben di più di un semplice nuovo mezzo di pagamento messomi a disposizione da un'azienda (o un prodotto da ricambiare magari con un altro così come si fa con un cellulare). A rileggerlo dopo del tempo mi sento un po' ingenuo  

La prima votazione è ormai andata, la seconda tornata parte dal blocco 439488+2016 = 441504, cioè tra poco più di 200 blocchi, ovvero tra 1 giorno e mezzo circa.

Nel momento in cui scrivo siamo arrivati al blocco 441290, quindi sono stati minati 1803 blocchi, di cui 407 blocchi con segnale di supporto a segwit (22,6%).

EDIT 04/12/2016 : Anche la seconda tornata è iniziata ma è anche già virtualmente finita.

Al momento infatti su 369 blocchi, 87 hanno segnalato la  disponibilità a segwit (solo il 23,58%!) , e 282 no (ricordo che per non far passare segwit bastano 101 blocchi contrari in ciascuna finestra di 2016). La percentuale dei sostenitori proprio non vuole decollare, altro che 95%, questo segwit sembra un grandissimo flop...

Io pure.


Allora riguardiamo questo incipit del famoso paper, a partire dal titolo:
Peer to peer nella sua visione significa: io posso scambiare del denaro a distanza con te come se fossimo in presenza e ci scambiassimo del contante. E' uno scambio "da pari a pari" poichè non interviene un terzo (o un quarto) a veicolare la nostra transazione come succede invece con carta di credito/bonifici ecc. Qui stava e sta la grossa novità e il senso del P2P.
Nessun terzo è nella posizione superiore di decidere se nella nostra transazione tu "meritavi" i miei soldi e quindi nessuno può annullare a posteriori il pagamento. Così come funziona con il contante, se io ti dò una banconota, a meno che tu stesso non me la restituisca, il pagamento è definitivo. E' uno scambio alla pari senza autorità esterne che possano dire la loro e entrare nel merito della transazione.

Un utente nella sezione internazionale ha fatto una osservazione molto interessante: si dà per scontato che agli inizi ci fosse più decentralizzazione di adesso per quanto riguarda il mining, in realtà questo dato non è del tutto vero.

Si è soliti infatti pensare che l'introduzione degli ASIC sia stato il motivo che ha reso inaccessibile il mining all'utente comune, in realtà a ben pensarci il motivo è un altro: una volta il sistema era costituito da pochissimi attori, quindi il compenso dei 144 blocchi giornalieri era suddiviso tra pochi, e anche se allora valeva poco come compenso, poteva avere un senso minare.

Se oggi per assurdo non esistessero gli ASIC, ma avessimo una base utente di 1 milione di persone/CPU, comunque non avrebbe senso minare da soli, in quanto la probabilità di trovare un blocco in un anno sarebbe dell'ordine di 1/1000000 * 144*365 = 5% circa, la probabilità di minare un blocco in 20 anni sarebbe del 66% (e per quella data la ricompensa potrebbe essere veramente scarsa ...). Al momento 1 blocco vale circa 8/9k euro, quindi per qualcuno forse potrebbe valere ancora la pena tenere acceso il pc per 20 anni, ma all'aumentare del numero di persone che comprano il biglietto della lotteria le probabilità diminuiscono di conseguenza, inoltre il premio della vincita si dimezza ogni 4 anni, quindi tra 20 anni ci saranno stati 5 dimezzamenti : 12,5 -> 0,39 btc di ricompensa.

Tradotto: le mining pool non nascono per colpa degli ASIC,  quando ancora si minava ancora con la cpu (in passato) si era già reso necessario mettersi insieme nelle mining pool, per avere comunque "garantito" quel milionesimo di parte e non affidarsi troppo alla sorte. Nel 2011 la pool Deepbit era arrivata ad avere più del 50% di hash power e quindi la situazione allora era più centralizzata di quanto non lo fosse oggi.

Quindi, per rimanere sulla precisione dei termini, decentralizzazione non vuol dire che ognuno mina da solo!

Io convengo sul fatto che bitcoin sia un sistema liberale nell'accesso, assolutamente non democratico nel modo di prendere decisioni.

La parola "democrazia" non è mai stata usata che mi risulti da satoshi, nè nel paper iniziale si è mai accennato a questa parola (ripeto: p2p non vuol dire certo democrazia, 1 cpu - 1 voto vuol dire che per votare serve forza computazionale, casomai è una"capacitàcomputazionale-crazia", quindi alla fine servono soldi e capacità e voglia di rischiare in proprio per poter votare, questo era scritto chiaro nero su bianco sin dall'inizio.

Bitcoin nasce principalmente come metodo di pagamento sicuro (per chi lo riceve, soprattutto a distanza laddove è molto difficile cioè verificare l'identità di chi paga, per eliminare i costi derivanti dal rischio di chargeback).

Tutto ciò che ne consegue e che ha acceso gli animi liberal/anarchici di molti, ad esempio il fatto di rendere la gente veramente proprietaria dei propri soldi e quindi la possibilità di bypassare il sistema bancario, la possibilità di effettuare transazioni  pseudoanonime, ecc.  è semplicemente una conseguenza del funzionamento di questo sistema, non costituiva l'obiettivo diretto per cui è stato costruito bitcoin, ma al più un effetto collaterale.

EDIT:
Anche per questo sono nati diversi tentativi di monete alternative (al di là dei casi meramente speculativi): diversi hanno guardato agli "effetti collaterali" del bitcoin e li hanno giudicati non solo collaterali ma degni di essere considerati aspetti fondamentali e fondanti, e quindi hanno cercato di modificare alcune caratteristiche della moneta per poter rafforzare sempre di più quelle caratteristiche che considerano oltremodo positive.
Chi ha visto semplicemente in bitcoin il fatto positivo di poter far soldi rapidamente ha creato dei semplici cloni per poter tirare su soldi (obiettivo speculativo), chi ha visto come positivo l'anonimato (o pseudo) delle transazioni, ha cercato di migliorare quell'aspetto (e recentemente ci sono state proposte di legge dirette esplicitamente contro quel tipo di criptovalute, non contro bitcoin).

L'equivoco su bitcoin e democrazia nasce dal fatto che all'inizio chiunque partecipasse alla rete era sia utente sia full node sia miner. L'accesso liberale all'inizio coincideva quindi in effetti con la democrazia nel prendere le decisioni, ma con il passare del tempo in un qualsiasi sistema liberale la differenza tra chi ha investito molto in conoscenza, hardware, ecc. e chi non lo ha fatto ha determinato la situazione odierna; è una questione di efficienza, io semplice utente che passo la maggior parte della mia giornata facendo altro e non occupandomi di bitcoin non posso competere con chi invece ci ha investito anni, cioè tempo e soldi. Quindi ho perso pian piano peso decisionale.
Il fatto che satoshi prevedesse che i semplici utenti non avrebbero mantenuto alla lunga neanche i full node lo testimonia il fatto che nel suo paper dedica un'intera sezione per la spiegazione del SPV, il metodo per verificare in modo semplificato la validità di un pagamento:  era chiaro che la maggioranza degli utenti avrebbe con il tempo utilizzato quel metodo e non la validazione completa della blockchain attraverso il proprio full node.

Sono pienamente d'accordo. Aggiungo anche che tenere un full node (non minare) allo stato attuale in realtà non è affatto costosissimo (certo non è gratis, ma direi che è normale se qualcosa ha un valore spendere dei soldi).  Certo non è economicamente conveniente se muovi poco denaro.

Da una discussione nella sezione internazionale è saltato fuori un riferimento a questo vecchio post (2010) di satoshi:


Quindi Nakamoto affermava chiaramente che non era mai stato nel progetto iniziale che ogni utente avesse un full node nè tantomeno che ogni utente potesse generare autonomamente bitcoin (sarebbe stato possibile solo in una primissima fase iniziale):
"The rest will be client nodes that only do transactions, the design supports letting users just be users"

Il futuro che Nakamoto prevedeva già allora ("Those few nodes will be big server farms") sta diventando oggi realtà.

Più rileggo questi post storici (oltre al famoso white paper) più mi domando come sia stato possibile che il bitcoin sia stato venduto a moltissimi come un sistema democratico e "paritetico" (o almeno da molti è stato così percepito inizialmente, me compreso ovviamente), un sistema nel quale ognuno avrebbe potuto gratuitamente verificare da solo la validità dei pagamenti ricevuti. Non è così e sicuramente non lo è mai stato nelle intenzioni del suo ideatore.

Uno dei motivi di questo abbaglio (parlo per me)  credo stia nel concetto di peer to peer, che può generare dei fraintendimenti. Sicuramente non sono stato l'unico, basti vedere altri post nello stesso thread prima citato, scritti anche da altri; ad esempio, sempre nello stesso thread, 3 messaggi prima del post di satoshi,  l'utente Red osservava (già allora, 2010!):

https://bitcointalk.org/index.php?topic=532.msg6223#msg6223,


Da notare infine che già allora si parlava di problemi di scalabilità e sostenibilità futura dei micropagamenti, ...

Hash function (sha256) is used to mine and identify a block. The digest is a 256 bit string.

We don't know whether this function is surjective or not (whether there is an input-block header for each output-digest).

But we assume that the output of the hash function is evenly distributed (so we can calculate target and difficulty for proof-of-work algorithm).

How can we know for sure the output is evenly distributed?

If you receive many payment, it's an incentive for you to run a full node. Why should it be free? If you want to be 100% sure about your payment and check yourself for it, why should you be paid by network to do it?  

From http://www.coindesk.com/how-to-save-bitcoins-node-network-from-centralization/ :


Every payment processor/merchant gains advantage from running a full node, that means thousands of node in the world.

Avendolo posseduto, l'unica controindicazione evidente che mi viene in mente è la fragilità fisica di questo wallet, che di "hard" ha veramente poco  .

Ciao!

Armory 0.94.1 + Bitcoin Unlimited 0.12.1 + Ubuntu 14.10 64 bit is working for me.

Hai PM.

EDIT:  transazione conclusa, tutto ok, gentile e rapido, ottimo venditore, consigliato!