Flood attack - transazioni lente - aggiornamenti

[Sampey]

Mi spiace, a lei solo su pagamento 

Certo dovresti pagarmi per avermi fatto perdere quasi 120 minuti della mia vita.

Buona serata qualunque cosa stesse facendo.

Cordiali saluti.

In primis ho usato il tuo stesso modo di porti, e in secundis credo di averti dato delle info utili. Poi se sei uno di quelli "Io ho ragione voi torto" non è un problema mio.

Le info le trovi qua :

https://github.com/gavinandresen/bitcoinxt/commit/821e223ccc4c8ab967399371761718f1015c766b

Parameters are:
  8MB cap
  ... doubling every two years (so 16MB in 2018)
  ... for twenty years
  ... earliest possible chain fork: 11 Jan 2016
  ... after miner supermajority (code in the next patch)
  ... and grace period once miner supermajority achieved (code in next patch)

Questo è avvenuto nel momento in cui delle grosse mining pool hanno detto che 8 MB Andava bene.
Ovviamente trovi varie notizie nella sezione international.

Chiaramente resta il gruppo degli scettici.

[1714908677]

1714908677

[1714908677]

1714908677

[1714908677]

1714908677

[FaSan]

L'aumento del blocco si rapporta alla naturale necessità di gestire un sempre più crescente incremento del numero di transazioni. Problema reale e non artificiale.
Su questo si stanno mettendo d'accordo nonostante ci siano scuole di pensiero ben distinte. Alla fine si sono forse trovati sugli 8MB con raddoppio ogni tot anni.

Qua invece c'e un problema di SPAM, si sta sfruttando il sistema per saturarlo, cosa che puoi tranquillamente fare anche col blocco a 20MB. Anzi paradossalmente potrebbe essere proprio l'azione intrapresa dai CONTRO-20MB per far incazzare la gente che ogni 10 minuti butta sul proprio hd 20MB di spazzatura.

L'unica cosa che hanno dimostrato è che possono rallentare la rete.
Tant'è che nonostante ci sia una UXTO da circa 30K Transazioni, le mining pool stanno mettendo nei blocchi un numero a  "piacere" di transazioni e ben poche arrivano ai fatidici 976+ KB

Quindi oltre al problema dello spam che non si cura di certo con l'aumento del blocksize, si evidenza (come se già non fosse evidente) anche come le mining pool abbiano un pò troppo potere tra le mani.

2 problemi che ripeto, non hanno niente a che fare con la problematica dell'aumento del blocco, che non è la soluzione a questo problema.

Come fanno i miners a decidere quante transazioni inserire in ciascun blocco? Non è casuale?

In realtà non decidono "quante", ma decidono il periodo temporale di aggiornamento dei job (non i miner, ma le pool). C'è chi aggiorna ogni 30 secondi, chi ogni minuto, qualche furbetto anche più lentamente. Ad ogni aggiornamento "assorbono" transazioni dal client, ricalcolano la merkleroot e distribuiscono ai miners.



FaSan

[Sampey]

L'aumento del blocco si rapporta alla naturale necessità di gestire un sempre più crescente incremento del numero di transazioni. Problema reale e non artificiale.
Su questo si stanno mettendo d'accordo nonostante ci siano scuole di pensiero ben distinte. Alla fine si sono forse trovati sugli 8MB con raddoppio ogni tot anni.

Qua invece c'e un problema di SPAM, si sta sfruttando il sistema per saturarlo, cosa che puoi tranquillamente fare anche col blocco a 20MB. Anzi paradossalmente potrebbe essere proprio l'azione intrapresa dai CONTRO-20MB per far incazzare la gente che ogni 10 minuti butta sul proprio hd 20MB di spazzatura.

L'unica cosa che hanno dimostrato è che possono rallentare la rete.
Tant'è che nonostante ci sia una UXTO da circa 30K Transazioni, le mining pool stanno mettendo nei blocchi un numero a  "piacere" di transazioni e ben poche arrivano ai fatidici 976+ KB

