Topic: BIP 322 draft design and improvement thread - page 3. (Read 1118 times)

I have addressed some more TODOs in a mailing list post, which I will quote verbatim:


At this point, the core of the BIP is already done, but such cases need to be addressed as "how can I sign a message from the Lightning Network" and "how can I allow another person to sign a message on my behalf, without giving him/her access to my private keys?"

Side note: I don't think most people here even know what a Merkle branch is, the form that is already used in Taproot, so if I prepared an explanation about this data structure, would it help you guys understand what is being proposed here?

Side note 2: I'm starting to suspect that the witness stack which contains the solution to a "challenge" in the second transaction which the spec calls 'to_sign' just has an ecdsa signature and public key (from bottom-to-top order) in the case of P2[W]{SH|PKH} - I'm not really sure what is pushed on a Taproot address, so I may have to make a guide for that too.

[silent transactions as referred to in the mailing list and Github is the same thing as Silent Payments thread started by @witcher_sense].

@NotATether,
It is called "BIP322 discussion thread", isn't it?

Change its title to "I want to join the club by any means", or lock it, whatever, just don't get mad and angry because it doesn't make sense to stop discussing in a discussion thread. 

Guys can we stop with these arguments that aren't accomplishing anything? The point of this thread is to discuss how to solve the edge cases of BIP322 to bring it to final status:


