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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1SfUj3-0006RK-Jx
for bitcoin-development@lists.sourceforge.net;
Fri, 15 Jun 2012 11:30:01 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.53 as permitted sender)
client-ip=74.125.82.53; envelope-from=mh.in.england@gmail.com;
helo=mail-wg0-f53.google.com;
Received: from mail-wg0-f53.google.com ([74.125.82.53])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SfUiz-0007GB-LO
for bitcoin-development@lists.sourceforge.net;
Fri, 15 Jun 2012 11:30:01 +0000
Received: by wgbfm10 with SMTP id fm10so2493964wgb.10
for <bitcoin-development@lists.sourceforge.net>;
Fri, 15 Jun 2012 04:29:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.99.70 with SMTP id eo6mr3740758wib.17.1339759791470; Fri,
15 Jun 2012 04:29:51 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.216.254.232 with HTTP; Fri, 15 Jun 2012 04:29:51 -0700 (PDT)
Date: Fri, 15 Jun 2012 13:29:51 +0200
X-Google-Sender-Auth: JNFHUa5RAl9M3kq9Q-iJ4-B4kM0
Message-ID: <CANEZrP3w+AiTXmv9Wb3Zi5yyFmGPk82-ysVo4_DVvtg8HHBCdQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1SfUiz-0007GB-LO
Subject: [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 11:30:01 -0000
I had to hit the sack last night as it was 2am CET, but I'd like to
sum up the discussion we had on IRC about scalability and SatoshiDice
in particular.
I think we all agreed on the following:
- Having senders/buyers pay no fees is psychologically desirable even
though we all understand that eventually, somebody, somewhere will be
paying fees to use Bitcoin
- In the ideal world Bitcoin would scale perfectly and there would be
no need for there to be some "winners" and some "losers" when it comes
to confirmation time.
There was discussion of some one-off changes to address the current
situation, namely de-ranking transactions that re-use addresses. Gavin
and myself were not keen on this idea, primarily because it just
avoids the real problem and Bitcoin already has a good way to
prioritize transactions via the fees mechanism itself. The real issue
is that SatoshiDice does indeed pay fees and generates a lot of
transactions, pushing more traditional traffic out due to artificial
throttles.
The following set of proposals were discussed:
(1) Change the mining code to group transactions together with their
mempool dependencies and then calculate all fees as a group. A tx with
a fee of 1 BTC that depends on 5 txns with zero fees would result in
all 6 transactions being considered to have a fee of 1BTC and
therefore become prioritized for inclusion. This allows a transition
to "receiver pays" model for fees. There are many advantages. One is
that it actually makes sense ... it's always the receiver who wants
confirmations because it's the receiver that fears double spends.
Senders never do. What's more, whilst Bitcoin is designed to operate
on a zero-trust model in the real world trust often exists and it can
be used to optimize by passing groups of transactions around with
their dependencies, until that group passes a trust boundary and gets
broadcast with a send-to-self tx to add fees. Another advantage is it
simplifies usage for end users who primarily buy rather than sell,
because it avoids the need to guess at fees, one of the most
problematic parts of Bitcoins design now.
The disadvantages are that it can result in extra transactions that
exist only for adding fees, and it requires a more modern payment
protocol than the direct-IP protocol Satoshi designed.
It would help address the current situation by avoiding angry users
who want to buy things, but don't know what fee to set and so their
transactions get stuck.
(2) SatoshiDice should use the same fee algorithms as Bitcoin-Qt to
avoid paying excessive fees and queue-jumping. Guess that's on my
plate.
(3) Scalability improvements seem like a no brainer to everyone, it's
just a case of how complicated they are.
(4) Making the block size limit float is better than picking a new
arbitrary threshold.
On the forums Matt stated that block chain pruning was a no-go because
"it makes bitcoin more centralized". I think we've thrashed this one
out sufficiently well by now that there should be a united opinion on
it. There are technical ways to implement it such that there is no
change of trust requirements. All the other issues (finding archival
nodes, etc) can be again addressed with sufficient programming.
For the case of huge blocks slowing down end user syncing and wasting
their resources, SPV clients like MultiBit and Android Wallet already
exist and will get better with time. If Jeff implements the bloom
filtering p2p commands I'll make bitcoinj use them and that'll knock
out excessive bandwidth usage and parse overheads from end users who
are on these clients. At some point Bitcoin-Qt can have a dual mode,
but who knows when that'll get implemented.
Does that all sound reasonable?
|
