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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
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 1VZMBT-0002sV-LC
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Oct 2013 14:46:47 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.179 as permitted sender)
client-ip=209.85.214.179; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f179.google.com;
Received: from mail-ob0-f179.google.com ([209.85.214.179])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VZMBS-00024O-SV
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Oct 2013 14:46:47 +0000
Received: by mail-ob0-f179.google.com with SMTP id uy5so2375075obc.24
for <bitcoin-development@lists.sourceforge.net>;
Thu, 24 Oct 2013 07:46:41 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.117.164 with SMTP id kf4mr522696obb.104.1382626001467;
Thu, 24 Oct 2013 07:46:41 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.156.42 with HTTP; Thu, 24 Oct 2013 07:46:41 -0700 (PDT)
In-Reply-To: <20131024144358.GA17142@savin>
References: <20131024143043.GA12658@savin>
<CANEZrP100Lg_1LcFMKx1yWrGTSFb5GZmLmXNbZjPGaiEgOeuwA@mail.gmail.com>
<20131024144358.GA17142@savin>
Date: Thu, 24 Oct 2013 16:46:41 +0200
X-Google-Sender-Auth: LXD0z2eWlbg3OU7EH5YrMk8NO84
Message-ID: <CANEZrP1TfM+wYbGjUk3+8JJZs6cKZXdb57xGMc=hDr9dQjMMZA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=089e015382b8acbec504e97db346
X-Spam-Score: -0.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.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: petertodd.org]
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1VZMBS-00024O-SV
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: Thu, 24 Oct 2013 14:46:47 -0000
--089e015382b8acbec504e97db346
Content-Type: text/plain; charset=UTF-8
Well, miners are all supposed to be more or less equivalent - modulo
differences in tx acceptance policies - so I'd hope that having out of bad
fee mechanisms yet still broadcasting the TX isn't that common. If it was
broadcasted, it should get mined in short order, otherwise things are going
wrong.
On Thu, Oct 24, 2013 at 4:43 PM, Peter Todd <pete@petertodd.org> wrote:
> Anyway, in what circumstance would a customer want an exclusive contract
> with a miner?
>
I was thinking for transactions that aren't standard so have to be
submitted to miners directly.
--089e015382b8acbec504e97db346
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Well, miners are all supposed to be more or less equi=
valent - modulo differences in tx acceptance policies - so I'd hope tha=
t having out of bad fee mechanisms yet still broadcasting the TX isn't =
that common. If it was broadcasted, it should get mined in short order, oth=
erwise things are going wrong.</div>
<div><br></div>On Thu, Oct 24, 2013 at 4:43 PM, Peter Todd <span dir=3D"ltr=
"><<a href=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petertod=
d.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gma=
il_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><span style=3D"color:rgb(3=
4,34,34)">Anyway, in what circumstance would a customer want an exclusive c=
ontract</span><br>
</div>
with a miner?<br></blockquote><div><br></div><div>I was thinking for transa=
ctions that aren't standard so have to be submitted to miners directly.=
</div></div></div></div>
--089e015382b8acbec504e97db346--
|