I dropped the old BIP because luke-jr told me it's better to help finalize BIP322, and I want to make change happen [as opposed to whining about it]. That's the end of the story. This thread is not for rambling about why my BIP was (or shouldn't have been) rejected, open a new thread if you want to discuss that.
Message signing with transactions looks ugly but is the only way to demonstrate proof-of-spendability-from-UTXOs. Let's leave it at that.

---

Anyway, what I did come here to post was that there is apparently a bunch of TODOs for addressing interoperability with various BIPs and proposals that are likewise in draft or maybe not submitted yet - one of them is interoperability with Silent Payments so this is what I have suggested on the Github issue for it (see the second post of this thread):

I purposefully avoided it to stay on the main line which was criticizing the concept, and not the BIP.
As you've brought it up: BIP322 supports both worlds at the same time!
How is it even possible? Is the BIP trying to invent another third universe where paradoxes are considered normal and tolerable?

I got this standard script behind a txo which somehow I'm able to unlock, and I'm trying to tie a message to it,  the problem is I got two different interested parties, one uses Bitcoin Core while the other party has another wallet.
What do I have to do when trying to convince them?
More critically important: When the said parties finish verifying (probably different versions of) my message, the party using the interpreter is convinced about a message being supplied by "somebody" who is able to unluck the txo, but what about the other party? Should they ignore the fact that their wallet already knows the public key(s) that actually was used?

See? Two different messages, two different signing processes, two different verification algorithms, and finally two, radically different application domains. What kind of BIP is it? A derailed BIP!

Yes, it's easy when you see it, but you should look, just look. Essentially, the BIP is trying to get implemented by any means without insisting on any principle or philosophy, I suppose I could forge an arbitrary third world and successfully convince Karl Johan to support it as well!

It's Greg Maxwell, not Luke, I like Luke, even when he goes too far. As for Greg? No ways! I mean, I'm a fan, not comfortable with the polemic but a fan, still, I don't know why I frequently find myself on the opposite side of where Greg stands, what's wrong with him?  

No, it is not optional, the other way is supposed to be optional, you just admitted that Bitcoin Core reference implementation is focused on "tying" stuff. I've already refuted this mix-and-support design policy.

Bitcoin script, has it through employing ES technologies like ECDSA and Schnorr, but script signing? No! It doesn't. It just implies that the script interpreter has passed testing some witness data for unlocking a txo. It is silent about the identity of the party who prepared this data, hence there is no established mechanism for authentication and repudiation unless you/your app would examine the witness data beyond what the interpreter does, e.g., by checking whther the message is signed and if so, is the signature identical with the one used for unlocking? See? It's so ugly!

Did you even read the BIP or are you just spouting nonsense based on the one sentence summary?

Conveniently, the BIP addresses this. Wallets without script interpreters can use template matching and verify the common, standards scripts. If it finds a script that it is unable to verify, then it should return a result of "inconclusive". A template matching verifier can look at the address it is given and understand what data to expect.

So third party wallets and services can implement the common single key, multisig, lightning htlc, etc. scripts and probably get 99% of the signed messages. It's not that hard to figure out.

Where is this being claimed? I don't see that in the BIP text anywhere. And just so you know, if you heard this from luke-jr, not every opinion that luke-jr has is shared by other developers (or anyone else).

And how does BIP 322 fail to do this? You do know that you can sign arbitrary messages, right? You do know that tying to specific UTXOs is an optional feature of BIP 322, not a requirement? Frankly, it sounds like you did not read the BIP at all and are getting your entire understanding of it based on what other people are saying about it, or perhaps you read it and just failed to understand it.

Who said anything about ignoring your message? How does Bitcoin script not have authenticity or non-repudiation?

It is just true for Bitcoin Core, how is it supposed to be implemented by third party wallets and services, or maybe it is never going to happen, right?

It is not a failure of our old friend, it is part of the specification. Tying transactions to signatures, is a new feature, adding new features is always possible, but specific measures should be taken both in the definition of the requirements and in the design process.
On the other hand, for now, this 'new feature' is suspected to be artificially invented for justifying the "sign-by-script" idea, where, as I've mentioned before, it claims:
Tying a message to a txo as metadata, is the only relevant application of message signing with bitcoin keys.
Which is absolutely wrong:
First and foremost, this so-called 'tying metadata'(!) is not that important, if it is relevant at all, in the context of 'signing'. The common application is, and has always been, proving authenticity, data integrity and non-repudiability of a message, using bitcoin keys with a possible reference to a txo in the blockchain, if the owner finds sych a reference useful. i.e., the main application is using bitcoin as a public key infrastructure. In the concrete world we are living in, (not the abstract world created by the above claim) signed messages are not supposed to be 'metadata' of a txn, signing is not binding anything to any other thing. It is just about authenticity and other characteristics we mentioned above.

it is not a use-case, just an imaginary scenario, projected from the solution domain to the problem domain, in an upside-down world. Interestingly, even this "use-case" is not fulfilled by the design:
I provide your application with a utxo reference and a proof bound to some message as being a "sign-by script" BIP322, convincing it, your app. that I'm able to unlock the said utxo, right?
Now what? Your application decides to give me a credit or something, either with respect to or ifnoring the content of my message? Who am I? The one who provided the proof? How this scheme is supposed to resist a simple man-in-the middle attack? What happened to authenticity? What about non-repudiation?
About branches being irrelevant the way you put it:
I'm afraid, you are missing the point; Once you abandon the original meaning of signing a message in favor of "tying metadata to a txo", by using scripts instead of  keys,  you have no choice other than processing/using this metadata, someday, somehow (otherwise it deserves no label other than "absurd"), hence you need to know how viable this metadata is, and how exactly the unlock process has taken place.
The point being that, you have no clue about the script under consideration, you shouldn't have such a clue, the whole scheme falls apart with such a dependency. It is why this scheme never works as a general signing mechanism, it is a dependent, application specific, utility which by no standard is supposed to be called a "signing" mechanism. It has nothing to do with signing per se.

Please stay focused a bit more, it is just the beginning of my criticism:
Even the loose defined concept of "binding metadata to UTXOs" being considered a serious application, it doesn't force us to adopt BIP322!

Engineers would merge it with established ES concept, (making lemonade with the lemon) by applying 3 constraints:

1- Restricting the problem domain to well-formed, standard scripts, either built in or external.

2- Restricting the message to be well-formed in an application specific sense, though.

3- Enforcing general compatibility of the metadata under consideration to be authenticated, non-repudiable, integrated using a supported ES scheme with explicitly distinguished public key(s).

Now, it'd be easy to implement without ruining everything in the name of generalization or abstraction, one should take care of such practices not to go excessively wild, turning to be useless and absurd.

You can check the author of BIP-322: "Karl-Johan Alm <[email protected]>".

You can ignore BIP-322, and focus on Bitcoin Message instead. Then, you will notice, why it is incomplete:
1) It is defined only for P2PKH legacy addresses. If you have any other public key, you have to convert it into legacy format first, and then validate it.
2) It is limited only to legacy ECDSA signatures. You cannot easily make it compatible with Schnorr signatures and Taproot addresses. In practice, handling Taproot at all is hard inside Bitcoin Message, because P2TR is a combination of pay-to-public-key and pay-to-script. You can limit it into public keys, but even then you have to invent a new version or something to distinguish between legacy ECDSA signatures and Schnorr signatures.
3) It cannot be used to validate outputs produced by the Lightning Network. If something is timelocked, then Bitcoin Message cannot handle it properly. You need to define another version for handling HTLCs, and nothing else.
4) It cannot be used to validate signatures for a combination of some public key and some preimage. If you have "OP_SHA256 OP_EQUALVERIFY OP_CHECKSIG", then it is spendable by providing " " in the input.
5) Each and every new script will require modifying Bitcoin Message to handle it separately.

