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

[Carlton Banks]

So basically kano is dancing around like a child, saying "i've read something mundane about this soft-fork that you haven't, and I'm going to troll you with it"


What's wrong, Mr. Misanthropist, did your mom refuse to make your food again?

[1715019839]

1715019839

[1715019839]

1715019839

[1715019839]

1715019839

[gmaxwell]

This behavior is not limited to just segwit but in general for node services; it just happens to be that segwit is the only major node service right now.

Not quite-- NODE_NETWORK exists, and is absolutely required for outbound connections (e.g. doesn't even get the bypass for draws; also the 40 count isn't 40 connection attempts, it's 40 results from addrman (which could be connection attempts or rejected for other reasons)).

In whatever release that comes out after segwit is required NODE_WITNESS will become required just like NODE_NETWORK is.   The purpose of outbound connections is to make sure you aren't partitioned and can obtain blocks, they're for your own benefit. Inbound connections are for the benefit of others.

It's not acceptable for the network topology to suddenly change when segwit activates--  can you imagine that? drop all your current connections and then form new ones hoping that the network can make a non-partitioned graph?-- that would be irresponsible.  Instead, it changes its connection preference at install time, so if there were any issues they could be addressed while the user is paying attention.

If you addnode a non-witness peer, it will be accepted just fine. Any inbound non-witness peers are accepted fine. If it's not able to get connected to witness peers it'll connect out to up to 4 of them so to avoid being partitioned if there are no witness peers available. It isn't "blacklisting" in any form-- my own 0.13.1 nodes have 82 out of 118 and  71 out of 113 peers which are not 0.13.1. (and in the latter group one of those 71 is an outbound connection to a 0.12.1 peer, FWIW).

None of it impedes the ability of non-segwit nodes to operate.  This was discussed in several public meetings and documented. I'm not aware of any problems resulting from it, besides the usual giving Kano something to howl abusively about.   When Bitcoin XT merged "xthin" it incorporated something far more aggressive (an absolute prohibition on outbound connections to non-xthin peers, even if addnoded, even if the node was partitioned)-- yet as far as I can tell there has been narry a complaint from Kano about it.

[kano]

This behavior is not limited to just segwit but in general for node services; it just happens to be that segwit is the only major node service right now.

Not quite-- NODE_NETWORK exists, and is absolutely required for outbound connections (e.g. doesn't even get the bypass for 40 connections).

In whatever release that comes out after segwit is required NODE_WITNESS will become required just like NODE_NETWORK is.   The purpose of outbound connections is to make sure you aren't partitioned and can obtain blocks, they're for your own benefit. Inbound connections are for the benefit of others.

It's not acceptable for the network topology to suddenly change when segwit activates--  can you imagine that? drop all your current connections and then form new ones hoping that the network can make a non-partitioned graph?-- that would be irresponsible.  Instead, it changes its connection preference at install time, so if there were any issues they could be addressed while the user is paying attention.

Oh you've never heard of that 95% rule?

That's rather interesting, you seem to almost be saying that you can't connect to non-segwit nodes at all with that comment.
Otherwise there would be a problem if it activated and you were connected to non-segwit nodes ...
Well that doesn't match anything else anyone has said ...

If you addnode a non-witness peer, it will be accepted just fine. Any inbound non-witness peers are accepted fine. If it's not able to get connected to witness peers it'll connect out to up to 4 of them so to avoid being partitioned if there are no witness peers available. It isn't "blacklisting" in any form-- my own 0.13.1 nodes have 82 out of 118 and  71 out of 113 peers which are not 0.13.1. (and in the latter group one of those 71 is an outbound connection to a 0.12.1 peer, FWIW).

None of it impedes the ability of non-segwit nodes to operate.  This was discussed in several public meetings and documented. I'm not aware of any problems resulting from it, besides the usual giving Kano something to howl abusively about.   When Bitcoin XT merged "xthin" it incorporated something far more aggressive (an absolute prohibition on outbound connections to non-xthin peers, even if addnoded, even if the node was partitioned)-- yet as far as I can tell there has been narry a complaint from Kano about it.

You keep throwing around this word 'partition'.
You forgot that 95% is required?

So, anyone who doesn't accept incoming connections and only makes outgoing connections with 0.13.1 ...

--

Heh, why would I need to complain about something that, for all intents and purposes, doesn't exist
I've never sided with XT
I have posted against it

The one I did side with was BIP100 - that turned out to be a bitcoin dev scam - no intention of ever adding code to vote for it, even though around 70% of blocks gave 'comment' voting for it and a vote implementation would very likely have gone to acceptance. It didn't suit the bitcoin dev's pocket financial requirements like LN does

[achow101]

Oh you've never heard of that 95% rule?
--snip--
You keep throwing around this word 'partition'.
You forgot that 95% is required?

The 95% activation rule is completely irrelevant to this. That rule is 95% of the blocks in a retarget period, not 95% of nodes. It has nothing to do with nodes.

The one I did side with was BIP100 - that turned out to be a bitcoin dev scam - no intention of ever adding code to vote for it, even though around 70% of blocks gave 'comment' voting for it and a vote implementation would very likely have gone to acceptance. It didn't suit the bitcoin dev's pocket financial requirements like LN does

BIP 100 was proposed by Jeff Garzik, not any of the other Core developers. He never followed through on it (and never even submitted it to the bitcoin-dev mailing list IIRC) so it was dropped.

[jonnybravo0311]

I posted this on kano's thread as well.  Reposting it here since it seems to be more relevant to this discussion...

Reading through the comments, my understanding is that a 0.13.1 node will fill its outgoing connections with other 0.13.1 nodes on priority, and only connect to non-0.13.1 nodes if it cannot find any 0.13.1 nodes to connect to.  It will accept inbound connections from any version.

Looking at one of my own 0.13.1 daemons, I get the following from calling getpeerinfo (I snipped a lot to only show relevant info):

Code:

[
  {
    "id": 6,
    "addr": "84.245.27.185:8333",
    "addrlocal": "50.2.189.35:42918",
    "services": "0000000000000005",
    "relaytxes": true,
    "lastsend": 1480270212,
    "lastrecv": 1480270213,
    "bytessent": 224159059,
    "bytesrecv": 582881556,
    "conntime": 1478943142,
    "timeoffset": -6,
    "pingtime": 0.120353,
    "minping": 0.11485,
    "version": 70012,
    "subver": "/Satoshi:0.12.0/",
    "inbound": false,
    "startingheight": 438527,
    "banscore": 0,
    "synced_headers": 440804,
    "synced_blocks": 440804,
    "inflight": [
    ],
...
{
    "id": 17,
    "addr": "213.251.186.216:8333",
    "addrlocal": "50.2.189.35:51776",
    "services": "0000000000000005",
    "relaytxes": true,
    "lastsend": 1480270212,
    "lastrecv": 1480270212,
    "bytessent": 295398321,
    "bytesrecv": 125067139,
    "conntime": 1478943165,
    "timeoffset": 0,
    "pingtime": 0.209322,
    "minping": 0.10465,
    "version": 70014,
    "subver": "/Satoshi:0.13.0/",
    "inbound": false,
    "startingheight": 438527,
    "banscore": 0,
    "synced_headers": 440852,
    "synced_blocks": 440852,
    "inflight": [
    ],

Based on that, I can clearly see I've got outbound connections to nodes with a version lower than 0.13.1.  Here's the call to getinfo (balance removed):

Code:

{
  "version": 130100,
  "protocolversion": 70014,
  "walletversion": 60000,
  "blocks": 440852,
  "timeoffset": 0,
  "connections": 125,
  "proxy": "",
  "difficulty": 281800917193.1958,
  "testnet": false,
  "keypoololdest": 1452577986,
  "keypoolsize": 100,
  "paytxfee": 0.00000000,
  "relayfee": 0.00005000,
  "errors": ""
}

So, I'm running a 0.13.1 node that has outbound connections to nodes with a version less than 0.13.1.

My initial statement about when a 0.13.1 node might connect to lower-version nodes is likely incorrect.  However, I've certainly shown that a 0.13.1 node will indeed fill outgoing connection slots with versions that are not 0.13.1.

[Fatman3001]

"no-one with any real stake in the network opposes it" - that one left me a bit confused, but thx for the answer

The pools who have come out against Segwit have apparently seen declining hashrate. They had 8% before that. You do the math.

... ok, math done

https://bitcoinmagazine.com/articles/where-bitcoin-mining-pools-stand-on-segregated-witness-1480086424

idk, I really hope you have a plan b. or at least are making an effort to communicate with the mining community.

[stdset]

As I see it, the word 'Segwit' can have 2 different meanings now:
1) Bunch of improvements packaged together in the latest release of bitcoin-core;
2) Segregating signatures from the rest of transaction data (segwit itself).

While clearly many of the improvements result from signatures segregation, do all of them depend on it? Or are there some, that are implemented independently, that don't need signatures segregation? If all improvements depend on signatures segregation, then there's actually little sense in distinguishing the two meanings one from another.

Edit: In other words, can some of the improvements be implemented as a separate softfork, or maybe even without softforking at all?

[johoe]

While clearly many of the improvements result from signatures segregation, do all of them depend on it? Or are there some, that are implemented independently, that don't need signatures segregation? If all improvements depend on signatures segregation, then there's actually little sense in distinguishing the two meanings one from another.

Edit: In other words, can some of the improvements be implemented as a separate softfork, or maybe even without softforking at all?

My personal opinion: segregated witnesses add a new kind of transactions, which look like anyone-can-spend for non-upgraded node making it a soft-fork.  So it is possible to choose completely new set of rules while still making it a soft fork. You now have two options:

• use the old rules for the new transactions making it only segregated witnesses.  Any further updates require either a hard fork or a new witness script version and then you need to support both intermediate and new version.
• or learn from the problems in the past and fix some small but nasty things that were on the hardfork wishlist for some time, like O(n) hashing and signing the input amount.

I prefer the second option.

The much discussed witness discount also serves two things: incentivice spending UTXOs by making signing cheaper and giving a block size increase with a soft-fork.  And it also discourages using the additional space for crypto-graffiti spam, since the discounted witnesses might not be stored forever.  You have a one-time chance to take all these advantages, so why not take it?  You can't introduce them in a second step without a hard fork.

I see the political problems - giving a signal against doing any necessary hard fork, making it harder to increase the capacity later.  But from a technical standpoint bundling these changes makes sense.

[RocketSingh]

Are all SegWit addresses necessarily multisig?

[achow101]

Are all SegWit addresses necessarily multisig?

If by multisig you mean "starts with a 3", then yes. They are not multisig addresses but rather p2sh addresses.

[RocketSingh]

Are all SegWit addresses necessarily multisig?

If by multisig you mean "starts with a 3", then yes. They are not multisig addresses but rather p2sh addresses.

So, they starts with 3, but have only 1 private key?

[achow101]

So, they starts with 3, but have only 1 private key?

Yes

[RocketSingh]

So, they starts with 3, but have only 1 private key?

Yes

Great. A normal Tx takes more space if its input uses a multisig UTXO. So, this is not the case for a SegWit address. Right?

[achow101]

So, they starts with 3, but have only 1 private key?

Yes

Great. A normal Tx takes more space if its input uses a multisig UTXO. So, this is not the case for a SegWit address. Right?

Yes. The "redeemscript" of a segwit p2sh address is smaller than that of a multisig p2sh address.

[amaclin]

Is it possible to redeem funded segwit p2sh address today before segwit is activated?

[ScripterRon]

Is it possible to redeem funded segwit p2sh address today before segwit is activated?

Bitcoin Core 0.13 will not accept a P2SH transaction with a witness redeem script until segwit is activated (I've tried this and the transaction is rejected).  Earlier versions of Bitcoin Core should refuse to relay the transaction because it is non-standard (you need at least two input data elements for a standard P2SH transaction and a segwit transaction has a single input element with the signature and public key in the witness data).  If you can get the spending transaction into a block, then it should be accepted by all of the nodes.

I don't know how other node software would handle this.

[amaclin]

non-standard (you need at least two input data elements for a standard P2SH transaction and
a segwit transaction has a single input element with the signature and public key in the witness data

Is it non-standard today because of leaving two elements in stack after script execution instead of one?

[gmaxwell]

This behavior is not limited to just segwit but in general for node services; it just happens to be that segwit is the only major node service right now.

Not quite-- NODE_NETWORK exists, and is absolutely required for outbound connections (e.g. doesn't even get the bypass for 40 connections).

In whatever release that comes out after segwit is required NODE_WITNESS will become required just like NODE_NETWORK is.   The purpose of outbound connections is to make sure you aren't partitioned and can obtain blocks, they're for your own benefit. Inbound connections are for the benefit of others.

It's not acceptable for the network topology to suddenly change when segwit activates--  can you imagine that? drop all your current connections and then form new ones hoping that the network can make a non-partitioned graph?-- that would be irresponsible.  Instead, it changes its connection preference at install time, so if there were any issues they could be addressed while the user is paying attention.

[...]
That's rather interesting, you seem to almost be saying that you can't connect to non-segwit nodes at all with that comment.
Otherwise there would be a problem if it activated and you were connected to non-segwit nodes ...
Well that doesn't match anything else anyone has said ...

Egads. I was saying the exact opposite of you can't connect to non-segwit nodes. In repeated loud text. You can and do.

But once segwit activates you cannot request blocks from them, because they don't provide the witness data that you need to verify the blocks.

Oh you've never heard of that 95% rule?
[...]

You keep throwing around this word 'partition'.
You forgot that 95% is required?

95% is regard to hashpower. Hashpower is not listening node count.

So, anyone who doesn't accept incoming connections and only makes outgoing connections with 0.13.1 ...

Is in a perfectly fine state. They'll preferentially connect to other segwit capable nodes (about 40% of reachable peers), but if they can't find enough (or if addnoded/connected otherwise) they'll happily connect to what they can.

that turned out to be a bitcoin dev scam

Bitcoin Classic dev scam would be more accurate, you should pay attention to who writes things. The author of that "proposal" (which has never even had a BIP written for it) is well known for behavior like that in my circles. Then again, it's absurd that you supported something that hardly gave a clear description of what it would do-- beyond hand more power to miners which I suppose served your "pocket financial requirements" well enough that you didn't even care about the details.

It didn't suit the bitcoin dev's pocket financial requirements like LN does

Segwit doesn't have much to do with lightning, but good job showing that you've been brainwashed by rbtc. AFAIK no regular contributors to the Bitcoin project stand to gain financially from lightning on Bitcoin, except by virtue of the Bitcoin currency itself becoming a lot more valuable because of more options for using it.

[classicsucks]

So I guess no one noticed the blacklisting in the new 0.13.1 code?

So if you run 0.13.1 you will find that it will connect to other 0.13.1 nodes on the network, but not to 0.13.0 or lower.

i.e. you are disconnecting yourself from the majority of pools, mining transactions on the network.

At the moment that's ~75% of blocks.
Your txns can of course get to the pools via other roundabout ways, but you wont connect to them directly.

Yeah even the main core developers implement blacklists without making it clear they exist

It looks like "blacklisting" might be an exaggeration here... nonetheless, the soft fork is a touchy subject and it's for reasons like this. Suddenly Segquit blocks are "higher quality" than non-Segquit ones.

I see that the Segwit adoption rate has flatlined at around 25%. I'm not running it, I'm running core 0.12. Reason being (sorry devs, I respect, but...), Segfault is a NERD SOLUTION: hugely overcomplicated, risky, and unnecessary. It's like going to get a car at a dealer and coming home with a portable automotive manufacturing plant!  Now before anybody buttrages on me, please understand that I've been a huge critic of the lame code forks like Classic, XT, and Unlimited, etc (heck, look at my username!). Those code forks were done with the worst of intentions by the worst devs. However, the blocksize needs to increase... I guess we're in a "stonewall period" right now where nobody wants to scream about blocksize anymore, all the cards are on the table, and everything that can be said has been said. Antonopolous says a compromise is near and I hope he's right...

Whoever is filling the mempool with sh*t will probably be able to do that even if the blocksize is 4MB, so that will be the next problem to solve. Ironically, if they are spamming, which is what I see, they're currently pricing themselves out of the market - fees are rising rapidly! I suspect it's "churn", people pumping the price... Thanks for listening.

[Decoded]

So after reading through the forums, I'm still trying to fully get my head around Segwit. It has a couple of large changes, like

 - A two (or is it four with a soft Cap of two) megabyte blocksize
 - A unique ID for a single transaction (removing the need to search for duplicate transactions with different IDs
 - Smaller transaction size by removing a large part of the transaction (I'm not sure what this is)