From: Peter Todd <pete@petertodd.org>
To: Andreas Petersson <andreas@petersson.at>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Making fee estimation better
Date: Fri, 25 Oct 2013 12:13:23 -0400 [thread overview]
Message-ID: <20131025161323.GA15774@petertodd.org> (raw)
In-Reply-To: <91968c56640bf7647325728f490b9257@localhost>
[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]
On Fri, Oct 25, 2013 at 02:02:35PM +0200, Andreas Petersson wrote:
>
>
> > 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.
>
> If there is a situation where wallets are supposed to constantly monitor
> the tx propagation and recreate their transactions with different fees,
> this would make a lot of usecases inconvenient.
> half-offline bluetooth transactions, users with unstable connections,
> battery power lost, etc, etc. - and last but not least power concerns on
> hardware wallets on the bitcoincard (tx signing drains a significant amount
> of power and should therefore only be done once)
Anyway, as I've said repeatedly my problem with fee estimation is that
it needs to be combined with some form of transaction replacement to
give users a way to recover from bad estimates, not that I think the
idea shouldn't be implemented at all. After all, we alrady have fee
estimation: wallet authors and users manully estimate fees!
This particular case is a nasty one re: recovering from a bad estimate,
and it's exactly why the payment protocol is designed for the sender to
give the receiver a copy of every transaction they make so the receiver
can be held responsible for getting them mined, eg. with
child-pays-for-parent, out-of-band fee payment, or maybe even by adding
inputs to the transaction. (SIGHASH_ANYONECANPAY)
--
'peter'[:-1]@petertodd.org
0000000000000001231d6e04b4b18f85fa0ad00e837727e7141eaa8cfecc734b
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2013-10-25 16:13 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-24 14:30 [Bitcoin-development] Making fee estimation better 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
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 [this message]
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=20131025161323.GA15774@petertodd.org \
--to=pete@petertodd.org \
--cc=andreas@petersson.at \
--cc=bitcoin-development@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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