clean up bitcoin protocol technical debt which requires hardfork otherwise

[scravy]

Since we are starting a new chain we have the change to do protocol cleanup or implement BIPs which would require a hardfork if done to bitcoin. There is a list of such things at https://en.bitcoin.it/wiki/Hardfork_Wishlist

Should we apply some of these?

[Gnappuraz]

The list is a bit superficial I'm afraid. I have no clear understanding of the scope of most of those features. Maybe we can take in consideration some "quick win" if any of those is such.

[scravy]

Fair enough, here's some items extracted from that list that I find particularly interesting (I'll add some abbreviations to refer to them in later discussion):

• Protocol housekeeping
  • (BOC) Byte order consistency (big endian)
  • (MAL) Avoiding hashes covering malleable fields
• Bug fixes
  • (CMS) CHECKMULTISIG popping one-too-many items off the stack
  • (PCB) coinbases must be parseable.
  • (P2SH++) Some way for bigger BIP 16 P2SH scripts

BOC is in no way critical, but absolutely nice to have, as every developer coming to the bitcoin project first scratches her head about it (and while not targeting consensus it does require a hard fork as it affects hashes, versions, magic numbers)

MAL is something which is also targeted by SegWit but could be solved differently / more elegantly ( see for example: The right way to fix transaction malleability )

CMS is a super annoying bug which is well worth fixing but also requires a hard fork

PCB is something I completely agree with. Right now a lot of stuff which is not necessary for the execution of a script is put in the coin base transaction, such as the block height and in our case the kernel hash (and in case of segwit the witnesses hash). These could live in dedicated fields which do not need to be part of the block header.

P2SH++ Right now P2SH scripts are limited to somewhat about 512 bytes.

All of these issues have in common that these are things which actually work as of now but they were bolted on to bitcoin retroactively or are confusing as fudge and are especially sources of confusions for new comers to the project. Yet, since things already work, they do not pay off immediately (one could say most of these are what would classically be considered technical debt).

As we are starting a new chain we have a chance to clean them up, but it also takes time. Nevertheless, all of these affect the protocol and could not be altered once we went live.

[mergeable[bot]]

There has not been any activity in the past month. Is there anything to follow-up?

[scravy]

Thanks @mergeable.

Following up on the named items:

• CMS I will create a ticket for this one specifically, @Nizametdinov is interested in this I think.
• PCB Our coinstake transactions are completely parseable (see ADR Transaction Types), and we have an open ticket to make it even better: #292
• MAL We adopt segwit by default which fixes this. Will be done in #212, there's an ADR about including the merkle root tree in the header.
• BOC still a nice to have, but least priority, and possibly too much hassle
• ~P2SH++ still worth thinking about, but least priority, no ticket or action item for it yet~

[mergeable[bot]]

There has not been any activity in the past month. Is there anything to follow-up?

[Nizametdinov]

P2SH++ Right now P2SH scripts are limited to somewhat about 512 bytes.

P2WSH allows for scripts up to 10,000 bytes. https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Witness_program

[scravy]

Good point. Back when we created this ticket we did not have a clear understanding and decision on segwit. As by default every P2SH would be P2WSH actually P2SH++ is a no brainer.

Was I right about the following?

CMS I will create a ticket for this one specifically, @Nizametdinov is interested in this I think.

[Nizametdinov]

Yeah, I want to fix that. I will work on it after remote staking.