SLIP39 is adopted by Trezor and it isn't an experimental implementation, there is a standard for it. If done correctly, Shamir Secret Sharing gives you the benefits of having N-1 parts of your shares exposed without them of being any use for the attacker and plausible deniability as well. MultiSig can function the same, but the process is done on-chain while a passphrase doesn't give you sufficient redundancy.

I've been using ColdCard for quite a while, no problems or complains with it so far. I find ColdCard far more competent than Ledger and Trezor, in terms of the packaging and generally how they manage their products. Ledger and Trezor had pretty bad breaches and existing vulnerabilities respectively, so I didn't choose to go there. If you'd like, there is an option to make it an air-gap as well. You can use the microSD card to transfer unsigned PSBT in and a signed PSBT out, getting the best of both world.

Most secure elements are not open source, because they have NDA governing them. I consider the reliability of the company more important than how open source it is, because where security is concerned, security by obscurity is quite important as well.

You can't feed a fake checksum, the pairing secret is also hashed and cross checked by the secure element.

I agree with both your assessment though. It isn't impossible to fool the users using methods like these which is also why most hardware wallets are either shipping with tamper evident bags or seals at the very least. Acquiring a second hand device just means that the user would be completely bypassing it.

L2 and L1 are fundamentally different. L2 is suitable for smaller transactions while L1 is suitable for larger transactions, which makes far more sense. L2 cannot scale without the base layer being expanded as well. We will always have on-chain transactions when opening or closing the channel, which will happen far more frequently than you think. Lack of transactions on-chain will probably not be due to the popularity of L2 for years to come. There are still various hurdles to overcome.
Mining is as decentralized as it gets, anything that favours economy of scale will also result in centralization. That is a fact. The security would primarily be regarding the costs of attack rather than how decentralized it actually is. If it is not desirable to attack at all, then it simply won't happen.

Your method is fine. It is about what you're trying to achieve. Are you sure that you can secure both of them, the seeds and the order, such that you'll never ever lose them? Losing either of them is equivalent to losing the whole seed.

I would recommend a split seed system, not something like SSS but a simpler one. IanColeman does this in the form of a mnemonic card; https://iancoleman.io/bip39/. Where you need at least two of the cards to be able to recover the seeds. Unlike SSS, an additional card gives you an easier time to bruteforce it but it is still both time and resource intensive.

Ahh thanks! That's quite interesting indeed.

I wasn't aware of this for Ledger. To be fair, any process that requires you to open up your hardware wallet to inspect already compromises the integrity of it so i wouldn't recommend it regardless. I'm wondering if ColdCard's boot check with the LEDs can prevent scenarios like these.

Please do not purchase second-hand or used hardware wallets. It is possible for someone to modify the wallet physically that might not be immediately evident. Most hardware wallets are sealed and sold in tamper-proof bag and for a very good reason. It is possible for someone to fabricate something that could communicate in the same manner and be functionally the same, might be a bit difficult but it can still be possible.

Factory-reseting the device merely wipes the device but might not be sufficient to guarantee security. Considered it compromised if the tamper-proof bag(if any) has been tampered with. There isn't a very easy way to validate the authenticity of the wallet without cracking it open to inspect the PCBs and validate the firmware either.

Your wallets, if it is unmodified, are designed to only accept updates signed by the manufacturer. Assuming your device is guaranteed to not be tampered with and the signers are not compromised, then you should be fairly safe. I'll probably load up an update to make sure. There were cases of some lame social engineering techniques which tricked the user into using keys that were generated by the previous users. Just be aware of that.

By running a full node, you are already helping the network by being a node within the network that relays information. What you can do is to also portforward port 8333 on your router or firewall such that others can also connect to you. If you don't, it is fine as well because you are still relaying and validating blocks/transactions to and from others, thereby forming a part of the consensus. It would be far more beneficial for you to also be using Bitcoin with your full node and not just running it. There is an abundance of node such that an additional node won't really make that much of an improvement in rendundancy.

Just a quick note; Nodes aren't really particularly beneficial to the network at all stages... Yes it is beneficial in terms of redundancy and enforcing consensus but the main benefits would be to the user themselves.

It is quite trivial to take care of your coins, especially if you're knowledgable enough. For those attractive targets, they're likely to have a hot wallet and a cold storage. Their operational requirements requires a hot wallet for faster processing of withdrawal but the majority of it should be stored in the cold storage, where it is very unlikely for an attacker to be able to exploit it.

You cannot eliminate attack vectors completely. Cold storage should have the minimum exposure and thus the best chances against an adversary.

The reason being, there is no volume expected in the early stages of Bitcoin. The supply schedule is designed to compensate for being the only revenue for the miners and when it matures, then fees becomes the primary factor. As you've said, since there is a stabilization, we're far less likely to experience sudden drastic drops in hashrate as we go through each halving.

