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
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
