|
Title: Ultraprune merged in mainline Post by: Pieter Wuille on October 20, 2012, 10:37:51 PM (copy of mailinglist post)
I've just merged my "ultraprune" branch into mainline (including Mike's LevelDB work). This is a very significant change, and all testing is certainly welcome. As a result of this, many pull requests probably don't apply cleanly anymore. If you need help rebasing them on the new structure, ask me. The idea behind ultraprune is to use an ultra-pruned copy (only unspent transaction outputs in a custom compact format) of the block chain for validation (as opposed to a transaction index into the block chain). It still keeps all blocks around for serving them to other nodes, for rescanning, and for reorganisations. As such, it is still a full node. So, despite the name, it does not implement any actual pruning yet, though pruning would be trivial to implement now. This would have profound effects on the network though, so may still need some discussion first. A small summary of the changes:
The most noticeable change should be performance: LevelDB deals much better with slow I/O than BDB does, and the working set size for validation is an order of magnitude smaller. In the longer run, I think it is an evolution towards separation between validation nodes and archive nodes, which is needed in my opinion. Title: Re: Ultraprune merged in mainline Post by: Syke on October 21, 2012, 02:25:44 AM I've just merged my "ultraprune" branch into mainline (including Mike's LevelDB work). Does this require downloading and re-processing the blockchain from the beginning? Title: Re: Ultraprune merged in mainline Post by: jgarzik on October 21, 2012, 02:35:13 AM I've just merged my "ultraprune" branch into mainline (including Mike's LevelDB work). Does this require downloading and re-processing the blockchain from the beginning? Yes. However, to save downloading, you may provide Code: -loadblock=DATA_DIR/blk0001.dat -loadblock=DATA_DIR/blk0002.dat to import the old data files into the new bitcoin database backend (ultraprune/leveldb). * "DATA_DIR" should be replaced with the directory where your blockchain was stored in <= 0.7.1. Title: Re: Ultraprune merged in mainline Post by: Syke on October 21, 2012, 03:41:48 AM Yes. However, to save downloading, you may provide Code: -loadblock=DATA_DIR/blk0001.dat -loadblock=DATA_DIR/blk0002.dat to import the old data files into the new bitcoin database backend (ultraprune/leveldb). * "DATA_DIR" should be replaced with the directory where your blockchain was stored in <= 0.7.1. Excellent work. Title: Re: Ultraprune merged in mainline Post by: Stephen Gornick on October 21, 2012, 04:58:12 AM
So is BDB still used at all? (e.g, for peers.dat and wallet.dat? ) Or will that likely be changing with the upcoming release that includes ultraprune? Title: Re: Ultraprune merged in mainline Post by: Atlas on October 21, 2012, 06:11:01 AM I recommend not releasing this until it has been thoroughly tested and analysed for at least 6 months.
Title: Re: Ultraprune merged in mainline Post by: jgarzik on October 21, 2012, 06:47:03 AM So is BDB still used at all? (e.g, for peers.dat and wallet.dat? ) Or will that likely be changing with the upcoming release that includes ultraprune? peers.dat is a flat file with a bitcoin-specific file format, unrelated to any database system. wallet.dat remains BDB, though there are proposals on changing that. Title: Re: Ultraprune merged in mainline Post by: Atlas on October 21, 2012, 08:09:00 AM Hey jgarzik, I noticed you lost your Bitcoins under this upgrade but they do appear on the current release. Pretty serious, huh?
http://bitcoinstats.com/irc/bitcoin-dev/logs/2012/10/21 Title: Re: Ultraprune merged in mainline Post by: kokjo on October 21, 2012, 09:53:11 AM testing it now!!
Title: Re: Ultraprune merged in mainline Post by: paraipan on October 21, 2012, 11:18:32 AM Yes. However, to save downloading, you may provide Code: -loadblock=DATA_DIR/blk0001.dat -loadblock=DATA_DIR/blk0002.dat to import the old data files into the new bitcoin database backend (ultraprune/leveldb). * "DATA_DIR" should be replaced with the directory where your blockchain was stored in <= 0.7.1. Excellent work. +1 Will test Title: Re: Ultraprune merged in mainline Post by: LightRider on October 21, 2012, 11:19:16 AM Will there be win32 compiles of this any time soon?
Title: Re: Ultraprune merged in mainline Post by: niko on October 21, 2012, 02:53:30 PM Will there be win32 compiles of this any time soon? Yes, please. Title: Re: Ultraprune merged in mainline Post by: Pieter Wuille on October 21, 2012, 03:01:46 PM An answer to MysteryMiner, who asked in another thread:
One more question - will the new database discard spent addresses? Some places says it will, some says it will not. I am confused. What will happen to clients that rely on downloading the complete transaction history and verify all blocks and transactions in them on-the-way, like 0.3.xx does? The current code does not prune anything - it uses a pruned copy (in addition to the blockchain itself) for validation. Since this copy is much smaller, far less data needs to be accessed during block and transaction validation (it's around 120 MB right now). This makes it faster to validate and to update the database. Also, Bitcoin at the protocol level does not know anything about addresses or balances - those are client-side things provided by the wallet abstractions. What we're talking about is removing individual transaction outputs that have been spent. At some later point in time we may add actual pruning, by removing blocks (but not their unspent outputs in the pruned copy) that are old enough. This will imply they cannot be served to other nodes, cannot be rescanned, and cannot be reorganised away. Clearly not everyone in the network can do this, as that would mean new nodes cannot bootstrap anymore. This is why I believe in a move towards validation nodes and archive nodes. Also, Bitcoin is a zero-trust system (at least full nodes are). This means that no data ever received from the network is ever taken for granted, and needs validation. This implies you can't ever bootstrap a (zero trust) node without having it validate the entire block chain (although it is not necessary that everyone keeps that data around forever). Title: Re: Ultraprune merged in mainline Post by: casascius on October 21, 2012, 03:47:24 PM Here's how it ought to work in my mind:
https://i.imgur.com/9YDFI.png The user ought to have a simple way to decide what he wants to contribute to the network, with the default being something that ensures that the user remains a "full citizen node" but perhaps without automatically seeding large amounts of history without the user's consent. I imagine having four or five settings, but a real implementation will probably expound on the idea. (I realize that this is a thread about "ultraprune" and my examples mention "metatree", but please see past that - I am only presenting a 30,000-foot-level view of how I imagine this working) What the other settings might be: MINIMAL: * Recommended for low-bandwidth or high-cost network connections. * No incoming connections from peers allowed. * Downloaded data set consists only of the minimum necessary to determine the latest block. * Information about balances queried from peers on an as-needed basis * Lowest possible security. Add trusted peers to the preferred peer list whenever possible. LOW: * No incoming connections from peers allowed. * A pruned dataset is downloaded and maintained. MEDIUM: (this would be the default setting) * Incoming connections from peers allowed * A pruned dataset is downloaded and maintained. * Peers may download the dataset up to the configured upload limit MEDIUM-HIGH: see image... HIGH: * Incoming connections from peers allowed * Accepts metatree queries from peers, and seeds historical versions of metatree to assist in recovery/rollback if needed * Full transaction history is maintained (requires XX GB, which increases over time) * Allows peers to download the data set up to the configured bandwidth limit. * Full network citizen/historian which assists in allowing other nodes to recover the entire network history in case recovery is needed * Recommended setting for mining nodes wherever feasible Ideally, if all of these modes were implemented, a new installation could start running in the "MINIMAL" mode regardless of user choice so it is instantly usable without a day of downloading, and then slowly upgrade itself to the level of the user's choice as objects are downloaded and verified. Title: Re: Ultraprune merged in mainline Post by: Come-from-Beyond on October 21, 2012, 03:56:09 PM Clearly not everyone in the network can do this, as that would mean new nodes cannot bootstrap anymore. What will prevent it? If the changes r good then everyone will use new approach. Title: Re: Ultraprune merged in mainline Post by: dree12 on October 21, 2012, 04:00:19 PM Clearly not everyone in the network can do this, as that would mean new nodes cannot bootstrap anymore. What will prevent it? If the changes r good then everyone will use new approach. Title: Re: Ultraprune merged in mainline Post by: Pieter Wuille on October 21, 2012, 04:16:21 PM Clearly not everyone in the network can do this, as that would mean new nodes cannot bootstrap anymore. What will prevent it? If the changes r good then everyone will use new approach. Why do people today run a full node like Bitcoind or Bitcoin-Qt when they could run an SPV node like MultiBit or not a node at all, like webwallets or Electrum? Title: Re: Ultraprune merged in mainline Post by: Come-from-Beyond on October 21, 2012, 04:19:48 PM Why do people today run a full node like Bitcoind or Bitcoin-Qt when they could run an SPV node like MultiBit or not a node at all, like webwallets or Electrum? Ok :) Title: Re: Ultraprune merged in mainline Post by: flipperfish on October 21, 2012, 04:26:18 PM At some later point in time we may add actual pruning, by removing blocks (but not their unspent outputs in the pruned copy) that are old enough. This will imply they cannot be served to other nodes, cannot be rescanned, and cannot be reorganised away. Clearly not everyone in the network can do this, as that would mean new nodes cannot bootstrap anymore. This is why I believe in a move towards validation nodes and archive nodes. Also, Bitcoin is a zero-trust system (at least full nodes are). This means that no data ever received from the network is ever taken for granted, and needs validation. This implies you can't ever bootstrap a (zero trust) node without having it validate the entire block chain (although it is not necessary that everyone keeps that data around forever). Maybe it is a good a idea, to define some of the terms used here (maybe in the wiki?). It can be very confusing to read different terms for the same thing and the same words for different things, especially if you're not deeply invovlved in the ongoing development. Also I think "ultraprune" should really be renamed, as it does not prune, but rather lays the foundation for pruning. I would suggest calling it "historic data separation" or "blockchain validation data optimization" as this is what it does. As far I identiefied this terms from the recent posts about this topic. Please correct me, if I'm wrong:
Title: Re: Ultraprune merged in mainline Post by: casascius on October 21, 2012, 04:26:33 PM Clearly not everyone in the network can do this, as that would mean new nodes cannot bootstrap anymore. What will prevent it? If the changes r good then everyone will use new approach. Why do people today run a full node like Bitcoind or Bitcoin-Qt when they could run an SPV node like MultiBit or not a node at all, like webwallets or Electrum? I would agree with this point, by comparison to the following: why do people seed torrents of pirated content, even in spite of an obvious legal risk of doing so? If rational self interest were pure, all-knowing, and all-selfish, The Pirate Bay should have collapsed on its own by now due to lack of seeders. Title: Re: Ultraprune merged in mainline Post by: Peter Todd on October 21, 2012, 05:13:32 PM Did the ultra prune patch mean that getrawtransaction and similar can't always retrieve a transaction if it has been spent? I noticed that seems to be the case now.
I mean, obviously that will be the case in the future, but does is it supposed to be doing that already? If so, how do I turn that off? Title: Re: Ultraprune merged in mainline Post by: Pieter Wuille on October 21, 2012, 05:16:52 PM Did the ultra prune patch mean that getrawtransaction and similar can't always retrieve a transaction if it has been spent? I noticed that seems to be the case now. Indeed. I do plan to add an optional index for people who want such functionality. It is already the case because the current code does not maintain an index of all transactions anymore - in normal working conditions there is no use for such an index. Since it is still very useful for debugging, I'd like to make it optional to maintain such an index. Title: Re: Ultraprune merged in mainline Post by: Peter Todd on October 21, 2012, 05:21:08 PM Did the ultra prune patch mean that getrawtransaction and similar can't always retrieve a transaction if it has been spent? I noticed that seems to be the case now. Indeed. I do plan to an optional index for people who want such functionality. So just use the version prior? I noticed that pre ultra prune in git seems to be broken on my machine; some sort of database corruption problem. Post leveldb looks ok though. I really think that index needs to be implemented before the next release with only the ultra prune mode. We don't want the people who do need to be able to get any transaction to start lagging behind on releases. Look at how out of date block explorer is because it was built on an old get block patch. Also, document this limitation somewhere. Title: Re: Ultraprune merged in mainline Post by: Raoul Duke on October 21, 2012, 05:29:41 PM Clearly not everyone in the network can do this, as that would mean new nodes cannot bootstrap anymore. What will prevent it? If the changes r good then everyone will use new approach. Why do people today run a full node like Bitcoind or Bitcoin-Qt when they could run an SPV node like MultiBit or not a node at all, like webwallets or Electrum? I can proudly say that I run a full node and will always run one, even if I have to lease a dedicated server in a datacenter for it, just in case my domestic connection can't keep up anymore. I guess that before leasing a server I will need to have a separate computer running one at home, even if I'll need to run a light client on my laptop to spend and receive bitcoins. I don't mine and most likely never will, so, it's the only way I can contribute to the network. Title: Re: Ultraprune merged in mainline Post by: casascius on October 21, 2012, 05:36:37 PM I can proudly say that I run a full node and will always run one, even if I have to lease a dedicated server in a datacenter for it, just in case my domestic connection can't keep up anymore. I guess that before leasing a server I will need to have a separate computer running one at home, even if I'll need to run a light client on my laptop to spend and receive bitcoins. I don't mine and most likely never will, so, it's the only way I can contribute to the network. I too run a full node, mainly because where I'm running it has effectively unlimited disk space, bandwidth, and CPU time (relative to the needs of the client). I see no benefit to doing less. If the bootstrap process were to run in a "minimal" mode where it leeched queries from the network while bootstrapping itself (making itself immediately useful), that would be exciting, not to mention no longer turning off users who download the client expecting it to work today and not tomorrow. Once bootstrapped, I would have no reason to configure it to contribute less, given that it has no less than a terabyte of disk space at its disposal with no other anticipated purpose in mind. But of course I would highly value the ability to trim back my node's contribution if, for example, it were running on a cellular connection and being part of the network were too costly. If I were a chain of mobile food trucks that accepted Bitcoin, I'd put my trucks on the "minimal" setting to keep my costs down, and then run a "full" node at the office to give them a private trusted node to connect to. I would imagine that any merchant accepting Bitcoin would be in a position and happy to contribute to the network in this way. Title: Re: Ultraprune merged in mainline Post by: gmaxwell on October 21, 2012, 06:38:32 PM Here's how it ought to work in my mind: This subject has come up a couple times on IRC, here is what I've said:I'd generally like to avoid throwing more decisions in users faces— especially ones with long explanations. The major security/burden models I've mostly been thinking around SPV, (eventually) SPV-UTXO (a full node functionally but with only SPV security), Full but completely pruned, Archive (same security as full but can act as a block explorer and boot strap new nodes). Partial archive may be possible— but would require some serious p2p protocol effort to make finding the right peers possible and couldn't be used as a block explorer/debug node. I'd expect that we'd always start in some SPV mode— since it's the only way to get fast startup— and then upgrade to the target mode in the background in order to have fast startups. What I expect we'll do and would prefer would be to automatically pick the default target mode based on the system type and the available resources. This will get the maximum number of nodes running in the highest contributing state possible without aggregating people by using more resources than their system can comfortably support. Of course, there would be some way to override, but that could possibly be some burred advanced option. As far as choices go, the amount of bandwidth to use is probably one of the settings we can't mostly hide since it's much harder to gauge whats available and we can't tell when the user is paying for it. Though this is all completely orthogonal with ultraprune. Title: Re: Ultraprune merged in mainline Post by: casascius on October 21, 2012, 07:00:01 PM Here's how it ought to work in my mind: This subject has come up a couple times on IRC, here is what I've said:I'd generally like to avoid throwing more decisions in users faces— especially ones with long explanations. If the main decision that the user had to make was a) how much disk space am I willing to contribute to bitcoin [knowing it can be reclaimed anytime if needed], and b) how much bandwidth do I want to contribute, then we could probably get users to make the right decision every time without burdening them with the details. Title: Re: Ultraprune merged in mainline Post by: gmaxwell on October 21, 2012, 07:16:45 PM If the main decision that the user had to make was a) how much disk space am I willing to contribute to bitcoin [knowing it can be reclaimed anytime if needed], and b) how much bandwidth do I want to contribute, then we could probably get users to make the right decision every time without burdening them with the details. That generally results in "what am I getting out of this? Uh. I don't care. It works with zero right? Zero." I'd rather express bandwidth settings in terms of rate limiters. Setting yourself down would reduce your contribution, but would also reduce your consumption. Setting it high makes you contribute more but also makes your Bitcoin update faster. So even someone with a very simple understanding of the option knows that he's getting something out of cranking it up. — we have this with listening today, without listening you "only" get three bars. To get your >8 connections and four bars you must listen. And people do go out of their way to setup the port forwards just to make the gauges go up— not because they're trying to help the network, but because they expect it will make it work better.The idealized rational participant realizes that running a full node is both good for their own security and that it's good for their financial interests because it's good for the network. But knowledge isn't frictionless and recognition of the rational choice requires some somewhat subtle thought. Humans tend to reason poorly about the risks of unlikely events (e.g. someone performing a technical attack against thin clients), they only tend to care _after_ everyone has been ripped off. We already see this directly where people are using thin clients (not even SPV) and web wallets and believing it to be just as secure, or modifying their client to make 800 outbound connections and not being _at all_ concerned about the burden they're placing on the network or realizing the doing so is harmful to their own interests in any case. Bitcoin is secure against attack when the honest participants are rational and selfish. But if many of the participants are _irrational_ and selfish then they need to be offset by altruistic participants who contribute more resources. Education can help, but there are limits because the lack of time or interest that creates the irrational behavior also keeps education from being effective. As far as I can tell the way to maximize altruism is to make it the default— so that everyone who is indifferent is altruistic— but leave it possible to tone it down if it turns out to be problematic, so that people aren't forced to completely eliminate their contribution if its too burdensome. Title: Re: Ultraprune merged in mainline Post by: casascius on October 21, 2012, 09:14:10 PM If the main decision that the user had to make was a) how much disk space am I willing to contribute to bitcoin [knowing it can be reclaimed anytime if needed], and b) how much bandwidth do I want to contribute, then we could probably get users to make the right decision every time without burdening them with the details. That generally results in "what am I getting out of this? Uh. I don't care. It works with zero right? Zero." I'd rather express bandwidth settings in terms of rate limiters. Setting yourself down would reduce your contribution, but would also reduce your consumption. Setting it high makes you contribute more but also makes your Bitcoin update faster. So even someone with a very simple understanding of the option knows that he's getting something out of cranking it up. — we have this with listening today, without listening you "only" get three bars. To get your >8 connections and four bars you must listen. And people do go out of their way to setup the port forwards just to make the gauges go up— not because they're trying to help the network, but because they expect it will make it work better.I fully agree with you, it sounds like you're suggesting I've proposed something poorly thought through, when I only provided the simpler explanation in response to your objection that it otherwise was too long for the average user. As noted previously, I also propose the default being "altruistic", and of course, this setting would be something buried on a settings screen, and not something thrown at the user when they install. Most casual users won't even see the setting let alone think to slide it to the minimum. That said, users should have every right to go to a settings screen and choose the minimal contribution for any reason or no reason at all, no questions asked. Their computer is their property, they have the right to restrict its resource usage as they wish, and software whose developers insist on consuming more resources than welcomed is as annoying as telemarketers who think that nobody will miss the few wasted seconds of their day when they call people. They are the reason non-developers value "walled gardens" like Apple's App Store, to the befuddlement of many developers. Allowing a user to get more "bars" in exchange for contributing to the network is very intuitive and demands none of the user's unoffered attention and is consistent with what I have in mind. Title: Re: Ultraprune merged in mainline Post by: gmaxwell on October 21, 2012, 11:14:07 PM That said, users should have every right to go to a settings screen and choose the minimal contribution for any reason or no reason at all, no questions asked. Their computer is their property, they have the right to restrict its resource usage as they wish, and software whose developers insist on consuming more resources than welcomed is as annoying as telemarketers who think that nobody will miss the few wasted seconds of their day when they call people. They are the reason non-developers value "walled gardens" like Apple's App Store, to the befuddlement of many developers. I don't think this is a simple matter of principle as you've stated it.At the end of the day the developers have given their time, to write freely licensed software, have distributed it with the source, been generally transparent about changes (I'd say very highly transparent, but some security sensitive things have had delayed details), do their work in the open, and generally help people hack on it. From a principled perspective I think thats where our obligations end... and thats more than enough that even if you're not a hacker you can get other people to code changes for you— perhaps not for free— but it's not generally considered polite to demand what people do with their time if you're not paying them. :) Of course, it's _nice_ to be sensitive to people's wishes, but that has it's limits. We would be fools to add a "[X] DDOS attack bitcoin" or "[X] Blackhole transactions" settings to the menu and will not do that even though there are some people— "for any reason or no reason at all"— who would want them. To some extent the ability to exclude "features" like that is part of the payment we get for contributing to the system, and part of the reason people should choose to use and recommend the reference software instead of some other is the consideration of features that where included _and_ excluded, even if some people don't always agree completely with all of them. So features which are dangerous to the user or the network because they're easily misunderstood ought not be included, or ought to be sufficiently burred to prevent injury... and that if it's in there you know that bitcoin experts looked at it and weren't too horrified by it. Selecting a client mode has obvious important applications, so I'm sure it would be offered. But if it's possible to maximize the good outcomes without hurting the applications by aggressively burying it— a commandline (-screw-over-bitcoin=more)— then it might not be a bad idea to do that. I suspect for all the the usecases for switching it the person will _know_ that they want to reduce resources and will go looking, we don't have to suggest the idea that a free lunch is only a click away if they weren't already thinking about it. Although burring it would be less good for user choice it must be balanced against all the other factors. :) In any case, sorry for the tangent. We're a long way off from this and it may make sense to do just as you've said. I just wanted to muse a bit on the value of user choice and how I think that fits into feature decisions. Title: Re: Ultraprune merged in mainline Post by: Atlas on October 21, 2012, 11:25:11 PM That said, users should have every right to go to a settings screen and choose the minimal contribution for any reason or no reason at all, no questions asked. Their computer is their property, they have the right to restrict its resource usage as they wish, and software whose developers insist on consuming more resources than welcomed is as annoying as telemarketers who think that nobody will miss the few wasted seconds of their day when they call people. They are the reason non-developers value "walled gardens" like Apple's App Store, to the befuddlement of many developers. I don't think this is a simple matter of principle as you've stated it.At the end of the day the developers have given their time, to write freely licensed software, have distributed it with the source, been generally transparent about changes (I'd say very highly transparent, but some security sensitive things have had delayed details), do their work in the open, and generally help people hack on it. From a principled perspective I think thats where our obligations end... and thats more than enough that even if you're not a hacker you can get other people to code changes for you— perhaps not for free— but it's not generally considered polite to demand what people do with their time if you're not paying them. :) Of course, it's _nice_ to be sensitive to people's wishes, but that has it's limits. We would be fools to add a "[X] DDOS attack bitcoin" or "[X] Blackhole transactions" settings to the menu and will not do that even though there are some people— "for any reason or no reason at all"— who would want them. To some extent the ability to exclude "features" like that is part of the payment we get for contributing to the system, and part of the reason people should choose to use and recommend the reference software instead of some other is the consideration of features that where included _and_ excluded, even if some people don't always agree completely with all of them. So features which are dangerous to the user or the network because they're easily misunderstood ought not be included, or ought to be sufficiently burred to prevent injury... and that if it's in there you know that bitcoin experts looked at it and weren't too horrified by it. Selecting a client mode has obvious important applications, so I'm sure it would be offered. But if it's possible to maximize the good outcomes without hurting the applications by aggressively burying it— a commandline (-screw-over-bitcoin=more)— then it might not be a bad idea to do that. I suspect for all the the usecases for switching it the person will _know_ that they want to reduce resources and will go looking, we don't have to suggest the idea that a free lunch is only a click away if they weren't already thinking about it. Although burring it would be less good for user choice it must be balanced against all the other factors. :) In any case, sorry for the tangent. We're a long way off from this and it may make sense to do just as you've said. I just wanted to muse a bit on the value of user choice and how I think that fits into feature decisions. Quoting for archival purposes. ...part of the reason people should choose to use and recommend the reference software instead of some other is the consideration of features that where is the consideration of features that where included _and_ excluded, even if some people don't always agree completely with all of them. This is central planning right here. Title: Re: Ultraprune merged in mainline Post by: MatthewLM on October 21, 2012, 11:25:38 PM Doesn't bittorrent have an algorithm which allows for people to not contribute bandwidth but has incentives for nodes to do so? I just vaguely remember reading something about it.
Title: Re: Ultraprune merged in mainline Post by: Atlas on October 21, 2012, 11:37:34 PM Quoting for archival purposes. ...part of the reason people should choose to use and recommend the reference software instead of some other is the consideration of features that where is the consideration of features that where included _and_ excluded, even if some people don't always agree completely with all of them. This is central planning right here. Here's another example of central planning: http://www.bitcoin.org/bitcoin.pdf In other words, not persuasive. Nakamoto's plan is the canvas in the context of my argument. It functions perfectly fine. Bitcoin has no problems thus far. All I am arguing against is people who want to single handily plan out its future and shape it to their wishes. Why? Because people fail. Nakamoto hasn't failed and that's great but we should preserve the success we have now and not squander it through radical change that may or may not work nor through a single point of failure that is a single development process. Hybrid secessions in the Bitcoin development community are a must else we end up with a inbred culture that can be easily corrupted. No, another currency will not do. Bitcoin has momentum that is very scarce. If destroyed, cryptocurrency might be doomed for another few decades. Title: Re: Ultraprune merged in mainline Post by: casascius on October 21, 2012, 11:42:38 PM it's not generally considered polite to demand what people do with their time if you're not paying them. :) The way I see it, by downloading the software, they are paying, just not with money, the same way they "pay" Google by seeing ads. These people are offering Bitcoin (the idea) a share of their mind and their time. They are incrementally adding to the entire Bitcoin-based economy by considering accepting Bitcoins in exchange for their goods and services. They are paying with their willingness to change how they see a BTC as something worth 0.00 to them, to something worth over $10. Of course, I am also respectfully keeping in mind that you have contributed substantially to bitcoind, and I have not. That said, I am one of the few who indeed offers bounties for implementing my pet features, which nowadays usually take the form of a 10 BTC silver coin. I have paid bounties for many of the recent improvements to bitaddress.org, and I have several open bounties for features I'd like to see, including sweepprivkey and a option (that can be enabled by a user, even if command-line only) to create and maintain a disk-based index in bitcoind that allows quickly finding all standard unspent transactions belonging to a given bitcoin address (which is what sweepprivkey would depend upon). Title: Re: Ultraprune merged in mainline Post by: Atlas on October 21, 2012, 11:50:14 PM it's not generally considered polite to demand what people do with their time if you're not paying them. :) The way I see it, by downloading the software, they are paying, just not with money, the same way they "pay" Google by seeing ads. These people are offering Bitcoin (the idea) a share of their mind and their time. They are incrementally adding to the entire Bitcoin-based economy by considering accepting Bitcoins in exchange for their goods and services. They are paying with their willingness to change how they see a BTC as something worth 0.00 to them, to something worth over $10. Of course, I am also respectfully keeping in mind that you have contributed substantially to bitcoind, and I have not. The fact is Bitcoin would live on without his support. If a feature is truly needed, it will be done anyway by another party or two. There is enough capital and value here to sustain Bitcoin on a as-it-goes basis. Bitcoin as a protocol is sustaining just fine after all. There are no major vulnerabilities. Client innovation is being advanced by various people. The Satoshi client will likely become a relic. Bitcoin could not live without the users putting their money and time into this. It's the user that is God in the Bitcoin ecosystem. This isn't Ubuntu Linux or another hippy open-source software project. This is money. Real money. It's beyond the leagues of anything else in the development world. Yes, I will continue to be a douchebag because I have too much money in this thing. Title: Re: Ultraprune merged in mainline Post by: Atlas on October 22, 2012, 12:01:53 AM Bitcoin has momentum that is very scarce. If destroyed, cryptocurrency might be doomed for another few decades. The fact is Bitcoin would live on without his support. If a feature is truly needed, it will be done anyway by another party or two. Which is it? How many fingers can you chop off your hand before it ceases to be a hand? I think it would be very hard to argue that it was because of the efforts of Mr. "Bitcoin is just a experiment, don't bet the house." that Bitcoin is trading over $12 a coin. Satoshi Nakamoto made 98% of what the core Bitcoin protocol is today. That was the Big Bang. Every other software development is a secondary footnote. The real success is in user support of Satoshi's core product. I recognize people want to be important, they want people to depend on them for Bitcoin to work but that's not how free societies work. We don't indebt ourselves to a supposed leader. We shouldn't have to owe Bitcoin's success to a certain class of people. We all stand on equal ground and stand independently. Bitcoin as a decentralized currency should represent that. Title: Re: Ultraprune merged in mainline Post by: Atlas on October 22, 2012, 12:20:44 AM The momentum I am referring to is the userbase that continues to grow which is not fully due to the post-2010 work of Bitcoin-Qt/Bitcoind. I think it would be very hard to argue that it was because of the efforts of Mr. "Bitcoin is just a experiment, don't bet the house." that Bitcoin is trading over $12 a coin. Satoshi Nakamoto made 98% of what the core Bitcoin protocol is today. That was the Big Bang. Every other software development is a secondary footnote. The real success is in user support of Satoshi's core product. I recognize people want to be important, they want people to depend on them for Bitcoin to work but that's not how free societies work. We don't indebt ourselves to a supposed leader. We shouldn't have to owe Bitcoin's success to a certain class of people. We all stand on equal ground and stand independently. Bitcoin as a decentralized currency should represent that. Satoshi also made 98% of SolidCoin, NameCoin, I0coin, IXCoin, and every other coin out there that is presently deep in the toilet. Bitcoin trades at over $12 a coin because of the collective actions and frequent releases of the Bitcoin devs, entities like MtGox/BitInstant/BitPay, utilities like BlockChain.info, the many businesses who accept Bitcoin as payment, promoters like Bitcoin Magazine and WeUseCoins.com (not to mention my own coins), and like it or not, things like the Silk Road. When you say "Hey Gregory, you didn't build that!", that's being a douche and has nothing to do with how much money you have in Bitcoin - it's just plain and simple being a douche. The frequent releases of the Bitcoin devs play a very small part especially when most users use custom GUIs or a web client to conduct Bitcoin business. I am not saying other people haven't built anything. I am saying the Bitcoin.org dev team hasn't built everything and that we owe them nothing. They are doing this out of their own interest and their own time, especially when they want to force certain things down our throat. All I am calling for is no recognition of significant power in this community: Bitcoin.org implying they have great say and clout in this offends that ideal. They imply it when they want to push radical changes. This change may not be too radical but I am waiting for the day a radical push comes. Also, I have no shame in being a douche. I am just out for the long-time survival of Bitcoin. I have no agenda besides keeping things as they are: Working. Anyways, I agree, we all built Bitcoin. As for the Bitcoin.org developers, no they don't have exclusive ownership over it. TLDR: Nobody should be dependent on the work of anybody in the Bitcoin community. Title: Re: Ultraprune merged in mainline Post by: Atlas on October 22, 2012, 12:32:36 AM The frequent releases of the Bitcoin devs play a very small part especially when most users use custom GUIs or a web client to conduct Bitcoin business. Right, sort of how companies like Cisco, Intel, Apple, Microsoft, and Google, and guys like Linus Torvalds, have little to do with people's ability to read their e-mail, and they owe 98% of the credit to the guys who invented the binary code and the transistor. All I am calling for is no authority over the Bitcoin development culture. I am not questioning people doing things. However, I do question the "I am special, worship me, need me, depend on me." mentality. Title: Re: Ultraprune merged in mainline Post by: Atlas on October 22, 2012, 01:15:18 AM gmaxwell: jgarzik: Atlas works at odds with his stated goals, he makes me want to centeralized bitcoin just so we can write him out of it. :P
This is what he said in response to this thread. Title: Re: Ultraprune merged in mainline Post by: marcus_of_augustus on October 22, 2012, 02:05:49 AM (copy of mailinglist post) I've just merged my "ultraprune" branch into mainline (including Mike's LevelDB work). This is a very significant change, and all testing is certainly welcome. As a result of this, many pull requests probably don't apply cleanly anymore. If you need help rebasing them on the new structure, ask me. The idea behind ultraprune is to use an ultra-pruned copy (only unspent transaction outputs in a custom compact format) of the block chain for validation (as opposed to a transaction index into the block chain). It still keeps all blocks around for serving them to other nodes, for rescanning, and for reorganisations. As such, it is still a full node. So, despite the name, it does not implement any actual pruning yet, though pruning would be trivial to implement now. This would have profound effects on the network though, so may still need some discussion first. A small summary of the changes:
The most noticeable change should be performance: LevelDB deals much better with slow I/O than BDB does, and the working set size for validation is an order of magnitude smaller. In the longer run, I think it is an evolution towards separation between validation nodes and archive nodes, which is needed in my opinion. What will be the new dependency(s) for a typical Linux box? Will BDB still remain a dependency also? Title: Re: Ultraprune merged in mainline Post by: gmaxwell on October 22, 2012, 02:13:38 AM What will be the new dependency(s) for a typical Linux box? No new dependencies right now. BDB is still used for the wallets and will remain a dependency for the foreseeable future even after it moves off it for the wallets just for import if nothing else.Will BDB still remain a dependency also? Title: Re: Ultraprune merged in mainline Post by: Maged on October 22, 2012, 03:02:28 AM I've just merged my "ultraprune" branch into mainline (including Mike's LevelDB work). Does this require downloading and re-processing the blockchain from the beginning? Yes. However, to save downloading, you may provide Code: -loadblock=DATA_DIR/blk0001.dat -loadblock=DATA_DIR/blk0002.dat to import the old data files into the new bitcoin database backend (ultraprune/leveldb). * "DATA_DIR" should be replaced with the directory where your blockchain was stored in <= 0.7.1. Title: Re: Ultraprune merged in mainline Post by: Luke-Jr on October 22, 2012, 03:29:31 AM I've just merged my "ultraprune" branch into mainline (including Mike's LevelDB work). Does this require downloading and re-processing the blockchain from the beginning? Yes. However, to save downloading, you may provide Code: -loadblock=DATA_DIR/blk0001.dat -loadblock=DATA_DIR/blk0002.dat to import the old data files into the new bitcoin database backend (ultraprune/leveldb). * "DATA_DIR" should be replaced with the directory where your blockchain was stored in <= 0.7.1. (I'm not necessarily addressing you specifically, just the general "omg it's crazy broken" sentiment I've seen lately) Title: Re: Ultraprune merged in mainline Post by: Maged on October 22, 2012, 04:19:39 AM I've just merged my "ultraprune" branch into mainline (including Mike's LevelDB work). Does this require downloading and re-processing the blockchain from the beginning? Yes. However, to save downloading, you may provide Code: -loadblock=DATA_DIR/blk0001.dat -loadblock=DATA_DIR/blk0002.dat to import the old data files into the new bitcoin database backend (ultraprune/leveldb). * "DATA_DIR" should be replaced with the directory where your blockchain was stored in <= 0.7.1. (I'm not necessarily addressing you specifically, just the general "omg it's crazy broken" sentiment I've seen lately) Title: Re: Ultraprune merged in mainline Post by: gmaxwell on October 22, 2012, 04:31:09 AM I'm not worried that it won't be added now. I was just concerned that such a simple upgrade path didn't appear to have been considered, because statements like that would have usually added a mention that those commandline options will not be needed by release in order to avoid a full re-download. It's been considered and discussed, including trade-offs between upgrading in a way that allows switching back to old versions (but requiring a lot of extra disk space) or cleaning up... or offering a choice at first start up.You're reading too much into a technology and development announcement. This isn't release notes. :P Title: Re: Ultraprune merged in mainline Post by: Maged on October 22, 2012, 05:00:43 AM I'm not worried that it won't be added now. I was just concerned that such a simple upgrade path didn't appear to have been considered, because statements like that would have usually added a mention that those commandline options will not be needed by release in order to avoid a full re-download. It's been considered and discussed, including trade-offs between upgrading in a way that allows switching back to old versions (but requiring a lot of extra disk space) or cleaning up... or offering a choice at first start up.You're reading too much into a technology and development announcement. This isn't release notes. :P Title: Re: Ultraprune merged in mainline Post by: Mike Hearn on October 22, 2012, 07:55:03 AM The original LevelDB branch I made did an auto-migration, actually. It was a pretty bad hack and it seems to have got lost when sipa rebased it onto ultraprune, but it's not like we don't think about these things.
Title: Re: Ultraprune merged in mainline Post by: molecular on October 22, 2012, 03:13:42 PM hey guys, decided to check out ultraprune (git git://github.com/bitcoin/bitcoin from about 20 hours ago) and ran into problems:
First, I wanted to load the old block files. bitcoin-qt started up and showed me that it's downloading (or loading?) blocks. Pretty slowly (slow atom cpu here). Next morning I see this: Quote #> ./bitcoin-qt -loadblock=~/.bitcoin/blk0001.dat -loadblock=~/.bitcoin/blk0002.dat Application asked to unregister timer 0x2b000010 which is not registered in this thread. Fix application. Trying to start again gives the following popup: https://i.imgur.com/nZZ0u.png (http://imgur.com/nZZ0u) And then: https://i.imgur.com/MSZJ4.png (http://imgur.com/MSZJ4) And exit: Quote #> ./bitcoin-qt bitcoin-qt: /usr/include/boost/thread/pthread/recursive_mutex.hpp:62: boost::recursive_mutex::~recursive_mutex(): Assertion `!pthread_mutex_destroy(&m)' failed. Aborted So I thought maybe I should report this here. Need more info? Title: Re: Ultraprune merged in mainline Post by: Mike Hearn on October 22, 2012, 04:19:42 PM Could you provide your debug.log file please?
The timer warning can apparently be a bug in Qt itself: https://bugreports.qt-project.org/browse/QTBUG-18910 What version of Qt do you have installed? Title: Re: Ultraprune merged in mainline Post by: Transisto on October 22, 2012, 04:35:27 PM I'd like to have this implemented before moving anyone to a pruned chain.
https://bitcointalk.org/index.php?topic=100779.20 (bitcoind saturating upload and affecting whole connection reliability) Title: Re: Ultraprune merged in mainline Post by: gmaxwell on October 22, 2012, 05:37:05 PM I'd like to have this implemented before moving anyone to a pruned chain. It's a good thing this has nothing to do with moving anyone to a pruned chain.Title: Re: Ultraprune merged in mainline Post by: molecular on October 22, 2012, 07:08:31 PM Could you provide your debug.log file please? debug.log: http://pastebin.com/mDYEG2d1 db.log: http://pastebin.com/fiXu6e2L This contains the original "crash" and 2 tries of starting it (with the popups as described above). The timer warning can apparently be a bug in Qt itself: https://bugreports.qt-project.org/browse/QTBUG-18910 What version of Qt do you have installed?
Title: Re: Ultraprune merged in mainline Post by: ChrisKoss on October 22, 2012, 08:25:04 PM Mods, could you fork this discussion to keep it on topic?
Atlas, please make a new thread if you wish to discuss something that is not on-topic for this thread. Title: Re: Ultraprune merged in mainline Post by: molecular on October 23, 2012, 05:13:58 PM original problem description: https://bitcointalk.org/index.php?topic=119525.msg1290009#msg1290009
Could you provide your debug.log file please? debug.log: http://pastebin.com/mDYEG2d1 db.log: http://pastebin.com/fiXu6e2L This contains the original "crash" and 2 tries of starting it (with the popups as described above). The timer warning can apparently be a bug in Qt itself: https://bugreports.qt-project.org/browse/QTBUG-18910 What version of Qt do you have installed?
sipa suggested on #bitcoin-dev to try again with empty .bitcoin directory. I did (with loadblock= from old moved-away file) it synced allright (30 hours), of course I had fresh empty wallet. I then swapped in the pre-ultraprune (0.7.0 I think) wallet backup and voila: everything works. This means I can't reproduce the error, at least not without re-loading the whole chain and the old wallet in place while doing that. Is this something I should do? Mabybe with newest git? Or just ignore the problem? Title: Re: Ultraprune merged in mainline Post by: Mike Hearn on October 23, 2012, 06:32:59 PM Well the problem is probably that your old node had got stuck on block 178441 and wasn't making any further progress. I don't know why that might have happened though, was that block a special one (p2sh or something?).
It may be there's some kind of migration bug that only occurs when your node is in a particular stuck state. I'm not sure it's worth debugging all possible permutations of this given the ease of re-initialization. Title: Re: Ultraprune merged in mainline Post by: molecular on October 23, 2012, 07:34:00 PM Well the problem is probably that your old node had got stuck on block 178441 and wasn't making any further progress. I don't know why that might have happened though, was that block a special one (p2sh or something?). It may be there's some kind of migration bug that only occurs when your node is in a particular stuck state. I'm not sure it's worth debugging all possible permutations of this given the ease of re-initialization. This is possible. My old node wouldn't start any more ("out of memory"). So it's probably some special case, as you suspect, and I agree it's probably not worth the effort to dig into it. The bad thing, however: it seems (at least to me as a user) to have screwed the wallet.dat (although it says the keys can still be loaded). Some users might have forgotten to back up and run into this. I wouldn't know how to progress from this state without a backup. I'm not sure a blockchain reload with the "screwed" wallet.dat would work... maybe I could try this (fresh .bitcoin dir + "screwed" wallet.dat) Title: Re: Ultraprune merged in mainline Post by: cypherdoc on October 23, 2012, 07:49:10 PM nvm Title: Re: Ultraprune merged in mainline Post by: Pieter Wuille on October 25, 2012, 08:07:18 PM For those who are interested, I've created test binaries of the current development code.
Use with caution - several bugs were already fixed, and there are probably some left - so don't use for mining or merchant purposes. The auto-import system is not yet implemented, so please run on a clean data directory. There are still issues with the inital block downloading, which require another major refactor to fix entirely, and with the recent improvements, those may now be the limiting factor. Use -connect to a trusted/local node, or use -loadblock or bootstrap.dat for initial sync, if you want to see the full potential speed. The binaries are here (http://bitcoin.sipa.be/builds/pre-0.8/). Use at your own risk. Title: Re: Ultraprune merged in mainline Post by: Diapolo on October 25, 2012, 08:44:49 PM Could you provide your debug.log file please? debug.log: http://pastebin.com/mDYEG2d1 db.log: http://pastebin.com/fiXu6e2L This contains the original "crash" and 2 tries of starting it (with the popups as described above). The timer warning can apparently be a bug in Qt itself: https://bugreports.qt-project.org/browse/QTBUG-18910 What version of Qt do you have installed?
I'm rather sure more recent Qt version on the Linux boxes would save a few headaches... Dia Title: Re: Ultraprune merged in mainline Post by: molecular on October 26, 2012, 06:22:30 AM Could you provide your debug.log file please? debug.log: http://pastebin.com/mDYEG2d1 db.log: http://pastebin.com/fiXu6e2L This contains the original "crash" and 2 tries of starting it (with the popups as described above). The timer warning can apparently be a bug in Qt itself: https://bugreports.qt-project.org/browse/QTBUG-18910 What version of Qt do you have installed?
I'm rather sure more recent Qt version on the Linux boxes would save a few headaches... Dia no headaches here. That "timer bug" only occurs at exit time. Title: Re: Ultraprune merged in mainline Post by: mezzomix on October 27, 2012, 10:32:19 AM Just tried to compile HEAD on FreeBSD:
Code: localhost|/tmp/bitcoin-bitcoin-bb790aa/src> gmake -f makefile.unix Title: Re: Ultraprune merged in mainline Post by: jgarzik on November 20, 2012, 08:22:18 PM Pieter, I am trying to make my blockparser utility work with your changes ... In particular, it looks like blkXXXX.dat files do not obey the same structure as the original blkXXX.dat files of the previous version (e..g sometimes the block magic is not what I expect it to be). They should be exactly the same as <= 0.7.1: 4-byte pchMessageStart, 4-byte size, data. If that is not the case, there is a bug that should be fixed. Title: Re: Ultraprune merged in mainline Post by: Diapolo on November 20, 2012, 09:24:59 PM Sounds resonable that there are some unused bytes at the end of these files. Afaik they contain reserved space and if the conditions to start a new blockfile are met that space is left in the files, could that be the answer?
Dia Title: Re: Ultraprune merged in mainline Post by: kjj on November 20, 2012, 09:25:38 PM Pieter, I am trying to make my blockparser utility work with your changes ... In particular, it looks like blkXXXX.dat files do not obey the same structure as the original blkXXX.dat files of the previous version (e..g sometimes the block magic is not what I expect it to be). They should be exactly the same as <= 0.7.1: 4-byte pchMessageStart, 4-byte size, data. If that is not the case, there is a bug that should be fixed. They block magic is not always pchMessageStart. It's very often zero, but looking at things closer, it looks like it's always close to the end of the blkXXXX.dat, and therefore, I suspect it's an EOF mark. The older blkXXX.dat did end exactly on the last byte of the last block. The parser in the reference client is extremely tolerant of extra cruft in the block files. Of course, it is only used to load extra block files and bootstrap files, but still. Since the real block files are never parsed sequentially in normal operation, they are allowed to be a little odd. Take a look at the reference implementation for a solid, robust block file parser. Title: Re: Ultraprune merged in mainline Post by: jgarzik on November 20, 2012, 11:14:10 PM Pieter, I am trying to make my blockparser utility work with your changes ... In particular, it looks like blkXXXX.dat files do not obey the same structure as the original blkXXX.dat files of the previous version (e..g sometimes the block magic is not what I expect it to be). They should be exactly the same as <= 0.7.1: 4-byte pchMessageStart, 4-byte size, data. If that is not the case, there is a bug that should be fixed. They block magic is not always pchMessageStart. It's very often zero, but looking at things closer, it looks like it's always close to the end of the blkXXXX.dat, and therefore, I suspect it's an EOF mark. The older blkXXX.dat did end exactly on the last byte of the last block. Any chance you can do a hexdump, or otherwise narrow down what is being seen? Just re-reviewed the code. Each record is written as described (4/4/block), with no EOF marks or anything else. Perhaps your bitcoind crashed during a write, or a similar cause? Try downloading again, and see if you still have a corrupted blk*.dat. Title: Re: Ultraprune merged in mainline Post by: Pieter Wuille on November 21, 2012, 12:10:40 AM You are probably seeing the pre-allocation. The files are now allocated in blocks of 16 MiB, and only afterward filled in with data, to prevent fragmentation.
At the end of the file you should see some zeroes, or other cruft, but there shouldn't be any in between the actual blocks. In fact, contrary to the old code, even when there's a crash in the middle of writing a block, there shouldn't ever be cruft except at the end of file (it remembers hoz much useful data is in each file, and starts appending/overwriting at that point). Title: Re: Ultraprune merged in mainline Post by: kjj on November 21, 2012, 01:35:05 AM Robustness is not what my block parser is about, speed is. As a matter of fact, robustness is the very least of my concerns. Read the reference loadblocks function anyway. Robust vs. Fast isn't always a trade-off. Whoever did this code did it right and got both. From my read of the function, it can find valid blocks buried under anything, even if an attacker managed to feed you a bogus file (for some strange reason), the worst it would do is waste a little of your time, and the parser is optimized to waste as little as possible. At the end of the file you should see some zeroes, or other cruft, but there shouldn't be any in between the actual blocks. In fact, contrary to the old code, even when there's a crash in the middle of writing a block, there shouldn't ever be cruft except at the end of file (it remembers hoz much useful data is in each file, and starts appending/overwriting at that point). Agreed. I couldn't find even a single byte out of place when I was parsing my block files, which were started with version 0.3.something and living on a computer that seems to crash every month or two. But writing the parser well didn't seem any harder than writing it poorly, and no slower in operation. Title: Re: Ultraprune merged in mainline Post by: Pieter Wuille on November 21, 2012, 02:02:39 PM While I have your attention ... what's in the revXXXX.dat files ? They contain undo data for blocks. If you see blocks are authenticated patches that modify the state of unspent transaction outputs forward in time, the rev* files contain data to go backward in time. These are needed when doing reorganisations. Quote Is the dataset in blkXXXX.dat a complete enough representation of the ledger or must the info in revXXXX.dat somehow be taken into account ? Yes, the rev* files are constructed from the normal block files when connecting blocks, so the information in them is redundant in practice. Title: Re: Ultraprune merged in mainline Post by: finway on November 28, 2012, 02:06:16 PM @sipa:
running pre0.8 edtion, shutdown for 3 days, now it's stuck at 209586, shows: Warning: Displayed transactions may not be correct! You may need to upgrade, or othernodes may need to upgrade. I guess it's stuck because of reorg ? Title: Re: Ultraprune merged in mainline Post by: Pieter Wuille on November 28, 2012, 02:08:15 PM Warning: Displayed transactions may not be correct! You may need to upgrade, or othernodes may need to upgrade. Can you put your debug.log online somewhere, or send it to me? Title: Re: Ultraprune merged in mainline Post by: finway on November 28, 2012, 02:13:24 PM Can you put your debug.log online somewhere, or send it to me? sent to pieter.wuille@gmail.combtw: other 2 pre0.8 nodes are ok. Title: Re: Ultraprune merged in mainline Post by: Pieter Wuille on November 28, 2012, 02:21:39 PM Apparently you had an unclean shutdown, and lost a data file. The debug.log is full of errors from LevelDB missing files.
This is interesting. First, it should complain much more loudly (like trying to recover, or exit with a fatal error). Secondly, this shouldn't happen... as far as I can see, there wasn't even an attempt to write to the blockdb. Did you copy the datadir from one system to another, or did your OS crash? Title: Re: Ultraprune merged in mainline Post by: finway on November 28, 2012, 02:35:17 PM Apparently you had an unclean shutdown, and lost a data file. The debug.log is full of errors from LevelDB missing files. I think you are right, i had an unclean shutdown (Window 7, power off).This is interesting. First, it should complain much more loudly (like trying to recover, or exit with a fatal error). Secondly, this shouldn't happen... as far as I can see, there wasn't even an attempt to write to the blockdb. Did you copy the datadir from one system to another, or did your OS crash? Never mind, i'll reinstall. Thanks for your time. Title: Re: Ultraprune merged in mainline Post by: Diapolo on November 28, 2012, 02:52:45 PM @sipa Can you think of a cause, that leads to a massive spam of ORPHAN BLOCKS with current master during an initial chain sync in testnet?
Could that be caused by a BitCoinJ:0.6-SNAPSHOT/BC vend server:1.0 node somehow? Dia |
