Fluff & aggregation tracker

Tech Support
1

I’d really like to track how many transactions my node fluffs and whether it aggregated any of them.

Is there a way to do that (somewhat) easily?

2

If you log at debug level then I believe you should be able to parse this out of the logs.

3

Sweet, thank you @antioch. I’m now tracking three things on my debug log:

$ tail -f ~/.grin/main/grin-server.log | grep "in/out/kern"
and
$ tail -f ~/.grin/main/grin-server.log | grep "broadcast_transaction"
and
$ tail -f ~/.grin/main/grin-server.log | grep "Aggregating"

Also, I know that I need to allow inbound connections if I want to receive stem txs before they’re fluffed, but do I receive them only from inbound peers? Or can I receive them from outbound peers as well? (with port 3414 being open).

p.s. a transaction with more than 350 inputs was just broadcasted a few minutes ago, was fun to catch live.

4

Peers will only relay a stem tx to an outbound peer connection.
So you will only receive them via an inbound peer connection.

If both your node and the peer are “public” then it depends who connected to who first. One side of the conection will be inbound and one outbound.

The motivation for this is to prevent a supernode connecting to large numbers of nodes on the network and tricking them into relaying stem txs. You have to explicitly connect outbound to a peer, before relaying stem txs to them. And you only need 8 outbound connections, presumably most of which are long-lived, so you are unlikely to connect to a brand new (super)node appearing on the network.

2 Likes
5

If you grep for dand_mon and DandelionEpoch in the logs also you should see the “Dandelion Monitor” thread doing some stuff also.

6

Will do, thanks.

Let’s see what my node is actually doing.

7

@antioch here’s a line logging a tx that i fluffed:

add_to_pool [txpool]: 27787cac0016 (Fluff) [in/out/kern: 2/2/1] pool: 0 (at block 0000218a4e1e)
(changed the actual values to keep privacy)

  1. Do you know of any explorer that allows searching for blocks only by their first 12 characters, as the log show?
  2. I can find the 0000218a4e1e block but not any mention of the value 27787cac0016, I thought it would be the first 12 chars of a kernel excess. what does it represent?
  3. How does my node log the tx fluffing action and at the same line log the block it would be included in? A transaction obviously has to be broadcast before the block (which it ends up in) is found, so what am I missing?
8
  1. Grinscan allows searching for a subset of the characters.
  2. 27787cac0016 is the transaction hash, which is not on chain, and differs based on how the transaction is aggregated.It’s not an incredibly useful hash. It’s probably better to log the kernel there, but there could be multiple kernels per transaction, so it would need to change to log a list.
  3. I can only assume that’s the block the pool is currently building on top of (ie, it’s the most recent block, but doesn’t include that transaction).
9
  1. Huh, I thought I tried Grinscan already. It works, sweet.
  2. I see, too bad.
  3. You’re right. For some reason I imagined seeing the tx ended up in that block too.

Thanks @david.

My node actually managed to aggregate quite a few transactions tonight because I set aggregation_secs = 120 and stem-probability = 0. Pretty satisfying to see them on chain.

edit: for future reference I’ll mention that it’s helpful to keep track of keywords add_to_pool, (Fluff) and stempool.

2 Likes