I've highlighted the constraints of the network with a larger block size and why a block size that is excessively large isn't favorable for the network. I'm not concerned about your algorithm, I'm concerned about whether you think it is okay for the so called self-regulated system to regulate the block size such that it can potentially take up to minutes to propagate across the network.

Do you think the point of the block size we have today is to introduce scarcity into the block or is it ensure that the blocks are appropriately sized and thereby preventing any issues, pertaining to the security of the network or it's resources? Your self-regulated system is not going to work if it can have the potential to make the network excessively centralized or insecure. There is a very good reason why most of Bitcoin's derivatives don't have a dynamic or an unlimited block size (for which a dynamic block size without any hard cap can also be considered as an unlimited block size).

Edit: If you think that it is fine for a dynamic block size without any upperlimits, then I rest my case. I don't have anything to add on ontop of what I've mentioned and I'm not a huge proponent of increasing it to meet a level that could be compared to the TPS of a mass adoption.

There is no such thing as complete decentralization, sorry to burst your bubble. You can only achieve complete decentralization if every user of Bitcoin is mining by themselves, ie. 1 CPU 1 Vote. That has never been the case for anything, because you cannot stop people from expending more resources into mining. There was a sharp drop in difficulty but the est. network hashrate has been rising for the past few weeks. People moving their operations out of China is more of a precautionary measure; China banned Bitcoin mining but it also doesn't mean it can be done overnight.

The crackdown did not cripple Bitcoin at all, the network was still running smoothly. It is fine for a certain degree of centralization so long as no single entity are able to dominate and control Bitcoin, which is still true.

It shouldn't be impossible to read the code; you only have to find out if Trezor, at any point will communicate the seed through the USB interface. If it doesn't, then you should be safe.

I don't think it is a problem with our current technology. HW wallets are designed to keep your seeds safe and the only reason why it would ever become unsafe is if the seed is revealed through a zero-day vulnerability; ie. design oversight. Obviously, airgaps can be compromised and it is also possible for zero day exploits to appear.

It would be still ideal for a significant portion of the users to have the capabilities to run a full node. Relying on someone else for validation isn't really a good idea, and yes, I did agree that the full node numbers would probably dwindle in the future.
Do you think we should cap the block size with your variable block size scheme? You do realize that an increase in block size or transactions per block will inevitably result in the blocks being propagated through the network slowly or a far slower validation. This makes it unsuitable for smaller miners to be mining and will have to be directly connected to at least half of the network to achieve a lower stale rate. There is a reason why the blocks were capped at 1MB, and that any scheme should strive for a reasonable block size that doesn't compromise the security of Bitcoin. An increase in the stale rates also results in a decrease in the perceived security, as there can be multiple conflicting blocks at the same height.

I don't disagree that we need a block size increase. What I'm thinking of is a sustainable block size increase that balances the tradeoffs to the benefits.

I'm far more concerned about the security of the network being impacted, instead of the issue surrounding the costs of a full nodes. In this day and age, most people simply wouldn't opt for a full node as their daily driver unless they're interested in Bitcoin. Most people wouldn't run a node, no matter how much money they can save simply because it is time consuming and not very rewarding.

The issue surrounding block size has really been discussed over and over again and I doubt we would reach a new conclusion by doing it again. Again, since this issue brings us to whether we scale on-chain or second layer, it doesn't make much sense to discuss it on this thread. I prefer the latter, 100MB blocks isn't really desirable for the near future.

Hmm, okay I understand your argument on this.
The ideal block size should be something that still ensures that the network is sufficiently secure. It makes no sense for us to implement a dynamic size, where the size gets inflated to unrealistic limits at times just to accommodate the extra transactions. It would be far better for us to determine the specific and appropriate block size from the on-start because there isn't any downsides to that. If the demand isn't enough, then the blocks would naturally be smaller.

Electrum inherits the word list from BIP39. While the generation is not done in the same way, the fact that they have the same word list will result in them meeting the criteria set forth in the BIP.

Assuming that the way the seed is generated is compliant with BIP39 and uses that word list. BIP39 states:

- the wordlist is created in such a way that it's enough to type the first four letters to unambiguously identify the word

The wordlist within the BIP fulfills this criteria.

I doubt it would crash to zero. The price would probably crash and bring down the rest of the cryptos as well. The network is likely to fork and change the algorithm as there exist an adversary which controls the majority of the network hashrate. There is a potential for SHA256D coins to change their algorithms pre-emptively which would render all of their ASICs useless.

Just to clarify. P2PKH or the v1 Bitcoin addresses has been around since the initial release. It is just that the mining interface and the pay to IP are both using P2PK but I doubt it is really of any concern since no one uses them anymore.

