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
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bc@bcdev.net>) id 1W65Qe-0006tF-Vk
for bitcoin-development@lists.sourceforge.net;
Wed, 22 Jan 2014 21:33:45 +0000
X-ACL-Warn:
Received: from relay.ox.registrar-servers.com ([199.188.203.174]
helo=relay1.ox.registrar-servers.com)
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1W65Qc-00039v-SX
for bitcoin-development@lists.sourceforge.net;
Wed, 22 Jan 2014 21:33:44 +0000
Received: (qmail 1993 invoked by uid 89); 22 Jan 2014 21:06:55 -0000
Received: from unknown (HELO imap3-1.ox.registrar-servers.com) (198.187.29.241)
by relay.ox.registrar-servers.com with SMTP; 22 Jan 2014 21:06:55 -0000
Received: from localhost (localhost [127.0.0.1])
by oxmail.registrar-servers.com (Postfix) with ESMTP id D159A2A008D
for <bitcoin-development@lists.sourceforge.net>;
Wed, 22 Jan 2014 16:06:49 -0500 (EST)
X-Virus-Scanned: Debian amavisd-new at imap3.ox.registrar-servers.com
Received: from oxmail.registrar-servers.com ([127.0.0.1])
by localhost (imap3.ox.registrar-servers.com [127.0.0.1]) (amavisd-new,
port 10024) with LMTP id tWJva-zx4Ou1
for <bitcoin-development@lists.sourceforge.net>;
Wed, 22 Jan 2014 16:06:49 -0500 (EST)
Received: from [151.248.38.22] (ip-151-248-38-22.free.aero2.net.pl
[151.248.38.22])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by oxmail.registrar-servers.com (Postfix) with ESMTPSA id DFA3B2A0087
for <bitcoin-development@lists.sourceforge.net>;
Wed, 22 Jan 2014 16:06:48 -0500 (EST)
Message-ID: <52E032BD.4020206@bcdev.net>
Date: Wed, 22 Jan 2014 22:06:05 +0100
From: bc <bc@bcdev.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1W65Qc-00039v-SX
Subject: [Bitcoin-development] Combining big transactions with hash-only
blocks to improve tps.
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2014 21:33:45 -0000
Pdf version:
http://bcdev.net/data/bitcoin_big_tx_with_coin_join.pdf
== Combining big transactions with hash-only blocks to improve tps. ==
==== Abstract: ====
I've heard people talk about including only hashes in a block to speed
up the network and also about using CoinJoin to improve privacy. I've
not heard anyone talk about implications of combining these two
techniques. I think that it would both improve network's anonymity, but
also improve tps by a few orders of magnitude.
I propose two optimizations:
1. Keep only hashes of transactions included in a block. Transfer all tx
separately.
2. Use CoinJoin to merge transactions from many users for online
shopping and banking.
3. Use Jumbo transactions as a fallback for applications where CoinJoin
is inappropriate.
==== Keeping only hashes of tx in a block: ====
Currently every bitcoin block includes a copy of all transactions. This
is redundant and unnecessary, since after the transaction gets
transmitted, every node learns about it in seconds.
By keeping only transaction hashes in block, we can keep block
propagation time from increasing.
Assuming a typical tx with one or two inputs and two outputs [typically
300 bytes], current 1MiB block can contain about [assuming a block every
10 minutes]:
1MiB / 300 bytes = 3300tx = 5.5tps
By keeping only hashes in a block [32 bytes per hash]:
1MiB / 32 bytes = 31000tx = 50tps
== Benefits: ==
This method allows to achieve more tps without increasing the block
propagation time, which is critical for mining decentralization.
It removes redundancy, since every tx has to be transmitted only once.
It leads to a more consistent bandwidth utilization [large transactions
are transmitted all the time, while blocks are kept small and easy to
propagate].
Because a block size is a constant, mining fees would not depend on the
size of a transaction. Obviously to limit the network flood, there
should be a transaction size limit.
== Problems: ==
Selfish miner can keep a subset of transactions only for yourself and
release them only with a new block. This problem can be mitigated by
making nodes verify all transactions before propagating a block. The
incentive will then be to mine only a well-distributed transactions to
lower orphan rate.
The miner can try to sneak up invalid transaction in a block. This
problem is also mitigated by not accepting a block before it gets verified.
==== CoinJoin: ====
If the block size keeps only hashes, a transaction can be much bigger.
Since CoinJoin allows many people to send coins with one transaction,
the effective transaction rate can be increased considerably.
== Example: ==
Let's assume the transaction size limit of 50KiB. Limit of this size
allows for a CoinJoin transaction between 50KiB / 300b = 170 participants.
So for a block of 1MiB, it would allow for 50tps *
170effective_transactions/tx = 8500tps.
== Benefits: ==
There would be an incentive for users to use CoinJoin by default [lower
tx fees per effective transaction], which would greatly increase
anonymity of the network.
Since block size stays the same, block propagation time also stays the same.
It doesn't require any changes to the protocol. CoinJoin transactions
were always supported in bitcoin.
== Problems: ==
1) CoinJoin requires collaboration between many users in real-time. It
means, that transaction must be distributed to every CoinJoin
participant, and every participant has to sign it before it can be
released. Therefore it induces delays, which can take some time.
It wouldn't be an issue with Internet banking or on-line shopping [where
even 10 minutes per transaction is fast enough], however even 20 seconds
can make the system unsuitable for POS payments.
Potential solution: Use bigger CoinJoin user base for online payments
[with smaller fees], and a smaller one for POS payments [with larger fees].
2) Signing a CoinJoin transaction requires to transfer a whole
transaction for a user to sign.
This can sometimes take up to a few minutes on a very slow networks.
3) CoinJoin transactions are limited. They are good enough for money
transfer, but for more advanced appliances CoinJoin might be inadequate.
==== Jumbo transactons: ====
I propose another tx type as a fallback where CoinJoin is not Combining
big transactions with hash-only blocks to improve tps.applicable. It
would remove the CoinJoin induced delays, while keeping transaction
sizes big.
Image: http://bcdev.net/data/jubo_transaction_description.png
Transaction joiner is a service that collects transactions from clients
and publishes them as a Jumbo transaction.
Jumbo pubkey prevents transaction from being modified. It can only be
accepted or rejected by the miner as a whole, which should limit
discrimination.
== Algorithm: ==
1) Transaction joiner sends a Jumbo pubkey hash to the client.
2) Client creates a transaction, includes a Jumbo pubkey hash and signs it.
3) Transaction joiner waits until there are enough transactions and
releases a Jumbo transaction to the network.
4) A miner includes only a hash of a Jumbo transaction in a block, he
cannot cherry-pick individual transactions from the bulk.
5) The network checks if every transaction inside a Jumbo transaction
includes a Jumbo pubkey hash and if every transaction inside is valid.
== Benefits: ==
Since the block size stays the same, block propagation time also stay
the same.
There is no need to wait for every participant to sign the transaction.
It's therefore more suitable for POS payments.
No additional network overhead for a thin client compared to a standard tx.
Backwards compatibility with current transaction system.
== Problems: ==
1) Jumbo transactions don't mix coins. Anonymity of the network is not
increased.
2) There would be an incentive to use this transaction type by default
[compared to CoinJoin].
Potential solution:
Make Jumbo transaction size limit lower than CoinJoin. That would make
fees for these transactions higher, thus creating an incentive to only
use them when necessary.
3) Transaction joiner has to wait for a Jumbo transaction to be big
enough before it gets released.
It's not a big problem. When the network load is low, the fee required
for a tx to be included should be lower, allowing for smaller Jumbo
transactions. When the network load is high, it takes less time to fill
a Jumbo transaction.
==== References: ====
Increasing the Network Hashing Power by reducing block propagation time
https://bitcointalk.org/index.php?topic=145066.0
CoinJoin: Bitcoin privacy for the real world
https://bitcointalk.org/index.php?topic=279249.0
Bitcoin: A Peer-to-Peer Electronic Cash System
http://bitcoin.org/bitcoin.pdf
|
