From: Peter Todd <pete@petertodd•org>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Floating fees and SPV clients
Date: Tue, 3 Dec 2013 06:31:17 -0500 [thread overview]
Message-ID: <20131203113117.GA12623@tilt> (raw)
In-Reply-To: <CANEZrP3tGdFh6oG5fbX9JbU6sYbbex1cq=0tQB-0A4aDrdbXrQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3257 bytes --]
On Sun, Dec 01, 2013 at 12:51:46PM +0100, Mike Hearn wrote:
> 4) Finally, when we next hard fork, we make v2 transactions include the
> output value in the signature, same as the output script (this proposal has
> been on the forums for a while now). That allows the fee data added in step
> 2 to be cross-checked against the signatures on the inputs, thus
> authenticating it.
FTFY s/hard-fork/soft-fork/
The proposals on the forums with regard to a soft-fork are for a new
transaction format - to be done in parallel with the old one - that
commits to transaction inputs and outputs via a merkle tree extending
into the transaction. This data is then committed to via the merge-mine
standard.
In addition, all this discussion about trying to figure out transaction
fees based on transaction is a bit irrelevant if you suppose a
soft-fork. We already know that we need a merkle-sum-tree of fees and
transaction size to be able to audit miners and create compact fraud
proofs, and using that merkle-sum-tree you can easily calculate sum
fees/sum size for the whole block to determine fees.
We know that we can make a good assumption that transactions in
blocks will have been broadcast prior by the assumption you and Gavin
are making that miners would by far prefer to mine transactions that
have already been broadcast so that block propagation via txid lists
works. That advantage is on the order of 10x to 100x (or even higher)
lower cost per KB to the miner. (if this is not true, let us all know,
because then your scalability arguments are bunk with regard to
blocksize)
In addition faking fees via non-disclosed high-fee transactions has a
cost of about 1% due to the risk your block gets orphaned and the tx fee
gets mined by another miner.
Between those two the merkle-sum-trees for fees and size can be used for
various levels of average fee for a whole block, plus statistical
distributions.
Next it is also desirable for another, related, soft-fork to include a
sorted list of txids and/or H(scriptPubKey)'s in a block. (the latter is
explicitly part of my TXO commitments proposal) With the txids version
especially it's easy and low-bandwidth for SPV nodes to get proof that a
given transaction has been mined recently, by asking for proof of
inclusion or exclusion to accompany a bloom filter match.
Finally with various anti-sybil techniques that create long-term
identities it's easy to show that a peer lied about the data required
for fee estimates anyway.
> One obvious concern is what to do if nodes don't converge on very similar
> estimates. Wallets will always want to pay the lowest fee possible, so that
> means they'll always be riding the very edge of what's acceptable, opening
> up tx propagation to random flaky failures if fee estimates change whilst a
> transaction is in progress, or if some nodes don't calculate the same
> estimates as others.
Propagation failures are not a major problem if transactions can be
rebroadcast with new, higher, fees; propagation failures can be detected
easily and quickly with my proof-of-tx-mining proposal.
--
'peter'[:-1]@petertodd.org
000000000000000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
prev parent reply other threads:[~2013-12-03 11:31 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-01 11:51 Mike Hearn
2013-12-01 12:15 ` Andreas Schildbach
2013-12-01 13:41 ` Mike Hearn
2013-12-01 16:50 ` Andreas Schildbach
2013-12-01 17:19 ` Mike Hearn
2013-12-01 17:40 ` Andreas Schildbach
2013-12-01 17:52 ` Mike Hearn
2013-12-01 18:12 ` Peter Todd
2013-12-01 18:18 ` Mike Hearn
2013-12-01 18:37 ` Peter Todd
2013-12-02 13:54 ` Patrick Mead
2013-12-02 14:33 ` Mike Hearn
2013-12-02 14:37 ` Jeff Garzik
2013-12-02 14:44 ` Mike Hearn
2013-12-02 14:47 ` Jeff Garzik
2013-12-03 1:40 ` Gavin Andresen
2013-12-03 10:06 ` Mike Hearn
2013-12-03 10:36 ` Drak
2013-12-03 10:45 ` Mike Hearn
2013-12-03 11:04 ` Drak
2013-12-03 11:07 ` Gavin Andresen
2013-12-03 11:29 ` Mike Hearn
2013-12-03 11:37 ` Peter Todd
2013-12-03 11:41 ` Gavin Andresen
2013-12-03 11:46 ` Mike Hearn
2013-12-03 11:54 ` Gavin Andresen
2013-12-03 12:05 ` Drak
2013-12-03 11:57 ` Taylor Gerring
2013-12-03 12:07 ` Peter Todd
2013-12-03 13:20 ` Jamie McNaught
2013-12-03 13:20 ` Mike Hearn
2013-12-03 13:48 ` Taylor Gerring
2013-12-03 13:54 ` Mike Hearn
2013-12-03 14:42 ` Quinn Harris
2013-12-04 1:45 ` Jeremy Spilman
2013-12-04 10:40 ` Mike Hearn
2013-12-04 10:57 ` Peter Todd
2013-12-04 11:09 ` Mike Hearn
2013-12-04 13:06 ` Peter Todd
2013-12-04 13:48 ` Mike Hearn
2013-12-04 21:51 ` Peter Todd
2013-12-03 11:03 ` Peter Todd
2013-12-03 11:09 ` Drak
2013-12-03 11:33 ` Peter Todd
2013-12-04 5:50 ` kjj
2013-12-03 11:31 ` Peter Todd [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=20131203113117.GA12623@tilt \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/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