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
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
|
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 2380992B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Nov 2015 01:26:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f178.google.com (mail-io0-f178.google.com
[209.85.223.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 528D8120
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Nov 2015 01:26:52 +0000 (UTC)
Received: by ioc74 with SMTP id 74so39328404ioc.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 24 Nov 2015 17:26:51 -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=ku9uU6p34C1ea7pKRoWZZUyemrmr+x4C1tN05iG39Rk=;
b=r4chyKmO/mpUAMbsW5/PT1Tahg4fsY0eW6U+Gms3URp2UHizOhpmXiIsDX0DkR58jz
RMo/lrrsBKDr9bb8M99NST22DoWREvllnWUFkq0mX7UA3vFKEMG0kU+pSlkRoPk2xZ44
YXMoIkP21wT0Drcxa0LIGG1aq1F/S2NJHWOjeCRFhm/LpzAEWcJMXl2D5LcMR18p7EAL
xTphYFdjukaC/U6w2uZKOUQ6RC88sAaDoEPbEN5PJn7BGpiehg7CgsxKZ7ArkA7T1dvx
jEiIzzDhU12jf+SCXiYVq3R2VgsEFM6crFKFYDPc5dcTQ1lRUR3vFiOS1HDGuN9CI7L9
u/EA==
MIME-Version: 1.0
X-Received: by 10.107.13.143 with SMTP id 137mr23165337ion.72.1448414811732;
Tue, 24 Nov 2015 17:26:51 -0800 (PST)
Sender: nbvfour@gmail.com
Received: by 10.36.20.130 with HTTP; Tue, 24 Nov 2015 17:26:51 -0800 (PST)
In-Reply-To: <CABeL=0hm=6S6YRQP45pNVv42b1kHZrH1TFuz3xguN+YNW5o=ww@mail.gmail.com>
References: <CAAcC9yuM+dG+mJn_0vPqZuig5cHqeF-xgszw-zzD3D9UKRsyrQ@mail.gmail.com>
<CABaSBaxKJjEd2e9hrnzyS57-YHspqCv9PiSH4XccqSZJMQG6qg@mail.gmail.com>
<CAGLBAhd-6NbxppFdqNVSQ5ot_GX12eL8P2-qVe7_dZcUfHYv6w@mail.gmail.com>
<CAAcC9yubb-Ajig+ZLrGVe3a7ON5MTzuLARP1_HCj2ngStJAGGg@mail.gmail.com>
<CABeL=0hm=6S6YRQP45pNVv42b1kHZrH1TFuz3xguN+YNW5o=ww@mail.gmail.com>
Date: Tue, 24 Nov 2015 17:26:51 -0800
X-Google-Sender-Auth: L3vKDR4FyknYvCtNr_rDsx_RYZo
Message-ID: <CAAcC9yuUYx5o50ocTiFp2keYUuew8aT5fuCnx-huHUgeGK5r1g@mail.gmail.com>
From: Chris Priest <cp368202@ohiou.edu>
To: Jannes Faber <jannes.faber@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: Wed, 25 Nov 2015 01:26:53 -0000
1. Technically is it promoting address reuse, but in this case, I
think it's OK. The primary purpose of a coalescing transaction is to
clear out *all* funds associated with one address and send them to
another address (belonging to the same owner). If you coalesce the
inputs to the same address over and over again, you an do that, but
you'll run the risk of leaking your private key.
2. I see these transactions being broadcast in the background when the
user is not planning on sending or receiving any payments. By the time
the wallet user wants to spend funds from the address, the coalescing
transaction should be sufficiently deep enough in the blockchain to
avoid re-org tomfoolery. Exchanges and payment processors who take in
payments around the clock will probably never use these transactions,
at least not on "live" addresses.
3. I never thought of that, but thats a benefit too!
On 11/24/15, Jannes Faber via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Few issues I can think of:
>
> 1. In its basic form this encourages address reuse. Unless the wildcard can
> be constructed such that it can match a whole branch of an HD wallet.
> Although I guess that would tie all those addresses together making HD moot
> to begin with.
>
> 2. Sounds pretty dangerous during reorgs. Maybe such a transaction should
> include a block height which indicates the maximum block that any utxo can
> match. With the requirement that the specified block height is at least 100
> blocks in the past. Maybe add a minimum block height as well to prevent
> unnecessary scanning (with the requirement that at least one utxo must be
> in that minimum block).
>
> 3. Seems like a nice way to the reduce utxo set. But hard to say how
> effective it would really be.
> On 25 Nov 2015 12:48 a.m., "Chris Priest via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> > This idea could be applied by having the wildcard signature apply to
>> > all
>> > UTXOs that are of a standard form and paid to a particular address, and
>> be
>> > a signature of some kind of message to that effect.
>>
>> I think this is true. Not *all* transactions will be able to match the
>> wildcard. For instance if someone sent some crazy smart contract tx to
>> your address, the script associated with that tx will be such that it
>> will not apply to the wildcard. Most "vanilla" utxos that I've seen
>> have the formula: OP_DUP OP_HASH160 [a hash corresponding to your
>> address] OP_EQUALVERIFY OP_CHECKSIG". Just UTXOs in that form could
>> apply to the wildcard.
>>
>> On 11/24/15, Dave Scotese via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > What is required to spend bitcoin is that input be provided to the UTXO
>> > script that causes it to return true. What Chris is proposing breaks
>> > the
>> > programmatic nature of the requirement, replacing it with a requirement
>> > that the secret be known. Granted, the secret is the only requirement
>> > in
>> > most cases, but there is no built-in assumption that the script always
>> > requires only that secret.
>> >
>> > This idea could be applied by having the wildcard signature apply to
>> > all
>> > UTXOs that are of a standard form and paid to a particular address, and
>> be
>> > a signature of some kind of message to that effect. I imagine the cost
>> of
>> > re-scanning the UTXO set to find them all would justify a special extra
>> > mining fee for any transaction that used this opcode.
>> >
>> > Please be blunt about any of my own misunderstandings that this email
>> makes
>> > clear.
>> >
>> > On Tue, Nov 24, 2015 at 1:51 PM, Bryan Bishop via bitcoin-dev <
>> > bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >
>> >> On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bitcoin-dev <
>> >> bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >>
>> >>> **OP_CHECKWILDCARDSIGVERIFY**
>> >>
>> >>
>> >> Some (minor) discussion of this idea in -wizards earlier today
>> >> starting
>> >> near near "09:50" (apologies for having no anchor links):
>> >> http://gnusha.org/bitcoin-wizards/2015-11-24.log
>> >>
>> >> - Bryan
>> >> http://heybryan.org/
>> >> 1 512 203 0507
>> >>
>> >> _______________________________________________
>> >> bitcoin-dev mailing list
>> >> bitcoin-dev@lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>
>> >>
>> >
>> >
>> > --
>> > I like to provide some work at no charge to prove my value. Do you need
>> > a
>> > techie?
>> > I own Litmocracy <http://www.litmocracy.com> and Meme Racing
>> > <http://www.memeracing.net> (in alpha).
>> > I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
>> which
>> > now accepts Bitcoin.
>> > I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
>> > "He ought to find it more profitable to play by the rules" - Satoshi
>> > Nakamoto
>> >
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
|