So basically, the point is that you believe Satoshi should've decreased the block time while increasing the maximum supply.

Going by the economics of a currency, there is no problem with the supply because it is divisible, and thus we wouldn't run into an extreme shortage of the currency and making it excessively scarce and unsuitable for normal payments. As with the block intervals, it was done with a compromise, to try to keep orphan rates low while being sufficiently fast. At that time, it would've been a fairly reasonable assumption to make.

I would lean towards a Trezor, or hardware wallets in general. The main point of a hardware wallet (and also your air-gapped wallet) is to protect yourself against a malware attack. That is by far the greatest threat to Bitcoin users. Hardware wallets are specifically programmed to not reveal your seeds/private keys using the MCU and thus any communication should be sanitized and will make it difficult to compromise as compared to an air-gapped wallet.

Loads of users do not know how to properly setup an air-gapped wallet, comparatively, hardware wallets are more suitable for the general userbase as compared to an air-gapped wallet. If you'd like, HW wallets like ColdCard has an SD card feature which allows you essentially achieve an airgap as well.

Correct.
I'm against a dynamic block size because it fails to take into account the possibility of the miners intentionally colluding and manipulating the fee market, by either introducing scarcity or otherwise intentionally gaming the block size. Problem with dynamic block size is that it is difficult to accurately provision higher block size for the correct period, due to time lag mainly as the sample size is way too huge.

I would rather just proposing a predictable block size increase, than to have a dynamic block size because it is honestly quite redundant. I don't expect Bitcoin to survive solely on on-chain transactions, that isn't feasible.

No. Bitcoin 0.1.0's peer discovery mechanism has been deprecated for quite awhile, namely the IRC. You won't be able to discover any peers to connect to when running 0.1.0. Tons of protocol changes since then as well.

There isn't any reason why you should attempt to run 0.1.0, other than to perhaps satisfy your curiosity.

Unfortunately, that isn't what majority of the community wants. There is nothing wrong with increasing block size, but if you were to increase to that extent, then no one except a selected few can run a node because they are prohibitively expensive. Miners can only mine if they're fast enough, which would mean further centralization as they need to achieve the lowest latency possible to reduce orphans. Complete centralization of Bitcoin defeats the very purpose of it, and putting the control of it to a selected few only serves to discourage people from using it.

There is nothing wrong with increasing the block size to increase the on-chain capacity. However, if you want to achieve mass adoption and surpass that of the major banking systems, you can't do it without making it impossible for the average joe to run a node. There is no way this should ever happen, because we'll be at the mercy of whoever is running the few nodes.

I briefly read through the topic again. Are you still proposing a complicated dynamic block size as opposed to a simple and linear block size increase?

B is correct. The idea of blockchain was conceived in the 90s, IIRC.

The concept of Bitcoin as a currency was also conceived around that time as well, though in a rather unrefined and abstract form. It wasn't until B-money proposed a similar concept then Satoshi creating Bitcoin as a currency which combines all those into one.

The network hashrate won't grow because the rogue chain is mining alongside the honest chain but the chain isn't revealed until the attack has started and even then, it would be good for a single attack because precautions would be taken by the merchants or the stakeholders on the network.

It will only grow if the rogue entity mines on the honest chain aswell, before taking it offline but even then the growth will probably be gradual.

There's no answer to your question.

It really depends on the purpose of the update; is it to fix a known bug, is it to fix a vulnerability, or is it to add new features? You have to read the changelog yourself, starting from the version that you're in to the latest version. You aren't really risking anything if it isn't done to patch a vulnerability but I would probably still advice people to just update it. There's no harm done.

I assume this is done when you were using your Electrum? The blue bubble appears if you're connected over the proxy or Tor that is set within Electrum. If you did not specify the server before that, then the server would've been random.
Within Electrum?
An Electrum server is different from a full node. Electrum servers communicates differently from a full node, so you can't just specify any random node as your server. It has to be an Electrum server, so I'm assuming your umbrel supports it. Tor browsers are hardened browsers that is used to access the web using Tor while a Tor daemon doesn't necessarily include that.

You've always had to download Tor. Either Tor browser or Tor daemon, the only difference being the ports.
Are you connecting to your node correctly?
Electrum servers are designed to communicate with Electrum clients while full nodes do so with other full nodes.

I think OP's point is for redundancy, in case of certain disagreements so at least 4 of 6 of the parties can agree on it and the approval of the final 2 isn't needed. Moving it to a 6-of-6 musig wouldn't make that much sense in comparison.

Wallets should probably discard excess signatures for obvious reasons, because it is quite rare for people to have to prove that all of the parties are in control of their keys. Would it be possible for you to just create 2 transactions, with one of the parties signing both TXes and the other parties being unique.