More Information Coming

What you see written above should only be taken as an extremely brief synopsis of the full metamorphic evolution that this brand has underwent over the past few weeks and months.

Make sure to stay tuned if your interest has been piqued and you're looking to dig into the gritty details alongside us.

For now, let's start off by clearly establishing:

A) The new, mostly-permanent structure & activity of this channel going forward (www.tg-me.com/LibrehashANN)

B) What you should/can expect in the very near future from us

C) Instructions on how to ensure you are up-to-date on everything that we are doing as an organization.

Background Behind 'LibrehashANN' Telegram Channel Modifications

This channel's prior purpose (before the complete re-brand and affiliation with 'Librehash') was to serve as a supplement to the "main channel".

For reference, the 'main channel' is a term that is used in reference to the brand's "central" Telegram channel (i.e., the channel where the 'buck stops' to immediately settle any 'chicken vs. egg' questions / speculations users may have now or in the future).

The current URL for the main channel = www.tg-me.com/Librehash ; nothing beyond that.

Apt observers that have been following the brand have probably already realized that all other channels (i.e., ones that, by default, stem from the 'main channel') will almost always have a name that is some sort of variant of the core brand identity (Librehash).

This naming convention was done to offer at least some mitigation to any potential confusion that may arise as users become privy to the countless brand facets that will be introduced from this point going forward (there are well over 50+ platforms that users will become aware of very soon ; and these platforms range greatly from completely 'free' [we'll dig into what we mean with that in the near future as well] to outright membership benefits).

LibrehashANN Channel's New Responsibilities & Role (Concise Synopsis)

As mentioned before, the 'main Telegram channel' for the 'Librehash' platform not only served as the flagship - it also essentially functioned in as an 'ANN channel'.

———

Quick Recap (What Does 'ANN' Mean?) = 'ANN' is an online abbreviation for "Announcement" ; no different than 'lol' / 'g2g' etc.

———-

From this point going forward, the main Telegram channel (www.tg-me.com/Librehash) will serve as a reflection and reference point for new curated content & research by the Librehash brand.

Anything that falls outside of that realm (i.e., membership information / brand direction & roadmaps / new app integrations / Git Issue address / Modifications to the Overall Platform), will no longer be posted in the main channel.

Instead, any and all information related to noteworthy updates that detail a substantive addition, subtraction or modification of the brand's resources, identity and/or philosophy will be posted and addressed in this channel first.

Questions/Concerns

For the time being (as brief as 'brief' can be), if you have any questions/issues/queries/general curiosity about what's going on, go ahead and join our Telegram chat channel, which is (at the time of writing) = www.tg-me.com/librehashdiscussion

Closing Statements

Expect to be inundated with countless additional free resources, breakdowns, links, guides, references, tools, etc.

There's "no catch" ; the same way Satoshi Nakamoto didn't have a 'catch' when he first proposed the idea of Bitcoin to a few other interested cypherpunks subscribed to the same 'Metzdowd' e-mail list as himself.

Thank you in advance for your support. 2020 will be an amazing year!

New Release

Pixelfed Instance to accompany the PeerTube release.

An example post is provided below (which also happens to provide a sneak peek at two other projects that are in the woodwrks):

https://photos.libreha.sh/p/librehashadmin/128524274301538304

Code Audit Review Tool

As mentioned before, our blockchain analysis capabilities have expanded greatly over the past few weeks.

One way this has occurred has been through the integration of a valuable automated code analysis platform that quickly sifts through code to check:

A) Flaws in code calls / dependencies

B) Hierarchal issues

C) Potential vulnerabilities in code

etc.

See below:

https://videos.libreha.sh/videos/watch/8fc06fe6-4860-4647-b226-73f8d3a09e72

Another Useful Deployment = Sourcegraph (self-hosted)

Sourcegraph is an open-source, self-hosted tool that allows us to quickly dig into large code repositories that we've forked for further analysis.

In this example, we probed through Insolar as well to get a better look 'under the hood' at this project.

See below:

https://videos.libreha.sh/videos/watch/abc2025b-4092-4cde-9876-51b1524df24c

Immediate access to all membership benefits listed in this chat today for $100 and today alone.

Message @librehashcrypto ; again, today and today only.

Patreon is going up as well as our payment site tomorrow and then it’s $150.

No negotiation.

That’s immediate access to things like proxy > VPN ran through TLS. A quant algorithmic bot that hasn’t missed this year. End to end encrypted email (documented, thoroughly), a newly designed project that allows for secure generation of private keys via API on a remote server to avoid insecure production due to viruses / malware etc (much more on that soon).

We build.

If you don’t take advantage of this deal, that’s your loss in the worst way.

That Quant bot? Made by a former data scientist at Google. Verifiably. As in, we worked together on this and they’re comfortable putting their name out behind this.

These other people make grandiose claims and try to hustle you into various offerings. We don’t.

The markets are going crazy - this is just consolidation. Don’t hop on the bandwagon when Bitcoin is crossing $15,000 later this year and get angry when we tell you $200 flat out.

This stuff we listed cost a lot of money and we went through hell on earth to make it happen.

GPG Keys Rotated

Check the 'description' for this channel as well as @librehash for the new public key fingerprint.

Thank you.

(We will be attempting to rotate every 30 days ; soon this will be integrated with movements on the blockchain as well as a form of Bitcoin-backed 2FA for additional verification).

*Quick Note for Readers*:

We have shifted the domain of the public-facing blog from librehash.com to libre.fail

In the near future, we will publish more links that provide a better 'map' of where everything is at.

Unfortunately, the last few articles had to be taken down because we were serving the images from our own CDN. Thus, when we migrated our previous servers, the link to said images embedded in the articles broke (as they weren't hosted at the same domain anymore).

During our migration, this was honestly something that we forgot to even account for because its something that you don't have to go out of your way to setup. If you copy & paste an image that's hosted on our site to another site - it will be served from our CDN by default (because that's where the image is).

For certain pieces like the Bitcoin Cash Miner Fee debate (among others), we will simply either re-write or re-populate those articles in due time because those pieces possess a lot of good information that people should read.

Stay tuned.

(Announcement) New Bitcoin Innovation: 2FA-enabled (TOTP Transactions)

Over the past few days, we set about figuring a way to institute 2FA on the blockchain.

This idea does not involve a token, requires no funding / fundraising and should not mandate a change in the versioning of the protocol or transactions at all.

How We Were Able to Sketch Out This Innovation

To be frank - it took a pen and paper, several tabs open to various portions of the Bitcoin documentation, a Bitcoin IDE, and some trial and error.

Specifically, we used P2SH addresses because of the flexibility that they have (and because the second-factor will require another signature).

Challenges

Bitcoin is stateless and TOTP is anything but. TOTP (think - Google Authenticator) relies on a ticking nonce that increases by intervals from the time that the 'secret' (QR Code) is entered into whatever application is being used.

How that secret is hashed is meaningful for the server side. The root formula for deriving the 6-digit code, however, is fairly straightforward.

The challenge with Bitcoin though is in creating a reflexive (adaptable) transaction without changing its hash at all.

We can't predict the future and there is no telling when someone will decide to spend their unspent outputs. In addition, with a P2SH script, the sender establishes the conditions that must be fulfilled via a 'redeem script'. That script, in addition to the transaction hash, contains op_codes that perform fixed operations on the input given by anyone attempting to spend said transaction.

If those operations do not resolve to a value that the stack processes as 'true', then the transaction (in 99% of cases) will be considered invalid and thus, null (not spent ; i.e., the funds don't move).

Normally, this is a background process when users are sending funds because the condition is almost always a provided signature & ECDSA public key pair that, when hashed, provides the requisite output (proving that attempted 'spender' can spend said funds).

New Bitcoin Innovation: 2FA-enabled (TOTP Transactions) [part 2]

*Brief Breakdown*

In order to implement this solution properly, we needed to start with P2SH transactions.

This transaction also needs to be specially crafted.

Some of the rarely used op codes that we created for our redeem script include:

-CHECKLOCKTIMEVERIFY
-OP_SUB1
-OP_HASH160
-(if, then conditions)

Among others. The first two (checklocktimeverify + op_sub1) are ran on the submitted expiry time value (which is measured against the block height in this case, not the UNIX time).

If the expiry time is at least at the height of the chain at the time that it is submitted, then the expiry time is valid.

However, if this 2FA TOTP authentication is to work, then we need to ensure that an arbitrary time is not being selected either.

That's where the 'OP_IF', 'OP_ELSE' condition statements come in.

By lining up these conditions on the stack to generate a condition that declares that our submitted block height value must pass the CHECKLOCKTIMEVERY (with a 'true'), yet render a 'false' when its value is subtracted by '1' (with the 'OP_SUB1' operation), we can essentially validate that whatever number was submitted must be accurate to the block height at the time that the operations were performed.

New Bitcoin Innovation: 2FA-enabled (TOTP Transactions) [part 3]

Where it Gets Quirky

Using literal UNIX time would be the best case scenario - as this is what the TOTP uses (generally a 'nonce' factor for your TOTP secret code increases by '1' every time a 30 second period transpires).

However, since transactions are stateless as we mentioned before, there is no 'server' or central time tracker that has accounted for this 2FA setup that we have.

No matter though - there's a work around to this.

After Validating the Block Height

At this point in our transaction operations, we should have removed the op conditions + CHECKLOCKTIMEVERIFY from the stack, duplicated the submitted block time (after the conditions are met successfully), then remove the top submitted block time from our step.

At this point, we should be left with an input.

What Do We Do With the Block Height Value? And How to Handle the Input

In order to really make this work, we made this a multi-signature address (m-of-n). However, there will be multiple signatures involved and only two are needed.

One signature is obviously the signature (and accompanying public key) associated with the wallet.

However, another one is the 'input' (which will be our 2FA TOTP secret), which will hash out to one of the provided signatures.

Since cryptography is strong (this is what makes a "normal" transaction secure), we don't weaken our security by affixing pre-generated signatures to the transaction to select from (guessing these should be no easier than guessing someone's private / public key pairing).

From this point, we're going to run the 'op_hash160' operation on our input secret (which will be 32 bytes in length) [operation hashes the input twice with SHA256, then peforms a ripemd160 hash operation on the result of those two sha256 hashes).


Lucky Break

According to the IETF, the recommended length of the 2FA TOTP secret = 160-bits (link = https://tools.ietf.org/html/rfc6238) - thus that result can also be the 'secret' for our 2FA authenticated code (more on this later before you object).

New Bitcoin Innovation: 2FA-enabled (TOTP Transactions) [part 4]

On the Backend

Blake2bs is hashed from a true secret (to give us our variable input). Hashed with RIPEMD160 and placed in as our secret.

From there, we generate our first 6-digit code.

It is that code that is then inputted back into our Blake2bs function (as the IV key) to generate our set of 20 signatures.

This is a bit complex to explain in a Telegram channel, but we were able to work it out to where this will validate on a blockchain, must be required in order to fulfill the condition to spend the transaction, is pegged to time in a pretty direct manner (by polling the block height in a fairly concrete manner), is attached to the ECDSA-generated priv+pubkey pair so that we don't impose a vendor restriction (in other words, you don't need a 'special wallet' or software that leverages capabilities that other general wallet software does not have).

Announcement #2: Renewal of 'Py-Bitcoin'
—-

This idea is (somewhat) attached to our already existing membership. However, those that aren't members will benefit as well because we'll have be publishing the renewed 'PyBitcoin' script out for the general public (under copyleft because Bitcoin & Python3.8 are open source - all we're doing is providing formulas, there's nothing we should be paid for as it pertains to that).

Updating the 'PyBitcoin Code Shouldn't Be Difficult

At least when it comes to the basic functions & operations of Bitcoin (i.e., key pair generation, RPC commands like polling the blockchain for UTXOs, crafting a transaction, etc.).

Truthfully, there are probably many people in this chat that know Python that could do the same within a few solid hours, max.

For Members

After the code is renewed, we'll be integrating it into our *JupyterNotebook*.

These notebooks possess the ability generate snippets of Python code, markdown, etc.

"But I Don't Know Python!"

We're not expecting you to (and would be pleasantly surprised if you did).

The benefit of JupyterNotebook is that its designed to share code (Python in our case) to others and all they need to do is just hit the 'Run' button.

Specifically, we felt it would be useful to have a few Bitcoin-related Python snippets pre-saved as notebook items for users that would like to play around w those functions.

However, the current code for Bitcoin Py is outdated at the time of writing.

In addition, we're going to reach back out to coinmetrics.io (we did a bit of research a while back for them) to see if we can ink out a renewed agreement to obtain their API as data sources for us to query against for :

A) Prices of various assets

B) On-chain data [they are the industry-leader when it comes to polling blockchain data and statistics; which can be really useful in assessing a lot of underlying factors that move things on the 'surface']

