What Utility Do Third-Party Services Provide with Undisclosed Slot Lottery Information?

Question

Small Sample of Concerns Belonging to Larger Family of Unknown Real or Figurative Concerns

I would like to send my predetermined Slot Leader reports to PoolTool, yet I only use the API key they provide for sending tip heights.

What happens when they know I won the slot lottery? At first I was very paranoid and could only imagine slot leader, even when plural for a single slot, is private information not for public disclosure. But aha, it's not! At least I am unable to find it on PoolTool after a reasonable search.

Worse though, it's not public and not private, so it's valuable information in the hands of a privileged few, or so I thought to myself. My reasoning being if I am an SPO with a relay or two, and the Whales and pre-AML/KYC bullies are around, it would be trivial to assault my nodes, and also interesting:

• Can we force a Slot Leader to fail to forge with a given attack that is cheap enough to put me back in the lottery for that slot? DDoS cheap, for example.
• Is this easier when colluding with other giants?
• Could small SPOs be denied the ability to mint new blocks in the worst case scenario of mass-collusion scenarios where the at least one of the collaborators would have a better chance at being the slot leader than they did if they were to do nothing.

Effect on Operator Behavior

So I never reported, yet I still missed two blocks when I was slot leader anyway. Now that I've probably figured out the network issues causes this, I will report my slot, just because, why not?

But still, what utility is being served by conceding privileged information to a community member, which means many things from competitor to valued contributor, but still a private third-party.

Bounty Will Likely Not Be Rewarded Within Seven Days

I am asking for a canonical answer. @Anton, tried to derive one, but I see holes that I can comment on later.

Therefore, I will delegate to the answers I find interesting, thought-provoking, reasonable-yet-contradicting, and so on; just ones I personally found valuable. I encourage you to do the same.

Upvote and ADA-only Recipients

So far these are those delegators, with the first satisfying all of the listed qualities.

1. Ticker: SNOWY for Anton's Answer - OP comments,

"having the previous slot would be quite the computational challenge alone, and it does take days or weeks for those pages to populate, but they don't show a decision tree for a slot battle–maybe a deceptive illustration of 3,100 pools POSTing (every second as required) its Tip Height API endpoint, which does some processing on before responding to the POST. Like wanting to know which node your running, if it's a release or dev build, other things it must record before responding. It does not report a Slot Battle diagram based on what delegators are reporting to relays and other delegators. I don't even think it asks if a delegator is saying it is the Slot Leader.

The API has nine endpoints, but Amazon masks their location, claiming they are all in the US. But they appear to be AWS CloudFront "Web 3.0" CDNs, and that a show of good faith if CloudFront was chosen for its equal access to low-latencies ambitions:

> To deliver content to end users with lower latency, Amazon CloudFront
> uses a global network of 275+ Points of Presence (265+ Edge locations
> and 13 regional mid-tier caches) in 90+ cities across 47 
> countries. Amazon CloudFront Edge locations are located in: 

"Looks nice, but you can't know where they are. You can experiment, but if you just want gains you don't experiment, you stake in the most developed of Western Europe, hedging in the coasts of the US, because it had had an inflation clock downtown from me since before I was born, and the world likes it that way. AAA debt for sale for almost all of me and that clock's life, ala CIA and USN, and so on."
"Meanwhile, the orphan graph reminds me of a PoolTool page, or the other way around..."

[Middle Finger Emoji to almost every stake holder]

"Okay, I'll lay off pooltool, or why it doesn't report past slot leader, leader arrays, empty slots, or pull from the verbose as the need for a reconstructed Globe Theater."

What if you just need 51% of topology pathfinders to agree that your AWS CloudFront WebAPI is gospel? You'd make a topologyUpdater script that basically reinforced this Western exploit attacking the single-second slot. Sites like PoolVet claiming if you don't comply, go let the Best Practices Group promote gain over virtue.

"And on and on," he continued ranting. "Where's the utility? What's this project really about?"

Answer 1

I had to do a lot of digging but this is what I have came up with. Please correct me if any of this is incorrect and I'll update the answer.

What happens when they [PoolTool] know I won the slot lottery?

