Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 10480C0878 for ; Fri, 15 Nov 2019 22:29:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id EC823882D8 for ; Fri, 15 Nov 2019 22:29:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6kuJTZTdCcT for ; Fri, 15 Nov 2019 22:29:14 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) by hemlock.osuosl.org (Postfix) with ESMTPS id 02A55882BD for ; Fri, 15 Nov 2019 22:29:14 +0000 (UTC) Received: by mail-lj1-f170.google.com with SMTP id e9so12259633ljp.13 for ; Fri, 15 Nov 2019 14:29:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Mkl/ULvQZuQDdVV+PtgwJMQX62alZt3zKxrhqVwaVQA=; b=BIEUGQL60GY4OZPnch/2BIRpzLNSETyvgD7mXMrlY5lLgR2rWlP3HU+seXX73MAVMn aleIRwaDNvupPWNLVc3FlzHve+l7j15mAQXdysji/QOe4Pmte2+Nq6nhaiYNlo/vpsAh e5XsVHfDJroZ+KWel0Kv77T8qBssi8hUbSIdg9TT+Sk3CXhqDHtlAvqUjO5Ip8YFDE5Y mSSAge05c0szpreRsGvf6fogwAejwIcYk4tht1UPBCnlWkNo2o3d9/HTPIqvww16w++Y hbQiPwz1KqCWgaUeh0TYW7a4JSnLbZYjfCgnpTl1FpQQsMo4jL8g0EDyDoUsnNLvTtZv C1uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Mkl/ULvQZuQDdVV+PtgwJMQX62alZt3zKxrhqVwaVQA=; b=jVp6UKg3GJkdrc+oCmAm3pGUoIMo/WWJCh4onqsU6g/9MJNmJMZKOC0uB7RaDqb/Mt zgzGzcYphhnrl7JG7/CPzQiGfCS9ihnBZI/n1vnazPyJV61+cmh9GZb8p1oWZx6vJapF vlbzuPc9ANtljoOYnwYibm8vfYzgacCtpXtJsd49QrJYg5pc3rREJMqZsInLEGCGMmFA 4L8Ax1gJqI3e0BTs7fNtqTsfpkVTyrWwLQ5Hsd3mzmUSfUBR/XiUiFHPGiFRoDt2xKXp DqNXokyvlbUMRjCDIedmFDqeUgSfyMwZV234mEyQuRfBSKbGOnegW9t1jBo1Fjtc4iK3 Bj9g== X-Gm-Message-State: APjAAAWOWZeBW4jd2DjVTlEFb42OPU7X2aoYZ4o0CIlehy7BhMADU+sX 3xHMrofT5oPpv74woovOH3mtHkK5HYbp0qP5B8uObHm39Dg= X-Google-Smtp-Source: APXvYqyTQTcYTuhGsWdD18J7ZwPqlvAF6SK93cmGVPt7pXS/KZme0V6JkRb8+6C0UDpJbfhm/RyP5SE0xbAQc3t+hq0= X-Received: by 2002:a2e:63c9:: with SMTP id s70mr13160856lje.73.1573856951841; Fri, 15 Nov 2019 14:29:11 -0800 (PST) MIME-Version: 1.0 From: Ian Kroozbi Date: Fri, 15 Nov 2019 16:29:01 -0600 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="0000000000008ab7f205976a20b6" X-Mailman-Approved-At: Sat, 16 Nov 2019 03:34:23 +0000 Subject: [bitcoin-dev] PSBT_GLOBAL_XPUB: Version bytes in xpub X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2019 22:29:15 -0000 --0000000000008ab7f205976a20b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What=E2=80=99s the rational for including the version bytes in the xpub in = the GLOBAL_XPUB field? This was briefly touched upon in an earlier email from Stepan, but I don=E2=80=99t think it was every fully addressed. I am not sure if we need the whole xpub or keeping chain_code and > public_key is enough, but I would suggest to keep other data > just in case. For example, keeping prefix that defines if the key is used > for testnet or mainnet may be useful. > The version bytes seem to be superfluous data considering the transaction format and the rest of the PSBT key-values are network agnostic. If we wanted to attach network data to the PSBT then I think that would be better served by using a new key. There is also a potential issue where we could have conflicting versions on different xpubs in the PSBT. If we remove the version bytes then we can eliminate this possibility. I haven=E2=80=99t formed an opinion on whether or not the other data outsid= e of the public key and chain code should be included, but I think it would be good to discuss any rational for either including it or omitting it. --0000000000008ab7f205976a20b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What=E2=80=99s the rational for including the version byte= s in the xpub in the GLOBAL_XPUB field? This was briefly touched upon in an= earlier email from Stepan, but I don=E2=80=99t think it was every fully ad= dressed.

I am not = sure if we need the whole xpub or keeping chain_code and
public_key is e= nough, but I would suggest to keep other data
just in case. For example,= keeping prefix that defines if the key is used
for testnet or mainnet m= ay be useful.

The version bytes seem to be superfluous = data considering the transaction format and the rest of the PSBT key-values= are network agnostic. If we wanted to attach network data to the PSBT then= I think that would be better served by using a new key.

There is al= so a potential issue where we could have conflicting versions on different = xpubs in the PSBT. If we remove the version bytes then we can eliminate thi= s possibility.

I haven=E2=80=99t formed an opinion on whether or not= the other data outside of the public key and chain code should be included= , but I think it would be good to discuss any rational for either including= it or omitting it.
--0000000000008ab7f205976a20b6--