|
FaSan
|
 |
November 19, 2013, 06:09:10 PM
Last edit: November 19, 2013, 06:32:21 PM by FaSan |
|
pensa che la mia e' una transazione di 1,1 bitcoin ed ho pure pagato una commissione
Commissione troppo bassa: la transazione è comunque non standard. Ciao! puo' essere, diciamo che sia un errore mio, dovuto a mia ignoranza. e diciamo pure che sia abbastanza improbabile, ma non cosi' tanto visto che il thread non l'ho aperto io ma un altro utente che si era infilato in una situazione analoga. questo non toglie che la cosa sia abbasstanza spiecevole, vista sia la cifra non irrisoria che ho in gioco io (chissa' che fine faranno i miei 500 euro) e sopratutto le situazioni paradossali che si possono creare. un altro esempio: il bitcoin comincia a crollare, voglio vendere, ma ho il mio bitcoin "intrappolato" nel limbo di non si sa che durata e non si sa che esito... Premesso che io sono un entusiasta del bitcoin, e sono disposto a sopportare questi problemi, credo che questa sia una carenza abbastanza grave in caso di diffusione nel mondo reale... te lo immagini spiegare alla massaia o al muratore che ha 500 euro finiti in un limbo che non si sa quanto dura e non si sa se ricevera' i soldi indietro o il pagamento sara' effettuato ? Se vai alla tua banca e per saltare la fila chiedi al "tuo amico" allo sportello se ti fà una certa operazione, si prospettano due possibilità : 1. te la fà a tempo perso dicendoti di ripassare x la ricevuta 2. gli paghi il caffè e te la fà in tempo reale fregandosene della gente in fila Ecco... un tedesco magari non capirebbe, ma con un italiano è come sfondare una porta aperta  FaSan |
|
|
|
|
gbianchi
Legendary
 Offline
