The disconnect here is that you're talking about "lasting harm" in the context of the network.  If I get one confirm, give you the keys to my car, you drive off and the blockchain reorganizes so your payment goes someplace else (due to double spending on another branch)— lasting harm was done by any sane measure.

If you wait long enough then you can make the risk arbitrarily small, though the buyers risk starts increasing with too much delay and large delay aren't always tolerable.   

If the network is more concentrated (lower latency, longer block intervals) then it is less likely for someone to pull off an uncertain low depth attack because there will be fewer instances of multiple forks with a non-trivial survival chance.

 

It's called nolisten (or simply not forwarding the port…). Or more aggressively, "connect" though that should really be a trusted node since it makes you more vulnerable to misbehavior by your peer.

Please don't add anything more damaging to the network than that, we've already been having problems due to the pre-.24 nodes.

Yes, a tribute to Satoshi:  http://blockexplorer.com/block/0000000000004c78956f8643262f3622acf22486b120421f893c0553702ba7b5

After wasting a good hour or two of my life arguing with the proposer I think I'm in a better position to talk about what he is and isn't proposing.

He's got a fetish for attacking bitcoin— after talking about this his next grand idea was to embed child pornography in the block-chain.

You're coming off as hysterical— and also factually inaccurate. The behavior hasn't be to "trim off anything less than .01", it's to not take change when the change was _entirely_ less than 0.01.

Rather than demonstrating to others the urgency of your point, as you no doubt intend, it may have the opposite effect.

Rest assured that anyone worth convincing already takes things seriously in general, adding a bunch of dire warnings is not helpful for your cause.

