Replies (50)
That’s assuming it will even get that far.
I think we can make it happen. Everyone’s interests are aligned here. Both main chainers and Luke’s acolytes want to see them fork off.
Whatever it takes to shut them up.
I'm a big fan of doing nothing and letting the children beat each other up.
Yeah and assuming you do not have any LN channels. With LN channels things get even more complicated. So better have prepared some watchtowers.
I'll keep "Luke coin" because that'll be real Bitcoin.
I would gladly close any channels I have with Knots nodes if I had a way to identify them.
Is not only about that. Any peer you have channels with will be affected, running knots or not.
We should try to avoid this fork as much as we can, because it could be really messy.
The one in 2017 was easy peasy, without LN, everyone doubled their stash easily, but now is much more complicated.
I also want to double again my BTC stash, but with LN channels running, is not that simple.
Hadn't heard the term replay attack before.
Do I have it right if I say I'm safe by just not receiving nor sending on either chain until I reorg?
A replay attack is when a transaction is valid on both chains. If you do nothing (HODL tight), then you’re at no risk by definition, since you haven’t made any transactions to replay.
However, the instant you want to make a transaction, you’re at risk of replay, and hence the need to split.
Existing Lightning channels are definitely a problem since they’ll exist on both chains and therefore could get into a bad state. In the case of Lightning, the winning move is probably to close channels quickly, split, then re-open on each chain.
Easy, just stick Luke and Mechanic in a mental hospital where they belong.
The market will decide which chain ultimately gets to wear the Bitcoin brand label. It’ll be messy. The good news is that everyone can vote with their money, keeping or selling the chain they prefer.
Fucking hell, I don’t want to shut down 80 channels.
OK start educating all those thousands of public node runners and also other thousands of private node runners to coordinate them all closing their channels in the same time and in a cooperative mode.
Nobody is compelled to do anything. Two nodes sharing a channel will continue to operate just fine. The only issue is that Lightning payments will effectively be auto-replayed on both networks (in a sense) until the Lightning network bifurcates.
It’ll be messy, but it’ll work. People who are most concerned with replay will split and reopen fastest.
I disagree. We should activate BIP-444 as quickly as possible and get the fork started. The sooner the market can start pricing the two chains independently, the quicker this will be behind us.
Your greed talk from inside you now...
We should avoid a fork in this moment as much as is possible.
The disruptions in LN will be enormous. You still do not think clearly about those implications.
Yeah, the potential stacking opportunity is not worth the pain.
I agree that there will be disruptions. I agree that it’ll be painful and messy.
I argue that the pain and disruption is better to handle sooner than later. If a contentious soft fork is disruptive to Lightning, it’s better to learn from that sooner so we can adapt Lightning to make it more resilient to the next one.
Bitcoin is anti-fragile. It will strengthen under this test.
Agreed that the financial benefit is not huge. Maybe a 20% increase in stack would be my prior, based on BCash.
The advantage here is to eject a toxic minority and to become more resilient to future contentious forks.
BIP-444 should be only about placing op_return limits on a consensus level, it would be less messy and would probably get consensus. Down the road other data restrictions could be proposed more carefully.
It doesn’t matter to me what exactly is in BIP-444. The point is to get it underway quickly so the market can start pricing the two competing chains’ coins.
There's alway the option of the bip not going forward wich is probably the best.
🤣
Wouldn’t it be simpler if Core reversed the Op Return limit increase ?
Bip-444 should just be ignored. If one wanted to spam the chain with csam one could do it without anyone’s permission using fake pubkeys. There is nothing that this bip does that can stop that.
You’re right that technologically, the fork has no effect. What was possible before remains possible after.
The point of the fork is sociological. Give the Knots folk their own chain with their own rules. A clean break from Core.
This is not true in the same way as OP_RETURN and that's literally the whole point of contention. This has been stated and refuted nearly millions of times at this point.
Agree that the mechanism is different for how to insert arbitrary data with/without OP_RETURN.
The important thing is to get BIP-444 activated so that the market can price the two chains.
The underlying assumption of data contiguity being irrelevant is wrong. That's literally been the entire debate. One side thinking contiguous byte order is irrelevant and the otherside arguing MANY MANY ways that it is. But what ever, forks like this won't stop anything.
Remove OP_RETURN standardness and increase the witness weight to see real results. Then Fake pubkeys, taproot annex, fake sighash, ALL don't matter, as long as you pay.
If spam outbids financials, fair enough. Economics should be the only determinant.
Nah, the fork is doomed to fail for other reasons. Libbitcoin is the only promising implementation and even it is still working on a viable branch for all of its features.
PSA: This is shit advice and a good way to lose all your Bitcoin. There likely will not be a (long lived) chain split regardless of what consensus wins, since this is a soft fork. There could be, but it's not guaranteed.
If you try to trade a "airdrop" you may just find the chains reorged and you sold all your actual Bitcoin, according to both clients. You have been warned.
View quoted note →PSA: This is shit advice and a good way to lose all your Bitcoin. There likely will not be a (long lived) chain split regardless of what consensus wins, since this is a soft fork. There could be, but it's not guaranteed.
If you try to trade a "airdrop" you may just find the chains reorged and you sold all your actual Bitcoin, according to both clients. You have been warned.
Bitcoin maximalists now fall in line with captured Core because it is too dangerous to do any thing against it is how every project in human history started to degrade.
Too big too fail out of this chief Bitcoin maxi mouth.
👀
Money of the future hey?
Don't forget to move your Bitcoin on the winning chain to a new address, before moving your Bitcoin on the losing chain. Otherwise you're vulnerable to a replay attack. This also assumes that you know which chain will ultimately win.
Because of the nature of the situation, you must move your legacy coins first to split them, irrespective of whether any chain “wins” or we have persistent dueling forks.
You don’t have to know the ultimate outcome to split safely.
And it also assumes there even will be more than one chain. This was my point above. Since this is not certain, trading the airdrop is super risky.
We're saying the same thing
@jimbocoin 🃏
You do have to know if you want to sell one and consolidate into the winner. Which is the "airdrop" reference I was replying to. Otherwise you sold the winner to buy the loser. Like the bigblockers who sold their BTC and bought BCH with it.
The lowest risk thing to do is nothing. Just HODL and let the network work itself out.
Selling one fork to gain more of the other fork is a higher risk, higher reward option.
It's unanimous 🤝
True
🤣
Bitcoin is money not data storage. whatever you says UASF will win
No it's impossible. Once it's 'in the wild' it's done. In addition... it's purely a small configuration change in the node software. It could be changed to above 83 before Core30, or below 83 after Core30.
If core 'reversed' the default op_return size... what happens to the current Core30 nodes? Do they 'change back?' What if some users don't want to?
Ultimately this isn't about mempool filters or policy really, it's about economic incentives. If users don't like certain transactions on the chain, they should pay more in fees to get their *own* transactions mined instead.
