Replace By Fee

Les comissions per transacció tenen un paper fonamental en el bon funcionament del protocol Bitcoin. Aquestes comissions actuen com a incentiu econòmic per als miners, que competeixen per crear un bloc —que inclou transaccions— i calculen un hash d’aquest bloc que compleixi la dificultat mínima requerida perquè esdevingui un bloc vàlid. Aquest procés és el que anomenem “minerar un bloc”, i el miner que minaria amb èxit un bloc vàlid rep la recompensa actual de bloc de 3,125 BTC com el 2025, més totes les comissions de les transaccions incloses en aquest bloc.

Com que la mida del bloc és limitada, els miners tendeixen a prioritzar les transaccions amb comissions més altes, ja que això els permet maximitzar els ingressos que obtenen.

En aquest context, cada vegada que un usuari vulgui enviar una transacció, ha de definir quant està disposat a pagar en comissions perquè la transacció sigui acceptada i confirmada en el següent bloc. Si l’usuari estableix una comissió massa baixa, la transacció pot trigar molt a confirmar-se, o potser no s’inclourà mai en cap bloc i, finalment, es descartarà.

Actualment, el protocol Bitcoin ofereix dues alternatives per resoldre aquest problema: Child Pays For Parent (CPFP) i Replace-by-Fee (RBF). Ambdues poden ajudar a que una transacció s’inclogui en un bloc més aviat augmentant la comissió total que un miner guanyaria per incloure-la.

RBF permet que una transacció pendent sigui substituïda per una de nova que paga una comissió més alta, augmentant així les seves possibilitats de ser confirmada ràpidament.

Problemes de privadesa de Bitcoin

• Tot i que Bitcoin sovint es percep com un sistema anònim, la seva arquitectura no garanteix la privadesa per defecte. Cada transacció es registra públicament a la cadena de blocs, cosa que permet analitzar-les i establir possibles vincles entre adreces. Les sortides d’una transacció, que posteriorment s’utilitzen com a entrades en una altra transacció (conegudes com a UTXO), s’han de gastar íntegrament. Això normalment significa que les transaccions de pagament solen incloure una sortida de canvi que retorna BTC a l’emissor.
• Analitzant una transacció, sovint és possible identificar quina sortida va ser el pagament (enviat a un tercer) i quina va ser el canvi (retornat al remitent). Si es detecta la sortida del canvi, es fa més fàcil identificar quina adreça pertany al remitent, cosa que compromet la traçabilitat de la seva activitat a la cadena de blocs.
• Hi ha heurístiques per detectar canvis en les sortides, com ara comparar valors de sortida, tipus d’adreces o analitzar patrons típics de construcció de transaccions utilitzats pels moneders. Aquestes tècniques poden posar en risc la privadesa de l’usuari.

Què és RBF?

La política de reemplaçament per tarifa és una política de mempool que permet que la transacció sigui reemplaçada per una de nova que comparteixi almenys una de les mateixes entrades, però pagui una tarifa més alta. Quan es produeix aquesta substitució, ambdues transaccions (l’original i la de substitució) mai coexisteixen al mempool. Un cop acceptada la nova, s’elimina l’antiga. La política RBF s’ha utilitzat durant un temps, però hi ha diferents maneres d’aplicar-la:

• RBF de primera vista segura: aquesta variant permet substituir una transacció si la nova paga comissions més altes i té les mateixes sortides que la transacció original. Això es va proposar en els primers dies a causa de la preocupació (posteriorment refutada) que RBF podria facilitar atacs de doble despesa.
• RBF opcional: Aquesta variant només permet que una transacció es reemplaci si la transacció original ha definit un camp específic que indica que es pot reemplaçar. L’inconvenient d’aquest mètode és que l’usuari ha de saber per endavant si vol reemplaçar la transacció. Per aquest motiu, molts usuaris generalment marquen les transaccions com a reemplaçables en cas que les necessitin reemplaçar més tard.
• RBF retardat: Aquesta variant permet que una transacció sigui substituïda després que s’hagi minat un cert nombre de blocs.
• RBF complet: Aquesta variant permet que qualsevol transacció sigui substituïda, sempre que la nova transacció pagui com a mínim les comissions totals de la transacció o transaccions originals més una comissió addicional suficient per cobrir el seu propi cost de relé. Un node substitueix una transacció quan detecta que una nova transacció utilitza com a mínim una de les mateixes entrades i paga comissions més altes. Actualment, a la versió de Bitcoin Core (v28.0), s’aplica el RBF complet a totes les transaccions. Això significa que les transaccions no cal marcar-les explícitament com a substituïbles, sinó que es poden substituir directament. El mempool detecta una substitució quan una nova transacció intenta entrar utilitzant una entrada que ja està sent gastada per una altra transacció del mempool. Quan això passa, comprova que la nova transacció superi la taxa de taxa (BTC/byte) i la comissió total (és a dir, el total de BTC pagats en comissions).

