diff options
| author | Matt Corallo <bitcoin-list@bluematt.me> | 2012-06-15 18:18:36 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2012-06-15 16:18:48 +0000 |
| commit | e8e7012b030bccd88ac0281086add2714a8dd21e (patch) | |
| tree | e4acc7a75372cf4e565988f5946660981335d794 | |
| parent | 92f226d6215fcf8b12f9af4b60bd59169fa4f00d (diff) | |
| download | pi-bitcoindev-e8e7012b030bccd88ac0281086add2714a8dd21e.tar.gz pi-bitcoindev-e8e7012b030bccd88ac0281086add2714a8dd21e.zip | |
Re: [Bitcoin-development] Near-term scalability
| -rw-r--r-- | e9/4433533cd9e6b7dedaad153c183b1b3c4fca38 | 177 |
1 files changed, 177 insertions, 0 deletions
diff --git a/e9/4433533cd9e6b7dedaad153c183b1b3c4fca38 b/e9/4433533cd9e6b7dedaad153c183b1b3c4fca38 new file mode 100644 index 000000000..7477876bc --- /dev/null +++ b/e9/4433533cd9e6b7dedaad153c183b1b3c4fca38 @@ -0,0 +1,177 @@ +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 <bitcoin-list@bluematt.me>) 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 <bitcoin-list@bluematt.me> +To: Mike Hearn <mike@plan99.net> +Date: Fri, 15 Jun 2012 18:18:36 +0200 +In-Reply-To: <CANEZrP2rZEwQqkceTN3yOqx_Mo_8gyRyBUgv8NnfKd8ZWGYzww@mail.gmail.com> +References: <CANEZrP3w+AiTXmv9Wb3Zi5yyFmGPk82-ysVo4_DVvtg8HHBCdQ@mail.gmail.com> + <1339765735.31489.40.camel@bmthinkpad> + <CANEZrP2rZEwQqkceTN3yOqx_Mo_8gyRyBUgv8NnfKd8ZWGYzww@mail.gmail.com> +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 <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Near-term scalability +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 + + + + |