From: Mike Hearn <mike@plan99•net>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Near-term scalability
Date: Sat, 16 Jun 2012 09:55:55 +0200 [thread overview]
Message-ID: <CANEZrP2pgBQUj7TYhyAw38p5KKNjmg_mOG4+O-A0DENErYbk5Q@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T0Z3xKGOO=4Tr94cKTBpfUwHQ_qHJPidB_MPYAGCJV=VQ@mail.gmail.com>
[resend, sorry gavin]
I think these ideas all make a ton of sense, some have been floating
around for a while in various forms but it's good to draw them
together coherently.
> o Fill up the "free" space (if any) with the highest-priority
> transactions, where priority is a function of transaction size, age of
> inputs, number of bitcoins... and ratio of inputs to outputs (to
> encourage combining inputs so more pruning is possible).
Is more incentive needed? If you have tons of tiny outputs you already
have incentives to merge them because otherwise your txns will become
large and the fees needed to overcome the DoS limits and gain priority
will rise.
The code to do it is a bit irritating as you really want to de-frag
wallets in the background when the user is not likely to need the
outputs quickly, and I suspect over time transaction volumes will
become diurnal so it'd be cheaper to do that at night time, but it's
all possible.
> But that won't work for newly started clients that haven't seen a lot
> of transactions enter/exit the memory pool
Peers could provide first-seen timestamps for transactions when
announced or when downloaded with Jeffs proposed command, but the
timestamps are not necessarily trustable. Not sure if that'd open up
new attacks.
> or SPV clients that can't lookup transaction inputs
SPV clients can do it by getdata-ing on the relevant inputs, but it's
very bandwidth intensive just to guesstimate fees.
> Maybe each client developer runs a "fee policy server"
That's reasonable. I don't believe this case is worth worrying about
right now. For the common cases of
a) Customer buys from merchant (runs full node)
b) Trusted person sends money to trusting person (does not need confirms)
it wouldn't matter after the changes to the block creation code. It's
only really an issue when a user running an SPV client wishes to
accept money from somebody they do not trust, and they want it to
confirm quick-ish (within an hour), but can tolerate delays up to
that. I think this is likely to be rare.
Much more common is that you want to accept the payment immediately,
which is an oft discussed but different problem.
prev parent reply other threads:[~2012-06-16 7:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-15 11:29 Mike Hearn
2012-06-15 13:08 ` Matt Corallo
2012-06-15 13:34 ` Mike Hearn
2012-06-15 16:18 ` Matt Corallo
[not found] ` <CAAS2fgTJ0UH0Gr6gVMNZwOiv41WzZVesyvNCULj8UfCPPGxQrw@mail.gmail.com>
2012-06-15 16:53 ` Gregory Maxwell
2012-06-15 16:56 ` Stefan Thomas
2012-06-15 17:37 ` Mike Koss
2012-06-15 18:38 ` Amir Taaki
[not found] ` <CAAS2fgSVbYFkkhP_0Ny5ULB-DJKN-3hZLkqWukrGL80-UenMwQ@mail.gmail.com>
2012-06-15 18:50 ` Amir Taaki
2012-06-15 18:55 ` Gregory Maxwell
2012-06-15 20:56 ` Gavin Andresen
2012-06-16 7:55 ` Mike Hearn [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=CANEZrP2pgBQUj7TYhyAw38p5KKNjmg_mOG4+O-A0DENErYbk5Q@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--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