Could the network of nodes be used in a way to create a built-in system to send joined transactions of sorts within the Bitcoin Core?
You can use different sighashes than SIGHASH_ALL, and you can use PSBT, to create a transaction, that is "partially signed". Maybe more UI improvements are needed, to make it as simple as "Coin Control": for example, you select some inputs, some outputs, click "Create transaction", and then pick sighashes in the UI. And then, you can see, what is signed, and what is not.
So, the first step to join any transactions, is to make them different than SIGHASH_ALL. The second step is to observe your mempool, and join some transactions, if they can be joined. All of that can be technically done, but having built-in privacy is not the first step: it is the final step, and there are many low-hanging fruits, which are required first, before you even start thinking about privacy.
Or is this considered outside of the scope of the project and you are always going to need to use some sort of 3rd party software or web as a service?
It is not "outside of the scope", because if you cannot reach functionality X, then it probably means, you can split it into N steps, and merge at least some of them into Bitcoin Core. For example: is it possible to add Lightning Network support into Bitcoin Core here and now? No. Why not? Because you cannot handle multisig properly from UI. First, focus on getting just that, and then think about LN. Not the other way around. Can you make 2-of-2 multisig on Taproot, from UI? If not, then it is more important than implementing LN in Core. See? You think about winning a marathon, but your legs are not yet implemented. Or they are implemented in console-only mode, so you can technically run quite fast, but you need external tool, because it is not yet automated on UI level.
Could there be any legal implications in doing this?
No, if you handle things correctly. Providing multisig is just providing a tool, that is available in the protocol. And it is implemented in console, but not in UI. The same with sighashes. And the same with a lot of other stuff.
see, "privacy enhancing" coins like XMR, I reckon had some sort of problems when being listed in some wallets
We don't have those features on the protocol level, to be affected by them. Unless you try to bring 2P-ECDSA implementation into Bitcoin Core, but it is a different story:
https://duo.com/labs/tech-notes/2p-ecdsa-explainedI would like to get your view on this and if it's worth developing for Bitcoin Core with the eventual implementation or nobody is going to want this within the wallet software?
1. My view on this is something you can read above.
2. It is worth developing, and it is in progress.
3. People want that, but their strategy is to implement the basic protocol support first, and add more features later, if there will be no other tools available.
And again the legal implications would also be interesting to know if anyone is an expert on this matter.
I am not an expert, but I think if something is directly available in console, then it can be safely ported into UI, and nobody will complain. Because if there would be some legal implications, then they should be raised when console version was released. Unless you have some law, that allows something in console, but bans it in UI, but I cannot think of any such example. And if you bring up anything like that, then what about ASCII-art?
Then how do you choose the PERFECT Coin Join or Mixing technique to introduce to Bitcoin Core?
1. Silent payments are already chosen.
2. Supporting N-of-N multisig on Taproot is already chosen.
3. Adding more sighashes is already chosen.
4. OP_CAT or similar improvements are already chosen.
It depends, who you ask, but some work is already in progress. We even had some failed attempt with OP_CHECKTEMPLATEVERIFY as a soft-fork.
How do you pick the right one then?
Just by posting Pull Request on GitHub, or a proposal to a mailing list, and voting on that. There are procedures for reviewing proposals, and code changes, just use them, and convince the right people to merge it.
What if a new, better Privacy option is worked on right now and pops up soon?
Then, the first merged thing wins, and the second one has to make changes. As with every other code review, if you merge something first, then you can expect conflicts in the second Pull Request. Also, that thing already happened. Because we currently have a lot of address types, but if we would know in 2009, what we know today, then the history could be completely different, than it is. We could have compressed P2PK from the very beginning, and it could be the only available address type. And then, P2SH could be hidden behind P2PK, as well as all other address types. It would be better for privacy, but it was discovered too late, so we have to handle many different address types, because the history is already set in stone.
Do we enforce every body to sit on the same 'pool' you say or do we add other options too?
Each Pull Request is handled individually. And sometimes, a better proposal could cause closing some earlier Pull Requests, before they will be merged.
And of course, you can always roll up your own client, because you cannot beat something with nothing. But if you want to merge something into Bitcoin Core, then you have to stick to their rules, there is no other way.
How do you choose who gets to be the Coordinator on Bitcoin Core?
All nodes should behave as a P2P-based Coordinator. If you don't understand it, then answer that question: "how do you choose who gets to be the one that accepts new transactions into blocks on Bitcoin Core"? You can say "miners", but it is only a partial answer. You can say "mining pools, and their nodes". It is a better answer, but not full.
Each node, no matter if owned by some mining pool or not, can create a candidate block. Which means, the functionality should be added there: when constructing the candidate block. If you can see some transactions in your mempool, and if you can join them, and make things more private by doing so, then your node should do that. But to achieve that, the transactions should be opened for joining. So, they should use correct sighashes (or even use some not-yet-invented sighashes and data structures) to allow joining in the first place. And that should be implemented first, before you even start thinking about implementing any Coordinator.
