Your claim is objectively false. If it were that important at all there would have been _someone_ to step up and maintain it. But there was none although we begged and begged and warned that it wouldn't go in without one.  Complain all you like about "deal breakers", — actions speak much louder than words.

You can achieve the same level of control using the console and listaddressgroupings / listunspent / createrawtransaction / signrawtransaction / sendtrawtransaction.  (Listaddressgroupings was part of the coincontrol patch, and I was willing to maintain it because it's all I needed to get the level of coincontrol functionality I wanted... I don't use the GUI)

This is a poor idea currently because only /actual developed/ demand for it are things like instant messaging, transaction source deanonymization, and timestamping— things which are would be done better without creating an immortal burden on all future users of Bitcoin by instead using payment protcols or an overlay messaging network (or both) (or in the case of timestamping O(1) cost for infinite use by doing it via the coinbase).  The applications where it would make sense are few, speculative, and perhaps won't ever be developed much less used.

It's not like its impossible to write non-standard txn now, you just have to get a miner to mine them— so please, if I'm mistaken point me to the virtuous usage of OP_DROP in the chain. Additions to the standard set should be based on established trial usage, not speculation.

As far as mitigation goes, if you were to propose that they only be standard in scriptsigs (allowing fast pruning) or P2SH, that they have a maximum of 32 bytes (as you did), and that SHA256(data) begins with 32 zero bits, and that they have a fee which is >= the mean in the last N blocks, you'd probably cut it down to harmlessness... because you would have successfully taken it away from most of the applications where it doesn't belong (except timestamping, which is probably the least bad especially if limited to scriptsigs), but I think that would be pointless because doing so also only leaves it for applications which are currently undemanded and non-existant.

Perhaps you need to speak more concretely then. What rule?
Any rule you can imagine could be met by a natural block gap. E.g. you set it to two hours. Then a natural two hour gap happens, and an attacker can create a chain killer fork that covers that gap.

No. They wouldn't. Nodes only propagate what they believe to be the best chain.

He would cut back one week, and create a fork with a bunch of consecutive timestamps.  e.g. 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3 ....

Then a new bootstrapping node would startup and see "1 1 1 1 1 1 2 2 2 2 2 2 3 3 3". Then it would hear the valid chain, and see "1 600 1200..." and think that it jumped.

Then any bugfix that changes the typical network behavior is a 'protocol change'. Not really a useful distinction, in my view. We're just arguing over defintions, which is a waste of time. The important point is that a fixed node is fixed without upgrading any of its peers.  Call that whatever you like.

Of course there would be, otherwise it would be a config option and not an RPC.

We do not have any 'dynamic risk' "last resort" mechanisms anymore: no safemode alerts. Checkpoints only get changed by updating the software.
Your reject-txn sounds like sipa's fork-mode patch.
0_o I don't consider that a midpoint at all. We'd first have to rename Gavin "Bitcoin Bernanke", but fortunately I know he's smart enough to not accept that job.  I don't quite see how making it possible for anyone who kidnaps Gavin to shut down bitcoin is an improvement over your million dollar scale attack, as I expect it would cost much less than a million dollars to do so...

You're imagining a honest shorter chain, and a dishonest longer fork that has a big timestamp gap. Lets reverse that:

Imagine the network is following your rules. There is an honest longest chain. Now I construct a dishonest fork timestamped such that the true longest chain looks like it jumped forward in time relative to to my fork. Either the whole network now rejects the honest chain on seeing my fork (bad),  or they only apply your rule only one way on reorg decision (e.g. only demand it when switching from a 'better timestamped' shorter fork to a longer fork) which would mean that a newly bootstraped node's chain decision depends on which chain he heard first (because the dishonest fork may have been the longest from his perspective until he heard the longer one) and as a result network can't reliably converge (bad).

I'm skeptical about the extra work comment... The amount of work needed to overtake the longest chain from a given cut point is _constant_: its the amount of work in the longest chain after that cut. Difficulty doesn't come into play.  Ignoring the timewarp issue, there isn't much advantage that can be gained by lying about the timestamps, and most you could get 4x per 8 weeks you cut. Go too far back and you need a really significant super majority to get ahead in a reasonable time... and the advantage is just the inflation you could create for as a factor of log4(your rate/network rate) from undercorrection with your correct timestamps during the point where your chain is 'catching up'.


When I initially read your message I misread it as asserting that sufficiently old stamped blocks should not be considered. I realize now I misread it, but since someone else might have:

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)