![stamp-denied.jpg](https://files.peakd.com/file/peakd-hive/edicted/EpNtmmKa887wZdDAMwmA3NVutZHzBYueS9aCab8ytSGCcSyndodpmtvT1VFtrEgMCKZ.jpg)

##### So the other day I checked my voting power and it seemed a bit low...
>  That's weird I don't remember casting any votes today. 

After checking a block explorer I noticed that my account was making several 40% votes on some kind of curation train... which is weird because I don't cast 40% votes.  I don't remember signing up for that. Checked which accounts I had given posting key authority to and it came down to:

1. Ecency
2. Threespeak

#### Truth be told I thought it was more. 
I forgot that a while back I did quite a purge on accounts that had my posting authority.  After all, any account that has it can upvote and comment in my name (even if they pinky promise not to).  It's always a good idea to check them from time to time, and granting active key authority is almost always a bad idea (unless you control both accounts or unilaterally trust the account with your money).  If you haven't checked them in a while head on over to https://peakd.com/@edicted/permissions (replace @edicted with your username).  Always good to clean house once and a while. 

So I revoked authority from Ecency and waited to see if the auto-upvoting would end. I thought it was a bit odd that I couldn't see which account was signing my transactions.  Isn't that something that should appear within the API?  I guess not.  I've been told the only information that remains is simply that "the signature is valid" for "optimization issues".  

Which again I find pretty odd because all Hive nodes have to make sure that the signature is valid anyway.  If the signature isn't valid for @edicted's public key then it just has to go down the line and check every other account that has @edicted's posting key authority.  Makes me wonder if there is some kind of exploit there that would allow Hive to be bogged down. 


![Threat-vectors-attack.png](https://files.peakd.com/file/peakd-hive/edicted/Eo6KVTwH9KiNAG8EZ4EgcfUKx2XRj4gTQh5FSnqNesD681MGW9xECi3NMbdbekaufHS.png)


For example: What would happen if someone created a million Hive accounts and then added posting authority for each account to every other account?  A million accounts with a million posting authorities each.  Then sign a million messages with the million accounts using a random key (or maybe not random at all if nodes check in alphabetical order and you sign everything with an accounts starting in 'z').  

All of a sudden every Hive node has to do a trillion account checks on operations that are essentially free (we can currently post a surprising number of custom JSONs to chain with 0 Hive powered up and 0 RC delegations).  Of course this ignores the initial cost of creating a million accounts and then setting posting authority a trillion times.  However, assuming such a thing is possible once an annoyance like that is up and running the attack becomes relatively free. 

Of course I'm just spitballing here and really have no idea how it EXACTLY works which is very much required for attack vectors of this kind.  For example if the data was in an ordered list it could be traversed using a binary sort which would reduce the million lookups to log base 2 of a million (which is 20).  I don't know how it would be possible to order such a list when signatures are pretty much random and can't be linked back to the account that signed them without explicitly checking (AFAIK). 



I don't know to me it just seems like a glaring oversight that messages signed by other accounts don't have to declare which account they are using to sign the message. Or maybe I'm just annoyed that I put effort into figuring out who was signing my upvotes and came up empty handed because I was too 'lazy' to write a script that would check each one on the list by brute force (in this case all two of them).  Aint nobody got time for that. 


###### This actually reminds me of the hostile takeover now that I think about it. 
Because even if a threat vector like this did in fact exist the witnesses could just do what they did back then: ignore the accounts trying to post to chain and refuse to include their transactions.  It's technically every witness's choice as to what they include in their block.  If all the witnesses get together and decide to unilaterally exclude certain content from the chain that is totally allowed, and only requires a 'soft-fork'.  However even then it's not really a fork at all just an optional filter on any given node.

Interestingly enough this is also totally allowed and part of Bitcoin core as well. Any miner/node can choose what goes into a block and what doesn't.  It's just much harder to collude on bitcoin because of POW mining and the financial incentives and decentralization that comes along with it. But enough about this rando thought experiment. 

Another solution to this make-believe problem would be for witnesses to require certain meta-data to be approved for posting data to chain (like your account) and then this meta-data would simply get thrown away later after confirmation.  Of course anyone booting up a new node then runs into the same issue of not being able to easily verify the data because the meta-data has been discarded.  So I guess what I'm trying to say here in the most roundabout way possible is that crypto is ~~needlessly~~ complicated. 

![guess-and-check.png](https://files.peakd.com/file/peakd-hive/edicted/23xVgepbdJfmG1iP3pBG2VS9gcjeCjf9shoKsDDUgMXfWqDwkv27nX9e1Am73dbWHdR3a.png)

#### Didn't find the answer given the technical way. 
So I just... waited. 

A couple hours later another 40% upvote was cast in my name.  Ah, Threespeak is voting for me for some reason or another. Rishi told me that hive.vote goes through Threespeak but I really can't be arsed at this point.  I'm curious how long this has been going on but I feel like it must be pretty recent or the amount of votes getting signed increased enough for me to notice.  Doesn't really matter one way or the other though.  I revoked my authority and the curation train was severed.  

For a second there I was actually worried that the upvoting would continue and then I'd have to make wild accusations like Hive Keychain was voting with my keys (which would be much... much worse).  Always a good reminder that my posting and active key are just sitting there in a Chrome Extension on a Windows machine.  lol... not the most secure implementation to be sure.  Luckily we got them timelocks and owner keys to contend with.  Hive security is pretty clutch when people really take the time to figure it out.  Considering all the recent Ledger drama it's good to keep an eye out. 

#### Conclusion
Any account with your posting key authority can comment and upvote in your name without any other permissions required.  Always good to remind oneself how it works (even if I've NEVER seen an instance of someone abusing the comment functionality... as all the bots and curation trains are tailored to upvotes).  This is why it's nice that custom JSONs come with an optional posting/active authority requirement.  Imagine if all custom JSONs only had posting authority: all your HE tokens could be transferred by anyone with basic posting authority. 

In any case this was one of those interesting blips on the Hive blockchain.  
Never a dull moment in crypto. 
Keep grinding.