Blockstream employee delivers the bad news for BitcoinCore coin.

[hv_]

The really bad news is this here:

https://github.com/bitcoin/bitcoin/pull/10982

Blockstream really wants to isolate and keep core power centralized, rather to compromise and allow multiple client implementation.

Will all follow by blindly upgade to 0.15 ?

No. Core is forking to an altcoin. They try to pretend it's not though.

If you count just all the sheep installing whatever comes from core the network split might be huge.

Core is not able to collude with NYA (Hongkong,..) , they rather want to go the EGO and hard trip.

[1713516677]

1713516677

[1713516677]

1713516677

[1713516677]

1713516677

[1713516677]

1713516677

[-ck]

The really bad news is this here:

https://github.com/bitcoin/bitcoin/pull/10982

Blockstream really wants to isolate and keep core power centralized, rather to compromise and allow multiple client implementation.

Will all follow by blindly upgade to 0.15 ?

No, you're really not understanding what that's doing. There would be serious partitioning and disconnects with bans with multiple incompatible clients out there leading to a complete mess of a network.

The whole purpose of this PR is to ensure that when the fork happens, it happens cleanly. The goal is to make nodes not ban each other, not have cross talk between chains, and avoid partitioning the network. By disconnecting (not banning) peers with these service bits, we are making it easier and more likely for those peers to be able to connect to other peers that will be using the same consensus rules, i.e. btc1 peers are more likely to make connections to other btc1 peers. This minimizes the risk of network partitioning following the fork as the btc1 nodes will be connected to each other.

In the PR thread, people mentioned that this will encourage nodes to lie about what their version is and the service they support. This behavior would actually be detrimental to btc1 peers. The service bit is used for preferential peering. By removing their service bit, they will be less likely to connect to other btc1 peers and more likely to end up partitioned from the rest of the btc1 network following the fork. In order to avoid that, it would be best for them to use the service bit for preferential peering and maintain connections to other btc1 nodes before the fork so as to have the same connections after the fork.

Lastly, the PR ensures that the network topology changes gradually. At the time of the fork, what will happen is that the network topology will change suddenly and possibly fracture the network into multiple partitions. By disconnecting the peers that we know will be following different consensus rules than us, we are ensuring that the network topology will gradually shift from a mixed pool of nodes, to two pools of nodes mostly separated, but still connected to each other. At the time of the fork, this will split in two instead of into multiple pieces.

[hv_]

The really bad news is this here:

https://github.com/bitcoin/bitcoin/pull/10982

Blockstream really wants to isolate and keep core power centralized, rather to compromise and allow multiple client implementation.

Will all follow by blindly upgade to 0.15 ?

No, you're really not understanding what that's doing. There would be serious partitioning and disconnects with bans with multiple incompatible clients out there leading to a complete mess of a network.

The whole purpose of this PR is to ensure that when the fork happens, it happens cleanly. The goal is to make nodes not ban each other, not have cross talk between chains, and avoid partitioning the network. By disconnecting (not banning) peers with these service bits, we are making it easier and more likely for those peers to be able to connect to other peers that will be using the same consensus rules, i.e. btc1 peers are more likely to make connections to other btc1 peers. This minimizes the risk of network partitioning following the fork as the btc1 nodes will be connected to each other.

In the PR thread, people mentioned that this will encourage nodes to lie about what their version is and the service they support. This behavior would actually be detrimental to btc1 peers. The service bit is used for preferential peering. By removing their service bit, they will be less likely to connect to other btc1 peers and more likely to end up partitioned from the rest of the btc1 network following the fork. In order to avoid that, it would be best for them to use the service bit for preferential peering and maintain connections to other btc1 nodes before the fork so as to have the same connections after the fork.

Lastly, the PR ensures that the network topology changes gradually. At the time of the fork, what will happen is that the network topology will change suddenly and possibly fracture the network into multiple partitions. By disconnecting the peers that we know will be following different consensus rules than us, we are ensuring that the network topology will gradually shift from a mixed pool of nodes, to two pools of nodes mostly separated, but still connected to each other. At the time of the fork, this will split in two instead of into multiple pieces.

I fully understand what Matt & BS are about. They WANT to split from btc1 - and so make btc1 and the 2x to be an alt..

