Topic: 2X - page 3. (Read 4187 times)

First point: I don't understand ALL technical aspects
Second point: I don't think that is the best way, but it wouldn't do any real harm. Also, in future (especially for Lightning) we will be needed in bigger blocks.

From my another post :
Sorry, but i can't agree with this. Who tell you that they really know what they do? For example, Luke in his twitter wrote that high fees for btc is normal. (https://np.reddit.com/r/Bitcoin/comments/6ereib/these_fees_are_unacceptable/dicq95v/)
Do you think it is good answer for Bitcoin developer, BITCOIN, who tries to become new financial system? For example, i don't think so.
Also, here is interesting article. Author shows very interesting opinion: http://hackingdistributed.com/2017/08/26/whos-your-crypto-buddy/

In fiat system with 3d party you must to believe and trust someone. Bitcoin is network without trust (between peers) so you must verificate and check any kind of information and it doesn't matter who tells it to you: me, or core dev, or someone else.

I oppose it mostly on philisophical grounds that I do understand. I suppose you understand all the technical aspects. So tell us please, why should we all believe 2x is going to be the best road forword? Make sure you address all the reasons why Core is opposed to it, they're the ones who really know what they're doing.

Oh man I remember when I tried to set a full Ethereum node last year. It was an absolute mess. Apparently there is a part of the blockchain that got spammed into oblivion with some sort of attack and now that part is pretty much impossible to download. My computer was going into overdrive trying to process that part. It would have taken ages, so now they recommend that you skip that part.

So I gave up and used Parity instead, only to find out later on that it got some massive security bugs.

Trying to use Ethereum as a store of value is indeed an act of insanity.

It's brilliant   "I don't understand principles of bitcoin but i believe someone" "and now i firmly against any other opinions" True bitcoin user 


Very funny. I have an idea: lets decrease block size to 300kb because someone can't handle 1mb load.

well ok, fair enough, but your reply does not seem to answer why you would not 2x, excepting as to a reference to "stability" without more. Even for the sake of showing commitment by precedent to some block size increase, which appears to be reasonable given the size of HD vs cost decrease and bandwidth cost decrease. To not do this offers less choice to the market, and also gives BCH arguments more credence.

