From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1SfdZI-0005UF-Bp for bitcoin-development@lists.sourceforge.net; Fri, 15 Jun 2012 20:56:32 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.83.47 as permitted sender) client-ip=74.125.83.47; envelope-from=gavinandresen@gmail.com; helo=mail-ee0-f47.google.com; Received: from mail-ee0-f47.google.com ([74.125.83.47]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1SfdZH-0001Tk-JZ for bitcoin-development@lists.sourceforge.net; Fri, 15 Jun 2012 20:56:32 +0000 Received: by eekd49 with SMTP id d49so1099019eek.34 for ; Fri, 15 Jun 2012 13:56:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.22.69 with SMTP id s45mr1679525ees.186.1339793785331; Fri, 15 Jun 2012 13:56:25 -0700 (PDT) Received: by 10.14.3.66 with HTTP; Fri, 15 Jun 2012 13:56:25 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 Jun 2012 16:56:25 -0400 Message-ID: From: Gavin Andresen To: Mike Hearn Content-Type: text/plain; charset=ISO-8859-1 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gavinandresen[at]gmail.com) -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: 1SfdZH-0001Tk-JZ Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Near-term scalability 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, 15 Jun 2012 20:56:32 -0000 > (1) Change the mining code to group transactions together with their > mempool dependencies and then calculate all fees as a group. I think there is general consensus this is a good idea. > (2) SatoshiDice should use the same fee algorithms as Bitcoin-Qt to > avoid paying excessive fees and queue-jumping. Guess that's on my > plate. I don't think the problem is with SatoshiDice, but is with the current fixed/inflexible fee rules: ---------------------------- I've been thinking about fees a lot the last couple of days, and I'm close to making a formal proposal. Here are my thoughts so far: It seems to me there are two typical use cases: Case 1: I want my transaction to be confirmed quickly, and am willing to pay a fee to make that happen. Case 2: I want my transaction to be confirmed eventually. I'd rather not pay, unless I have to. I don't think the current code handles those two cases as well as it could; here's a proposal to fix that: o Let miners decide on how many free transactions they'll support, by letting them specify how much of each block to set aside for 'free' transactions (bytes) and what the threshold for 'free' is (bitcoins/kilobyte). I think a new RPC call to get/set the parameters dynamically is the right way to go. o Change the block creation code to calculate a bitcoin-fee-per-kilobyte for each transaction, where the fee and size are both calculated based on the transaction and it's dependent descendants (so we get the receiver-can-opt-to-pay-the-fee behavior we want). Order transactions so highest-paying get into the non-free space first. o Fill up the "free" space (if any) with the highest-priority transactions, where priority is a function of transaction size, age of inputs, number of bitcoins... and ratio of inputs to outputs (to encourage combining inputs so more pruning is possible). The fee-paying space in a block lets Use Case #1 users compete to make their fees high enough to get into the block. The free space should let non-spamming Use Case #2 users (who don't send a lot of transactions, and so have well-aged, high-priority inputs) send transactions for free, at least as long as there are miners willing to accept free transactions. The question is: how do clients suggest fees to users if miners might have very different fee policies? I think full, transaction-verifying clients can watch how long transactions stay in the memory pool to figure it out. I'm gathering statistics right now to test a couple of simple heuristic algorithms for reasonable fee/priority policies. But that won't work for newly started clients that haven't seen a lot of transactions enter/exit the memory pool, or SPV clients that can't lookup transaction inputs (so can't calculate what fees are being paid -- and once we have bloom filters may not be paying attention anything but their own transactions, anyway). I'm still thinking about that. Maybe a new p2p network command: you give me a list of block hashes, I tell you average fees paid per kilobyte for fee-paying transactions in those blocks, and minimum and average priority of free transactions in those blocks. Maybe the big mining pools all publish their fee policies and that information somehow gets to clients (encoded in the coinbase? ... but they have a strong incentive to lie to try put upward pressure on fees... ). Maybe each client developer runs a "fee policy server" and clients periodically ask it for reasonable fee rules (HTTP fetch info from a web page that is updated as often or infrequently as is convenient, maybe). I think I like this solution the best, it should let clients compete to have the smartest/bestest algorithms for saving their user's money on transaction fees. -- -- Gavin Andresen