Topic: What would happen to bitcoin if all bitcoin-related stuff on GitHub got banned? - page 2. (Read 1149 times)

What I like about your idea is that a Git commit history is one of the few data structures that slightly resemble - and because of that might actually make sense to implement as - a blockchain.

I see 2 issues:
[1] Embedding developer keys in the 'genesis commit' means they can't revoke them, add new ones or add new developers to the project down the road.
[2] You need a consensus mechanism, and as so often discussed on the forum, nothing works as well as PoW (if at all). So either it's built on top of a PoW cryptocurrency like Bitcoin, or you need to incentivize people to 'mine commits' using real-world energy resources.

That would be interesting if the full nodes (or even SPV clients) could also keep a copy of the repository and be able to share it with other clients. The repository sizes aren't that high to need a very high incentive. For example repository sizes:
bitcoin core = 218 MB
Electrum = 50 MB
Gocoin = 17 MB

In the scheme, authenticity of a repository is hard-coded to its genesis and is not forgeable ever, though the genesis itself is a different story:

Once a repository is introduced to the blockchain for the first time (the genesis) its metadata provides a rich set of information including a title and a public key that are used to generate a unique ID, unlike other parts of the repository, downloading and maintaining the metadata is mandatory for all nodes. The authorization scheme built into the metadata is used subsequently for integrity assessment of incoming commit requests (CRs).

Repositories change version as a result of authorized commits, and they fork by unauthorized commits. The head of a versioned repository is identified by its original ID and its latest (legitimate) commit, this rule is also applicable to a forked repository, noting that its ID is changed and generated using the commit that caused the fork.

Maintaining forks, (and repositories generally), comes with very little costs because actual downloads are not part of the scheme, it is the node operator/owner's job to decide and execute downloads accordingly, it is done using Tor as of what is available now.

That said, I'm working on a project for implementing an overlay network above bitcoin P2P for a more general purpose networking, the main challenge here is incentivizing bitcoin full nodes to participate, whether maintaining their own software repository is enough incentive or not is subject to further assessments.
Note that it is inappropriate if not impossible to maintain a single repository with my scheme, once you decide to support forks, you have opened doors to other repositories to join, almost infinitely. Thanks to no-downloads policy, it is not a DoS backdoor.

The problem is that most people don't actually know how to use Web of Trust since most of the people they know do not reveal their emails, and those who do, probably do not have PGP key.

This root public key. How can you make sure it isn't altered effectively, since repository is distributed among nodes. For example, what forbids a node change it, and send the entire repository to other nodes?

What I'm saying is: You can't have a Web of Trust without a central point. I can trust you only after I've downloaded your key from a reliable source. This "distributed GitHub" can work, but public keys must not be transmitted that way. 

As a first step, I'd avoid surveillance by running a GitHub-like repository hosting service under Tor.

I agree that the only true option is decentralization but not with the other part specially nowadays that the world is slowly becoming a multipolar one as opposed to being unipolar for decades.

You are forgetting about an essential part of PGP which is called Web of Trust, you don't just trust any key that signs a binary. You have to first spend time finding the correct key that you can trust then import that and verify the signature that it created.

Depending on a keyserver again means depending on a centralized entity, which is what aliashraf is trying to avoid.

Except if you define 'people have a local copy of it' as decentralized, which is how I called Git's current state ('somewhat decentralized' as in: anyone that has a copy of the bitcoin/bitcoin repo can push it to a new remote if GitHub remote server goes down).

Although you are right, I need to reiterate:
This is the trivial approach, relying on external data and human decision-making, in the scheme I proposed we use a more sophisticated approach though:
Once a repository is initialized, it comes with a built-in authentication metadata that includes a root public key which is committed by the fingerprint of the whole repository, hence immune to forgery. It allows Distributed Git nodes to distinguish forked versions from the authentic ones, as the legitimate commits are checked for their authenticity, failing this check is considered a fork.

Everyone in the world who has imported ThomasV's PGP key (assuming his email is verified), can retrieve the key from a keyserver, attempt to verify your binary, and notice that it fails because of wrong signature.

So the keyserver plays a very important role (I just wish GPG shipped with a default keyserver that actually works! )

As I said, we push them behind the scene. Consider how a file system hides the actual low level block I/O, applications read/write files as a continuous stream of bytes but behind the scene it is done with discrete blocks that are not guaranteed to be physically adjacent.


Gitea has nothing to do with decentralization per se. It provides excellent, yet centralized Git self-hosting features as you have the reference repository concept and other related stuff as ordinary Git.

It is both easy and hard. Trivially, one can always use its social knowledge (external data) to prune the invalid/unwanted  forks (@cricktor has already mentioned it above), unfortunately it is not applicable to automated synchronization process I'm suggesting.

For the latter purpose, my scheme imposes a well-defined authorization metadata that PRs which try to change it are considered forks as well as unauthorized PRs. For legitimate authorization update, the metadata is organized hierarchically, it is possible for a repository owner (with unique signature) to grant/revoke  commit access to other contributors, etc.


The original dev key is, analogically speaking, the Genesis, it can't be changed without kinda hard-forking the repository, it changes the identity of the repository and can't be done covertly.

