Yep, you can definitely have multiple invisible cosigners!
For example, one could be self-hosted if you have an always-online machine.
Of course, since MuSig2 is an AND of all the cosigners, having more increases the chance of at least one of them failing, so in practice I expect a single cosigner managed by a professional entity to be a very popular option. In that direction, an interesting thing to explore is: how private can this be? It should be possible to combine MuSig2 with Schnorr blind signing, so that the cosigner doesn't necessarily have to learn about your transactions, while still being able to check predicates in them (this paper does it for single-sig: https://eprint.iacr.org/2022/1676 but smarter people tell me it should be generalizable for MuSig/FROST).
Good point about the AND. So maybe only one is enough.
The problem with new crypto, is that well, it is new 😉
I wonder if instead of a centralised large entity signing and thus requiring privacy, if we can let people run such services anywhere they want. What we want is plausible deniability of such a service existing for the user. IDK if such fantastical setups are even possible.
Thanks for sharing that there is some work being done on blinded Schnorr sigs. It could get interesting as things mature. Forza! Avanti!
Coming soon - vibe reading!
I think they shill the chain as a means to serve AI. A chain to pay ai models, something something
Great to see musig2 coming into production ready tools. I loved the invisible cosigner idea there. I wonder if one could have more than one invisible cosigner? This will reduce risk of the one invisible cosigner being hacked. Then you could have two keys that you control via a ledger and electrum to secure your coins.
Am sure the above is a shitty scheme. So much to think through to be sure schemes are secure.
Can TLA+ help to figure out vulnerabilities in schemes?
"Bitcoin is a movement of people" - Matt Odell
Eric Voskuil has something very similar in the past. Bitcoin lets us resist "by other means", where we share the risk.
Go Bitcoiners!
It's not even a question! If a product isn't open source, try not to use it. Especially when it claims to handle your money or your date - which is all uses of software 🤣
Agreed, and as the project grows, you still need to know what you are doing, and hopefully by then you do know what you are doing. 😅
There is also an economic limitation. More block space you take for making miner payouts, the less you can earn fees for that same space. Plus, it hurts smaller miners. They want to pay fees aggregating small payouts.
Belcher did an excellent job explaining it all in this post: https://bitcointalk.org/index.php?topic=2135429.0
"Here is an example of a p2pool coinbase transaction: https://blockchain.info/tx/d1a1e125ed332483b6e8e2f128581efc397582fe4c950dc48fadbc0ea4008022
It is 5803 bytes in size, which at a fee rate of 350 sat/b is worth 0.02031050 btc of block space that p2pool cannot sell to any other transaction. As bitcoin inflation goes down and miners are funded more by fees, this puts p2pool at more and more of a disadvantage compared to trusted-third-party mining pools.
As each hasher is paid to their own bitcoin address, this limits the number of hashers taking part as adding more individual people to the payout transaction increases its size. Also small payouts cost a disproportionate amount in miner fees to actually spend, which hurts small miners who are essential to a decentralized mining ecosystem.
This could maybe be solved by keeping a separate balance state for each user that is independent from the payouts, and make payouts only when that balance state exceeds some reasonable threshold. But this increases the variance which goes against the aim of pooled mining."
Am thinking of moving blog like posts and annoucement pages for p2pool to nostr. What is the most convenient way to organise these atm? Any suggested tools?
Your keys haven't been synched! :) My favourite pain point on matrix. I heard self hosting addresses that problem. How is the experience for you so far?
Exploring YakoHonne. Really nice interface, plus the attempts to "verified notes" is interesting too.
Thought you had given up on matrix?? Going back to a self hosted on?
You could fund the ecash mint using VTXO Spillman channels. Like this proposal but again flipped backwards.
It's more secure. You really don't want to open LN channels with pools. Spillman channels solve that.
https://gist.github.com/lukechilds/307341239beac72c9d8cfe3198f9bfff
Exactly, we can use much simpler contracts than LN to provide the trade between the shares on p2pool and BTC. We do need atomicity in the trade though. So miner's shares and buyers BTC are swapped or not, there should be no state in each either of the party is left hanging.
I wonder if we should write down the contracts in the case of doing this swap without ecash and then with ecash. The devil is always in the detail. I am curious how much extra code complexity we need to introduce to use ecash here.
Another point to keep in mind is, since p2pool is a block chain with transactions, we can provide an extra op code in the script engine. So, can we make the transactions even less expensive on the bitcoin chain by using something like CSFS on the p2pool chain? My intuition says it should be possible, but I haven't explored this yet. Still in the weeds of building the p2pool chain.
First, a cult is the flipside of a wise crowd. The cult patterns seemed accurate, and I watched people applying the cult model to others over and over.
Any intense group, family, business, or team starts to resemble a cult, in little or larger ways.
It's a matter of degree. However, as soon as you spend your free time on someone else's project, you are essentially starting to slide down that slope.
I watched as entire groups went off the rails, unable to think straight or produce accurate results. There was a straight causal effect: as the group became more cult-like, they became more useless.
https://hintjens.wdfiles.com/local--files/books/social-architecture.pdf
Just asked chatgpt to look up p2pool-v2 repo and write a blog post about changes in the last two weeks.
Pasting verbatim below. The repo is at: https://github.com/pool2win/p2pool-v2
Over the past two weeks, the p2pool-v2 repository has seen significant updates aimed at enhancing its functionality, reliability, and integration with Bitcoin's network. Here's a summary of the key developments:
**1. Enhancements to Bitcoin Integration**
- **Bitcoin Difficulty Assessment**: A new function was introduced to retrieve Bitcoin's current network difficulty. This allows for real-time adjustments to mining operations, ensuring miners are working at appropriate difficulty levels.
- **Share Validation Against Bitcoin Difficulty**: Building upon the difficulty assessment, another function was added to verify if a submitted share meets the Bitcoin network's difficulty criteria. This ensures that only valid shares contribute to the mining process, maintaining the integrity of the pool.
- **Bitcoin Block Verification via RPC**: To bolster security and accuracy, a feature was implemented to verify Bitcoin blocks using Remote Procedure Call (RPC) methods. This allows the system to cross-check blocks against Bitcoin's blockchain, ensuring authenticity and consistency.
**2. Testing and Code Quality Improvements**
- **RPC Error Response Testing**: Comprehensive tests were added to handle potential RPC error responses. This proactive approach ensures that the system can gracefully manage and recover from errors, enhancing overall stability.
- **Configuration Testing**: A dedicated test for configuration settings was introduced. This ensures that any changes to the configuration do not inadvertently disrupt the system's functionality.
- **Dead Code Cleanup**: The codebase underwent a cleanup to remove redundant or unused code segments. This not only streamlines the code but also reduces potential points of failure, leading to a more efficient system.
**3. Network and Connectivity Enhancements**
- **Optional mDNS Implementation**: Multicast DNS (mDNS) was made optional, providing users with flexibility based on their network environments. This is particularly beneficial for setups where mDNS might cause conflicts or is unnecessary.
- **Connection Limits**: To prevent potential overloads and ensure fair resource distribution, connection limits were introduced. This ensures that no single user can monopolize the network resources, promoting a balanced mining environment.
These updates collectively enhance the p2pool-v2's robustness, security, and adaptability, reinforcing its position as a reliable platform for decentralized mining operations.
Excellent. Thanks for sharing. I'll read through and come back here.
How is #p2pool managing payouts? The answer - anyway you want. We can say that because p2pool sharechain uses UTXO set, just like bitcoin and the sharechain transactions use bitcoin Script. The p2pool sharechain thus has a fully compatible bitcoin transaction system.
Our first goal is to provide atomic swaps (onchain) between p2pool sharechain and bitcoin. P2Pool pays a handful of miners and market makers from bitcoin coinbase, the other smaller miners sell their shares to the larger miners/market makers. We need this to avoid the coinbase size limit imposed by antminers.
I wrote a blog post describing this approach with some helpful images 😉
https://blog.opdup.com/2025/02/26/trading-shares-for-bitcoin-user-story.html
Potential scalable payout ideas:
1. Atomic swaps on LN a la boltz exchange
2. Swap shares for e-cash?
3. Atomic swaps via Ark providers?
I left the last two with question marks, cause I don't have a solid handle on them yet. Looking for help here to define and implement these! 😃
I published a design a while back for using DLCs to pay miners, where the federation of mining service providers act as the oracle.
https://www.radpool.xyz/1/payout-mechanism.html
Do you have any links on how ecash is locked into a DLC? i haven't read about that.
Regarding swaps, another idea is to run these swaps on LN. I have been told boltz is doing just that.