From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4687140A for ; Sat, 18 Jul 2015 19:46:04 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9D7BD153 for ; Sat, 18 Jul 2015 19:46:03 +0000 (UTC) Received: by pdrg1 with SMTP id g1so79588158pdr.2 for ; Sat, 18 Jul 2015 12:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type; bh=aHtL8jepvW+HZ+lcUV8OLA32EhpvxplihCCz7mkn5JQ=; b=OT3fpLij0Q0nNBQF+v4NXKyehX9YQbTsWnKEn9R3B6opb/Yd1GrJAAF/XjhQ6nJHqM obv4Ui5QflBdy7RlEyY1epSTfSWd/0Tdo9FpLO8Qhkj2+V0UUFDFl1iCMydxsBJjo7AT Kj/P788iws0ZvnRaG4/Ut7LQpvwdM5LRvxmZbPlIwSZt1Aedn47LERtDFfCDePd1z1Bh Suj1ET1mMN/xs6lTXO3/zmJ3ZT2fPB6CP1QA68o+oemnZ4zv2cyKC6NQR9Y5l0K5iYt8 wVeqXhUH5r/wx+8UGpedaD3TY87JaAC7KmGJ4quUSvnHsCqEVwy+9V1nov0F+vOc9PNE 5/2Q== X-Received: by 10.68.206.68 with SMTP id lm4mr42400695pbc.147.1437248763362; Sat, 18 Jul 2015 12:46:03 -0700 (PDT) Received: from [192.168.43.241] ([166.170.42.137]) by smtp.googlemail.com with ESMTPSA id pq3sm15086896pbb.24.2015.07.18.12.46.01 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Jul 2015 12:46:02 -0700 (PDT) Message-ID: <55AAACF9.90007@gmail.com> Date: Sat, 18 Jul 2015 12:46:01 -0700 From: Patrick Strateman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: bitcoin-dev@lists.linuxfoundation.org References: <20150718185259.GA3477@muck> In-Reply-To: <20150718185259.GA3477@muck> Content-Type: multipart/alternative; boundary="------------030202040003040402040300" X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Do we really need a mempool? (for relay nodes) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 19:46:04 -0000 This is a multi-part message in MIME format. --------------030202040003040402040300 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Relay nodes do not need a mempool, but do need some mechanism to avoid DoS issues. Wallet nodes can use the mempool for fee estimation (in addition to looking at past blocks). On 07/18/2015 11:52 AM, Peter Todd via bitcoin-dev wrote: > As in, do relay nodes need to keep a record of the transactions they've > relayed? Strictly speaking, the answer is no: one a tx is relayed modulo > DoS concerns the entire thing can be discarded by the node. (unconfirmed > txs spending other unconfirmed txs can be handled by creating packages > of transactions, evaluated as a whole) > > To mitigate DoS concerns, we of course have to have some per-UTXO limit > on bandwidth relayed, but that task can be accomplished by simply > maintaining some kind of per-UTXO record of bandwidth used. For instance > if the weighted fee and fee/KB were recorded, and forced to - say - > double for each additional tx relayed that spent a given UTXO you would > have a clear and simple upper limit of lifetime bandwidth. Equally it's > easy to limit bandwidth moment to moment by asking peers for highest > fee/KB transactions they advertise first, stopping when our bandwidth > limit is reached. > > You probably could even remove IsStandard() pretty much entirely with > the right increasingly expensive "replacement" policy, relying on it > alone to provide anti-DoS. Obviously this would simplify some of the > debates around mining policy! This could even be re-used for scalable a > general-purpose messaging network paid by coin ownership if the UTXO set > is split up, and some kind of expiration over time policy is > implemented. > > Miners of course would still want to have a mempool, but that codebase > may prove simpler if it doesn't have to work double-duty for relaying as > well. > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --------------030202040003040402040300 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Relay nodes do not need a mempool, but do need some mechanism to avoid DoS issues.

Wallet nodes can use the mempool for fee estimation (in addition to looking at past blocks).

On 07/18/2015 11:52 AM, Peter Todd via bitcoin-dev wrote:
As in, do relay nodes need to keep a record of the transactions they've
relayed? Strictly speaking, the answer is no: one a tx is relayed modulo
DoS concerns the entire thing can be discarded by the node. (unconfirmed
txs spending other unconfirmed txs can be handled by creating packages
of transactions, evaluated as a whole)

To mitigate DoS concerns, we of course have to have some per-UTXO limit
on bandwidth relayed, but that task can be accomplished by simply
maintaining some kind of per-UTXO record of bandwidth used. For instance
if the weighted fee and fee/KB were recorded, and forced to - say -
double for each additional tx relayed that spent a given UTXO you would
have a clear and simple upper limit of lifetime bandwidth. Equally it's
easy to limit bandwidth moment to moment by asking peers for highest
fee/KB transactions they advertise first, stopping when our bandwidth
limit is reached.

You probably could even remove IsStandard() pretty much entirely with
the right increasingly expensive "replacement" policy, relying on it
alone to provide anti-DoS. Obviously this would simplify some of the
debates around mining policy! This could even be re-used for scalable a
general-purpose messaging network paid by coin ownership if the UTXO set
is split up, and some kind of expiration over time policy is
implemented.

Miners of course would still want to have a mempool, but that codebase
may prove simpler if it doesn't have to work double-duty for relaying as
well.




_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--------------030202040003040402040300--