Please do me the respect of reading my message above where (in the last paragraph) I explain how to solve this, in a way which isn't a fork or a rule change at all... just a minor difference in the order of operations when fetching and checking a chain. While I didn't include an actual implementation, I provided pseudocode of the algorithm detailed enough to propose attacks against.  It isn't a new idea: this whole set of issues has been discussed many times before and so far no one has yet pointed out why what I suggest wouldn't make it mostly a non-issue.

Right. Because of the timewarp attack an attacker who cuts >2 weeks back (more is better, of course) can make a chain with interleaved past timestamps which reduces in difficulty no matter how much hashpower he's throwing at it (if anyone is interested in this attack, I performed it on testnet3). Of course, if he doesn't have a majority of the hashpower his chain won't be the longest; so it's moot except as a flooding DOS against nodes with the full block sync behavior.

It's possible to do a little more aggressive timestamp sanity checking to largely close that behavior... but it's hardly an attack if nodes first check header difficulty before pulling a chain.

I feel fairly leery about this. In terms of the general baddness, having nodes on mutually inconsistent forks, _regardless of the details_, is actually much much worse than just about anything that can happen short of some kind of long sustained attack (which can't be fixed by adding checkpoints if it really is sustained).  The ability to add a checkpoint is basically a big footgun because it sounds pretty attractive in the short term or with simplistic analysis (ignoring what happens when everyone else doesn't do the same thing as you).   Basically, getting a transaction finney attacked on you _sucks_ and there surely would be a temptation to try to go around and convince people to set some checkpoint to undo it. Perhaps you might even get some friends to join some co-conspiring network to coordinate it a bit and allow you to pay the participants ala GPUMAX (introducing an ugly bit of central control if it grew to a relevant size). But actually getting enough of a majority of hash-power onto it would be very hard... and as bad as your finny attack is, the currency being split in two for potentially days or weeks as this is resolved would be much much worse to everyone collectively (though this is mostly an externalized cost that you don't care about when you start the snowball). And if it _isn't_ hard to get the hashpower onto it, then it really is a highly vulnerable central point of control itself.

We think and work so hard to make sure that any BIP rule change we'd introduce doesn't carry the risk of triggering a hardfork... An addcheckpoint RPC could just as easily be called addhardfork.

And the PPcoin results convinces me that there is a fairly substantial part of the community that doesn't really grok decenteralized systems— and that they would use a checkpoint RPC foolishly if given a chance, especially if guided by leaders that don't understand the technology themselves (e.g. people who run justly loved services, but understand bitcoin poorly enough, or are indifferent enough to it, to pick the worst transaction styles for scalability)— since with PPcoin people are willing to pay a premium for coins which are checkpointed block by block by some anonymous authority (I mined a bit and even had one of my blocks orphaned by one of their centrally controlled checkpoints!).  Perhaps, because of this reality, bitcoin is already doomed to become a failed experiment— a modest money maker for the earliest participant but something that eventually becomes undifferentiated from all the rules-of-convenience based currencies, but I hope not.

As far as "any other possible patch" goes, I believe the correct (and really boring) solution to any all orphan/weak-chain flooding concerns, which doesn't depends on any checkpoints or other potentially risky compromises:   Select the best chain first based on headers only (very small! 10 years worth is under 50 MB), then only switch to a second best if the best fails validation. I wrote about this sometime back, and originally suggested it somewhat earlier when roconnor went a bit fatalistic thinking that there was no way to produce a DOS resistant node without checkpoints. IIRC, roconnor was satisfied that header based chain selection was sufficient.  Though I haven't bothered writing any code for it, as I don't think it's actually important. For me it's enough to know that it's possible, without any incompatible changes, or especially difficult implementation.  This remedy would be greatly improved by either reducing the timewarp attack surface by making the timestamp rules slightly stricter, or increasing the min difficulty after some height to, say, 10000 (~irrelevant hardfork risk: only a risk if bitcoin fails), or both... but generally solves the problem even without those tweaks.

If you'd like to get in the business of proving things, you could start by demonstrating your honesty. You claim to be representing a large corporation but you will not disclose which, or any other information which could be used to seek remedy if your operation ultimately rips people off. I've previously stated that your activity is harming myself and other bitcoin users, and requested you have your supervisor contact me.

As far as I can tell you're just another scammy ponzi operator, but one that catches my particular attention because the pointeless high transaction loads you generate makes bitcoin slower for all its users.  But feel free to prove my position as paranoid…

Have you set irc=0 or listen=0 ?  I checked and there are a couple of listening hosts on IRC right now. So it should work for you.

Er. This doesn't split the database environment, so if its used as this thread is requesting it will almost certainly result in wallet corruption. (and leak wallet information as well).

You need at least one peer before you can learn of more over the network.  Right now the only way to bootstrap an onion-only node is manually.

I think this is the only bullet you gave for something you actually want it to do, the rest were just operating constraints.  For this purpose you could use vanitygen or any of a large number of other totally offline tools.

If you actually want to, say, detect the reception of transactions— you might want to look into bitcoinj.

Your 'experiment' is indistinguishable from many popular scam patterns and your way of going about it creates enormous transaction loads which slow processing for regular usage, for no discernible benefit to the bitcoin economy. The secrecy and constant invocations of an undefined 'us' are also typical characteristics of scam behavior. A uncharitable interpretation might conclude that the secrecy only exists to isolate you from the consequences of your actions. Real "big companies" don't post ponzi schemes on forums without disclosing their identities or their motivations. Technical testing doesn't require weird schemes and public participation, and responsible engineering starts by asking what is already known. I call shenanigans. On the off chance that you're not full of it I'd like to speak to your supervisor, feel free to send me a private message. My gpg key is on bitcoin.org.

There is a separate test bitcoin network available for testing, you can also fairly easily run a private bitcoin network. There is no need to spend money or load the production network to test— unless you're just seeking to test the gullibility of the community.

You can trivially generate transaction load on testnet or an isolated test network and many people, myself included, would be glad to help out with any legitimate testing initiative on testnet.

It was not intended to be a holier than anything response. It was the frank, honest reason. Why isn't it done?— because no one who wanted it done has done it, people doing things have considered other things more important. It isn't an idea whos usefulness had escaped attention, though that happens sometimes.

On the contrary, I could argue your tone here sounds rather holier-than, with your imperative "Please sort this out or show me a version of bitcoind that uses it already", and your essays on access, linked tables, and two line changes. .... but sometimes tone doesn't come across clearly online and I had no more intention of offending you than you did of offending me, I'm sure.


You can only switch between the files when they've been cleanly closed. Desync of the wallet.dat and the other database coupled with an unclean shutdown results in database corruption which can not be automatically repaired.

Not an argument against it, as I said I think it woudl be great (personally I'd use it to have wallet files on more reliable media than the block databases), but a walletdir is far outside of a "most mortals" feature in any case. As generally is plausible denyability. I'm always a little weary about brittle security: People are better off not having denyabilty and knowing they don't have it, then they are not having it and thinking they have it. Moving the wallet is a fine feature, but it does not achieve the goal of hiding bitcoin usage and shouldn't be advertised as such.

Electrum depends on servers to not lie to it about the existence or validity of transactions. You could learn over the network that you were paid a million bitcoin, but its all a fabrication. Worse, the value of your transactions could be _understated_, causing you to sign transactions when you spend which give away all your coin into fees (which then the attacker would presumably mine themselves to collect). These attacks don't require any computing power, they only require that your software is talking to the attacker.  Electrum gives security similar to a JS web wallet, except it has the improvement that the operator can't swap out your client code right from under you.

Yes, and I asked you to see the other thread for the workaround quoting pattern for the debug console. Diapolo provided the quoting style for windows here— you didn't specify what OS you were on before.  I tested that on RC1 just for you.

Because you haven't submitted a pull request for it, of course.

As Pieter points out, it's not a two line change at all.

And although it would very much be a welcome feature I think you're overestimating it's usefulness. It's quite hard to hide the evidence of a second wallet on a partially encrypted system— shell history, log entries, etc would point to the location of another wallet. We have integrated encryption already for basic security, and the concept of a not-online wallet really requires the not online-wallet be actually not-online— trojans/malware/and compromises will _happily_ steal your displaced wallet when you _do_ access it, as it's absolutely trivial to just watch the bitcoin process and take whatever wallet it accesses.

I find the admonishment to use electrum in response to a message apparently concerned about security to be quite perplexing. Electrum is useful and interesting software, but it has a _much_ weaker security model.

0_o

I certainly hope people are not exposing the bitcoin rpc port to the open internet.

Works fine for me:
Feel free to sign and submit if you have any doubt. (though I don't seem to have that input in my mempool or blockchain)

There is a quoting bug with the debug console, see page 2 of the 0.7.0rc1 thread for details on a workaround.

Bug in the release notes.  You want getrawtransaction <id> 1

No, it doesn't. On mainnet it will begin with a 3. Clever notion, but the way address versions work that wouldn't really be possible.

It's just a typo in the page, the output of the client is correct:

Running two instances is no big deal. I have six on some machines. Of course, if you don't _need_ multiple ones then you'll save space to run run multiple ones.

Give each one its own datadir and tell it about it on the commandline. In each datadir put a config file, make sure you set the port and rpcport to different values on each. They _CAN NOT_ share the same datadir.  You can start off multiple copies by copying an initial one, however, but you must run with the detachdb option and shut down cleanly before copying if you do that.

Have fun.