The Barry Silbert segwit2x agreement with >80% miner support.

[Searing]

They want to activate segwit WITH the hardfork, not separately, nor before the 2MB change.

I agree that the proposal is not "what we expected". But it's pretty close to proposals where Segwit comes first and 2MB, some months after. The item that mostly worries me from the proposal is that it doesn't address quadratic validation time.

Couldn't it be possible to change the proposal very slightly, allowing only 1 MB for legacy transactions (P2PKH/P2PSH), and to make the 2 MB change exclusively for P2WPKH/P2WPSH transactions? It that was possible and accepted by the miners, the most worrying problem would have been solved.

Bitcoin core has taken the position of 'no hard forks ever'

Thus unless the miners want to fork, bitcoin core will simply take over

in blocking mode from BU and stop this dead or if desperate, do UASF

They, up to this point reject any type of hardfork period.

Thus miners will fork or fold imho.

[1714937981]

1714937981

[1714937981]

1714937981

[1714937981]

1714937981

[1714937981]

1714937981

[stdset]

Yes, and in fact, transactions of 1 MB are ridiculous, because they could easily be replaced by a tree structure of smaller transactions, changing the N^2 into N log N.  

How about CoinJoin transactions? Is there a way to replace such transactions with tree structures of transactions in a safe, trustless way? And wouldn't a tree structure be larger than equivalent single many-inputs-many-outputs tx?

[dinofelis]

Yes, and in fact, transactions of 1 MB are ridiculous, because they could easily be replaced by a tree structure of smaller transactions, changing the N^2 into N log N.  

How about CoinJoin transactions? Is there a way to replace such transactions with tree structures of transactions in a safe, trustless way?

In bitcoin, there is no way to do CoinJoin trustlessly - at least at the protocol level.  But the tree structure of doing CoinJoin trustlessly is exactly what is done in DASH.  I think each step mixes 16 at a time or something of the kind (long time ago I read their whitepaper).  The trustlessness comes from the collateral that masternodes need to provide in doing so.  DASH has deep down, the bitcoin code, because it is a bitcoin code fork.
Of course, this is trustless concerning the safety of one's funds, not concerning the anonymity: the set of masternodes knows which funds went where ; but that's always the case of the entity that makes the coinjoin transaction.

[stdset]

In bitcoin, there is no way to do CoinJoin trustlessly - at least at the protocol level.

Why so? A link?
To me it looked quite simple:

The signatures, one per input, inside a transaction are completely independent of each other. This means that it's possible for Bitcoin users to agree on a set of inputs to spend, and a set of outputs to pay to, and then to individually and separately sign a transaction and later merge their signatures. The transaction is not valid and won't be accepted by the network until all signatures are provided, and no one will sign a transaction which is not to their liking.
No risk of theft at any point.

[AngryDwarf]

That's a lot of DCG portfolio companies disagreeing with the road map put forward by the other DCG portfolio company, BS.

