This was an unexpected find, admittedly - but while perusing Verizon's website (don't ask why) , a faint message was spotted on the right side of the screen .
Sparking curiosity, the 'learn more' button was pressed to gather more information about Verizon's use of blockchain technology (after all, that's what its there for, right?).
Clicking on the link brings us here
Verizon's Explanation For the Use of Blockchain Technology
At the top of the page, Verizon states:
"By incorporating blockchain technology, full transparency initiative reinforces our commitment to transparency while fundamentally changing the way visitors engage with a newsroom."
Reading further, Verizon explains that they built a blockchain-based tool to exploit its functional advantages to other forms of 'storing data'.
In specific, Verizon claims that their use of blockchain technology has provided a foolproof way to ensure that the editorial integrity of their publications (press releases) are preserved.
This is pretty interesting since Verizon isn't reporting news to the general public. However, it is possible that Verizon finds it important to ensure that current and prospective customers will not read information on their site that contains inaccurate / outdated information about their offers, leading them to make purchases they would not have otherwise.
Verizon Gets a Few Things About Blockchain Wrong Though
For the sake of brevity, we'll go ahead and list the numerous inaccuracies contained within the Verizon will be listed, in order.
Sometime before the publishing of this article, the list of identified inaccuracies will be sent to Verizon for their own benefit. The purpose here isn't to bully Verizon or yield the impression that Verizon, as a company, is in anyway incompetent or ill-equipped to leverage blockchain technology for whatever ends they're looking to meet.
Unfortunately, at this point in time, information on blockchain technology is scarce. Thus, it is likely that a company of Verizon's size that's already at the forefront of an entirely different industry, may not have the time and resources necessary to delve into the minutiae of blockchain.
With that said, below are a few misconceptions detected on Verizon's article about blockchain:
- "A blockchain is a shared ledger or record book": This is close, but blockchain is a distributed ledger. The ledger itself is not shared, per se, but rather reconstructed by nodes on the network by virtue of adhering to one ultimate, objective assessment of determining the 'legitimate' chain (greatest 'Proof of Work').
- "It's the definitive repository where all relevant details about a content record are permanently logged.": This part is completely untrue, unfortunately. Not all relevant details about a 'content record' are required - a reality manifested by the instantiation of 'Segregated Witness'. Although one could nitpick and say that records are never 'permanently logged', that would be arguing semantics to a certain extent. However, an extra caveat should be included here to note that this permanence is only conferred to a record after it has been definitively added to the blockchain (i.e., >1 confirmation).
- "Changes rigorously tracked": No prior records on the blockchain can be changed without changing the blockchain itself (thus, making it an entirely different one). Therefore, no blockchain can be changed since its alteration can only come with the cessation of that blockchain.
- "Everyone on the network has equal access and a standard, unified view, regardless of where they are": This is entirely untrue. In fact, its so untrue, we're going to take some time to prove that this isn't true and then explain why (and then justify why its actually beneficial for blockchain to not have this property)
Addressing the Claim That, 'Everyone on the Network Has a Unified View'
The website,'Blockchair' provides a count of all of the nodes on the Bitcoin network as well as the different node software that's being ran on the Bitcoin blockchain.
In addition, the tool also identifies the different versions of the main wallet client that can be detected on the network.
What's really notable, however, is the fact that there are several participants (nodes) on the network that are at varying block heights.
To assist readers that perhaps are having trouble seeing the disparity between the very top entry in the 'Block Heights' category:
What You're Seeing Above
To be entirely honest, even for the author of this piece, its hard to understand why there would be certain nodes that are >1 block behind the majority of the network.
Since the vast majority of the nodes (~7900) arrived at the same conclusion in terms of block height, its hard to imagine that the 'missing' blocks had not been propagated to those nodes
Beyond the fact that there are different versions of nodes (on the same network) that seem have different records of the "real" blockchain (again, this is enigmatic and something that should actually be looked into), nodes within a blockchain network do not have a unified view of the network because blockchain is not designed to meet this end.
The term 'decentralized' in this context refers to the network structure of blockchain.
In fact, the actual title of the Bitcoin whitepaper is, 'Bitcoin: A Peer-to-Peer Electronic Cash System'.
This is no different than Verizon's network, in a way (if we're referring to the distribution of customers connected to the network, rather than the uniqueness of the provider, which is obviously just '1' - Verizon here):
For Bitcoin and much of blockchain, nodes learn of new information on the network by way of the "gossip protocol". As its name suggests, this involves nodes simply 'sharing' new information to other peers on the network.
Below is a visual of how the gossip protocol works on a network level:
As we can see in the picture above, the first layer of nodes (just one), sends data to three different nodes on the network.
From there, those three nodes then send data to three more nodes. Thus, the rate of propagation is usually exponential on a distributed network like Bitcoin - which provides the relatively safe guarantee that a block that has been propagated by a miner (i.e., sent to the network for confirmation), will be affirmed by the network without unreasonable latency.
Confirming Block Propagation Speeds
Not too long ago, Toomin - one of the developers for Bitcoin Cash - published the propagation times they received after running numerous tests on the network to assess how long it would take, on average, for a block to be propagated.
Below is a figure that contains the data shared by the developer (Toomin):
How This Ties into Bitcoin / Blockchain's Uniqueness
What makes blockchain unique from any other protocol that implements this strategy (like Bittorrent or Tor, for instance), is that the blockchain is trustless, which means that, although nodes can receive information from anyone (since the blockchain is permissionless).
However, the source of the information makes no material difference since nodes evaluate it by verifying the transactions independently. Thus, it is actually impossible for the network to have a "unified view" whilst retaining the properties of blockchain.
Verizon's Use of Blockchain is Inefficient
This isn't the fault of Verizon, per se, but it is nonetheless a criticism that must be leveled of the multi-national telecommunications giant.
Specifically, on their site, they state:
"Every time an official news release is updated, all text-based changes are rigorously tracked and become a permanent part of the shared ledger."
If readers are wondering what's meant by 'text pictures', it is assumed that Verizon is referring to the animated gifs on their site here:
While this seems like an intuitively good idea, it is not - at least not right now with the current state of blockchain technology.
Questioning the Use of Pictures
Before digging into the merits of placing information directly on the blockchain, its worth exploring the medium they propose to store the content in.
In this case, we'll assume they're referring to an image excerpt no greater than the ones shown in the .gif above.
Obtaining a Baseline Estimate For the Size of Each Photo
While we don't have the samples Verizon plans on using (or any greater information for how they plan on extracting these image-based samples of their articles), there's no reason to suggest that one would receive wholly different results if they attempted to 'recreate' a similar photo
Below is the author's modest attempt (which contains information from this article):
The photo was saved as a '.png', which makes it inherently larger than .jpeg or .jpg files. However, this is not an issue if Verizon is okay with paying exponentially more (in fees) than they otherwise would have had to.
Below are the 'file properties' for the image saved from above :
In the photo above, we can see that the image was approximately 62.9 kB, which amounts to roughly 62900 bytes.
Generally, Bitcoin's fee is charged at a rate right around 100 sats/byte, which means that this hypothetical will assess the costs that would usually be incurred for anyone looking to have their transaction confirmed within a reasonable timeframe.
With all of that being said, the total fee payment for inclusion in the first couple of blocks would likely be around 6.29 million sats.
At a price of roughly $58k / bitcoin, the resulting fee payment would be $3,703... per transaction:
This is obviously wholly impractical for Verizon on any level.
However, there is an alternative here that would be even more efficient than Verizon's currently proposed method of doing this using a text-based method first.
Bellard's Text Compression Tool
For those that do not know, there exists a programmer and developer by the name of Fabrice Bellard that has long been known has as one of the more brilliant minds in the computing world today.
At the time of writing, Fabrice Bellard has the current world record for text compression.
Below is a screenshot from a tool that he has hosted online (comes accompanied with a free binary as well as extensive documentation breaking down the operation & logic of the tool):
In the example above, we were able to compress 292 characters down to 26 characters. This is an approximate 92% reduction in the character size.
Translating This Example to an Actual Verizon Article
Let's use a recent article Verizon published on their website, titled, 'Social Media Live Streaming'.
The link to that article can be found here: https://www.verizon.com/articles/social-media-livestreaming/
Extracting the words (explicitly) from the article yielded a total count of 1279 words or 7411 characters.
Using Fabrice's tool, it would not be unreasonable to expect that we could reduce the 7411 characters down to 592 characters (same ratio rate as our example above).
ASCII characters typically represent 2 bytes (like hexadecimal) these days. So we could expect that the condensed version of the article may hold 1184 bytes total.
At 100 sats/byte, that would amount to 118400 sats total that must be paid as a fee. This would amount to $69 total for the transaction, but now the creator can rest easy knowing that the potentially prohibitive nature of the experiment is due solely to the operators of blockchain technology rather than the fault of any one individual at Verizon.
Recommendations For Verizon
There are a number of solutions that Verizon should consider to either optimize their current setup or fix certain gaps in implementation.
Each recommendation will be made in succession, below.
Recommendation One: Use the Litecoin Blockchain
There are plenty of biased acolytes that will attempt to convince the space otherwise, but the plain truth is that there is no discernible advantages to using Bitcoin over Litecoin.
Both projects are built from the same code base (with the latter being a fork of the former back in 2011)
Litecoin uses Scrypt and not SHA256, so the age-old argument that Bitcoin is somehow inherently more "secure" than Litecoin due to the fact that there are more hashes on the Bitcoin network than there are for Litecoin (this is an apples to oranges comparison). When considering the fact that Litecoin uses Scrypt instead of SHA256, it should be argued that Litecoin is more secure than Bitcoin because Scrypt is a KDF, not just a hash function - so it comes with tweakable parameters that can easily be tweaked to increase the difficulty by orders of magnitude on a whim, if necessary.
Litecoin's fees are fixed (unlike that of Bitcoin). This is really great when looking to estimate the total cost.
Litecoin only has a 2.5 minute block time and its only other project competitor for hashrate is dogecoin, which operates off of 1 minute block times.
Recomendation Two: Hash the Compressed Articles
So this is a multi-step process, but its a really easy one.
Essentially, after obtaining the compressed version of the article (~90% reduction in byte size), the algorithm should then be ran through Blake3 (hash function) in order to truncate the output to 64 bytes [due to the interleaving process that Blake3 uses, the hash serves as both a hash tree & an XOF].
Let's go start by looking for a Verizon article here - https://www.verizon.com/articles/tips-to-maximize-at-home-entertainment/
Put the browser in 'reader mode' so that we can jiust quickly grab all of the raw text off of the page
From there, we throw it into a separate document (.txt); or if we're in a script we send this to a named pipe (or something similar to that).
We'll check the stats on the article we selected:
639 words (just for someone edification
3935 characters (total)
We feed this information into a regular .txt file
From here, we're gong to go ahead and compress this text using the Bellard tool that we mentioned prior. That should get us a nice compact size for the output.
Wow, only 471 bytes! Best part is that we're still able to truncate the size of the file even further with the shake256 hash function (while enjoying a really high level of security too).
The file that's created by the compression tool is a binary, but that's no issue. Using openssl, we can still iterate over it with shake256 (by calling a 'cat' command on the file itself, piping it into shake256, then dumping the output into another text file) to give us the result
Gave the file one final count (character-wise); that's bytes now that we've truncated the Verizon article down to 64 characters (ASCII)
From Here, We Add a CRC32 Cyclic Redundancy Check
Run blake3 over the .bin created after compressing it with Bellad's algorithms
echo "c5c3928a61fc37b1384f2fe502fbe50e53ababf70d09529cd12eefed2dbe86c5" | b3sum >> b3sumverizon.txt
Then I took the first 24 characters. of the b3sumverizon.txt
Then I hashed by shake256 (gives me 64-byte output)
Took the checksum of that shake256 output
Appended it to the end of (#3) ; for 32 -bytes (so checksum added for error checking if necessary; used crc32 to make this happen
Conclusion: Relevance to Verizon
If they're looking to push a solution on to the blockchain that's going to meet this goal of providing transparency, then it should entail being this thorough.
The final string should only be 32 characters
That's a record that can easily be stamped on the Litecoin blockchain using the "op_push 32" op_code (which will push this first 32 bytes that we have here to be stamped, followed with an op_return output only w no address specified.
Bonus: Crafting a P2SH Script Appropriate For This Scheme
We want a way of being able to update the records in a manner that leverages the consensus features of blockchain.
Otherwise, we're missing the point entirely. Thus, the best way to ensure that this does happen is to craft the op_return in such a way to where the funds are still spendable (so maybe there will be layered conditionals included with the 32-bit string that's included within the op_return or some other facet of the data; that's dark -- just ignore this scheme.
Another Idea We Don't Want to Let Slip
Using a hash function like 'yescrypt' or 'Catena', whom both have "client-independent update" ; this essentially allows one to update a stored hash for a password (among other things), without having to know the original value that was hashed.