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 E01BEC84 for ; Fri, 22 Jun 2018 19:10:17 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6FD0073B for ; Fri, 22 Jun 2018 19:10:17 +0000 (UTC) Received: by mail-oi0-f48.google.com with SMTP id t22-v6so7067266oih.6 for ; Fri, 22 Jun 2018 12:10:17 -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=1Rj3EXoE28B/B6+KTC52IxhPIu3H7RLB+kSctoTHndk=; b=tV8h8n0yUpJku+XKczPdReAiOLTSTQhFPzVPQNBHPzNnd3EDJhlpdGmcWiqTTj7eZH BeSTPK3wRF5s6Ff6hQTmPzdxySr+qCZzLzk4hggpGmDKKeltWOO4LSfRV/3ww3iqWnrq VCFEGkLpAXocr1kZ5MeAzPLr+icMfZBC10svkvBRlP6Ws7BFOHafBp/iaXztjIQ01BMe 0iQkQioVAFoum6j50uhBDLVdqkOeYrl8g6akArfZTXV7Yu6mxwcQ0dmAWAWme3egSOLU BqTXXTljAQIRz3OznxyzPJXFv7dZn2CQ3EX6r4sHS2ClY+rU8mKMqXkNgUsMz8Eh1jRt RjUQ== 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=1Rj3EXoE28B/B6+KTC52IxhPIu3H7RLB+kSctoTHndk=; b=Abu5dYiZPNYyGUszVoEzB7kByBjY73m+fCdCBwtS/lgf9BKX+n63GL25XA+/mzILeP Xm/7BLDSGKevpskNjfAIOf+xhQgEv8mUJyE3dbxMIpbpkajRhGEpZeZFGrEe17UWiY+A n7tTQNjQpGHK/3o2Usee1e0CTU1Gy7T0k6Be/qRHGlhLVdRyBnW+6PsE0n+loRAsHE0d YZmWJ3dMt2s07Y2+5hg0DtznK9trSsy4kN/FB5EYcXHsFLSaxWF6eO1C7F+0QycnFAWn 2PSwdwRaKcDvfJdIcs2RCYCUCYk9agvw/jE45ZrI2URDw38QGPLSbKpdvH4VA5BgbDhc Lolw== X-Gm-Message-State: APt69E39B1s5KkXR6ipRT/0hs6CQ6HX0jVmvvvIO0keFBdH+xi6eI/wc papJo4AmoL9802MDkwHExRrcwosSwXGiiRNTtgLrDg== X-Google-Smtp-Source: ADUXVKJUEJolrfjTaiZ2BjmIOVdt8D+85itXXRZSx0DjjlslHKwQd9SVtlQCTFXfweWxoC1dbWigITWLHRJ+PCBy6a4= X-Received: by 2002:aca:bfd6:: with SMTP id p205-v6mr1631301oif.46.1529694616417; Fri, 22 Jun 2018 12:10:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:6a89:0:0:0:0:0 with HTTP; Fri, 22 Jun 2018 12:10:15 -0700 (PDT) In-Reply-To: <20180621195654.GC99379@coinkite.com> References: <21a616f5-7a17-35b9-85ea-f779f20a6a2d@satoshilabs.com> <20180621195654.GC99379@coinkite.com> From: Pieter Wuille Date: Fri, 22 Jun 2018 12:10:15 -0700 Message-ID: To: Peter Gray , Bitcoin Protocol Discussion 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 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: Fri, 22 Jun 2018 19:10:18 -0000 On Thu, Jun 21, 2018 at 12:56 PM, Peter D. Gray via bitcoin-dev wrote: > I have personally implemented this spec on an embedded micro, as > the signer and finalizer roles, and written multiple parsers for > it as well. There is nothing wrong with it, and it perfectly meets > my needs as a hardware wallet. This is awesome to hear. We need to hear from people who have comments or issues they encounter while implementing, but also cases where things are fine as is. > So, there is a good proposal already spec'ed and implemented by > multiple parties. Andrew has been very patiently shepherding the PR > for over six months already. > > PSBT is something we need, and has been missing from the ecosystem > for a long time. Let's push this out and start talking about future > versions after we learn from this one. I understand you find the suggestions being brought up in this thread to be bikeshedding over details, and I certainly agree that "changing X will gratuitously cause us more work" is a good reason not to make breaking changes to minutiae. However, at least abstractly speaking, it would be highly unfortunate if the fact that someone implemented a draft specification results in a vested interest against changes which may materially improve the standard. In practice, the process surrounding BIPs' production readiness is not nearly as clear as it could be, and there are plenty of BIPs actually deployed in production which are still marked as draft. So in reality, truth is that this thread is "late", and also why I started the discussion by asking what the state of implementations was. As a result, the discussion should be "which changes are worth the hassle", and not "what other ideas can we throw in" - and some of the things brought up are certainly the latter. So to get back to the question what changes are worth the hassle - I believe the per-input derivation paths suggested by matejcik may be one. As is written right now, I believe BIP174 requires Signers to pretty much always parse or template match the scripts involved. This means it is relatively hard to implement a Signer which is compatible with many types of scripts - including ones that haven't been considered yet. However, if derivation paths are per-input, a signer can just produce partial signatures for all keys it has the master for. As long as the Finalizer understands the script type, this would mean that Signers will work with any script. My guess is that this would be especially relevant to devices where the Signer implementation is hard to change, like when it is implemented in a hardware signer directly. What do you think? Cheers, -- Pieter