So, it is all about expanding Bitcoin Message. It can handle legacy ECDSA signatures, and pretty much nothing else. So if you made any kind of Bitcoin contract by using Script, then Bitcoin Message cannot handle it properly. On the other hand, if there would be another soft-fork, that would define Segwit addresses for version two, then BIP-322 can be easily extended to cover that. But when it comes to Bitcoin Message, it is very limited, and you will endlessly reach the same problem every time, when you will see any new kind of Script.

Edit: Also, it is hard to make sidechains without things like BIP-322: you have to interpret the Script, in other case you will end up in a chain, where you can move coins in, only if you move them to some public-key-based-address first. So, depositing coins from Lightning Network to the sidechain is impossible if you cannot handle 2-of-2 multisig correctly.

Several people, actually. And no, it is not trolling, because it's useful.

Not a twin or separate implementation, rather it is the script interpreter. The implementation in Bitcoin Core uses the actual script interpreter used for actual script verification.

That's true of the old message signing method too.

In the original message signing, you get a pubkey out at the end, not an address, a pubkey. An intelligent app/human must convert that pubkey into an address and compare it against the address that they were given. Depending on your verification software, you may have to do this comparison manually, Or the software might do it for you.

Furthermore, there are actually 3 addresses an ECDSA pubkey can become, so how do you know which the signer intends? Neither the original message signing nor it's extension in BIP 137 can guarantee that the address you are given is actually the address that the signer intended to sign with. The signature does not cover the component that indicates the address type, so how do you know that the signature and address weren't modified in flight to be one of the other address types? You can't be sure that the signer actually is capable of comprehending segwit, or that they know the redeemScript for p2sh wrapped segwit. The signature leaves a ton of ambiguity there and no amount of intelligent app/human can resolve that. So actually, it doesn't "work fine" at all.

Not all cases require inspection of the script either. One of the main use cases I've seen for message signing is to prove that a person has the ability to spend coins sent to the address. It doesn't matter which branch is used in the script to prove that because any branch can spend the coins. If you do want to determine that a particular branch was used, then yes, you do need to inspect the script. However tools like Miniscript make this much easier to do as it can lift script into a more human readable form, along with interpreting the witness to determine which branch was taken.

You seem to have gotten BIP 322 and original message signing mixed up here. In original message signing, you have to figure out the address from the pubkey and compare it to what you are given. In BIP 322, it just fails if the address provided is wrong.

In BIP 322, you don't provide the first to_spend transaction that would contain the output script. Rather you give the address, and the to_spend transaction is computed from that, with the output script being filled in from the address. When script verification is run, it needs the output script in order to work, and the wrong script means that the whole thing will fail. No intelligence required on the user. No need to check the address separately from the verification algorithm described in the BIP. This is, in fact, a more meaningful result for just P2KH addresses than the original message signing. It guarantees that the signer signed with that address because script verification requires signing the output script.

This looks to me as being totally absurd, a byproduct of trolling. Who suggested it in the first place?  

According to the latest version of  BIP322, a twin of bitcoin script interpreter, verifies that a stupid, fake txn is supplied with appropriate witness data for unlocking its first input, which is a real outpoint of a real transaction, a message is supposed to be signed in this process, hence, 'tied' to the said outpoint. So, what this 'tying' implies?!  Nothing! It has has no meaning without examining the witness data more closely by an intelligent app/human being, interested in questions like what follows:
Is there any actual signature? How many signers? Are the signers, if any, the sole entities able to unlock the outpoint under consideration? If No, are they primarily supposed to be the normal destination, or they are relevant because of a backup branch in the script?
Without specific answers to such questions, the 'tie' established by "script signing" is worthless, bears no information, applies to no real use-case.

Oppositely and in a sharp contrast, for our, plain, old, (troll-frree) message signing, a verifier is absolutely convinced that an explicit, pseudonymous owner of a given outpoint has signed a message. Period.
You can't feed it a P2SH address, obviously, but when it accepts an input, it works fine, producing a meaningful result, unlike BIP322 scheme which fails to do it in any case, even with P2KH addresses! You have to check the address to be P2KH intelligently.
Believe it or not, your fancy BIP322 verifier should give you heads-ups, for your security when using it:

Warning:
This message is signed using a P2SH script, to understand what it means to be signed by the specific script behind this address,  you need to examine the script personally or using an AI powered application!

Warning:
This message was signed by a P2KH standard script, you are so lucky because you are able to understand what is the relation between the outpoint and the signed message, congratulations!


