Transazione "dust", piccolo esperimento

[reee]

Dunque, leggetevi il primo post di questo thread:
https://bitcointalk.org/index.php?topic=1161663.0

(l'autore del thread in realtà sono io, poi avevo usato l'account come "collateral" per un prestito e mi hanno scammato tenendosi l'account. Non avevo protestato perchè all'epoca volevo cancellarmi dal forum e quindi me ne fregava poco di quell'account. Vedo che ora ha anche reputazione negativa.)

In realtà quel post può essere considerato una sorta di esperimento sociale. Ho guardato l'indirizzo e ancora oggi non sono riusciti a sbloccare la transazione. Io all'epoca credevo che qualche smanettone ci sarebbe riuscito. Invece vedo che c'è molta gente che è abbastanza ignorante sul funzionamento del protocollo bitcoin (non che io ne sappia molto eh, ma qualche base minima ce l'ho), molti mi accusavano di scam quando era fisicamente impossibile scammare qualcuno dandolgi semplicemente la chiave privata di un indirizzo.

Secondo voi è possibile sbloccarla? Forse l'unico modo sarebbe che un miner decidesse volontariamente di minarla. Se riuscite a farlo (e siete svelti) potrete anche beccarvi i 0.013 btc 

[1714707693]

1714707693

[1714707693]

1714707693

[1714707693]

1714707693

[1714707693]

1714707693

[Sandro kensan]

Mi pare di avere capito che la transazione che tu hai pubblicato non è valida, non che io sappia il perché ma gli esperti del forum mi pare dicano questo.

Poi la chiave privata è pericolosa e si possono perdere molti soldi aggiungendola al proprio wallet, quindi l'accusa di truffa sta in piedi nel senso che è possibile rubare soldi pubblicando la chiave privata.

[arulbero]

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

   bool IsDust(CFeeRate minRelayTxFee) const
    {
        // "Dust" is defined in terms of CTransaction::minRelayTxFee,
        // which has units satoshis-per-kilobyte.
        // If you'd pay more than 1/3 in fees
        // to spend something, then we consider it dust.
        // A typical txout is 34 bytes big, and will
        // need a CTxIn of at least 148 bytes to spend:
        // so dust is a txout less than 546 satoshis
        // with default minRelayTxFee.
        size_t nSize = GetSerializeSize(SER_DISK,0)+148u;
        return (nValue < 3*minRelayTxFee.GetFee(nSize));
    }

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

The transaction must not include any outputs which receive fewer than 1/3 as many satoshis as it would take to spend it in a typical input. That’s currently 546 satoshis for a P2PKH or P2SH output on a Bitcoin Core node with the default relay fee. Exception: standard null data outputs must receive zero satoshis.

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.

[reee]

@arulbero

grazie della spiegazione molto dettagliata. Praticamente è come pensavo io, l'unica soluzione sarebbe un miner che decidesse di includerla nei blocchi.

Poi la chiave privata è pericolosa e si possono perdere molti soldi aggiungendola al proprio wallet, quindi l'accusa di truffa sta in piedi nel senso che è possibile rubare soldi pubblicando la chiave privata.

Non vedo come. Come sarebbe possibile secondo te?

[Sandro kensan]

Poi la chiave privata è pericolosa e si possono perdere molti soldi aggiungendola al proprio wallet, quindi l'accusa di truffa sta in piedi nel senso che è possibile rubare soldi pubblicando la chiave privata.

Non vedo come. Come sarebbe possibile secondo te?

Se non sei alle prime armi lo avrai visto che includendo un indirizzo bitcoin con la chiave privata in un wallet questo comporta che il resto che arriva dopo avere fatto una transazione viene mandato a un indirizzo qualsiasi (dipende dal tipo di wallet) che appartiene al proprio portafoglio. Non so se tu questo lo sappia ma altri lo sanno e non sono sicuri della tua buona fede.

Questo comporta che dopo una transazione l'indirizzo 1GQrjuC59UuDv3LqbhPHX5mREDY4521f12 abbia soldi dentro e un truffatore potrebbe avere un programma automatico che appena verifica che ci sono fondi li preleva e li mette al sicuro su un altro indirizzo di cui possiede la chiave in modo esclusivo. Spero non sia il tuo caso.

[arulbero]

Poi la chiave privata è pericolosa e si possono perdere molti soldi aggiungendola al proprio wallet, quindi l'accusa di truffa sta in piedi nel senso che è possibile rubare soldi pubblicando la chiave privata.

Non vedo come. Come sarebbe possibile secondo te?

Se non sei alle prime armi lo avrai visto che includendo un indirizzo bitcoin con la chiave privata in un wallet questo comporta che il resto che arriva dopo avere fatto una transazione viene mandato a un indirizzo qualsiasi (dipende dal tipo di wallet) che appartiene al proprio portafoglio. Non so se tu questo lo sappia ma altri lo sanno e non sono sicuri della tua buona fede.

Questo comporta che dopo una transazione l'indirizzo 1GQrjuC59UuDv3LqbhPHX5mREDY4521f12 abbia soldi dentro e un truffatore potrebbe avere un programma automatico che appena verifica che ci sono fondi li preleva e li mette al sicuro su un altro indirizzo di cui possiede la chiave in modo esclusivo. Spero non sia il tuo caso.

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:

Code:

010000000147ce0e81fac45653e8f82b4edfb2873c83fc95ee67219a0b2c9a7f9a0020a0c5000000008b48304502205814f0c588383a38c00b7f9d2317f2aeb2649e60dd341e603b22ae79f334f83c02210094a35f42d1c9f32ea700e66354ecd457ab2bcf0247865cb037be886569a5ac7f014104227f4a6de87d345dc08601920c1ab8b9bf4a76868e053f5f90faf307bcf0d72b014be36394a1f8a98bd8f2e5bb2243464fa67eee14e5cfc0888d7f15b7b2a1100c0000000264d31300000000001976a914a90cf97578df33b7d261105f3ba7b7297fd3f77d88ac00000000000000001976a9149f27c31c0bf89cb4958e7fc99c0f9117623b4e4b88ac44a70500

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)

Bitcoin Core dalla versione 0.11.1 non consente più questa flessibilità che poteva portare problemi:

Inherent ECDSA signature malleability We require that the S value inside ECDSA signatures is at most the curve order divided by 2 (essentially restricting this value to its lower half range). See reference: Low S values in signatures

quindi all'algoritmo della firma, per precisione, va aggiunto adesso un ulteriore passaggio:

se s è maggiore di (n+1)/2 allora sostituisci s con (n - s)

le versioni più recenti di Bitcoin Core non propagano più quindi transazioni nelle quali le firme presentano una s maggiore di (n+1)/2

[Sandro kensan]

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.

C'è anche un'altra possibilità ovvero che chi importa la chiave privata non sia a conoscenza di questi meccanismi che invece tu conosci molto bene. Poi con multibit classic ci sono le chiavi private importate e non c'è il seed, il seed c'è in multibit HD e in altri tipi di wallet.

[reee]

@arulbero: avevo provato anch'io quei servizi e avevo visualizzato gli stessi errori.
Ci sarebbe questo http://eligius.st/~wizkid057/newstats/pushtxn.php che non fa particolari verifiche, ma non riesce comunque a propagare la transazione.

Questo comporta che dopo una transazione l'indirizzo 1GQrjuC59UuDv3LqbhPHX5mREDY4521f12 abbia soldi dentro e un truffatore potrebbe avere un programma automatico che appena verifica che ci sono fondi li preleva e li mette al sicuro su un altro indirizzo di cui possiede la chiave in modo esclusivo. Spero non sia il tuo caso.

Non so se ho ben capito. Ovviamente sì, c'è il rischio che essendo la chiave privata di dominio pubblico, una volta effettuata la transazione qualcun'altro possa trasferire i bitcoin su un indirizzo "sicuro" e tenerseli. Ma questo fa punto parte del gioco, oltre ad effettuare la transazione bisogna essere svelti a trasferire i btc su un altro indirizzo.
Quello che intendo dire è che non credo ci sia la possibilità di "fregare" a qualcuno i suoi soldi. Se ad esempio qualcuno ha 1btc, fa la transazione, ed importa la chiave privata, alla fine avrà 1.013btc. Se non sposta gli 0.013 btc, chiunque può fregarglieli in qualsiasi momento ma nessuno può rubargli il restante 1btc.
Sì, c'è l'eventualità del resto alla quale sinceramente non avevo pensato, ma credo sia una circostanza abbastanza improbabile, i moderni wallet non credo che rimandino il resto all'indirizzo appena importato. In ogni caso basta prendere i dovuti accorgimenti. Comunque essendo l'indirizzo pubblico in quel caso i btc potrebbe fregarli chiunque, non solo io.

[Sandro kensan]

Sì, c'è l'eventualità del resto alla quale sinceramente non avevo pensato, ma credo sia una circostanza abbastanza improbabile, i moderni wallet non credo che rimandino il resto all'indirizzo appena importato. In ogni caso basta prendere i dovuti accorgimenti. Comunque essendo l'indirizzo pubblico in quel caso i btc potrebbe fregarli chiunque, non solo io.

Secondo me con i bitcoin ci sono molti pericoli se non si è bene informati, questo del resto è uno dei tanti.

[arulbero]

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).

[arulbero]

Se hai firmato quest'ultima transazione con la firma relativa all'indirizzo 1GQrjuC59UuDv3LqbhPHX5mREDY4521f12 (quello a cui erano destinati i bitcoin inizialmente), rimarrebbe comunque un output non speso nella prima transazione:

    0.00000000 btc        -->   1FWY5DxbgVSBbCwCDMwsgSPUCKQKWfjYWa

