Pages:
Author

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

staff
Activity: 3458
Merit: 6793
Just writing some code
legendary
Activity: 1662
Merit: 1050
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?
staff
Activity: 3458
Merit: 6793
Just writing some code
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.
legendary
Activity: 1662
Merit: 1050
Are all SegWit addresses necessarily multisig?
full member
Activity: 217
Merit: 259
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.
hero member
Activity: 572
Merit: 506
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?
legendary
Activity: 1554
Merit: 1014
Make Bitcoin glow with ENIAC
"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.
legendary
Activity: 1344
Merit: 1024
Mine at Jonny's Pool
I posted this on kano's thread as well.  Reposting it here since it seems to be more relevant to this discussion...

Quote
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.
staff
Activity: 3458
Merit: 6793
Just writing some code
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 Smiley
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.
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
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 ...

Quote
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 Smiley
I've never sided with XT Smiley
I have posted against it Smiley

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 Smiley
staff
Activity: 4326
Merit: 8951
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.
legendary
Activity: 3430
Merit: 3080
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? Roll Eyes
staff
Activity: 3458
Merit: 6793
Just writing some code
Sigh, read achow101's post if you wont read mine Tongue

You WON'T connect to non 0.13.1 nodes.

Yes they CAN connect to you, but you blacklist making connections to them, since they are 'different'.
Actually technically that isn't entirely true either. 0.13.1 will still connect to nodes without the relevant services (i.e. no NODE_WITNESS) under certain circumstances. Right now that is 40 failed connections and having less than 4 outbound connections. Otherwise yes, it won't connect to nodes without the relevant services. 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.
legendary
Activity: 3430
Merit: 3080
So 13.1 will make outgoing connections to lower version nodes, but won't make incoming connections to lower versions. Explain why you have to drag the soft-fork through the mud to make that point
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
Another person who doesn't know how 0.13.1 works Smiley
It seems like you're the one who doesn't know anything here. Explain the following in conjecture with your statement "0.13.1 will not connect to 0.13.0 or lower" then:

http://i.imgur.com/oTsN7q8.png
http://i.imgur.com/FkbrrRN.png
http://i.imgur.com/DceH4bN.png
Sigh, read achow101's post if you wont read mine Tongue

You WON'T connect to non 0.13.1 nodes.

Yes they CAN connect to you, but you blacklist making connections to them, since they are 'different'.
legendary
Activity: 1284
Merit: 1042
This fight against core gets really annoying. We have a good solution on the table, which fits more transactions in one block using the same amount of resources. It makes no sense to implement a solution (bigger blocks), which uses more resources and has the same effective result ( double tx per block).

Technically there is no alternative to segwit. A real alternative would be a implementation which fits more tx in one block using a other methode then segwit. Segwit is real engineering, just rasing blocksize is scrypt kiddo style.

legendary
Activity: 2674
Merit: 3000
Terminated.
Another person who doesn't know how 0.13.1 works Smiley
It seems like you're the one who doesn't know anything here. Explain the following in conjecture with your statement "0.13.1 will not connect to 0.13.0 or lower" then:




A 0.13.1 node connecting to peers that are older than 0.13.1. Is this magic? Roll Eyes
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
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.
Clear and utter FUD. My node runs 0.13.1 and the majority of connections is not even to 0.13.1 nodes. It is so sad to see you go down this road.
Another person who doesn't know how 0.13.1 works Smiley
legendary
Activity: 2674
Merit: 3000
Terminated.
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.
Clear and utter FUD. My node runs 0.13.1 and the majority of connections is not even to 0.13.1 nodes. It is so sad to see you go down this road.
donator
Activity: 4760
Merit: 4323
Leading Crypto Sports Betting & Casino Platform
If we find ourselves well into 2017 and SegWit is still showing somewhere around 25-50% support, would it be reasonable for a 2mb blocksize limit in order to gain the support needed to activate SegWit?
Pages:
Jump to: