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 1Sfnra-0007CV-Ra for bitcoin-development@lists.sourceforge.net; Sat, 16 Jun 2012 07:56:06 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.181 as permitted sender) client-ip=209.85.212.181; envelope-from=mh.in.england@gmail.com; helo=mail-wi0-f181.google.com; Received: from mail-wi0-f181.google.com ([209.85.212.181]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Sfnra-0000ZT-4E for bitcoin-development@lists.sourceforge.net; Sat, 16 Jun 2012 07:56:06 +0000 Received: by wibhn14 with SMTP id hn14so178228wib.10 for ; Sat, 16 Jun 2012 00:56:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.8.69 with SMTP id p5mr9917625wia.17.1339833355406; Sat, 16 Jun 2012 00:55:55 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.216.254.232 with HTTP; Sat, 16 Jun 2012 00:55:55 -0700 (PDT) In-Reply-To: References: Date: Sat, 16 Jun 2012 09:55:55 +0200 X-Google-Sender-Auth: grbDIn7wI9ZEQRqMTniVcadRG7E Message-ID: From: Mike Hearn To: Gavin Andresen Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.4 (-) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 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 0.1 AWL AWL: From: address is in the auto white-list X-Headers-End: 1Sfnra-0000ZT-4E 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: Sat, 16 Jun 2012 07:56:06 -0000 [resend, sorry gavin] I think these ideas all make a ton of sense, some have been floating around for a while in various forms but it's good to draw them together coherently. > 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). Is more incentive needed? If you have tons of tiny outputs you already have incentives to merge them because otherwise your txns will become large and the fees needed to overcome the DoS limits and gain priority will rise. The code to do it is a bit irritating as you really want to de-frag wallets in the background when the user is not likely to need the outputs quickly, and I suspect over time transaction volumes will become diurnal so it'd be cheaper to do that at night time, but it's all possible. > But that won't work for newly started clients that haven't seen a lot > of transactions enter/exit the memory pool Peers could provide first-seen timestamps for transactions when announced or when downloaded with Jeffs proposed command, but the timestamps are not necessarily trustable. Not sure if that'd open up new attacks. > or SPV clients that can't lookup transaction inputs SPV clients can do it by getdata-ing on the relevant inputs, but it's very bandwidth intensive just to guesstimate fees. > Maybe each client developer runs a "fee policy server" That's reasonable. I don't believe this case is worth worrying about right now. For the common cases of a) Customer buys from merchant (runs full node) b) Trusted person sends money to trusting person (does not need confirms) it wouldn't matter after the changes to the block creation code. It's only really an issue when a user running an SPV client wishes to accept money from somebody they do not trust, and they want it to confirm quick-ish (within an hour), but can tolerate delays up to that. I think this is likely to be rare. Much more common is that you want to accept the payment immediately, which is an oft discussed but different problem.