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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Sfnra-0007CV-Ra
for bitcoin-development@lists.sourceforge.net;
Sat, 16 Jun 2012 07:56:06 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.181 as permitted sender)
client-ip=209.85.212.181; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f181.google.com;
Received: from mail-wi0-f181.google.com ([209.85.212.181])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Sfnra-0000ZT-4E
for bitcoin-development@lists.sourceforge.net;
Sat, 16 Jun 2012 07:56:06 +0000
Received: by wibhn14 with SMTP id hn14so178228wib.10
for <bitcoin-development@lists.sourceforge.net>;
Sat, 16 Jun 2012 00:56:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.8.69 with SMTP id p5mr9917625wia.17.1339833355406; Sat, 16
Jun 2012 00:55:55 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.216.254.232 with HTTP; Sat, 16 Jun 2012 00:55:55 -0700 (PDT)
In-Reply-To: <CABsx9T0Z3xKGOO=4Tr94cKTBpfUwHQ_qHJPidB_MPYAGCJV=VQ@mail.gmail.com>
References: <CANEZrP3w+AiTXmv9Wb3Zi5yyFmGPk82-ysVo4_DVvtg8HHBCdQ@mail.gmail.com>
<CABsx9T0Z3xKGOO=4Tr94cKTBpfUwHQ_qHJPidB_MPYAGCJV=VQ@mail.gmail.com>
Date: Sat, 16 Jun 2012 09:55:55 +0200
X-Google-Sender-Auth: grbDIn7wI9ZEQRqMTniVcadRG7E
Message-ID: <CANEZrP2pgBQUj7TYhyAw38p5KKNjmg_mOG4+O-A0DENErYbk5Q@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.4 (-)
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
0.1 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Sfnra-0000ZT-4E
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: Sat, 16 Jun 2012 07:56:06 -0000
[resend, sorry gavin]
I think these ideas all make a ton of sense, some have been floating
around for a while in various forms but it's good to draw them
together coherently.
> o Fill up the "free" space (if any) with the highest-priority
> transactions, where priority is a function of transaction size, age of
> inputs, number of bitcoins... and ratio of inputs to outputs (to
> encourage combining inputs so more pruning is possible).
Is more incentive needed? If you have tons of tiny outputs you already
have incentives to merge them because otherwise your txns will become
large and the fees needed to overcome the DoS limits and gain priority
will rise.
The code to do it is a bit irritating as you really want to de-frag
wallets in the background when the user is not likely to need the
outputs quickly, and I suspect over time transaction volumes will
become diurnal so it'd be cheaper to do that at night time, but it's
all possible.
> But that won't work for newly started clients that haven't seen a lot
> of transactions enter/exit the memory pool
Peers could provide first-seen timestamps for transactions when
announced or when downloaded with Jeffs proposed command, but the
timestamps are not necessarily trustable. Not sure if that'd open up
new attacks.
> or SPV clients that can't lookup transaction inputs
SPV clients can do it by getdata-ing on the relevant inputs, but it's
very bandwidth intensive just to guesstimate fees.
> Maybe each client developer runs a "fee policy server"
That's reasonable. I don't believe this case is worth worrying about
right now. For the common cases of
a) Customer buys from merchant (runs full node)
b) Trusted person sends money to trusting person (does not need confirms)
it wouldn't matter after the changes to the block creation code. It's
only really an issue when a user running an SPV client wishes to
accept money from somebody they do not trust, and they want it to
confirm quick-ish (within an hour), but can tolerate delays up to
that. I think this is likely to be rare.
Much more common is that you want to accept the payment immediately,
which is an oft discussed but different problem.
|