Quindi oltre al problema dello spam che non si cura di certo con l'aumento del blocksize, si evidenza (come se già non fosse evidente) anche come le mining pool abbiano un pò troppo potere tra le mani.

2 problemi che ripeto, non hanno niente a che fare con la problematica dell'aumento del blocco, che non è la soluzione a questo problema.

Come fanno i miners a decidere quante transazioni inserire in ciascun blocco? Non è casuale?

In realtà non decidono "quante", ma decidono il periodo temporale di aggiornamento dei job (non i miner, ma le pool). C'è chi aggiorna ogni 30 secondi, chi ogni minuto, qualche furbetto anche più lentamente. Ad ogni aggiornamento "assorbono" transazioni dal client, ricalcolano la merkleroot e distribuiscono ai miners.



FaSan

Ma possono eseguire dei check sulle transazioni da includere o meno no? NOn si è solo legati ad un range temporale.

[FaSan]

L'aumento del blocco si rapporta alla naturale necessità di gestire un sempre più crescente incremento del numero di transazioni. Problema reale e non artificiale.
Su questo si stanno mettendo d'accordo nonostante ci siano scuole di pensiero ben distinte. Alla fine si sono forse trovati sugli 8MB con raddoppio ogni tot anni.

Qua invece c'e un problema di SPAM, si sta sfruttando il sistema per saturarlo, cosa che puoi tranquillamente fare anche col blocco a 20MB. Anzi paradossalmente potrebbe essere proprio l'azione intrapresa dai CONTRO-20MB per far incazzare la gente che ogni 10 minuti butta sul proprio hd 20MB di spazzatura.

L'unica cosa che hanno dimostrato è che possono rallentare la rete.
Tant'è che nonostante ci sia una UXTO da circa 30K Transazioni, le mining pool stanno mettendo nei blocchi un numero a  "piacere" di transazioni e ben poche arrivano ai fatidici 976+ KB

Quindi oltre al problema dello spam che non si cura di certo con l'aumento del blocksize, si evidenza (come se già non fosse evidente) anche come le mining pool abbiano un pò troppo potere tra le mani.

2 problemi che ripeto, non hanno niente a che fare con la problematica dell'aumento del blocco, che non è la soluzione a questo problema.

Come fanno i miners a decidere quante transazioni inserire in ciascun blocco? Non è casuale?

In realtà non decidono "quante", ma decidono il periodo temporale di aggiornamento dei job (non i miner, ma le pool). C'è chi aggiorna ogni 30 secondi, chi ogni minuto, qualche furbetto anche più lentamente. Ad ogni aggiornamento "assorbono" transazioni dal client, ricalcolano la merkleroot e distribuiscono ai miners.



FaSan

Ma possono eseguire dei check sulle transazioni da includere o meno no? NOn si è solo legati ad un range temporale.

No, è sempre il client che passa le TXs al software delle pool, e si attiene alle regole base della chain, ovvero se include la fee o meno, etc etc ovviamente chi monta la patch per il DS si comporterà come tale.



FaSan

[HostFat]

I prossimi messaggi OT li cancello

Proseguite (se volete) e non rispondetemi.

[Ermo]

C'è qualche soluzione lato miner o siamo in alto mare ?
Infine i miner ci stanno guadagnando con tutto questo spam o no ?

Per i litecoin dicono di aver aggirato il problema, ma come hanno fatto ?
http://cointelegraph.com/news/114791/litecoin-shows-there-is-a-simple-fix-for-spam-attacks-on-bitcoin

Se lo spam è possibile individuarlo, perché non è possibile escluderlo ? Su liveblock le segnano in rosso...
Io stavo pensavo di ridurre ad una transazione massima per blocco per ogni indirizzo/destinazione.


 

[lottoitaliano]

C'è qualche soluzione lato miner o siamo in alto mare ?
Infine i miner ci stanno guadagnando con tutto questo spam o no ?

Per i litecoin dicono di aver aggirato il problema, ma come hanno fatto ?
http://cointelegraph.com/news/114791/litecoin-shows-there-is-a-simple-fix-for-spam-attacks-on-bitcoin

