rich1.0npub17cwk7hm623dm5npjzu8cvv994h43k2keanegs8w78xyvlez8hqqsqqmtzyhttps://nostr.ae/npub17cwk7hm623dm5npjzu8cvv994h43k2keanegs8w78xyvlez8hqqsqqmtzynjumphttps://nostr.ae📅 Original date posted:2020-03-04 📝 Original message:I forgot one: ============= 5. The current BIP itself is poorly written and/or unnecessarily complex: e.g. remove the multi-proof support, and/or remove the extensibility stuff for a future proof-of-funds extension, and/or focus solely on the generic sign message stuff. ============= 6. Some other solution On Wed, Mar 4, 2020 at 3:23 PM Karl-Johan Alm <karljohan-alm at garage.co.jp> wrote: > > Hello, > > I noticed recently that a PR to Bitcoin Core that pretty much touched > everything my BIP-322 pull request touches (around the same > complexity) was merged without a thought given to BIP-322 > compatibility, despite the BIP-322 PR being open for 2x the time. I > can only conclude from this that people dislike BIP-322 in its current > form, which the 9 month old pull request stagnating can probably > attest to. > > There are several things that I can do to make this a bit more > appealing to people, which would hopefully kick the progress on this > forward. I have already put in a non-trivial amount of energy and > effort into maintaining the pull request as is, so I'd prefer if > people were harsh and unfiltered in their criticism rather than polite > and buffered, so I can beat this thing into shape (or abandon it, in > the worst case). > > ============= > 1. People use signmessage as a way to prove funds. This is misleading > and should be discouraged; throw the sign message stuff out and > replace it entirely with a prove funds system. > > I know in particular luke-jr is of this opinion, and Greg Maxwell in > https://github.com/bitcoin/bitcoin/pull/16440#issuecomment-568194168 > leans towards this opinion as well, it seems. > > ============= > 2. Use a transaction rather than a new format; make the first input's > txid the message hash to ensure the tx cannot be broadcasted. This has > the benefit of being able to provide to an existing hardware wallet > without making any modifications to its firmware. > > I think Mark Friedenbach and Johnson Lau are of this opinion, except > Johnson Lau also suggests that the signature hash is modified, see > https://github.com/bitcoin/bips/pull/725#issuecomment-420040430 -- > which defeats the benefit above since now hw wallets can no longer > sign. > > Prusnak (I think he works at Trezor; apologies if I am mistaken) is > against this idea, and proposes (3) below: > https://github.com/bitcoin/bips/pull/725#issuecomment-420210488 > > ============= > 3. Use Trezor style > > See https://github.com/trezor/trezor-mcu/issues/169 > > This has the benefit of already being adopted (which clearly BIP-322 > is failing hard at right now), but has the drawback that we can no > longer do *generic* signing; we are stuck with the exact same > limitations as in the legacy system, which we kinda wanted to fix in > the updated version. > > ============= > 4. Introduce OP_MESSAGEONLY > > Quoting Johnson Lau at > https://github.com/bitcoin/bips/pull/725#issuecomment-420421058 : > """ > OP_MESSAGEONLY means the script following the code would never be > valid. For example, a scriptPubKey: > > OP_IF OP_MESSAGEONLY <key_m> OP_ELSE <key_s> OP_ENDIF OP_CHECKSIG > > For messaging purpose, OP_MESSAGEONLY is considered as OP_NOP and is > ignored. A message could be signed with either key_m or key_s. > > For spending, only key_s is valid. > > I don't think it is a big problem to consume a op_code. If this is a > real concern, I could modify it as follow: in message system, > OP_RETURN will pop the top stack. If top stack is msg in hex, it is > ignored. Otherwise, the script fails. > """ > > ============= > 5. Some other solution