Detecció de canvis de sortida amb RBF

Quan s’utilitza Replace-By-Fee (RBF), la transacció de reemplaçament sol ser molt similar a l’original; l’única diferència important és l’augment de la tarifa. Si algú està monitoritzant el mempool i capturant totes les transaccions emeses, podria obtenir tant la transacció original com la de reemplaçament.

Com que aquestes dues transaccions són gairebé idèntiques, un observador maliciós podria comparar-les per identificar quina sortida és el pagament i quina és el canvi. Això comprometria la privadesa del remitent en revelar l’adreça que li pertany.

Explorem alguns escenaris comuns en què RBF pot perjudicar la privadesa del remitent:

• Mateix nombre de sortides:
  • Dos Sortides:
    • Aquest és el cas més simple. La presència de només dues sortides facilita la identificació del canvi (ja que una de les sortides és el pagament i l’altra el canvi). Per detectar la sortida del canvi, comparem les sortides de la transacció original i la seva substitució: si una de les sortides és idèntica en ambdues versions, suposem que és la sortida del pagament; l’altra, que canvia de valor, es considera el canvi, ja que reflecteix l’ajust associat a la diferència de comissions.
    • 
    • En el primer exemple (TX1 i TX2), observem que una de les sortides roman igual, mentre que l’altra disminueix de valor. Aquest comportament és coherent amb l’augment de les comissions en la transacció de reemplaçament: si les entrades són les mateixes, una comissió més alta només es pot reflectir en una reducció de la sortida de canvi.
    • En el segon exemple (TX3 i TX4), es produeix el mateix patró de comparació, però en aquest cas, la sortida que canvia augmenta de valor. Això pot passar si s’ha modificat una de les entrades, de manera que, malgrat la tarifa més alta, l’augment del valor de l’entrada compensa la diferència i fa que l’import del canvi creixi.
    • Aquest tipus d’anàlisi és especialment fiable en transaccions amb dues sortides, ja que només hi ha una sortida de pagament possible i una sortida de canvi, cosa que elimina l’ambigüitat.
  • Més de dues sortides:
    • Aquest cas és una petita evolució de l’anterior.
    • Aquí, analitzem transaccions amb més de dues sortides, però la idea subjacent continua sent la mateixa: comparem les transaccions de substitució amb una sortida que té un valor diferent. Aquesta sortida, que és diferent, s’identifica com el canvi.
    • Tanmateix, a diferència dels casos amb exactament dues sortides, no podem garantir que les sortides restants siguin totes pagaments. Si bé podem assumir que la sortida identificada com a canvi és realment el canvi, no podem descartar que algunes de les altres també puguin ser canvis. En general, podem assumir que les sortides sense canvis corresponen a pagaments, però també hem de considerar la possibilitat que alguns moneders creïn intencionadament múltiples sortides de canvi per dificultar la detecció mitjançant heurístiques.
    • 
    • En el primer exemple, observem que totes les sortides romanen inalterades excepte una, que disminueix de valor. Seguint la mateixa lògica que en casos anteriors, aquesta sortida es considera el canvi.
    • Aquests són els casos més bàsics i també els que ofereixen les garanties més fortes a l’hora d’identificar correctament la sortida d’un canvi.
  • Per comprovar si aquests escenaris comuns eren realment efectius a l’hora de detectar els canvis de sortida, vam desenvolupar un programa per capturar transaccions reals al mempool que s’havia substituït. Més tard, vam buscar transaccions que seguissin aquests patrons i vam intentar deduir els canvis de sortida. Aquests van ser els resultats:
  • 
  • Els escenaris anteriors representen el 76% de totes les transaccions capturades. Això indica que, tot i que és el cas més fàcil per identificar el canvi de sortida, també és el més comú.
  • Com es mostra a la Figura 7, quan la transacció només té dues sortides, la sortida de canvi es detecta en el 88,6% dels casos. En aquest escenari, podem estar segurs que la sortida de canvi identificada és correcta, ja que l’altra sortida ha de correspondre necessàriament al pagament.
  • En transaccions amb més de dues sortides, els resultats continuen sent positius, però és important tenir en compte que no sempre podem estar segurs que la sortida identificada sigui l‘única sortida de canvi present a la transacció.

• Nombre diferent d’entrades
  • This case presents a greater difficulty compared to the previous ones. Until now, the comparison between different versions of a replaced transaction was relatively simple, as the number of outputs remained the same across versions. However, in this scenario, each replacement may contain a different number of outputs, which significantly complicates the task of identifying the change output.
  • In these cases, we do not have many clear patterns that allow us to reliably identify the change. The only pattern we’ve observed with some consistency is characterized by the appearance of an additional output in each replacement. We observe that, except for one, the rest of the outputs maintain the same value across versions, allowing us to assume they are payment outputs. The output that does change in value is split into two new outputs.
  • 
  • Seguint l’exemple, veiem que de la transacció TX1 a TX2, la sortida 12 es divideix en dues noves sortides, 22 i 23. La suma d’aquests dos nous valors és gairebé igual al valor original de 12, tenint en compte l’augment de la tarifa associada a la substitució. Això suggereix que la sortida 12 era molt probablement la sortida de canvi. El mateix patró es repeteix en el pas de TX2 a TX3.
  • Aquest comportament ens pot ajudar a identificar les sortides de pagament (aquelles que mantenen un valor constant), però quan es tracta d’identificar la sortida de canvi, sempre ens deixa amb almenys dos possibles candidats. Sense l’ajuda d’heurístiques complementàries addicionals, no és possible determinar amb certesa quina de les dues sortides és realment el canvi. A més, és important tenir en compte que no podem assumir que només hi ha una sortida de canvi

• Altres heurístiques:
  • Hem vist l’alta efectivitat en la detecció dels canvis de sortida en transaccions que utilitzen la política Replace-by-Fee (RBF). Això ens porta a fer-nos la següent pregunta: aquesta efectivitat és realment tan alta com sembla, o és simplement habitual que els canvis de sortida siguin tan fàcilment identificables? Per respondre a això, hem comparat els resultats obtinguts amb heurístiques per a la detecció de canvis de sortida.
  • Per fer aquesta comparació rigorosa, ens hem centrat exclusivament en transaccions simples amb dues sortides. Aquesta elecció es deu al fet que és l’escenari més senzill i fiable. A més, en el cas més bàsic (dues sortides), podem assumir amb un alt grau de confiança que la sortida identificada com a canvi per RBF és correcta, cosa que facilita la comparació i la validació dels resultats heurístics.
  • Per a cada cadena de transaccions RBF, només vam analitzar la transacció final (és a dir, la versió que finalment acaba a la cadena de blocs). Aquest enfocament es va escollir perquè les heurístiques funcionen amb la transacció confirmada i no tenen en compte les versions anteriors que van ser substituïdes.
  • Els resultats obtinguts d’aquesta anàlisi es mostren a la taula següent: | | Total de transaccions RBF | 36.819| | RBF | 33.419| | Heurística de canvi òptim | 23.119| | Coherència del tipus d’adreça Heurística | 24.353| | Pagaments amb número arrodonit Heurística | 18.452|
  • We now can confirm, that the RBF herusitics is much supperior to the classic heuristics used to detect the output change.

Com podem millorar la nostra privadesa?

• Ara que entenem els problemes de privadesa associats amb l’ús de RBF, hi ha alguna manera d’evitar-los? Afortunadament, hi ha algunes estratègies que poden dificultar aquest tipus d’anàlisi, cosa que dificulta la detecció de canvis.
• La primera estratègia és crear una transacció de reemplaçament amb un nombre de sortides diferent en comparació amb la transacció original. Tot i que encara es podria inferir alguna informació, aquesta variació complica la comparació entre les sortides entre versions.
• També vam observar que moltes transaccions reutilitzen les mateixes adreces en totes les substitucions. Aquest és un problema crític, ja que facilita molt que un actor maliciós identifiqui el canvi de sortida.
• Finalment, si és molt important per a vosaltres evitar la detecció de canvis, podeu incloure més d’una sortida de canvi. Això afegeix ambigüitat i garanteix que no tots els canvis es puguin rastrejar amb confiança fins a vosaltres.
• Seguint aquests passos, podeu millorar la vostra privadesa, tot i que val la pena tenir en compte que aquests mètodes solen comportar comissions més elevades a causa de l’augment de la mida de les transaccions.