Sorry if it offends, but people labeling their personal wild ass ideas "Bitcoin 2.0" creates confusion.

Nit: There was _far_ more <0.8 nodes at the time than >=0.8. What there was more 0.8 of is hashpower. This disagreement between what everyone else runs and what mining runs can easily happen because ~3 people control the operation of >50% of the hashpower, and miners in general had updated to 0.8 quite quickly.

I have no clue who made that transaction, but it was an "ordinary folk", no special privileged was required.  Electrum's server reimplementation of the Bitcoin protocol was fatally incorrect in a way which that transaction was structured to trigger, thus isolating them from the network. Fortunately (?), the transaction also included a fix.

Perhaps you've mistaken Bitcoin for one of the whole cloth pump and dumps in the altcoin forums?  The public had access to Bitcoin from the start.

Why?  I've found it hard to convince people that full nodes offer additional security. (Indeed, I've found it hard to convince people that SPV clients provide more security than JS web wallets).

Doubly so because the inflationary threat running full nodes is most uniquely suited to fighting is generally not that relevant to businesses. We do not see businesses standing up to fight fiat inflation. Generally businesses care more about differential advantages with their competition, can avoid fixing contract prices in inflation resistant terms, and can afford the resources to invest away (self or otherwise) inflation risks.

In some ways I'd expect businesses to prefer running SPV nodes that get blocks from a single source which cryptographically signs them. The security model is more traditional and thus easier to understand, it completely closes some kinds of risks, and gives them someone to sue if things go wrong (except when the wrongness is produced by a state level threat, but see above). Today we see businesses very frequently depending on parties like bitpay for their whole transaction processing needs, a step even further towards centralization end of the spectrum then SPV with signed blocks.

Decentralization is hard and it's costly. Anyone who believe it will be easily retained in Bitcoin if Bitcoin grows is fooling themselves.

I'd suggest that you also implement some protections just in case something clever get past your eyes.

beyond some programmatic 'xss' matching, one idea would be to iframe the html/css ads on another domain, so even if they do go rogue the browser sandboxing will rescue you.

I'd also be a little careful with assumptions like "CSS can never be a security risk", CSS is now a huge amount of code, it's a big attack surface, and I wouldn't be surprised if there were some zero-day CSS remote execution exploits (though... getting through manual inspection would be tough). Conversely CSS loading images and other assets from remote hosts could be used to trigger exploits in the image handlers, or just act as webbugs.

Posters: Please don't create threads just to promote your referral links. It's spammy BS and if everyone did it the forum would be useless... rewarding just the few of you selfish enough to behave in a way that harms the forum is not in our interest.

The form has official ads, and the social norms here seem to tolerate advertising in signatures— or limited referral links in the context of places where you would naturally provide the same link absent the referral incentive. Creating a bunch of new threads purely to direct people to referral links clearly harms the signal to noise ratio here.

Vendors: Please don't create referral programs which are highly vulnerable to abuse, and to the extent that your programs can be abused by spamming please police yourselves by de-crediting users who promote through outright spamming.  If you don't do this you may find your services completely blacklisted from places where they've become a nuisance.  You can't claim zero responsibility for the foreseeable abusive behavior your programs encourage.

"To enjoy freedom, [...] we have of course to control ourselves." --Virginia Woolf

Empoweoqwj, you're not really adding to the discussion here.  It turns out that the world is a complicated place.  When Bitcoin users are persecuted by association or Bitcoin itself is attacked on the basis of its unlawful use by some of its users that hurts all the users of Bitcoin including those who aren't engaging in those activities.   Because none of us use Bitcoin in isolation we all have a responsibility to our fellow users to execute our freedoms with consideration and minimize the collateral damage to others.  Even when that damage comes from places that are believed to be unjust or misguided, it is no less _real_ and does no less harm to people. Special care is required when an activity is very profitable to you, since that can create biases that help you ignore the costs/risks your justifiable-to-you actions indirectly impose on everyone— including a lot of people who aren't sharing in your profits.

In my view one of the limitations in popular libertarian philosophy is that it takes an overly limited view of violence against others, because a more complete perspective must acknowledge how very difficult and limiting completely avoiding harming others through your actions can be.

I would imagine that a lot of that stuff is just pure ignorance. In any developed place on earth the number of laws and regulations makes their scope beyond any single person's ability to comprehend them.  While some are enforced more frequently than others, it's not actually that surprising to encounter people who are not aware of the rules they may be violating. Even something like selling alcohol— in the US its normal for supermarkets to have beer and wine (and liquor in many places), it's not hard to imagine that someone might think it to be no big deal to sell some on Bitmit.

A possible course of action would be to just politely contact the people selling this stuff (or the sites hosting it) when you run into something that you're aware is problematic and express your concern. ... if people can't handle a little nagging and tattling by other community members they're surely not going to enjoy some state agency breathing down their throat.

I look forward to your paper, as I'm sure DJB would as well.   (Though sure, if you're not going to go all the way to a deterministic signature, might as well use lots of randomness instead of a counter)

Correct! (and this is what is normally described, e.g. FIPS DSA, so the developers can hardly be blamed).

The idea of making the nonce H(message||secret||random) is to just armor against bad RNGs without making K non-random, though it doesn't need to be non-random— it just need to be secret and distinct per message.

Two things can happen,  given two distinct messages with the same unknown K you can recover K, or Given K you can recover the private key.  (also, knowing fairly small amounts of K in several signatures can also allow you to recover the key through more complicated techniques)

If the nonce is H(message||secret)  then if you have identical data being signed you will get a completely identical signature and learn nothing (otherwise I could crack any key by just writing another copy of the same transaction down! ).  If you have non-identical data being signed you will have non identical nonces.

No you don't.

