From: Nathan Wilcox <nathan@leastauthority•com>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism
Date: Thu, 11 Jun 2015 12:18:50 -0600 [thread overview]
Message-ID: <CAFdHNGgtf+AuW=yMegCuFPNPpi6GgArsTkBWbdVxKNY6R7Erug@mail.gmail.com> (raw)
In-Reply-To: <20150611131048.GA24053@savin.petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 2812 bytes --]
On Thu, Jun 11, 2015 at 7:10 AM, Peter Todd <pete@petertodd•org> wrote:
> On Wed, Jun 10, 2015 at 02:18:30PM -0700, Aaron Voisine wrote:
> > The other complication is that this will tend to be a lagging indicator
> > based on network congestion from the last time you connected. If we
> assume
> > that transactions are being dropped in an unpredictable way when blocks
> are
> > full, knowing the network congestion *right now* is critical, and even
> then
> > you just have to hope that someone who wants that space more than you do
> > doesn't show up after you disconnect.
>
> Hence the need for ways to increase fees on transactions after initial
> broadcast like replace-by-fee and child-pays-for-parent.
>
>
I haven't looked closely at replace-by-fee yet, but I assume this is a
non-consensus change to mempool mechanics. To me, this seems like the
"actuator" side of fee mechanics: it provides a transaction sender a way to
influence the system. By contrast, learning about fees is the "sensor"
side of fee mechanics.
Consider how a replace-by-fee wallet makes fee decisions. When does it
replace by fee? It needs feedback in one of two forms:
a. Direct feedback from a trnasaction relay service, or:
b. Information in the blockchain, which is verified by all verifying nodes
and refined by all miners.
The first kind of information is quite acceptable and practical for many
use cases, but leave the wallet vulnerable to fabrications by that service.
This vulnerability is precisely what SPV security intends to mitigate,
right?
With only information type a, a (non-SPV) wallet can "shop around" to find
competing services, and this should work pretty well, provided the wallet
can discover those competing services. If, OTOH, the wallet has access to
information type b, it now has "perfect competition" across all such
services, even when it can't discover the low-priced services directly.
This actual-fees-in-the-actual-block-chain information of type b seem like
a powerful source of pricing information, and if SPV security is already
valuable for other reasons, then it seems natural to leverage that value.
Re: "dropped in an unpredictable way" - transactions would be dropped
> lowest fee/KB first, a completely predictable way.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000124bae79afdcee9267b4e6f8137758b8b4135455cd8e3bfd
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Nathan Wilcox
Least Authoritarian
email: nathan@leastauthority•com
twitter: @least_nathan
PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993
[-- Attachment #2: Type: text/html, Size: 3956 bytes --]
prev parent reply other threads:[~2015-06-11 18:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-10 17:37 Nathan Wilcox
2015-06-10 19:19 ` Aaron Voisine
2015-06-10 20:00 ` Nathan Wilcox
2015-06-10 20:03 ` Peter Todd
2015-06-11 18:30 ` Nathan Wilcox
2015-06-11 18:55 ` Aaron Voisine
2015-06-13 15:38 ` Nathan Wilcox
2015-06-10 21:18 ` Aaron Voisine
2015-06-10 20:26 ` Mike Hearn
2015-06-10 21:18 ` Aaron Voisine
2015-06-11 10:19 ` Mike Hearn
2015-06-11 13:10 ` Peter Todd
2015-06-11 14:11 ` Martin Lie
2015-06-11 17:10 ` Tom Harding
2015-06-11 17:52 ` Mike Hearn
2015-06-12 6:44 ` Aaron Voisine
2015-06-11 18:18 ` Nathan Wilcox [this message]
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='CAFdHNGgtf+AuW=yMegCuFPNPpi6GgArsTkBWbdVxKNY6R7Erug@mail.gmail.com' \
--to=nathan@leastauthority$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pete@petertodd$(echo .)org \
/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