Activity: 3108
Merit: 2670
|
|
November 19, 2013, 08:09:12 PM |
|
Se vai alla tua banca e per saltare la fila chiedi al "tuo amico" allo sportello se ti fà una certa operazione, si prospettano due possibilità : 1. te la fà a tempo perso dicendoti di ripassare x la ricevuta 2. gli paghi il caffè e te la fà in tempo reale fregandosene della gente in fila Ecco... un tedesco magari non capirebbe, ma con un italiano è come sfondare una porta aperta FaSan analisi approfondita e condivisibile MA bitcoin dovrebbe essere usato anche dai tedeschi, dagli americani, dai cinesi, dagli indiani... fortunatamente non solo dagli italiani, perpetuando i nostri modi di fare di sedicente pese occiddentale con le usanze di un paese del terzo mondo. |
|
|
|
fatlove (OP)
Newbie
Offline
Activity: 19
Merit: 0
|
|
November 19, 2013, 09:21:28 PM |
|
Io non ho pagato le commissioni! Penso che a sto punto i miei bitcoin spariranno nel nulla..
|
|
|
|
|
gbianchi
Legendary
Offline
Activity: 3108
Merit: 2670
|
|
November 20, 2013, 01:06:38 AM |
|
Io non ho pagato le commissioni! Penso che a sto punto i miei bitcoin spariranno nel nulla..
no dai non dire cosi'... il mio 1,1 bitcoin non puo' sparire cosi' !!!! comunque siamo praticemente nella stessa situazione, ho visto che anche i tempi "presunti" (ed erratici) stimati di conferma delle nostre due operazioni piu' o meno variano allao stesso modo... a volte sono 30 ore, prima erano 6, adesso sono risalite ad 8. Devo dire che questa cosa mi ha messo una certa ansia per le operazioni future !!! visto che tu con 0,1 bitcoin e senza fee, ed io con 1,1 e 0,0001 di fee abbiamo fatto la stessa fine, chi mi garantisce che con 100 bitcoin e 0,0005 di fee andava tutto liscio ? e devo essere sincero.... se avessi 100 bitcoin in questo stato, sarei molto ma molto incazzato ... (anche se non so di preciso con chi) |
|
|
|
|
FaSan
|
|
November 20, 2013, 01:14:06 AM |
|
visto che tu con 0,1 bitcoin e senza fee, ed io con 1,1 e 0,0001 di fee
abbiamo fatto la stessa fine, chi mi garantisce che con 100 bitcoin e 0,0005
di fee andava tutto liscio ?
Non andava bene lo stesso. La fee è di 0.001 e non di 0.0001. Se la paghi giusta, non hai problemi. FaSan |
|
|
|
|
gbianchi
Legendary
Offline
Activity: 3108
Merit: 2670
|
|
November 20, 2013, 01:42:44 AM |
|
visto che tu con 0,1 bitcoin e senza fee, ed io con 1,1 e 0,0001 di fee
abbiamo fatto la stessa fine, chi mi garantisce che con 100 bitcoin e 0,0005
di fee andava tutto liscio ?
Non andava bene lo stesso. La fee è di 0.001 e non di 0.0001. Se la paghi giusta, non hai problemi. FaSan veramente qui https://en.bitcoin.it/wiki/Transaction_fees#Rules_for_calculating_minimum_feesdice diversamente... "Note that a typical transaction is 500 bytes, so the typical transaction fee for low-priority transactions is 0.1 mBTC (0.0001 BTC), regardless of the number of bitcoins sent. " |
|
|
|
bertani
Legendary
Offline
Activity: 1022
Merit: 1000
|
|
November 20, 2013, 01:43:47 AM |
|
Ops mi ero perso il thread  A me è successo diverse volte, finalmente sono riuscito a capire come andrebbe "ufficialmente" risolta. Basta broadcastare un'altra transazione con gli stessi input script ma con fee superiore. Questo sistema tutto se ci pensate: sembrerà un double spend, ma i miner includeranno in un blocco la transazione con fee più alta e l'altra si perderà di conseguenza. |
|
|
|
|
bertani
Legendary
Offline
Activity: 1022
Merit: 1000
|
|
November 20, 2013, 02:04:27 AM |
|
visto che tu con 0,1 bitcoin e senza fee, ed io con 1,1 e 0,0001 di fee
abbiamo fatto la stessa fine, chi mi garantisce che con 100 bitcoin e 0,0005
di fee andava tutto liscio ?
Non andava bene lo stesso. La fee è di 0.001 e non di 0.0001. Se la paghi giusta, non hai problemi. FaSan veramente qui https://en.bitcoin.it/wiki/Transaction_fees#Rules_for_calculating_minimum_feesdice diversamente... "Note that a typical transaction is 500 bytes, so the typical transaction fee for low-priority transactions is 0.1 mBTC (0.0001 BTC), regardless of the number of bitcoins sent. " int64_t CTransaction::nMinTxFee = 10000;
[..]
int64_t nMinFee = (1 + (int64_t)nBytes / 1000) * nBaseFee;
Quindi stando al client ufficiale ( v0.8 ) la fee minima è 0.0001btc di base + 0.0001btc per ogni kb. |
|
|
|
|
Stemby
Legendary
Offline
Activity: 2450
Merit: 1008
|
|
November 20, 2013, 02:19:15 AM |
|
int64_t CTransaction::nMinTxFee = 10000;
[..]
int64_t nMinFee = (1 + (int64_t)nBytes / 1000) * nBaseFee;
Quindi stando al client ufficiale ( v0.8 ) la fee minima è 0.0001btc di base + 0.0001btc per ogni kb. In effetti dalla versione 0.8.2 la commissione minima è diventata più dinamica: da un valore fisso nel codice (in precedenza 0,0005 XBT) a uno da calcolarsi di volta in volta. Resta comunque l'intervento manuale dei programmatori per correggere periodicamente la base (al momento 0,0001 XBT) e/o il coefficiente. (questo almeno nella versione 0.8.2; non so se ci siano state ulteriori evoluzioni) |
“…virtual currencies, could have a substitution effect on central bank money if they become widely accepted.”
ECB Report, October 2012
|
|
|
|
FaSan
|
|
November 20, 2013, 03:01:16 AM |
|
Sarà anche così, ma le freccette del contatore del client-qt (opzioni->commissione) incrementano di 0.001 alla volta (v 0.8.5)
FaSan
|
|
|
|
|
gbianchi
Legendary
Offline
Activity: 3108
Merit: 2670
|
|
November 20, 2013, 08:48:06 AM |
|
Ops mi ero perso il thread A me è successo diverse volte, finalmente sono riuscito a capire come andrebbe "ufficialmente" risolta. Basta broadcastare un'altra transazione con gli stessi input script ma con fee superiore. Questo sistema tutto se ci pensate: sembrerà un double spend, ma i miner includeranno in un blocco la transazione con fee più alta e l'altra si perderà di conseguenza. interessante, ma non ho capito come si realizza, visto che nel client adesso ho 0 bitcoin e non posso fare altro che aspettare... mi spieghi come dovrei fare ? grazie !!!! il mio bitcoin che vaga nel nulla mi fa un po' pena  |
|
|
|
|
bitcoinplaza
|
|
November 20, 2013, 12:11:58 PM |
|
Ops mi ero perso il thread A me è successo diverse volte, finalmente sono riuscito a capire come andrebbe "ufficialmente" risolta. Basta broadcastare un'altra transazione con gli stessi input script ma con fee superiore. Questo sistema tutto se ci pensate: sembrerà un double spend, ma i miner includeranno in un blocco la transazione con fee più alta e l'altra si perderà di conseguenza. interessante, ma non ho capito come si realizza, visto che nel client adesso ho 0 bitcoin e non posso fare altro che aspettare... mi spieghi come dovrei fare ? grazie !!!! il mio bitcoin che vaga nel nulla mi fa un po' pena Quando mi è capitato ho sempre risolto cosi : backuppo tutto eseguo pywallet.py --web si scarica qua https://github.com/jackjack-jj/pywalletmi collego in locale a http://localhost:8989 e configuro i dati per il mio wallet : Wallet Directory, Wallet Filename, Key: all Type: 'Transaction' poi cancello tutte le tx non confermate e faccio un rescan completo del blockchain riapro il client e non ho piu la tx unconfirmed poi aspetto almeno 24/48 che la tx venga "dimenticata" e la rieseguo con fee ciao spero che possa aiutare |
|
|
|
gbianchi
Legendary
Offline
Activity: 3108
Merit: 2670
|
|
November 20, 2013, 01:06:29 PM |
|
Quando mi è capitato ho sempre risolto cosi : backuppo tutto eseguo pywallet.py --web si scarica qua https://github.com/jackjack-jj/pywalletmi collego in locale a http://localhost:8989 e configuro i dati per il mio wallet : Wallet Directory, Wallet Filename, Key: all Type: 'Transaction' poi cancello tutte le tx non confermate e faccio un rescan completo del blockchain riapro il client e non ho piu la tx unconfirmed poi aspetto almeno 24/48 che la tx venga "dimenticata" e la rieseguo con fee ciao spero che possa aiutare grazie... adoro quando scrive qualcuno che ha vero contenuto da condividere ! Tra parentesi, se ho capito bene basterebbe una piccola modifica al client per "annullare" volontariamente le transazioni che dopo un po' di tempo sono rimaste nel limbo ! che so, un bottone di annullamento che si puo' pigiare solo se la transazione e' rimasta li a marcire senza nessuna conferma per piu' di 24 ore... Almeno darebbe la possibilita' anche alla famosa "massaia" di gestire una situazione del genere. |
|
|
|
Stemby
Legendary
Offline
Activity: 2450
Merit: 1008
|
|
November 20, 2013, 02:48:17 PM |
|
Tra parentesi, se ho capito bene basterebbe una piccola
modifica al client per "annullare" volontariamente le transazioni
che dopo un po' di tempo sono rimaste nel limbo !
che so, un bottone di annullamento che si puo' pigiare solo se la transazione
e' rimasta li a marcire senza nessuna conferma per piu' di 24 ore...
Almeno darebbe la possibilita' anche alla famosa "massaia" di gestire
una situazione del genere.
Sì, direi di sì. Se hai voglia di spendere un po' di tempo per il bene della comunità, prova a cercare su GitHub se gli sviluppatori stiano discutendo di questo. Se sì, unisciti alla discussione; altrimenti apri tu un ticket, o, ancora meglio, invia una pull-request (devi sapere programmare, per questo). Ciao! |
“…virtual currencies, could have a substitution effect on central bank money if they become widely accepted.”
ECB Report, October 2012
|
|
|
bertani
Legendary
Offline
Activity: 1022
Merit: 1000
|
|
November 20, 2013, 03:20:15 PM |
|
Penso che si stia creando un po' di confusione  Se trasmetti una 0-fee tx la politica del relaying non è sempre uguale, dipende dal nodo (implementazione, versione, etc). Le tx in attesa di conferma vengono tenute nella mempool, la soluzione che suggerisce bitcoinplaza è quindi "parziale" nel senso che risolve la cosa solo localmente (la elimini dal tuo storico, ma è già stata trasmessa, quindi qualche altro nodo potrebbe averla ritrasmessa). In ogni caso ad oggi la maggior parte dei nodi non tiene nella mempool le 0-fee tx e quindi non si propagherà molto nella rete (oltre ad avere priorità bassissima, ma questo dipende anche dall'input script age!). La soluzione proposta sopra è comoda perchè permette di broadcastare una transazione con gli stessi input script (cosa normalmente non possibile ovviamente, per prevenire i double spend) ma con fee più alta. Questa nuova transazione verrà quindi ben propagata nella rete, nei mempool e poi inclusa in un blocco. Anche il "double-spending" quindi è un concetto abbastanza relativo e non definitivo. I miner sono quelli che devono decidere se includere una tx nel blocco o meno, ma poi i nodi rioperano una verifica dei blocchi contro il double-spending. Se ci pensate un attimo siamo in una botte di ferro! |
|
|
|
|
gbianchi
Legendary
Offline
Activity: 3108
Merit: 2670
|
|
November 20, 2013, 03:26:50 PM |
|
La soluzione proposta sopra è comoda perchè permette di broadcastare una transazione con gli stessi input script (cosa normalmente non possibile ovviamente, per prevenire i double spend) ma con fee più alta. Questa nuova transazione verrà quindi ben propagata nella rete, nei mempool e poi inclusa in un blocco.
Anche il "double-spending" quindi è un concetto abbastanza relativo e non definitivo. I miner sono quelli che devono decidere se includere una tx nel blocco o meno, ma poi i nodi rioperano una verifica dei blocchi contro il double-spending. Se ci pensate un attimo siamo in una botte di ferro!
Beh quello che vorrei risolvere non e' il propblema del double spending, che immagino ben gestito dalla rete, visto che e' la base dalla quale sono partiti. Io vorrei gestire "al meglio" le transazioni senza conferme. La mia e' ancora li' appesa da ormai 3 giorni, senza possibilita' di riutilizzare il mio bitcoin... cercate di capire che aldila' del mero tecnicismo, e' un problema non da poco per chi ci incappa e non sa come gestirlo e/o risolverlo. per bertani: mi spieghi la tua versione di come potrei "rispedire la transazione con gli stessi script ma con una fee piu' alta" ? |
|
|
|
bertani
Legendary
Offline
Activity: 1022
Merit: 1000
|
|
November 20, 2013, 03:37:26 PM |
|
per bertani: mi spieghi la tua versione di come potrei "rispedire la transazione con gli stessi script
ma con una fee piu' alta" ?
In bitcoind penso che tu debba fare come ha suggerito bitcoinplaza. Oppure apri un nuovo wallet (non necessariamente su bitcoind, anche multibit è ok), importi la chiave privata del vecchio wallet e rifai l'invio con una fee sensata (vedrai che la transazione senza fee molto probabilmente non verrà proprio vista dall'altro client, per i "tecnicismi" di cui sopra). |
|
|
|
|
|
bitcoinplaza
|
|
November 20, 2013, 04:01:05 PM |
|
Penso che si stia creando un po' di confusione Se trasmetti una 0-fee tx la politica del relaying non è sempre uguale, dipende dal nodo (implementazione, versione, etc). Le tx in attesa di conferma vengono tenute nella mempool, la soluzione che suggerisce bitcoinplaza è quindi "parziale" nel senso che risolve la cosa solo localmente (la elimini dal tuo storico, ma è già stata trasmessa, quindi qualche altro nodo potrebbe averla ritrasmessa). In ogni caso ad oggi la maggior parte dei nodi non tiene nella mempool le 0-fee tx e quindi non si propagherà molto nella rete (oltre ad avere priorità bassissima, ma questo dipende anche dall'input script age!). La soluzione proposta sopra è comoda perchè permette di broadcastare una transazione con gli stessi input script (cosa normalmente non possibile ovviamente, per prevenire i double spend) ma con fee più alta. Questa nuova transazione verrà quindi ben propagata nella rete, nei mempool e poi inclusa in un blocco. Anche il "double-spending" quindi è un concetto abbastanza relativo e non definitivo. I miner sono quelli che devono decidere se includere una tx nel blocco o meno, ma poi i nodi rioperano una verifica dei blocchi contro il double-spending. Se ci pensate un attimo siamo in una botte di ferro! e si, oltrettutto se il client rimane aperto rifa il broadcast della trasazione ad intervallo regolare, mi sembra 30 minuti per tentare double spending devi per forza esportare la PRiKey in formato Base58 creare un nuovo wallet, aprirlo, importare la PriKey da console, uscire, e fare rescan, poi puoi rimandare l'importo con fee superiore c'è anche un online tool per forzare il double spending se volete posto link, ma io non fido ad usarlo |
|
|
|
gbianchi
Legendary
Offline
Activity: 3108
Merit: 2670
|
|
November 20, 2013, 09:21:48 PM |
|
Penso che si stia creando un po' di confusione Se trasmetti una 0-fee tx la politica del relaying non è sempre uguale, dipende dal nodo (implementazione, versione, etc). Le tx in attesa di conferma vengono tenute nella mempool, la soluzione che suggerisce bitcoinplaza è quindi "parziale" nel senso che risolve la cosa solo localmente (la elimini dal tuo storico, ma è già stata trasmessa, quindi qualche altro nodo potrebbe averla ritrasmessa). In ogni caso ad oggi la maggior parte dei nodi non tiene nella mempool le 0-fee tx e quindi non si propagherà molto nella rete (oltre ad avere priorità bassissima, ma questo dipende anche dall'input script age!). La soluzione proposta sopra è comoda perchè permette di broadcastare una transazione con gli stessi input script (cosa normalmente non possibile ovviamente, per prevenire i double spend) ma con fee più alta. Questa nuova transazione verrà quindi ben propagata nella rete, nei mempool e poi inclusa in un blocco. Anche il "double-spending" quindi è un concetto abbastanza relativo e non definitivo. I miner sono quelli che devono decidere se includere una tx nel blocco o meno, ma poi i nodi rioperano una verifica dei blocchi contro il double-spending. Se ci pensate un attimo siamo in una botte di ferro! e si, oltrettutto se il client rimane aperto rifa il broadcast della trasazione ad intervallo regolare, mi sembra 30 minuti per tentare double spending devi per forza esportare la PRiKey in formato Base58 creare un nuovo wallet, aprirlo, importare la PriKey da console, uscire, e fare rescan, poi puoi rimandare l'importo con fee superiore c'è anche un online tool per forzare il double spending se volete posto link, ma io non fido ad usarlo se bisogna dargli le chiavi private, non ci penso proprio altrimenti se ne puo' parlare ! |
|
|
|
ercolinux
Legendary
Offline
Activity: 938
Merit: 1000
|
|
November 21, 2013, 08:28:45 AM |
|
c'è anche un online tool per forzare il double spending se volete posto link, ma io non fido ad usarlo
se bisogna dargli le chiavi private, non ci penso proprio altrimenti se ne puo' parlare ! Non conosco il tool ma dubito che senza chiave privata possa fare molto |
Bitrated user: ercolinux.
|
|
|
|
