Is there an upper limit to the number of Guardians?

Since every guardian (aka server aka node) in a fedimint needs to communicate and come to consensus over the network, you largely run into a latency constraint around consensus.

Especially if the network latency of those machines amongst each other is variable or high.

Eric Sirion (fedimint creator), supposedly did some upper limit testing and found that consensus starts to get unreliable/weird/etc around ~15 guardians, so I'd estimate ~4-10 being a sweet spot for number of guardians. This works well with the intended scope of fedimints - small, "local", focused, second-party custody.

Since each guardian might be running different hardware/operating system/etc. giving explicit upper limits can be tricky, especially given the relatively small sampling set of people running fedimints in the real world.

Just a small test — giving out 150,000 sats to people who drop an area I should research in cutting edge BTC dev! Starting now! Will be more later.

Crazy to think that most of the world is completely ignorant to the power of Nostr and what’s going on here.

Unpopular opinion:

Lightning is amazing tech and the best we have, but being unable to receive funds without spending funds first sucks.

The main issue with the Hodl Contracts technology simply on its own is the need for a individual third party to acts as an Oracle and to decide on the betting event outcome.

Although this Lightning Routing Node cannot steal the funds that are being routed through it thanks to the Lightning Network's technology, they could hold the funds hostage for up to the invoice's expiration either by malfeasance or lack of connectivity or, in the wort outcome, they could settle the payment incorrectly either due to error or by being bribed by one of the participants somehow.

In order to mitigate the flaw of this trust model, Vigless will utilize the Fedimint protocol in order to band together several Lightning Network Nodes under a MultiSig technology.

Unlike a normal Fedimint “Federation", this federation will not actually issue any Ecash tokens but will only be used band together routing lightning nodes that watch over each in a programatic manner using open source code. Most importantly the ability to access and change a Arbitrator's Lightning Node operating code curtailed by the fact that all the nodes belonging to the same federation are able to validate each other's operation and keep each other in check. Therefore, the Arbitrator belonging to the same federation are assured to run act as honest nodes as well as a majority of guardians remain honest.

Any user of Vigless can become a participant of the Federation quorum simply by running a node and stating their interest in doing so, given more credibility to it’s trust model.

The federation will be periodically disbanded and reformed to integrate additional guardians over time. By virtue of having the Escrow Node functionality distributed amongst a large number of anonymous users and by the fact that the mint itself actually does not custody any funds but rather only temporarily holds and routes lightning payments, the possibility of collusion becomes very difficult and unpractical and most importantly, there is very little incentive for the guardians to do so.

For reference, here are my main thoughts on the current Bitcoin softfork ideas/dramas to those who care.

For context with regards to wherever it might matter, I have a 12-year background as an engineer initially and eventually an engineering manager, including overseeing electrical/mechanical/software for an aviation simulation facility, but although I have written code here and there in my early days, I am certainly *NOT* a software engineer. My career work is on electrical engineering and multi-discipline engineering management, and my master's degree is in engineering management, with an emphasis on systems engineering and engineering economics. Any viewpoint I have is from an engineering/systems management perspective or an economics perspective, not a programmer perspective.

I follow multiple software Bitcoin experts on various topics, many of which disagree with each other, similarly to how I followed my various lead engineers when I was working in engineering management.

The U.S. Constitution is well-written but of course not perfect. It's a good document, especially after the amendments it has had. The most recent amendment was over 30 years ago, and it is minor enough that most people don't know what it is. The second most recent one was over 50 years ago, and that one is also pretty minor, imo, and most people don't know that one either. The Constitution, the Bill of Rights, and a then a handful of key amendments after that to fix key issues with race and gender voting and so forth, have been the foundational aspects of this whole Constitutional project.

In order to change the U.S. Constitution, you need both a supermajority in Congress and a supermajority among States. Good luck getting that. And that near-immutability is exactly why the Constitution is valuable. Even if it was better written and included all sorts of things I liked, if it were easier to change, I would consider it to be a *worse* foundation than it is now. The near-immutability is the critical part. A nearly-immutable good document, is a great document, if it serves as the foundation of something important.