But what is the point of segwit if you are going to do a hard fork anyway? The whole point of segwit is that it masquerades hard fork functionality through a soft fork, so if hard forks can work safely (Monero hasn't blown up yet, nor Dash or Ethereum*), then the functionality provided by segwit can be implemented in a cleaner manner with a HF.

*Ethereum has hard forked many times, only a contentious one ended up with a permanent split chain.

[dinofelis]

In bitcoin, there is no way to do CoinJoin trustlessly - at least at the protocol level.

Why so? A link?
To me it looked quite simple:

The signatures, one per input, inside a transaction are completely independent of each other. This means that it's possible for Bitcoin users to agree on a set of inputs to spend, and a set of outputs to pay to, and then to individually and separately sign a transaction and later merge their signatures. The transaction is not valid and won't be accepted by the network until all signatures are provided, and no one will sign a transaction which is not to their liking.
No risk of theft at any point.

Yes, you are right, I confused the anonymity, and the fund security.  With coinjoin "done by hand", there is always an entity that has to construct the transaction, and of course that entity knows which output and which input go together, but you are right that there's no risk for the funds themselves, if you can check yourself that to your input you need to sign, corresponds an output you wanted with the right amount.

There's nothing that would stop the "central mixer" to propose a tree of coinjoin mixings to the users, in the same way DASH does automatically with master nodes, and monero does implicitly without need for user agreement in ring signatures.

[dinofelis]

That's a lot of DCG portfolio companies disagreeing with the road map put forward by the other DCG portfolio company, BS.

But what is the point of segwit if you are going to do a hard fork anyway? The whole point of segwit is that it masquerades hard fork functionality through a soft fork, so if hard forks can work safely (Monero hasn't blown up yet, nor Dash or Ethereum*), then the functionality provided by segwit can be implemented in a cleaner manner with a HF.

*Ethereum has hard forked many times, only a contentious one ended up with a permanent split chain.

Indeed, the whole thing of soft fork versus hard fork is ridiculous: in both cases you change the protocol.  The difference resides in:
1) a way to ENFORCE it: if 51% of the hash power implements the soft fork, it is enforced upon the 49% (exactly like a 51% attack enforces the new history upon the whole system)

2) the ridiculous belief that non-mining nodes (who can be Sybiled at almost no cost) have an important role to play, and hence to "respect nodes with old software" (who cannot USE the new protocol, but don't block it).

If a cryptocurrency is centralized on a dev team, then it can hardfork in the same way it can soft fork.  This is what many crypto currencies do, of which, indeed, DASH, ethereum and monero are examples.  Monero even has a REGULAR hardforking policy: it is in the code that the running protocol remains only valid up to a certain block, so IN ANY CASE a hardfork is needed. 

If a cryptocurrency is truly decentralized, its protocol is immutable in the same way its history is immutable.

You can't have it both ways.

[stdset]

I think the best solution in this situation would be Core to support Segwit2MB.

Do core devs say that there are many desired improvements that need to be packaged together to do a HF once instead of several times? I think most people would understand that. Ask for reasonable amount of additional time to do that. Cannot be It's not negotiable.

Is 2MB base size slightly more than Bitcoin needs right now? Maybe so. But should adoption grow, Bitcoin will need it anyway.

Are we afraid of 8MB total size blocks? I don't think so. Even with transactions backlog like now, most of time we won't be having 8MB blocks, more likely most of blocks will be about 4MB. Even if increased storage, bandwidth requirements will force some people to give up their full nodes, small decline in full nodes count isn't critical. Moreover, increased adoption may result in increased number of people interested in running full nodes.

So what's the point in refusing the 2MB HF and pushing the UASF? To teach miners a lesson? Maybe they deserve it. But it's unwise, immature. Even if they are so, does that mean that we should be like them?

If Core accepts the 2MB HF (not just plain blocksize increase, but combined with all desired improvements, properly scheduled), Segwit will most likely be activated sooner than with BIP148, in more reliable, civil way.

[Calangaman]

The current situation is very confusing. We are at a turning point here.
The BTC community is mostly made of articulate people who have been thru all sort of cycles. They think time is working for them as BTC has never been that high. It doesn't.
The market cap of crypto almost quadrupled in 6 months and new investors go either for the quick buck or for better technical features.
It is painful to admit that newbies have the firepower to boost any coin to a point where BTC miners may want to consider mining other stuff.
I'm personally fed up with seeing scam coins going to the moon. This market is going crazy and it's up to the big boys to put the house in order!

Why? Missing out on making easy money?? A coin may be a scam to you but not to others. Hence why they are going to the moon.

There are those who thinks Bitcoin is a scam? What do you say to those?

Big boys - core developers?? Why? it is none of their business.

Like all crypto holders, I've been doing fine this year, don't worry.

By scamcoin, I meant the likes of Bytecoin (600mln market cap, hello!) and other artificially managed coins.
By big boys, I meant influent users, miners, etc

[Denker]

...The point being, the Bitcoin maximalists are kidding themselves when they imagine everyone returning solely to Bitcoin. It's a multipolar cryptoverse now, and we may never see Bitcoin at 50% of market again. Even if we do I expect it to be temporary.

I can think of 1/2 a dozen coins that paid miners almost 2x what bitcoin would/did (and even 3x or more given the right trading scenarios) in the last week or two.

This greed also works the other direction! When the trend turns downside and the big guys will start to short the market.
Pretty easy with all those alts!
This bubble will burst and will be like the second half of the dotcom phase.
History always repeats. People are greedy and dumb. Will sit at the sideline and watch the shit show happening.This will be epic!
The greedy idiots will cry for regulation due to all the huge losses the majority will make.
All those ICO bs is a big scam, like 95% of the alts as well. Something from regulator side will happen. Mark my words!
If you make 10x or even 20x with shitcoins now doesn't matter when the end of this story will be a big crash.
Go and continue buying your pets.com. As I said, I will watch it from the sideline.

[hv_]

...The point being, the Bitcoin maximalists are kidding themselves when they imagine everyone returning solely to Bitcoin. It's a multipolar cryptoverse now, and we may never see Bitcoin at 50% of market again. Even if we do I expect it to be temporary.

I can think of 1/2 a dozen coins that paid miners almost 2x what bitcoin would/did (and even 3x or more given the right trading scenarios) in the last week or two.

This greed also works the other direction! When the trend turns downside and the big guys will start to short the market.
Pretty easy with all those alts!
This bubble will burst and will be like the second half of the dotcom phase.
History always repeats. People are greedy and dumb. Will sit at the sideline and watch the shit show happening.This will be epic!
The greedy idiots will cry for regulation due to all the huge losses the majority will make.
All those ICO bs is a big scam, like 95% of the alts as well. Something from regulator side will happen. Mark my words!
If you make 10x or even 20x with shitcoins now doesn't matter when the end of this story will be a big crash.
Go and continue buying your pets.com. As I said, I will watch it from the sideline.

++

[DooMAD]

I think the best solution in this situation would be Core to support Segwit2MB.

That's probably the desired goal of this agreement.  All the drama queens in this thread were assuming that the miners were going to suddenly fork away without developer support, but if you think about it, that seems pretty unlikely.  This whole thing could just be the miners simply saying "come a little closer to our stance and you might have a deal", although admittedly including a pretty strong ultimatum in the process.  Plus all the 'Chicken-Little' crybabies can't seem to take solace from the fact that this completely derails even the slightest possibility of 'emergent consensus' happening.

After some consideration, I think my first impression was wrong.  In all likelihood, this isn't an escalation, this is a concession from miners.  SegWit is happening and BU isn't.  The rift in the community just shrank a little (but I fully expect everyone on the forums/reddit/etc to act the opposite and keep going full retard at each other like their lives depended on it).

And if people don't want 2MB straight away, you know what you need to do.

[The One]

The item that mostly worries me from the proposal is that it doesn't address quadratic validation time.

Solution is pretty trivial:

To prevent worsening block verification time because of the O(N^2) hashing
problem, the simple restriction that transactions cannot be larger than 1Mb
has been kept. Therefore the worse-case of block verification time has only
doubled.

Yes, and in fact, transactions of 1 MB are ridiculous, because they could easily be replaced by a tree structure of smaller transactions, changing the N^2 into N log N.  

All the arguments against "bigger blocks" are bogus.  Non-mining nodes have nothing to do with decentralization (of power), and the N^2 time has to do with the size of individual transactions, which have been erroneously left to be much much too big from the initial design.  There is simply no point in having such big single transactions.

And why it that others can't see it?

[dinofelis]

And why it that others can't see it?

Some do.

The purely technical argument I've repeated several times now, that full nodes have no *power* in the decision-making process, still stands unchallenged, and several people understand it too.  Hell, Satoshi and Gavin are part of those people too, even though I don't have to appeal to authority, but just to show you that "others can see it too".  They have an informational role, they can be used in the "psychological game of FUD and FOMO concerning miners forking or not forking", they can give assurance to their owner, they can help with the internet connection, they can help with the privacy of transactions, and they can keep a copy of the block chain if all miner pools get bombed.  I'm not saying they are useless.  But they have no *power*.  As such, they don't play a role in "decentralization" which is a notion of *power* (as contrasted with distributivity which is a technical notion of geographical and hardware spread of a function).

This is why a UASF is a ridiculous notion, apart from the psychological encouragement for miners that suffer from FUD to fork.   And this is also why, apart from their utility for their owner, the number of non mining nodes in the power structure of bitcoin is of no importance, which changes entirely the balance of arguments if this is taken into account.

It is not the first time that I encounter religiously convinced people that lost their ability to think rationally, open minded about a technical/game theoretical issue without clinging to dogmatic truths they accept on authority, but look at the reasoning for its sole value of logical validity.

What is dramatic in this debate, is that a false argument is used, of which not many people are ready to analyse in depth, critically, its validity, and that, based upon this false argument, certain options are considered erroneously "bad" from the start.  I gave the analogy before: if you're convinced that plastic guns are necessary to stop an invasion of the Russians, and if this "known truth" is not put into question critically, then you will end up setting up a whole wrong defensive strategy.  If it would turn out that you need to diminish the number of plastic guns to make enough tanks and fighter planes, you may erroneously call people who are in favour of making more tanks and fighter planes "shills of the Russians" because they would diminish the amount of plastic guns, and "everybody knows these are essential to stop the Russians".

[kelceyott]

The item that mostly worries me from the proposal is that it doesn't address quadratic validation time.

Solution is pretty trivial:

To prevent worsening block verification time because of the O(N^2) hashing
problem, the simple restriction that transactions cannot be larger than 1Mb
has been kept. Therefore the worse-case of block verification time has only
doubled.

Yes, and in fact, transactions of 1 MB are ridiculous, because they could easily be replaced by a tree structure of smaller transactions, changing the N^2 into N log N.  

All the arguments against "bigger blocks" are bogus.  Non-mining nodes have nothing to do with decentralization (of power), and the N^2 time has to do with the size of individual transactions, which have been erroneously left to be much much too big from the initial design.  There is simply no point in having such big single transactions.

And why it that others can't see it?

The majority of those who reject larger block numbers are miners, I'm not sure my answer, but as far as I understand, if the number of blocks is bigger, the transaction fee will be smaller, and that is detrimental to the miners.

[The One]

The item that mostly worries me from the proposal is that it doesn't address quadratic validation time.

Solution is pretty trivial:

To prevent worsening block verification time because of the O(N^2) hashing
problem, the simple restriction that transactions cannot be larger than 1Mb
has been kept. Therefore the worse-case of block verification time has only
doubled.

Yes, and in fact, transactions of 1 MB are ridiculous, because they could easily be replaced by a tree structure of smaller transactions, changing the N^2 into N log N.  

All the arguments against "bigger blocks" are bogus.  Non-mining nodes have nothing to do with decentralization (of power), and the N^2 time has to do with the size of individual transactions, which have been erroneously left to be much much too big from the initial design.  There is simply no point in having such big single transactions.

And why it that others can't see it?

The majority of those who reject larger block numbers are miners, I'm not sure my answer, but as far as I understand, if the number of blocks is bigger, the transaction fee will be smaller, and that is detrimental to the miners.

No. Bigger blocks = more txs = more smaller fees = higher value of BTC.

[dinofelis]

The item that mostly worries me from the proposal is that it doesn't address quadratic validation time.

Solution is pretty trivial:

To prevent worsening block verification time because of the O(N^2) hashing
problem, the simple restriction that transactions cannot be larger than 1Mb
has been kept. Therefore the worse-case of block verification time has only
doubled.

Yes, and in fact, transactions of 1 MB are ridiculous, because they could easily be replaced by a tree structure of smaller transactions, changing the N^2 into N log N.  

All the arguments against "bigger blocks" are bogus.  Non-mining nodes have nothing to do with decentralization (of power), and the N^2 time has to do with the size of individual transactions, which have been erroneously left to be much much too big from the initial design.  There is simply no point in having such big single transactions.

And why it that others can't see it?

The majority of those who reject larger block numbers are miners, I'm not sure my answer, but as far as I understand, if the number of blocks is bigger, the transaction fee will be smaller, and that is detrimental to the miners.

Remarkably it are the miner pools who want larger blocks.  It is Core that doesn't want larger "base" blocks.

[stdset]

In all likelihood, this isn't an escalation, this is a concession from miners.  SegWit is happening and BU isn't.  The rift in the community just shrank a little (but I fully expect everyone on the forums/reddit/etc to act the opposite and keep going full retard at each other like their lives depended on it).

I agree. It's a good summary.

[Argon2]

The item that mostly worries me from the proposal is that it doesn't address quadratic validation time.

Solution is pretty trivial:

To prevent worsening block verification time because of the O(N^2) hashing
problem, the simple restriction that transactions cannot be larger than 1Mb
has been kept. Therefore the worse-case of block verification time has only
doubled.

Yes, and in fact, transactions of 1 MB are ridiculous, because they could easily be replaced by a tree structure of smaller transactions, changing the N^2 into N log N.  

All the arguments against "bigger blocks" are bogus.  Non-mining nodes have nothing to do with decentralization (of power), and the N^2 time has to do with the size of individual transactions, which have been erroneously left to be much much too big from the initial design.  There is simply no point in having such big single transactions.

And why it that others can't see it?

The majority of those who reject larger block numbers are miners, I'm not sure my answer, but as far as I understand, if the number of blocks is bigger, the transaction fee will be smaller, and that is detrimental to the miners.

No. Bigger blocks = more txs = more smaller fees = higher value of BTC.

One could argue bigger blocks = mempool drained and dumped or sold, lower Tx fees due to larger block space and increased volatility due to lack of Tx backlog.

[dinofelis]

No. Bigger blocks = more txs = more smaller fees = higher value of BTC.

One could argue bigger blocks = mempool drained and dumped or sold, lower Tx fees due to larger block space and increased volatility due to lack of Tx backlog.

One could even argue: bigger blocks => bitcoin not a shit coin any more, one can again do some transactions => all speculation on which alt coin is going to take over becomes moot => alt coin over inflated market crashes => this was what had also pulled bitcoin up as a speculative token too, so bitcoin crashes too because no more uncertainty, hence no more speculation, back to economic reality which is much, much, much smaller than the current ~80 billion market cap, back to $2 billion for crypto.

Or, like on LTC: no effect.