Se lo spam è possibile individuarlo, perché non è possibile escluderlo ? Su liveblock le segnano in rosso...
Io stavo pensavo di ridurre ad una transazione massima per blocco per ogni indirizzo/destinazione.


 

E' quello che avevo proposto io, una transazione forse è poca, ma limitare a poche transazioni sarebbe l'ideale. Attualmente, quante ne stanno mandando per ogni indirizzo per intasare la rete?

[FaSan]

Per una larga diffusione devi essere competitivo, diversamente usi la carta di credito anzichè il bitcoin. Le limitazioni quindi andrebbero escluse a priori.

Come già citato Litecoin non ha risolto niente, ha solamente inserito una spesa maggiore, impostando il pagamento di una fee per ogni UTXO anzichè sulla TX totale, aumentando quindi i costi di transazione. Può essere una possibilità ma non la vedo vantaggiosa.

IMHO il sistema deve essere in grado di sopportare tutte le transazioni possibili, poche o molte che siano. Questa è la strada per una diffusione globale.



FaSan

[BitNow]

E' quello che avevo proposto io, una transazione forse è poca, ma limitare a poche transazioni sarebbe l'ideale. Attualmente, quante ne stanno mandando per ogni indirizzo per intasare la rete?

Io quoto questa "view": l'unico modo e' quello di mettere un limite al numero di transazioni che si possono inviare da un determinato indirizzo.

Il limite deve essere correlato alle dimensioni del blocco attualmente in uso.

La Dimensioni del blocco e' correlata al limite sul numero di transazioni prima che la rete Bitcoin si intasi.

Se c'e' un'altro limite che infierisce sull'intasamento della linea prego fatemelo sapere.

Quello che credo e' che il limite sul numero di transazioni da inviare da un determinato indirizzo sia l'unico modo di risolvere elegantemente questo problema (AKA: senza aumentare la spesa da parte dell'utente).

Altre soluzioni non ne vedo.

[BitNow]

La Versione 0.11.0 di Bitcoin Core risolve parzialmente il problema.

Soluzioni:
1) La crescita della mempool puo' essere monitorato con il seguente comando getmempoolinfo.
2) Aumentare il costo della transazione minima minrelaytxfee (default 0,00001) causa che tutte le transazioni con meno BTC/kB rispetto a minrelaytxfee vengano scartate e come conseguenza di cio' meno transazioni entrano la mempool.
3) Restringere l'affidamento delle transazioni gratuite mediate limitfreerelay. Tale parametro setta il numero di kB/minuto al quale le transazioni gratuite, con sufficiente priorita', saranno accettate (default 15). Riducendo di conseguenza la velocita' alla quale la mempool puo' crescere a causa delle transazioni gratuite.

Ad esempio aggiungere i seguenti parametri al bitcoin.conf:

Code:

minrelaytxfee=0.00005
limitfreerelay=5

Soluzioni piu' affidabili sono allo studio e in preparazione per la prossima release.

Fonte1: https://bitcoin.org/en/release/v0.11.0
Fonte2: http://www.newsbtc.com/2015/07/13/new-bitcoin-core-version-0-11-0-released/

Notizia di ieri.

Ho aperto una nuova discussione sulla faccenda e la posto anche qui per non offendere l'utente Anon39 che ha cominciato per primo la discussione.
Link al nuovo thread: https://bitcointalk.org/index.php?topic=1122203

Questa info necessitava un nuovo post chiedo scusa all'admin.

[gbianchi]

devo fare qualche transazione, mi date un consiglio ?

1) transazione da localbitcoin a un mio wallet. Da li immagino che non posso impostare la fee, quindi che
speranze ho che la transazione da localbitcoin a un mio wallet venga eseguita in tempi umani ?

2) transazione tra due wallet... che fee devo impostare per avere una buona
probabilita' di essere incluso nel primo blocco estratto ?

[gbianchi]

Ho aperto una nuova discussione sulla faccenda

a che serve ?

[BitNow]

