From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4FF33EEF for ; Wed, 11 Jul 2018 18:27:15 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0C6EE77E for ; Wed, 11 Jul 2018 18:27:13 +0000 (UTC) Received: by mail-oi0-f46.google.com with SMTP id k81-v6so51018385oib.4 for ; Wed, 11 Jul 2018 11:27:13 -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=X0E9+SjfvCmHj61MOeh+r/kHaDgUsPnVhE22xl+oJL0=; b=qnwrclfxfyiM6BLMb9bSwCQCuayLCSojfIa69iI4yVWSCy8jM1v32bGq2zPnEUuCLm 3kmLy4B6MkDgbwvRUU3Jlq2pQfaNoa4/vXe+i/X8cz9PxXvauMOZ8rwhnYmZMkbyFunu YOkSoXncbcrAeuNCq42996MDp5PqyJRgVdbrKpGpO+aKQRuJ6J7y71fddFdh7M3QS5Hl HKOQ3M9G/4w2S1rgoP88tlZVj7R69kqauBa6Mn8N9znQg1oZdb/vben2gfSQNVf3uiaX GsrZOKfCK45/chtvy/vccRegvxwxSaTTBwk5sIugnpVgWVxM8Xcs4a5SI1HaLkq2XIoj AQYA== 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=X0E9+SjfvCmHj61MOeh+r/kHaDgUsPnVhE22xl+oJL0=; b=PzZkPbnZcP/92B3kt3gRydYaS4VWd9L5PlOeXi3tDXXPCQi9o+nW1H7f9qQ1zLKSuZ qZqcNZW+318UinV2dk0MjmAIG0hWGF/pcbQlcKrXryv/eL3MG//Z8k9z5jIP8GONSbup h9oATzhbjaQ/aWGCKog8Nt49LGRVIn1rl8I8EBI5mLVqALV8oqqnZlqRi8vLyydpT1Xq UrmoNAyjARea5C+AWTGW9UwRRC52r3QKUEYoTUJqhUv3ma3mx4pGgcEY4mXt5yPDCL3k s8vrK316SwmgWCAdc6m8X3jovE8qXmkZd+RqAci9O1DCgXbSKzDmqAOFA/gA83ZqydiG n9oQ== X-Gm-Message-State: AOUpUlEO2uatECb2L63hltgDU+BpKmafryvBennTq/NVQuPvFZswPGTz 6uNJbxTXIjuaEb4BJIhkGhwjpIGW0cfBUQEIwPM= X-Google-Smtp-Source: AAOMgpc4p5f5EhH6OgEPjsUUJC+oIe/M04P2Xk8oYcs5ocYI7eHELTm2QR1lBKPlVtUgx2E6xXf5tPn0jrWyZGAhQU4= X-Received: by 2002:aca:5003:: with SMTP id e3-v6mr450693oib.89.1531333633091; Wed, 11 Jul 2018 11:27:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:6a89:0:0:0:0:0 with HTTP; Wed, 11 Jul 2018 11:27:11 -0700 (PDT) In-Reply-To: <797d9751-9795-55e6-35c9-61532e067d27@satoshilabs.com> References: <881def14-696c-3207-cf6c-49f337ccf0d1@satoshilabs.com> <95137ba3-1662-b75d-e55f-893d64c76059@satoshilabs.com> <797d9751-9795-55e6-35c9-61532e067d27@satoshilabs.com> From: Pieter Wuille Date: Wed, 11 Jul 2018 11:27:11 -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: Wed, 11 Jul 2018 18:27:15 -0000 On Tue, Jul 10, 2018 at 5:10 AM, matejcik wrote: > On 6.7.2018 00:06, Pieter Wuille wrote:> 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. > > This is an interesting thesis, and also an unspoken assumption ISTM. It > seems worth adding something like this to the spec: > """ > In general, the result of Combiner combining two PSBTs from independent > participants A and B should be functionally equivalent to a result > obtained from processing the original PSBT by A and then B in a sequence. > or, for participants performing fA(psbt) and fB(psbt): > Combine(fA(psbt), fB(psbt)) == fA(fB(psbt)) == fB(fA(psbt)) > """ Adding that sounds like a good idea, indeed. >> 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. > > This sounds reasonable and IMHO it would be good to have a summary of > this argument in the Rationale section. Sounds good. >> 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. > > I'm reluctant to sign an input with unknown data, on the premise that there could be *anything* in that data But the point is: you are not signing an input with unknown data. You are signing your own interpretation (since you compute the sighash yourself), which doesn't include what you don't understand. If that interpretation doesn't match reality, the signature is at worst useless. Who cares that someone added information about a transaction that doesn't affect what you sign? > We are most likely to implement the "do not sign with unknown fields" > rule in any case (technically a whitelist of "known OK" field types), > and resolve potential problems as they arise. I raised this point mainly > because I think discussing this explicitly in the spec is beneficial: a > distinction between mandatory and optional fields is one way, mentioning > or prescribing possible signing strategies is another. I don't think that's a particularly useful policy, but certainly Signers are allowed to implement any policy they like about what they accept in signing. Cheers, -- Pieter