19:02:25 <achow101> #startmeeting
19:02:25 <lightningbot> Meeting started Fri Jun  5 19:02:25 2020 UTC.  The chair is achow101. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:02:25 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:02:52 <achow101> any topics?
19:03:12 <provoostenator> HWW?
19:03:19 <achow101> one thing I would like to discuss is whether we should change our signer policy for PSBTs
19:03:22 <jonatack> hi
19:03:25 <provoostenator> I haven't done much other than rebase, but happy to answer questions
19:03:31 <provoostenator> Oh yeah, that's a good one.
19:04:15 <luke-jr> achow101: presumably with a synced node, we can access the full input tx?
19:04:19 <achow101> #bitcoin-core-dev Wallet Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james amiti fjahr jeremyrubin lightlike
19:04:20 <achow101> emilengler jonatack hebasto jb55 elichai2
19:04:25 <fjahr> hi
19:04:43 <sipa> having thought about it more, i'm not sure it's worth requiring full input txn
19:05:05 <achow101> #topic HWW (provoostenator)
19:05:18 <achow101> any updates on that?
19:05:43 <achow101> FYI meshcollider broke is IRC and can't send messages
19:05:46 <provoostenator> The first PR for that is #15382
19:05:49 <gribble> https://github.com/bitcoin/bitcoin/issues/15382 | util: add runCommandParseJSON by Sjors · Pull Request #15382 · bitcoin/bitcoin · GitHub
19:05:49 <sipa> given that the same attack model (software wallet malicious, able to make the vixtim sign twice with hww) already enables the attacker to e.g. be paid twice
19:06:07 <provoostenator> And the meat is in #16546
19:06:10 <gribble> https://github.com/bitcoin/bitcoin/issues/16546 | External signer support - Wallet Box edition by Sjors · Pull Request #16546 · bitcoin/bitcoin · GitHub
19:06:39 <achow101> so just review those?
19:07:01 <provoostenator> achow101: yup
19:07:15 <provoostenator> At least as a start.
19:07:42 <achow101> cool
19:07:51 <achow101> anything you wanted to discuss right now?
19:08:05 <provoostenator> There's also some dependencies
19:08:43 <provoostenator> But I think those two PR's can be reviewed mostly without worrying about these other dependencies. Just go for them if you're bored.
19:08:59 <provoostenator> Nothing specific to discuss.
19:09:05 <phantomcircuit> hi
19:09:50 <achow101> alright
19:10:00 <achow101> #topic Changing PSBT signer policy (achow101)
19:10:24 <bitcoin-git> [13bitcoin] 15hebasto opened pull request #19180: refactor: Replace RecursiveMutex with Mutex in Shutdown() (06master...06200605-shutdown) 02https://github.com/bitcoin/bitcoin/pull/19180
19:10:51 <achow101> So there was the whole announcement from trezor 2 days ago about the thing in segwit where a signer could be tricked into sending money into fees
19:11:10 <achow101> and they're requiring full prevtxs (i.e. non_witness_utxo) for segwit inputs
19:11:26 <achow101> do we want to do the same policy to protect against that attack?
19:11:34 <meshcollider> ping
19:11:38 <provoostenator> A less drastic measure could be for the device to remember the last couple of inputs it signed?
19:11:38 <achow101> meshcollider: pong
19:11:49 <achow101> it seems that sipa doesn't think so
19:12:05 <sipa> provoostenator: i'd say that's far more drastic, but it's also the only real solution
19:12:06 <meshcollider> Yay it's working finally
19:12:08 <meshcollider> Sorry about that
19:12:26 <achow101> provoostenator: I think that would require more storage than they have
19:12:51 <luke-jr> sipa: why is just including the inputs not a solution?
19:13:15 <sipa> luke-jr: that doesn't prevent double paying
19:13:15 <provoostenator> Not having giant PSBT files was a nice improvement...
19:13:24 <sipa> luke-jr: it prevents this specific attack
19:13:55 <sipa> but it doesn't prevent the victim fr being told "your signature is invalid, try again" and then just paying the attacker twice
19:14:06 <luke-jr> well, that's social engineering
19:14:18 <achow101> sipa: but that would be new inputs, so remembering previous inputs wouldn't matter
19:14:27 <luke-jr> achow101: remembering the address could
19:14:33 <luke-jr> ie, strictly forbid address reuse
19:14:46 <luke-jr> but social engineers can probably work around that too
19:15:15 <provoostenator> So the attack mentioned, it doesn't matter who you were paying to? Or does the attacker have to be the recipient?
19:15:19 <sipa> luke-jr: right, it is - but my point is that if "attacker can convince the victim to sign twice" is part of the threat model, then this attack isn't the only problem
19:15:37 <luke-jr> hmm, true
19:15:38 <sipa> and this specific attack can be worked around, but others can't be with stateless HWW
19:15:44 <achow101> provoostenator: it doesn't matter. the amount lost was going to fees
19:16:10 <provoostenator> Right, so I don't think a spend-twice bug is fully comparable
19:16:18 <luke-jr> the recipient does need to be the same address, though, right?
19:16:33 <gwillen> that depends on whether the victim is looking at the address
19:16:34 <sipa> for the currently-discussed attack, yes
19:16:52 <gwillen> we're already positing they're signing twice even though they're only sending one transaction, so it's already got a social engineering component
19:16:52 <provoostenator> If the victim doesn't look at the address, they're toast regardless.
19:17:16 <gwillen> but, this is true, "oops please retry" is a much smaller social-engineering ask
19:17:30 <sipa> gwillen: than what?
19:17:31 <provoostenator> Once your computer has the kind of the malware that can do that, it can do so many things...
19:17:45 <luke-jr> deterministic input sorting could fix this too I think?
19:18:00 <sipa> luke-jr: i don't think so
19:18:06 <provoostenator> It can fool your browser, fool the UI of your wallet where you "check"  the address, mess with clipboard, alter the chain on disk.
19:18:09 <luke-jr> provoostenator: but otoh, malware on your comnputer is what hw wallets claim to protect against
19:18:24 <provoostenator> luke-jr: they do, but only to a limited extend
19:18:35 <provoostenator> They can't trivially run off with your private keys
19:18:55 <achow101> this attack already has a strong social engineering component in convincing the user to sign twice
19:18:58 <provoostenator> But if you just let someone take over your computer long enough..
19:20:41 <provoostenator> Would it help to store block height as a nonce?
19:20:45 <gwillen> achow101: people are used to things like that, though, so I think most people unaware of the attack would fall for it, even if they're otherwise careful
19:20:49 <provoostenator> nLockTime I mean
19:20:59 <gwillen> (for example, you would have to do that if USB flaked out, probably)
19:21:35 <gwillen> the coldcard has a big advantage if you're having to carry the transaction across by hand each time vs just spitting it over USB
19:21:47 <gwillen> this attack really does not work in that setting
19:22:22 <sipa> i think the only feasible solution is education really
19:22:35 <sipa> of course fixing this specific bug is a good thing of it comes at no cost
19:22:53 <sipa> but i'm unconvinced breaking "only need utxo to sign" is worth it
19:23:00 <achow101> sipa: education as in educating users they should inspect their transactions before sending?
19:23:18 <sipa> that they should be wary if they're told to retry signimg
19:23:19 <provoostenator> For the RPC it's cheap to add an opt-in feature to fill in the UTXO for SegWit, for GUI I would find it cluttery.
19:23:44 <sipa> oh we should add the full input tx where possible, i think
19:23:52 <sipa> for bitcoin core this is easy to do
19:24:03 <achow101> to be compatible with latest firmwares that fix this, we still need to add the full input tx
19:24:17 <sipa> but i'm not sure about requiring full input tx when signing
19:24:17 <luke-jr> add it, but don't require it to sign
19:24:20 <achow101> this does break compatibility with previous versions of Core and HWI
19:24:27 <luke-jr> is I think what sipa's saying
19:24:41 <achow101> right
19:24:46 <sipa> indeed
19:24:53 <achow101> ack
19:25:03 <sipa> unless we can get trezor to reverse their stance
19:25:09 <sipa> which seems unlikely
19:25:43 <luke-jr> it may be more likely than you assume
19:25:59 <achow101> i believe trezor, ledger, bitbox, and coldcard have/will have the same requirement to provide the full previous tx
19:26:16 <luke-jr> it's *possible* (but not certain) that the motive is to get another security fix released without drawing attention to it
19:26:22 <sipa> if that happens we have no choicw to follow suit
19:26:22 <achow101> although I think ledger does something where they allow single input segwit without full prevtx
19:26:35 <sipa> +but
19:26:45 <gwillen> achow101: I was under the impression that hww other than trezor were making this a user option at most
19:27:18 <achow101> gwillen: i've been working through a bunch of trezor issues over the past couple of days, so I havnen't had the change to test out ledger's changes
19:27:34 <achow101> coldcard hasn't published a new firmware yet but I'm told they probably will
19:27:50 <jonatack> luke-jr: not entirely implausible given how it was handled
19:28:39 <achow101> luke-jr: then they did a real poor job of it by giving users a good reason to not upgrade.
19:29:26 <luke-jr> achow101: are users getting that impression?
19:29:30 <jonatack> makes 2 recent trezor upgrades now that were better to avoid
19:29:59 <achow101> luke-jr: yes. electrum, wasabi, and btcpay server no longer work with the new firmware. so users who want to keep using those software with their trezors are incentivized to not upgrade
19:30:13 <provoostenator> What happens when you do add the full input tx, and give it to an non-upgrade hardware wallet?
19:30:52 <achow101> provoostenator: usually they're fine with it. but HWI makes some assumptions about that so it makes the wrong signature
19:31:10 <provoostenator> Updating HWI is probably the easiest part.
19:31:20 <sipa> i have to run for a bit, will be back in 10-15 or so
19:31:20 <achow101> provoostenator: you would think so....
19:31:21 <provoostenator> Even if we added support for this, it'd be a while before a release / backport.
19:32:19 <achow101> right
19:32:22 <luke-jr> provoostenator: that's up to us
19:32:57 <provoostenator> True
19:33:57 <achow101> any other topics?
19:35:57 <achow101> seems not
19:36:00 <achow101> #endmeeting