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

What is "proof of sent-transaction" problem? You can always make " OP_DROP OP_CHECKSIG" output, and prepare a signature for that. Checking if any such thing is connected with real, on-chain coins, is up to the recipient of such signature. Also, you can have just " OP_CHECKSIG", and your R-value of your signature could be converted to a Taproot address, and then you can provide "OP_RETURN " TapScript for such key. I wonder what this "proof of sent-transaction" is about: is it about providing OP_CHECKDATASIG functionality?

Quote

2. How is all this going to be implemented without excessive classes and libs (code bloat).

By specifying the script for each address type, and then by concatenating it with some BIP-defined constants, and hashing the result. From your BIP perspective, you don't have to describe that "there is transaction version equal to zero". You can say "just concatenate this data", and redirect people to BIP-322 to learn more, why those constants were picked.

Quote

why don't they support BIP137 in this area since it was finalized years ago?

Because it cannot be easily extended to signing any script.

Quote

It needs a UTXO set, something that is not trivial to get without the address of a full node (unless the software is a full node itself!)

It doesn't. The recipient is responsible for checking if some UTXO is spent or not. So, that recipient could have full node, could use SPV node, could check it in some block explorer, or could skip that at all, if the only purpose is to know, if someone can "control" a given key. For many people, checking that "I love pancakes." message matches some public key, is sufficient. So, it is possible to create a standard, where basic verification can be performed entirely offline, and when the recipient could get more advanced verification by being online, or by providing more information, for example "I want to verify it offline, and I want to assume that is a valid output". Another thing is that storing the whole chain is not needed, you can limit it to knowing only transactions, then it would be possible to support SIGHASH_PREVOUT_SOMETHING in the future.

Quote

How should we cope with such situations such as the one above? Should other wallets shave off the parts they can't implement without access to a full node?

Exactly. If you are offline, and you sign a multisig transaction, you can get a valid signature, and also you can get a boolean value saying that it is incomplete. The same could be here: you could get more detailed verification than yes/no. You can get "valid signature", "valid UTXO", "valid something else", etc., it could depend, how many things you want to verify, it could be decided by the recipient, and the program could return "more information needed" when something is missing, or could return "unsupported script type" if something is not implemented.

Quote

Is it true that people will only need to make a hash of the "transaction" in the signing part?

Yes.

Quote

Is there not at least a check that the transaction hashes to something correct [and is then distributed with the sig, otherwise it would be malleable]?

Yes, it is checked that the z-value really hashes to the computed data, otherwise it would be unsafe from ECDSA point of view, because for every public key, it is possible to compute random tuple. But you can force Bitcoin Core to sign any transaction, so it could be possible to also force it to verify any transaction. If you have a pruned node that has some "" in its database, then Bitcoin Core thinks it is 100% trusted data. The same with signatures: you can have some full node, and then be absolutely sure that your transaction corresponds to some existing UTXOs. But you don't have to, you can decide, how many things you want to verify.

@garlonicon:

It's not about my BIP anymore, it's about trying to make BIP322 as simple as possible for people to implement.

Is it true that people will only need to make a hash of the "transaction" in the signing part? I can't seem to find any cryptographic validation that is being done in the verifying part, for example in ECDSA we create r,s values corresponding to a public key, but with this transaction-based signature method, I only see that fields are being verified to have sane data. Is there not at least a check that the transaction hashes to something correct [and is then distributed with the sig, otherwise it would be malleable]?

You can solve it quite easily: for each address type, there is only one thing that needs to be changed: the signed message. So, you can just define it for each address type as "", then hash it, and that's all, everything else will be the same. So, you can prepare all things like transaction version, output, locktime, and all of that, to finally get it as some constants, and some script-encoded addresses inside. Then, your format will be fully BIP-322 compatible, and will allow extending it in the future, just by adding implementation for signing any scripts. For now, you can just treat any unknown script types as "unsupported" in your BIP.

The Github issue where everybody is reviewing BIP322

Notes:
One thing is certain - its ubitiquous use will not become a reality unless standalone script interpreters are made and maintained.

This is a thread for coordinating and discussing improvements for the BIP322 draft and problems that need to be addressed inside the draft. There is an active "issue" (technically speaking. But I view that as more of a "list all problems" thread) on Github where the BIP designers are trying to iron out all the creases inside the draft. Let's give them a helping hand, shall we?

Since my signing message reference manual BIP "proposal" has been rejected on the grounds that more work should be done on BIP322 to make it final (Interested viewers can read the full discussion here), I have done two things, besides locking the other thread:

- I created this page https://en.bitcoin.it/wiki/Signed_Message and salvaged the bulk of the algorithms there (all these years, and nobody thought about creating this page? NO wonder why we have divergent signing implementations. But that's not the point).

- I am redirecting efforts to BIP322, by opening threads like this for example.

---

This thread should be used as the mailing-list analogue for discussion about BIP322, a draft BIP that is supposed to make universal signed messages.

In other words, talking about BIP322, and shower thoughts about how to improve or simply it are welcome here (BIP322 suffers from only one problem and it's that the document is quite difficult for people getting on the initiative to understand, when you compare it to e.g. BIP340, or how I wrote my BIP).

Do not derail this thread with off-topic arguments. Proposals made here will be relayed to the mailing list. I am not self-moderating this thread, but if this thread gets derailed, I will lock it, and open a new, self-moderaded thread.
EDIT 2020-08-09: This is not the place to talk about why XXX proposal is better than BIP322, or vice versa, either.

---

The questions we should be asking ourselves are:

1. What exactly does BIP322 give us to solve the "proof of sent-transaction" problem
2. How is all this going to be implemented without excessive classes and libs (code bloat).

Well for 1, we see that we have "Legacy" aka. equivalent to the legacy signing format - why don't they support BIP137 in this area since it was finalized years ago? Anyway, the second format "Simple" appears to be the one that solves the bulk of the problems with message signing (the last one, "Full", is something I expect to be used only by mad computer scientists toying around with transactions because it lets you customize all the tx fields).

That leaves us with 2. On paper, it looks simple enough - provided a step-by-step guide for deriving them is created - but I am not sure how one is supposed to implement "Full (proof of funds)". It needs a UTXO set, something that is not trivial to get without the address of a full node (unless the software is a full node itself!)

How should we cope with such situations such as the one above? Should other wallets shave off the parts they can't implement without access to a full node?