Motivo per cui non penso possa essere accettata neanche la seconda transazione.

Il problema è che se venisse confermata la vecchia transazione si creerebbe un output "dust" nel database degli UTXO, e questo non è consentito.

Ricordo qual era la tua vecchia transazione che ha dato origine a tutta la questione:

Code:

{
   "lock_time":370500,
   "size":258,
   "inputs":[
      {
         "prev_out":{
            "index":0,
            "hash":"c5a020009a7f9a2c0b9a2167ee95fc833c87b2df4e2bf8e85356c4fa810ece47"
         },
         "script":"48304502205814f0c588383a38c00b7f9d2317f2aeb2649e60dd341e603b22ae79f334f83c02210094a35f42d1c9f32ea700e66354ecd457ab2bcf0247865cb037be886569a5ac7f014104227f4a6de87d345dc08601920c1ab8b9bf4a76868e053f5f90faf307bcf0d72b014be36394a1f8a98bd8f2e5bb2243464fa67eee14e5cfc0888d7f15b7b2a110"
      }
   ],
   "version":1,
   "vin_sz":1,
   "hash":"bc23946a4335370962015d7947e37717568852a83f4b1721ee2a8eed499914a4",
   "vout_sz":2,
   "out":[
      {
         "script_string":"OP_DUP OP_HASH160 a90cf97578df33b7d261105f3ba7b7297fd3f77d OP_EQUALVERIFY OP_CHECKSIG",
         "address":"1GQrjuC59UuDv3LqbhPHX5mREDY4521f12",
         "value":1299300,
         "script":"76a914a90cf97578df33b7d261105f3ba7b7297fd3f77d88ac"
      },
      {
         "script_string":"OP_DUP OP_HASH160 9f27c31c0bf89cb4958e7fc99c0f9117623b4e4b OP_EQUALVERIFY OP_CHECKSIG",
         "address":"1FWY5DxbgVSBbCwCDMwsgSPUCKQKWfjYWa",
         "value":0,
         "script":"76a9149f27c31c0bf89cb4958e7fc99c0f9117623b4e4b88ac"
      }
   ]
}

Per non inquinare gli UTXO bisognerebbe riuscire a sostituire l'ultimo pezzo della transazione con qualcosa del genere:

Code:

      {
         "script_string":"OP_RETURNquellochevuoi",
         "value":0,
         "script":"6a13quellochevuoi"
      }

ma non avendo più la firma iniziale, non c'è modo di fare questa modifica senza alterare l'hash che deve essere poi firmato. In teoria si potrebbe mantenere la firma iniziale che si trova nello scriptSig di input, ma allora bisognerebbe riuscire a modificare a tentativi la stringa "quellochevuoi" fintanto da riprodurre lo stesso sha256 iniziale, cioè dovresti ottenere una collisione in sha256  

[reee]

beh però la mia domanda era, ipotizzando che la prima transazione venga accettata, la seconda è fatta in modo corretto? Ho provato a farla con coinb ma non so se ho selezionato gli input correttamente.

[arulbero]

beh però la mia domanda era, ipotizzando che la prima transazione venga accettata, la seconda è fatta in modo corretto? Ho provato a farla con coinb ma non so se ho selezionato gli input correttamente.

No, devi selezionare il primo input (index = 0), con index = 1 stai cercando di spendere il secondo output

Code:

{
   "lock_time":0,
   "size":223,
   "inputs":[
      {
         "prev_out":{
            "index":1,
            "hash":"bc23946a4335370962015d7947e37717568852a83f4b1721ee2a8eed499914a4"
         },
         "script":"47304402201e143becfbc35268575711e73958bc0153bde0704bb52c54e585097b833cabd8022028fcca1f746d847289ab85bd91b5e1a8e543ea6fb11da3a14e4d9e34a20bbc230141041e18446ed1b491d776f8593efbd514b4fa0536996406d3983a5b76eaa8958d1bd67cb498be16c276008d89c13eb79e0287936c2339bbfadd2f5ba48a604415f5"
      }
   ],
   "version":1,
   "vin_sz":1,
   "hash":"c6de7d06cc99d9eb017925528cd5dd3d866fc02c1fce7dd98069d17d0bab69b0",
   "vout_sz":1,
   "out":[
      {
         "script_string":"OP_DUP OP_HASH160 ed766419e42b2b7bc1121fa2da949a104d9fbafa OP_EQUALVERIFY OP_CHECKSIG",
         "address":"1NeayR8k319gy3ygDs1SBkdTw4VpY5AbMc",
         "value":1100000,
         "script":"76a914ed766419e42b2b7bc1121fa2da949a104d9fbafa88ac"
      }
   ]
}

