Topic: Post your SegWit questions here - open discussion - big week for Bitcoin! - page 23. (Read 84847 times)

0.13.1 was basically only segwit.

I'm pretty sure that the majority jumped onto 0.13.1 due to Segwit. The other changes that it brings are minimal,thus upgrading was not really important.

Indeed. The other group of people are those that are failing to upgrade despite of the massive improvements in the later versions (e.g. people running 0.12.1 or lower).

There is no proper way to know that for sure. The changes that Segwit brings are huge, thus should be appropriately tested (by them) before being deployed.

Does anyone have any good data on why the numbers are where they are? Must confess I expected it to be much higher by now, but I don't have a good understanding of how difficult it is for a large mining operation to implement an upgrade like this.

Right, but there's no way to tell what their reasoning is for using 13.1, Segwit support is not the only change introduced in 13.1. Also, some people upgrade software with zero knowledge of what the fixes or new features are, they do it out of a vague sort of "keeping up" mentality. But with the miners, signalling for any soft-fork is completely unambiguous; either you're signalling activation or you're not.

Right, but the question was about running nodes.

There is no reliable measure that shows SegWit support by nodes and users in general.

"Running 0.13.1"  is not equal to "Supporting (voting for) segwit"

The miners job is to support the network. This is what they are paid for. If some of them start to work against the rest of the users, it is time to eliminate them.


This site provides an overview: https://bitnodes.21.co/nodes/

If we trust the agent string, more than 30% of the nodes are running on 0.13.1

Im just another broke guy going from month to month, I get enough to pay bills and that's about it, im afraid I can't do shit nothing in the mining circuit, I would have 0 impact and I would be running out of money at the end of the month since I would be investing it on that (on something that is giving me 0 returns). Doesn't seem realistic to me. Im trapped on this bill to bill lifestyle, I can't do nothing for bitcoin other than run a node on my computer, unfortunately.

If you feel strongly about SegWit, then you can purchase mining equipment and point it towards mining pools that support SegWit activation (or you could solomine with your blocks indicating support for SegWit activation)

You could also "rent" hashpower and point said rented hashpower towards the above type of pools.

True, we can run nodes and push miners to activate segwit, but ultimately it all comes down to what the miners will do. If I was a miner and I saw how most people are runnin core nodes, I would feel like a jackass not signaling for segwit.

How can I see how many 0.13+ nodes are being run vs sub 0.13+ nodes tho? I only see total Core nodes

https://coin.dance/nodes

By not relaying new non-segwit blocks and prioritizing segwit blocks all node operators can state their opinion in this case!

Look at this here:

http://bitcoin.sipa.be/versions.html

As you can see... CSV had 100% at some points... so yes it's possible. I don't know how much things have changed now compared to a couple months ago but I don't see the mining game having changed that much... CSV just was a non controversial update, but apparently some miners don't like segwit for a reason I still don't understand since it only has positives.


It would mean some features can't be implemented also LN will not work as good... im worried about this happening since bitcoin would remain just a better gold and not a global currency, but oh well it's still the best crypto out there with or without segwit, but it still would suck if we cant get segwit, but right now its stuck at 25% ish, i dont know what can we do to convince miners to start activating it.

What does it mean for Bitcoin if Segwit never activates?

If 90% of the miners decide to orphan the blocks of the remaining 10%, then they would have 100% consensus. It isn't that we can vote to change the threshold but rather that the threshold can effectively be lowered if a majority of miners can orphan all the blocks of the miners who are not signalling the change.

Yes, this has been done before. All soft forks in the past have had a threshold of 95% and we have activated several soft forks already with that threshold.

So if we reach 90% of segwit activation, we could vote that it's not 95% anymore but 90%? wouldn't that piss some people off? I don't get it so I would like to know.

Also, has a 95% of a big group of people ever agreed on doing anything? Shouldn't this have been foreseen a long time ago? I think 95% it's too much... but at the same time, it's great to guarantee that the big majority of people want something, but that 5% could be potential trolls, so I think 90% is probably a good enough compromise.

Yes. Point.
Because 90% is also a majority. The majority *can* change anything in any consensus at any moment.

Is there potential that the 95% threshold could be reduced at some point?  Considering that a single miner with greater than 5% can prevent SegWits adoption, I assume that this was never the intention.

Anything over 990kb is effectively full for the current network block size limits. The algorithm to fill the last few bytes of a 1MB block is designed to not waste heaps of time sorting through thousands of transactions just to find the last few bytes to fill the block. However none of this matters because the size of the block ultimately is up to the miner's configuration. Some miners haven't even bothered changing the default which is set to 750kb in bitcoind, while others (like p2pool miners) have lowered it to work around terrible speed issues in their mining pool design with more transactions. Furthermore the network may have 1 million transactions pending but the miner is free to mine their next block with absolutely zero transactions beyond their generation transaction, and many large pools still do such an optimisation as a workaround for slow block changes in the rest of their tool chain. Basing block size on some dynamic mechanism based on the last block sizes is silly since it means it will depend on miners' whims as to how big the block is, and not really represent how many pending transactions are on the network. Alternatively basing it on the number of pending transactions is also silly because one man's high priority transaction is another's spam, and vice versa. Dynamic sounds good in theory but fails to address the issue that not all miners are altruistic and choose defaults that are best for the network.

But most of the blocks I added also aren't full and they appear more frequently. A 990KB or less block definitely means that there may not be a problem as there must be a deficit of transactions or an ill configured miner

I think he is talking about the blocks that are not 990+ Kb that occur semi frequently. These are often either empty blocks or are simply just not full.