[franky1]

The really bad news is this here:

https://github.com/bitcoin/bitcoin/pull/10982

Blockstream really wants to isolate and keep core power centralized, rather to compromise and allow multiple client implementation.

Will all follow by blindly upgade to 0.15 ?

No, you're really not understanding what that's doing. There would be serious partitioning and disconnects with bans with multiple incompatible clients out there leading to a complete mess of a network.

The whole purpose of this PR is to ensure that when the fork happens, it happens cleanly. The goal is to make nodes not ban each other, not have cross talk between chains, and avoid partitioning the network. By disconnecting (not banning) peers with these service bits, we are making it easier and more likely for those peers to be able to connect to other peers that will be using the same consensus rules, i.e. btc1 peers are more likely to make connections to other btc1 peers. This minimizes the risk of network partitioning following the fork as the btc1 nodes will be connected to each other.

I fully understand what Matt & BS are about. They WANT to split from btc1 - and so make btc1 and the 2x to be an alt..

yep a direct unilateral split.
the real funny part is this all makes more sense from a dictionary point of view if you swap the words

ban :-> suspend
disconnect:->ban

because a ban is more official/permanent. where as a suspend is temporary

which currently is confusing for some because cores current 'ban' is temporary(minutes/hours). where as their proposed 'disconnect' is more permanent(1 year, possibly more)

meaning core dont want to temporarily avoid their opposition. they want to permanently avoid communicating with their opposition.
again this is another attempt of core controlling the network and again avoid bitcoins built in consensus/orphaning mechanism from allowing users to decide when/if the network should move to 2mb baseblock. by forcing the core fanboys to not even have a free choice.

it would be so much easier for core to just add the 2mb base block code into their implementation and just allow the network to evolve. instead of forcing their stifled, 1mb base block, Neanderthal mindset onto their fanboys

being conservative is not about forward looking innovation. is about devolving, and preserving things. which will actually end up chocking the network

it seems people prefer to trust devs more than reading code, reading a dictionary and reading between the lines.. core are becoming more ridiculous with every passing year.

in short.
core: stop wasting time and lots of lines of code to avoid evolving the network by splitting the community. and instead just add the lines of code that add 2mb base blocks and unite the community!!!
USE BITCOINS NETWORK CONSENSUS MECHANISM.. STOP AVOIDING IT!! stop working around consensus

[neurotypical]

The really bad news is this here:

https://github.com/bitcoin/bitcoin/pull/10982

Blockstream really wants to isolate and keep core power centralized, rather to compromise and allow multiple client implementation.

Will all follow by blindly upgade to 0.15 ?

It's just how it's supposed to be. You can't accept protocol-changing nodes trying to change consensus rules. Satoshi warned us about that:

The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime.  Because of that, I wanted to design it to support every possible transaction type I could think of.  The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time.  It would have been an explosion of special cases.  The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates.  The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.

The script is actually a predicate.  It's just an equation that evaluates to true or false.  Predicate is a long and unfamiliar word so I called it script.

The receiver of a payment does a template match on the script.  Currently, receivers only accept two templates: direct payment and bitcoin address.  Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them.  All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.

The design supports a tremendous variety of possible transaction types that I designed years ago.  Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc.  If Bitcoin catches on in a big way, these are things we'll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.

I don't believe a second, compatible implementation of Bitcoin will ever be a good idea.  So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network.  The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.

It's hard enough maintaining backward compatibility while upgrading the network without a second version locking things in.  If the second version screwed up, the user experience would reflect badly on both, although it would at least reinforce to users the importance of staying with the official version.

[franky1]

It's just how it's supposed to be. You can't accept protocol-changing nodes trying to change consensus rules. Satoshi warned us about that:

The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime.  Because of that, I wanted to design it to support every possible transaction type I could think of.  The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time.  It would have been an explosion of special cases.  The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates.  The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.

The script is actually a predicate.  It's just an equation that evaluates to true or false.  Predicate is a long and unfamiliar word so I called it script.

The receiver of a payment does a template match on the script.  Currently, receivers only accept two templates: direct payment and bitcoin address.  Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them.  All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.

The design supports a tremendous variety of possible transaction types that I designed years ago.  Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc.  If Bitcoin catches on in a big way, these are things we'll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.

