Mystery of the Daisy Chain: Solved

5 Days ago

On Thursday I wrote this post about revoking my permissions from Hive account@threespeak and how annoying it was that I couldn't actually see which account was signing my transactions. The entire ordeal ended up somewhat as a mystery. Wasn't sure why upvotes would be cast by Hive account@threespeak considering that they don't really run a curation service like that, or at least not one that I was aware of.

Turns out that post actually sent alarm bells ringing over at 3speak (wasn't sure they'd notice), so they wanted to get to the bottom of what had actually happened. I was pulled into a private Discord party line and we figured it out pretty fast on Saturday after the CTT broadcast. I was going to write a post on this back then as the issue seemed pretty pressing, but I was asked very nicely not to do that until a solution was in place, which is fair.

A recap of what happened.

• My account was casting 40% upvotes without my permission.
• My posting authority was granted to Hive account@ecency.app and Hive account@threespeak.
• I revoked authority from Hive account@ecency.app
• The upvotes coninuted.
• I revoked my authority from Hive account@threespeak.
• The upvotes stopped.

This was an extremely weird situation because Hive account@threespeak is a very trustworthy entity on Hive and they aren't even running one of these curation trains in the first place. With that in mind I felt like it was very appropriate to tiptoe around the issue and not throw any accusations around because surely something very strange was going on in the background here.

In the comments of that post

You can't daisy chain the authorities.

So Hive account@mahdiyari was in there and he's super knowledgeable about Hive core code and proved to be a quite valuable resource. Apparently we can rip a public key by running the signature of an operation through a function (which was the exact answer I was looking for in that post without even realizing it). Of course Hive account@fulltimegeek and Hive account@proofofbrain ended up downvoting the thread... which was... again weird. Seriously though what is going on here?

So my witness partner Hive account@rishi556 solved this problem almost immediately at first glance. He told me to take a look at http://hive.vote/ and see if I had signed up with that service because Hive account@threespeak was giving Hive account@steamauto posting key authority, and Hive account@steamauto is the account that hive.vote still uses from the old days.

So I headed on over to Hive.vote but it's telling me to "register" or "log-in" using Hivesigner and I immediately decide this is a dead end. I never use Hivesigner for anything (it's been years). Authorities can't be daisy chained and it's been years since I used any kind of automated curation service.

But it like... wasn't a dead end doe.

In fact... Hive account@rishi556 even found the code to back up that we absolutely can daisy-chain authorities.

So Hive account@eddiespino ran some tests to confirm.

So... mystery solved!

Authorities can be chained (like trusting friends of friends).

https://gitlab.syncad.com/hive/hive/-/blob/master/libraries/protocol/include/hive/protocol/sign_state.hpp

So this code that was authored a year ago and committed 9 months ago seems to allow recursive additions to the posting authority based on "depth". With a max depth of 2, it would seem that we are not only trusting friends of friends with our authorities, but also their friends as well.

I'm sure there is a reason for doing this and is convenient in a fair number of scenarios, but I gotta say it just seems like a bad idea. If I give my authority to Hive account@xyz account then I expect Hive account@xyz account to have my authority and no one else. I'm truly a little confused as to how Hive account@blocktrades and other Hive Core devs signed off on this.

I have to say I'd be pretty furious if I gave an alternate account of mine ACTIVE_KEY authority for Hive account@edicted not knowing that if giving ACTIVE_KEY authority on my alt to someone else would give that person full access to all my liquid funds. Isn't that the entire point of permissions? The ability to segregate and carefully pick who you trust and who you don't? A recursive depth 'solution' that can potentially exponentially expand that breadth without users realizing it seems like a disaster waiting to happen. Very much dumpster-fire vibes here. #ThisIsFine.

It looks like I gave posting authority to Hive account@steemauto in 2020.

Maybe even 2019. Only after Hive account@threespeak added them to their trusted list did the curation trail become reconnected. If I'm being honest I'm a bit floored that I was the one to find this "bug". But it's not a bug is it? Working as intended. It's right there purposefully embedded into the core code of the network... for whatever reason. And you know I'm having this vision of the future being told what the reason is, and I don't care. I just want to hear that, "yes, that was a terrible idea," and have it rolled back. Because obviously. I'd be floored if anyone was able to convince me otherwise.

It's also worth noting that in many circumstances our system of posting/active authority granting is quite clunky. Needless to say the most popular form of authority permissions are curation trains (the ability to upvote with an account). However, granting this authority_[posting] also allows comments, custom-JSONs, and downvotes to be signed to the chain on that same account, which is often not something the user wants that entity to do. Authority is very much an honor-system in this regard, and the vast majority of players on Hive do indeed play by the rules because they don't want to nuke their own reputation over trifles.

So the question we have to ask ourselves is if it's really worth it to make the system we have here even more complex in order add these kinds of options to the chain. Very much on that fence on that one as I feel like I don't know enough about how Hive works on the base-level to really forge an opinion on the matter. I lean toward "it's fine the way it is" but if there's little drawback to a particular implementation then why wouldn't we change it? The devil is in the details.

Conclusion

It all makes sense. Mystery solved. Hive account@fulltimegeek's downvote on Hive account@mahdiyari is a particularly nice touch. Imagine being told how to rip the pubkey from a signature only to find out that the pubkey you ripped from a "fraudulent transaction" just so happened to be an account run by the guy that helped you figure it out. Hive has a weird sense of irony.

Posting and Active Key Authority can be chained to other accounts... twice. You've been warned. When you grant an account your posting key you're implicitly also granting it to whoever they give their posting key to, and whoever the next wave gives their posting key to as well. Again, I'm not sure how anyone on this network is cool with that, but here we are.

So don't forget to grab your torches and pitchforks and demand that this recursive expansion of the authority gets rolled back to the intended acceptable position. Hive account@threespeak isn't the only one that grants posting authority to Hive account@steemauto. Hive account@leofinance does as well, and Hive account@khaleelkazi has been informed of this situation personally by yours truly so there aren't going to be any surprises (especially because that particular hole has already been plugged).

But still it doesn't matter that one frontend fixes a small bug. I was looking at potential double-jumps the other day and it looks like Hive account@gerber might have posting-key access to every single account that gives their authority to Hive account@leofinance, and may be able to sign transactions for Hive account@leo.voter as well. Is that a problem?

Is anything bad going to happen? No, Hive account@gerber is cool... but it is not a robust and scalable solution. Eventually someone will exploit these double jumps and it will really be nobody's fault but our own. Luckily a posting key exploit wouldn't be too bad under the current infrastructure, but who knows what we might build on top of this powerful network in future years to come.

Just my two cents on the matter.

This isn't really a big deal right now but it could be a big deal one day.

To be honest maybe the curation bot even saved me money by not allowing my account to go up to 100% voting power. But I feel like the principal of the thing is more important right now, and what might happen if devs continue unknowingly building atop such foundations.

P.S.

Shoutout to everyone who participated in helping me figure this all out.
Hive account@eddiespino
Hive account@mahdiyari
Hive account@starkerz
Hive account@fulltimegeek
Hive account@rishi556

_{Perhaps one day I'll have enough dev experience to rival a single person in this list :D
Cheers.}