CIP Proposal - Segwit Support (CIP 15)

Development Counterparty
1

Here is the link to the work-in-progress CIP. Tentatively titled CIP 15.

[UPDATED] Moved number from CIP 14 to 15

1 Like
2

Does this CIP specify that it be possible to issue assets from a SW address?

Iā€™m not asking for this, but just wondering.

3

To be clear, there are not segwit addresses - only segwit outputs. Regular 1xxx addresses can spend and receive segwit outputs as long as the wallet is compatible.

Yes. To answer your question - yes - all operations including issuances will send and receive segwit outputs.

The exception is BTC sends which will will use standard P2PKH addresses by default.

4

Iā€™m assigning this CIP number 14 and submitting a PR for acceptance in draft status.

UPDATE: There is already a CIP 14 in progress. Assigning this to CIP 15.

5

With some more input from @rubensayshi, I updated the proposal in the pull request.

1 Like
6

@deweller Do you prefer unbridled open discussion on this hereā€¦ or in the Github as issues. Telegraphing where I am heading with thisā€¦ As an asset owner, my preference is to be able to not be forced to adopt Segwit transactions. If other asset holderā€™s and CP users (not me) want it - let 1000 flowers bloom. But I have unresolved issues with the topology of Segwit TXā€™s such that as an issuer and a Bitcoin user - they donā€™t notionally hold fungibility for me. So in shortā€¦ I advocate any Segwit implementation be opt-in and refutable by issuer. A will-not-accept flag or explicit delineation be provided for. I donā€™t want that Counterparty at the protocol level imposes it wholesale on all users and token holders irrespective of any objections they may hold. That enforcement would be commercially incompatible with our own projectā€™s use case of CP and a really frustrating and undesirable choice between two or three equally bad outcomes if CP protocol moves to a place Iā€™m reticent to go to and follow. By two or three equally bad outcomes - Counterparty Classic (Pre-Segwit) forking or ERC-20 as a replacementā€¦ neither pathway is FTW as far as I can see.

7

This CIP proposes that all Counterparty transactions are Segwit transactions going forward.

Segwit transactions have the distinct advantage of saving a significant amount in transaction fees.

With that said, I expect the Counterparty APIs will still support the old-style base58 addresses for the forseeable future until such time that segwit is the overwhelming dominant transaction format on the network.

If Segwit does not gain transaction, then this proposal may never be implemented.

8

I am averse to this implementation being made compulsory on Asset Owners. I was asked by @loon3 ā€œout of curiosity, why donā€™t you like SegWit?ā€

So for me itā€™s a combination of the following:

  1. SegWit solves for a non-problem - specifically damn obstinance in the ā€˜discussionā€™ (or lack thereof) around scaling E.G it went like:

    if isevil ((hardfork) && (blocksize increase)) {
  throw_exception();
  progress_halt();
  echo "because ".to_string($some_pretzel_logic_shim)." is a problem.";
}

  2. The result of SegWit is the Satoshi fee per byte of data is made into dual-class citizen (SegWit Bytes vs Satoshi Transactions) whereas irrespective of where you put the signature (aka ā€œwitness dataā€) it is still in Mempool and hurting peopleā€™s RasPiā€™s

  3. The mining incentive is skewed in a small block environment and is pushed toward rewarding lightning channels at scale - I donā€™t agree. I believe that 100% of the economic incentive should go to encouraging mining capital investment.

  4. The growing SegWit PiƱata:

  • Pre-SegWit (such as in Bitcoin Cash) the upside of a 51% attack by miners was the ability to re-spend a minerā€™s own coins (double spend).

  • Post-Segwit everyday more TX go into a 51% bounty pool of anyone-can-spend free money to take off the tableā€¦ the network disruption of hurting Bitcoin will affect price for a timeā€¦ but not forever with decent post 51% image managementā€¦ in time the bounty of such attack should overcome short term reputation hit and loss-of-confidence in the system (given that many many user will be unaffected - specifically those with only Satoshi class UXTOā€™s)

In my view SegWit is toxic to the Bitcoin eco-system and is a material threat to the planet scale viability of Bitcoin as a currency.

Material Objections:

"This CIP proposes that all Counterparty transactions are Segwit transactions going forward"

  1. For us this is a breaking change at a protocol level.
  2. This change has impact on our financially invested 5m token holders.
  3. This change, if mandatorily implemented so as to compel us as an issuers into accepting SegWit transactions as valid shall permanently push Blockfreight, Inc. off the Counterparty network if that change is implemented as currently proposed.
  4. The universal and compulsory nature of the proposal is the issue.

Questions:

  1. Is it viable to have asset owners determine if a SegWit transactions are permisible? Dis-allowable?
9

This is merged in draft status.

10

@julian.smith - I will look into the feasibility of making segwit a configuration setting when this gets closer to the implementation phase.

1 Like
11

SegWit will reduce fees. Bech32 P2WKPH (bc1ā€¦) is a superior address format, at least, as evidenced by Bitcoin Cash adopting it (bitcoincash:ā€¦) for its strong error detection.

But I would like to still preserve Bitcoin Cash usersā€™ abilities to transact their Counterparty assetā€¦ Iā€™m considering all the things a multi-chain Counterparty could facilitiate

12

I just thought about Bitcoin Segwit and Lightning support and found that even if counterparty does not support these the bitcoin transaction base load will reduce and fees get lower.

1 Like
13

Segwit pushed to develop

The CIP was changed to account for the complexity found during implementation and postergation of support for P2WSH on a later CIP. Milestones were changed to reflect the complexity and were spread out on more progressive deliveries.

This branch adds ā€œregtestā€ support, all protocol changes are activated on regtest by default, so you can test segwit on a private network.

This commit covers milestone #1

1 Like
14

CIP 15 bounty has been updated to 850 XCP to account for additional work required on segwit development and XCP price drop since the CIP development bounty was raised.

350 XCP transferred from XCP dev fund to cover additional development costs.
https://xchain.io/tx/8a6e1c26bf8546333d2c1a4f4c5ff32d0c0fe79eae526461b41f96791e47c8a5

Milestone #1 Payout (175 XCP)
https://xchain.io/tx/08ed268c602fc51b1957dfc37d67f8be12a501514fcea47d9a9456b450df7863

15

Ugghā€¦ Bitcore (counterwalletā€™s library for dealing with Bitcoin) doesnā€™t support segwit, we will probably have to shove in bitcoinjs-lib in to support segwit for counterwalletā€¦ making the wallet load time even larger :disappointed:

16

Almost done segwit support for counterwallet

1 Like
17

Segwit added to counterwallet on the develop branch

18

Milestone #2 Payout (175 XCP)
https://xchain.io/tx/07d5e614288de065fd69211a39c10e4ffefcd2bacd8c5d6412bb8533f0a337aa

19

Milestone #3 Payout (350 XCP)
https://xchain.io/tx/8c762d8f046c28bbbbe5c93cea521e7cd5802a29652917f26c358911c980d3d8

20

Milestone #4 Payout (150 XCP)
https://xchain.io/tx/0d6e3c481a750e6e415415bd3ef3370b956bb0da861065a9a3298360f2a7113a