1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A289ED69
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Aug 2018 18:56:55 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com
[209.85.218.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5DC3578B
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Aug 2018 18:56:55 +0000 (UTC)
Received: by mail-oi0-f44.google.com with SMTP id q11-v6so29100225oic.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Aug 2018 11:56:55 -0700 (PDT)
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=gF0ZFJtBBBBdGId4IhM5L+Ba4Xy55jjDe+s+h+nL1LY=;
b=MZPWYzwsQ15qL5gE/GgMgxObkCCO9/FnE1nNyRoF0aCLghbcNtF2S4kZSxUch+NlbL
F7G8NpL3kZSHZMd4llWn2xkptteNJ6F3rAC+kuTfYJnN3EcPGJ7O6cFmlYmJexx98Pou
7/9mBb3pysLrMrTSHJ81k5/p3M1w2hRMEk0g9EifO7FK20xuyJkEbP/aQpJH9WAz+PMN
vM1Q5KQrMKjepOWgNzASWaE/HCIc+IqDNkGPZxbuC7oYXQN+d9gqZWA0r8C65zabNzYF
3iTbjk3CweKbPosx+uW3qreL0j6G/L5BzRpaGkk+1W4Ef/yw/6RLKI20GE8/0LQztxrc
BTJw==
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=gF0ZFJtBBBBdGId4IhM5L+Ba4Xy55jjDe+s+h+nL1LY=;
b=M/PrDMYhWiHqABsrGOBxtnIZ7Rw2qYFyfSydqu7ZN5bDl1WqQ1vujEUKa1izI7gAw/
3Pqq3l2gxod8vxv5YWlBFxMMD5uCqxIR0OUNLYtpSrYHgzMEueYzeewH3wNijtND5kDR
POVTI6aXoL4Y1YOzmd3OcmnFsCjznM1HExwKV3+K451A0bvQCNXceIXE++VcoMSuntPg
PVYe/CKhauyoVAExf/hNbQs1vVjBR2o+c8dxUFI55P6Mou1clWAjxv77RlsL5fT0hgAL
EGrmF7mzfmpLK55883fPLof/gnOYY4WKrWxlS4mOK/tdgdPP2JB3EOG3c8RtSq4Op/FJ
JQHg==
X-Gm-Message-State: AOUpUlGva/jK2sOGL3O+/H59jX8/i3fRRTrhKDW83PRGA9FunIjRPGmU
Wsvinl+/yK8pn42wIZwQai0JTrm11Qd9e4LDvUnaKh6J
X-Google-Smtp-Source: AA+uWPwmehJ0bJD1L1bgny2pQS/Q3oTTsoZ0Bw7tTZ1pL5ry0H/oJ9Cw87XyfydNuxfDDct6c4Co/8k++4qwhQreU8A=
X-Received: by 2002:aca:3507:: with SMTP id
c7-v6mr20521027oia.46.1534186614308;
Mon, 13 Aug 2018 11:56:54 -0700 (PDT)
MIME-Version: 1.0
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Mon, 13 Aug 2018 11:56:41 -0700
Message-ID: <CAPg+sBgf-qSh0UVZF5RZnO+nygF-HN9=LL1gxE1JfXKrQhBbmw@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
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: [bitcoin-dev] Witness serialization in PSBT non-witness UTXOs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Aug 2018 18:56:55 -0000
Hello all,
BIP174 currently specifies that non-witness UTXOs (the transactions
being spent by non-witness inputs) should be serialized in network
format.
I believe there are two issues with this.
1. Even in case the transaction whose output being spent itself has a
witness, this witness is immaterial to PSBT. It's only there to be
able to verify the txid commits to the output/amount being spent,
which can be done without witness.
2. "Network format" is a bit ambiguous. We can imagine a future
softfork that introduces a new type of witness. Network format could
be interpreted as including that new witness type, which is clearly
unnecessary (by the above argument), and would gratuitously break
compatibility with existing signers if implemented pedantically.
So my suggestion is to update the specification to state that
non-witness UTXOs must be serialized without witness. If it's too late
for that, it should instead be updated to explicitly specify with or
witnout witness, but it's safe to drop the witness.
Opinions?
Cheers,
--
Pieter
|
