Because they can be made not a security risk by the construction of a proper testing framework which can validate them. Most of the opcodes can be exhaustively tested, except for the ones that do crypto operations because the input spaces are too big, and those can be exhaustively tested by converting them to dummy versions with smaller input spaces (e.g. all even valued sig inputs validate as passing, all false fail).

If/when someone does the work to create such a testing framework and uses it to validate the opcodes, I think that would be a good argument for re-enabling them.

Hm.

How about this:

I'm A, I want to pay one btc to B with fast validation.   I have a preexisting relationship with C, and B has a pre-existing relationship with B.

I give C a signed transaction with an nlocktime somewhat in the future, covering the the amount, any fees C is charging me, and any BTC txn fees.  C gives a similar open transaction to B.    

If there are more exchanges between any of the parties we replace the transactions with updated versions that reflect the new outstanding balances. All of the is hidden from the blockchain until the locktime runs out.  After some time has passed without any changes, the lock time arises and the latest version of the transactions are published, settling the accounts.

A<->C can settle independently of B<->C.

Parties are vulnerable to double spending of the committed funds, but thats why they have a pre-existing trust relationship. They are assured that their activities are backed by funds their trusted peer has— at least fractionally (in the case of double spending).

This obviously works when C is a chain of parties too.

Now the fun part is working out the bitcoin script commitment so that the bitcoin transactions are only valid when an IOU exists, so that if C tries to cheat A by reducing the reducing A's balance via an IOU payment, but then settles using the old open transaction instead of an updated one, that A can prove C cheated by presenting the sequence of IOUs.

Sorry, — I shouldn't post at dark-am when I should be sleeping. The mixed case threw me, I saw that a was the initial private key and thought you were saying you were using it in the hash and I stopped reading. Sorry.

I'd need to see a more concrete version of the chain version. The simplest implementation with just H(prior-key|type|serialnumber) would be insecure because the serial number would not have enough entropy. e.g. I'd generate two addresses keys on your site, getting sequential serial numbers, then I'd send money to both and wait for you to spend it and disclose the public keys in the process,  then I'd search the space of likely serial numbers such that one address leads to the next.  Then I can generate all future public addresses.

In ten seconds I see a way to address that, but there may be a better one.

It seemed to me that the lack of cheap random access was a bit of a liability, but if the chaining variable is simply the prior key or address which you'd need to cache in any case to identify transactions, then this would be pretty good.

You're making a mistake of thinking about the mining process as primarily a mechanism for the initial wealth distribution.  This is an incorrect way of looking at it and it will lead to confusion.

The bitcoin hash chain embodies an attack resistant distributed algorithm for determining a consensus ordered transaction log which does not require a central authority or any trusted parties at all.  Difficulty is an absolutely essential part of providing the attack resistance, as is the average time between blocks and a multitude of other interlocking factors.

Mining, the process of extending the transaction log,  will continue / would be required even if there were no new coins being distributed.  

Initial wealth distribution has to happen somehow— and the absence of a central authority limits your options considerably: mostly you're left with lotteries of various kinds.  Linking it to mining had the dual benefit of promoting the system security early on, and taking advantage of an already existing lottery infrastructure.

So, in any case, you can't just change how difficulty works without completely reworking the system, and your desired tweaks may not be directly compatible with the behavior required for system security.  In which case, proof of work to create your bonds would need to be decoupled from the core blockchain process, which would inevitably distract from system security…

You've missed a whole use case here:

Say I want to run a webserver that accepts paymets. It needs to be able to generate addresses, but if it gets hacked, I don't want the hacker to be able to spend any of the incoming money.

By splitting the master private key and the seed used to generate the addresses, a RX only wallet can generate unlimited new addresses without having the ability to spend or any required communication with a separate secure wallet that can spend.  An attacker who stole the data on the webserver could only deanonymize payments.

Thats why I proposed it with a separate seed.

Perhaps not important for all uses, but pretty useful for this ecommerce one.

Hm. Yea, I've been pretty skeptical of ripple in general, but backed with bitcoin and automatic true-ups (why not settle frequently?) that seems like a pretty compelling combination...