I don't believe a second, compatible implementation of Bitcoin will ever be a good idea.  So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network.  The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.

It's hard enough maintaining backward compatibility while upgrading the network without a second version locking things in.  If the second version screwed up, the user experience would reflect badly on both, although it would at least reinforce to users the importance of staying with the official version.

satoshi as one man said it was hard for him to monitor, peer review and bug fix multiple versions.

however if you actually check history. in satoshi's day there were atleast 12 different codebases.
most notably, while satoshi was working on his codebase on a different platform, gavin was working on a codebase on github. and that same githb codebase of gavins evolved to be what is now core..

meaning core were and are not using satoshi's codebase..

secondly satoshi knew at that very point by saying those words that if he continued with that mindset he would become the leader/ruler/decider of bitcoin if there was only one codebase. which actually was his wakeup call to pull back and allow the community to diversify and keep bitcoin open with no controller.

bitcoin has a mechanism that prevents an implementation just taking over, its called consensus.. meaning the majority of people running a certain rule win.. changes only occur when a certain ruleset is used by the majority.

core try bypassing this by slipping in changes under the fense. which is where people get confused and afraid to actually use consensus and instead think consensus is bad. thus basically handing control over to one party because they think that is what satoshi wanted.

to me its all just twisting the facts to make it sound like satoshi was advocating dominant control of bitcoin by the BScartel simple from bscartels fanboys thinking satoshi wanted just one implementation. when the actual context is that one man cannot monitor and maintain more than one implementation at a time without going nuts.

bitcoins consensus/orphaning mechanism is there for a reason.. avoiding it and trying to slip code in without using it while also REKTing anything else that wants to actually use all of bitcoins features.. is the opposite of bitcoins ethos

[keithers]

Meanwhile Bitcoin Cash like: https://zander.github.io/posts/bcc-fees/

 

Hold your Bitcoin Cash. Selling could be the worst mistake of your life.

Nobody is using Bitcoin Cash other than people making transactions to dump it for BCC. Nobody but some idiots would want to have Bitcoin nodes centralized inside china. Nobody wants a coin that is mined by "ViaBTC + "other"" (BitmainCoin).

Accept defeat already. Bitcoin Crash was DOA. It may have artificial pumps here and there like ETC: doesn't matter.

Ya no one uses it after one week, wow its dead LOL

You sound like someone who dumped your BCH early and now realize you goofed up like tons of others.

Bitcoin Cash IS the real Bitcoin now and will only get bigger and stronger as the weeks go by.

Did you forget to take your meds? If he dumped BCash when it was 0.25 he could have made a ton of money, now BCash is 0.10 and struggling to keep there. A coin that is worth 10 times less than BTC and is not accepted anywhere and basically nobody cares about it but some Roger Ver fanboys is not the real Bitcoin, sorry to break your bubble.

Everyone that hasn't sold out yet is just waiting for the next pump to liquidate their BCash. It's over.

While you may end up being right that bitcoin cash may not make it long term, don't you think 8 days in, is WAY too early to say.  Most coins take way way longer from inception to even being available on any major exchange.  Everyone is acting like Bitcoin Cash has been around for like 5 years and it is dying...it's barely been over a week...

[whaawh]

Meanwhile Bitcoin Cash like: https://zander.github.io/posts/bcc-fees/

 

Hold your Bitcoin Cash. Selling could be the worst mistake of your life.

Nobody is using Bitcoin Cash other than people making transactions to dump it for BCC. Nobody but some idiots would want to have Bitcoin nodes centralized inside china. Nobody wants a coin that is mined by "ViaBTC + "other"" (BitmainCoin).

Accept defeat already. Bitcoin Crash was DOA. It may have artificial pumps here and there like ETC: doesn't matter.

Ya no one uses it after one week, wow its dead LOL

You sound like someone who dumped your BCH early and now realize you goofed up like tons of others.

Bitcoin Cash IS the real Bitcoin now and will only get bigger and stronger as the weeks go by.

Did you forget to take your meds? If he dumped BCash when it was 0.25 he could have made a ton of money, now BCash is 0.10 and struggling to keep there. A coin that is worth 10 times less than BTC and is not accepted anywhere and basically nobody cares about it but some Roger Ver fanboys is not the real Bitcoin, sorry to break your bubble.

