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
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 63578407
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 Nov 2015 22:02:46 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id BA50B150
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 Nov 2015 22:02:45 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:61b6:56a6:b03d:28d6])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id D175C38A6305;
Tue, 3 Nov 2015 22:01:21 +0000 (UTC)
X-Hashcash: 1:25:151103:decker.christian@gmail.com::lVUG5XWRZvefvL9B:a4buq
X-Hashcash: 1:25:151103:danny.thorpe@gmail.com::xz4cGaavOp=lS2Gr:dX1KL
X-Hashcash: 1:25:151103:bitcoin-dev@lists.linuxfoundation.org::R87LHGJ3+PheG7wH:kuBa
From: Luke Dashjr <luke@dashjr.org>
To: Christian Decker <decker.christian@gmail.com>
Date: Tue, 3 Nov 2015 22:01:20 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.9-gentoo-r1; KDE/4.14.8; x86_64; ; )
References: <CALxbBHU+kdEAh_4+B663vknAAr8OKZpUzVTACORPZi47E=Ehkw@mail.gmail.com>
<201511032048.18680.luke@dashjr.org>
<CALxbBHVwv_T4=DTUdmbgG2y7QmjETCKbQ6_oKKNjsCS=HDrJ+A@mail.gmail.com>
In-Reply-To: <CALxbBHVwv_T4=DTUdmbgG2y7QmjETCKbQ6_oKKNjsCS=HDrJ+A@mail.gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201511032201.21047.luke@dashjr.org>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP] Normalized transaction IDs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Tue, 03 Nov 2015 22:02:46 -0000
On Tuesday, November 03, 2015 9:44:02 PM Christian Decker wrote:
> Ok, so assuming we can get a connected component of upgraded nodes that
> relay both the transaction and the associated external scripts then we
> could just piggyback the external scripts on top of the normal messages.
> Non-upgraded nodes will read the entire two-part message but only parse the
> classical transaction, dropping the external script. Validation rules for
> upgraded nodes are the same as before: if the attached signatures are
> invalid the entire TX is dropped. We have to commit to the external scripts
> used during the creation of a block. I think the easiest way to add this
> commitment is the coinbase input I guess, and following the transaction
> list a new list of signature lists is shipped with the rest of the block.
> Non-upgraded will ignore it as before.
I'd throw it in the merged-mining tree; it's not ideal, but it can be swapped
out for something better when it's ready (I'm working on such a BIP -
hopefully it can be before or at the same time as a SW deployment).
> Would that work? It all hinges on having upgraded miners in a connected
> component otherwise non-upgraded nodes will drop the external scripts on
> the way (since they parse and then reconstruct the messages along the
> path). But if it works this could be a much nicer solution.
It's actually better than that. If miners don't get the SW transactions, then
they just won't mine them, and the wallets will continue to rebroadcast until
they do. But realistically, the entire network will likely be running SW-
capable nodes long before any wallets have deployed SW transactions.
> > > As for open venues for malleability, I'm not sure we can fix them at
> > > all, after all the ability of a single signer to doublespend by
> > > appending/replacing inputs/outputs in an arbitrary fashion is not
> > > fixable IMHO and will cause any future transaction building on its
> > > outputs to be orphaned. What would the perfect properties for such a
> > > fix be?
> >
> > The problem isn't changing inputs/outputs, but that such changes
> > invalidate later spends. In particular, note that wallets *should
> > ideally* be actively trying to make transfers using multiple malleated
> > versions of the same payment.
>
> So this is indeed a form of desired malleability we will likely not be able
> to fix. I'd argue that this goes more into the direction of double-spending
> than a form of malleability, and is mostly out of scope for this BIP. As
> the abstract mentions this BIP attempts to eliminate damage incurred by
> malleability in the third party modification scenario and in the multisig
> scenario, with the added benefit of enabling transaction templating. If we
> can get the segregated witnesses approach working all the better, we don't
> even have the penalty of increased UTXO size. The problem of singlesig
> users doublespending their outputs to update transactions remains a problem
> even then.
I don't know what you're trying to say here. Double spending to the same
destination(s) and malleability are literally the same thing. Things affected
by malleability are still just as broken even with this BIP - whether it is
triggered by a third-party or not is not very relevant.
> > So the way to make an anti-malleable wallet, would be to strictly enforce
> > the
> > no-address-reuse rule on payments received (note this has no effect on
> > other/current wallets) and rely only on the hash of that
> > scriptPubKey+value for the input in subsequent transactions. This way,
> > no matter what inputs or
> > other outputs the transaction paying the address/invoice uses, the
> > subsequent
> > transaction ignores them and remains valid. (I am not suggesting this as
> > a mandatory change that all wallets must adopt to receive the current
> > semi- malleability protection you propose - only that it be *possible*
> > for wallets
> > to upgrade to or offer in the future.)
>
> Sounds very interesting. That would then be a new signature checking opcode
> I guess that would allow the transaction hash in the input be replaced by
> the hash of the serialized output it is spending? That way the transaction
> would not be detached from the coins unless the amount or the scriptpubkey
> (containing the address) is modified. So a user may add new outputs and
> inputs to an existing transaction like you mentioned.
Correct...
> This does not help someone receiving funds from a sender to build new
> transactions on top since the sender may simply doublespend its output
> before it is confirmed. I think this is probably best addressed in a
> separate proposal.
Huh??
Luke
|
