Transaction forwarding

[theZerg]

I am investigating why it can take many minutes to synchronize a few thousand (a few MB of) transactions.

The Satoshi client transaction forwarder employs some techniques to obfuscate the source of transactions. In particular, if a node requests transactions (a INV message), it randomly defers announcing knowledge of 3/4ths of the transactions to subsequent requests, recursively. And it slows down the speed of subsequent requests. The idea is that doing so may give a transaction time to propagate to you via other nodes.

While this feature may be valuable for people who are using the wallet functionality (to obfuscate their locally created txns), I wonder if it is valuable for nodes that are being deployed mainly to help route bitcoin traffic and distribute it to SPV clients.

In particular, I am contemplating adding an option that reduces or eliminates the transaction delays.

The use cases for the Satoshi client are fracturing into personal, mining, merchant/exchange, and super-node specializations... and ultimately I could see an option that lets the user choose one of these "personalities" (presuming that different clients don't grow to fulfil separate roles) which then changes all of the specific options to fit that personality.

What do you think?

 

[solex]

@theZerg I have been thinking about what you have described. My preference is not to deliberately try and fracture the client into too many specialized types. It will happen long-term, but in the short-term there is an advantage for a node being a jack-of-all-trades i.e. multiple "personalities".

In this specific example where there is an argument for obfuscating a transaction source, could this be better done by looking at the context. So, a full node might internally switch to employing obfuscation once the wallet tab has been opened in preparation for a locally generated transaction, while the rest of the time it employs efficient techniques as it doesn't care so much about obfuscating other people's tx? Of course that is just one use-case.

 

[theZerg]

Yes just obfuscating your txns helps but if the next node down the line isn't obfuscating then your txn source can still be narrowed down. Development wise a global option is a lot simpler...

 

[Peter Tschipper]

I think it's a great idea to have a user selected options...perhaps not too many, for now maybe just one for privacy and one for high performance. The obfuscating or trickle logic is a real impediment to high performance. There is a required 100ms delay in the message queue handler that has been shown to not only be a performance issue but also causes node connections to get hung on windows. If we are going to take this up to another level performance wise then that trickle logic should come out IMO, at least for the users that want high performance...for those that want privacy then we could and should optionally leave it in and make the node more user configurable.