Post your SegWit questions here - open discussion - big week for Bitcoin!

[manselr]

Is there potential that the 95% threshold could be reduced at some point?

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

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.

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.

What does it mean for Bitcoin if Segwit never activates?

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.

[1714189914]

1714189914

[1714189914]

1714189914

[mezzomix]

i dont know what can we do to convince miners to start activating it.

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

[manselr]

i dont know what can we do to convince miners to start activating it.

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

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

[Quickseller]

i dont know what can we do to convince miners to start activating it.

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.

[manselr]

i dont know what can we do to convince miners to start activating it.

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.

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.

[mezzomix]

i dont know what can we do to convince miners to start activating it.

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

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.

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.

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

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

[amaclin]

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

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

[mezzomix]

Right, but the question was about running nodes.

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

[Carlton Banks]

Right, but the question was about running nodes.

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

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.

[tertius993]

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.

[Lauda]

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.

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.

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.

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).

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.

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.

[gmaxwell]

0.13.1 was basically only segwit.

[Carlton Banks]

Were there not some Compact Blocks fixes in 13.1? Miners not signalling Segwit could make use of those

[gmaxwell]

Were there not some Compact Blocks fixes in 13.1? Miners not signalling Segwit could make use of those

No, just segwit support for compact blocks; and more compact block tests.

[classicsucks]

OK I have a couple more thoughts about the failed Segwit soft fork. Firstly, Segquit was a technical solution for political and human problems. Transaction malleability is a problem, but it's easily mitigated in the current environment and is largely irrelevant in the big picture. Core devs were rightly afraid to increase blocksize because people are spamming the blockchain, manipulating exchange rates through churn, and the blockchain is getting huge. Also devs (and miners) wanted everyone to pay higher fees for transactions. Not only do higher fees cut down on spam, they also get people accustomed to bitcoin not being almost free. This is what Satoshi predicted: as the coin issuance decreases, fees should increase. So core was right to delay the blocksize increase. Block space needed to be a scarce and valuable commodity.

However, Core devs were also becoming increasingly arrogant, because the masses had never rejected one of their releases, and the code forks like XT, Unlimited, and Classic were complete garbage.

This actually marks a very important moment, when core releases are no longer "God's word". That said, core is the only team can be reasonably expected to carry this code forward, as they are highly technically skilled and deeply invested in the technology succeeding.  Also, IMHO they have the right values and ethics that got bitcoin to where it is today - an amazing $10bil+ market cap cryptocurrency. I'm hoping that Core can accept Segwit's defeat, merge the latest bug fixes into the 12.1 code, hard fork the blocksize to 2MB or whatever, and MOVE FORWARD.

The alternative will be people continuining to run the 12.1 release with whatever issues it might have.

Here's to honest and open dialogue so that we may keep improving on this amazing technology!

[achow101]

OK I have a couple more thoughts about the failed Segwit soft fork.

In what way has Segwit failed? It still has another 10 months to go before the activation period is up.

Firstly, Segquit was a technical solution for political and human problems. Transaction malleability is a problem, but it's easily mitigated in the current environment and is largely irrelevant in the big picture.

Not really. Transaction malleability is still a large problem and not irrelevant. There have been multiple times within the past year where transaction malleability has caused issues. Off the top of my head, I can remember once instance which screwed with a lot of users and wallets.

Dealing with malleability in wallets is still a major pain in the ass for both developers and users.

However, Core devs were also becoming increasingly arrogant, because the masses had never rejected one of their releases, and the code forks like XT, Unlimited, and Classic were complete garbage.

In what way are they becoming arrogant? In what way do the devs act arrograntly?

I'm hoping that Core can accept Segwit's defeat, merge the latest bug fixes into the 12.1 code, hard fork the blocksize to 2MB or whatever, and MOVE FORWARD.

As I said earlier, segwit is far from dead. Segwit is moving forward. Hard forking, less so.

The changes since 0.12.1 are not just bug fixes. There have been numerous optimizations and additional features that overall make Core a better wallet and node software. People can use 0.13.0 and get all of those changes without using segwit. Core has already significantly diverged from the 0.12.x versions; we are almost two major releases ahead as 0.14.0 is coming out in a few months.

