He notes that he “had hoped could be put out as a miner education piece at OCEAN” but “it never got published” and “That effort failed” so he posted it personally instead (ref: https://x.com/wk057/status/2077444826232955365).
In your role at OCEAN of “Head of Communications”, this sort of correspondence to your customers would seem under your direct purview. OCEAN has communicated about BIP110 previously, “We encourage miners to study BIP-110, form their own view, and signal accordingly” and this post seems a valuable, if not the most valuable, part of that study.
Did you advocate for or against OCEAN publishing this seemingly thoughtful and accurate information for your users/customers? Why or why not? And why wasn’t it ultimately published?
There have been many attempts to agree on official comms regarding BIP110 scenarios that were sadly fruitless.
In the end, what happens next month depends on who you talk to, as well as how miners can prepare for it.
Jason said what he believes to be likely and stated that they're his views in so doing. I didn't have access to what he wrote prior and didn't have the option of approving/disapproving it.
Eh I'm wrong here. I did have access to the linked document above per Jason. I forgot about it, and definitely don't remember if I said anything about it being OK to post or not (and I don't have that authority anyway, despite being "head of comms").
If there is a chain split where one chain is BIP 110 compliant and the other is not, will you trade me you non BIP 110 coins for my BIP 110 coins at a 1:1 ratio? If not, what ratio will you be willing to accept?
I have struggled to understand the urgency behind BIP 110/RDTS. I am not opposed to trying to optimize the types of transactions used in Bitcoin for money/payments. But the pressure of BIP 110 and the urgency has not made sense to me.
I think I could have been a supporter in a world where it was done with less force and what felt like knee jerk reaction.
I'd disagree with your perspective - it has been presented as critical but not urgent.
It was presented on the mailing list back in November. There wasn't anything meaningful by way of push back. Dathon wrote and interated on the client for a while, rebuilding BIP9 which needed to be done anyway. People pushed back on the language in the BIP using the world "legal" too many times in its rationale (I was one of the ones complaining). That was removed. People complained of it being confiscatory - so the UTXO height checker was added. (There are edge cases with pre-committed TXs I'll not bother getting in to here, yes it's possible someone can be in a crazy scenario where they end up generating a UTXO post-activation that becomes temporarily unspendable but the practical answer it that BIP110 is not confiscatory.)
Two consensus issues were found by Lorinc and another dev whose name I forget (sorry). Both of which were fixed.
We're now about 8 months or so down the line. There is clearly a lot of adoption and no one involved in advocating it (at least to my knowledge) is motivated by anything other than a desire to make Bitcoin better. If there really is something wrong with it (it's 37 lines of new code?) then there is a massive appetite for discovering and making public such a development.
All that is to say I don't consider it "rushed".
It's criticality comes simply from those who have drawn a line wrt arbitrary data, saying that if some revolting media makes it in via the apparently sanctioned methods of adding files to Bitcoin that they'd quit not wishing to host such media on their devices.
I agree with this. What's worse is that you can still be a "Bitcoin" and just make someone else deal with running the node on your behalf. That kind of centralizing pressure is unacceptable to me, and anything imminent that improves centralization or prevents something that would undermine it I will always treat as critical.
My memory is that when dathon first proposed it, the timeline was somewhat shorter (2 or 3 months).
8 months does not seem to me to be enough time to build consensus around this. The fact RDTS has changed in response to feedback does not mean it has formed consensus. I suppose we each have our definitions of what constitutes a "rushed" fork, but my question wasn't about whether it was rushed or not, but rather why it is presented as an emergency.
You make a distinction between "critical" and "urgent" but I do think that many supporters of BIP 110 have used language that BIP 110 is required soon. I believe the original version had a sort of emergency activation method.
But I will accept your position that it is not urgent, but rather critical. Can you explain how such a difference looks in real life? It still seems to me that there are many Bitcoiners who aren't sure about BIP 110, why not extend the timeline 6 months to see if you can get us on board?
Let's say a mining cartel (or a single large miner ) were to privately mine BIP 110 (not releasing blocks) at whatever hashrate gives them greatest work (versus public BIP 110) along the entire time -- all just to grief BIP 110.
When this hypothetical mining endeavor eventually broadcasts their blocks, and bexome the public BIP 110 tip, what could and/or would the response be at that point in time?
If BIP110 does not end up with the most cumulative PoW, do you plan to follow the BIP110 chain or plan to regroup and try another fork? Or is it too early to decide?
If BIP110 is not adopted by the industry who resoundingly ignore it then I'd happily say good bye to them rather than capitulate and try something else from within.
Every few cycles Bitcoin is attacked by some megalomaniac character with a savior complex thinking they are uniquely situated to rescue Bitcoin from some existential threat. As we’re living through one of those attacks right now, looking back at the deranged ramblings of a loud loser from the previous fight is quite revealing.
A criticism I have heard about bip-110 is that it seems to invite a chain split scenario. This is a potentially chaotic disruption for the network, to my understanding, that might be brought on by the change.
I'd like to know if you believe the temporary soft fork Bip-110 is the best solution for the perceived problem of spam on chain, and if you could imagine a better one, what would it be?
If it is the best solution, then does a chain split worry you? Why or why not?
I hesitate to appear frivolous, but I really don't care if a split happens. Disruption is sometimes something that has to be tolerated. Stability at all costs is its own tradeoff.
Can you give a broad timeline of what the next year looks like? I'm particularly interested in how you see Bitcoiners navigating the temporary nature of BIP 110. How do you see the next step going?
I think Knots adoption would increase significantly, and hope that Core would reopen the PR for BIP110 so that it didn't make Knots ultimately just end up in the position Core has been in that resulted in all the issues there.
The psyop against arb data mitigation can stop (turns out that's just how a monetary protocol would operate, it isn't censorship now and it never has been).
At the end of the enforcement period I would likely advocate maintaining the consensus limit for 83 byte OP_RETURNs, unless spam filters were actually restored as should have been the case since 2023. The latter is preferred as obviously it makes things more flexible.
Taproot, it remains to be seen. It seems so minimally used that it's hard to not see it as a mistake entirely rather than just adding temporary guard rails as BIP110 does.
CTV might end up getting activated - I doubt it even if it's the one fork that has the potential to happy that BIP110 doesn't temporarily make impossible. I'm not really a fan so would not agitate for it.
Malicious, and hypocritical. Evades the "censorship" of a permissionless p2p network and then subjects all submissions to terms and conditions that are unrealistic for nodes to implement.
Not really. I'm fine with it as it is. 83 byte OP_RETURN could have been permanent with the taproot guard rails temporary but it would just have complicated it further.
Yes, minority UASFs are clearly possible in Bitcoin and thus an attack vector.
If they are actually malicious (obviously BIP110 is not) then we are obligated to URSF against them and ensure there is no risk to miners pretending a threat of that nature is something they can simply ignore as anti-BIP110 people often present as sufficient.
The debate about spam and the RDTS soft fork has been somewhat divisive. Do you have any suggestions for how bitcoiners can get past it and begin to focus on other things.
Also: what do you think those other things might be?
RDTS is reactionary. The division is a result of those whose actions they are reacting to. Defending the network against bad actors is not something anyone should be apologizing for.
Bitcoiners coming together again would be lovely but it's somewhat unrealistic if we take Bitcoin seriously as a anti-government movement that somehow manages to not get infiltrated and subverted from within.
division is a result of those whose actions they are reacting to
I also don't see people apologizing, nor do I think they should. however it seems unlikely to me that we will defend ourselves from the state when a chunk of the people who are most likely to self custody and use bitcoin are all pissed at each other.
(it is my impression that it is only the people who are pretty deep in Bitcoin who have been concerned with the debate about spam and BIP 110)
Perhaps you are right that is is unrealistic that we will come together again. I'd at least like to see people focus on self-custody again and resisting things like kyc/aml.
My focus is always on decentralization at the node level. To me the approach taken by Core (and the industry in being largely unconcerned with it) represented a deviation from that priority and everything else is downstream of that. Decentralized mining/self custody/sovereign MoE usage (no KYC/AML etc) are all over if most people aren't doing this stuff with their own nodes.
(i asked this elsewhere, but it's relevant here) why not just do smaller blocks? that would make it easier for people to run nodes and we clearly aren't pressed for blockspace...
Neither, though you can assume the former. It's stuff that'd make me say "I don't want to run a node anymore" or even "I expect other people will trash their node over this".
You've characterized OP_RETURN data carrier as "file storage" multiple times now. Is there any support in Bitcoin or Bitcoin Core for actually storing or viewing "files" here in your mind?
So how is it "file storage"? If it's just possible to embed a file (that you need a file carver to extract), why don't you characterize Knots the same way, given that it's trivial to embed a contiguous TIFF in standard Knots txs?
There isn't one I'm interested in really. I don't really think Bitcoin can work properly outside of Core-forks (or Knots-forks if it ends up becoming the reference). Too much risk of accidental splits like with BTCD. Libbitcoin is celebrated for having some custom design that is optimized for making UTXO bloat less of a problem, but I'm not holding my breath.
Do you believe and resonate with the argument that there is a big difference between continuous data and segmented data when holding illegal content (in the given jurisdiction)?
Not especially. It's relevant (there's a reason op_return data is contiguous - because it's intentionally file storage) but not the be-all-and-end-all (hence BIP110 targeting OP_IF in taproot which is being used for non-contiguous file storage).
The contiguity speaks to the undeniable fact of it being very obviously for a specific purpose rather than a hack job in taproot spends that betray the fact that it was not intended use.
Deferring to their miners can mean a few things, difficult to know. It certainly means that the fork has the potential to succeed (which I still believe is the likely outcome).
On face value it's certainly sensible for a pool in particular to make sure they have plans for contingency if there ends up being chaos around consensus rules otherwise they risk retribution from their miners/shareholders.
You can go further and read into circumstancial aspects to try and read if this implies some kind of subtle support or the opposite.
The fact that they default to assuming "no" votes for non-participants implies a bias against, but again, the approach of deferral is ultimately appropriate. It just appropriately goes to the network, not miners :P
The irony isn't lost on me, the biggest bip110er managed to create a temporary username fork during the AMA... and then reorged back to the original account
The symbolism was almost too perfect 😂🤣🤣
Perhaps network effects are more persuasive than we sometimes admit
I would support any effort in that regard, but it's not an alternative to BIP110. Big OP_RETURNs and OP_IF in taproot are still vulnerabilities that need closing.
Jason Hughes, who is VP of engineering at OCEAN, drafted a “BIP110 / RDTS: What Miners Need to Know”, a 9 page document to help keep miners, including OCEAN customers/users, informed about things they may need to remain aware of as BIP110 plays out (ref: https://docs.google.com/document/d/14DfMSVYBHTHIOmW32JTOR6BAP7AITbinvrhl8rJuvvc/edit?tab=t.0).
He notes that he “had hoped could be put out as a miner education piece at OCEAN” but “it never got published” and “That effort failed” so he posted it personally instead (ref: https://x.com/wk057/status/2077444826232955365).
In your role at OCEAN of “Head of Communications”, this sort of correspondence to your customers would seem under your direct purview. OCEAN has communicated about BIP110 previously, “We encourage miners to study BIP-110, form their own view, and signal accordingly” and this post seems a valuable, if not the most valuable, part of that study.
Did you advocate for or against OCEAN publishing this seemingly thoughtful and accurate information for your users/customers? Why or why not? And why wasn’t it ultimately published?
There have been many attempts to agree on official comms regarding BIP110 scenarios that were sadly fruitless.
In the end, what happens next month depends on who you talk to, as well as how miners can prepare for it.
Jason said what he believes to be likely and stated that they're his views in so doing. I didn't have access to what he wrote prior and didn't have the option of approving/disapproving it.
Jason says this is not true:
https://twiiit.com/i/status/2078216215072555315
Eh I'm wrong here. I did have access to the linked document above per Jason. I forgot about it, and definitely don't remember if I said anything about it being OK to post or not (and I don't have that authority anyway, despite being "head of comms").
has there been any communication at all sent out to ocean miners/posted through ocean official comms about preparing for it?
https://twiiit.com/wk057/status/2077444826232955365
he doesn't answer this particular question though
Thanks all, I'm off.
Thank you for the time!
If there is a chain split where one chain is BIP 110 compliant and the other is not, will you trade me you non BIP 110 coins for my BIP 110 coins at a 1:1 ratio? If not, what ratio will you be willing to accept?
No thanks, too close to gambling which clouds judgement. I have no idea what happens next month and neither does anyone else.
so... you didn't put your sats where your mouth is, I take it?
https://beta.predyx.com/market/will-bip-110-activate-and-be-enforced-on-bitcoin-by-sept-1-2026-1770282509?ref=PREDYXTZ0UUNOP
Doesn't seem much like gambling if you are planning on leaving the non BIP 110 anyway.
#1526729
Here is exactly what will happen next month. You clowns will fork yourself off into a shitcoin with a stalled blockchain.
Exactly like we told you would happen three years ago while you were all in a delusional state of denial about policy vs. consensus.
Enjoy trying to gaslight your way out of this one.
I stopped reading there as neither of us actually know.
you shoulda read the rest it was pretty short
I have struggled to understand the urgency behind BIP 110/RDTS. I am not opposed to trying to optimize the types of transactions used in Bitcoin for money/payments. But the pressure of BIP 110 and the urgency has not made sense to me.
I think I could have been a supporter in a world where it was done with less force and what felt like knee jerk reaction.
Can you give me the case for the urgency?
I'd disagree with your perspective - it has been presented as critical but not urgent.
It was presented on the mailing list back in November. There wasn't anything meaningful by way of push back. Dathon wrote and interated on the client for a while, rebuilding BIP9 which needed to be done anyway. People pushed back on the language in the BIP using the world "legal" too many times in its rationale (I was one of the ones complaining). That was removed. People complained of it being confiscatory - so the UTXO height checker was added. (There are edge cases with pre-committed TXs I'll not bother getting in to here, yes it's possible someone can be in a crazy scenario where they end up generating a UTXO post-activation that becomes temporarily unspendable but the practical answer it that BIP110 is not confiscatory.)
Two consensus issues were found by Lorinc and another dev whose name I forget (sorry). Both of which were fixed.
We're now about 8 months or so down the line. There is clearly a lot of adoption and no one involved in advocating it (at least to my knowledge) is motivated by anything other than a desire to make Bitcoin better. If there really is something wrong with it (it's 37 lines of new code?) then there is a massive appetite for discovering and making public such a development.
All that is to say I don't consider it "rushed".
It's criticality comes simply from those who have drawn a line wrt arbitrary data, saying that if some revolting media makes it in via the apparently sanctioned methods of adding files to Bitcoin that they'd quit not wishing to host such media on their devices.
I agree with this. What's worse is that you can still be a "Bitcoin" and just make someone else deal with running the node on your behalf. That kind of centralizing pressure is unacceptable to me, and anything imminent that improves centralization or prevents something that would undermine it I will always treat as critical.
My memory is that when dathon first proposed it, the timeline was somewhat shorter (2 or 3 months).
8 months does not seem to me to be enough time to build consensus around this. The fact RDTS has changed in response to feedback does not mean it has formed consensus. I suppose we each have our definitions of what constitutes a "rushed" fork, but my question wasn't about whether it was rushed or not, but rather why it is presented as an emergency.
You make a distinction between "critical" and "urgent" but I do think that many supporters of BIP 110 have used language that BIP 110 is required soon. I believe the original version had a sort of emergency activation method.
But I will accept your position that it is not urgent, but rather critical. Can you explain how such a difference looks in real life? It still seems to me that there are many Bitcoiners who aren't sure about BIP 110, why not extend the timeline 6 months to see if you can get us on board?
Where is "adding files" (much less viewing them!) a feature of Bitcoin or Bitcoin Core?
Because I can "add files" just as easily by making a transaction include a valid and contiguous TIFF file even with Knots-policy-standard txs.
yet another similarity to Roger Ver...
Which bitcoin open source projects have you contributed to?
As a dev? Technically DATUM and Knots but that'd give you the wrong impression, I'm a noob.
Let's say a mining cartel (or a single large miner ) were to privately mine BIP 110 (not releasing blocks) at whatever hashrate gives them greatest work (versus public BIP 110) along the entire time -- all just to grief BIP 110.
When this hypothetical mining endeavor eventually broadcasts their blocks, and bexome the public BIP 110 tip, what could and/or would the response be at that point in time?
Great question bro, surely a massive timechain reorg couldn't happen under bip110 🤣🤣
If BIP110 does not end up with the most cumulative PoW, do you plan to follow the BIP110 chain or plan to regroup and try another fork? Or is it too early to decide?
If BIP110 is not adopted by the industry who resoundingly ignore it then I'd happily say good bye to them rather than capitulate and try something else from within.
Looking forward to holding you to that.
How do you spend your free time? Do you have any interesting hobbies?
No free time, just flip between working, parenting, and basic sustenance (food/sleep etc). There really isn't much else!
Do you also see the obvious similarity between Luke Dashjr and Roger Ver?
#1525909
One fought against decentralization, the other fights to support it.
So I guess they are alike in that they have both fought in their lives, and that fight involved Bitcoin.
ah, wrong link.
#1525907
I support BIP110, I didn't support block size increases. You can hate Luke/love Roger all you want, it makes no difference.
Both are equally ridiculous and opponents of Bitcoin, and its astonishing to me that you can't see the overlap
Using this account cos switched to other device
I've checked with Mechanic out of band and this is also him
Wen CLINK offers for mining payouts?
A criticism I have heard about bip-110 is that it seems to invite a chain split scenario. This is a potentially chaotic disruption for the network, to my understanding, that might be brought on by the change.
I'd like to know if you believe the temporary soft fork Bip-110 is the best solution for the perceived problem of spam on chain, and if you could imagine a better one, what would it be?
If it is the best solution, then does a chain split worry you? Why or why not?
I hesitate to appear frivolous, but I really don't care if a split happens. Disruption is sometimes something that has to be tolerated. Stability at all costs is its own tradeoff.
So would you consider the disruption is a feature of the change, and something to be desired?
I'm essentially still asking the first question, whether you believe bip-110 is the best solution for the perceived problem of spam on chain.
Also, I noticed you didn't attach a lightning wallet, which, if you did, I could zap you real sats.
Let's imagine that BIP 110 is successful.
Can you give a broad timeline of what the next year looks like? I'm particularly interested in how you see Bitcoiners navigating the temporary nature of BIP 110. How do you see the next step going?
I think Knots adoption would increase significantly, and hope that Core would reopen the PR for BIP110 so that it didn't make Knots ultimately just end up in the position Core has been in that resulted in all the issues there.
The psyop against arb data mitigation can stop (turns out that's just how a monetary protocol would operate, it isn't censorship now and it never has been).
At the end of the enforcement period I would likely advocate maintaining the consensus limit for 83 byte OP_RETURNs, unless spam filters were actually restored as should have been the case since 2023. The latter is preferred as obviously it makes things more flexible.
Taproot, it remains to be seen. It seems so minimally used that it's hard to not see it as a mistake entirely rather than just adding temporary guard rails as BIP110 does.
CTV might end up getting activated - I doubt it even if it's the one fork that has the potential to happy that BIP110 doesn't temporarily make impossible. I'm not really a fan so would not agitate for it.
What do you think of Slipstream?
Malicious, and hypocritical. Evades the "censorship" of a permissionless p2p network and then subjects all submissions to terms and conditions that are unrealistic for nodes to implement.
I think Slipstream needs competition. Low entropy TX can get RBF'd after broadcasting so there needs to be a way to put a TX privately into a block.
How would you (or not) address it? As node runner as well as node client architect?
In your view, does BIP110 not go far enough? Are there restrictions you wish it had that it doesn't?
Not really. I'm fine with it as it is. 83 byte OP_RETURN could have been permanent with the taproot guard rails temporary but it would just have complicated it further.
What's the minimum hashrate BIP 110 needs to be a sustainable chain?
No one knows, there's plenty of conjecture out there about it.
Hashrate is so centralized among the few FPPS pools that it's more about "who" than "how much" anyway.
If BIP 110 ends up attracting the majority of hashrate, do you think other soft forks will attempt to use the same activation method?
I could see a quantum fork trying to get integrated to Bitcoin this way.
Do you see any risks if most soft forks proceed with much lower signalling rates than past forks?
Yes, minority UASFs are clearly possible in Bitcoin and thus an attack vector.
If they are actually malicious (obviously BIP110 is not) then we are obligated to URSF against them and ensure there is no risk to miners pretending a threat of that nature is something they can simply ignore as anti-BIP110 people often present as sufficient.
The debate about spam and the RDTS soft fork has been somewhat divisive. Do you have any suggestions for how bitcoiners can get past it and begin to focus on other things.
Also: what do you think those other things might be?
RDTS is reactionary. The division is a result of those whose actions they are reacting to. Defending the network against bad actors is not something anyone should be apologizing for.
Bitcoiners coming together again would be lovely but it's somewhat unrealistic if we take Bitcoin seriously as a anti-government movement that somehow manages to not get infiltrated and subverted from within.
I also don't see people apologizing, nor do I think they should. however it seems unlikely to me that we will defend ourselves from the state when a chunk of the people who are most likely to self custody and use bitcoin are all pissed at each other.
(it is my impression that it is only the people who are pretty deep in Bitcoin who have been concerned with the debate about spam and BIP 110)
Perhaps you are right that is is unrealistic that we will come together again. I'd at least like to see people focus on self-custody again and resisting things like kyc/aml.
My focus is always on decentralization at the node level. To me the approach taken by Core (and the industry in being largely unconcerned with it) represented a deviation from that priority and everything else is downstream of that. Decentralized mining/self custody/sovereign MoE usage (no KYC/AML etc) are all over if most people aren't doing this stuff with their own nodes.
(i asked this elsewhere, but it's relevant here) why not just do smaller blocks? that would make it easier for people to run nodes and we clearly aren't pressed for blockspace...
I want to do that too. But it doesn't do anything about the concerns about unacceptable media storage.
when you say "unacceptable media storage" do you mean illegal media or a resource issue (too much data)?
Neither, though you can assume the former. It's stuff that'd make me say "I don't want to run a node anymore" or even "I expect other people will trash their node over this".
What's the most surprising thing you've learned advocating for BIP110?
Not much. I'm just relearning what I learnt in 2017 that many people seem to have forgotten (or never understood in the first place).
You've characterized OP_RETURN data carrier as "file storage" multiple times now. Is there any support in Bitcoin or Bitcoin Core for actually storing or viewing "files" here in your mind?
No, Bitcoin Core isn't literally a media player (yet?)
So how is it "file storage"? If it's just possible to embed a file (that you need a file carver to extract), why don't you characterize Knots the same way, given that it's trivial to embed a contiguous TIFF in standard Knots txs?
Other than Core and Knots, what Bitcoin implementation is most interesting to you?
There isn't one I'm interested in really. I don't really think Bitcoin can work properly outside of Core-forks (or Knots-forks if it ends up becoming the reference). Too much risk of accidental splits like with BTCD. Libbitcoin is celebrated for having some custom design that is optimized for making UTXO bloat less of a problem, but I'm not holding my breath.
BTCD already powers most of the Lightning Network and test vectors are no different than one version of Core upgrading to another...
Every new version of Core or fork of core incurs the same risk.
Case in point, Core's database backends (Berkeley DB and LevelDB) in 2013 caused a temporary chain split.
Diversity of implementations keep whoopsies small when they do happen, rather than most of the network downloading a default
It's a tradeoff, I'm not trying to bash BTCD, and yes you're right, different versions of the same implementation can cause splits too.
Why are you so soft that you block everyone on X that disagrees with you?
I don't. Usually the people I block are spreading obvious misinfo or being vulgar.
That's a very Lukian move. Anything you disagree with is just "obvious misinfo". You blocked me despite my verifiable and provable claims.
Do you believe and resonate with the argument that there is a big difference between continuous data and segmented data when holding illegal content (in the given jurisdiction)?
Not especially. It's relevant (there's a reason op_return data is contiguous - because it's intentionally file storage) but not the be-all-and-end-all (hence BIP110 targeting OP_IF in taproot which is being used for non-contiguous file storage).
The contiguity speaks to the undeniable fact of it being very obviously for a specific purpose rather than a hack job in taproot spends that betray the fact that it was not intended use.
How far are you willing to push this before you admit it's doing more harm to Bitcoin than good?
what's the signal that tells you you've gone too far?
Eh, seems too leading a question to be considered genuine. I'm only supporting BIP110 because I believe it to be necessary and good.
Conviction isn't evidence. Every controversial proposal in Bitcoin's history had supporters who were convinced it was necessary
That's not necessarily true...Bitcoin is obviously a prime target for intentional sabotage given its disruptive qualities.
Pizza or tacos?
Carnivore
What do you think of Foundry's thing telling their hashers to vote:
Deferring to their miners can mean a few things, difficult to know. It certainly means that the fork has the potential to succeed (which I still believe is the likely outcome).
On face value it's certainly sensible for a pool in particular to make sure they have plans for contingency if there ends up being chaos around consensus rules otherwise they risk retribution from their miners/shareholders.
You can go further and read into circumstancial aspects to try and read if this implies some kind of subtle support or the opposite.
The fact that they default to assuming "no" votes for non-participants implies a bias against, but again, the approach of deferral is ultimately appropriate. It just appropriately goes to the network, not miners :P
https://twiiit.com/BitcoinNewsCom/status/2078129671728722053
What were you doing before bitcoin? What do you imagine you would be working on if not for bitcoin?
Music before, not sure what I would move on to post-Bitcoin. I'd pray on it and see what appeared.
What's something you believe that practically no one else does?
That US politics is a pantomime.
I believe that... political actors are bad actors. In both senses.
The irony isn't lost on me, the biggest bip110er managed to create a temporary username fork during the AMA... and then reorged back to the original account
The symbolism was almost too perfect 😂🤣🤣
Perhaps network effects are more persuasive than we sometimes admit
There have been many attempts with contentious forks over the years to try to “take control” of Bitcoin.
What makes you believe this attempt will be successful, this time?
Why not just reduce the block size?
I would support any effort in that regard, but it's not an alternative to BIP110. Big OP_RETURNs and OP_IF in taproot are still vulnerabilities that need closing.
So. What's new?
nm bro, u?
🫂