It means what it says... it matures in XXX blocks (starts at 120).  Once that countdown is done your balance will go up. The whole network produces 144 blocks per day on average, so it's about a 20 hour wait.

The anti-DOS rule is:

A 0.0005 fee is required if any output is smaller than 0.01 (not the sum of the inputs)  or if the priority is less than 51,000,000.
You calculate the priority as sum(input value * confirmations)/tx_data_size

If your change would be smaller than the fee 0.0005 the wallet is smart enough to give it up as fee to avoid the 0.0005 fee— but it's not generally smart enough to always pick the mixture of inputs required to avoid a fee and could be improved.  What it currently does is tries to find the smallest set of inputs that sum to at least your transaction value, first using only input txn which have 6+ confirms, then 1+ confirms (and your own zero confirm txn), then using unconfirmed inputs.

Enh, I dunno. Having to maintain a separately compiled fork is a hurdle.

Look at things like the deterministic wallet generator here that uses some crack ass and probably insecure novel cryptographic crap— most bitcoin users are insulated from insecure key generators, for the moment, by the fact that they can't import the keys that crap generates.    Not the most solid protection— but don't underestimate the power of the default.

But it's moot because the complain here is misguided...

I don't agree with his concerns here— merged mining is, in fact, the _cure_ to the problem he's worried about.  But your response is unreasonable and unfair.  Forking the client doesn't solve the problems with _other_ people throwing garbage in the blockchain which you are forced to store forever in order to participate in bitcoin.