Everyone that hasn't sold out yet is just waiting for the next pump to liquidate their BCash. It's over.

While you may end up being right that bitcoin cash may not make it long term, don't you think 8 days in, is WAY too early to say.  Most coins take way way longer from inception to even being available on any major exchange.  Everyone is acting like Bitcoin Cash has been around for like 5 years and it is dying...it's barely been over a week...

It seems that Bitcoin cash is beginning to support the artificial. But why this is done is not clear. Perhaps this is another manipulation, with the help of which he wants to warm his hands very well. I would advise everyone to be more careful.

[cashclash]

https://medium.com/@rusty_lightning/dear-bitcoin-im-sorry-fees-will-rise-b002b1449054

Looks like Blockstream, leaders of BitcoinCore coin (BTC) are warning of an impending fee disaster that could cripple their chain.

Whatever you do, hold onto your BitcoinCash. Things are about to get a little crazy.

Edit: Bitcoin Cash promises cheaper and cheaper fees: https://zander.github.io/posts/bcc-fees/

OP Tittle fiercely attacks BitCoincore team
has link to medium space link
has empty emphasizing space between sentences
has by the looks, prophetic warnings of crazy fee disasters
has bad coin hack edit:promise of good news hodl 'forever'

.

imagine i would say nay, BTC has been grand and come so far and there is zero content or anything personal but an external link in your OP, therefore Sir you have earned the same tittle you try to sell, Ignore it is for you

cheers

[-ck]

I fully understand what Matt & BS are about. They WANT to split from btc1 - and so make btc1 and the 2x to be an alt..

Uh hang on, did you expect core to support the 2x fork? Absolutely none of the core developers have ever officially supported it.

This is why I'm far more concerned about the 2x part of segwit2x and not the segwit activation thanks to BIP91 making it compatible. Nothing will make core compatible with the 2x component so it's now a standoff between core and the bulk of the miners. We'll see if the miners follow through with 2x or if a significant number now drop off their NYA support.

[BillyBobZorton]

It's just how it's supposed to be. You can't accept protocol-changing nodes trying to change consensus rules. Satoshi warned us about that:

The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime.  Because of that, I wanted to design it to support every possible transaction type I could think of.  The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time.  It would have been an explosion of special cases.  The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates.  The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.

The script is actually a predicate.  It's just an equation that evaluates to true or false.  Predicate is a long and unfamiliar word so I called it script.

The receiver of a payment does a template match on the script.  Currently, receivers only accept two templates: direct payment and bitcoin address.  Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them.  All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.

The design supports a tremendous variety of possible transaction types that I designed years ago.  Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc.  If Bitcoin catches on in a big way, these are things we'll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.

I don't believe a second, compatible implementation of Bitcoin will ever be a good idea.  So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network.  The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.

It's hard enough maintaining backward compatibility while upgrading the network without a second version locking things in.  If the second version screwed up, the user experience would reflect badly on both, although it would at least reinforce to users the importance of staying with the official version.

satoshi as one man said it was hard for him to monitor, peer review and bug fix multiple versions.

however if you actually check history. in satoshi's day there were atleast 12 different codebases.
most notably, while satoshi was working on his codebase on a different platform, gavin was working on a codebase on github. and that same githb codebase of gavins evolved to be what is now core..

meaning core were and are not using satoshi's codebase..

secondly satoshi knew at that very point by saying those words that if he continued with that mindset he would become the leader/ruler/decider of bitcoin if there was only one codebase. which actually was his wakeup call to pull back and allow the community to diversify and keep bitcoin open with no controller.

bitcoin has a mechanism that prevents an implementation just taking over, its called consensus.. meaning the majority of people running a certain rule win.. changes only occur when a certain ruleset is used by the majority.

core try bypassing this by slipping in changes under the fense. which is where people get confused and afraid to actually use consensus and instead think consensus is bad. thus basically handing control over to one party because they think that is what satoshi wanted.

to me its all just twisting the facts to make it sound like satoshi was advocating dominant control of bitcoin by the BScartel simple from bscartels fanboys thinking satoshi wanted just one implementation. when the actual context is that one man cannot monitor and maintain more than one implementation at a time without going nuts.

bitcoins consensus/orphaning mechanism is there for a reason.. avoiding it and trying to slip code in without using it while also REKTing anything else that wants to actually use all of bitcoins features.. is the opposite of bitcoins ethos

Everyone is free to make their own Bitcoin client. Bitcoin Knots has existed for a long time for example. As long as it doesn't change the network rules, it's ok  (XT, Classic, segwit2x, Unlimited, Cash... changes the rules). You can hardfork into an altcoin Bitcoin Cash style, just don't pretend it's Bitcoin.

[franky1]

Everyone is free to make their own Bitcoin client. Bitcoin Knots has existed for a long time for example. As long as it doesn't change the network rules, it's ok  (XT, Classic, segwit2x, Unlimited, Cash... changes the rules). You can hardfork into an altcoin Bitcoin Cash style, just don't pretend it's Bitcoin.

everyone is free to make their own bitcoin client

but who says only core get to choose the rules!!

what it should be is that anyone can make a client.. and the rules only change when the community follow a majority client of a certain rule.
this does not mean that client then suddenly becomes the god code forever and always after that no matter what.

in the future core devs may move onto different projects and new better devs turn up using different clients.. this does not mean we should still remain with core for brand sake even if their pool of devs have diluted down to script kiddies and spell checkers

if a different client offers better code and better long term view of keeping bitcoins longevity going. people should be free to follow it.

trying to make core the only rule decider .. or more realistically the rule change preventer.. then bitcoins ethos has been destroyed and you might aswell call core the IMF..

if you think core should be lord and master forever and always even if gmax, wuille and others moved away and only coded for hyperledger.. then  you have missed logic, technical innovation and diversity principles..

please look passed your brown nose of brand "core".. and think about bitcoin..
its simple anyone can make a client that fits the current rules but can also include (future activating) features that may offer something better in the future.. let people use it. if it fails to function it fails.. diversity of different brands and codebases holding current ruleset will keep the network alive..
if the future feature fails to gain consensus.. then it fails to gain consensus.. diversity of different brands and codebases holding current ruleset will keep the network alive with the current ruleset

if the future feature gains consensus.. then it gains consensus.. the diversity then has to adapt to the new ruleset to remain a diverse part of the network by the time the feature activation period occurs.. meaning all the brands are then on the same equal level playing ground.

what should not happen is one small group become gods.. as that is not diverse, that is not decentralised and that is certainly not the bitcoin ethos.

stop being afraid of bitcoins mechanism.. stop avoiding using bitcoins consensus mechanism and stop screaming doomsdays of the consensus mechanism purely due to brand dictatorship desire.

[keithers]

So do you guys think we are headed for another hard fork again with segwit2x.  Theoretically this could result in a third form of bitcoin right?  While it was pretty cool getting airdropped what is the equivalent of free money, I don't really like the idea of three different bitcoins. The entry barrier for newbies just becomes that much more confusing.

[hv_]

I fully understand what Matt & BS are about. They WANT to split from btc1 - and so make btc1 and the 2x to be an alt..

Uh hang on, did you expect core to support the 2x fork? Absolutely none of the core developers have ever officially supported it.

This is why I'm far more concerned about the 2x part of segwit2x and not the segwit activation thanks to BIP91 making it compatible. Nothing will make core compatible with the 2x component so it's now a standoff between core and the bulk of the miners. We'll see if the miners follow through with 2x or if a significant number now drop off their NYA support.

AFAIK the 2x was bespoke many times (Hongkong,...) , it was / is part of the core road map, it is good for the new harmony - some core guys worked on HF (a bit).

I really do not see the issue to do it in November or with some compromise early next year.

I do not see the benefit to risk the new harmony.

I do not see tech is really that bad and nobody can mathematically prove that centralization is the real issue.  

I still hope groups speak and help each other and toxic elements go away.

I hope individuals put themselves behind Bitcoin.

Can only be good for Bitcoin in the long run.

[pinkflower]

If you are a Core opponent then it would be nice to shut up and let them make mistake after mistake that would lead them to their own demise. I genuinely dont like the fork but the fact that its now there, I ended up holding both to protect myself from all this stupidity from Bitcoiners who are acting like children.

Go ahead Core and Cash. Try to kill each other.