My point about "4 years being a long time" is that it is sufficient to explore capacity increases in every epoch. It is possible to try to increase the capacity (and the block rewards) to cushion, not eliminate the impacts of a block halving.

If there will probably be lots of on-chain transaction, then why would a lack of transactions be a problem? There will be an equilibrium for the miners as well.

The needs are the demand of the users.


I do. So far, the consensus mainly maintains that it isn't a threat, economic wise. There is nothing that you can really do. The only solution out of this is to break the 21 million cap and maintain a tail emission system such that you don't get any supply-shock from a sudden drop in the block rewards. That is, if you assume that the fees aren't sufficient to cover this. So we'll have a fixed inflation every year, kind of like Monero.

If not, then there is nothing you can really do without radically changing Bitcoin. Bitcoin has a fixed market cap, and if you change that then you aren't using Bitcoin. It is more of a non-issue and I believe that there are still quite a bit of misconceptions about how fees dominated mining income would play out. My primary argument against these kinds of paranoia is that, the current scheme actually works. If we want to ensure that the Bitcoin network today consumes more of that yesterday, then that is never going to be realistic.

That is actually quite a common misconception. Most people don't consider the elasticity of Bitcoin transactions when considering on-chain volumes. Bitcoin transactions are very elastic, if it doesn't prove to have far more benefits than other payment methods, they won't use it. This is the main issue that we're seeing right now. Price of Bitcoin is so high, yet actual transaction volume and real life usage is far lower than it should be. Fees has been high for a long time and it is obvious that the network won't be able to sustain larger TPS, and users have to resort to paying more fees, and at times waiting quite a few blocks before confirmation.

4 years is a long time. There is a point where smaller sub-groups of miners starts to drop off as soon as it becomes less profitable for them and reaching an equilibrium thereafter. There is a reason why the decrease in block rewards is the most significant at the start and starts to taper off as we reach more milestones. At no point in time, will we ever see 50% of the network drop off solely due to the block rewards being halved, so long as we're able to scale on-chain.

In 8 years, if we're facing a problem where we still don't have enough on-chain transactions or still cannot meet the needs, then I suggest that we should just ditch Bitcoin as an experiment.

I don't agree that the incentives will decrease to the point that it becomes a threat to Bitcoin's security. The block rewards will decrease over-time, that isn't really disputable. Just look at the numbers. I don't agree that the drop in block rewards cannot be cushioned through other means.

---

I'd just like to seek your understanding on this concept; There is no reason for concern until we reach a point where it becomes easy or feasible for an attacker to attack Bitcoin. Do you agree?

Help me understand. The resources used in PoW is a function of the income acquired from mining. If we were to assume that the price remains stable, then why wouldn't a capacity increase result in an increase in the fees. The main deterrence with Bitcoin achieving higher utility is only with the capacity as it is closely related to the costs per transaction. The transaction in Bitcoin is highly elastic, a change in the fees would result a greater than proportionate change in demand. If you were to accommodate more TXes per block, then it is not out of the realm of possibility that you will one day be able to substitute the block rewards with the fees.

The computational power is not a good metric to compare with the security of the network*, you will need to be looking at the costs of it. It is also not a good metric to compare using the previous halving. I'm estimating the block rewards to at least,be comprising of 8/10 of the miner's income at best, perhaps 9/10 at worst in the near future (within the next few halvings). You will see a smaller decrease in the drop in hashrate in the future, because fees start to compensate for the decreasing block rewards.

It has nothing to do with how Bitcoin's pricing being volatile or on an upward trend. There will be a point, in the future where the hashrate will stabilize, or at least have negligible change due to it. Fees are supposed to balance out the block rewards in the long run, you will absolutely be able to mitigate any issue with regards to the security if you are able to and want to increase on-chain capacity.

Even with the fees being a very minuscule part of miner's income, with the prices and improvement in efficiency of ASICs factored in, I'm still seeing a relatively stable hashrate throughout the past few halvings, latest halving being 2.74x. Again, think about how much better we can cushion it if fees were to form a larger percentage of the income.

*Ultimately, there is no good way to accurately measure it. So any predictions has to be done on a set of assumptions.

As in, there is no need for us to maintain the security or the difficulty of mining. The point is that: yes, it is great for us to make it more difficult for attackers to attack the chain. It only becomes an area of concern if you look at the chain at any point and tell me that it is easy for someone to attack it. As of now, that is not the case. We're still looking at the difficulty increasing at the current price and a limited block rewards.

It has never really been the case at all. Each of the halving are so far spaced apart in time, there is always a more than sufficient time to ensure that the compensation is sufficient such that the difficulty drop is less than proportionate. As each of the halving are 0.5x the block rewards, you will start seeing the rewards being a lower composition of the miner's income. Subsequent halving should still result in a less than proportionate difficulty drop.

Yeah. I didn't really meant to say that a capacity increase should result in the majority being excluded. Simply no point to make up even more excuses to not make any improvements.