C) Various indices

And more...

Announcements

1. Began a public “Phabricator” instance for the sake of maintaining a legitimate (suitably complex) means of documenting our progress as an organization

2. Revamped a # of projects that we were working on (with our first major improvements being facilitated through the “PrivateBin” fork that we are currently developing)

3. Made significant headway with a few of our blockchain initiatives - such as a publicly available “Bitcoin full node” that can be used to query the chain & even create a Bitcoin wallet that receives funds + is tracked independently (wallet creation is generated via secure, transparent + auditable client side encryption that deploys cryptography *correctly* within a W3C-designated “secure context” in order to ensure that we’ve done everything in our power to provide a meaningfully “safe” environment for Bitcoin users to move funds to and fro freely).

4. Reinstated our public newsletter (first edition of the new issue releases today)

5. Incorporated new analysis methods into our publicly disseminated reports on blockchain & other related entities

6. Rotated our GPG keys

7. Hardened our mail servers much further than where they were before. Part of that gardening process has involved finding a reasonably simple means of employing GPG encryption (of the highest, RFC-compliant strength available), whilst simultaneously providing a reasonably feasible & super simple means of generating such key pairs + storing them w/o being forced to be concerned about the learning curve of integrating an *entirely new concept* & new habits

Publish0x Stole Our Ideas: Their Site Looks Great

Had a lengthy discussion with the 'owner' of the project several months ago (probably dating back to 2018, now that I think about it).

At that time, they wanted me to start writing on the platform in order to help them gain adoption sooner.

I told them that I was intrigued by the offer - but only if they made a few select integrations on their site.

Essentially all of the ideas that I contributed to them is what they have in motion right now.

Check them out! https://www.publish0x.com

This is a great idea for them (that I came up with).

Unfortunately, even if you give people ideas - they're still not going to be able to match the drive & passion that you would have had for it.

There are also a ton of much better things to be doing. And that's why we;'re doing them.

From the initial conversation that we had with Igor toward the beginning of 2019 (February)