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.
Topic: BIP 322 draft design and improvement thread - page 4. (Read 952 times)
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?
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?
Jump to: