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
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1F58F953
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 12 Nov 2015 21:27:20 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id BDC0516E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 12 Nov 2015 21:27:19 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:61b6:56a6:b03d:28d6])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 5790138A6EAE;
Thu, 12 Nov 2015 21:26:46 +0000 (UTC)
X-Hashcash: 1:25:151112:morcos@gmail.com::cZt506EEBxQz/TaL:a/8Bd
X-Hashcash: 1:25:151112:jtimon@jtimon.cc::nRU9hOPPFyhqx2qZ:a=x=C
X-Hashcash: 1:25:151112:bitcoin-dev@lists.linuxfoundation.org::rliA3mTVkaQNRrxd:atRbc
From: Luke Dashjr <luke@dashjr.org>
To: Alex Morcos <morcos@gmail.com>
Date: Thu, 12 Nov 2015 21:26:38 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.9-gentoo-r1; KDE/4.14.8; x86_64; ; )
References: <5644ECE6.9090304@mattcorallo.com>
<201511122110.47665.luke@dashjr.org>
<CAPWm=eXNFimrG1A7bxJ3i=w_iWm57r93bjfiGZwq9y8KbZ8+Qg@mail.gmail.com>
In-Reply-To: <CAPWm=eXNFimrG1A7bxJ3i=w_iWm57r93bjfiGZwq9y8KbZ8+Qg@mail.gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201511122126.39532.luke@dashjr.org>
X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Upcoming Transaction Priority Changes
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Nov 2015 21:27:20 -0000
On Thursday, November 12, 2015 9:21:57 PM Alex Morcos wrote:
> To be clear Luke, its not THAT complicated to maintain the mining policy,
> but preserving the ability of people to place priority based transactions
> in a limited mempool world is quite complicated. See recently closed
> #6992.
> I think the biggest issue with #6357 is being sure the logic doesn't break
> in future changes. There are a lot of things that need to be updated in
> the right order when blocks are connected or disconnected.
That's what unit tests are for. :)
> And whats the point of having even that added extra complication if its not
> easy to place free transactions and starting priority is a decent
> approximation for mining anyway (txs can just be rebroadcast in the worst
> case).
I'm not sure what you're getting at here, but rebroadcasting won't work if
they're still in the memory pools (unless we open the door to DoS from
reprocessing the same tx over and over).
Luke
|
