You can do this with far less complexity, and the same extortion risk like this:

Alice and Bob want to trade Acoins and Bcoins. They each pick secrets. Asecret and Bsecret.
They each tell each other H(Asecret)=Ah, and H(Bsecret)=Bh.

After agreeing on the amounts they each form transactions
AAlice 1 Acoin ->  ABob_pub + H(x)==Ah + H(y)==Bh
BBob  1 Bcoin ->  BAlice_pub + H(x)==Ah + H(y)==Bh

once both transactions are in one or the other reveals their secret out of band. The redemption works for all or none.

As mentioned, there is holdup risk here, which could be solved by adding semi-trusted observer keys to optionally release the funds in the case of defection.

But I think the fragment protocol  described here has the same risk.  (and the obvious ways to do avoid it make it possible to rip off one party by delaying the mining of the solution).

As Gavin says, spend-to-pubkey is valid— and it's used by the reference software for mined blocks. (and, IIRC, it used to be use for send-to-IP transactions, you'd connect to an IP and the peer would give you a pubkey to send to)

That it would increase the security is doubtful, however.  The hash function has comparable size to the ECDSA security margin, and while hash functions can be attacked being able to generate a _valid_ ecdsa key which you have the private component to which matches an arbitrary (or even any of billions) of specific hashes is basically inconceivable to me and itself would likely require both an ECDSA break and a hash break of a kind never seen on any modern hash.

If I were a betting man, I'd say it's more likely (but still unlikely) that someone would find a way of compromising some ECDSA public keys with large but feasible amounts of computation.  Under this threat model the use of hashed keys is protective, because your public key isn't revealed until just before compromising it is pointless so long as you do not reuse addresses.

There is, in fact, a oddbal altcoin proposal call MAVEPAY which uses ordered disclosures of hash preimages as its _only_ signing primitive.  (it's crazy for a bunch of reasons, but fact that you can build a plausible signing system out of just ordered disclosures of single hash inputs (e.g. not high overhead like lamport) suggests that you shouldn't discount the security benefit of that)

It makes sense after you've seen people argue that their 'losses' and betcaps are "proof" that a favored gambling strategy is a "sure win".

Same reason casinos promote grand stories of card counting blackjack sharks bilking casinos and pretend to be concerned about card counters,  while simultaneously employing multi deck continuous shuffling machines that moot card counting.

I maintain modified openssl Fedora rpm's for my own use:

https://people.xiph.org/~greg/openssl/

Perhaps some other people might find them useful, either outright or just the spec file changes.

I observed it on 3.3.7-1.fc16.x86_64 and 3.4.2-4.fc17.x86_64.  Not all vulnerable systems hit it, it depended on the system load at the time of the leapsecond.

Sadly, this doesn't do what you think it does. Wallet data ends up in your database directory.... so you can easily leak private keys that way if you're not using the integrated encryption,  and if you lose your disk while your wallet hasn't been flushed the copy on the flash may be unreadable without a manual recovery effort.

Well, you can do things like run sloccount on it— which actually gives reasonable figures for 'typical' software... though bitcoin isn't especially typical, there is a whole novel distributed algorithm at its center, its own network protocol, and as you mention more than typical care was put in to making it secure.

Feeding the earliest commit in git (easier than finding the first release zip file) to SLOCCount gives me
Total Estimated Cost to Develop                           = $ 464,573

The question:

How can we have free transactions, but not make it possible for someone to cheaply DOS the system into oblivion by simply typing "while true; do bitcoind sendtoaddress `bitcoind getnewaddress` 0.00000001 ; done" ?

To solve this we ask:  What characterizes that kind of activity which is distinct from normal usage?    We can't tell that the DOS transactions are all coming from a single party because they can just use many addresses.  We can't really single out smallish transactions because regular users make small transactions and the attack would work just as well even it was moving 50 BTC in each transaction. What characterizes them is that they're rapidly moving the same coins over and over again.

Bitcoin days destroyed is a simple metric that measures coin velocity, and it's basically what the prioritiy system uses.  Sum(input_values * input_ages) / tx_data_size = priority.

Our priority system in effect uses the transaction's Bitcoin days destroyed to pay for them— evidence that the user isn't engaging in a maximum speed coin recycling— in lieu of fees.  The metric is directly connected to real DOS attack behavior, it doesn't depend on the impossible task of distinguishing users, it doesn't disproportionally penalize low value transactions, it expends a real scarce resource (though not one that users consider otherwise valuable), it doesn't actively encourage bad behavior, and it's demonstratively effective. If you don't have enough priority or pay a fee peer nodes will not relay your transaction, miners will not mine it— not until it does have enough priority via aging.

With this metric an attacker is required to have an enormous and near unending supply of unmoved coin in order to sustain an attack or they must spend on fees (or con some suckers into paying fees for them).

The downsides are that it can be a bit inexplicable for the users— "you can't make a free txn now, but you can after the next block??", which is made worse by the fact that the reference software doesn't really try to construct transactions in a way that avoids fees— and more complicated to find _optimal_ coin selections with this metric (it makes the objective non-linear). But otherwise it's a pretty excellent metric.

Because if namecoin was widely used the cost of running a full node would increase. It has _far_ less usage than bitcoin and already it's about 18% of the blockchain size.  Namecoin's design, unfortunately, doesn't enable lite resolvers (there can be no equivalent of a SPV node, like bitcoinj, for namecoin with its current design) of any kind which I think will probably doom its adoption.  I posted a sketch of a design to solve this last year, but other than the addition of merged mining namecoin development appears to be more or less completely dead.

I consider this to be fatal flaw which will ultimately prevent the adoption of namecoin unless it is resolved.


