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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <luke@dashjr.org>) id 1Qg0ev-0000wt-I4
for bitcoin-development@lists.sourceforge.net;
Sun, 10 Jul 2011 20:31:21 +0000
X-ACL-Warn:
Received: from zinan.dashjr.org ([173.242.112.54])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Qg0eq-0004aA-LB for bitcoin-development@lists.sourceforge.net;
Sun, 10 Jul 2011 20:31:21 +0000
Received: from ishibashi.localnet (fl-67-77-87-241.dhcp.embarqhsd.net
[67.77.87.241]) (Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 74B0A560565;
Sun, 10 Jul 2011 20:31:08 +0000 (UTC)
From: "Luke-Jr" <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Sun, 10 Jul 2011 16:30:53 -0400
User-Agent: KMail/1.13.7 (Linux/2.6.39-gentoo; KDE/4.6.4; x86_64; ; )
References: <BANLkTinus7PWNLJi9rEvTtSB93hjLKhFpg@mail.gmail.com>
<201107101442.43605.luke@dashjr.org>
<1310325132.2230.20.camel@Desktop666>
In-Reply-To: <1310325132.2230.20.camel@Desktop666>
X-PGP-Key-Fingerprint: CE5A D56A 36CC 69FA E7D2 3558 665F C11D D53E 9583
X-PGP-Key-ID: 665FC11DD53E9583
X-PGP-Keyserver: x-hkp://subkeys.pgp.net
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201107101630.55518.luke@dashjr.org>
X-Spam-Score: 0.1 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain 0.1 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Qg0eq-0004aA-LB
Subject: Re: [Bitcoin-development] Useful bitcoin patches...
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: Sun, 10 Jul 2011 20:31:21 -0000
On Sunday, July 10, 2011 3:12:12 PM Matt Corallo wrote:
> On Sun, 2011-07-10 at 14:42 -0400, Luke-Jr wrote:
> > For the "3diff" version, I extracted and made proper git branches for
> > each logical part:
> > hub_mode
>
> No, no, no, no, no. This has been discussed several times and provides
> little to no advantage for miners and has the potential to severely harm
> the network.
I just said it exists. I don't expect anyone to promote or merge it.
> > In addition, I also consider these branches valid candidates for merging:
> > coinbaser (popens a given command and reads coinbase outputs from
> > stdout)
>
> Seems like you are the only one who would benifit here, as noone else
> but eligius changes coinbase output to a random set.
I suspect because they haven't figured out how. Take it or leave it.
> > minfee_modes (internal function changes to allow specifying different
> > fees for relay, send, or accept-in-block)
>
> We don't need something that just generically changes the functions to
> allow whatever fee you want, we need something more generalized to allow
> more custom settings, not just blind accept if fee is x per kb or
> something. Sipa has suggested various things that should allow for more
> fee control by the users while still preventing users from sending
> transactions that lock their coins in limbo.
This is a step in that direction, at least, by providing the mode as input.
Since 0.4 is moving to Qt, perhaps moving GetMinFee to QtScript is
appropriate.
> > \-- eligius_relay (relay lower fees only Eligius will accept)
> > \-- eligius_sendfee (send lower fees only Eligius will accept)
>
> No, and no. Just because you are willing to accept lower fees doesn't
> mean the incentives are right to prevent DDoS. The fees aren't there to
> support the miners (not for a while, at least) they are there to prevent
> stupid users from DDoSing and just generally wasting everyone else's
> resources for no reason.
Again, take it or leave it, but in the meantime you're asking for trouble from
users who feel they're being forced to pay more than they have to. Or perhaps
rather than trouble, that decision will increase awareness of other clients
that don't try to control the users. That could be good too.
|
