Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
I've been following the discussion of the block size limit and IMO it is clear that any constant block size limit is, as many have said before, just kicking the can down the road. My problem with the dynamic lower limit solution based on past blocks is that it doesn't account for usage spikes. I would like to propose another dynamic lower limit scheme: Let the block size limit be a function of the number of current transactions in the mempool. This way, bitcoin usage regulates the block size limit. I'm sorry i don't have the knowledge of the code base or time to make simulations on this kind of approach, but nevertheless I would like to leave it here for discussion or foster other ideas. cheers -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
He also said that the equation for miners has many variables, as it should. There is no disadvantage if the network speed is the same between the miners. If there is a difference in network speed, the miner is incentivized to invest in their network infrastructure. 2015-05-31 23:55 GMT+01:00 Alex Mizrahi alex.mizr...@gmail.com: Yes, if you are on a slow network then you are at a (slight) disadvantage. So? Chun mentioned that his pool is on a slow network, and thus bigger blocks give it an disadvantage. (Orphan rate is proportional to block size.) You said that no, on contrary those who make big blocks have a disadvantage. And now you say that yes, this disadvantage exist. Did you just lie to Chun? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-06-01 0:40 GMT+01:00 Pindar Wong pindar.w...@gmail.com: On Mon, Jun 1, 2015 at 7:23 AM, Ricardo Filipe ricardojdfil...@gmail.com wrote: He also said that the equation for miners has many variables, as it should. There is no disadvantage if the network speed is the same between the miners. Hi, Is that an assumption? no, let me rephrase: The disadvantage alex refers to only exists if miners do not have the same network speed. If there is a difference in network speed, the miner is incentivized to invest in their network infrastructure. Perhaps it's best not to assume that investing in Internet network infrastructure's a free or open market everywhere. Just like easy ASIC access, low price electricity, etc are not a free and open market. p. 2015-05-31 23:55 GMT+01:00 Alex Mizrahi alex.mizr...@gmail.com: Yes, if you are on a slow network then you are at a (slight) disadvantage. So? Chun mentioned that his pool is on a slow network, and thus bigger blocks give it an disadvantage. (Orphan rate is proportional to block size.) You said that no, on contrary those who make big blocks have a disadvantage. And now you say that yes, this disadvantage exist. Did you just lie to Chun? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Electrum 2.0 has been tagged
i guess you look at the glass half full :) even though what you say is true, we should aim for wallets not to require those instructions, by standardizing these things in BIPs. let's hope bitcoin doesn't fail in standards as our industries have in the past... 2015-03-11 19:04 GMT+00:00 Jim jim...@fastmail.co.uk: The wallet words system isn't perfect for sure but it does help the user in two main ways: 1) Assuming wallet devs ensure forward compatibility for _their_ wallet the user knows they can recover their bitcoins using the same wallet software in case of a Bad Thing Happening. 2) To an imperfect degree, they can transfer/ recover their bitcoins that are stored in Wallet X into Wallet Y. We need to give them guidance on how to do this. I think it is up to each wallet team to explain to their users clearly how they can do this in their help. It's only good manners to show your guests where the fire exits are. It can be a simple help page saying: If you want to transfer your bitcoin out of MultiBit HD to Lighthouse, do this, this and this. If you want to use the Trezor wallet you created in MultiBit HD on myTrezor.com, do this, this and this. That way users have clear instructions on how to recover their bitcoins. Users don't care about BIP this or BIP that but they REALLY DO CARE about keeping their bitcoins. -- http://bitcoin-solutions.co.uk On Wed, Mar 11, 2015, at 05:14 PM, Mike Hearn wrote: Sigh. The wallet words system is turning into kind of a mess. I thought the word list is in fact not a fixed part of the spec, because the entropy is a hash of the words. But perhaps I'm misunderstanding something. The main problem regular SPV wallets have with BIP39 is that there is no birth time included in the data. Therefore we must ask users to write down a timestamp as well, so we know where to start rescanning the chain. It sounds like the Electrum version doesn't fix this, so now we have at least FIVE incompatible results from a 12 word list: - Electrum v2 with a version number but no date - myTREZOR with no version and no date and BIP44 key derivation. Some seeds I believe are now being generated with 24 words instead of 12. - MultiBit HD with no version and a date in a custom form that creates non-date-like codes you are expected to write down. I think BIP32 and BIP44 are both supported (sorta). - GreenAddress with no version, no date and BIP32 - Other bitcoinj based wallets, with no version and a date written down in normal human form, BIP32 only. I really hope we can recover from this somehow because otherwise all wallets will have to provide the user with a complicated matrix of possibilities and software combinations, and in practice many won't bother so these word combinations will actually end up being wallet specific for no particularly good reason, just very minor details like the presence or absence of single fields. It feels like we somehow fell flat on our faces just before the finishing line. This is deeply unfortunate. Compatibility and UX consistency is important! Currently, I don't have any bright ideas for how to get everyone back onto the same page with a fully compatible system that is acceptable to all. If anyone else has suggestions, I'm all ears. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and
Re: [Bitcoin-development] New paper: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies
As a researcher in a distributed systems group, it is awesome to see these papers flocking up that help convince the supervisors to pay more attention to blockchain technologies. thanks for keeping us up to speed. 2015-03-02 16:48 GMT+00:00 Andrew Miller amil...@cs.umd.edu: We (Joseph Bonneau, myself Arvind Narayanan, Jeremy Clark, Ed Felten, Josh Kroll -- from Stanford, Maryland, Concordia, Princeton) have written a “systemization” paper about Bitcoin-related research. It’s going to appear in the Oakland security conference later this year (IEEE Security and Privacy) but we wanted to announce a draft to this community ahead of time. http://www.jbonneau.com/doc/BMCNKF15-IEEESP-bitcoin.pdf One of the main goals of our work is to build a bridge between the computer science research community and the cryptocurrency community. Many of the most interesting ideas and proposals for Bitcoin come from this mailing list and forums/wikis/irc channels, where many academic researchers simply don’t know to look! In fact, we started out by scraping all the interesting posts/articles we could find and trying to figure out how we could organize them. We hope our paper helps some of the best ideas and research questions from the Bitcoin community bubble up and inspires researchers to build on them. We didn’t limit our scope to Bitcoin, but we also decided not to provide a complete survey of altcoins and other next-generation cryptocurrency designs. Instead, we tried to explain all the dimensions along which these designs differ from Bitcoin. This effort has roughly been in progress over two years, though it stopped and restarted several times along the way. If anyone has comments or suggestions, we still have a week before the final version is due, and regardless we plan to continue updating our online version for the forseeable future. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Ricardo Filipe GSD/INESC-ID Lisboa -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Chain pruning
anyway, any kind of compression that comes to the blockchain is orthogonal to pruning. I agree that you will probably want some kind of replication on more recent nodes than on older ones. However, nodes with older blocks don't need to be static, get the block distribution algorithm to sort it out. 2014-04-10 17:28 GMT+01:00 Mike Hearn m...@plan99.net: Suggestions always welcome! The main problem with this is that the block chain is mostly random bytes (hashes, keys) so it doesn't compress that well. It compresses a bit, but not enough to change the fundamental physics. However, that does not mean the entire chain has to be stored on expensive rotating platters. I've suggested that in some star trek future where the chain really is gigantic, it could be stored on tape and spooled off at high speed. Literally a direct DMA from tape drive to NIC. But we're not there yet :) -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Chain pruning
that's what blockchain pruning is all about :) 2014-04-10 17:47 GMT+01:00 Brian Hoffman brianchoff...@gmail.com: Looks like only about ~30% disk space savings so I see your point. Is there a critical reason why blocks couldn't be formed into superblocks that are chained together and nodes could serve a specific superblock, which could be pieced together from different nodes to get the full blockchain? This would allow participants with limited resources to serve full portions of the blockchain rather than limited pieces of the entire blockchain. On Thu, Apr 10, 2014 at 12:28 PM, Mike Hearn m...@plan99.net wrote: Suggestions always welcome! The main problem with this is that the block chain is mostly random bytes (hashes, keys) so it doesn't compress that well. It compresses a bit, but not enough to change the fundamental physics. However, that does not mean the entire chain has to be stored on expensive rotating platters. I've suggested that in some star trek future where the chain really is gigantic, it could be stored on tape and spooled off at high speed. Literally a direct DMA from tape drive to NIC. But we're not there yet :) -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why are we bleeding nodes?
Or have blocks distributed through pruned nodes as a DHT. 2014-04-07 20:13 GMT+01:00 Mark Friedenbach m...@monetize.io: On 04/07/2014 12:20 PM, Tamas Blummer wrote: Validation has to be sequantial, but that step can be deferred until the blocks before a point are loaded and continous. And how do you find those blocks? I have a suggestion: have nodes advertise which range of full blocks they possess, then you can perform synchronization from the adversed ranges! -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address
2014-04-07 21:08 GMT+01:00 Troy Benjegerdes ho...@hozed.org: I have to play dissenter here again.. Using a bitcoin address as a persistent identity key is the first real-world use of Bitcoin that I can imagine will make it a 'killer app' that everyone and their grandma will want to use. I am of the same opinion, although i understand Gavin's point. Would the multisig seed work for this purpose? I have been toying with this idea and I think that for this BIP to make sense it would require a root key as your login. Then if you need to make transfers the system would request you to create and associate a new key to your account for each purchase (signing the new key with the root one for example). -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Okay, time to bring up bitcoin/bitcoin
Kevin, the thing is you gave us a bad link... what is the correct URL of your project? 2014-04-02 16:30 GMT+01:00 Kevin kevinsisco61...@gmail.com: On 4/2/2014 11:13 AM, Laszlo Hanyecz wrote: Maybe this site serves up exploits selectively? I'm guessing most people are getting the 'domain for sale' but whoever is the target probably gets something special? On Apr 2, 2014, at 2:53 PM, Kevin kevinsisco61...@gmail.com wrote: On 4/2/2014 9:08 AM, Jeff Garzik wrote: At first, this is a poor choice of URL. But it really looks like a phishing attempt that no one should visit. On Tue, Apr 1, 2014 at 4:00 PM, Kevin kevinsisco61...@gmail.com wrote: I've sat on this for some time after starting this. I have forked this from bitcoin core and am working on a secure tax mode for bitcoin. It is written in Autoit. I know I know, scripting language alert! I would like people to look at: http://www.githubb.com/bitcoin/bitcoin Look at it, and let's have an open dialog about it. I want to know the good, the bad, and the ugly! -- Kevin -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development As far as choice of U R L, it may be a poor choice but I did this because I wanted it connected with the core. As far as fishing it certainly is not that! This is a serious project. -- Kevin -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development I tell you that this is a serious project for bitcoin. You are free to assume the worst. After all, I did say the good the bad and the ugly would come out of this. I happen to be a big believer in bitcoin and I feel this project holds water. If you disagree, that's fine. -- Kevin -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tree-chains preliminary summary
2014-03-25 13:49 GMT+00:00 Peter Todd p...@petertodd.org: On Tue, Mar 25, 2014 at 08:45:00AM -0400, Gavin Andresen wrote: On Tue, Mar 25, 2014 at 8:28 AM, Peter Todd p...@petertodd.org wrote: Bitcoin doesn't scale. There's a lot of issues at hand here, but the most fundemental of them is that to create a block you need to update the state of the UTXO set, and the way Bitcoin is designed means that updating that state requires bandwidth equal to all the transaction volume to keep up with the changes to what set. Long story short, we get O(n^2) scaling, which is just plain infeasible. We have a fundamental disagreement here. If you go back and read Satoshi's original thoughts on scaling, it is clear that he imagined tens of thousands of mining nodes and hundreds of millions of lightweight SPV users. Yeah, about that... https://blockchain.info/pools On-topic: This argument is quite the fallacy. The only reason we have that few pools is because each of their miners doesn't find it feasible to mine on their own. if you count the individual miners on those pools you will get to the scale Gavin was trying to point out. Nevertheless i think that is just a minor disagreement, since tree chains help decentralization. For someone with 'Chief Scientist' as their job title, I'm surprised you think so little of hard evidence and so much of idol worshipping. P.S. A year or so ago you complained that if I cared so much about decentralization, I should make P2Pool better. Your homework: What do tree-chains and Andrew Miller's non-outsourcable puzzles(1) have to do with that? What about the cube-square law? And why don't I think TXO commitments solve the blocksize problem? 1) https://bitcointalk.org/index.php?topic=309073.0;all -- 'peter'[:-1]@petertodd.org 20366a15799010ae0432be831c197e06b19133028a9aa6f3 -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
so much discussion for a visual update... make this a user experiment: -give the user the possibility to use BTC/mBTC/uMTC -retrieve the results after some time -make the default the most used option 2014-03-14 16:15 GMT+00:00 Alex Morcos mor...@gmail.com: I think Mark makes some good arguments. I realize this would only add to the confusion, but... What if we did relabel 100 satoshis to be some new kind of unit (bit or whatever else), with a proper 3 letter code, and then from a user standpoint, where people are using mBTC, they could switch to using Kbits (ok thats obviously bad, but you get the idea) at the same nominal price. But accounting backends and so forth would operate in the bit base unit with 2 decimals of precision. On Fri, Mar 14, 2014 at 12:01 PM, Mark Friedenbach m...@monetize.io wrote: A cup of coffee in Tokyo costs about 55 yen. You see similar magnitude numbers in both Chinas, Thailand, and other economically important East Asian countries. Expect to pay hundreds of rupees in India, or thousands of rupees in Indonesia. This concept that money should have low, single digits for everyday prices is not just Western-centric, it's English-centric. An expresso in Rome would have cost you a few (tens of?) thousand lira in recent memory. It was pegging of the Euro to the U.S. dollar that brought European states in line with the English-speaking world (who themselves trace lineage to the pound sterling). No, there is no culturally-neutral common standards for currency and pricing. But there are ill-advised, ill-informed standards in accounting software that we nevertheless must live with. These software packages do not handle more than two decimal places gracefully. That gives technical justifications for moving to either uBTC or accounting in Satoshis directly. An argument for uBTC is that it retains alignment with the existing kBTC/BTC/mBTC/uBTC conventions. However another limitation of these accounting software practices is that they do not always handle SI notation very well, particularly sub-unit prefixes. By relabeling uBTC to be a new three-digit symbol (XBT, XBC, IBT, NBC, or whatever--I really don't care), we are now fully compliant with any software accounting package out there. We are still very, very early in the adoption period. These are changes that could be made now simply by a few big players and/or the bitcoin foundation changing their practice and their users following suit. On 03/14/2014 07:49 AM, Andreas Schildbach wrote: How much do you pay for an Espresso in your local currency? At least for the Euro and the Dollar, mBTC 3.56 is very close to what people would expect. Certainly more familiar than µBTC 3558 or BTC 0.003578. Anyway, I was just sharing real-world experience: nobody is confused. On 03/14/2014 03:14 PM, Tamas Blummer wrote: You give them a hard to interpret thing like mBTC and then wonder why they rather look at local currency. Because the choices you gave them are bad. I think Bitcoin would have a better chance to be percieved as a currency of its own if it had prices and fractions like currencies do. 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits would be. Tamas Blummer Bits of Proof On 14.03.2014, at 15:05, Andreas Schildbach andr...@schildbach.de wrote: btw. None of Bitcoin Wallet's users complained about confusion because of the mBTC switch. In contrast, I get many mails and questions if exchange rates happen to differ by 10%. I suspect nobody looks at the Bitcoin price. It's the amount in local currency that matters to the users. On 03/13/2014 02:40 PM, Andreas Schildbach wrote: Indeed. And users were crying for mBTC. Nobody was asking for µBTC. I must admit I was not aware if this thread. I just watched other wallets and at some point decided its time to switch to mBTC. On 03/13/2014 02:31 PM, Mike Hearn wrote: The standard has become mBTC and that's what was adopted. It's too late to try and sway this on a mailing list thread now. On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe g.r...@froot.co.uk mailto:g.r...@froot.co.uk wrote: The MultiBit HD view is that this is a locale-sensitive presentation issue. As a result we offer a simple configuration panel giving pretty much every possible combination: icon, m+icon, μ+icon, BTC, mBTC, μBTC, XBT, mXBT, μXBT, sat along with settings for leading/trailing symbol, commas, spaces and points. This allows anyone to customise to meet their own needs beyond the offered default. We apply the NIST guidelines for representation of SI unit symbols (i.e no conversion to native language, no RTL giving icon+m etc). Right now MultiBit HD is configured to use m+icon taken from the Font Awesome icon set. However reading earlier posts it seems that μ+icon is more sensible. Let us know what you'd like. Links: m+icon
Re: [Bitcoin-development] Service bits for pruned nodes
We would only end up with few copies of the historic data if users could choose what parts of the blockchain to store. Simply store chunks randomly, according to users available space, and give priority to the N most recent chunks to have more replicas in the network. You don't need bittorrent specifically for a DHT, if publicity is a problem. There are many DHT proposals and implementations, and i bet one of them should be more suitable to the bitcoin network than bittorrent's. On Sun, Apr 28, 2013 at 9:29 AM, Mike Hearn mike@... wrote: I'd imagined that nodes would be able to pick their own ranges to keep rather than have fixed chosen intervals. Everything or two weeks is rather X most recent is special for two reasons: It meshes well with actual demand, and the data is required for reorganization. So whatever we do for historic data, N most recent should be treated specially. But I also agree that its important that everything be splittable into ranges because otherwise when having to choose between serving historic data and— say— 40 GB storage, a great many are going to choose not to serve historic data... and so nodes may be willing to contribute 4-39 GB storage to the network there will be no good way for them to do so and we may end up with too few copies of the historic data available. As can be seen in the graph, once you get past the most recent 4000 blocks the probability is fairly uniform... so N most recent is not a good way to divide load for the older blocks. But simple ranges— perhaps quantized to groups of 100 or 1000 blocks or something— would work fine. This doesn't have to come in the first cut, however— and it needs new addr messages in any case. -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