For our plain old message signing buddy, no further intelligent assistance is required.
Either a signed message is generated, and you can happily rely on it, or there is no confusing, meaningless signed message at all!  Though a  hypothetical extension to it is feasible, even necessary (Once upon a time, it was OP's agenda, but he eventually preferred not to stand by it, why should he? you want to have a BIP, don't you? Is it rational to mess with BIG guys?),  for supporting other opcodes, especially P2SH,P2WSH, ... are acceptable as long as the script behind them follows a standardized template that allows the same sharp semantics to be implied by signing a message.

It would be the only true generalization which complies with a software engineering design pattern that prunes wild trees of imagination, restricts supported features and utilities to be coherent and consistent, unlike BIP322 which is nothing more than a subjective generalization that fails to meet basic requirements.





Disclaimer:
Annoying content, avoid reading if you are not in the mood.

Trolling, was a start but the reason (this derailed version of) BIP322 and specially the absurd sign-by-script slogan, got traction, was elitism which takes a while to be thoroughly assessed and analyzed for a dedicated group of researchers including social-psychiatrists, software engineers/architects, and other experts with background in studying micro-cultures. I'd happily accept a $$$$$$ grant for assembling and leading a team for such research, BTW.

A preliminary insight:
In a micro-culture, people mostly follow memes, no questions asked, no brain activity, kinda resembling dementia. Unlike patterns which are followed consciously and intelligently, for memes it is all about unconsciousness and ignorance:  something that is said carelessly, e.g., in an act of trolling, is found to be pleasant, ensuring, funny, ... then it is relayed and resonated to become a meme:

Bitcoin script is an electronic signature! (Good! Pleasant! We are using a superior technology!)

We actually sign by script when we use ESDSA to sign messages with bitcoin keys! (Pleasant! Ensuring! We are so much talented, we do abstractions and generalizations like nobody else in the planet!)

Let's go wild: sign/verify everything using our beautiful script interpreter! (Ensuring! Funny, We are exceptional coders! We will have so much fun writing (stupid) super codes that cover everything forever!)

Nonsense, crazy illusions, insulting 'others', claiming superiority, blah, blah. (Funny! As much as it strengthens our brotherhood, we enjoy it!)

I think the best way to start with this is to write a small BIP322 signing and verifying program, and then a full-scale script interpreter can come later. It's going to be subject to change since it's still a draft, but we get the advantage of getting a peer-reviewed (C++) library.

I think it is just the scriptSig, because the full signed transaction can be constructed from other data. It is always created in the same way, so if you change for example transaction version, it will be considered invalid by BIP-322.

For that reason I think you could start with concatenating constants. You don't need the full script to create "76a914

88ac", you don't need to know, what does it mean 0x76. You don't have to know it is OP_DUP. Many fields are constant, you can concatenate them first, and expand your implementation later. And I think it is better to start with some BIP-322-compatible placeholders like 0x76 than pick your own format, and then think hard how to expand it. If you start from Bitcoin Message and expand it, you will end up in a situation, where you will get Bitcoin Message compatibility, but the whole BIP will be more complex than BIP-322 if you will expand it step-by-step to cover signing scripts. So, making it a subset of BIP-322 is easier if you consider future expansion.

