From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: <20131024143043.GA12658@savin> <20131024144358.GA17142@savin> <20131024145447.GA19949@savin> Date: Mon, 28 Oct 2013 07:17:50 +0000 Message-ID: From: John Dillon To: Gavin Andresen , Peter Todd 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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-----