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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tomh@thinlink.com>) id 1Z360L-0007Tn-BP
for bitcoin-development@lists.sourceforge.net;
Thu, 11 Jun 2015 17:11:01 +0000
X-ACL-Warn:
Received: from mail-qg0-f52.google.com ([209.85.192.52])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z360K-0007xA-Fk
for bitcoin-development@lists.sourceforge.net;
Thu, 11 Jun 2015 17:11:01 +0000
Received: by qgf75 with SMTP id 75so3906298qgf.1
for <bitcoin-development@lists.sourceforge.net>;
Thu, 11 Jun 2015 10:10:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
:subject:references:in-reply-to:content-type
:content-transfer-encoding;
bh=VGXNDTh0J/TdUTQ/ViU89RvP51at/V/huYC4ckdkHs4=;
b=mVsWN0gvbFHY3GXHkmCQEw5yXFeXp+B/EiHw8FhhLHaWPkT+RNyz3O41mH8E8ptqG2
zpOObN+Ji4+qtsikYVZoOX/Cull6xuvvQ34qUolDYEPOTFIGB0ogUsp5wdO9fH9QK0Ns
fY1k2Wi0TzUA/C3+zBzruqgBaGyJWX5oTwr4vmZVBi1LtAcVLZyNx7LGFMNTaoHRxxPW
oWocg2anthKa2dAAnSpjg9sJ3aTOASO1R4W/vu5P/2mMdOnpaWBBuJZs3zmm1jo9TLZm
AJvoeqxxdDG0MlEZrM1aJiwO5eQwLmyRpzJveSVg/5+UUNWG5SiDfET3h1JEgXByB4yG
+bUA==
X-Gm-Message-State: ALoCoQnWm6WSldTSoJxmn9RrAn5Q5ht/2SSycYCdRbx3zoE8ZTKSS86BOzve0zZwhsB5zwCVCLLY
X-Received: by 10.140.91.246 with SMTP id z109mr12746532qgd.39.1434042654993;
Thu, 11 Jun 2015 10:10:54 -0700 (PDT)
Received: from [10.100.1.239] ([204.58.254.99])
by mx.google.com with ESMTPSA id i91sm495352qgd.46.2015.06.11.10.10.53
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 11 Jun 2015 10:10:53 -0700 (PDT)
Message-ID: <5579C0FE.8080701@thinlink.com>
Date: Thu, 11 Jun 2015 10:10:22 -0700
From: Tom Harding <tomh@thinlink.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CAFdHNGgtgWGu8gnnJfM0EcVn2m_Wff5HPwAe-9FBvjR++q0Q-Q@mail.gmail.com> <CANEZrP3+jW3BO=Zv41CGubJL7bSZ==o=Wp83K6Q0xL4PP+0ZUQ@mail.gmail.com> <CACq0ZD6Qr7F7_20Nfd0a8TTHEVMR0fxu-T5bO4FfN1Lp9PcGDQ@mail.gmail.com>
<20150611131048.GA24053@savin.petertodd.org>
In-Reply-To: <20150611131048.GA24053@savin.petertodd.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server
[204.58.254.99 listed in dnsbl.sorbs.net]
X-Headers-End: 1Z360K-0007xA-Fk
Subject: Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism
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, 11 Jun 2015 17:11:01 -0000
On 6/11/2015 6:10 AM, Peter Todd wrote:
> On Wed, Jun 10, 2015 at 02:18:30PM -0700, Aaron Voisine wrote:
>> The other complication is that this will tend to be a lagging indicator
>> based on network congestion from the last time you connected. If we assume
>> that transactions are being dropped in an unpredictable way when blocks are
>> full, knowing the network congestion *right now* is critical, and even then
>> you just have to hope that someone who wants that space more than you do
>> doesn't show up after you disconnect.
> Hence the need for ways to increase fees on transactions after initial
> broadcast like replace-by-fee and child-pays-for-parent.
>
> Re: "dropped in an unpredictable way" - transactions would be dropped
> lowest fee/KB first, a completely predictable way.
Quite agreed. Also, transactions with unconfirmed inputs should be
among the first to get dropped, as discussed in the "Dropped-transaction
spam" thread. Like all policy rules, either of these works in
proportion to its deployment.
Be advised that pull request #6068 emphasizes the view that the network
will never have consistent mempool/relay policies, and on the contrary
needs a framework that supports and encourages pluggable, generally
parameterized policies that could (some might say should) conflict
wildly with each other.
It probably doesn't matter that much. Deploying a new policy still
wouldn't be much easier than deploying a patched version. I mean,
nobody has proposed a policy rule engine yet (oops).
|