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 nailed it.  

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

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.

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.

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 their exposure is not strictly necessary with MAST:
For 1 of n signatures, unlike legacy Bitcoin script, you will have n identical leafs such as <pubkey-i> OP_CHECKSIG for each pubkey.

To spend the P2TR outpoint, or for what you are interested in (proving to be relevant), holders of each key should include log₂n - 1  hashes (Merkle path) and only their own public 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 any Bitcoiner. We are not hired by anybody, 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: dev resistance.

I can imagine an attack like this:
1- The adversary recruits an army of average programmers, sending them to Bitcointalk, Reddit, the 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, while they enjoy free technical/editorial support for their contributions, to follow 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 be comfortable with just 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 defenseless. With all the hypes and threats, it is the worst time for us to be distracted by BIPs and TODOs.

Again: Keep it low and slow, that's the 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 any means to anybody.

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. They weirdly sanctioned 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).

P.S.
Note how downward compatible and inclusive is the scheme I suggested, with just standard Digital signature libraries, very simple applications can communicate (just ignoring the bitcoin address related meta data) with each other as well as with much more sophisticated applications.

Also note that there is no need to reject the upside-down world, it can exist and do whatever it is  supposed to do.

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?

As for your show-off with what you've learned about the way interpreter is implemented in bitcoin client:

Please note: We are comparing message signing using templates with this job done using the interpreter, the latter, according to BIP32 is done by putting the message in a virtual/invalid transaction and signing this transaction, these two are incompatible, so, no, they don't reach to an agreement. The only way for this to happen is the ugly dependent way, I briefly described.

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 the rights to review and to resist.

What happened now? Bitcoin script is a digital signature with transactions as their messages, then it evolved to a general pupose one for arbitrary messages? So, there are two consecutive inventions : first we invent programmable DS, and immediately we go all-in to make it even more general purpose? Fantastic but absurd, isn't it?
Or maybe BIP322 is just hijacking (taking) your invention, landing it where it was not supposed to land (through a transposition).  

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 a digital signature scheme, it may use this technology (we have signature free scripts, don't we?). Using a technology doesn't make a system identical with that technology.

However, why should anybody do it? Ruining an 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.
For compatibility, you should
1- Prepare and sign a message template based.
2- Put the signed message in the virtual txn.
3- Supply witness data, using your signature again!
4- Every time check the verifier and supply properly either the virtual txn or the message.

The last step is necessary unless you IMPOSE dependencies on template based wallets.

Ugly & Disgusting.

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 genius, ..., 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-ref-to-txo and proof-by-interpretation/whatever.
[/list]

You are right, the core engine is opensource but Github is a proprietary 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" sounds funny, BTW

OP,
I started the topic @pooya87 referenced above,  eventually mods for an unknown reason decided it as 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. 

I purposefully avoided it to stay on the main line which was criticizing the concept, and not the BIP.
As you've brought it up: BIP322 supports both worlds at the same time!
How is it even possible? Is the BIP trying to invent another third universe where paradoxes are considered normal and tolerable?

I got this standard script behind a txo which somehow I'm able to unlock, and I'm trying to tie a message to it,  the problem is I got two different interested parties, one uses Bitcoin Core while the other party has another wallet.
What do I have to do when trying to convince them?
More critically important: When the said parties finish verifying (probably different versions of) my message, the party using the interpreter is convinced about a message being supplied by "somebody" who is able to unluck the txo, but what about the other party? Should they ignore the fact that their wallet already knows the public key(s) that actually was used?

See? Two different messages, two different signing processes, two different verification algorithms, and finally two, radically different application domains. What kind of BIP is it? A derailed BIP!

Yes, it's easy when you see it, but you should look, just look. Essentially, the BIP is trying to get implemented by any means without insisting on any principle or philosophy, I suppose I could forge an arbitrary third world and successfully convince Karl Johan to support it as well!

It's Greg Maxwell, not Luke, I like Luke, even when he goes too far. As for Greg? No ways! I mean, I'm a fan, not comfortable with the polemic but a fan, still, I don't know why I frequently find myself on the opposite side of where Greg stands, what's wrong with him?  

No, it is not optional, the other way is supposed to be optional, you just admitted that Bitcoin Core reference implementation is focused on "tying" stuff. I've already refuted this mix-and-support design policy.

Bitcoin script, has it through employing ES technologies like ECDSA and Schnorr, but script signing? No! It doesn't. It just implies that the script interpreter has passed testing some witness data for unlocking a txo. It is silent about the identity of the party who prepared this data, hence there is no established mechanism for authentication and repudiation unless you/your app would examine the witness data beyond what the interpreter does, e.g., by checking whther the message is signed and if so, is the signature identical with the one used for unlocking? See? It's so ugly!