Repeat after me: There is no minimum transaction fee.

and then:

Repeat:  The overwhelming majority of transactions are zero fee.

The software requires a for relay for transactions which the adaptive technical detection for DOS-attack-like transactions can't distinguish from an attack, and for transactions which are unusually burdensome (many kbytes of data).   The adaptive detection doesn't depend on the instantaneous network status:  Its can't easily because in a decentralized system there is no singular status, and if nodes disagree about the status the protection isn't effective (if its fail open) or it makes txn get stuck in unspendable limbo at random (if its fail closed).

Instead the adaptivity depends on the character of the transaction itself— it's value, the time since its inputs were last spent, the size of the outputs, and the amount of data used to represent it.   These are all factors which are directly relevant to a DOS attack because they objectively measure the effort it takes to perform the attack and the impact on the whole network of performing the attack.  This is a usable criteria because it's objective and can be acted on uniformly by independent nodes.

Above the cutoff priority txns are handled in a priority oriented manner which gives the soft "only messes things up if there is an attack" behavior that you seem to think we lack.   .... You only think we lack it because it actually works.   Unfortunately, the soft behavior can only work to a limited extent because in order to handle things in a priority order nodes must have first undertaken the non-trivial costs of storing and forwarding the transaction— so at some point the system has to simply say "No, I refuse to use memory for this, I refuse to use bandwidth for this". Otherwise the attacker can exhaust these resources even if non-spammish transactions always beat them into the blocks.  If the threshold at which transactions aren't remembered (which makes them _very unlikely_ to go through) is too dynamic then you'll continually end up with transactions which are stuck in limbo polluting your wallet, and potentially polluting the wallet of the receiver if they happened to hear the txn.  

These zombie unconfirmed transactions can end up like a spreading cancer, since their (or their change) will eventually get used as inputs as a last resort thus spreading the confirmation delays to additional transactions which would otherwise confirm quickly.

At yes, the setup is far from perfect— for example because, unfortunately, a lot of new users make transactions which are technically indistinguishable from a DOS attack... and because the proper fee for DOS-like-txn depends on the current "value" of bitcoin, which changes in unpredictable ways.

On the flip side, the worst case for these newbie transactions is that it causes some users to have to pay a 0.0005 BTC fee per transaction sometimes.  This is less than a penny. The gross burden on the disk space of full nodes to store the transaction (around 10 megabytes for a normal sized transaction, assuming 40k full nodes) is currently a similar cost.  The fee structure also creates a nice opportunity to educate people about more pro-social usage of bitcoin (e.g. making all payments with zillions of 0.01 txn is unnecessarily burdensome on the network).

Certainly there is a lot of room for improvement, but whining— especially whining which exaggerates and misrepresents the situation is not helpful.

