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 1SfWfX-0007gp-Vq for bitcoin-development@lists.sourceforge.net; Fri, 15 Jun 2012 13:34:32 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.175 as permitted sender) client-ip=74.125.82.175; envelope-from=mh.in.england@gmail.com; helo=mail-we0-f175.google.com; Received: from mail-we0-f175.google.com ([74.125.82.175]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1SfWfS-0008RE-03 for bitcoin-development@lists.sourceforge.net; Fri, 15 Jun 2012 13:34:31 +0000 Received: by werg55 with SMTP id g55so2339459wer.34 for ; Fri, 15 Jun 2012 06:34:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.14.193 with SMTP id r1mr4643149wic.13.1339767259786; Fri, 15 Jun 2012 06:34:19 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.216.254.232 with HTTP; Fri, 15 Jun 2012 06:34:19 -0700 (PDT) In-Reply-To: <1339765735.31489.40.camel@bmthinkpad> References: <1339765735.31489.40.camel@bmthinkpad> Date: Fri, 15 Jun 2012 15:34:19 +0200 X-Google-Sender-Auth: eIXhlMSHuCujem0AU8By_OS_kDM Message-ID: From: Mike Hearn To: Matt Corallo Content-Type: text/plain; charset=UTF-8 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 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 X-Headers-End: 1SfWfS-0008RE-03 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 13:34:32 -0000 > 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". 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 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. 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. > 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. 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. 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. > 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? 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.