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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bitcoin-list@bluematt.me>) id 1SfZEW-00004y-SV
for bitcoin-development@lists.sourceforge.net;
Fri, 15 Jun 2012 16:18:48 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bluematt.me
designates 173.246.101.161 as permitted sender)
client-ip=173.246.101.161;
envelope-from=bitcoin-list@bluematt.me; helo=mail.bluematt.me;
Received: from vps.bluematt.me ([173.246.101.161] helo=mail.bluematt.me)
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1SfZET-0005Ql-2F for bitcoin-development@lists.sourceforge.net;
Fri, 15 Jun 2012 16:18:48 +0000
Received: from [IPv6:2001:470:9ff2:1:ee55:f9ff:fec6:e666] (unknown
[IPv6:2001:470:9ff2:1:ee55:f9ff:fec6:e666])
by mail.bluematt.me (Postfix) with ESMTPSA id AE296398F;
Fri, 15 Jun 2012 16:18:38 +0000 (UTC)
Message-ID: <1339777116.31489.87.camel@bmthinkpad>
From: Matt Corallo <bitcoin-list@bluematt.me>
To: Mike Hearn <mike@plan99.net>
Date: Fri, 15 Jun 2012 18:18:36 +0200
In-Reply-To: <CANEZrP2rZEwQqkceTN3yOqx_Mo_8gyRyBUgv8NnfKd8ZWGYzww@mail.gmail.com>
References: <CANEZrP3w+AiTXmv9Wb3Zi5yyFmGPk82-ysVo4_DVvtg8HHBCdQ@mail.gmail.com>
<1339765735.31489.40.camel@bmthinkpad>
<CANEZrP2rZEwQqkceTN3yOqx_Mo_8gyRyBUgv8NnfKd8ZWGYzww@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.2.2-1
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1SfZET-0005Ql-2F
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Near-term scalability
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: Fri, 15 Jun 2012 16:18:48 -0000
On Fri, 2012-06-15 at 15:34 +0200, Mike Hearn wrote:
> > The idea can be more generalized in that there are many cases where the
> > generator of a transaction doesn't care about confirmation times, and
> > would really be willing to make their transaction lower priority than
> > other 0-fee transactions.
>
> Just to be clear, I think this solution is a hack and don't support it
> because it's yet another change of network rules. Some random people
> will get whacked because of a heuristic "rule of thumb".
Its arguably not a change to network rules as its something that users
can already do today by patching their clients. Obviously any
implementation would have sane defaults which allowed for a significant
number of transactions to/from a given address at a time, avoiding
whacking random people unless they are large enough that they should
really already be fully aware of how bitcoin works.
>
> If it's implemented, SD could/would switch to fresh addresses and
> nothing would have been achieved except making an already complex
> system more complex.
I would think SD would switch to using fresh addresses for each bet.
But even that is a good thing, at least where user privacy is concerned.
However, I would hope that SD would see the rule tweak and, in order to
avoid having to generate a number of new addresses per second (or, if
they went the pool route, having a huge pool of many thousands of
addresses), they would consider implementing sendmulti support.
>
> I disagree with the notion that you need "less important than free".
> If you care about the confirmation time of a transaction that was sent
> to you and you need space in a limited resource, you can pay for it.
> It's an auction like any other. Besides, the idea that transactions
> are free today is just a psychological trick befitting governments but
> not us - transactions are funded by aggressive hyperinflation. I would
> never describe Bitcoin as a free system and I suggest nobody else does
> either.
I agree, free transactions isnt something we should aggressively push as
a feature of Bitcoin, its simply not. However, in the current system
free transactions are usually confirmed within a small number of blocks,
and for a number of users, that is an important feature that draws them
to get through the initial hurdles of converting money to Bitcoin and
understanding enough of the system to trust it. I believe that if we
can incentive large transaction creators to avoid delaying free
transactions, we should and giving them the option to delay their own
transactions seems like a perfectly reasonable way to do so. Even if
you drop all the per-address limit stuff, allowing transaction creators
to add a simple flag to transactions seems reasonable when they want to
encourage Bitcoin to continue to grow as it does today. Obviously
keeping free transactions confirming won't be possible forever, but
hopefully that will be as a result of natural growth which can encourage
further growth without the need for free transactions and not as a
result of a few actors in the community creating a transaction volume
significantly greater than their user-base.
>
> If grouped fee calculations are implemented, we can keep the nice
> property that the person who cares about double spending risk pays the
> fees, and if you assume most transactions are hub-and-spoke from
> buyers to merchants, rather than a pure p2p graph, in practice it'll
> work out to seeming free most of the time even if seen globally it
> doesn't make much difference.
ACK, thats an important thing to implement IMO, but I really dont see it
as something that replaces the option to deprioritize your own
transactions to below 0-fee transactions. It could even allow users who
receive payouts which are below 0-fee transactions to place a fee on the
subsequent transactions to allow the payouts to confirm quicker (if done
right).
>
> > My point was that the easiest way to do it would be to ship a pruned
> > snapshot with Bitcoin, and such a system, while verifiable, would
> > increase Bitocin's centralization.
>
> I'm not sure why. If you want to audit everything from scratch, after
> checking the code you could just blow away the included files and then
> "-connect=archive.bitcoin.org" or something like that. After
> rebuilding the chain from scratch, check the databases for consistency
> with the included data.
I would be surprised if more than a handful of devs audit such a thing.
And I would say that does define an increase in centralization.
>
> It reduces the number of nodes with full copies of the block chain,
> yes, but as long as there's at least one copy of the old data in an
> accessible location new nodes can still bootstrap just fine.
Sadly, old nodes do not know where to look for such data, and I'm fairly
certain people running old nodes don't read the forums enough to catch
when it is announced that old nodes should make sure to
-connect=archive.bitcoin.org in order to avoid initially having horrible
initial bootstrap times and eventually not being able to connect to
full-chain-serving nodes at all.
>
> I'm sure we can find organizations willing to host full chains for
> people who want to rebuild their databases from scratch, given how
> cheap disk space is.
Sadly, disk space isnt the issue. Each connection to bitcoind (not that
it cant be fixed, but currently) eats a nice chunk of memory. An
organization that wants to provide nodes for old nodes to connect to
would need to have a significant number of open incoming connection
slots, have plenty of bandwidth for nodes that are in IBD and have
plenty of memory and CPU to manage all the connections.
>
> > connect to, possibly complicating using Bitcoin for clients that either
> > wish to run a full IBD or older clients which need a non-fClient node
>
> Yes, but old nodes probably have a copy of the chain already, so it
> wouldn't affect them. New blocks would still be fully distributed,
> right?
Sadly, BDB's infamous database corrupted messages appear all too often,
and the usual response is "delete the chain and resync." I have a hard
time believing that old nodes will rarely be in IBD.
>
> The only case where it'd cause issues is if you install a fresh copy
> of a very old node. Not a common occurrence, and those nodes will have
> to wait until they find an archival node announcing itself. Those
> nodes could be made to announce more frequently than normal, if need
> be.
I agree that its very possible to have archival nodes available and to
make it work, but I have yet to see anyone doing any work to actually
get commitments to run archival nodes and I have yet to see any
discussion of what, exactly, that would entail.
Matt
|
