Hello devs,

Shared new code for bitcoin backbone available on the website
(bitcoinbackbone.org). Biggest changes from latest release has
been mostly working on BIP324 re-implementation, cleaning bugs
implementing a simple tx-relay stack, a little mempoool buffer
and some groundworks on address management. Tx syncing works with
vanilla bitcoin core v0.30 software.

I did a layout of the process architecture on the website, but the
mempool is fully living in its own mempool process, fully separate
from the block pipeline. In case of mempool DoS for whatever reasons,
the full-node keeps processing blocks. This also opens the door to
have *multiple* mempools with incompatible policies among themselves,
and just select the highest fees paying graph of consensus-valid
transactions, after sanitizing out conflicts.

As I was writing in my latest email about bitcoin backbone, of course
there are some trade-offs with the mempool not living in the same memory
space than the validation engine, though I think you have practical
improvements on this area.

The simple tx-relay stack also implements a basic implementation of the
proposed overhaul of the tx-relay v2 [0]. Currently, the tx flow is
INV(txid) -> ; <- GETDATA(inv(txid)) ; TX(tx) -> . With the proposed 
tx-relay
v2 overhaul, if an INV for the txid has not previously received for the
transaction, i.e the transaction processing has not been requested, the
transaction is strictly rejected, without further processing. This more
stricter tx processing can be activated with a setting option in bitcoin
backbone.

Long-term, I think some form of tx-relay link-level mitigation is a strong
necessity to diminish the surface attack of time-sensitive contracting
protocol in face of tx-relay throughput overflow, where a malicious peer
is buying out your full-node tx bandwidth to tamper with the propagation
of a time-sensitive tx (e.g a lightning's HTLC-preimage) [1].

The day we wish to improve time-sensitive second-layers tx-propagation
security, it might take time to have network-wide upgrade of the full-node
and wallets participating in tx-relay (you have deployment transition
problem, where traffic from non-upgraded tx-relay clients can be used to
jam the outgoing traffic of upgraded tx-relay nodes or clients). So doing
a heads up on that sounds wise, there are clearly well-used wallet library
that have never respected the INV -> ; <- GETDATA ; TX -> relay flow [2] [3]

Finishing to have Erlay support in bitcoin backbone, then I'll work on a 
more
refined version of the tx-relay V2 protocol proposal, because current 
version
of the draft proposal on the BIP repo is silent on advanced tx 
synchronization
protocols.

This is still mostly a very toy full-node but it's taking shape.

Keep building.

Cheers,
Antoine
OTS hash: 79ae6e1fda391d3aa44d36f26acb32b3871d01543037d467a8210e4e96c972a8

[0] https://groups.google.com/g/bitcoindev/c/PkNlRu1ylX4
[1] https://groups.google.com/g/bitcoindev/c/GuS36ldye7s
[2] E.g bitcoinj 
https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/core/TransactionBroadcast.java#L178
[3] Dropping unrequested transaction is only one approach on mitigating 
that,
but a simple first building block on which more sophisticated mitigation 
strategies
can be built.

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/299d4f39-b8cd-4736-b6bb-71def4d85f74n%40googlegroups.com.