From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1X8CHT-0001BS-7a for bitcoin-development@lists.sourceforge.net; Fri, 18 Jul 2014 17:49:15 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of bitpay.com designates 74.125.82.179 as permitted sender) client-ip=74.125.82.179; envelope-from=jgarzik@bitpay.com; helo=mail-we0-f179.google.com; Received: from mail-we0-f179.google.com ([74.125.82.179]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1X8CHR-0003Gi-UB for bitcoin-development@lists.sourceforge.net; Fri, 18 Jul 2014 17:49:15 +0000 Received: by mail-we0-f179.google.com with SMTP id u57so4853774wes.24 for ; Fri, 18 Jul 2014 10:49:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=77SB2EMujes1LPjOA3vtCyPge/1+jfYN3cyjtylaxa0=; b=Wv08qTXfznww7qQ5jZYp8jU4w3ioLGMtzOuE/WoM/KX2GoLTZmXufyQ1qv3tE/3RpH pzv2A0f/58xWBi1P82XfQxiOryOE11+6ZPXjBWKwm/Hw6GPUtA+4AGmdbxiOEw3sR1/m mCUsuokHRRPOl52XAqp1H4ov5MBFBZIut1QCSxfG5dtAXDuHMqDyyar8EyNCCr/oK251 agEnz5wBA0xXwGlUe7IMen7yoMYJi6R9DdXHbzHWu+xJ3Gi/RaR0mrRNBJ436OvgtRFm 92mnEn29KrV7jQywRWMxapwYNTjcNTAGO6tnOhSXs/XPlWCIZTlDpc4BFJV5NH9RfbgP Csrg== X-Gm-Message-State: ALoCoQkuT6ZMU/cGjHvZxgr5puYFHejqqh06Fv7zDlNaenLGMezaYVako9riBOFr/y+XTD7VB/14 X-Received: by 10.194.172.167 with SMTP id bd7mr9298841wjc.74.1405705747233; Fri, 18 Jul 2014 10:49:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.5.67 with HTTP; Fri, 18 Jul 2014 10:48:47 -0700 (PDT) In-Reply-To: References: From: Jeff Garzik Date: Fri, 18 Jul 2014 13:48:47 -0400 Message-ID: To: Kaz Wesley Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1X8CHR-0003Gi-UB Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Squashing redundant tx data in blocks on the wire X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 17:49:15 -0000 On a flood-fill network, you don't want to create a storm of "I already have this" replies. On Fri, Jul 18, 2014 at 1:39 PM, Kaz Wesley wrote: > Peers exchanging mempool priority policies is great; that accomplishes > the flexibility in what txes to remember that I was going for with the > forget-filters, but much more neatly, with less overhead and some side > benefits. > > Here's what I'm picturing now: > - exchange priority policies in peer introductions > - assign unique sequential IDs in the order the transactions were > inved (per peer) > - receiving a getdata for a tx updates last-known-peer-received inv to > all invs up to the one referenced > - include ID-last-received, last-known-peer-received in sparse block > - reference txes in sparse block by index in receiver's > prioritiziation with peer's sent invs up to ID-last-received and > sender's prior invs up to last-known-peer-received > > Possible new messages: > - sparseblock > - invack message a node can send at times when it's received a bunch > of invs it already has, so it hasn't acked with a getdata in a while > - gettx: getdata, but using new sequential ID to save 28 bytes per tx > > It seems important for ordering policies to be able to be specified in > as much detail as possible. Parameters that should be available: > - total inputs > - total outputs > - bytes > - coin days destroyed > - net UTXO size change > - sigops > - is data carrier > - is output raw multisig > - age in mempool > - what else? > This parameter set should be extensible to allow for unforeseen future factors. > > Ordering policies should allow arbitrary algebraic combinations of > their parameters, as well as thresholds. Boolean combinations of > sub-policies would also be desirable. This could be implemented with a > tx-script-like stack-based language, in which each supported tx > property is pushed onto the stack by a particular opcode, and > +-*//min/max/boolean operators combine them to yield the sort key. > > Difficult parameters: > * Coin-days-destroyed: changes, peers need agreement on when (if?) > it's recalculated. Probably can just not recalculate, but peers still > need agreement on "time seen" to get CDD. > * Age in mempool: seems intractable in terms of time, but could be > done easily in terms of "how many txes old is this sequential ID" > > One potential pitfall: this allows for an environment of completely > heterogeneous mempool policies. I think that's a good thing, but we > need to avoid a situation where only least-common-denominator > transactions make it farther than a hop or two, and we don't want > nodes to have a strong preference for connecting to like-minded peers > since clustering reduces overall connectivity. It may be worthwhile to > add a parallel mechanism for relay policies, to differentiate between > what a node would keep in its mempool vs. what it wouldn't even relay > and doesn't want to see at all. Relay policies could be specified just > like prioritization policies, but with the final stack value evaluated > in a boolean context. > > An interesting additional use of policy-scripts would be a > standardized way for miners to include a policy script in a coinbase, > allowing miners a mechanism to advertise things like their relative > price of sigops vs bytes. Nodes may then choose to take this > information into account in order to optimize their mempool policies > for likelihood of consistency with future blocks. Since policy scripts > provide only relative information on prices of different transaction > properties rather than an absolute fee, this should not allow miners > to "vote fees up", although care would need to be taken they wouldn't > be able to drive up prices by claiming common transaction types are at > the high end of the fee scale. > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/