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
|
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 EB9CCB0C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 7 Dec 2015 23:39:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com
[209.85.213.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6F10E16C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 7 Dec 2015 23:39:13 +0000 (UTC)
Received: by igl9 with SMTP id 9so85325112igl.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 07 Dec 2015 15:39:13 -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=ZqQEtKl/G/eS0+5Bq8GQK20M5tdHVW97NRttvVnBEpA=;
b=Rq3C9qrYGWmtpVhiqKjr0y40/ktvzygW3hO1w1iSGaO501C87U1WRu4pARf/0YpDlX
G3PjZV5q3bMZPubq8NRLn5wDi0nEjoHw4yk7gYDX7TN5pccRYlrAxaTpa3BH7DQ4m72H
ZgYR+lhI5uWbEjHwe0NQ92RFUqArpZCpPRDx1lcdchQe5kX5w/RA/Zhz+id3MJnIm4uv
nk/bfYTr9xvEg8l91YamJnKGa+UXR87gHxnsxlemm5ojvUYtzkQ28bNaOpqOGztHiTnG
YbA7GnXUouU+jC57zJUGWBvEZ0xeGlvEh8KgKLpsV/FSfOltVQapA6ObpoCyc7owZNfi
CcVw==
MIME-Version: 1.0
X-Received: by 10.50.3.71 with SMTP id a7mr992685iga.80.1449531552888; Mon, 07
Dec 2015 15:39:12 -0800 (PST)
Sender: nbvfour@gmail.com
Received: by 10.36.20.130 with HTTP; Mon, 7 Dec 2015 15:39:12 -0800 (PST)
Date: Mon, 7 Dec 2015 15:39:12 -0800
X-Google-Sender-Auth: yfifVLf3NJeBLxODKT0sdWCER4Q
Message-ID: <CAAcC9yv3Eaqa4af0U4s_V3hpEt7cWn5mLx0DyhqBCK-g32D1yw@mail.gmail.com>
From: Chris Priest <cp368202@ohiou.edu>
To: Bitcoin Dev <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] Coalescing Transactions BIP Draft
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: Mon, 07 Dec 2015 23:39:14 -0000
I made a post a few days ago where I laid out a scheme for
implementing "coalescing transactions" using a new opcode. I have
since come to the realization that an opcode is not the best way to do
this. A much better approach I think is a new "transaction type" field
that is split off from the version field. Other uses can come out of
this type field, wildcard inputs is just the first one.
There are two unresolved issues. First, there might need to be a limit
on how many inputs are included in the "coalesce". Lets say you have
an address that has 100,000,000 inputs. If you were to coalesce them
all into one single input, that means that every node has to count of
these 100,000,000 inputs, which could take a long time. But then
again, the total number of inputs a wildcard can cover is limited to
the actual number of UTXOs in the pool, which is very much a
finite/constrained number.
One solution is to limit all wildcard inputs to, say, 10,000 items. If
you have more inputs that you want coalesced, you have to do it in
10,000 chunks, starting from the beginning. I want wildcard inputs to
look as much like normal inputs as much as possible to facilitate
implementation, so embedding a "max search" inside the transaction I
don't think is the best idea. I think if there is going to be a limit,
it should be implied.
The other issue is with limiting wildcard inputs to only inputs that
are confirmed into a fixed number of blocks. Sort of like how coinbase
has to be a certain age before it can be spent, maybe wildcard inputs
should only work on inputs older than a certain block age. Someone
brought up in the last thread that re-orgs can cause problems. I don't
quite see how that could happen, as re-orgs don't really affect
address balances, only block header values, which coalescing
transactions have nothing to do with.
Here is the draft:
https://github.com/priestc/bips/blob/master/bip-coalesc-wildcard.mediawiki
|
