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
|
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 3D7A92F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 Feb 2019 15:27:01 +0000 (UTC)
X-Greylist: delayed 00:07:19 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 CBF19FE
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 Feb 2019 15:27:00 +0000 (UTC)
Received: from [2001:470:5:265:a45d:823b:2d27:961c] (unknown
[IPv6:2001:470:5:265:a45d:823b:2d27:961c])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id B74E438A0C76;
Fri, 15 Feb 2019 15:18:53 +0000 (UTC)
X-Hashcash: 1:25:190215:bitcoin-dev@lists.linuxfoundation.org::2lR1Be2vrhFli39R:55SK
X-Hashcash: 1:25:190215:stevenroose@gmail.com::J2r6EAi/MxRXmVwX:cnAQo
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org, Steven Roose <stevenroose@gmail.com>
Date: Fri, 15 Feb 2019 15:18:18 +0000
User-Agent: KMail/1.9.10 (enterprise35 0.20100827.1168748)
References: <CAChG=YV2em+6c9P4DEUB1=+ZSEA6S0j9HDuWoKBeRVMmtzaMNg@mail.gmail.com>
In-Reply-To: <CAChG=YV2em+6c9P4DEUB1=+ZSEA6S0j9HDuWoKBeRVMmtzaMNg@mail.gmail.com>
X-KMail-QuotePrefix: >
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <201902151518.50135.luke@dashjr.org>
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 16 Feb 2019 15:43:25 +0000
Subject: Re: [bitcoin-dev] [BIP Proposal] Simple Proof-of-Reserves
Transactions
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: Fri, 15 Feb 2019 15:27:01 -0000
On Tuesday 29 January 2019 22:03:04 Steven Roose via bitcoin-dev wrote:
> The existence of the first input (which is just a commitment hash) ensures
> that this transaction is invalid and can never be confirmed.
But nodes can never prove the transaction is invalid, thus if sent it, they
will likely cache the "transaction", taking up memory. I'm not sure if this
is an actual problem, as an attacker can fabricate such transactions anyway.
> #:Not all systems that will be used for verification have access to a full
> index of all transactions. However, proofs should be easily verifiable
> even after some of the UTXOs used in the proof are no longer unspent.
> Metadata present in the proof allows for relatively efficient verification
> of proofs even if no transaction index is available.
I don't see anything in the format that would prove unspentness...
> The proposed proof-file format provides a standard way of combining
> multiple proofs and associated metadata. The specification of the format
> is in the Protocol
> Buffers<ref>https://github.com/protocolbuffers/protobuf/</ref> format.
IIRC, this has been contentious for its use in BIP70 and may hinder adoption.
> message OutputMeta {
> // Identify the outpoint.
> bytes txid = 1;
> uint32 vout = 2;
>
> // The block hash of the block where this output was created.
> bytes block_hash = 3;
This isn't really sufficient. There should probably be a merkle proof.
Luke
|
