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
|
Return-Path: <nbvfour@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7DAB986
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 24 Nov 2015 21:01:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f195.google.com (mail-io0-f195.google.com
[209.85.223.195])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CAB57138
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 24 Nov 2015 21:01:27 +0000 (UTC)
Received: by ioef137 with SMTP id f137so2929864ioe.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 24 Nov 2015 13:01:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:cc:content-type;
bh=oOTbwIvIEO7jeIGYpGgM+LRovnRXvg4fW9VgSYALWYY=;
b=uqwPimIWErjKXZN/CumU9hdKtYyHY3jt8mOmHEDpWBrqHDN9nqZb0PwHM4JuzU8w3+
CPjkqNLN/fXbRWy7f3TEdPne6v7PQ59OheWeKP6l3hVykb/xOKpGbcKM9+Kc++qvAZXn
7uOlXoEbfLcNQr/gdbSTyg93wVvqogcGSYiX0dJJ3SxKPRx5zN7gM9sLzVehp5gnHExS
yGp0PO+wBDK8iVzS39fJVERbViD0T0X8b7Frkw6Lx22eUnXiyExg9nZ5KTFtW/knGY3w
sZW6g27wHghAoIH97z9xobXcfm6o68U78ylzLhay8lhcdobZFgV7vCwSp8Rnnp2FrsqJ
a25Q==
MIME-Version: 1.0
X-Received: by 10.107.13.143 with SMTP id 137mr22199268ion.72.1448398886674;
Tue, 24 Nov 2015 13:01:26 -0800 (PST)
Sender: nbvfour@gmail.com
Received: by 10.36.20.130 with HTTP; Tue, 24 Nov 2015 13:01:26 -0800 (PST)
In-Reply-To: <CABsx9T0A8EczcsE8f3D4WGk-0xsPadupBVgH5_kTs=GEhOq_9g@mail.gmail.com>
References: <CAAcC9yuM+dG+mJn_0vPqZuig5cHqeF-xgszw-zzD3D9UKRsyrQ@mail.gmail.com>
<CABsx9T0A8EczcsE8f3D4WGk-0xsPadupBVgH5_kTs=GEhOq_9g@mail.gmail.com>
Date: Tue, 24 Nov 2015 13:01:26 -0800
X-Google-Sender-Auth: DCD4R7qnGCkFc-mU6-RPrffQ0rE
Message-ID: <CAAcC9yvX2QRQvjtnO_Uiv5i=PUfAcNVJAazr_qR0Uz+uThxL6Q@mail.gmail.com>
From: Chris Priest <cp368202@ohiou.edu>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW 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] OP_CHECKWILDCARDSIGVERIFY or "Wildcard Inputs" or
"Coalescing Transactions"
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, 24 Nov 2015 21:01:28 -0000
A coalescing transaction in my scheme is the same size as a normal
transaction. You only include one UTXO, the rest are implied based on
the presence of the OP_CHECKWILDCARDSIGVERIFY opcode.
The code that determines if a UTXO is spent or not will need to be
modified to include a check to see if any matching coalescing
transactions exist in any later block. Maybe there should be a
"coalescing pool" containing all coalescing transactions that make
such a check faster.
The part I'm not too sure about is the "wildcard signature". I'm not
too versed in cryptography to know how exactly to pull this off, but I
think it should be simple.
You'd just have to some way inject a flag into the signing process
that can be verified later.
I originally wanted the "wildcardness" of the transaction expressed by
the transaction version number.
Basically any input that exists within a "version 2 transaction" is
viewed as a wildcard input. Then I realized whats to stop someone from
modifying the transaction from version 1 to version 2 and stealing
someones funds. The "wildcardness" must be expressed in the signature
so you know that the private key holder intended all inputs to be
included. Hence the need for a new opcode.
btw, this scheme is definitely in the 10x or higher gain. You could
potentially spend an unlimited number of UTXOs this way.
On 11/24/15, Gavin Andresen <gavinandresen@gmail.com> wrote:
> On Tue, Nov 24, 2015 at 12:34 PM, Chris Priest via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> The technical reason for this is that you have to explicitly list each
>> UTXO individually when making bitcoin transactions. There is no way to
>> say "all the utxos". This post describes a way to achieve this. I'm
>> not yet a bitcoin master, so there are parts of this proposal that I
>> have not yet figured out entirely, but I'm sure other people who know
>> more could help out.
>>
>
> So every input has:
> 32-byte hash (transaction being spent)
> 4-byte output (output being spent)
> 4-byte sequence number
> ... plus the scriptSig. Which is as small as about 73 bytes if you're
> spending a raw OP_CHECKSIG (which you can't do as a bitcoin address, but
> could via the BIP70 payment protocol), and which is at least two serialized
> bytes.
>
> Best case for any scheme to coalesce scriptSigs would to somehow make
> all-but-the-first scriptSig zero-length, so the inputs would be 42 bytes
> instead of 40+73 bytes -- the coalesce transaction would be about one-third
> the size, so instead of paying (say) $1 in transaction fees you'd pay 37
> cents.
>
> That's in the gray are of the "worth doing" threshold-- if it was a 10x
> improvement (pay 10 cents instead of $1) it'd be in my personal "definitely
> worth the trouble of doing" category.
>
> RE: the scheme: an OP_RINGSIGVERIFY is probably the right way to do this:
> https://en.wikipedia.org/wiki/Ring_signature
>
> The funding transactions would be: <public key> OP_RINGSIGVERIFY
> ... which might could be redeemed with <ring signature> for one input and
> then... uhh... maybe just <index_to_input_with_signature> for the other
> inputs that are part of the same ring signature group (OP_0 if the first
> input has the signature that is good for all the other public keys, which
> would be the common case).
>
> --
> --
> Gavin Andresen
>
|
