Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BF006E54 for ; Thu, 5 Jul 2018 22:06:55 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f67.google.com (mail-oi0-f67.google.com [209.85.218.67]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1B05A2C4 for ; Thu, 5 Jul 2018 22:06:55 +0000 (UTC) Received: by mail-oi0-f67.google.com with SMTP id w126-v6so19782696oie.7 for ; Thu, 05 Jul 2018 15:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=du4CcZPY39ifg9WsC4cP3DvB4Ck2CHhgTcj/C3g+Gqk=; b=cGAsEV34og6/dOb/PNnRufNPDj17DTH+09gyxxf7FBzwvtBzzVLPjAFJwZMwJXAK7l pV8sQD/JcaysXGIHoM4hShPRdQRdKcOPD2xxVEANV52iWaQnOMZp1BW4w+0F0b3efRA2 WvR8HMg+SgF6EYLwT+05YcuoWiDGpPvwZUdWYAcxrDWhwKRIgj29QqHpcInkNaSX84i0 awMgJ9HvfgqO03v3EiVgFsEgzw6TQ9s8DeKfjeyfxKm0lBcbvaAnfdsYBeh76NPP0Csz x3FxFGeo3qgkDIFiJOzkt1PZC4NhzONIKDxV49UMkBPLZ/sUdt9BASP/qTeSfefZOfwt mkdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=du4CcZPY39ifg9WsC4cP3DvB4Ck2CHhgTcj/C3g+Gqk=; b=ZpXVzx+4DGtYUTVjNrygkLh5H84M+0I69iz0gsMjC+6O2qRTr/L4kCFeLYP/JxbzVy fBgcBmJcCV9XxSRu4dZ6S7GpucxM4q3z1pUn1rtVWnCXjV0d9rcZs8OGbWdOJwM789C+ DJkQYSWaYHoFweJRxw68tR8ImaAoF4SARnIpFntQtM9zwnCgnCMl/cqrYPJegLyZzAnC MvuyWWe403bCJOW5lMB53ys09Pf2ANlfzKlIh433aPkANKiunVhkHLhxq23QyzmClkNn e/BDBlfOIRanI/Gt+d7Esi8OUTTSPYspFMsxPSkU8tZc2xHs9410t5PXy2eXQwRjqefK x+kA== X-Gm-Message-State: APt69E1Me4xkwcayKUoKioIh/uIWbnDLpQaf4j8YYU9SfgLVXDW/9KSu hgR/DMzOwLAR/XY/HawtLEzNecU+dMdv8nFBx5E= X-Google-Smtp-Source: AAOMgpc2CH+KTXcoDITgfSD7zRkcWSXmgrYbJqsjHWjfX9XL899jw/ForiSqIIZVSnTr7tQrvK6CDCkJAh8tHlDuVDc= X-Received: by 2002:aca:3507:: with SMTP id c7-v6mr9184690oia.46.1530828414219; Thu, 05 Jul 2018 15:06:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:6a89:0:0:0:0:0 with HTTP; Thu, 5 Jul 2018 15:06:53 -0700 (PDT) In-Reply-To: References: <881def14-696c-3207-cf6c-49f337ccf0d1@satoshilabs.com> <95137ba3-1662-b75d-e55f-893d64c76059@satoshilabs.com> From: Pieter Wuille Date: Thu, 5 Jul 2018 15:06:53 -0700 Message-ID: To: matejcik Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] BIP 174 thoughts X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 22:06:55 -0000 On Thu, Jul 5, 2018 at 4:52 AM, matejcik wrote: >> Allowing combiners to choose any value also allows for intelligent combiners to choose the >> correct values in the case of conflicts. A smart combiner could, when combining redeem scripts >> and witness scripts, check that the redeem scripts and witness scripts match the hash provided >> in the UTXO (or in the redeem script) and choose the correct redeem script and witness script >> accordingly if there were, for some reason, a conflict there. >> >> Can you explain why it would be unsafe for combiners to arbitrarily choose a value? > > We're worried that the "pick one of non-deterministic signatures" is a > special case and that most fields don't have this property: > > * conflicts in UTXOs, sighash type, redeem/witness scripts, derivation > paths, are at best a recoverable error, usually an unrecoverable error, > at worst malicious activity. > > * conflict in finalized scripts, in case more than one valid > finalization exists, might indicate that the Finalizers picked different > ND signatures, or it might indicate two possible interpretations of the > transaction (see next point). Picking arbitrarily in the latter case > would be an error. > > * even for partial signatures: if two Signers with the same public key > use different sighash types, the Combiner shouldn't pick the winning one > arbitrarily. > > It seems generally safer to default to rejecting conflicts, and > explicitly allowing the Combiner to process them intelligently if it > understands the relevant fields. So consider two possible topologies for a multiparty signing: A) Creator and Updater produce a PSBT T. T is sent to signer 1 who turns it into PSBT T1. T1 is then forwarded to Signer 2 who turns it into T12. A Finalizer extracts the transaction. B) Creator and Updater produce a PSBT T. T is sent to signer 1 and 2 simultaneously, who then produce T1 and T2 respectively. A Combiner combines those into T12. A Finalizer extracts the transaction. The only case where "malicious" conflicting values can occur is when one of the Signers produces an invalid signature, or modifies any of the other fields already present in the PSBT for consumption by others. If this were an issue, it would be an issue regardless of the Combiner's operation, as in topology A no Combiner is even present. This is generally true I think - Combiners can always be replaced with just a different (and possibly less parallel) topology of data flow. So the question is independent of Combiners IMHO, and really about how we deal with roles that intentionally or unintentionally produce invalid values. I believe this is mostly not an issue. Let's go over the cases: * If a partial signature is invalid, the resulting transaction will be invalid. * if a non-witness UTXO is incorrect, you'll fail to sign because the txid mismatches the input's prevout (which you do have to check) * If a witness UTXO is incorrect, the resulting signature will be invalid. * If a derivation path is incorrect, the signer will fail to find the key, or sign with the wrong key resulting in an invalid transaction. * If a witnessscript or redeemscript is incorrect, the resulting signature will be invalid (as those go into the scriptCode of the sighash, and affect the type of sighashing) * If a sighash type is incorrect, the resulting transaction may be useless for its intended purpose (but still something every signer agreed to sign). So all of this boils down to dealing with the possibility that there can be roles which intentionally or unintentionally create incorrect fields in a PSBT, and the solution is (a) checking that prevout txids match non-witness utxos (b) checking that the transaction you're signing is one you want to sign (including sighash type) (c) worst case accepting that the resulting transaction may be invalid. Now, (c) can sometimes be caught early, by implementing additional sanity checks for known fields. For example, rejecting PSBTs with partial signatures that are invalid (feed them through a verifier). This is something a Combiner can of course optionally do, but so can a Signer or any other role. The bottom line is that a Combiner which picks arbitrarily in case of conflicts will never end up with something worse than what you already need to deal with. If you disregard the case of invalid fields (because the result will just be an invalid transaction), then any choice the Combiner makes is fine, because all the values it can pick from are valid. > I agree with your response, and I also think that in technical sense, > the worst that can happen is an invalid signature. Our concern is twofold: > > 1. the produced signature is most likely valid, _for a different > transaction_ than the Creator intended. It is a transaction that the > Signer must have authorized, so we could argue that they would not mind > if that unintended transaction was published. Nevertheless, this opens > an attack surface. If you're worried about attack surface, I don't believe rejecting invalid fields ever matters. An attacker can always drop the fields you don't understand before giving you the PSBT, making your behavior identical to one where you'd have ignore those fields in the first place. At best, you can make it protect against accidental mistakes that would result in invalid transactions anyway. If there is a way to sign a message in a way that can be misinterpreted as a signature on a different message with a different meaning, then that is a huge flaw in Bitcoin itself, and not going to be solved by rejecting to sign unknown fields. With regard to defense in depth: >> I would not be opposed to having fields with an explicit flag bit that >> says "Don't sign if you don't understand this", but I expect that that >> can also be left for future extensions. > > It seems safer to consider this flag be on by default, and leave it to a > future extension to allow non-mandatory fields. The worst case here is > that legacy Signers can't natively process new PSBTs (solvable by a > preprocessor) - as opposed to legacy Signers signing unintended values. There could be some rule like "if the highest bit of the field type is set, don't sign", but I don't think there is any current field where such a flag would be necessary right now. Cheers, -- Pieter