But, the attacker carries both the developers' public keys, the binaries / source code, and finally the signatures. Therefore, they have everything needed to alter the software effectively, without notice. For example, I can change Electrum's source code, replace Thomas' key with mine, replace the Thomas' signature with mine, and give it to you. How can you know I've compromised it?

But the forged attacker's keys don't match the real dev's key signature. If you don't compare that the obtained key is actually the proper key, you miss an important step.

So we don't abandon them. We just stop being dependent on Github.com for their maintenance. Decentralizing git (which isn't already accomplished with Gitea servers?) doesn't break the core idea of distributing and tracking software versions, which includes fetching and pulling requests.

One thing I don't understand is how you do ensure for the integrity of the software. For example, say you want to install Electrum. Normally, you should download the binaries (or the source code) with their respective signatures. These signatures correspond to public keys that are uploaded to some server, preferably to some trustworthy server (e.g., Github.com). On a p2p network, an attacker can replace the devs' keys with theirs.

When it comes to violating human rights, defending the rich, suppressing the poor, preserving the corrupt fiat based monetary system, etc.,  there is only one jurisdiction across the globe, it is the US jurisdiction nowadays. Mirroring doesn't work, decentralization does.

Unfortunately, Git abundantly resists decentralization, unlike what it looks like inthe first glance. The same basic approach that distinguishes Git from traditional "delta" based VCS, makes it hard to be truly distributed as you are dependent on a reference repository, a single point of failure. For an analogy, consider how we keep the ledger synced in bitcoin blockchain: there is no reference ledger, blocks change the ledger incrementally if they pass the consensus test, there is no "reference ledger" or "fetch" operation.

In my design, we abandon "reference repository", "fetch","pull", etc., altogether. To be more specific, we push them behind the scene using an abstraction layer, keeping the legacy Git intact. In this new world, pool requests are relayed by devs to their immediate peers in a p2p network, checking consensus rules (specific to the repository) peers decide to reject or forward the PR, in the latter case they keep it in "reqpool" waiting for commit requests, CR, that refer to (a set of) PRs. Devs who can produce PR, are eligible to issue CS, it is up to nodes to choose between forks or even support multiple forks which have unique identities generated by PRs that have been committed.

It would be just the infrastructure necessary for a truly decentralized Git ecosystem, resistant to any bullying practice and more importantly a fun adventure. I stopped developing it just because it is beyond my personal budget and time to do it in lone ranger fashion, in case anybody got enough support and motivation to follow, I'd be more than happy to share more, a lot more.

Although this is not a full solution but it could significantly reduce the risks of disrupting development and access to code BUT only as long as the different mirrors are hosted in jurisdictions that are separate. For example if both are located in US or any country that follows US (UK, Japan, South Korea,...) then it will only create false sense of security.

I know that GitHub comes with a lot of extra bells and whistles; but fundamentally, it's a Git remote.
If it comes down to protecting against deletion of the https://github.com/bitcoin/bitcoin repo, any simple Git remote will suffice in keeping the whole commit history.

What about just having mirrors on other Git 'hosting services' / Git remotes - self-hosted ones and popular, known ones? In case one remote is shut down, devs can just open a ticket on one of the mirrors, agree on which one becomes the new 'master' remote and the other remotes continue mirroring that?

Git is not decentralized. It just makes it more difficult to "delete" something if it is part of a git-based repo. This is why if there is ever any kind of private key or "secret" committed to a GitHub (or other git-based) repo, the "secret" needs to be invalidated, and no longer be used.

If a repo is removed from GitHub (by the owner of the repo, or by GitHub), if you do not already have a local copy of the repo, it is not possible to obtain a copy, and authoritatively know you have the same code as was on the repo.

It is the technical sub of the bloody original bitcoin forum, we are all supposed to avoid spreading misinformation.

Github is a web application that uses Git, the latter is a Version Control System, CVS. When you work with Github you are offered dozens of features and utilities that are not part of a CVS.

Git is open source and free, while Github is a multibillion $  property of Microsoft that provides a sophisticated user interface for versioning, it is not hosting in the exact sense of the word. Hosts are infrastructure providers, they host your own or third party software for you.

Github doesn't abstract users from Git, because typically the user is a software engineer/programmer, the one who abstracts but doesn't like to be abstracted8), it is a matter of design and requirements.


As much as it is needed, it is hard to replace Github, but not impossible. The alternative is neither bare Git, nor another Github-like centralized service. What we need ( and it is inevitable, imo), is a decentralized network of Git repositories behind a decentralized web application.

There are decent technologies that are available, and as I mentioned above thread I've done some research about it years ago, only missing factors, as usual, money and commitment.

It makes more sense to ban free speech, than code. What is code to be banned? How can you ban, forbid, criminalize something that's free, and can be ran by anyone, at any country, anytime, with little effort? Remove the repository, and be sure that a wave of decentralized Git network will appear. You can't ban restriction-resistant software. You can only prove it's more vital for a free society.

Self hosting is not that easy, the biggest challenge is providing security. You don't want someone modifying the code by gaining access to accounts and merging pull requests, etc. I think this is what @aliashraf means by "github goes beyond that".

Good thing that bitcoin is international not national...