Re: [bitcoin-dev] Hardware wallets and "advanced" Bitcoin features
Hi Antoine, and Kevin, >> * Proposed improvement: The HW should display the Bitcoin Script itself when >> possible (including the unlock conditions). > > What level of script literacy are you assuming on your users ? I can see > enterprise/hobbyist folks to know enough of Script to understand the intended > behavior but I don't think that's a reasonable assumption for your average > user. Of course, Miniscript Policy makes things easier, but IMHO, I still > hope to see some mature, higher-level language (e.g Ivy) to ease script > semantic understanding and thus widen the crowd of users. No Script literacy should be assumed. I believe with Miniscript Policy (with possibly alias instead of pubkeys, see below) we are to the highest possible level of abstraction without loss of meaning for user verification. I don't think Ivy would be helpful here. Also, as Kevin mentioned, anything would be better than an address anyways. > Further, I would do a bit on UX research on the correctness model expected by > your users. I.e if they fail to verify accordingly, are they losing funds, > transaction doesn't confirm, transaction doesn't even propagate, etc. You > should also make assumptions on the mental resources you're required from > them. Time-sensitive L2 protocols have a wide scope to check, e.g not > verifying the nSequence/nLocktime fields can provoke funds failures. Regarding the correctness, with the OP threat model (laptop compromised), for any transaction: if they fail to verify the locking policy, fund loss. Re nSeq: If we trust the HM, and the HM support Miniscript, it must be able to satisfy inputs in a sa[n,f]e way. >> This applies to pre-signed transaction protocols especially well as the >> template of these transactions could be known > and recognized by the HW. Typically for Revault, the HW could display: > "Unvault Transaction, all expected pubkeys > present in the script". > > In the future, I would expect templates of high-security protocols like > vaults to be part of the trusted computing base of any decent HW. I think > good standards there would avoid HW vendors to come with some kind of > certified-templates scheme and thus having to bless custom scripts of every > vaults implementations. +1 >> Then there is PSBT support and the maximum transaction size limit for > these: we need more transparency from HW manufacturers on their li > mitations. > > I understand them, Script is full of subtleties, taproot is likely to have > more of them and if you take sighash malleability that's not something you > want your average user to play with. Maybe it > would be better to come up with a first wave of script features on which you > expect transparency ? For sure, OP_CSV is a good candidate. I agree that rather than supporting all of Script it would be better to support a "safe", analyzable subset of Script: that's Miniscript :p I also believe supporting any new Script capabilities without Miniscript would be a huge footgun. It would also ease the upgrade to Tapscript. >> Once any input of a (pre-signed)transaction is > spent, this transaction isn't valid anymore. Most pre-signed transactions > protocols are used today as a form of defense > mechanism, spending any input would mean incapacitating the entire defense > mechanism. > > I don't see the exact issue here. E.g in Lightning, even if you pre-sign a > justice transaction punishing every revokeable outputs on counterparty > transaction, and one input is spent, will current HWs prevent you to-resign > an updated justice transaction ? That's because in Revault we don't require HMs for watchtowers. Funds holders are expected to have a routine signing of cancel / deterrent / unvault transactions and share them with the watchtowers. The attack Kevin is talking about is a (expected-to-be-stateless) HM will happily sign a cancel of deterrent transaction that spends an already-signed input. So let's say a fund holder sends a signature for an Unvault tx and a Cancel tx that does not spend this Unvault to their watchtower. The watchtower would cringe (in our v0 protocol, send an NACK): but the NACK isn't handled by the HM therefore at the end of the day the already-compromised laptop is ensuring the (statefull) validity of the signature. Thanks, Antoine > Le jeu. 14 janv. 2021 à 13:46, Kevin Loaec via bitcoin-dev > a écrit : > >> Hello everyone, >> >> I would like to start a discussion on improving Hardware Wallets. >> >> My approach to this right now is from a vault protocol we are developing >> (Revault, [1]), and its Hardware Wallet >> requirements. I started working on a Github Issue in our repo [2], other >> people recommended us to do a more general >> discussion on the mailing list instead as it could benefit many other >> protocols and users. >> This email discusses improvements that would benefit everyone, and some that >> are more suitable for "layer 2" or pre- >> signed transactions proto
Re: [bitcoin-dev] Bech32m BIP: new checksum, and usage for segwit address
Hi all, A few updates, in response to comments here and in a few other places: - Updated several reference implementations (C, C++, Python, Javascript) to support Bech32m: https://github.com/sipa/bech32/tree/bech32m (but contributions to update other languages are welcome!) - Updated website, including error-locating JS decoder, and demo: http://bitcoin.sipa.be/bech32/demo/demo.html - Opened a Bitcoin Core PR: https://github.com/bitcoin/bitcoin/pull/20861 - Updates to the BIP draft (https://github.com/sipa/bips/blob/bip-bech32m/bip-bech32m.mediawiki): * Made the title clearer (so it doesn't imply Bech32m is used for v0) * Added rationale for not permitting both Bech32 and Bech32m for v0 * Added a section on error location * Added links for more reference implementations On Friday, January 15, 2021 12:01 AM, nakagat wrote: > I read the BIP draft of Bech32m and implemented it in Go. Cool! Do feel like contributing it to https://github.com/sipa/bech32/tree/bech32m? > Let me ask you one question. > Does Checksum have to be fixed? > The 'bech32_verify_checksum' function has hrp and data as parameters, > so how about committing Checksum with these two values? > > For example, calculate Checksum from hrp and data using hash, chacha20, etc. I'm not entirely sure what you mean. Do you mean: 1) Can we use a hash function to compute the checksum instead of Bech32's algorithm? If you compute the checksum using the HRP and the data using a hash function, you just 2^-30 failure probability for any error. The idea behind Bech32 was doing better than that for common errors: any error that consists of up to 4 substitutions are a failure probability of 0 - far better than a hash can do. 2) Can we keep using Bech32's algorithm, but compute the final xorred-in constant from the HRP and the data using a hash function? That would be functionally equivalent to (1). 3) Can we keep using Bech32's algorithm, but compute the final xorred-in constant from the HRP (but not the data) using a hash function? It would mean that some (very) small set of potential HRPs would exhibit much worse behavior than others - including the 'q'-before-'p' that the original Bech32 has. Does that clarify things? Cheers, -- Pieter ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bech32m BIP: new checksum, and usage for segwit address
Dear. Peter, I'm not good at English, so I'm sorry for the poor explanation. I thought that BECH32M_CONST could be created from hrp and data instead of constants. I thought that the error position would be the same as bech32 by recalculating the value created from hrp and data. If this were possible, I thought I could commit hrp and data to the checksum. Thank you. Takatoshi Nakagawa 2021年1月18日(月) 13:15 Pieter Wuille : > > Hi all, > > A few updates, in response to comments here and in a few other places: > > - Updated several reference implementations (C, C++, Python, Javascript) to > support Bech32m: https://github.com/sipa/bech32/tree/bech32m (but > contributions to update other languages are welcome!) > > - Updated website, including error-locating JS decoder, and demo: > http://bitcoin.sipa.be/bech32/demo/demo.html > > - Opened a Bitcoin Core PR: https://github.com/bitcoin/bitcoin/pull/20861 > > - Updates to the BIP draft > (https://github.com/sipa/bips/blob/bip-bech32m/bip-bech32m.mediawiki): > * Made the title clearer (so it doesn't imply Bech32m is used for v0) > * Added rationale for not permitting both Bech32 and Bech32m for v0 > * Added a section on error location > * Added links for more reference implementations > > On Friday, January 15, 2021 12:01 AM, nakagat wrote: > > > I read the BIP draft of Bech32m and implemented it in Go. > > Cool! Do feel like contributing it to > https://github.com/sipa/bech32/tree/bech32m? > > > Let me ask you one question. > > Does Checksum have to be fixed? > > The 'bech32_verify_checksum' function has hrp and data as parameters, > > so how about committing Checksum with these two values? > > > > For example, calculate Checksum from hrp and data using hash, chacha20, etc. > > I'm not entirely sure what you mean. Do you mean: > > 1) Can we use a hash function to compute the checksum instead of Bech32's > algorithm? > > If you compute the checksum using the HRP and the data using a hash function, > you just 2^-30 failure probability for any error. The idea behind Bech32 was > doing better than that for common errors: any error that consists of up to 4 > substitutions are a failure probability of 0 - far better than a hash can do. > > 2) Can we keep using Bech32's algorithm, but compute the final xorred-in > constant from the HRP and the data using a hash function? > > That would be functionally equivalent to (1). > > 3) Can we keep using Bech32's algorithm, but compute the final xorred-in > constant from the HRP (but not the data) using a hash function? > > It would mean that some (very) small set of potential HRPs would exhibit much > worse behavior than others - including the 'q'-before-'p' that the original > Bech32 has. > > Does that clarify things? > > Cheers, > > -- > Pieter > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
