user2092: 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.

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?"


user4382: 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.

2092: <h1>Small Sample of Concerns Belonging to Larger Family of Unknown Real or Figurative Concerns</h1>
<p>I would like to send my predetermined <code>Slot Leader</code> reports to PoolTool, yet I only use the API key they provide for sending tip heights.</p>
<p>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.</p>
<p>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:</p>
<ul>
<li>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.</li>
<li>Is this easier when colluding with other giants?</li>
<li>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.</li>
</ul>
<h2>Effect on Operator Behavior</h2>
<p>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?</p>
<p>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.</p>
<h1>Bounty Will Likely Not Be Rewarded Within Seven Days</h1>
<p>I am asking for a canonical answer. @Anton, tried to derive one, but I see holes that I can comment on later.</p>
<p>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.</p>
<h2>Upvote and ADA-only Recipients</h2>
<p>So far these are those delegators, with the first satisfying all of the listed qualities.</p>
<ol>
<li>Ticker: SNOWY for <a href="https://cardano.stackexchange.com/a/4464/2092">Anton's Answer</a> - OP comments,</li>
</ol>
<blockquote>
<p>&quot;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 <code>POST</code>ing (every second as required) its <code>Tip Height</code> API
endpoint, which does some processing on before responding to the <code>POST</code>. 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 <strong>Slot Battle</strong> diagram based on what <em>delegators</em> are
reporting to <em>relays</em> and other <em>delegators</em>. I don't even think it
asks if a <em>delegator</em> is saying it is the <strong>Slot Leader</strong>.</p>
<p>The API has nine endpoints, but Amazon masks their location, claiming
they are all in the US. But they appear to be AWS CloudFront &quot;Web 3.0&quot;
CDNs, and that a show of good faith if CloudFront was chosen for its
equal access to low-latencies ambitions:</p>
</blockquote>
<pre><code>&gt; To deliver content to end users with lower latency, Amazon CloudFront
&gt; uses a global network of 275+ Points of Presence (265+ Edge locations
&gt; and 13 regional mid-tier caches) in 90+ cities across 47 
&gt; countries. Amazon CloudFront Edge locations are located in: 
</code></pre>
<p><a href="https://i.stack.imgur.com/lQXMG.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/lQXMG.png" alt="CloudFront Edge. &quot;Moreless,&quot; Foxy Brown on a Shyne song" /></a></p>
<blockquote>
<p>&quot;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.&quot;<br />
&quot;Meanwhile, the orphan graph reminds me of a PoolTool page, or the
other way around...&quot;</p>
<p>[Middle Finger Emoji to almost every stake holder]</p>
<p>&quot;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.&quot;</p>
<p>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 <a href="https://PoolVet.io#PPDAC" rel="nofollow noreferrer">PoolVet</a> claiming if you don't
comply, go let the Best Practices Group promote gain over virtue.</p>
</blockquote>
<p><a href="https://i.stack.imgur.com/Gbw7j.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/Gbw7j.png" alt="Shut up PoolVet" /></a></p>
<blockquote>
<p>&quot;And on and on,&quot; he continued ranting.
&quot;Where's the utility? What's this project really about?&quot;</p>
</blockquote>
 4382: <p>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.</p>
<p><strong>What happens when they [PoolTool] know I won the slot lottery?</strong></p>
<p>After going through the <a href="https://github.com/AndrewWestberg/cncli/blob/develop/INSTALL.md" rel="nofollow noreferrer">CNCLI documentation</a>, 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 &quot;slot&quot;, the &quot;slotInEpoch&quot; and an &quot;at&quot; 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.</p>
<p><strong>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.</strong></p>
<p>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.</p>
<p><strong>Is this easier when colluding with other giants?</strong></p>
<p>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. (<em>Still a big if</em>). The other would be a 51% attack if you got enough people to join you. This would be extremely unlikely to happen though.</p>
<p><strong>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.</strong></p>
<p>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.</p>
<p><strong>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.</strong></p>
<p>I believe the utility would be keeping a more up-to-date Orphaned block tab for PoolTool. In general, it would be statistical.</p>
<p>I hope this is helpful.</p>