I don't understand. Why is everyone so particular about *maintaining* security? That is not the point of PoW. The point of it is to make it prohibitively expensive for any adversary to launch an attack against Bitcoin. It is NOT an issue until we reach the levels where it becomes critical and profitable for an adversary to attack Bitcoin. We are very far away from that stage.

I think it is both unrealistic and unreasonable to demand the same level of security at all times. The resources needed to attack Bitcoin is astronomical at it's current stage, to the point where it is ridiculous to be attacking Bitcoin, and we still have block rewards. I don't see the need for block size to be increasing because there is nothing to be compensated for. Bitcoin is secure enough at the current stage, and it would suffice to have a linear increase for the near future.

We are. I don't think the argument here is to make it prohibitively expensive for normal people to run a full node... I think you misunderstood my "sustainable" block size increase?

Let's be a bit more pragmatic. Would users prefer to run full nodes over an SPV node at it's current stage. Full node offers virtually little to no benefits to most and the security/privacy of it is overblown. There is simply no reason for people to still be running a full node, unless they intend to run a full node without any tangible benefits to themselves. At that point, then it probably wouldn't matter to spare a couple bucks more to get a larger storage.

Having lesser people run full nodes isn't a problem. It only becomes a problem if it becomes centralized to the point that it poses a threat to the network. Full nodes are important, I never denied that. A capacity increase doesn't result in the majority of the users that were previously interested in or otherwise able to run a full node to suddenly not be able to do so.

Technological improvement has made manufacturing cheaper, and in a larger storage density. It simply doesn't make sense for us to not be keeping up with it as well. 1MB as a limit was arbitrarily defined, and it stuck for so long before Segwit got activated. Even the SW block sizes are underestimating the true capacity of the network.

It has been increased, Segwit.

You're right. There are many users here that have argued that we don't need a block size increase and that any of that is just pure big-blocker bullshit. Well, some of them are but there is a real need for a capacity increase. I have my doubts that many of the Bitcoiners are willing to even use Bitcoin for their day-to-day payments. In a lot of cases, it would be far better to just use fiat than have to deal with the miscellaneous hidden costs incurred by trying to use Bitcoin.

Does seem like many of the misunderstanding on the topic stems from the poor understanding of what LN is actually intended for.

There isn't any problems with a sustainable block size increase. It is ridiculous to be relying solely on off-chain transactions for the average person. Just because off-chain transactions are better for smaller transactions, it doesn't mean that there isn't any need for on-chain transactions. The problem with bigger blocks is almost always over-blown. There is no such thing as decentralization when it has always been far better for an average Bitcoin user to be running an SPV client instead of a full node. Storage size is obviously getting far better, either in terms of storage density or costs so that isn't really the issue here.

Just by assuming a doubling of the TX per block, you're easily looking at 0.5BTC or more at peak periods. Bitcoin isn't even suitable for day-to-day transaction right now, so I fail to see why we can't bank on having more TX per block to solve the problem. Bitcoin's current difficulty and required resources is huge, and it is still increasing. So the security issue is really overblown.

Yes. You need at least another one other seed or master public key.
Not necessarily. Multisig serves as a system to allow the users to specify the conditions for a transaction to be valid, and in this case the number of signatures from unique parties for a transaction to be valid. It doesn't make it more secure if you're going to be signing or exposing the keys to a single point of failure, eg. signing them on the same computer or generating the seeds on the same computer. You're also having a much larger transaction size due to the inclusion of the redeem script and signatures.

You can always implement a flawed RNG during the generation or intentionally make it predictable such that while the seeds are random, it isn't random enough. Given a compromise in the entropy by the manufacturer, it is far easier for a rogue manufacturer to bruteforce them. The manufacturer doesn't necessarily have to know the sequence for which they're generated, just sufficient information to be able to bruteforce them.

I'd just say that this would probably be extremely unlikely to happen. Most people don't have the capacity to identify it at all, so they can always ship one with a compromised pre-loaded firmware and bootloader, but the same goes for literally any other device that you want to have.

There is simply no way that transactions are done entirely on lightning or on layer 2. That is unrealistic and makes Bitcoin completely useless and which is why I've criticized repeatedly on the fallacy of having a limited on-chain capacity and banking on off-chain TXes to sustain the TX volume. We absolutely need a capacity increase in the future to even think of mass adoption. Again, 7TPS is ridiculously small and lightning network isn't (and should not) be the solution to the problem.

Again, the problem we're looking at right here is not to ensure that we maintain the same level of security. The whole point of PoW is to make it more expensive to attack the chain than be honest. If there is a substantial security decrease but we're still looking at a huge discrepancy between the profits from an attack vs profits from mining, then there is no problem.

You don't have to "register" a transfer. The payment request is simply for you to keep track of your transactions and assigning specific addresses for them. As long as the receiving address is still in your wallet (ie. you didn't delete the entire wallet file or the seeds), then it would be totally fine. Bitcoin addresses will never expire.