Forum Home
    • Register
    • Login
    • Search
    • Recent
    • Tags
    • Popular

    [Dev] Segregated witness and BIP 102

    Feathercoin Discussion
    8
    42
    25993
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • wrapper
      wrapper Moderators last edited by wrapper

      Just reading about a similar problem compiling :

      I think that the problem is that you put #ifdef instead of #ifndef at the top of your header.h file

      a search for what includes boost showed - checkpoints.h

      Which is a likely area for an error as it is included code for FTC. However, I can’t see a logical error in variable definition there, yet …

      https://github.com/FeatherCoin/Feathercoin/blob/0.9.3.1/src/checkpoints.h

      Also note https://github.com/FeatherCoin/Feathercoin/blob/0.9.3.1/src/rpcprotocol.cpp

      last change was to fix compile error …

      Also noted libqt5core5a replaces libqt5core5 mentioned in master-0.8/doc/readme-qt.rst

      1 Reply Last reply Reply Quote 0
      • lizhi
        lizhi @wrapper last edited by

        @wrapper

        Segregated Witness is a great improvement. It is not in order to expand the blockchain size.

        Because tx_hash = double_sha256(raw_tx), When S’ value replace S value, a unique transaction may have 2 different hash (tx_hash). It is a nightmare scenario.

        The transaction is the transaction, the signature is the signature. So we need to take out the signature, put it out, and put it on the outside. signature insert into witness

        Transaction structure = TxIn + TxOut.

        Currently a total of 4 related BiP (141-144) is proposed.
        https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
        https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki
        https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki
        https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki

        wrapper 1 Reply Last reply Reply Quote 1
        • wrapper
          wrapper Moderators @lizhi last edited by wrapper

          @lizhi said:

          @wrapper

          Segregated Witness is a great improvement. It is not in order to expand the blockchain size.

          Cheers for that and all your great work, I am for further developments in the software. I will study up as soon as I get a chance.

          B 1 Reply Last reply Reply Quote 2
          • B
            bsotnikow @wrapper last edited by

            @wrapper Is segwit on the road to smart contracts? From what I understand they need to implement segwit on BTC before they’ll be able to do smart contracts with it… . .I also for a long time didn’t see the value in smart contracts, but now I see. You can basically set up escrows right? Wherein coins can be tied up until certain requirements are met? That is a massive addition of function AND a very marketable thing towards the general public.

            1 Reply Last reply Reply Quote 1
            • wrapper
              wrapper Moderators last edited by wrapper

              'Lizi & @Bostnickow – Actually that sounds great

              I will read up on it more urgently, (am still failing to compile 9.3.1 on Ubuntu 15.10)

              but our basic policy is to include such in a “Development” version, then try to get some enthusiasm to test it, we have set up test networks for specific features, it seems to me testing a smart contract feature may attract more attention…

              Some of these features are complex, or really need to be on the network to be fully tested, at worst case that need high supervision at best they are backwardly compatible.

              1 Reply Last reply Reply Quote 0
              • lizhi
                lizhi last edited by

                0.9.3.2 is a bridge.It is compatible with the new blockchain version. Please upgrade client.

                1 Reply Last reply Reply Quote 0
                • B
                  bsotnikow last edited by

                  Events with ETH have changed my mind on this topic. I don’t think its a good idea to add complications like Segregated witness to the code. Keep the code as simple and secure as possible, focus on being a savings instrument and profitable for miners… It may take longer, but eventually someone will figure out how to create an encrypted bit of software that can create and manage crypto wallets. You’ll probably be able to download them free one day and set up as many smart contracts as you like with whatever crypto you like.

                  1 Reply Last reply Reply Quote 2
                  • ghostlander
                    ghostlander Regular Member last edited by

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

                    Wellenreiter 1 Reply Last reply Reply Quote 3
                    • wrapper
                      wrapper Moderators last edited by wrapper

                      We’re going to test some interface changes and do some help for the new features in 0.9.3.2.

                      It would be possible to make a intermediate release “0.9.3.3” with just the UI and minimum - fixes –

                      Then I’ll move onto into 0.1x.x series, and transfer those in and seeing if I can add some help and sharpen the new forms further. (any assistence accepted)

                      I’m assuming we can still make that branch compatible, while we create a tidy release of that.

                      https://github.com/wrapperband/Feathercoin/tree/0.9.3.2/doc

                      1 Reply Last reply Reply Quote 1
                      • Wellenreiter
                        Wellenreiter Moderators @ghostlander last edited by wrapper

                        @ghostlander said:

                        @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

                        Feathercoin development donation address: 6p8u3wtct7uxRGmvWr2xvPxqRzbpbcd82A
                        Openpgp key: 0x385C34E77F0D74D7 (at keyserver.ubuntu.com)/fingerprint: C7B4 E9EA 17E1 3D12 07AB 1FDB 385C 34E7 7F0D 74D7

                        ghostlander 1 Reply Last reply Reply Quote 2
                        • ghostlander
                          ghostlander Regular Member @Wellenreiter last edited by

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

                          1 Reply Last reply Reply Quote 2
                          • lizhi
                            lizhi last edited by 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 1 Reply Last reply Reply Quote 1
                            • ghostlander
                              ghostlander Regular Member @lizhi last edited by

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

                              1 Reply Last reply Reply Quote 0
                              • wrapper
                                wrapper Moderators last edited by

                                @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 1 Reply Last reply Reply Quote 0
                                • ghostlander
                                  ghostlander Regular Member @wrapper last edited by

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

                                  1 Reply Last reply Reply Quote 0
                                  • wrapper
                                    wrapper Moderators last edited by 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.

                                    1 Reply Last reply Reply Quote 0
                                    • Wellenreiter
                                      Wellenreiter Moderators last edited by

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

                                      1. 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.
                                      2. 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

                                      3. … ??

                                      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.

                                      Feathercoin development donation address: 6p8u3wtct7uxRGmvWr2xvPxqRzbpbcd82A
                                      Openpgp key: 0x385C34E77F0D74D7 (at keyserver.ubuntu.com)/fingerprint: C7B4 E9EA 17E1 3D12 07AB 1FDB 385C 34E7 7F0D 74D7

                                      1 Reply Last reply Reply Quote 2
                                      • lizhi
                                        lizhi last edited by

                                        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 1 Reply Last reply Reply Quote 1
                                        • ghostlander
                                          ghostlander Regular Member @lizhi last edited by

                                          @lizhi It isn’t going to work.

                                          1 Reply Last reply Reply Quote 0
                                          • Wellenreiter
                                            Wellenreiter Moderators last edited by

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

                                            Feathercoin development donation address: 6p8u3wtct7uxRGmvWr2xvPxqRzbpbcd82A
                                            Openpgp key: 0x385C34E77F0D74D7 (at keyserver.ubuntu.com)/fingerprint: C7B4 E9EA 17E1 3D12 07AB 1FDB 385C 34E7 7F0D 74D7

                                            1 Reply Last reply Reply Quote 1
                                            • First post
                                              Last post