summaryrefslogtreecommitdiff
path: root/e0/504f8d653e045e91e45e5ce6121be538e4c67c
blob: 7fac4886e110196bb01fb20e01d33308d8d2b106 (plain)
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
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 <john.dillon892@googlemail.com>) id 1Vah5J-0006rQ-DU
	for bitcoin-development@lists.sourceforge.net;
	Mon, 28 Oct 2013 07:17:57 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of googlemail.com
	designates 74.125.83.45 as permitted sender)
	client-ip=74.125.83.45;
	envelope-from=john.dillon892@googlemail.com;
	helo=mail-ee0-f45.google.com; 
Received: from mail-ee0-f45.google.com ([74.125.83.45])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Vah5I-0004Nh-E1
	for bitcoin-development@lists.sourceforge.net;
	Mon, 28 Oct 2013 07:17:57 +0000
Received: by mail-ee0-f45.google.com with SMTP id c50so4139637eek.4
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 28 Oct 2013 00:17:50 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.14.3.9 with SMTP id 9mr904677eeg.72.1382944670161; Mon, 28
	Oct 2013 00:17:50 -0700 (PDT)
Received: by 10.223.135.132 with HTTP; Mon, 28 Oct 2013 00:17:50 -0700 (PDT)
In-Reply-To: <CABsx9T0nc-TO1_=n47UnYHiWKSNvci9Xyhni9PQa=DRo1B7FDg@mail.gmail.com>
References: <20131024143043.GA12658@savin>
	<CANEZrP100Lg_1LcFMKx1yWrGTSFb5GZmLmXNbZjPGaiEgOeuwA@mail.gmail.com>
	<20131024144358.GA17142@savin>
	<CANEZrP1TfM+wYbGjUk3+8JJZs6cKZXdb57xGMc=hDr9dQjMMZA@mail.gmail.com>
	<20131024145447.GA19949@savin>
	<CABsx9T0T0v=HnRRr6BLKNQOFMBJWrhF4G4SOCJ9DidGJBB8Eow@mail.gmail.com>
	<op.w5h2rwhcyldrnw@laptop-air>
	<CABsx9T0nc-TO1_=n47UnYHiWKSNvci9Xyhni9PQa=DRo1B7FDg@mail.gmail.com>
Date: Mon, 28 Oct 2013 07:17:50 +0000
Message-ID: <CAPaL=UVnfVkU_mbQKE2gg7RXBv+B13A1eHU4VpiHkBdmfea80g@mail.gmail.com>
From: John Dillon <john.dillon892@googlemail.com>
To: Gavin Andresen <gavinandresen@gmail.com>, Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.3 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
	See
	http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
	for more information. [URIs: googlemail.com]
	-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
	(john.dillon892[at]googlemail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
	digit (john.dillon892[at]googlemail.com)
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	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: 1Vah5I-0004Nh-E1
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Making fee estimation better
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: Mon, 28 Oct 2013 07:17:57 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, Oct 26, 2013 at 12:25 AM, Gavin Andresen
<gavinandresen@gmail.com> wrote:
> I feel like there is a lot of "in the weeds" discussion here about
> theoretical, what-if-this-and-that-happens-in-the-future scenarios.
>
> I would just like to point out (again) that this is not intended to be Th=
e
> One True Solution For Transaction Fees And Transaction Prioritization. If
> you've got a better mechanism for estimating fees, fantastic! If it turns
> out estimates are often-enough wrong to be a problem and you've got a
> solution for that, fantastic!

This discussion seems to be a lot of hot air over a simple observation that
estimates are imperfect and always will be. I do not understand you vehemen=
t
opposition the notion that a backup is a good thing except in the context t=
hat
replacement to change fees is halfway to profit-seeking replacement by fee.


Peter Todd:

You did a fair bit of leg work for replace-by-fee. Seems to me that
replace-for-fee will help prep infrastructure to eventual replace-by-fee us=
age,
while avoiding some of the politics around zero-conf transactions.

Go dust off your code and make it happen. I want to see a mempool
implementation similar to what you did for me on replace-for-fee, and I
understand much of the code is written in any case. This time I also want t=
o
see a increasetxfee RPC command, and erasewallettx RPC command to deal with
duplicates. (I know touching the wallet code is scary) Having all will enab=
le
usage, and I can imagine getting pools to use this will be easy enough.
(eligius?)

Here is your 4BTC bounty. In the event I am not around Gregory Maxwell can =
also
adjudicate. If both you and him feel someone else deserves it, by all means
send them the funds

bitcoind decodescript
522102d527466a144aac2030cd16d8be3d91231af26a95c2f8fc345a0ea0e8d53ac3914104d=
34775baab521d7ba2bd43997312d5f663633484ae1a4d84246866b7088297715a049e2288ae=
16f168809d36e2da1162f03412bf23aa5f949f235eb2e71417834104f005d39733ec09a1efa=
0cf8dcf3df50691e22c2374ff9a96d1d9ecb98a1e866c9f558a9fa1ba8ef0bbbad01f396768=
c0cb2dda9924dc0aaee1481604a8bd9ce453ae
{
    "asm" : "2 02d527466a144aac2030cd16d8be3d91231af26a95c2f8fc345a0ea0e8d5=
3ac391
04d34775baab521d7ba2bd43997312d5f663633484ae1a4d84246866b7088297715a049e228=
8ae16f168809d36e2da1162f03412bf23aa5f949f235eb2e7141783
04f005d39733ec09a1efa0cf8dcf3df50691e22c2374ff9a96d1d9ecb98a1e866c9f558a9fa=
1ba8ef0bbbad01f396768c0cb2dda9924dc0aaee1481604a8bd9ce4
3 OP_CHECKMULTISIG",
    "reqSigs" : 2,
    "type" : "multisig",
    "addresses" : [
        "1L9p6QiWs2nfinyF4CnbqysWijMvvcsnxe",
        "1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv",
        "1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB"
    ],
    "p2sh" : "3BST1dPxvgMGL3d9GPCHvTyZNsJ7YKTVPo"
}

(I realized right after my Tor payment protocol bounty that I would need so=
me
bit of uniqueness like a bounty-specific pubkey to disambiguate multiple su=
ch
bounties!)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJSbg9wAAoJEEWCsU4mNhiPROQH/j+eWccx7oSVsr94cgGu7qza
kdnA7B6BAlnCPg3D+nqEFKDqzOyFppeHLadCCIYHHc5iVRfJuu9J1Gh9lgMCuyCW
qN7ZOBCARjiVOqrHPQR1pf18i0ko7dQWw2hZjy51XKuFxAsHwZpB/fzQCbVVzyB6
l5SECCou58bJ/x7B0L93K+yjXuMGnvi9jqiLAKkLWYDzVm7TeVWNVQr04B7sqi6A
mY+BfG61e7sqM2UJd69yGLeQdEfghYTmtA+EaaqYS0L11m7yFGZdUqD7UNy1FKO7
44M1JTh2ANnQRjSTJWOBXQNHMa/mxDCji1VFUtJhZKEuOZyWpGm7HMH1D3vcvcQ=3D
=3D4flN
-----END PGP SIGNATURE-----