Quote from: Zenixin on August 22, 2017, 10:24:19 AM

Activation of segwit2x is the best possible solution which the developer of blockchain suggested. And I believed their opinion was credible that's why I'm supporting BTC no matter how many hard fork happened.

You will have to wait almost exactly 3 months for segwit2x to activate. I believe that November 23rd is when the hardfork is scheduled.

Quote from: senseless on August 22, 2017, 10:39:48 AM

Quote from: aleksej996 on August 22, 2017, 10:22:30 AM

We did something, it is Segwit. I think it is tomorrow when it should activate.

#1) I don't know about this. Some cryptos do this to get rid of mining pools. There might be some drawbacks, but as other proposals it would definitively require a hard-fork and we know that this can take a lot of time.
#2) I don't think that differences between blocks have as much to do with daily changes in hashpower as just with luck. I don't think that this would help at all. This readjustments are representing the change in network's hashrate and I don't think that there is a significant change in hashrate on a daily basis.
#3) Woah there, this sounds like centralization to me. Nodes are represented by IP addresses and that means that whoever can get most IP addresses has that 1%. ISPs and therefore the governments would love this.
#4) Any suggestions on how to do this? I think that reducing block time would just increase the rate at which disk is accessed.

#1) There are a ton of coins that have low block times. They do it to make fast confirmations. Who wants to wait 50 minutes for a confirmation? Or even 10?
#2) Faster difficulty readjustment periods prevent nefarious actors from pushing difficulty up and leaving the network. This creates longer transaction times as time between blocks would be higher than it should be. This would have been helpful during the BCH split. Difficulty would have readjusted in a little over 12 hours.
#3) No, The way DASH did it was to require the people to keep coins in the wallet. Anyone can setup a full node, but the number of master nodes, aka, the number of people who are able to get a payment for their node would be limited. It guarantees a minimum number of full nodes on the network. As of right now, I don't know anyone who runs a full node.
#4) UTXO commitments ? There are some not so insignificant issues with this on bitcoin though.

#2) There is really no incentive for people to do this and it is quite costly. Either way, there needs to be a limit and in practice I haven't heard any real problems from an significant hashrate drop for now. I don't see an urgency for change just in case of very rare forks that don't affect the network in any major way.
#3) I really don't see anything that such an implementation would fix. The one who can get most IPs the quickest is still the one who gets the coins and there is plenty of full nodes already, they are not costly at all. Everybody should run a full node for their own security. I run a full node and have been running it for years, I haven't experienced any lag, network-wise,CPU-wise or disk-wise. You can run it on a less then 500$ PC that you bought 3 years ago and a 1 MB/s Internet connection without even noticing that it is running.

It takes 1 MB of network and disk every 10 minutes. It is unnoticeable. You do need couple of GB of RAM for it tho and maybe some modern CPU. Otherwise you are fine. Getting a 8 GB RAM PC is not that hard these days and it will be more then twice that you need.
#4) To be honest this is the first time I hear of this. Did some quick searching on the Internet and it seems like it has been discussed back in 2013, if you are refering to this https://bitcointalk.org/index.php?topic=314467.0 . I would assume that it is not that simple gain or it has already been implemented.