1) transazione da localbitcoin a un mio wallet. Da li immagino che non posso impostare la fee, quindi che
speranze ho che la transazione da localbitcoin a un mio wallet venga eseguita in tempi umani ?

La fortuna aiuta gli audaci: direi 50%.

2) transazione tra due wallet... che fee devo impostare per avere una buona
probabilita' di essere incluso nel primo blocco estratto ?

Ieri ho spedito con una tacca dalle fee massime nel wallet Bitcoin Core (bitcoin-qt), quello con conferma in "2 blocchi" per intenderci, ed ho raggiunto 6 conferme in 35 minuti.

a che serve ?

E' vietato postare due commenti di fila quindi ho aperto una nuova discussione e postato il commento "doppio" con le miei scuse all'admin per aver trasgredito alle regole di questo forum.

Cordiali saluti.

[Stemby]

2) transazione tra due wallet... che fee devo impostare per avere una buona
probabilita' di essere incluso nel primo blocco estratto ?

Direi da 0,0003 XBT in su (per una transazione "normale" più piccola di un kB); con 0,0005 dovresti andare abbastanza sicuro, anche se ci sono stati casi in questi giorni di transazioni rimaste nel limbo con commissioni mooooolto più alte.

Ciao!

[picchio]

Sbaglio o son due giorni che si sono calmati?
https://blockchain.info/it/charts/n-transactions?showDataPoints=true&timespan=30days&show_header=true&daysAverageString=1&scale=0&address=

[Anon39]

Sbaglio o son due giorni che si sono calmati?
https://blockchain.info/it/charts/n-transactions?showDataPoints=true&timespan=30days&show_header=true&daysAverageString=1&scale=0&address=

la dimensione media dei blocchi delle ultime 24 ore è di 723 KiB, quindi direi proprio di no, i blocchi continuano ad essere saturi. il numero di transazioni si sarà abbassato semplicemente perché entrano più transazioni grosse.

[BitNow]

Sbaglio o son due giorni che si sono calmati?
https://blockchain.info/it/charts/n-transactions?showDataPoints=true&timespan=30days&show_header=true&daysAverageString=1&scale=0&address=

Il numero medio di transazioni per blocco anche e' diminuita:
https://blockchain.info/it/charts/n-transactions-per-block?timespan=180days&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=

La release 0.11.00 sara' stata sufficiente anche se il tempo di adozione e' lungo.

la dimensione media dei blocchi delle ultime 24 ore è di 723 KiB, quindi direi proprio di no, i blocchi continuano ad essere saturi. il numero di transazioni si sarà abbassato semplicemente perché entrano più transazioni grosse.

Da quale sito hai preso la dimensione media dei blocchi Anon39?

[Anon39]

Da quale sito hai preso la dimensione media dei blocchi Anon39?

statoshi.info

[alexrossi]

Network ancora sotto pesante pressione, sarebbe interessante calcolare quanti mb di spam tutti i nodi ora devono archiviare in più

[picchio]

Io credo che BTC non possa soddisfare le esigenze mondiali in fatto di transazioni. D'altronde non è necessario sigillare in ogni pc del mondo per l'eternità la transazione dell'acquisto di 1 kg del signor Rossi a Roma il 15 luglio 2015. ..

Sarebbe interessante calcolare quante transazioni al giorno si possono avere per ogni chilometro quadro di superficie terrestre (creo venga un numero irrisorio) ne deduco che, come gli ipv4 non saranno sufficienti, neanche la rete BTC potrà rispondere alle esigenze.

Ci vuole "bitcoin v6" che magari si appoggia su bitcoin ma solo per dei dati di sintesi e che costeranno parecchio. Ad esempio memorizzo un hash ogni 10 minuti delle transazioni avvenute in un intero paese, la transazione avrà un costo adeguato e tutto il mondo potrà usare la chain ma non per tutte le transazioni ma solo per degli hash di altre informazioni più dettagliate, (qui' faccio fatica a spiegarmi ...) eventualmente si ripete ad un livello sempre più locale come delle matriosche ...