CIP Proposal - Segwit Support (CIP 15)


#1

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

[UPDATED] Moved number from CIP 14 to 15


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


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


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


#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


#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


#17

Segwit added to counterwallet on the develop branch


#18

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