Also (while I don't really agree with the word spam) it would allow 1/2 the fees and make twice the space say at 8MB (or approx 2MB and segwit, but I think you can see what I am getting at) and down that path it would become much more costly for spammers to spam the blockchain. Or another way of putting it, you allow a better economic signal by allowing more actors to signal at less cost and in fact increases miner reward.

To address the point of stability, does 2MB really threaten stability? if so how.

In a word: Inertia.

It's very easy for node operators to be lazy, myself included. You set and forget, and you don't care that much. It's on a server you don't use or log into very often, or it may be a remote server that you rarely look at, etc.

IMO this is a huge roadblock to progress with the bitcoin protocal, but it may be a benefit to network security...

So some good, some bad.

I dislike this inertia effect because it consolidates control and encourages extremely conservative behaviour. The conservative base further increases control as time goes on, regardless of whether that's the best course of action or not.

The more decisions that I disagree with, the more I feel pressured to act. Previously, I've been lazy and not bothered, but I think I might do a client changeover tonight.

99% of devs oppose segwit2x and will never work on btc1



2MB is the average capacity alloted with segwit alone with 90+% segwit txs and 4MB peak. segwit2x doubles this with 4MB average and 8MB peak.
Yes this is far to much and reckless to HF to since we have yet to study the effects of segwit alone which is a massive blocksize limit increase.


Most of BCH blocks are completely empty , and that chain is highly centralized.


I could care less if 100% core devs supported segwit2x . The only thing that would happen if they pulled a 180 is I would lose respect for them and not follow them with their alt.

Omg, the famous Gregory Maxwell responded to my post What an honor!

I agree. They don't even have a good multisig, if you search for an ethereum multisig all you get is bunch of news about lost coins due to the vulnerability in the commonly used multisig contract.

The inability to sync an ethereum node is exactly why I never used it in the first place. I tried, but it got so slow that it would never sync at that rate, perhaps due to some buggy code.

I appreciate your work mr. Maxwell. Thank you for all the good work you have done!

We do in terms of _real_ technological development, but not fake marketing crap... and not at the expense of stability and security.

Compare, Bitcoin moving to innovative second generation error protected addresses w/ BIP173  vs  ethereum still behind bitcoin 0.1 without a strong safe to use address system.

Or ethereum validation being so slow that its impractical to sync-up a full node anymore, pushing almost all eth users onto SPV-like security for their initial sync, while Bitcoin sync tx/s speed is orders of magnitude faster and keeps getting faster.

I guess that the increase in block size in not that necessary right now compared to the associated risks. Bitcoin Core probably sees Bitcoin as a stable network, that doesn't compete with altcoins in the speed of technological development as much as in stability and security in which Bitcoin can and is winning.

Fees sometimes still rise, but neither Lightning Networks nor even segwit has reached high adoption. Bitcoin network is ready for it, but the technology is still in the development/testing stage. We can't know at this point if an increase in block size is needed and is it needed right now, while the S2X has no replay protection and appears to be rushing this fork as a consequence. LN nor Segwit can't be considered a failure at the time of the fork, as it is too early and we don't have as much of a need for it to rush it.

https://coin.dance/blocks

Here is the ultimate proof that the current 94% signaling is nonsense. Look at the current miners signaling for segwit2x and you will find F2pool. Well here is the actual stance of FP2pool with segwit2x:

https://twitter.com/f2pool_wangchun/status/906022864389681153

So basically he hasn't stopped signaling because he is too lazy to do the whole reset thing, but once the time arrives, he will not send hashrate to scam2x even if it currently shows up on that list.

So stop thinking 94% of hashrate will signal for it.

With 2x, the worst case size is ~8 MB. We don't know how such large blocks will effect the network. It could increase orphan rates, it could cause many nodes to drop off of the network because they can't handle the additional load. We don't know if the network can handle such larger blocks. Just because your internet connection can and your machine can handle the load does not mean that everyone around the world who is running the node can. They may be restricted by things like the Great Firewall of China which may find larger blocks easier to spot and thus make Bitcoin easier for them to block entirely.

Furthermore larger blocks can lead to miner behavior that is detrimental to the network. If the mempool is constantly cleared by a new block, then miners may be more incentivized to perform fee sniping instead of moving the blockchain forward. That is not good for the network.

Why does the "base block size" need to be bigger to stop spammers? You don't think they aren't going to also use segwit? Spammers can use segwit and pay less in fees than they would with a non-segwit transactions, and make more spam that fits in a block. If you double the maximum block weight, you depress fees even more and let spammers pay even less to spam transactions.

Having more transactions on chain does not necessarily correspond to having more transaction fees in a block. If the general idea is that larger blocks will decrease fees, then that means that more transactions need to be made at a lower fee rate in order for total transaction fees to match the fees for when blocks were smaller. Currently transaction fees are pretty low anyways except the times when people are spamming transactions (and it is very noticeable when that happens because the number of transactions in the mempool at a certain fee rate inorganically shoots up).

What is important to me is what software will be used by the companies that I do business with.  If they use Bitcoin Core, then I must continue to use Bitcoin Core.  If they switch to BTC1, then I'll need to switch as well.  The worst case would be they are split between the two chains.

BitcoinABC included replay protection so you could use either chain (although you still needed to install software for both chains).  But BTC1 has said they will not include replay protection, so this leads to transactions being accepted on both chains.  I understand why BTC1 does not want replay protection: it would require new wallets for everybody to use the BTC1 chain.

I realize that not everyone is going to support every decision Core makes, but I would assume if someone supports Segwit2x they would at least be running the btc1 client. What is the rationale for not running a btc1 node if they have the intention of hardforking off the Core chain in November?

As long as there are miners supporting either side a hardfork is inevitable and will occur as soon as the first SegWit block will be mined that is to large for core. Which side will see more long-term support and thus have more mining power is anyone's guess.



To be honest, after the BCH split of I see hardforks as having merits of their own. Given that there is a proper 2-way replay protection. Dynamic scaling leads to yet a different set of challenges, but I didn't follow that discourse too deeply.

Your right hardforks have risks, I "feel" though that not hard forking can have risks of stultification. I wonder if some sort of dynamic scaling would allay your hard for concerns.

Thanks for your considered opinions by the way. I like it when you address point by point.

 

TBH I don't know and this really requires clarification.

The miners are in opposition to the running nodes at the moment, and the user community is utterly impossible to gauge accurately. Business doesn't seem to care, it will go to whatever is successful.

I believe that ultimate control comes down to miners in the end. If miners mine 2X and nobody mines the legacy, then that's all she wrote.

Its not the merits of core vs 2x thread. As i said in OP, I am curious as to how this might play out. When will we know how many are "locked in" to either side? Will the fork happen regardless and we wont know until after how many miners support each or is it possible that the fork will not happen due to overwhelming support for either side?

There's a difference between running a node with X software, and supporting the positions of the related development team.

Talking as if running software = support is something that needs to stop. It's not correct.

I run a bitcoin core node but I often do not agree with the decisions made by the core team. There aren't millions of clients to cater to everyone's minute differences of opinion, so it's not exactly easy to 'show' your support in this manner.

2x is a "physical" blocksize increase to 4-6MB, not just 2MB. Regular SegWit already leads to 2-3MB blocks.



BCH has barely any blocks that are larger than 50k because there are hardly any transactions being made, so it hasn't proven anything so far.



Regular SegWit does as well.



Spam is defined as transactions that are made explicitely for the purpose of clogging up the network, akin to DDoS requests. While to my knowledge there's little "hard" proof that spam transaction exists, they are not simply "transactions person A does not like."



Agreed.



Problem being, that this approach would require a hardfork any time a block size increase takes place. While it went fairly OK with BCH, a hardfork is always a risky endeavour.