After going through the CNCLI documentation, it looks like the intention is to only ever send the Current and Previous slot leader. Furthermore, when I look at the json result for a LeaderLog, it returns the "slot", the "slotInEpoch" and an "at" which is a date time. Based off knowing this payload as well as the intended use, I am guessing they are using it to fill in the Orphans section of the site before rewards are calculated. Looking at a couple of examples, I am only seeing Orphans 3 to 4 Epochs back (so 297/298). I believe with these logs they could fill in more realtime.

Can we force a Slot Leader to fail to forge with a given attack that is cheap enough to put me back in the lottery for that slot? DDoS cheap, for example.

If you could keep the relays down long enough for another slot leader to propagate, then yes you could. If the pool is protecting against DDOS/DOS attacks, then this is probably unlikely to work.

Is this easier when colluding with other giants?

If you were a pool like Binance, with 42 saturated pools, then you could potentially cause issues for other SPOs by denying them in your topology files. This could potentially cause issues for their propagation. (Still a big if). The other would be a 51% attack if you got enough people to join you. This would be extremely unlikely to happen though.

Could small SPOs be denied the ability to mint new blocks in the worst case scenario of mass-collusion scenarios where the at least one of the collaborators would have a better chance at being the slot leader than they did if they were to do nothing.

Short answer yes but it would likely be a very small effect. The example would be the Binance one above. This also could be worse if the pool has no protection against DDOS type attacks.

What utility is being served by conceding privileged information to a community member, which means many things from competitor to valued contributor, but still a private third-party.

I believe the utility would be keeping a more up-to-date Orphaned block tab for PoolTool. In general, it would be statistical.

I hope this is helpful.

Answer 2

Something that could be done is to ask stake pool operators to report just the number of blocks they have been awarded for the next epoch. They could report this just prior to the start of the epoch.

If a pool operator chooses to report his number of slots awarded then he would be incentivised to report the correct number.

He must tell the truth because if he lied by reporting just one less than the actual number, he will be found out if/when his pool successfully produces all its blocks. Maybe occasionally his pool will lose a block to a slot battle etc. but mostly it will produce all the blocks issued and then if he lied by saying less then everyone will know. He will then lose trust with the community.

I don't think reporting slots issued like this would create a security concern because no one would know the actual timing of the slots issued except for the pool operator himself. Even knowing the precise number of slots awarded doesn't reveal anything much since this amount can be approximated simply by looking at the total amount staked at his pool.

I did think about sending abridged slot leader reports like this but didn't look into where to send this information. I certainly formed the opinion that there was no way that I was going to send the full slot leader reports containing the timing because, as you say, that would provide timing information to potential attackers.

Answer 3

Please correct me if I'm wrong, but I think this is a non-issue if you don't send upcoming slots/the slot leader schedule, but use the Sendslots command instead:

CNCLI does not send the slot number and/or date and time of the blocks you are assigned to mint. Straight from the CNCLI Git:

Sendslots command

The sendslots command securely sends pooltool the number of slots you have assigned for an epoch and validates the correctness of your past epochs. You must have a synchronized cncli.db database and have calculated leader logs for every pool in pooltool.json before calling this command. It should be called within the first 10 minutes of the epoch cutover.

Here is an example:

2020-12-01T03:34:33.883Z INFO cncli::nodeclient::leaderlog > Sending: {"apiKey":"blah-blah-blah","poolId":"00beef0a9be2f6d897ed24a613cf547bb20cd282a04edfc53d477114","epoch":232,"slotQty":25,"hash":"d15b6c8d4c81fe48cff0650c5b59ab20da9765374c58c933dacd058eb38bb670"} 2020-12-01T03:34:33.969Z INFO cncli::nodeclient::leaderlog > Pooltool Response: {"statusCode":200,"headers":{"Content-Type":"application/json","Access-Control-Allow-Origin":"*"},"body":"{"success":true,"message":"We have updated your assigned slots for epoch 232 to be 25 with a hash of d15b6c8d4c81fe48cff0650c5b59ab20da9765374c58c933dacd058eb38bb670. You must provide an array of slots that matches this hash to have your performance counted."}"}

So as I understand, pooltool does not know which slots you are assigned to and they can't find out based on the info CNCLI sends to them.