pull down to refresh
op_ctv would be nice. Could spread out more lightning open and close actions across a lot more blocks.
If this makes Lightning more "efficient"... I'm not sure we need that
We should make a list of what our options are for this problem, with tail emissions being the most nuclear option, rank them by intensity and viability, and then just sit around until it becomes a problem.
I would rather the entire project fail than we propose a "tail emission" because if we do that then Bitcoin will fail.
Unfortunately, it takes waiting for it to be a problem for a unilateral soft fork (even hard fork) to work out for this problem specifically I believe.
I don't know why credible people haven't at least suggested a block size decrease. It's far less disruptive than anything else being proposed right now ("proposed") plus it decreases spam and makes blocks easier to process.
Sounds like a win-win to me if we're going to do something
If this makes Lightning more "efficient"... I'm not sure we need that
And it does, but there was also this idea about making a chain on on-chain transactions that don't wait to be mined because you've already committed to a limited set of possible spending paths, so the user is less worried about getting their transaction mined "right now"
However, having said all of that, I had a thought last night.
Mutually Assured Destruction Transactions could be a thing today and would kinda have the same affect. Only kinda. Don't know how you'd make a chain of CPFP transactions will still being able to maintain your MAD capability until it gets mined.
But do you get the idea? Transactions over more blocks vs more transactions in a block. Consistent fees included in blocks vs one block with a lot of fees.
If I understand what you are saying... we don't have almost any blocks with "a lot of fees." Fees are already pretty consistent at near 1 sat/vbyte and the spammy transactions (runes inscriptions etc) are typically .15 sat/vb or less. I mean they can't get much lower.
Have...you not been around very long?
Listen, we have months of VERY high fees, and times like this of almost no fees.
You have to solve both sides of the problem simultaneously, because only solving for one side, makes the other side worse.
So what I'm saying is, if people during the times when fees are VERY high, could instead be enabled to wait (which you can only really do by making waiting itself unnecessary), until these lower tides for their transaction to go through, the stress on both sides, high tide and low tide (high fee and low fee) can be solved at the same time.
CTV is retarded, all it does is delegation (centralization) which allows the deferral of costs at best. Proponents are just re-branding centralization and trust with scam fake L2 wallets and DeFi, shitcoiner mindset.
Channel ops (or transaction throughput generally) is not the scaling bottleneck, divisibility is. There's literally not enough Bitcoin for mass sovereign usage, given it only goes to 8 decimal places, and chain security costs a minimum of 4 decimals, realistically 5-6 if its not to be a substantial portion of ones assets.
Security budget stuff is nonsense, industrial mining is an arbitrage on a temporary subsidy and stranded energy. It must continue evolve into to waste energy or heat as a by-product, like space heaters, to re-decentralize.
If the network is valuable enough to users, even if block rewards are diminimis, there's an incentive to mine. Not that it will remain diminimis, the intended users aren't here yet, the chain is for institutions, akin to Wire/ACH: #1437045
Tail emissions won't happen, just as an increase in divisibility won't happen, both are supply increases that would capitulate to malleability thereby making it worthless.
op_ctv would be nice. Could spread out more lightning open and close actions across a lot more blocks.
We should make a list of what our options are for this problem, with tail emissions being the most nuclear option, rank them by intensity and viability, and then just sit around until it becomes a problem.
If it then does become a problem, we then UASF each option.
Unfortunately, it takes waiting for it to be a problem for a unilateral soft fork (even hard fork) to work out for this problem specifically I believe. Otherwise the other chain that might URSF could get away with paying for security in block subsidy and win by being the default.