adding multiple round trip times, this is the exact opposite of the desire here. Round trip times can easily dominate the process. You already largely know what txn your peers have because you know what they've advertised to you, and you know what you've sent them. Bloom filters this way already. It works great. Sending a bit of extra data is no biggie, if you don't like it— relay early.

I clipped out a lot of details, half was superfluous, half is already in that code linked above. Patches not posts if you want things to matter. This is really off the topic of the paper and should probably be in another thread.

Doubly so because all (?) large pools have a tiered architecture and don't expose their mining nodes to the public network (otherwise they get DOS attacked). Interesting point.

Some other minor comments, "each kilobyte in size costs an additional 80ms delay until a majority knows about the block". A majority of nodes isn't the interesting metric. For the purpose of rate dilution and orphaning a majority of hashpower is, because of the rather unfortunate consolidation of mining power, it seems unlikely that these too figures are greatly related to me, as something like three (administrative domain) nodes have a majority of the hashpower alone (though the (D) results show that the consolidated connectivity isn't magically perfect), so we know the "simplifying assumption" on this is a pretty poor one. But it's unclear to me what the magnitude of the impact is, though it might have been interesting to reason about the expected improvement from (D) vs the realized improvement.

"By extracting the timestamps"— block timestamps are lies due ntime rolling, with the overall fitting it may not really matter, but I'd generally caution against using them for much of anything where accuracy better than an hour is wanted.

Edit:replaced brief comment after reading the paper.

Having now read the paper (excepting the background parts, which I trust are correct), I'm excited to see good measurements. I am, however, disappointed that they are probably too old to inform the system as it practically is today (as they occurred prior to some of the performance improvements I mentioned above). I am also disappointed that the authors were apparently unaware of the implementation of the (A) and (B) proposals in August 2012 (see Luke's patches), prior to their work, and the related results.  After some more contemplation I may have additional thoughts on some of the measurement techniques used.

Separately,

While this may be mostly the fault of academic publishing norms, I believe that the work's academic integrity is degraded by its over-reliance on citations of other, often fringe and unimportant, academic publications on Bitcoin--while ignoring the substantial base of open source industry activity that takes place here, on bitcoin-development, and on github. Doubly so when the end result is that the authors will be credited in future publications for inventions which, in actuality, substantially predated their work.

In this case, the work does not cite a single piece of the industry discussion of block propagation timing concerns or potential solutions which occurred prior to and during the time under study. While this complaint is not unique to this work, I've reviewed preprints which have done far better, and I do not believe some other authors' similar behavior excuses the exclusion of the relevant citations here.

Without following the link, yet:

I've been telling people this for a while, but their dilution figures are far lower than I would have guessed. So at least that much is good!

Luke had partial patches for exactly that verification speedup change last year, but they were diminished in value by the general blocking/single-thrededness of the networking code.  The ECDSA caching really took a big bite out of the verification times, since most txn have been observed first. Ultraprune made other big improvements, and people haven't seemed to care quite so much. Our primary approach to poor propagation time was to make validation enormously faster. I do note that what Luke did was create a separate message type for unvalidated blocks in order to indicate to the peers that the block is unvalidated. This allows limiting the radius of bad blocks, avoids imperiling SPV nodes, and prevents an attacker from creating huge network partitions around an aggressive relayer by giving them bad blocks which trigger the anti-DOS logic and an instant 24 hour ban of a peer that forwards an invalid block.

The other obvious enhancement would be to split block forwarding to avoid sending redundant data for transactions which have already been received by the far end, this can be done without increasing round trips by just using the existing INV caches to track what txn we know the peer already knows.

At some point you start bumping into the actual networking delay limits and get diminishing return.

I'm not following where "must be found" is coming from there, but I suppose that means its time to follow the link.

Okay, it wasn't clear that you were still assuming the H(message||private||). Technically you can leave the "R" in that out entirely. The deterministic secret K is fine as far as anyone knows. However, it violates FIPS. So would your counter. For some things people care about this.

You understand incorrectly. If K is known a single signature can recover the private key.

I'm not sure if you're being snarky here or what. But I personally, and several other people (e.g. I'm aware of jrmithdobbs testing it pretty extensively too) have checked the RNG used in the reference code.  It's really easy to break (EC)DSA with a bad RNG at runtime and that makes me paranoid (e.g. my minor contribution to a netbsd security advisory).  That isn't to say that any particular flaw might not have gone unnoticed, especially a racy, platform specific, or library version specific issue— go link bitcoind/qt against some some novely broken openssl and all bets are off.

Without knowing all the details here it's hard to do retrospective analysis with the benefit of hindsight to say if something could better have been done here with the android wallets.  The one point I'm aware of is that I think back in January we had some evidence that some bitcoinj users may have had poor nonce entropy, but I think this was chalked up to old bad android. Perhaps in hindsight more exploration should have been done of that issue, or more proactive monitoring of the amount of R reuse.

IIRC if you seed it before ever pulling a random number from it, it will only be seeded from your (quite likely weak) seed, and not the OS provided randomness. Seeding it should be unnecessary, and it makes it easy to screw yourself.

"There’s no mechanism to ensure that people who make money through such digital currency report the income to the Internal Revenue Service"

:-/

There's no mechanism to ensure that people who make money through CASH report the income to the Internal Revenue Service... and yet the world continues on just fine.

Generally law enforcement in free societies is accomplished via sampling and stiff penalties for cheating... not some crazy panopticon of ubiquitous surveillance. There are places where Bitcoin creates some different challenges, taxation isn't one of them.

Uh. This forum is full of miners.  If anyone here wants to ask a miner a question, they can just— you know— send one a private message.

But hey, I can play along— for a miner that has an Avalon and mines on a 3% fee pool.  "Do you think you're getting $90/month per Avalon you have mining at that pool?"