You don't "decouple BGP relationships from physical links on a large scale" you'd use namecoin/something like namecoin to establish ownership of address space / ASNs. E.g. RPKI (https://www.arin.net/resources/rpki.html) but with a decentarlized blockchain in the place of ARIN.

I suppose it would work fine— but why. The centralized systems work okay for these things, and it's not like decentralizing ownership of the identifiers is enough to accomplish much (no one attacks ISPs by attacking their ownership of address space or ASNs).

Namecoin is interesting largely because the current domain name system is dysfunctional, often even failing to provide the fair protection of reasonable lawful process to its users.

We already have this in the form of checkpoints in the client software.  You don't need voting for it, because there is no ambiguity or controversy about the identity of the block hundreds of steps ago.    Better to have a check performed by _everyone_ than just people that happen to have a lot of bitcoin already.

Eh. I agree with your conclusions, disagree with your reasoning.
Listening / non-listening does limit who you connect to— you can't connect to someone who isn't listening.

If an attacker can bring up a super abundance of listening nodes in diverse /16s then there is chance that some nodes will connect only to his and he can selectively partition the network.  For example, if you control have 91.7% of the "nodes" (really just proxies) with the same /16 distribution as the regular network, any random non-listening node will have a 50% chance of connecting to you exclusively. This would take perhaps 50,000 hosts— not out of the question for a botnet operator.

If a large miner or two and a large merchant end up connected exclusively to his evil nodes, he can cause that miner to mine on a fork which he uses to make transactions in a partition which will be later reversed by the main chain when he de-partitions the network.

The fact that many nodes are non-listening makes this attack much easier, but the real solution to that is getting more listening nodes.

Where I agree with you is that adding _more_ node type diversity (especially attacker controllable ones) can only make the situation worse. The attacker will choose the types/positions of his nodes in order to maximize his effectiveness.

Absent a reliable measure of node independence I don't believe any automatic topology can have superior security to the randomly wired one for a given node order (obviously increasing the order helps) assuming the attacker has many potential targets and can run many fake nodes.

There are things we can do to improve things...  Automatic connection rotation, better support for manually configured trusted adjacencies (all the major miners full meshing with each other kills most zero-hashpower partitioning&respend attacks dead),  network health monitoring probes (and data feeds), and network health adjusted confirmation delays.

I've said before that saying "DHT" should trigger an automatic ban in IRC.  It's an almost perfect metric for identifying people who don't understand bitcoin, don't have any interesting in understanding bitcoin, and whom are going to just spout distracting buzzwords rather than contribute.

What problem exactly do you plan to solve with your DHTs. What measurements have you made to determine that the problem exists?  What analysis have you performed that supports that the DHT's will actually improve that problem?

Absent the existence of lite clients bitcoin is a flooding network: All participating nodes need to hear about everything eventually.   The randomly wired graphs appear to work perfectly well at this.  Because of the inv process any inefficiency in the topology doesn't actually increase bandwidth usage substantially, and global coverage of connected nodes seems to be no worse than a few seconds, which is well below what is strictly required.

Moreover, the 'random' wiring makes the network fairly resistant to various attacks short of isolating a node or adding tons of well distributed sybils.  This kind of resistance is hardware in more structured topologies.

It's not an oversight. The headers have a version field for a reason.

Changing to 64 bit for that field would inflate the block headers (something all lite clients need) by 5% for _null_ value because we'll almost certainly need to change to a new version or other reasons (most obviously for hash function upgrades) long before 32bit block timestamps become an issue.

It wouldn't have to be in the blockchain. You could hashcash complete txn to get them forwarded/mined.   But why? We have a _reusable_ proof of work system built into bitcoin:  transaction fees.


Creates a huge to split the chain in order to kill transactions forever even after they are confirmed, even absent obviously fraudulent respend activities and just by accident:   Consider the  the possible block a txn could have gone in: it goes in,  but the chain splits and it falls onto an orphan block, now it can't ever go in, even if it wasn't respent.   It basically allows random miners to denyable create reverse&respend like theft events without even having to control the private keys for respending.

If there were something like this the horizon would need to be much longer than an hour I think.

This can be done without possessing the private keys, actually.  The way it works is you generate a keypair, give the searcher the public part,  then the searcher looks for count of point additions needed to meet the required vanity hash value (this is same search which is currently done).  Then they report back to the requester the number of additions, and the requester combines that with their private key to get their new keypair securely.

Dunno if anyone will bother writing the fairly minor modification to make the tool handle this, plus the tool for making the request, anytime soon however. 

FWIW, this is mostly likely due to the flood protection logic which has recently been fixed in git. With prior code nodes you were pulling the chain from would disconnect you for flooding after they decided to send you too much data in response to your getblock requests.

You could potentially get disconnected from every clueful node you attempted until you ended up connected to a bunch of nodes which were as ignorant as yours.

With the new change a sync-up which took >8 hours before now finishes in about 35 minutes for me, most of that spent cpu-bound validating the data.  Unfortunately the benefit won't be realized until the bulk of the network upgrades to the not yet out .24.

Of course, lite clients are a good and planned thing, but the current poor performance is mostly due to bugs and missing features— not the lack of a lite client.

Well, I think we're stuck then:

I don't believe your proposal actually provides a secure solution with ECDSA_SIGN(SHA256(fixed_string+message)) under the assumption that the hash function has a weakness that makes collisions computationally feasible:   An attacker knows the fixed string and can often control the complete content of the signed message, so they can search to produce same value to sign as some attacker selected transaction. They compute and take as much time as they need, you sign, and they've stolen all your coin.

They can even attack all the known bitcoin keys at once with linear speedup, since for each key they can compute N target hashes to collide and then collide any one of them opportunistically. (A theoretical weakness you pointed out earlier for which you suggested including the address).

What I'm proposing would not have that particular weakness, unless you assume the attacker can create collisions even in the face of a large amount of sender selected random data.  It does has the weakness that given a key-signed-message they could potentially produce a second valid signed message which used a different nonce and had the same hash, but the simpler scheme has this same weakness assuming there was any replaceable data in the message.

The assumption of hash function weakness would be the same in each case, but I don't see how the latter could directly be used to steal all your bitcoin. Nor could it e.g. be used to have chosen input to ECDSA should some attack be discovered there.

So to summarize:

Attack 1.  Attacker finds some fixed_string+message and message2 which have the same hash, and where message2 is the hash of a bitcoin transaction stealing all your money. 

Sender selected nonce kills this one dead. (assuming that they can't perform the hack without knowing the complete input to the hash function)

Attack 2. Attacker has some signed message and finds another message that with the same hash then claims you signed it. This doesn't let them steal all your bitcoin directly but might allow them to exploit some other service which depends on address signed messages. (though you can prove after the fact that there was an attack, by presenting the message you did sign)

Both are vulnerable to this, the 'sender' selected nonce is only more so if acceptable fake messages couldn't contain any high entropy portions: due to the need for anti-replay, account numbers, etc. in many applications this seems unlikely. Sender selected nonce has the benefit of needing to collide an arbitrary hash rather than finding a pair of messages in advance.

Attack 3. Attacker finds some fixed_string+message such that the hash exploits some weakness in ECDSA (perhaps combined with other preexisting signatures) which discloses the private key.

Sender selected nonce kills this one dead.

If you don't take the assumption that the hash function is weak (or that chosen values for bad inputs to ecdsa are common) then I think both are equally secure.

There was discussion on IRC about having a "recovery code" which users were forced to write down in this manner... not to address the password security issue— no password people will be comfortable typing every time they spend will be secure, but to address the very real outcome that encryption is going to increase the amount of btc lost by people, because theft is uncommon (especially the narrow set of theft that encryption stops) but forgetting things is fairly common.

Hm?  It shouldn't require any changes to bitcoin.  Just make everything in .bitcoin the bitcoin context and deny everything else access to these files. I also don't see any reason to treat the rest of the files differently.

The wallet encryption already secures access within bitcoin itself.

So— using time and delaying confirmation when things look weird would be a useful enhancement, but its less important that I think you think it is:

If, say, btcguild goes evil and starts mining a fork which reverses and respends— then yes, given enough time they will mine six blocks.  _BUT_ in that same time the rest of the network would have mined 14 and so the chain produced by the rest of the network would be much larger and your client would ignore the chain produced by btcguild.

So the only way this would matter is if they were also able to get enough control of your network connectivity that they could prevent you from hearing about the blocks produced by the rest of the network.  The fact that this isn't impossible is why some additional logic would be useful.  (Along with peer rotation, explicitly configured trusted peers, etc)  But the fact that both significant hashpower and the network attack are required is why it's less of an issue than you might guess.

? It's reliably much faster than IRC in my testing. It pretty much always gets connections within a second of starting.

Since the overwhelming majority of all the nodes already have all the blocks, it doesn't matter which blocks you fetch... except: making it sparse would add the  overhead of having to communicate what blocks you do/don't have.

The reasons that it's slow right now doesn't appear have anything to do with the downloading external to bitcoin.  One reason its slow, for example, is that downloading a run of 500 blocks is frequently enough to trigger a flood protection disconnect now. So a new node spends a lot of time being disconnected over and over again from its neighbors, and when it reconnects it wastes a lot of time doing addr.dat exchange.  It also may get itself flooded off all the competent neighbors...

No arguments required. (There are some hardcoded dnsseeds in the software)

Don't bother with the IRC bootstrapping.  Add -dnsseed to your startup arguments.

IRC bootstrapping is going to go away in future versions of bitcoin, so getting more people testing with dnsseed now would be good.

This is a neat and nifty feature and I hope we get a version of in the mainline— I also hope we get a RPC version, for one not to further increase the dependance on tight GUI integration, but also so CLI jockies like me aren't left out. 

So I should start investing in heavy lifting spacecraft businesses because it would be smart to assume that in ten years, given your figures, we'll be at a factor 1.6e62 than now than now thus requiring us to construct a dyson sphere in order to power bitcoin mining?

Every exponential is a logistic in disguise.

I may not have much of a clue what the future hashrate will be— but I can easily predict a few things: It won't require us to capture the complete energy output of the sun, so any continued exponential projection is wrong beyond short time frames, and it won't become significantly unprofitable against power consumption for the most efficient operators. I can speculate about what efficient means in the future, but without knowing the exchange rate isn't useful. And anything thoughts about the future exchange rate will just be guesses.

No, a "naughty boy" who can't change the software other people are using. The DDOS protection comes not from the fact that your client won't do it, but from the refusal of most potential neighbors to relay it and miners to miner it. Your client's refusal is your protection from the protection.