[reee]

ah ok, ora provo a correggere. Ma nella casella "Address, WIF key or Multisig Redeem Script:" cosa devo mettere? la chiave privata?

[arulbero]

ah ok, ora provo a correggere. Ma nella casella "Address, WIF key or Multisig Redeem Script:" cosa devo mettere? la chiave privata?

Mai usata, ho creato questa transazione senza firma:

Code:

0100000001a4149949ed8e2aee21174b3fa85288561777e347795d0162093735436a9423bc000000001976a914a90cf97578df33b7d261105f3ba7b7297fd3f77d88acffffffff01e0c81000000000001976a914ed766419e42b2b7bc1121fa2da949a104d9fbafa88ac00000000

e poi l'ho firmata con la tua chiave privata:

Code:

0100000001a4149949ed8e2aee21174b3fa85288561777e347795d0162093735436a9423bc000000008b48304502210088e67c2c15c180ef0ab1aa080fd0be96def4047c39a4f220b40f29d7edf3832e022020864f5f4edee7d5c508171bf7c11234c661e3513ccdb323c05b17287353d7a50141041e18446ed1b491d776f8593efbd514b4fa0536996406d3983a5b76eaa8958d1bd67cb498be16c276008d89c13eb79e0287936c2339bbfadd2f5ba48a604415f5ffffffff01e0c81000000000001976a914ed766419e42b2b7bc1121fa2da949a104d9fbafa88ac00000000

Code:

{
   "lock_time":0,
   "size":224,
   "inputs":[
      {
         "prev_out":{
            "index":0,
            "hash":"bc23946a4335370962015d7947e37717568852a83f4b1721ee2a8eed499914a4"
         },
         "script":"48304502210088e67c2c15c180ef0ab1aa080fd0be96def4047c39a4f220b40f29d7edf3832e022020864f5f4edee7d5c508171bf7c11234c661e3513ccdb323c05b17287353d7a50141041e18446ed1b491d776f8593efbd514b4fa0536996406d3983a5b76eaa8958d1bd67cb498be16c276008d89c13eb79e0287936c2339bbfadd2f5ba48a604415f5"
      }
   ],
   "version":1,
   "vin_sz":1,
   "hash":"dbfe0f0893e18ed3706c07bda7d937accf67aa587f2fa33ddba4f09e8c0c6e70",
   "vout_sz":1,
   "out":[
      {
         "script_string":"OP_DUP OP_HASH160 ed766419e42b2b7bc1121fa2da949a104d9fbafa OP_EQUALVERIFY OP_CHECKSIG",
         "address":"1NeayR8k319gy3ygDs1SBkdTw4VpY5AbMc",
         "value":1100000,
         "script":"76a914ed766419e42b2b7bc1121fa2da949a104d9fbafa88ac"
      }
   ]
}

[reee]

ok grazie, per curiosità che sito/programma hai usato per creare la transazione?

[arulbero]

ok grazie, per curiosità che sito/programma hai usato per creare la transazione?

coinb.in per creare e firmare, https://blockchain.info/it/decode-tx per visualizzarla in formato leggibile.

[arulbero]

Ho notato che nell'ultima versione di Bitcoin Knots  --> http://bitcoinknots.org/  (si trova anche nella pagina https://bitcoin.org/en/choose-your-wallet )

c'è la possibilità per i miner di disabilitare i controlli sulle transazioni non standard

-acceptnonstdtxn :  option to skip "non-standard transaction" checks

quindi in questo caso si apre una possibilità per la tua transazione dust, a patto di trovare un miner che utilizzi quel client con quella opzione attivata.


Qui si trova una lista di 3 client che modificano Core senza creare fork.

[reee]

Ho notato che nell'ultima versione di Bitcoin Knots  --> http://bitcoinknots.org/  (si trova anche nella pagina https://bitcoin.org/en/choose-your-wallet )

c'è la possibilità per i miner di disabilitare i controlli sulle transazioni non standard

-acceptnonstdtxn :  option to skip "non-standard transaction" checks

quindi in questo caso si apre una possibilità per la tua transazione dust, a patto di trovare un miner che utilizzi quel client con quella opzione attivata.


Qui si trova una lista di 3 client che modificano Core senza creare fork.

nella pratica quindi come potrei fare per provare ad inviare la transazione? devo installare quel client modificato? se è un clone di core immagino che scaricherà l'intera blockchain.

[arulbero]

nella pratica quindi come potrei fare per provare ad inviare la transazione? devo installare quel client modificato? se è un clone di core immagino che scaricherà l'intera blockchain.

Penso proprio di sì, servirà l'intera blockchain. Ma soprattutto poi ci deve essere un miner che utilizza quel client con quella opzione attivata che accetti la tua transazione nella sua mempool e riesca a minare un blocco.