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
|
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 1AFA826C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 24 Nov 2015 17:34:37 +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 8A98D169
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 24 Nov 2015 17:34:36 +0000 (UTC)
Received: by ioef137 with SMTP id f137so2444640ioe.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 24 Nov 2015 09:34:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:date:message-id:subject:from:to:content-type;
bh=f3s6qECwLJNhh7t4ruxB+Kt3NlO25LiSoVys0cE6xl4=;
b=OR0OAlB/DjvRA+un2EA2nb0/rl1cbJ+uVyUiVhlw8KI9tg3XZZRJFIjefs83CliqgC
eqEhGAD63iCXKAtBgZNWF1rEbN0yvVdhPn2lU0RGHH26Nv70mCDVBMMiS1UE6pXe2DkG
buLFeYo5/7sMWaaJhM57SKMR2o03JMFyo2J5jlCSK+ZdxFxak+UBMiBlqrOvaR8fDX2c
54mU/m9GEQDNIPy7dtZREveGZbs7zDw1KhaBo5oJoF619lSKBKyM9J+Qelay8uqrR8zO
y7CndtCj58h6sNoz+wbSUepq0+/2s5CEyhVTkjeF3wFRPOGLuJ4+AvA3oRd+kHapyXAA
2Q0g==
MIME-Version: 1.0
X-Received: by 10.107.3.163 with SMTP id e35mr28790476ioi.157.1448386475918;
Tue, 24 Nov 2015 09:34:35 -0800 (PST)
Sender: nbvfour@gmail.com
Received: by 10.36.20.130 with HTTP; Tue, 24 Nov 2015 09:34:35 -0800 (PST)
Date: Tue, 24 Nov 2015 09:34:35 -0800
X-Google-Sender-Auth: m-OKJIWOPA_BAMFPrI41CN2j-ZQ
Message-ID: <CAAcC9yuM+dG+mJn_0vPqZuig5cHqeF-xgszw-zzD3D9UKRsyrQ@mail.gmail.com>
From: Chris Priest <cp368202@ohiou.edu>
To: bitcoin-dev@lists.linuxfoundation.org
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
Subject: [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 17:34:37 -0000
Here is the problem I'm trying to solve with this idea:
Lets say you create an address, publish the address on your blog, and
tell all your readers to donate $0.05 to that address if they like
your blog. Lets assume you receive 10,000 donations this way. This all
adds up to $500. The problem is that because of the way the bitcoin
payment protocol works, a large chunk of that money will go to fees.
If one person sent you a single donation of $500, you would be able to
spend most of the $500, but since you got this coin by many smaller
UTXO's, your wallet has to use a higher tx fee when spending this
coin.
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.
**OP_CHECKWILDCARDSIGVERIFY**
First, I propose a new opcode. This opcode works exactly the same as
OP_CHECKSIGVERIFY, except it only evaluates true if the signature is a
"wildcard signature". What is a wildcard signature you ask? This is
the part that I have not yet 100% figured out yet. It is basically a
signature that was created in such a way that expresses the private
key owners intent to make this input a *wildcard input*
** wildcard inputs **
A wildcard input is defined as a input to a transaction that has been
signed with OP_CHECKWILDCARDSIGVERIFY. The difference between a
wildcard input and a regular input is that the regular input respects
the "value" or "amount" field, while the wildcard input ignores that
value, and instead uses the value of *all inputs* with a matching
locking script.
** coalescing transaction"
A bitcoin transaction that
|
