I've been studying the bitcoin book lately [1]. Slowly but surely I'm getting a better understanding of all the pieces involved. I was inspired by an article I found here on HN, [2]. I saw that and decided I wanted to implement as much of the bitcoin protocol as possible without using any libraries.
I still haven't made too much progress. It was easy to generate private keys. Then I had to implement ECC. That took me quite a while to nail. But now I've got public keys on the curve mentioned in this article. Now I'm still in the process of mapping this into the public key hash. I got the sha256 hash working pretty quickly using just the psuedocode on wikipedia. But public key hashes are ripemd160(sha256(publicKey)), and I'm still having troubles with the ripemd160 hash.
After that, I'll base58 encode the hash. Then there's a couple of BIPs I wanna implement, the HD wallets and the 13 word mnemonics ones in particular.
Basically, I think this stuff's important for me to know. All these math abstractions are chained together in a certain way that gives us cryptocurrency protocols, internet monies. In the process, I get a strong foundation in cryptography as well as domain knowledge of cryptocurrencies.
Here's a cute way to generate Bitcoin key pairs using only bash and some fairly standard command line utilities (disclaimer: I wouldn't use it to generate production keys).
"I went on vanity-eth.tk and generated a public and a private key"
That people are actually still willing to do this in 2019 with BTC above 10K and ETH above 300 always surprises me, even if it's for a toy example like this article (as it might incite other less tech-savy people to believe it's ok to do something like that).
I guess OP thinks that vanity-eth.tk is a website with server side code.
If that were the case, the security of the private key would be compromised. But the website is client side only.
Or maybe the complaint is that non tech savvy users
might be getting confused and might be too trustful to other sites that do private key handling server side.
Or, y’know, they might serve everyone else client-side code, but serve one particular user server-side code. (Sort of like the hypothetical NSA Windows Update attack.)
This is why most crypto web-apps have a browser-extension form; you can check in your browser extension list to verify which version of the extension you have, and so know that it’s safe if someone you trust has already audited that version.
That doesn't help you much if you're starting out. You have to trust somebody and someone has to point you to something.
If it's a specific browser extension or a web page that you can run after you've cut the internet doesn't really make a difference. Note that vanity-eth.tk points out that you don't have to trust them and how to ensure that the private key stays private. But that needs some knowledge and that's certainly not for everybody.
>I guess OP thinks that vanity-eth.tk is a website with server side code.
I am fairly certain that very few people go and read the entire supposedly client-side JS code served by that site. It takes a very tiny bit of obfuscated JS to send 256 bit somewhere else.
[edit]: and when you generate a key pair that's going to potentially store multi kUSD in value, trusting anything that happens in a browser is - call me old fashioned - suicidal.
Aside from the obvious fact that the set everyday numbers (both rationals and reals) are fields, most crypto heavily relies on finite fields.
[edit] and come to think of it, I might be mistaken I don't think the notion of vector space and therefore the whole of linear algebra would work without a field for the underlying coordinates.
I thought it might just be volatility. It makes sense that when people are interested in something they will both trade and talk about it, and both actions are probably in feedback cycles with interest. I would expect the same to be true of, say, Boeing stock. I would expect shills to play some role, but perhaps a relatively minor one.
Building a decentralized supercomputer onchain
Let‘s instad have a thought experiment: We want to create a decentralized supercomputer, both on Ethereum and on BSV. Let‘s say we have a 60mb program to calculate 1gb of climate data.
Ethereum
On Ethereum it is impossible to put 1gb of climate data onchain. This is the capacity of about one week. It might be possible to push 60mb of program data onchain, but this requires a heavy refacturing of the scripts, will cost a lot of Gas and might cause several security risks.
If you try to do the operations onchain, you will fastly reach the limits. Executing the supercomputer operations will cost heavy amounts of Gas, while you only get a tiny power capacity, as the operation is done by every single node. It will not work very well.
Instead of creating the supercomputer onchain, you can create a marketplace for supercomputing onchain. This is approximately what Golem does. You create a smart contract, which tries to wrap up a complex logic of business scenarios to enable people to trustlessly trade supercomputer power on a decentralized marketplace. While such a contract will still cost a lot of Gas – it is relatively complicated for Ethereum – you still need a centralized third party to share data and tasks and to allow the involved actors to access the system.
Bitcoin SV
Now, how can it be done on BSV? First, you can put the files to process onchain – 1gb is not that much of data for BSV, Ryan X. Charles already uploaded 1.4gb of pictures. So you can do with the 60mb calculating instructions. Not as a smart contract for other nodes, but just as a string. All data you use is stringed: Nodes do not need to execute it, but they can.
Then you create an onchain website, giving users access to some kind of marketplace. This allows to access and produce onchain data: Identities or pseudonym of bidders, askers and maybe moderators; every step of a trade cycle – offers, acceptance, delivery, payment, review. It is not a shared computer, but a shared filesystem.
That‘s it, basically. You can share vast amounts of data and scripts, create the data items needed to run a supercomputing marketplace and process deliveries and payments without the need of a centralized third party website. Multisig transactions protected by a notary or moderator, can be used to secure the payments.
Sure, the supercomputing is something for the future. BSV just started its metanet enterprise. It‘s not ready. For example, processing multisigs on onchain sites is currently hardly doable in a userfriendly way.
But in general – it is possible. With this method you can basically build everything. While Ethereum struggles with making expensive zero knowledge proofs (zkSnark) compatible to onchain computing, people in BSV are already working on toolsets like onchain SSH.
A new paradigm
I still haven't made too much progress. It was easy to generate private keys. Then I had to implement ECC. That took me quite a while to nail. But now I've got public keys on the curve mentioned in this article. Now I'm still in the process of mapping this into the public key hash. I got the sha256 hash working pretty quickly using just the psuedocode on wikipedia. But public key hashes are ripemd160(sha256(publicKey)), and I'm still having troubles with the ripemd160 hash.
After that, I'll base58 encode the hash. Then there's a couple of BIPs I wanna implement, the HD wallets and the 13 word mnemonics ones in particular.
Basically, I think this stuff's important for me to know. All these math abstractions are chained together in a certain way that gives us cryptocurrency protocols, internet monies. In the process, I get a strong foundation in cryptography as well as domain knowledge of cryptocurrencies.
[1] https://github.com/bitcoinbook/bitcoinbook
[2] http://www.righto.com/2014/09/mining-bitcoin-with-pencil-and...