[coinableS]

I posted this on bitcoin stackexchange with no answer, so I'll try here.

How does one derive the Redeem Script for the new P2WPKH addresses? With existing P2SH it's revealed after providing N number of public keys through a `createmultisig` function in the bitcoin client. Is it the same, just provide a single public key through a `createwitness` or similar function?

Is it currently available for fiddling with on testnet?

I'm currently looking at the dev guide (https://bitcoincore.org/en/segwit_wallet_dev/) but still can't figure it out.

To create a P2SH-P2WPKH address:

- Calculate the RIPEMD160 of the SHA256 of a public key (keyhash). Despite the keyhash formula is same as P2PKH, reuse of keyhash should be avoided for better privacy and prevention of accidental use of uncompressed key

- The P2SH redeemScript is always 22 bytes. It starts with a OP_0, followed by a canonical push of the keyhash (i.e. 0x0014{20-byte keyhash})

- Same as any other P2SH, the scriptPubKey is OP_HASH160 hash160(redeemScript) OP_EQUAL, and the address is the corresponding P2SH address with prefix 3.

Can someone dumb down step 2 for me?
Is it possible to do currently with a library in python?

[achow101]

I posted this on bitcoin stackexchange with no answer, so I'll try here.

How does one derive the Redeem Script for the new P2WPKH addresses? With existing P2SH it's revealed after providing N number of public keys through a `createmultisig` function in the bitcoin client. Is it the same, just provide a single public key through a `createwitness` or similar function?

Yes. There is an RPC command called addwitnessaddress. The parameter is an address from the wallet and it will create the necessary witness script and add it to the wallet for tracking. It will create the P2SH-P2WPKH address and return that to you.

Is it currently available for fiddling with on testnet?

Yes.

I'm currently looking at the dev guide (https://bitcoincore.org/en/segwit_wallet_dev/) but still can't figure it out.

To create a P2SH-P2WPKH address:

- Calculate the RIPEMD160 of the SHA256 of a public key (keyhash). Despite the keyhash formula is same as P2PKH, reuse of keyhash should be avoided for better privacy and prevention of accidental use of uncompressed key

- The P2SH redeemScript is always 22 bytes. It starts with a OP_0, followed by a canonical push of the keyhash (i.e. 0x0014{20-byte keyhash})

- Same as any other P2SH, the scriptPubKey is OP_HASH160 hash160(redeemScript) OP_EQUAL, and the address is the corresponding P2SH address with prefix 3.

Can someone dumb down step 2 for me?

Hash160 your public key. Take that hash and tack on OP_0 and the length of the hash (20 bytes) to the front of the hash. The redeemscript for your p2sh address is 0x0014{hash160}. Take that redeemscript and make a p2sh address out of it.

Is it possible to do currently with a library in python?

I don't think any of the python bitcoin libraries have been updated yet.

[coinableS]

Thanks for taking the time Andrew!

[Shiver]

I was just reviewing the release notes for v0.13.2 released about a week ago, and noticed a 'feature' where it would not be mandatory to use the SegWit addition even if enabled (if I understood that correctly).

Is this a very shrewd move to allow both SegWit and BU parties to climb down a couple of pegs to make negotiations easier and possibly get SegWit active without opposition having their hand forced to participate?  If so I'm very impressed with BitcoinCore.

It doesn't prevent the possibility of a hard fork of course, but at least it allows for people to watch and see how it works and add some more fixes (malleability for example) and push back the date for blocks becoming full to an extremely uncomfortable level, which may allow a new approach to reaching consensus.

I was never happy that consensus was set to 95% in the first place, as it in effect gives a minority the ability to block the majority (something we're seeing more and more in Society in general).  I'd prefer elegant design first, and pure horse power (BU) to add to that at a later date.

People like Roger Ver are not proponents of Seg Wit, but currently he doesn't seem to be in such strong opposition to it either.  Maybe something like this could be acceptable to Roger and those that have the same concerns with a preference for bulldozer solutions.

Am I understanding all this correctly or are there some obvious major flaws in my thinking that only I can't see?

Thank you all.