From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1SfZEW-00004y-SV for bitcoin-development@lists.sourceforge.net; Fri, 15 Jun 2012 16:18:48 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bluematt.me designates 173.246.101.161 as permitted sender) client-ip=173.246.101.161; envelope-from=bitcoin-list@bluematt.me; helo=mail.bluematt.me; Received: from vps.bluematt.me ([173.246.101.161] helo=mail.bluematt.me) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1SfZET-0005Ql-2F for bitcoin-development@lists.sourceforge.net; Fri, 15 Jun 2012 16:18:48 +0000 Received: from [IPv6:2001:470:9ff2:1:ee55:f9ff:fec6:e666] (unknown [IPv6:2001:470:9ff2:1:ee55:f9ff:fec6:e666]) by mail.bluematt.me (Postfix) with ESMTPSA id AE296398F; Fri, 15 Jun 2012 16:18:38 +0000 (UTC) Message-ID: <1339777116.31489.87.camel@bmthinkpad> From: Matt Corallo To: Mike Hearn Date: Fri, 15 Jun 2012 18:18:36 +0200 In-Reply-To: References: <1339765735.31489.40.camel@bmthinkpad> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.2-1 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Spam-Score: -1.5 (-) 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 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1SfZET-0005Ql-2F 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 16:18:48 -0000 On Fri, 2012-06-15 at 15:34 +0200, Mike Hearn wrote: > > The idea can be more generalized in that there are many cases where the > > generator of a transaction doesn't care about confirmation times, and > > would really be willing to make their transaction lower priority than > > other 0-fee transactions. > > Just to be clear, I think this solution is a hack and don't support it > because it's yet another change of network rules. Some random people > will get whacked because of a heuristic "rule of thumb". Its arguably not a change to network rules as its something that users can already do today by patching their clients. Obviously any implementation would have sane defaults which allowed for a significant number of transactions to/from a given address at a time, avoiding whacking random people unless they are large enough that they should really already be fully aware of how bitcoin works. > > If it's implemented, SD could/would switch to fresh addresses and > nothing would have been achieved except making an already complex > system more complex. I would think SD would switch to using fresh addresses for each bet. But even that is a good thing, at least where user privacy is concerned. However, I would hope that SD would see the rule tweak and, in order to avoid having to generate a number of new addresses per second (or, if they went the pool route, having a huge pool of many thousands of addresses), they would consider implementing sendmulti support. > > I disagree with the notion that you need "less important than free". > If you care about the confirmation time of a transaction that was sent > to you and you need space in a limited resource, you can pay for it. > It's an auction like any other. Besides, the idea that transactions > are free today is just a psychological trick befitting governments but > not us - transactions are funded by aggressive hyperinflation. I would > never describe Bitcoin as a free system and I suggest nobody else does > either. I agree, free transactions isnt something we should aggressively push as a feature of Bitcoin, its simply not. However, in the current system free transactions are usually confirmed within a small number of blocks, and for a number of users, that is an important feature that draws them to get through the initial hurdles of converting money to Bitcoin and understanding enough of the system to trust it. I believe that if we can incentive large transaction creators to avoid delaying free transactions, we should and giving them the option to delay their own transactions seems like a perfectly reasonable way to do so. Even if you drop all the per-address limit stuff, allowing transaction creators to add a simple flag to transactions seems reasonable when they want to encourage Bitcoin to continue to grow as it does today. Obviously keeping free transactions confirming won't be possible forever, but hopefully that will be as a result of natural growth which can encourage further growth without the need for free transactions and not as a result of a few actors in the community creating a transaction volume significantly greater than their user-base. > > If grouped fee calculations are implemented, we can keep the nice > property that the person who cares about double spending risk pays the > fees, and if you assume most transactions are hub-and-spoke from > buyers to merchants, rather than a pure p2p graph, in practice it'll > work out to seeming free most of the time even if seen globally it > doesn't make much difference. ACK, thats an important thing to implement IMO, but I really dont see it as something that replaces the option to deprioritize your own transactions to below 0-fee transactions. It could even allow users who receive payouts which are below 0-fee transactions to place a fee on the subsequent transactions to allow the payouts to confirm quicker (if done right). > > > My point was that the easiest way to do it would be to ship a pruned > > snapshot with Bitcoin, and such a system, while verifiable, would > > increase Bitocin's centralization. > > I'm not sure why. If you want to audit everything from scratch, after > checking the code you could just blow away the included files and then > "-connect=archive.bitcoin.org" or something like that. After > rebuilding the chain from scratch, check the databases for consistency > with the included data. I would be surprised if more than a handful of devs audit such a thing. And I would say that does define an increase in centralization. > > It reduces the number of nodes with full copies of the block chain, > yes, but as long as there's at least one copy of the old data in an > accessible location new nodes can still bootstrap just fine. Sadly, old nodes do not know where to look for such data, and I'm fairly certain people running old nodes don't read the forums enough to catch when it is announced that old nodes should make sure to -connect=archive.bitcoin.org in order to avoid initially having horrible initial bootstrap times and eventually not being able to connect to full-chain-serving nodes at all. > > I'm sure we can find organizations willing to host full chains for > people who want to rebuild their databases from scratch, given how > cheap disk space is. Sadly, disk space isnt the issue. Each connection to bitcoind (not that it cant be fixed, but currently) eats a nice chunk of memory. An organization that wants to provide nodes for old nodes to connect to would need to have a significant number of open incoming connection slots, have plenty of bandwidth for nodes that are in IBD and have plenty of memory and CPU to manage all the connections. > > > connect to, possibly complicating using Bitcoin for clients that either > > wish to run a full IBD or older clients which need a non-fClient node > > Yes, but old nodes probably have a copy of the chain already, so it > wouldn't affect them. New blocks would still be fully distributed, > right? Sadly, BDB's infamous database corrupted messages appear all too often, and the usual response is "delete the chain and resync." I have a hard time believing that old nodes will rarely be in IBD. > > The only case where it'd cause issues is if you install a fresh copy > of a very old node. Not a common occurrence, and those nodes will have > to wait until they find an archival node announcing itself. Those > nodes could be made to announce more frequently than normal, if need > be. I agree that its very possible to have archival nodes available and to make it work, but I have yet to see anyone doing any work to actually get commitments to run archival nodes and I have yet to see any discussion of what, exactly, that would entail. Matt