diff options
| author | Luke Dashjr <luke@dashjr.org> | 2015-11-12 21:26:38 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-11-12 21:27:20 +0000 |
| commit | 4a0168547a5622d450ed68bb080094b7eda20b77 (patch) | |
| tree | 29a4a2c436541354d709abc6175b7b10a39db7a6 | |
| parent | 6110e298057f4aaa06ed0500e6d20380d18d9947 (diff) | |
| download | pi-bitcoindev-4a0168547a5622d450ed68bb080094b7eda20b77.tar.gz pi-bitcoindev-4a0168547a5622d450ed68bb080094b7eda20b77.zip | |
Re: [bitcoin-dev] Upcoming Transaction Priority Changes
| -rw-r--r-- | ca/386157d6a498fb3432a7c81626882f263ae35c | 76 |
1 files changed, 76 insertions, 0 deletions
diff --git a/ca/386157d6a498fb3432a7c81626882f263ae35c b/ca/386157d6a498fb3432a7c81626882f263ae35c new file mode 100644 index 000000000..dff76d74b --- /dev/null +++ b/ca/386157d6a498fb3432a7c81626882f263ae35c @@ -0,0 +1,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 + |