Re: [Bitcoin-development] Floating fees and SPV clients

[Peter Todd <pete@petertodd.org>]

[-- 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 --]