Protocol Change Proposal: Disable P2SH

[adamkrellenstein]

Our P2SH encoding no longer works with recent versions of Bitcoin Core. It was disabled in the API in October (because it was causing loss of user funds). There are multiple other bugs in the P2SH implementation (e.g. #2287 #2288). In general, this encoding scheme is simply superseded by #3054 which would be activated with the same protocol upgrade.

[adamkrellenstein]

Cost Comparison

Transaction Size Comparison

Size	OP_RETURN	P2TR	MULTISIG	P2SH
	Bytes vBytes	Bytes vBytes	Bytes vBytes	Bytes vBytes
10	212 212	353 239	303 303	295 241
16	218 218	359 240	303 303	301 247
32	234 234	375 244	303 303	317 263
64	266 266	407 252	303 303	349 295
80	282 282	423 256	415 415	365 311
128	N/A N/A	471 268	415 415	413 359
256	N/A N/A	599 300	639 639	541 487
1KB	N/A N/A	1367 492	1983 1983	1309 1255
2KB	N/A N/A	2391 748	3775 3775	2333 2279

Efficiency Ratio (vBytes per byte of data)

Size	OP_RETURN	P2TR	MULTISIG	P2TR vs MULTISIG	P2SH	P2TR vs P2SH
10	21.20	23.90	30.30	21% cheaper	24.10	1% cheaper
16	13.63	15.00	18.94	21% cheaper	15.44	3% cheaper
32	7.31	7.63	9.47	19% cheaper	8.22	7% cheaper
64	4.16	3.94	4.73	17% cheaper	4.61	15% cheaper
80	3.52	3.20	5.19	38% cheaper	3.89	18% cheaper
128	N/A	2.09	3.24	35% cheaper	2.80	25% cheaper
256	N/A	1.17	2.50	53% cheaper	1.90	38% cheaper
1KB	N/A	0.48	1.94	75% cheaper	1.23	61% cheaper
2KB	N/A	0.37	1.84	80% cheaper	1.11	67% cheaper

Most Efficient Method by Data Size

Size	Optimal Method	Efficiency (vBytes/byte)
10	OP_RETURN	21.20
16	OP_RETURN	13.63
32	OP_RETURN	7.31
64	P2TR	3.94
80	P2TR	3.20
128	P2TR	2.09
256	P2TR	1.17
1KB	P2TR	0.48
2KB	P2TR	0.37

[ouziel-slama]

done here #3098

[jdogresorg]

This “cost calculation” is inaccurate as it DOES NOT take into account all the BTC dust required to encode data, and only focuses on the transaction size to calculate cost, not total amount of BTC used in the transaction.

Also, Javier and I were able to generate, sign, broadcast, and parse a p2sh mpma send transaction using Bitcoin 28.1 perfectly fine on counterparty-classic with No changes to the codebase.

https://classic.tokenscan.io/tx/2974857

Seems as if you are wrongly blaming bitcoin for p2sh encoding issues rather than counterparty-core.

Counterparty-classic 9.62.1 release will be put out next week, including updating the fednode to run Bitcoin 28.1, at which point you can verify that counterparty-classic continues to work with p2sh perfectly fine, while counterparty-core does not.