OP,
I regret failing to give my feedback soon enough but I have something to share regarding your article.

First and foremost, it is very important to keep in mind that bitcoin is in a transient phase in which it has not fulfilled its eventual mission: changing the world and establishing a new fiat-free ecosystem: bitcoin ecosystem. IOW, this term refers to something that is a work in progress, something that is not realized, yet. The confusion begins right from here, because as long as the bitcoin ecosystem is not realized one may consider every single entity that is somehow 'related' to bitcoin as a part of it, a totally wrong assumption that introduces alien entities which typically deserve to be categorized as parasite.

For instance, exchanges are related to bitcoin, they claim and apply influence heavily on centralized/scam projects like Ethereum which you used as an example (and I'll come to this example later) as well, but the whole phenomenon is just a parasite for a simple and straight reason: In the future real bitcoin ecosystem, there will be no room for a concept such as 'bitcoin price', hence no room for what makes exchanges such a heavyweight player.  

Generally speaking, I think it is an obligation for any commentator, whenever it comes to such issues, to explicitly remind the transient nature of what bitcoin is going through currently and how this transience affects every single aspect of its status because without such a measure we will be lost in a jungle of raw evidence.

I also need to stress that it would be a huge mistake to compare bitcoin with centralized scam driven projects like Ethereum, no matter what their so-called 'market cap' (another alien concept) may be. For Ethereum, other than the ridiculously centralized approach its "owners" have followed for hard forks through the years, its vulnerability to centralization has much deeper roots in Turing Complete smart contracts which allows corporates and deep pocket token publishers to practically decide the future of the forks. The shameful transition to PoW, aka "The Merge" proved how powerful such entities are.

Centralization in cryptocurrency is ways more dangerous than almost any other form of concentration of power, as in this field it is much easier to violate the same contract that granted them this power. A centralized banking system, for instance, is practically bound by regulations and laws that are not easily applicable to an entity behind a so-called "pegged token" such as USDT.

Conclusively, I suggest not to put shady technologies such as Ethereum and other smart contract based blockchains in the same class with bitcoin, as they introduce a very active and dominating source of wild power.
To have a better understanding, just check how brutally and unlawfully this factor undermined the obvious and legal rights of miners to keep maintaining the PoW chain (note, it was VB gang, aka the Foundation, that forked off from the legacy PoW chain) and they've played this role without feeling any accountability about their obvious violation of the same contract that has made them rich. It is literally a breach of contract, because the contract has been deployed on the legacy chain and not the Proof of Sh*t fork. If the corporates have not such an unlimited power, either the shameful transition to PoW would have never been supported, or they would have introduced new tokens on the forked chain, allowing their users to freely migrate there. Instead, what happened was an embarrassing practice of behind the doors lobbying and brutally enforcing tens of thousands of miners out of the business. Ethereum and other smart contract based environments are such a poisonous environment, absolutely not entitled to be compared in any sense with bitcoin.

OP,
Thanks for sharing. Maybe I'm missing something, but other than implementation challenges, I suspect this scheme is vulnerable to miner theft as once it goes to the mempool, miners can take it and replace the output with theirs. It is because the transaction is not signed, hence forgery is not prohibited.

Kudos, you nailedit.  

I've already addressed it above thread:
The authorization scheme is hierarchical resembling a pki infrastructure. As long as the root is not compromised, it is possible to grant/revoke authority to new/old keys, it would be possible for root to delegate its authority, share it, and so fort, all happening on-chain and without being considered as a fork. It is done by conventional commits (metadata is part of the repository after all), though downloading and processing of commits to metadata is mandatory for nodes, to check for potential tempering attempts by devs with lower/incompatible authority.


Yes, it is the biggest issue, the only serious issue to be clear, other aspects of the scheme have been explored and addressed as much as it is possible for a lone ranger but the incentive mechanism? It is complicated.

Firs and foremost, it is important to understand how deeply different is the case with a blockchain that supports the scheme I'm proposing for a truly decentralized Git, with bitcoin that is designed basically for solving double-spending of digital cash. Noticeably what bitcoin solves is a threat posed by the potential owners of the asset, whereas for repository owners it is the contrary, they have full incentive to keep their asset intact.

It would be a good analogy that repositories in my scheme are better understood as evolving NFTs, their ownership can be delegated though it is neither common practice nor subject to ordinary double-spending by re-org attempts.

Finally, and most critically, blocks in this scheme are rather batches of commits, they are signed and don't compete with forks or other repositories.

That all said, there is still the incentive problem remained in gray zone. I've been mulling this for a long time, not a conclusive result, just a few ideas:

1- I think, in this context, participating in an ultimately decentralized repository network, the altruistic factor should not be underestimated.

2- As I've said before, the actual download takes place on demand and is not part of the protocol which is only concerned about versioning and forks, it implies that the costs of participation are considerably low if not negligible.

3- Theoretically once a node supports one repository, as long as it tracks forks, it is open to multiple repositories, still in practice it is possible, though not encouraged, for nodes to “choose” a subset of the whole universal  repository space to track, or even sticking with just the main branch. The drawback would be the potential obsoleting of less famous repositories/forks.

4-We have bitcoin p2p and full nodes as potential participant.

Spamming is another issue that I found as being important, interestingly it looks to be resolved by a game theoretic equilibrium, where spammers are suspected to lose support from nodes because of point (3) where nodes are free to restrict each repository they wish from their list.

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 I can imagine for now.

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 once a repository is initialized it comes with a built-in authentication method and is immune to forgery. It allows Distributed Git nodes to distinguish forked versions from the authentic one, as the legitimate commits are checked for their authenticity, failing this check is considered a fork.

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.
[/quote]

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 that 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.

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.

Yes, you can easily hide public keys that are their exposure is not strictly necessary:
For 1 of n signatures, unlike legacy Bitcoin script, using MAST, you will have n identical leafs such as <pubkey-i> OP_CHECKSIG for each pubkey. for claiming funds our what you are interested in (proving to be relevant), holders of each key should include log₂n  hashes (Merkle path) and only their own publik key, besides the signature as witness.

It was a more general complaint regarding OP's extreme practicism (as I see it) not any specific topic. OP doesn't like questioning BIP322, feeling an obligation to implement it in a rush.

As for sidechains, well I'm a fan as long as they are not deviated from basics, for instance I wouldn't contribute to RSk because they have adopted Turing completeness which is inherently vulnerable, for instance check what is happening with Ethereum: only 2 or 3, besides Vitalik's Foundation, are in charge. Just check what the rock star says:

It is what happens when you have Turing completeness and smart contracts full-blown, corporates decide everything, the decide who is allowed to fork or not to fork. The hilarious point about the situation with Ethereum is the fact that Vitalik and the gang are forking, not the other side!

It is what I believe in bitcoin to be colonized as its side chain, almost the exact same bitcoin, I mean.

@NotATether

Wandering in the woods, is beyond Bitcoiner. We are not hired by anybody, so there is no obligation to follow TODO assignments by BIPs just because they've got some stupid number.
More importantly, your approach compromises the very first line of resistance for Bitcoin: developers' resistance.
I can imagine an adverarial attack like this:

1- The adversary recruits an army of average programmers, sending them to bitcointalk, mailing list, GitHub, so forth.

2- The shills are rewarded based on the credit they grind in communities they are active.

3- They earn credit by minor contributions they make, They enjoy free technical/editorial support for their contributions while following adversary's strategy.

4- It takes some time, but eventually they manage to penetrate and start pushing weird ideas and BIPs, providing the necessary foundation for adversary's main project, which has been lurking in the shadows for the right moment to become public.

I have no trust in anybody to rest assure, following the orders, I do my own research, I have my own vision, IDGAF.

What makes me upset about your style is not its conformance with the above adversarial scenario, I don't go that far. No, you are not hired by a penetrator, but what you are doing is bad for the resistance, it makes us to look weak and irrelevant, leaving bitcoin defenceless. With all the hypes and threats, it is the worst time for us to be distracted by BIPs and TODOs.

Again: Keep the tempo slow and low, it is our tempo.

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.

Is there something known as delegation problem or you have figured it out as well? 

I appreciate your commitment but if you don't go with a bit slower and lower tempo, it becomes noisy, and eventually spammy, in the worst sense, as you wrap it behind innocent even formal technical stuff, as if there is a real problem, and you are doing your job, as a dev or something, to deal with it, which is absolutely misleading in its entirety, kinda covert spam.

Google it, "delegation problem", to find out that there is just one bitcoin related reference to such thing, and it is Faketoshi backed, nothing more than a scam advertisement!

Interestingly, still their work is more elegant than yours! They propose a same chain of delegation by signing stupid messages recursively, where it is supposed to convince users of a (centralized) entity that they have some authorization on behalf of the original signer.

No matter how anybody would solve or implement it, the sole fact that one is concerned about delegation of authority, puts her out of the bitcoin circle, why? Because, there was actually a delegation problem, i.e, delegation of control over funds; Bitcoin solved it unlike cryptography that had failed it for decades. Resurrecting it, for suggesting an imaginary cryptographic solution, is nothing other than breaking with bitcoin under its umbrella.

Oh, poof! BIP322 

It is crazy. How this delegation is going to be verified and approved anyway? By attaching the previous stupid txn(s) of BIP322 to the current stupid txn? Otherwise, the poor verifier from where should obtain the first one??? Remember, they are not going to the blockchain, so where are they? In Faketoshi Wright's private DB?
Pure nonsense, it is so anti-bitcoin that makes me truly sick.

"Scamming people by presenting it as a bitcoin development with a covert right to double-spend", answered  CSW while blinking 

Proving liquidity to whom? How?
We have nodes pared with each other in channels, each being fully aware of the balance/liquidity available, there is no way for any third party to be aware of this status unless it is running a sophisticated multi-node attack to monitor the fee circulation and other statistics. Publc channels voluntarily advertise their status through gossip protocol but it is not provable by anymeans to any body.

It is also a non problem.
Modern coinjoin services do not rely on liquid providers, thanks to Schnorr blind signatures, CoinJoin is now fully trustless and private, Wasabi Wallet for instance makes it possible for users to join their txns without relying on a liquidity provider middleman.
[/quote]

Sure, not to mention being useless.

GitHub is not Git! The latter is just an engine, but GitHub goes far beyond that.

It is very disappointing to see so many posts in this thread, touting Git as an alternative.

Anyway, I just read something about a dev being arrested by Dutch police, accused of writing the smart contract behind Tornado Cash, they are now going after devs, first they sanction a smart contract, for the first time in the history, now some stupid judge approves arresting a 30 years old programmer who coded the contract. 

Reading through your post, it looks that there is no template matching, it is verification without interpreter. The fake BIP322 transation is to be verified! A client without the interpreter! People have hell of a job to support it, don't they? Very few are invited to this party, I suppose.

It is not the way you design software, seriously. It is just contingent dependency, we need the message to be signed explicitly, otherwise we are dependent on this verifier.  Now, check a real template based solution and compare the elegance and beauty:
We have three parties: the signer, the verifier and the consumer.

The signer:
 already knows which address should be used, it signs a message with keys for the address, then it attaches the address the script behind it (if any).

The verifier:
First and foremost, checks whether signature is correct per se. If passed, the message is authenticated, but it continues checking if the signer has included supplementary, bitcoin blockchain related info, if so, it compares the address received directly or extracted from the supplied script (template based), comparing it with the keys used, if passed, the address reference is attached to the message.

The consumer module:
Has a signed message with public keys disclosed and a reference to a bitcoin address for profiling purposes and as a metadata.

Such a signed message is independent of bitcoin-like clients/modules, standing on its foot, it is self-contained.

Note that we have a total different scenario here with what Greg Maxwell has proposed:
Here the signed message is the core data, relation with bitcoin is metadata. Greg has put it upside-down because in the real world, we focus on the message. If this up-side down world has an excuse to exist, who am I to oppose, what I'm insisting on is to do it separately and in its own application domain (being a very narrow domain, I suppose).

Really? 
Just because we have scripts that USE Digital Signature schemes, then we have a Programmable Digital Signature system? Are you kidding or what?
Before rushing to the keyboard, always do your homework: Google it! Programmable Digital Signature System.

Done? As I said, and you quoted, there is no such thing in the world, Right?

For sure, if it holds any water, it would be poisonous, imo.

NO! It will be incompatible with ALL BIP322 generated signatures and vice versa, They belong to two different worlds and only with lots of dependencies and ugly stuff can agree upon a message being signed: you need to generate and sign a template friendly message then put this message in BIP322 virtual txn then again sign it!! lots of other ugly details here.

The question is: why should they communicate ever? One being a conventional message signing algorithm, the other being a special proof-of-authority "thing".

In my view, it is a too long shot which ends in a total miss-fire. There is no reasonable way for circumventing the versioning requirements when you add features, trust me, it will never happen, there is no general solution for all the problems. Soft-forks do not happen in bitcoin on a daily basis, it is not a "project", like what Etherem is, so, it'd be easy to add new templates ever few years or so.

With all due respect, Peter, you need to re-think this approach. You are free to implement your script version and promote it as whatever you wish.
I'm serious, it is useful, but as far as it is not introduced as a signing mechanism, hence "postponing" the development and implementation of a standardized template based (universal) signing system.

The interpreter based system you suggest is good and useful, but in its own domain and universe, for its own (future?) applications.

No!
It is just an invention, a bad one: Programmable digital signature. There was no such thing in the world before you guys made it up, right? No problem, as super devs you are entitled to do inventions, but as an observer I have all rights to review and to resist.

So, BIP322 is hijacking (taking) your invention and landing it where it was not supposed to (transposing). 
I understand how it feels, getting high by doing abstractions and generalizations, but it needs to pass some review and criticisn. I'm afraid the vague and loose terminology is a bad sign.

Bitcoin scripting system is not electronic signature, it may use this technology. Using a technology doesn't make a system identical with that technology.
Why should anybody do it? Ruining established terminology. What's the catch? Proof-of -ownership or something? Why should it be considered an act of signing? Why don't we simply open a BIP for this one with an appropriate terminology? It is not "message signing" per se, it is "virtual transacting", whatever.

Then how is it possible to have both, template based and interpreter based implementations in one world?
Above thread, I've already discussed it, for now let's check just one issue (there are more, believe me):

For a p2sh where the script is well-formed and can be supported by both, either the message produced by interpreter friendly style is not compatible with template based verification and fails, or it is compatible, the only way for this to happen is preparing and signing a message conventionally and template based the putting this message (including signatures) in the virtual txn and signing it AGAIN! A total mess of a design.


My Suggestions: (I want to be constructive)

1- First and foremost, stop scrambling the terminology, I know, we all know, Greg is genius, you are genious, ..., no doubts, but we are all humans, sometimes we go too far.

2- Ripping this sign-by-script concept off from BIP322, let it focus on true signing with support for references to standard txns (with well-formed scripts).

3- Make another BIP Just for proof-by-interpretation thing. Find a proper label.

Do not mix signing-with-reference-to-txo with proof-by-interpretation/ or whatever you may call it.

You are right, the core engine is opensource but Github is a propriatery web application with so many features besides being truly a hub where millions of devs are collaborating, years, "GatesHub", made me angry by applying stupid restrictions because of my nationality, an obvious act of discrimination, so I decided to do some research even started designing an alternative application based on GIT engine, documenting some ideas, planing a roadmap, stuff, but I couldn't convince a single investor to support, I'm used to reaching this point, dozens and dozens of projects with no sponsor, so, I moved on.

I'm curious tho, amid escalated regulatory threats and the way scam coin lobbyists are doing their nasty job, is it the right time for me to resume my decentralized Git application project?

"GatesHub" sound funny, BTW.

OP,
I started the topic @pooya87 referenced above,  eventually mods for an unknown reason decided it is being off-topic: https://bitcointalk.org/index.php?topic=5169284.0 I wish yours not to end that way.

That said, it is more than obvious that github is the worst option to rely on for development if you get too addicted and dependent. It is an open question though, how much bitcoin ecosystem is addicted to github, and what is the cure?

@NotATether,
It is called "BIP322 discussion thread", isn't it?

Change its title to "I want to join the club by any means", or lock it, whatever, just don't get mad and angry because it doesn't make sense to stop discussing in a discussion thread.