I liked the proposal where here where the secured transaction is exposed to the fast network rather than just using the blind IOUs of ripple(Edit 2013: Ripple's name was sold to a new, largely unrelated system).  Trust for someone to not double spend funds that they appear to have is quite different from general credit. Though it could be done in some other way where the unspent bitcoin balance secures the ripple activity, without actually being turned into a bitcoin transaction (still allowing transaction hiding to reduce the load on bitcoin). But there might be interesting privacy challenges with that.

Now mix in something namecoinish to have persistent bound identities to hang trust on...

Congrats, you've invented Ripple: http://ripple-project.org/(2013 Edit: The ripple name was acquired and the new ripple is nothing like the old ripple. Any comments I made about ripple prior to Feb 2013 apply to the old system.)

I hadn't considered using it this way. I think thats very cool

But what it doesn't do is reduce the block-chain volume of transactions for small payments.  In a world where bitcoin is being used for POS that kind of transaction hiding is also valuable. Bitcoin's security comes from the fact that everyone sees everything.  That kind of security is justified for the whole wealth of the world— not so justified for soda-pop transactions.   We can usually trust centralized institutions enough to handle our soda pop purchases without funny business.

So, really I think you've added something else useful to the ecosystem of ways to address fast transactions:

(1) Wait, don't do things fast.
(2) Take a risk
(3) Use a third party insurance service who uses good network visibility and miner relationships to gauge risk and have them approve it.
(4) Use escrow transactions to bind funds to a third party approver who is trusted not to sign double spends.
(5) Use a classic centralized processor that you keep deposits with. (this will be essential early on as we still need to interface with classic payment networks). Also has the huge advantage of hiding its internal transactions from bitcoin, all the network sees is periodic settlements.
(6) Your ripple(see edit above)-esq solution

I expect that all of these things will exist in various places, at various times, and in various mixtures. (In some ways, I guess your solution is a distributed version of (3)) Diversity is a good thing.

From recent discussion on bitcoin-dev:
(7) When a node sees a second transaction trying to spend an input which is already used by an in-memory-pool transaction (attempted double spend), it generates a double-spend-warning message per affected input which identifies the first two observed transactions using this input.  The warning is flooded (and validated by each node), and can be used to reduce the risk in option (2) above.

Because "a more sophisticated control system" inevitably means non-linear which leads to various attacks and perverse incentives, like mining in bursts being more profitable than mining continually.  Under the current system the only non-linear behavior is the clamps which don't happen unless someone is bursting a significant multiple of the network average rate, and with that much hash power they could have been been mining more profitably by just mining continually.

(Eventually there may be incentives to mine in bursts due to fees, but it seems likely to me that the incentive to do that goes away as soon as there is any with-fee backlog at all, orthogonal in any case— if the system commonly operated in a non-linear region there would always be incentives for these sort of games)

...Add this to the points I made about a faster system opening up many kinds of attacks.

Sometimes I wonder what kind of god Satoshi must be to have foreseen so many issues which are missed by so many other obviously intellegent people…

The longer cycle prevents a number of attacks.

What you've described is rather costly and fairly modest DOS attack at best, its damage is limited by the difficulty change clamping, it's not profitable for the attacker beyond "disrupt bitcoin", and it exists outside of the security model of bitcoin in any case.

The expenses is a key factor: If you have the tens of millions of dollars of specialized hardware to outpace the whole bitcoin network by a significant fraction, why wouldn't you mine profitably using that power— and if you are mining profitably then breaking bitcoin is not in your interest.   If you're the sort that doesn't care about bitcoin profits (perhaps some government gone crazy) then there are far less costly attacks against bitcoin available to you (DDOS, writing laws, negative PR campaigns, hiring ninjas to kill developers).  These attacks are likely to be far more effect too since the difficulty changes are clamped to 4x per cycle.

The most easily understood attacks that the long cycle prevents are ones related to manipulation of difficulty by miners via lying about the time.

Attack 1.

Because of the various physical realities of the world, we can only expect participating nodes to have approximately the same time. Because the chain splits when nodes disagree if a block is invalid, perhaps irreparably so depending on the nature of the disagreement, it's critical that any block validation be globally consistent.   So we need to allow considerable slop on any blockchain time validation.  The shorter the difficulty cycle is compared to the allowed time slop, the more lying miners can fake the difficulty, and thus artificially speed up the rate of inflation.    Right now, they can only shift it by two hours out of ~two weeks. Which isn't that much.  

Attack 2.

An attacker with some hash power, but not a ton has gained complete control of your network connectivity into the bitcoin network (perhaps they've compromised your ISP,  or they're performing a sybil attack against the whole network.   In any case, they're able to partition you.

In the worst case, you've been offline for a while and need a bunch of the block chain.   In preparation the attacker has been mining a fork of the blockchain starting, perhaps, from the highest hard-coded checkpoint in the popular client software (or otherwise, if they know what you last heard). They're off on their own doing this.  They mine out the rest of that DIFFCYCLE setting the timestamps to cause the greatest reduction in difficulty they can.  They continue to mine, setting the time to result in a 4x reduction in difficulty each cycle.   Every cycle of blocks they mine their work gets four times easier.

Eventually they get down to a difficulty low enough that they can easily produce one block per five minutes, and guide their timestamps back in line with reality.

Now you reconnect, they feed you their fabricated chain, proxying over transactions from the real network.  Other than discrepancies in the block number, which joe-user won't notice, you can't tell that you're on a fantasy chain.  Because they control your network you won't hear about the real chain.  On the fantasy chain they can respend transactions that were spent elsewhere on the real chain, they can also cheaply reverse and respend transactions given to you at will on the fantasy chain, since they can easily mine forks on it.

With the long diffcycle this attack is prevented by two mechanisms: The long cycles mean that you must perform a enormous amount of work in absolute terms in order to drive down the difficulty at all.  Unless you have enough hash power to challenge the whole network this will take you a very long time.   Before a very long time has passed, users will have either heard of the more of the real longer chain so your target is constantly movin, or they will have noticed that bitcoin has gone weeks without working, and updates to the bitcoin client will have moved forward the furthest point in the past at which you can split the chain.

All outputs must be at least 0.01 or you'll need a 0.0005 fee for the transaction.

If you want to make transactions that pay less than 0.01, then you ought to use sendmany to make a single transaction with many small outputs at once and then pay only one fee.

Without the anti-DOS behavior imposed by relaying and mining nodes, a single system of mine could saturate the cpus of just about every client in the network, and in in a week add a gigabyte of data to the blockchain that every client must currently download, store, and process.   Go spin up a miner on testnet with the fee rules disabled. You'll see it spewing 1MB blocks as fast as it mines them.

The fees are less than a penny in value (unless you're running old software, stop doing that!), which is pretty cheap for an operation which will be saved forever by all full nodes of bitcoin— and are only imposed against transactions which objectively look similar to attack patterns  (very tiny outputs, quick turnarounds, and or/lots of data).

As far as the 0.38 transaction goes:  Either it's comprised of lots of 0.01 inputs, in which case, it's taking a kilobyte of data to represent, thus getting subjected to a fee.  Or it's a quick turn around of an input that just landed in the wallet.  If it's the latter then simply waiting a bit (a day or so most likely) will make it work fee-less.

The bitcoin software tries to use the oldest inputs available to make new transactions (in order to get the highest priority),  but if coins which just landed in your wallet are all you have then thats what it will use, and your activity will look too indistinguishable from an attack where someone is ping-ponging coins between wallets quickly for the system to allow it without a fee.

It's never "non-profitable to mine" due to excessive computation, not as long as people are still using bitcoin at least not for everyone.  The difficulty of mining will adjust so that the same amount of mining (in terms of blocks created) is happening no matter how hard people are working at it.

(Now, in the far future the income from mining might not be enough to provide adequate security, which is a concern, but thats not at all the same as there being no mining.

Congrats: You're probably less screwed than you think.

When you load it on another machine, do a rescan, then wait a while while the machine thrashes and rescans the block chains up to the current network position. When you load a wallet on a machine with a more recent blockchain, you usually need to trigger a rescan to make it find transactions.

"doesn't load anything" is unlikely even with a somewhat out of date backup, instead an out of date backup will usually show some of your balance but not all of it— and If you were not doing more than 100 getaddresses / sends per week then your backup should not be out of date.

If this doesn't fix you, then it still might be possible to recover your coins from the db log files in the bitcoin directory on the machine that broke. Make a backup of the whole bitcoin directory— block chain and all just in case.

Even if we're not able to help you get your coin back— we should still dig in a bit to the specifics of your loss— like why didn't your backups work, so that better advice can be given in the future.  After all, you were backing up, and for many users weekly is more than enough.

The software shouldn't have let you make a transaction which had very low chance of near-term success.  Perhaps you've found a bug?

Something is wrong with your system.  I sync the full block chain onto a lowend SSD here on an old 2.3ghz cpu in about 35 minutes and then the system is much pretty idle.   You haven't provided much information: What version of bitcoin, what OS, what system, etc?

The rate of block creation has nothing to do with the reward.   This is the sort of thinking you end up with when you're thinking of mining as primarily a method of distributing the initial wealth— thats a wrongheaded way of looking at it.

The nakamoto hash chain is an attack resistant solution to a version of the byzantine generals problem. In our case nodes communicate over a lossy channel with unknown and sometimes high delay in the face of aggressive agents who may try to disrupt or impersonate the communications, and they want to come to some consensus about the past history which is backed by a resource which is difficult to obtain.

The hash chain allows any observer to figure out which transactions have been approved by the largest clique of communicating hash power.  If the blocks were to be generated faster than the communication between the miners,  then most of the hashing effort would go to waste as blocks are randomly orphaned. Rather than a long straight chain with knots here and there, you'd have a bush as hashing power is spent on lots of parallel dead ends. Basically, for the purpose of the algorithm nodes which can't communicate within the time between blocks aren't communicating, so they can't be part of the same largest clique, so the hash power of the network is divided.

An attacker who used a modified strategy of "always extend the near longest chain which contains most of my blocks"  would have an advantage over the rest of the network following the normal rules, and would be able to control the longest chain without having as much power.  Also, transactions near the boundary would be continually flickering in and out of blocks differently depending on where in the network you were located.

Faster blocks would also increase storage requirements for lite clients drastically, basically a 100x increase for your proposed 600 blocks an hour. Satoshi was already concerned that bitcoin's storage requirements would endanger its success. I think he considered 5 vs 10 minutes and eventually decided on 10, but I doubt he would have even considered much faster.

Wow. Cgminer has been coming along nicely!

Any plans for pool load balancing / redundancy?   Diablominer has load balancing, poclbm has failover. Both are nice for different reasons.

Load balancing is good because mining against multiple pools concurrently lowers your variance, reduces the concentration of hashing power to large pools, better tolerance to TCP head of line blocking (e.g. when a connection loses some packets and ends up stalled for a long time), and loses less time during a failure (because you already have current work for multiple pools).  The additional pool load is justified by the fact that the miner is pooling multiple cards (where older cards were one card one connection), and efficiency enhancements like ntime rolling.

Failover is good because all options are not always equal:  I might strictly prefer to mine for a medium sized cheating resistant pool, assuming its up and working correctly, and failing that mine for some large proportional pool,  and failing that mine solo, because solo is better than sitting idle or generating many minute stale work which is likely to be rejected by any current pool even if it isn't for an already orphaned block.

The obvious way to configure for both of these would bet to have lists of lists of RPC URLs:

{
  {"http://pool1/","http://pool2", ...},
  { "http://localhost..."}
}

and some timeout setting to consider a group failed when there hasn't been an updated prev or merkle root in N seconds or if all the TCP connections are closed, beyond with it fails to the next group.

Because any SHA256 engine created for a purpose other than mining would be pitifully slow.

In terms of SHA256 computation,  1MH/s ~= 1Gbit/sec of SHA256 computation.   Why would anyone need chips that do much more than 100gbit/s of SHA256... and more importantly, why would they need them at price points that would make them attractive for mining?

As a result, any pre-existing sha256 engine may have good density, or good power consumption— but it won't have good performance from our perspective.

This is what sendmany is for. I highly recommend you use it: You can pay many people with a single transaction, and a single fee (if required).

What is sounds like is happening in your case is that the change from the first transaction is being respent right away, and respending right away is a DOS-attack-like behavior (e.g. an attacker would ping pong coin rapidly to generate traffic). Bitcoin should normally avoid doing this— preferring to use older inputs, but if there aren't enough other inputs in the wallet to satisfy the payments without using the fresh change then it will use it.

If e.g. you have a single 50 BTC input in your wallet and you've been sending out 1 BTC payments you end up with transactions like  50->{1,49} ; 49->{1,48} ; etc.    So if you simply do a send of 50 to yourself: {10a,10b,10c,10d} to break the input up, then the software should instead prefer to spend 10a->{1, 9}; 10b->{1, 9} rather than reusing the change right away and probably avoid the fees.

Either of these cases should be sufficient to avoid the fees in your case, and the sendmany puts less load on the blockchain as well.

Care to share an example transaction so we can see why?

I can only guess you're making payments with outputs smaller than 0.01 BTC?

Right. This is my point.  There is no minimum fee:  I, and a great many other people using unmodified .24, send zero fee transactions all the time.  Thus: The minimum fee is zero.

If you went to a car lot shopping for used cars, would you say that there is a minimum fee of $90,000 because thats the price on some of the cars?  No.

It doesn't help that we've used some fairly confusing terminology in the software, we should be more careful about that in the future. But it still doesn't excuse people claiming that there is a minimum fee. :-/

If you don't want technical details — thats fine.   "There is a particular fee required for transactions that look too much like a DOS attack to the system" is an accurate statement.  "There is a minimum fee" is misleading and contributing to poor health of the bitcoin network by causing people to stay on older versions.