search

CounterpartyXCP / counterparty-core

Counterparty Protocol Reference Implementation
http://counterparty.io
MIT License
284 stars 206 forks source link

Remove ARC4 encoding #1814

Open Jpja opened 4 months ago

Jpja commented 4 months ago

When a Counterparty message is embedded in opreturn, it is encoded with ARC4. opreturn = arc4(first input coin, message)

I believe ARC4 was introduced in 2014 or '15 to obfuscate transactions. This to make it harder for mining pools (Eligius) to censor Counterparty. Since this is hardly a concern anymore, maybe we should consider removing ARC4? (Or at least make it optional; at parsing the node would look for the CNTRPRTY prefix in both encoded and raw opreturn.)

Without ARC4 encoding it will be easier for Bitcoin explorers to detect Counterparty transaction., slightly easier for devs, and dispensers can be bought from general Bitcoin wallets.

adamkrellenstein commented 4 months ago

Yup I'm fine with getting rid of it. Will have some small performance benefits, it'll make composing transactions simpler, and I don't think it's necessary anymore.

However I consider it to be fundamentally unsafe to use non-Counterparty wallets to, say, trigger dispensers. You need to make sure that the address type is supported, e.g.

jotapea commented 4 months ago

@Jpja gets me 🤗

jotapea commented 4 months ago

Maybe the addition of the OP_RETURN cleartext message to the classic send of BTC can be the first step. And it could just be the 'CNTRPRTY' prefix (or the shorter 'XCP'?) by itself, without anything else in the message.

This would make much of the current https://github.com/CounterpartyXCP/counterparty-core/pull/1809 unnecessary. The only consideration left would be to decide if is worth it to also have a separate create_dispense with its own message type.