diff options
| author | odinn <odinn.cyberguerrilla@riseup.net> | 2015-07-19 01:59:49 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-07-19 08:59:52 +0000 |
| commit | b859eff2c8f02b92478b3ef9cb9ee5dcfb02604a (patch) | |
| tree | f1319b2a6256c8d4f02133c03a5456b84549bd22 | |
| parent | a6383127c836618fd8d1b76a877c751fbbf75858 (diff) | |
| download | pi-bitcoindev-b859eff2c8f02b92478b3ef9cb9ee5dcfb02604a.tar.gz pi-bitcoindev-b859eff2c8f02b92478b3ef9cb9ee5dcfb02604a.zip | |
Re: [bitcoin-dev] Do we really need a mempool? (for relay nodes)
| -rw-r--r-- | 6c/fcd38581012e597de8070d25e7b86cf6e09ae4 | 169 |
1 files changed, 169 insertions, 0 deletions
diff --git a/6c/fcd38581012e597de8070d25e7b86cf6e09ae4 b/6c/fcd38581012e597de8070d25e7b86cf6e09ae4 new file mode 100644 index 000000000..0d883cd10 --- /dev/null +++ b/6c/fcd38581012e597de8070d25e7b86cf6e09ae4 @@ -0,0 +1,169 @@ +Return-Path: <odinn.cyberguerrilla@riseup.net> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 06AD7409 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 19 Jul 2015 08:59:52 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 068FD190 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 19 Jul 2015 08:59:50 +0000 (UTC) +Received: from plantcutter.riseup.net (plantcutter-pn.riseup.net [10.0.1.121]) + (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) + (Client CN "*.riseup.net", + Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) + by mx1.riseup.net (Postfix) with ESMTPS id 79B23420BA + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 19 Jul 2015 08:59:50 +0000 (UTC) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; + t=1437296390; bh=5H3EsVtmiW4/Q3O/NwaimQN98qWercL6mIpowHcgG4g=; + h=Date:From:To:Subject:References:In-Reply-To:From; + b=Duhe/YowZhEdi/frBqOaDG1lVXWQkGuNdFan7S8fEgFYsXcuaKRYPkSHmgM0BXbwT + fehz5spD3eSzHy1nQgG1gmBoAgxA6YjC46RW3EqyIUJNxcGlBuySQXn2isS1So9vkw + 9Xf0PtFraLBRIlUvuJR1+sLOjhajoKa1lxu/oMeQ= +Received: from [127.0.0.1] (localhost [127.0.0.1]) + (Authenticated sender: odinn.cyberguerrilla) + with ESMTPSA id 334C71FC52 +Message-ID: <55AB6705.7080701@riseup.net> +Date: Sun, 19 Jul 2015 01:59:49 -0700 +From: odinn <odinn.cyberguerrilla@riseup.net> +User-Agent: Mozilla/5.0 (X11; Linux x86_64; + rv:31.0) Gecko/20100101 Thunderbird/31.7.0 +MIME-Version: 1.0 +To: bitcoin-dev@lists.linuxfoundation.org +References: <20150718185259.GA3477@muck> <55AAACF9.90007@gmail.com> +In-Reply-To: <55AAACF9.90007@gmail.com> +Content-Type: text/plain; charset=windows-1252 +Content-Transfer-Encoding: 8bit +X-Virus-Scanned: clamav-milter 0.98.7 at mx1 +X-Virus-Status: Clean +X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD, + UNPARSEABLE_RELAY 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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Sun, 19 Jul 2015 08:59:52 -0000 + +-----BEGIN PGP SIGNED MESSAGE----- +Hash: SHA1 + +Some brief thoughts, adding here a suggestion for a dynamic approach +to the issue. (e.g. each additional tx relayed has some thing +associated with it, that is, a "doubling" for each additional tx +relayed that spends a given UTXO, doesn't sound like it would be the +most dynamic approach to the issue; considering that full nodes use +the (UTXOs) to establish if transactions are valid � all inputs to a +transaction must be in the UTXO database for it to be valid, but +rather, would end up ratcheting upward the fee/kB for each additional +tx relayed, as proposed). + +A more dynamic fee approach would be a better one, imho, but how is +this to occur? + +Quoting from Gavin Andresen's http://gavinandresen.ninja/utxo-uhoh, +"The entire UTXO set doesn�t have to be in RAM; it can be stored on an +SSD or spinning hard disk. The access pattern to the UTXO is not +random; outputs that were spent recently are more likely to be +re-spent than outputs that have not been spent in a long time. Bitcoin +Core already has a multi-level UTXO cache, thanks to the hard work of +Pieter Wuille." + +The relay nodes would, in this scenario that is proposed here in this +message, be confirming and discarding; the wallet nodes, if I +understand properly, in this scenario, as proposed, should be +retaining (keeping a record of the transactions they've relayed and +using a mempool). + +There are some questions here: + +- - How is the mempool to be limited? +- - What is the mechanism by which the UTXO set is stored (or proposed +to be stored)? +- - How would dynamic fee determinations be calculated? +- - Please describe more the general purpose messaging network? + +Thank you + + + +On 07/18/2015 12:46 PM, Patrick Strateman via bitcoin-dev wrote: +> 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 +> +> +> +> _______________________________________________ bitcoin-dev mailing +> list bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +- -- +http://abis.io ~ +"a protocol concept to enable decentralization +and expansion of a giving economy, and a new social good" +https://keybase.io/odinn +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1 + +iQEcBAEBAgAGBQJVq2cFAAoJEGxwq/inSG8CIo4IAJAZ97NvW6Qdjd6HLN8q2074 +sEUGdDeonARiQZXLfGyTJVg43Yb6LKPqkjWPQEgl9LLNni8t99iUqu3BJxedRDjd +8x+/F8n5VJrUrn1pXUcbC1aWss1y8JPTO2KpF/WL254IFc8iE8MJf4YF8PDSgy5j +9uW8NvWvdT4dz+rXu9vqfcplz8x7NGQ+CWN2N2JlChhKLMFprXPIx8a7NQwaKdrY +lTpgAJWGMyPGNCmYQprBjIjOfp8tdTLQFlsLUAsXDmEisJX9goRVGMsHOWLTREoA +l3kTgM0WMv6MIG7NOQQcWLD7cZdwWYR9e49hc27VcHt2R/FTepvnwPqo2GtE0tM= +=eRbR +-----END PGP SIGNATURE----- + |