Not quite—  You generate a normal block, then use your trust account to mine a trusted block right after it (especially easy since it's a minimal difficulty computation).  If someone else had beat you to the punch on the normal block it doesn't matter— the chain with the trusted block is the longest one.  So while the trusted block itself costs you coins it gives you a veto over the identity of the generator of the prior block.

It's even super extra special if you're the operator of this system— because the fee in the trusted blocks goes to to operator, so once he's extracted out the few hundred thousand in surplus coin those pre-mined accounts were equipped with he can simply recycle their fee and maintain them (and their ability to control the winning chain, and thus who the normal block coin goes to) indefinitely.

Still— the point remains, you can't get away with a six digit numeric pin here...

The phrase "double spend" is highly misleading, I wish it weren't the common phrase for that attack.  It would be better if we called that attack "reverse and respend":  What someone with a super majority hashpower can do is spend some coin with you, then after its deep enough in the chain that you trust it to be permanent (e.g. at least 6 deep) they release a new chain which starts before your txn was confirmed but spends the same coins someplace else.  The new chain must be longer than the current real one... so to do this with any reliability they need >>50% of the total hashpower.  So effectively they reverse one of their own payments to you by redoing the bitcoin transaction history so the funds when somewhere else instead.  The total amount of coins is conserved.

There isn't any majority voting on the rules. The rules of the bitcoin system are fixed in every copy of the software. When you change them you don't change bitcoin, you create an alternative chain, effectively... because the two systems won't talk unless their rules agree.

Of course, if ~everyone changed their software than things can change— but it's silly to claim that this constitutes a lack of immutability of the rules. After all, if I made an interface to paypal with a bitcoin logo on it, and convinced everyone to change to that you could hardly say that I changed the bitcoin rules or hold bitcoin accountable for it.

If you wanted to introduce a signature scheme which was much faster but which required more storage, then offset that storage with improved pruning, why not hash based signatures (lamport or similar tree analogs)?

They are quite fast, have fewer security assumptions than other signature schemes (other signatures also become insecure if H() has the same weaknesses which would break lamport), an intuitive security proof, and are strong against proposed QC models (regardless of the real merits of QC attacks, marketing garbage is making the public think that QC's are already a real thing and the true but misleading assertion that bitcoin would fall to some highly hypothetical very large QC is harmful to public confidence, though I don't have a real feel for how harmful it is generally but "OMG QC's break bitcoin" shows up in IRC ever other week or so).

Lamport signatures also allow distributed storage of signature data. You can forget parts of signatures over time at random but still use them for lower confidence validation of the signature, you can also partially validate them for a big speedup.

Consider this attack:   I have the ability to isolate the network connectivity many different nodes and I can pretend to be all of their peers (this isn't an especially hard attack— e.g. it's one people at large ISPs can pull)

I make a one time investment to fork the chain someplace after the highest of the currently used checkpoints, and mine enough blocks to get it down to a difficulty I can sustain on my own.  Once I've done this I can isolate fresh nodes and get them onto my fantasy chain (the fact that it's the sum-difficulty used for comparison is irrelevant because I've isolated them) and I can trigger their prudent must-have-n-confirms behavior before considering a txn safe.

Say I need to reduce it by 1024x to get it to where I can mine it on my own (which is about right, 1/1024 puts 10GH at ~11 minutes/block).  This would currently cost 134,268.75  BTC (the simple forgone income from the same amount of computation: 2016*(50/4^0) + 2016*(50/4^1) + 2016*(50/4^2) + 2016*(50/4^3) + 2016*(50/4^4.)).

If you switch to a sliding window with the same overall behavior your change clamp at each block will need to be at 0.25^1/2016.  You would still need to mine ~10080 blocks but total cost would be 72615 BTC because of the far fewer blocks calculated at the 'too high' difficulty.

So it would ~halve the cost of this attack.

The clamps in bitcoin are what make these attacks costly,  but the clamps also represent exciting non-linearities in the payout of the system which miners could exploit for increased profits.  The fact that the clamps are hard to reach currently makes it a non-issue, but with a sliding window the clamps would have to be very near a factor of 1.0 to preserve the resistance to these forged chain attacks, so the system would almost always be operating in the non-linear region.

Tightening the clamps to keep the attack cost the same would only worsen the non-linearity.

Moreover, (ignoring the screwed up calculation) the window plus node timestamp enforcement (the limitation against blocks from the future) limits the maximum gain miners miners can get from lying about the time to a couple percent.  A sliding window would make this worse because it would provide an incentive to lie for every block, and not just the final ones in a cycle.

People need to stop fixating on weirdness in other chains which are more or less irrelevant for bitcoin and realize that the design of bitcoin isn't an accident. Every one of the features of the distributed algorithm has a complicated relationship with all the others.

No, not really.   You still have to have a trusted part to hold the resultant derived key.   Meaning you can't use 2 of 3 to address  "one of my machines is compromised but I don't know which" since if you recover the complete key on the compromised machine you're screwed.

One thing I don't like about this but can't solve is that it changes the incentive structure for non-standard transactions.

Today if you try to issue a transaction that no one will forward or mine it just doesn't work and then you say "oh well" and spend your coin another way.

In the brave new OP_EVAL future, you spend coin to a script hash and then only later learn that mining the transaction spending it is difficult.  Instead of saying "oh well" you're out the funds until you can convince someone to mine the transaction... and you only discover this after your funds are tied up.

Presumably we'll be smart with the software and not allow the UI to issue transactions that won't work but I'm still concerned that this may increase the number of large burdensome transactions in the blockchain.   On the other hand, because only the input script will be large there may be some increased helpful pruning potential.

It might help a little if we made public key recovery (which we now have code for as part of Sipa's signing support) something that OP_EVAL scripts could use, at least scripts spending "must provide four signatures" wouldn't be quite so large.

Er!!! the downward side clamp is essential for security.

E.g. say the difficulty is a zillion and I want to mine a fantasy fork in order to trick clients that I've isolated into accepting txn that will never be confirmed on the main network.  I wait until near the end of a cycle at current difficulty pushing the timetamps into the future, ... when the adjustment happens on my fork if there is no limit the new difficulty it ends up pretty low and I can then maintain that fork in realtime for as long as I like.

With the limit it would require me mining tens of thousands of blocks at high difficulty to produce a valid chain at a difficulty I could maintain.

This still leaves evidence: Mybitcoin could provide a copy of their blocks file, which would still contain the orphan block even if no one had it.

It's evidence which could be faked, but only at non-trivial cost.

This is all well and good, and also completely meaningless.  If thats what you want to do, then just do it. You don't need any support from the software.

Perhaps you're under the impression that bitcoin will forget about older addresses that it has given you after it gives you a new one? That isn't the case. (I'm just guessing wildly, because I can't figure out what you're thinking). All addresses your client generates will be remembered forever, any other behavior would lose money.

Because of the inv process relaying takes very little bandwidth. We're talking about a grand total of a few kbit/sec. Even with enough transactions to cause a maximum blocksize it isn't much bandwidth.

The relaying also improves security by more broadly propagating evidence of transaction activity (even if no one is currently doing much monitoring).

Most importantly, perhaps, is that it allows nodes to see incoming transactions before they are mined and it allows them to do so without constantly disclosing the identity of the keys they hold.

This is an area were lightweight nodes could probably be more lightweight, but I don't see any advantage in changing this for full validating nodes.

No. It's not correct, you've used floating point and suffered from numerical precision problems you also started at the wrong point, as you noted. The first block is trivially found, its coded into every copy of bitcoin. http://blockexplorer.com/b/0

Assuming the precision of bitcoin is not increased:

python one liner
print "".join(["%0.8f %d %0.8f\n"%(5000000000/2**x/float(1e8),(x+1)*210000,sum([5000000000/2**y*210000 for y in range(x+1)])/float(1e8)) for x in range(34)])

50.00000000 0210000 10500000.00000000
25.00000000 0420000 15750000.00000000
12.50000000 0630000 18375000.00000000
06.25000000 0840000 19687500.00000000
03.12500000 1050000 20343750.00000000
01.56250000 1260000 20671875.00000000
00.78125000 1470000 20835937.50000000
00.39062500 1680000 20917968.75000000
00.19531250 1890000 20958984.37500000
00.09765625 2100000 20979492.18750000
00.04882812 2310000 20989746.09270000
00.02441406 2520000 20994873.04530000
00.01220703 2730000 20997436.52160000
00.00610351 2940000 20998718.25870000
00.00305175 3150000 20999359.12620000
00.00152587 3360000 20999679.55890000
00.00076293 3570000 20999839.77420000
00.00038146 3780000 20999919.88080000
00.00019073 3990000 20999959.93410000
00.00009536 4200000 20999979.95970000
00.00004768 4410000 20999989.97250000
00.00002384 4620000 20999994.97890000
00.00001192 4830000 20999997.48210000
00.00000596 5040000 20999998.73370000
00.00000298 5250000 20999999.35950000
00.00000149 5460000 20999999.67240000
00.00000074 5670000 20999999.82780000
00.00000037 5880000 20999999.90550000
00.00000018 6090000 20999999.94330000
00.00000009 6300000 20999999.96220000
00.00000004 6510000 20999999.97060000
00.00000002 6720000 20999999.97480000
00.00000001 6930000 20999999.97690000
00.00000000 7140000 20999999.97690000

(make up your own dates, — any dates are going to be somewhat approximate)

You're misunderstanding a bit how it works.  Most transactions don't need to pay a fee at all— but transactions that appear to be indicative of a DOS attack based on a simple objective criteria need to pay a fee or most nodes will simply drop them (they won't disconnect, the anti-flooding stuff is totally separate).

It works like this,  take the value of each input and multiply it by the number of confirmations it has. Sum that and divide by the size of the txn in bytes.   This is the transactions priority.  If the priority is less than a typical 1 BTC txn aged one day would have, then the transaction is low priority and needs a fee. Additionally transactions with outputs smaller than 0.01 need to pay a fee, just to make open-transaction bloating attacks more costly.

This way, holding the coins itself is the "proof of work" that shows you are probably not attacking.  It's a simple objective measure that can't really be gamed (except by simply using enormous amounts of bitcoin in your attack) and which doesn't require any additional communication or coordination between nodes and doesn't care if you connect to one node or 100.

It's not really about "spending money that haven't been confirmed they own yet" it's that people trying to DOS attack bitcoin produce transactions which look exactly like that:  They take some large amount of bitcoin and rapidly ping pong it between a series of addresses, or they take tiny amounts of bitcoin and mass broadcast it two and from many addressses, or something in between.

The 0.0005 (currently about a half cent USD in value) fee is required in cases when the system can't automatically distinguish your transaction from a DOS attack and so it wouldn't forward it.  You can avoid it by simply letting the inputs in your wallet age, also, when you can— try to get payments in bigger chunks rather than lots of little tiny ones. (like avoiding pennies).

FWIW, I may be filing a patent on this, so I'll report back if I find anything problematic.

If I do so, I will be offering it under terms no more restrictive than the Xiph.Org patent license: https://datatracker.ietf.org/ipr/1524/  (e.g. a free license to anyone who doesn't conduct patent litigation against bitcoin users)
 

By making the block time faster the risk from shorter confirmation or the number of confirmation needed to reduce risk is increased. This is a cost to all bitcoin users, especially since its users can suffer from the loss of confidence in addition to the loss itself.