From: Peter Todd <pete@petertodd•org>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Making fee estimation better
Date: Fri, 25 Oct 2013 03:07:08 -0400 [thread overview]
Message-ID: <20131025070708.GA5760@savin> (raw)
In-Reply-To: <CABsx9T0T0v=HnRRr6BLKNQOFMBJWrhF4G4SOCJ9DidGJBB8Eow@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2284 bytes --]
On Fri, Oct 25, 2013 at 06:39:34AM +1000, Gavin Andresen wrote:
> Yes, and I asked Luke what percentage of that 10% is OOB fee payments, and
> the answer is "a small percentage."
>
> So: there are multiple layers of reasons why OOB fee payments will not
> screw up the fee estimation code:
I've responded to nearly all those arguments elsewhere, but anyway...
> And all of the above is completely orthogonal to child-pays-for-parent
> and/or replace-with-higher-fee.
Indeed. Quoting myself here: "What we should have is both: fee
estimation with replacement so you can replace transactions in the event
that the estimate was too low."
So on IRC you were talking about very agressive mempool expiration - as
little as a block or two before tx's are expired. Now if a tx does fail
to get mined in that short window, am I correct in saying you want a way
to modify the fee it pays and rebroadcast? In which case wallet software
and other players in the ecosystem will have to adjust to the fact that
they can expect to see relatively frequent double-spends of unconfirmed
transactions?
As you know I've already written relaying/mempool code for
tx-replacement and replace-by-fee; it's the wallet code that's the hard
part that I haven't done. If you're already planning on changing the
wallet side of things to handle replacement-through-expiration that'd
save me a lot of hard work. You're probably better qualified to write
that code too; I'm not very familiar with the wallet.
Worth thinking about the whole ecosystem of wallets involved; they all
have to handle double-spends gracefully to make tx replacement of any
kind user friendly. We should try to give people a heads up that this is
coming soon if that's your thinking.
Also, regarding tx replacement user experience:
> Come back a few hours later and find out you need to type in your
> password again so your client can unlock your wallet, resign, and
> re-transmit with a higher fee?
Password-using wallets sign multiple versions of the transaction in
advance of course and release the higher fee versions only later if
required. (could be applied to coinjoin too)
--
'peter'[:-1]@petertodd.org
0000000000000005391e2338afe5204414d66b1f140b172da651daedf5663af2
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
next prev parent reply other threads:[~2013-10-25 7:07 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-24 14:30 Peter Todd
2013-10-24 14:38 ` Mike Hearn
2013-10-24 14:43 ` Peter Todd
2013-10-24 14:46 ` Mike Hearn
2013-10-24 14:54 ` Peter Todd
2013-10-24 20:39 ` Gavin Andresen
2013-10-25 7:07 ` Peter Todd [this message]
2013-10-25 12:02 ` Andreas Petersson
2013-10-25 13:29 ` Mark Friedenbach
2013-10-25 14:08 ` Andreas Petersson
2013-10-25 16:13 ` Peter Todd
2013-10-25 19:35 ` Jeremy Spilman
2013-10-25 22:13 ` Peter Todd
2013-10-25 7:51 ` Jeremy Spilman
2013-10-25 22:49 ` Peter Todd
2013-10-26 0:25 ` Gavin Andresen
2013-10-26 7:28 ` Peter Todd
2013-10-28 7:17 ` John Dillon
2013-11-04 10:52 ` [Bitcoin-development] Zeroconf-safe tx replacement (replace-for-fee) Peter Todd
2013-11-04 11:10 ` Adam Back
2013-11-04 11:59 ` Peter Todd
[not found] <mailman.289181.1382717617.21953.bitcoin-development@lists.sourceforge.net>
2013-10-25 16:40 ` [Bitcoin-development] Making fee estimation better Tamas Blummer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131025070708.GA5760@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gavinandresen@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox