[Dev] Segregated witness and BIP 102

Wellenreiter

@lizhi Your patch allows to put ANY block version above 2 in new blocks. Like 102938. It defeats the purpose of block versions at all. If someone puts maliciously such a block version in a new block, we have a forked network between all existing wallets and v0.9.3.2.

https://github.com/FeatherCoin/Feathercoin/commit/911098d4b9124ff01406729efc345a4dbbff6d68

Don’t upgrade to v0.9.3.2 unless you’re ready for a trouble.

@lizhi
@ghostlamder

Do we need to accept block version 3 in 0.9.3.2?

It is an easy fix to accept block version 2 and 4 or 2,3.4 only

ghostlander

@Wellenreiter We can accept any block version if it’s labelled 2. Otherwise it needs a hard fork.

lizhi

I think 0.9.3.2 is selection of transition. It accept V2 and V4 , and create V2 only. then 0.11 create V4.
last reject Version=2 blocks when 95% of the network has upgraded.

https://github.com/FeatherCoin/Feathercoin/commit/1e2cc219d6ed147ff80a5b1fa2200d661a2e4c7c

ghostlander

@lizhi If it accepts both, someone may create a v4 block and fork the network.

wrapper

@Lizhi and @ghostlander

Couldn’t they both remain on v2 untill 95% network is v 0.11 it then auto forks to v4 ?

Then last 5 % then just need to change over.

ghostlander

@wrapper There is no way to know 95% of the network is v0.11 unless it produces somewhat different coin base.

wrapper

The only way is if Lizhi is intimating that version v4 and v2 could coexist (For example they are called v4 but act as v2 untill 95%)

It would help as we could move onto testing and updating the other feature of 0.11 before the fork.

Wellenreiter

I think, we need a set of at triggers to change to block version 4.

majority (> 80%? > 95%?) of nodes is capable to at least accept Block Version 4
- Wallets could place a comment like ‘block v4’ in the BC with each transaction if they can read V4 blocks. As not many comments -if any- are manually placed in the BC this should work
  *when receiving a block clients check for that comment
- when >xx% of blocks during a given time frame - at least 48 or 72 hours, mey be longer - meet the requirement the trigger is met.
We define a block about 6 month in the future to trigger the switch to V4 as we did with the Neoscrypt switch and announce that block number and expected date/time to the community
… ??

If you think we need other or additional triggers please comment/add…

We must make sure, that only V2 blocks are generated in the production chain until all triggers are met.
All testing must be done in the Testnet, especially the switch over must be tested upfront.
We can simulate this by using a mixture of 0.8.7, 0.9.3.1 and >= 0.9.3.2 clients in the testnet, starting with a majority of <0.9.3.2 and increasing the percentage of ‘V4 capable’ clients gradually until the trigger is met.

In parallel we could run manual checks on the seed node and the explorer to determine the client versions, but this is no guarantee, so it only can be an additional check.

I don’t like to pull any 0.11.x version to the master before we have a clear plan how we approach the switch.

lizhi

I think 0.9.3.2 accept block 2 and block 4 , but mine block 2 only . 0.11 mine block 4 only. so 0.9.3.2 is a bridge. When the main pool is installed, we will broadcast the V4.

ghostlander

@lizhi It isn’t going to work.

Wellenreiter

@ghostlander You are right, we can’t switch to block version 4 based on the wallet versions only.

The idea is to use the time, until 0.11.X is ready to upgrade as many clients as possible to a version, that accepts blocks with version 4.
In an ideal world we would have 100% of 0.9.3.2 clients in the network, then define a block to switch over in the 0.11.X version and have to deal with the mining clients only, which of course must be upated to 0.11.x before the switch.
Any non-mining clients remaining on 0.9.3.2 then would not cause any harm and experience no change at all.

wrapper

Which Altcoins Are Implementing SegWit?

SegregatedWitness (SegWit) — the proposed upgrade to the Bitcoin protocol developed by the Bitcoin Core developers — is still far from activation. Requiring 95 percent of hash power to signal support for the solution, miner-adoption has seemingly stagnated at around 25 percent for now.

But, of course, SegWit’s open source code is out there. As such, altcoins based on Bitcoin’s codebase can take the code and implement the solution. Indeed, at least two altcoins are adopting SegWit: Litecoin and Viacoin …

https://bitcoinmagazine.com/articles/which-altcoins-are-implementing-segwit-1481577969

Wellenreiter

We clearly need a similar trigger as Bitcoin to implement BIP 102.
I’d set the level above 90% better 95%.

An alternate solution could be to advertize an upgrade to a new Version of code and announce the switch to BIP 102 for a given block number,like we did for the Neoscrypt fork

wrapper

Looks like most coins are taking 75%. Looks like @Lizhi was right in one front, FTC might have got good publicity if we had gone first. Not so much if we did a Vertcoin!

Not Just Bitcoin: Top 6 Altcoins Supporting Segregated Witness
http://cwt.top/en/news/2131/not-just-bitcoin-top-6-altcoins-supporting-segregated-witness

SimonTower

@wrapper Yeah, some attention and publicity would be awesome until this Segwit hype is going on.

Wellenreiter

@wrapper said in [Dev] Segregated witness and BIP 102:

Looks like most coins are taking 75%. Looks like @Lizhi was right in one front, FTC might have got good publicity if we had gone first. Not so much if we did a Vertcoin!

Not Just Bitcoin: Top 6 Altcoins Supporting Segregated Witness
http://cwt.top/en/news/2131/not-just-bitcoin-top-6-altcoins-supporting-segregated-witness

Well, other coins probably have more coders than we have at the moment…

SimonTower

Is there any chance to implement Segwit to FTC in the near future?

TrollboxChamp

@SimonTower i wondered this too

ghostlander

@SimonTower No need actually. FTC has fast blocks with a lot of free space.

SimonTower

@ghostlander Sure, but with Segwit we could use some kind of lightning network solution.