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
|
Return-Path: <rusty@ozlabs.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id EAEEF40F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 May 2017 04:58:02 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from ozlabs.org (ozlabs.org [103.22.144.67])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1725917C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 May 2017 04:58:01 +0000 (UTC)
Received: by ozlabs.org (Postfix, from userid 1011)
id 3wX3F40B3Rz9sP4; Tue, 23 May 2017 14:57:59 +1000 (AEST)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Gregory Maxwell <greg@xiph.org>, Pieter Wuille <pieter.wuille@gmail.com>
In-Reply-To: <CAAS2fgQKOKY6DEwY3ycMjysU5Xf2UUE+k=vg2ekkAMO7KG3Gsw@mail.gmail.com>
References: <CAPg+sBgruEiXya6oFy6VpmR1KPDebjeGDtZZU+facZx5=L_a5w@mail.gmail.com>
<CT3GNfkLsQJyM0EmWXc3HBmnW1h2iptP0SohZnXZfZPffoVmcofD8fs_E3kV5PuFL0pQSQwwk_FyR-8-wdANf15NE8UElNWqcEcc5Ql3n8M=@protonmail.com>
<CAAS2fgTif+Y6VzFG+w7W+CY1+D_roCqGyy392qB2KcDPGpVeiw@mail.gmail.com>
<20170516110104.GA5564@fedora-23-dvm>
<CAPg+sBjJLbhj71Epv=Qfc8HgJhSreN6BOmLkDkvcEGvPwxDNbg@mail.gmail.com>
<CAAS2fgQKOKY6DEwY3ycMjysU5Xf2UUE+k=vg2ekkAMO7KG3Gsw@mail.gmail.com>
Date: Tue, 23 May 2017 14:17:48 +0930
Message-ID: <8760gs2n7v.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
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] Rolling UTXO set hashes
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: Tue, 23 May 2017 04:58:03 -0000
Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes:
> On Tue, May 16, 2017 at 6:17 PM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
>> just the first - and one that has very low costs and no normative
>> datastructures at all.
>
> The serialization of the txout itself is normative, but very minimal.
I do prefer the (2) approach, BTW, as it reuses existing primitives, but
I know "simpler" means a different thing to mathier brains :)
Since it wasn't explicit in the proposal, I think the txout information
placed in the hash here is worth discussing.
I prefer a simple txid||outnumber[1], because it allows simple validation
without knowing the UTXO set itself; even a lightweight node can assert
that UTXOhash for block N+1 is valid if the UTXOhash for block N is
valid (and vice versa!) given block N+1. And miners can't really use
that even if they were to try not validating against UTXO (!) because
they need to know input amounts for fees (which are becoming
significant).
If I want to hand you the complete validatable UTXO set, I need to hand
you all the txs with any unspent output, and some bitfield to indicate
which ones are unspent.
OTOH, if you serialize more (eg. ...||amount||scriptPubKey ?), then the UTXO
set size needed to validate the utxohash is a little smaller: you need
to send the txid, but not the tx nVersion, nLocktime or inputs. But in a
SegWit world, that's actually *bigger* AFAICT.
Thanks,
Rusty.
[1] I think you could actually use txid^outnumber, and if that's not a
curve point SHA256() again, etc. But I don't think that saves any
real time, and may cause other issues.
|
