There is no encryption in Bitcoin. It uses asymmetric cryptography for signatures, and it uses hashing. Encryption might be used by wallets, but that is not part of the consensus layer and therefore not part of Bitcoin.
No. Encryption is just one type of cryptography, used to make data unreadable without the secret key. Signatures are something else, used to prove that the holder of a secret signed the public data. Zero knowledge proofs are another, used to prove you know a secret without revealing it. It's a fascinating subject.
I'm not saying all cryptography is encryption, I'm not even really talking about signatures, I'm specifically talking about asymmetric cryptography. I don't see any example of "asymmetric cryptography" which is not just a usage of public-private key encryption.
If you're talking specifically about RSA, then it's true that encryption and signatures both use the same type of asymmetric math, but in opposite directions. But most asymmetric cryptography doesn't have this property.
But the signature is an encrypted hash value, which is decrypted when verifying the signature. Maybe you could say signature verification as a concept is not encryption, but certainly Bitcoin's implementation uses encryption, and I don't think there's any definition of 'asymmetric cryptography' that is not also some form of encryption.
I'm not an expert on BTC, but I'd guess that if you can derive the private key of a signature from its public key (which is what the paper is describing), you can use that to place transactions from said wallet on the blockchain (ie. spend that wallet's money), right? Genuinely curious if I understand this correctly, there's a lot I don't know about how bitcoin's protocol works.
No I don't think the paper is talking about breaking hashing here, they're talking about breaking the 256-bit elliptic curve encryption of keys in the Bitcoin network.
Hashing isn't really the same thing... you're not "encrypting" data when you hash it, you're putting it through a one-way function that produces a consistent fixed-size output, such that if you provide the same input again, you get the same output.
Hashes aren't "reversible" in any reasonable sense of the word. Sure, you can keep guessing inputs until you produce one that has the same hash, but it's misleading to say that you're "decrypting" it. I'd instead say you're finding collisions.
To me, "decryption" implies that there's some secret you have which can take the hash and turn it back into its original input in constant or linear time. Using the word "decryption" to describe "finding a hash collision" isn't really correct.