When it comes to Bitcoin, the aspect that I view as being the most valuable is its near-immutability. We have a global open-source ledger foundation that gives us savings and payment/settlement technology. It makes hard trade-offs in order to remain reasonably decentralized. And yet, Bitcoin can settle more transactions per year than Fedwire does, which is the U.S. base settlement layer, which handles (not a typo) 1 quadrillion dollars worth of gross settlement volumes per year. Bitcoin does that function but is global, open-source, and has its own scarce units. Various layers can expand that scalability, (Lightning, sidechains, fedimints, custodial environments, etc). Certain softforks to the base layer may also add some new scalability options (covenants, drivechains, zero-knowledge proofs, etc). But those softforks present risks to the whole project, unless they have a supermajority of support and are considered to be of low technical+incentive risk.

When I was an engineering manager for my aviation facility, if I were to approve a major new change and help fund it, it would be because the supermajority of my senior technical leads supported it, and because they could convince me of it. Objective truth tends to be easy to share between rational people that listen to each other. In contrast, subjective things that are more contested of course tend to be harder. If I liked a new change but it didn't have a supermajority, I respected these divergent opinions and wanted to know why they saw it differently. Unless it was in an area where I was *specifically* the facility expert in (in my case, the electrical/control aspects within our organization's aviation simulators), I would never go with a minority opinion among my technical leads and override the majority of my technical leads.

One of the most common problems I encountered in my career was over-engineering. Not a single person knows every detail about how an aviation simulator works (which was my field of work). There are software experts, graphical design experts, mechanical experts, electronics experts, pilot experts, and then business experts that have to figure out what is valuable to clients and how to get the required stuff and how to make the whole thing economical and thus well-incentivized. Systems engineering, practically by definition, is the science of managing a project that is more complex than any one human mind can possibly understand. Any major project engineer/manager has to deal with this dilemma.

As it pertains to over-engineering, many people often have pet projects that they care about, or want to make really cool complex things, that are not economical or not robust. Endless changes can create endless complexity, which are hard to maintain, are less reliable, and so forth. The most beautiful engineering designs are often the most simple at the foundation. Complexity can exist in layers or silos built on or around that foundation, which reduces contagion risk to the simple-but-robust foundation.

In short, if you you can't convince a supermajority, then maybe your idea isn't right or needs more work. Maybe the problem is on your end. Especially if the supermajority that you need to convince are intelligent relevant people (in Bitcoin's case: software developers, node-runners, miners, capital allocators, etc).

And of course, foundations like the U.S. Constitution or the Bitcoin base layer are far more important than the engineering frameworks of some random aviation simulation facility, so the standards are higher.

So, how do I assess proposed softforks as someone who hasn't written code in a decade but tries to follow the designs and economics of various proposals where possible? I look towards technical leads, and look for a supermajority of serious stakeholders, and need the proposal to clearly make sense to me technically and economically.

I view Bitcoin as being valuable due to its near-immutability. That is the source of its monetary premium. And so as follows, from a project management perspective regarding what is among the most serious of all possible projects:

-The first rule of Bitcoin is you do not break Bitcoin.

-The second rule of Bitcoin is you do not break Bitcoin.

-The third rule of Bitcoin is you do not break Bitcoin.

-The fourth rule of Bitcoin is that, around the margins, you try to find conservative ways to improve Bitcoin that are clear enough to get a supermajority.

Therefore, my view on softforks is that I defer to the supermajority of experts I trust, while also needing it to make sense to me personally. I'm agnostic towards many softforks, since I don't have the detailed software expertise to be relevant between similar proposals. As proposed softworks gain momentum, I check to see if they make sense to me, and then look for a supermajority.

Bitcoin is valuable due to its near-immutability. If it can be changed by minority factions, then the relevance of the project over the long arc of time is limited. To the extent that it's going to be any sort of important base layer, that near-immutability, much like the U.S. Constitution, is critical. To that extent, any proposed change to Bitcoin is not just a software thing; it's an economics thing as well.

Therefore, if proponents of a given softfork try to find a way to push itself on the network without a supermajority of technical experts and economic actors, then whether or not I like it, I will oppose it. That's a way to turn me from neutral to opposed. Because that near-immutability is what I would fight for. I only support highly agreed-upon changes. Whatever small piece that my node, my voice, and my money can do, I err towards the near-immutability.

You still have to trust someone with your bitcoin. Which is not what satoshi had in mind for bitcoin.

You still have to trust someone with your bitcoin. Which is not what satoshi had in mind for bitcoin.