Discussion on BIP 322 Enhancements and Issues

Here we go with the discussion on BIP322 improvements and stuff that needs sorting out in the draft. There’s a GitHub issue where folks are pointing out problems and trying to refine it all. Let's pitch in and help out.

The GitHub issue is a key place for everyone to weigh in on BIP322. It's interesting how many opinions are flying around.

One thing is for sure, though if we don’t get some decent standalone script interpreters, BIP322 isn't gonna see wide use anytime soon.

You can totally make it easier. Just change the signed message for each address type. Define it like "<constant><addressData><constant>", hash it all, and that’s pretty much it. Other parts stay the same and you can keep the format BIP-322 compatible.

@garlonicon: This isn’t about me anymore. It's about simplifying BIP322 for everyone. Are we really only hashing the transaction for signing? I don’t see any cryptographic checks happening in the verification. Like, ECDSA does more... What gives?

What's this "proof of sent-transaction" nonsense? You can just make a structure and sign it. Figuring out if it connects to actual coins? That's on the recipient. And there’s always the simple pubkey verification.

Not gonna lie, that’s impossible because BIP322 needs a ton of script code that most tools just don’t have. Like, look at Electrum it barely deals with scripts. Adding a script interpreter isn’t in the cards.

Nah, you're twisted there. BIP 322 is signing a fake transaction but with a signature that’s not really cryptographic. It’s more about the whole script execution to see if a signature is valid or not.

We might have to take baby steps, though. Just get P2PKH validation sorted for BIP-322. That's pretty much a matter of address handling and some constants. Easy!

So, @OP, Greg Maxwell mentioned something on GitHub: this isn’t correct. There’s no digital signature scheme being proposed. This ‘sign by script’ is claiming some sort of superiority which is questionable.

But if we stick to your idea, we’ll just end up back at BIP137, which most wallets already understand. Your idea sounds like it needs hardcoded values, which isn’t clean code and it’ll fail scalability.

To get backward compatibility, OP_CHECKDATASIG is a solid choice. But we could just stick to <signature> <pubkey> OP_CHECKSIG, assuming it checks against a Bitcoin Message.

I finally got it we need two transactions. One to create coins and the other to spend them. Gotta keep future expansions in mind.

So transaction-based signing is powerful but complex. A lot of users just want something simple to sign messages. Like, why didn’t Legacy add BIP137 signatures, makes no sense.

I think it’s just the scriptSig we’re talking about. You can create a full signed transaction from the data you’ve got. Changing the transaction version would break BIP-322.

Best way? Start small with a BIP322 signing and checking program first. Build a full script interpreter later. It’s still a draft after all.

I swear this makes no sense. Who thought this was a good idea? The latest BIP322 drafts say it ties a fake txn to its witness data, which is pointless without some real verification.

Actually, quite a few people brought it up. And it’s not trolling, it could actually help. It’s not a twin implementation, it’s using the existing script interpreter from Bitcoin.

Then you can track down the author of BIP-322: Karl-Johan Alm. You could skip BIP-322 and focus on the Bitcoin Message instead. But guess what? It has limits, especially with non-P2PKH addresses.

That applies only to Bitcoin Core. What about third party wallets? They might never get it right. Tying transactions to signatures is new and it’s a feature that opens up possibilities.