That makes no sense at all and doesn't follow from the technology.  Namecoin is fundamentally more computationally costly to maintain because you _must_ have multiple unspent outputs pending in order to have multiple registered names (whereas any amount of bitcoin can be represented by a single txout), and you must carry additional indexes on them in order to perform lookups. (bitcoin txn only require lookups by txid).

These aren't any terrible flaws, but they're reasons why a full namecoin node— if as widely adopted as bitcoin— shouldn't be expected to be less expensive to run.

A fully validating bitcoin node can actually be operated with less than 100 mbytes storage, though the code for this is not mainline yet.


Can someone please decode this for me— because I don't have an idea what you're talking about.  I can assure you that I'm not trolling.
 
To the contrary, you've still made no suggestion about how namecoin could do anything to address the fundamentally hard problem of this thread: Demonstrating the independence of weakly trusted central servers, as required for the exponential security model given in the OP to hold.

Code misunderstanding detected:  The fees used in the generation of a txn have absolutely nothing to do with the current block size.

The most common cause of this kind of failure I've seen in the past is when a wallet is contaminated by zillions of very small inputs and ends up selecting so many the the resulting txn is >100KB, which it refuses to issue.

Litecoin carries a patch the sets a minimum value for inputs to be considered in coin selection.

Relative to the number of users namecoin is currently much more expensive to maintain. Or do you really think that namecoin has as many as 18% of the users as Bitcoin.


I understand the namecoin system very well.

It seems kind of odd to me that you'd invoke running a full namecoin node as a means to avoid running a full bitcoin node— and only a partial means, since it doesn't do anything to tell you if the parties you're communicating with are actually distinct.

How does namecoin help you know that they're distinct?   How does namecoin— as it's used today— help you defend against an attacker who has control of your router?  How do you resolve namecoin without having a namecoin full node without trusting someone (resulting in the same problem you're trying to solve here)?

A very tall assumption on the internet when identities are fairly cheap.  The question of interest is for a given definition of "organizations" how much does it cost me to make your P as low as I like?  If your definition would let you include individuals the answer is very low.

These sorts of assumptions can also fall down if the attacker has the ability to influence your routing unless you have a good way to validate the identities— and most ways of having good authentication and good ability to distinguish control work against having a lot of peers.

Bitcoin could have been created as 'one peer one vote' system under the logic given here but it would have been trivially exploited if it did.

[Edit: Oh, maaku said this all pretty succinctly, so succinctly that I missed it]

People are working on something better than that which won't compromise a node's ability to function as an autonomous fully validating node but will still make things much faster and use less storage.

More important than supporting header only (SPV) mode, but rather the ability to start as a SPV node and sync-up and transition in the background.  But this isn't yet in the immediate pipeline.

I think that critical/serious definition given here sounds fine, though I wonder if I'll remember it— especially if people come up with a number of similar sounding names.

The problems with names is that always get confused, people spend time arguing over them, and people get hurt when they misunderstand them, this is one of the reasons that CVSS was created— though I've run some example Bitcoin cases through the standard scoring criteria and I think it gives broken results. (E.g. giving more sever ratings for technically easy attacker-effort-proportional DOS attacks than for harder coin theft attacks).

My preference is to actually state what the risks is  "An attacker can crash your Bitcoin if he connects to it"  vs an opaque "Code yellow" kind of label,  at least where being descriptive won't imperil people.   This avoids getting stuck in word games over "serious" vs "severe" and other such matters of angels dancing on pins, and allows people to assess their own risks in ways that no boilerplate classification can do.

I suspect that any issue where you can't even say as much as what an attacker could do without unacceptable risk is by definition the most severe kind, Critical, or whatever you'd like to call it.

Yes, entitled,— where you expected to be contacted privately in advance of the "announcement". (Never mind that the stuff in question has been public for a while)


I have no clue what you're talking about there.  My grepfu fails me because I can't find anywhere where people have asked about that.  Also, I still don't understand how you think my personal preferences proves a lack of uniformity— preferences differ.  I also still don't understand your argument about about the classification being unclear since it was described specifically in the announcement instead of just being given a class.  ::shrugs::

Doing this will delete your wallet.  Please edit your post to include some kind of warning so that if anyone else hits this they don't just blindly follow your instructions and lose coin.

My best guess on your issue is that you didn't shutdown cleanly before upgrading. Deleting your databases is one way to recover from that, but users with coin should take care to not delete their wallets in the process.

Say "thank you for improving bitcoin"?   On IRC you seriously offended me with what I considered to be an entitled attitude and unjustified hostility.  I was particularly torqued after I said that I didn't agree that it was "critical" and wouldn't have personally described it that way and based on that you continued to repeat allegations that there were no standards and that the developers don't agree about vulnerabilities. I think I would know if I didn't agree with what Gavin posted.

I apologize if my willingness to argue back managed to keep us from effectively communicating. For all the trouble you'll have with your nodes keep in mind that we all work hard with Bitcoin too. I maintain more nodes than you do— though I do have the comfort of not handling a large flow of other people's money, I am  constantly dealing with juggling changes on them.

The issue at question is a (set of) DOS attacks, as described in the announcement.  They've been 'disclosed' for a month in git, and have been discussed in the abstract by class as long as a year ago.  We have not historically done embargoed releases and early warnings to major infrastructure on issues which didn't allow the theft of Bitcoin or ~O(1) knockout of the network, and I would stridently oppose beginning such a practice: We do not have the resources to manage that, and it would delay getting fixes into the hands of users.  This release announcement is not the first public mention of these issues, and standard best practices for node operation will generally protect you from DOS attacks.

You should handle this like you'd handle other testing releases: Upgrade one or two of your nodes and report issues. If you do not run testing version the release versions will likely not be of any higher quality. If by some crazy chance someone DOS attacks your other nodes, you at least have some that are working.

You receive transactions at that rate.