So, the transaction-based signed messages are very powerful in that regard. But with great power comes with great complexity, and often times people will simply want to create a transaction-based signed message from whatever address they are using. (Simple accomplishes this already. I was going to ask why Legacy didn't include BIP137 signatures, but now I have my answer.)


What is this? The full signed transaction or just the scriptSig?

Yes. We need two transactions, because coins should be first created, and then spent. It is possible to handle everything in a single transaction, but then, it is hard to expand it in the future. For example, if you have SIGHASH_ALL, then everything is signed, including some invalid transaction input, so that would be safe in a single transaction. But if you have SIGHASH_ANYONECANPAY, then only one input is signed, and by doing that, your signature would be valid on-chain, even if you would have some invalid transaction input attached somewhere. For that reason, to provide full functionality, it is needed to use two transactions.

Also, using both of them makes it easier to extend this scheme in the future, if SIGHASH_PREVOUT_SOMETHING will be introduced, and if it will modify signed , then knowing the previous transaction is needed to correctly prepare the message to sign. It is wise to control how coins are created, because then this scheme could be even more expanded, for example it could be recursive, then some signature will be valid only if someone else made a valid BIP-322 signature. Or, it could be possible to make it network-dependent, for example this to_sign transaction could be more expanded, and require N valid inputs, then it is possible to make a valid signature, only if N people agreed to create coins to sign.

So, now things are clear to me (at least for the the "to_spend" transaction) - we can now distribute two fields of message and that particularly-constructed transaction.

The worms then, seem to be coming from the "to_sign" transaction, because it is one that has the "to_spend" transaction input (which itself has an invalid transaction input), so the transaction verifier needs to be custom here.

Well, if we want to get it in a backward-compatible way, then OP_CHECKDATASIG is the way to go. But if we want to avoid introducing another opcode, then we could just use " OP_CHECKSIG", and always assume that OP_CHECKSIG will be checked with "Bitcoin Message" as z-value. But as the whole point is to make a signature without moving on-chain coins, I think even introducing OP_CHECKDATASIG is not a problem in this case, and can be beneficial, because then it would guarantee that such signed transaction will be invalid on-chain. For example, we could use " OP_RESERVED", and then treat OP_RESERVED as OP_CHECKDATASIG, it will guarantee that it will be invalid if used on-chain, and will nicely remain valid, when not executed, and when it would be skipped by "OP_0 OP_IF ... OP_ENDIF".

But with doing that we'd be back at the beginning with what BIP137 already offers and almost all wallets already have an implementation for. Besides what you suggests sounds like requiring some hard coded values which means it will be a dirty code that won't be scalable which is the opposite of what we want in any new algorithm in my opinion.

OP,

In BIP322 discussions in Github, Greg Maxwell argues:
Unfortunately, this is not correct as there is no such a digital signature scheme in the world, Maxwell is just inventing it. I don't want to dig it too much, asking why anybody should make such an attempt, it would be very interesting topic per se, but for the purpose of this discussion, it is very important to understand what this "sign by script" thing is saying: it claims kinda superiority, being more pure and generalized than conventional ES systems. From this, one should be able to understand BIP322, how it changed the course to become what it is now, what it wants to do, and why it is not implemented.

What is it?
BIP322 in its latest form and after the Maxwell's comment, wants to implement the illusive bitcoin script digital signature, How? Andrew described it above thread: A fake bitcoin transaction is generated and signed that follows a specific convention, in this txn, one outpoint of a real txn (unspent or spent in the blockchain or not even published yet) is virtually 'spent' hence the signer proves that he is the one who 'can do it'.

What is the use-case?
Well, in the same comment,  Maxwell suggests:
IOW, if you want to prove that you have unlocked, are able to unlock, will be able to unlock a script you should use bitcoin script.

But how correct this idea of use cases is? Well, not much.

Foremost, signing with bitcoin addresses is not limited to what Maxwell enlists, actually what he probably considers as a dumb reason, is the mainstream: we sign messages to prove authenticity while bragging with our bitcoin identity, the funds that are bound/have been bound to the address are not relevant in 99% cases what he considers as being dumb!

Even when funds are important, there is no reason to over generalize the case, the traditional sniffing out an address from the script is how you should deal with the problem as long as the script is standard, and both signing and verification can be trivially done using templates and placeholders, etc.
What about more sophisticated scripts?  
It is where you need to use your engineering skill: rip it out from the problem domain! Ignore it as a legitimate use-case, ask people, not to ask such 'dumb' things!  
Why? To avoid going down the rabbit hole and to be practical enough for the solution to be actually implemented and used, in the real world, I need to
emphasis.

But we could get there incrementally. For example, validating P2PKH in BIP-322-compatible way is just a matter of getting some address, putting "76a914

88ac" in some field, and then it is only about hashing and concatenating some constants. So, for each Bitcoin-Message-based signature, it can be converted into BIP-322-compatible signature, and it would require only concatenating some constants, and hashing different things, but as long as some implementation allows concatenation and hashing, no more things are needed, and other cases could be handled as "not implemented", and then added later.

So, I think we should start with some BIP-322-compatible signatures, and then extend them incrementally.

No.

Signing with BIP 322 is signing a transaction except that the transaction contains explicitly invalid inputs so that it cannot be used as a real transction. It is not a signature in the cryptographic sense because just signatures themselves are incompatible with the vast majority of Bitcoin scripts. Rather it requires the entire witness in order to validate the script, which may or may not include signatures, depending on the script. Verifiers must execute the script in order to determine whether the "signature" is valid. It is more than just checking data in fields. Bitcoin operates with a scripting system, so any proof method that wants to allow message "signing" for arbitrary scripts must have a script interpreter.

The aforementioned scripts often contain cryptographic signatures because signatures prevent Bitcoin from being taken when making actual Bitcoin transactions.

That's impossible in my opinion because BIP322 and any similar proposal requires a lot of script related code that majority of tools don't have. For example Electrum as one of the most popular SPV clients doesn't really support scripts (it has a minimal implementation of it). Implementing the script interpreter (even small parts of it like OP_IF) is also difficult since the interpreter is not fully documented and it is a large amount of code.