You won't get representative numbers right now—  you're running .24 (obviously, or you wouldn't maintain >100 connections) which means you're one of the good nodes which is feeding out the block chain to new and backlogged clients.

A significant fraction of the network is still on older versions which hang up on nodes trying to fetch the current blockchain, so the good nodes are taking an unusually large portion of the load right now.

A "change address" would do nothing useful except compromise privacy— bitcoin tracks transactions not balances.

You're seriously overblowing "a shitstorm of bad press". Did you know that some large US chains systematically incorrectly round sales tax? E.g. they always round up, and due to some strange coincidence their prices are such that they almost always overcharge the customer by .9 cents?  Yet it's never made the news.

In any case, one way of dealing with this would be for the coin selection logic to add more input to prevent the change from being smaller than 0.01, sort of like your "payment to yourself" but happening at the time of the transaction to prevent the dust from being created in the first place. Of course, this would require you to have extra inputs in your wallet to begin with, and I'd be willing to be that anyone noticing bitdust lost is running an empty wallet.

E.g.

(0) use the fewest inputs to sum to the output value (plus any desired or required tx fee) exactly
if that fails
(1) use the smallest inputs that sum to at least output+fees+0.01
if that fails
(2) use the smallest inputs that sum to outputs+fees and give
the dust up as additional fees

One of the crappy things about this however, is that the dust is still bad for your privacy— it tags which side of the txn was the change quite distinctly. E.g. if you have input 3.0123456, and you redeem it into {1.0, 2.0123456} then I know with pretty high confidence that you just spent 1 BTC and that the address that 2.0123456 went to was also yours.  This is a reason that it's good to avoid getting dusty inputs in your wallet in the first place.  It's like a marked bill.

Or don't.  I don't think this behavior should change, though perhaps the cutoff point should be reduced to the smallest fee.

Every single full node in the network must track and check all open outputs for all time.  The network should resist the accumulation of tiny outputs because allowing them increases the burden on the network substantially.

At some point it may become necessary to inhibit txn with very small outputs, in order to keep things expensive for the people trying to store childporn in the blockchain... so best to not increase the expectations now.

 

As I said in #bitcoin-dev:

This is a crap scheme which will burden every financial user of bitcoin which tons of crap data which is pointless for their financial transactions. Bitcoin users should aggressively block to the maximum extent possible (e.g. by refusing to forward transactions and blocks with large amounts of garbage data stuffed inside them). Anyone engaging in this crap should be forced to burn coins, by the network imposing minimum output sizes, thus compensating all bitcoin users by increasing scarcity.

The 'officially enforced' alternative chain scheme has nice O(1) scaling properties: One additional hash is added to each block to enable a practically infinite number of alternative chains. With that, people have no real excuse to fill the blockchain with garbage data.

Er. Well: Maybe.

The input selection is nearly deterministic. (or rather, it is deterministic if all your available inputs are at least 6 deep in the chain)

If it selects the same inputs, has the same destination(s), and same value it will be the same transaction (same TXid), and thus no double was attempted.

You mean all six slots?   (there is a 1x slot too).

I'm using all six with extenders, 16x ones on the 16x slots however. (less parts to saw!)

So, for SCIENCE (er, well, wallet code testing), I modified a bitcoin client to short-circuit IsMine, IsConfirmed, and the coinbase maturity check. Then I rescaned the blockchain:

    "balance" : 6848199.98999999,
    "blocks" : 136965,

50*136965 - 6848199.98999999 = 50.01000001

This isn't the same as lost coins— e.g. my client thinks it can spend the 1BitcoinEater coins. This is a count of coins that don't exist, at least as far as the wallet code is concerned.

The 1e-8 is the coin midnightmagic opted not to generate in tribute to Satoshi. The 0.01 is the fee midnightmagic accidentally destroyed in the process. (http://blockexplorer.com/block/0000000000004c78956f8643262f3622acf22486b120421f893c0553702ba7b5)

I'm _assuming_ the 50 is the duplicate coinbase from http://blockexplorer.com/block/00000000000a4d0a398161ffc163c503763b1f4360639393e0e4c8e300e0caec.

These coins aren't even recoverable with a magical ECC cracking and/or hash colliding machine, but at least as far as the wallet code is concerned they're the only ones.

The pool doesn't return the same work to each miner, of course.

It increments the extranonce field in the coinbase transaction for each getwork request.

The licensed code you're looking at has less logic because it's not unrolled.  Every hash operation probably takes 128 cycles (or maybe 64) because it reuses the same logic. Unrolled bitcoin engines complete 1 hash per cycle (and have a latency of 124 or perhaps 248 cycles).

It's very slow, by our standards, as a result.

The reason they made it so slow is what I gave you above: 1MH/s of mining is approximately equal to 1Gbit/sec of general hashing. Since no one but bitcoin miners wants >100gbit/sec of SHA-256 in a chip (or even >10gbit/sec, most likely), no one but bitcoin miners would bother creating a design which is able to reach those speeds.  

You could put many such engines on a chip, but they'd end up taking more space than an unrolled engine with the same performance, because unrolling eliminates overhead and eliminates idle logic between attempts.

-nolisten would be the best way to do this.

Right, this was what I meant.  Obviously the shipped binaries will need to be statically linked, alas.   Thats still no reason to leave everyone else statically linked.

You don't need autotools for this: just add another target "make static-dist", or whatever.

For me, on Fedora, the static builds fail because the distribution doesn't ship with static versions of pretty much _anything_ because the overuse of static libraries has been a reoccurring security nightmare.  So, really, for some people the failure to separate static and not static builds means that building simply doesn't work.

Oh, while we're talking about this— it was claimed upthread that bitcoin should already have -fstack-protector — I don't know about Ubuntu, but in fedora -fstack-protector is set via the default RPM cflags, and _not_ by modifying GCC.  If the same is true on ubuntu, then bitcoind doesn't have it.  Someone with ubuntu handy ought to compile the examples from that debian page and see if gcc in ubuntu is really providing the protection by default.



This is only the case for tight loop register starved cpu bound code.  Bitcoin is usually I/O bound.   I've been running bitcoin in _valgrind_  (which run most things things at 1/10th to 1/20th speed) and hardly notice any difference except while syncing up the blockchain.

I'm seriously doubtful that PIE is going to make a noticeable performance difference.  Also, the libraries on any system are all already fpic, and all the crypto stuff is already in libraries,  Moreover, there is a pretty easy answer to someone who wants more performance: use x86_64, which is generally true (esp for C++ code) with or without PIE.

It's probably worth mentioning that the default static linking defeats ASLR, ... which is probably a more important security enhancement than -fstack-protector.

The default build should probably not statically link— if you've got the libraries then you can dynamically link them.  It should also be compiled -pie -fPIE.

There appears to be good general hardening advice here: http://wiki.debian.org/Hardening

"Yes". Its for testing.


Though, at the moment the testnet difficulty is high enough again that its less useful for any kind of testing that requires mining.

It would appear that vanitygen is now the preferred tool of transaction spammers:

http://blockexplorer.com/tx/60d7988fd2bc22ce764f9651b20fc3e7418ab6ab57c7057a16dfedd22e837b11

Correct.

Here is a source for the skeptical: http://www.treasury.gov/resource-center/faqs/Currency/Pages/legal-tender.aspx

As with many things in law there is a fine distinction.  You can agree to contract for whatever terms you like and you are generally not forced to do business under terms you don't.  What legal tender is dealing with (in the US, in other places it might be different) are debts already created.

An effort to force people to accept USD when they don't want it would have preverse effects like not being able to sell tickets to events (wtf! you must let me in, here is USD!!) or other stupid things like "here is an armored car of pennies, give me your car now, I don't car that you only wanted to trade it for another similar car! Legal tender!"