I split this off the CoinTerra thread because it's not really relevant to CoinTerra.

Hashfast_CL reported dhenson's post above for "stalking", but if it is really the case that Icebreaker is an agent, investor, etc. in Hashfast it would be very interesting to the many people here who his conduct has irritated and would potentially be material information in future litigation undertaken by hashfast customers.

However, I don't think the speculation will do anyone good at least not when it elevates itself to becoming unfounded accusations.

There are some forum members who claim privately to have uncovered some tremendous revelation, I hope they make their results public so that people have no reason to speculate.

Please keep the thread on-topic and take the fighting with each other elsewhere (or better yet: make copious use of the ignore button— you know who's comments are going to be worthless, why waste your time reading? Why waste everyone elses time complaining? ...push...the...button...).  Otherwise you just leave me pushing the delete button instead on stacks of offtopic bickering.

ObOnTopic: My eyes were like saucers at the fake update.

Is it just me or is the only irate person in the CoinTerra thread the tireless promoter of a competitor?

Yea, it's pretty crappy. If you're a miner already any mining they do is reducing your income, in fact— even if your not: their mining now will increase difficulty at the next retarget when (hopefully!) you'll have received your miners. Sure, a single unit isn't much, but on the principle of it they are taking from their customers by doing this.

It's perfectly possible to test on a test harness or testnet, even superior: Testing on the real network will often fail to discover things like devices losing performance when blocks or coinbase transactions are large (a common firmware flaw that _several_ vendors have shipped with).

Have you found yourself with a dull axe, or what?

The heck— it was just an observation. Answers here are not terribly useful except in helping people refine their scams. (After all, knowing lots of people look for X isn't helpful without knowing if those people did or didn't get ripped off)

I'm not sure what sucks worse the delays or needing to stay home and miss out on seeing family in case the miners show up.

The safercurve page carefully explains a number of good arguments for curve parameters and promotes DJB's curves. Indeed— DJB's parameters are generally well selected.

I'm pretty happy with the analysis overall. (and I believe some of the explanation on the rigidity page is actually due to complaints I made because it overstated the criteria even with respect to his own curves.)

...But the reduction of this complicated discussion into a safe "Yes or No" takes this over the line from being a generally informative page into being a sales pitch— along with the intellectual dishonesty inherent in any sales pitch.

As we can see with the subject line it inspired you to write: "Bitcoin secp256k1 not safe", as if there were something to be concerned about. There isn't.

This is a complicated subject which can't just be reduced to a simple binary result, especially so when you've explicitly excluded certain considerations like patents, implementation performance, and existing deployments while elevating niche applications and simplified implementations to equal prominence with being outright broken.

Lets take the False criteria one by one:

field	equation	base	rho	transfer	disc	rigid	ladder	twist	complete	ind
True	True	True	True	True	False	True	False	True	False	True

CM field discriminants:
Basically a curve with a small |D| has security under rho attacks similar to a curve a few bits smaller. Secp256k1 has a small |D| by design as a result of designing the curve to allow high speed signature validation. I believe the endomorphisms reduce the Rho security by effectively 1.5 bits.

(There are, of course, other ways to get speedups)

DJB's comparable curve Curve25519 (which passes this test) has an order 4 bits smaller than Secp256k1 and so I believe it has similar Rho security even considering this speedup. Basically the criteria checks only for the speedup but doesn't credit the curve for having an increase in size more than enough to offset the speedup.

Secp256k1 can use this speedup for the forces of good and has a slightly larger curve that offsets the speedup for evil.

Ladders
This is a requirement that basically amounts to "the simplest possible braindead implementation is both fast, secure, and constant time". Which is indeed a good idea, but it's no reason to be concerned about an existing, correct, implementation. In particular, in our application (primarily signatures) some of the security considerations in dumb applications (like ECDH failing to check that the point is on the curve), just don't apply.  This criteria is somewhat redundant with the twist criteria, which by DJB's definition we pass, since a big part of the argument for use of a simple ladder is that you don't have to test if a point is on the curve or twist.

[Edit: Probably also worth noting that the common ed25519 implementations seen in the wild do not use constant time implementations for signature verification, they use WNAF, because it's faster.]

Complete
This is a slightly stronger duplicate of the Ladder's requirement, and we fail it because we fail it for the same reason. Again this reduces to an implementation being more complex, and a simpler one being constant time (and/or constant time in a stronger sense).

While I agree that its good if simple implementations are possible, if you look at the hand coded ninja-assembly promoted for curve25519 its clear that the author of the page agrees that performance matters and can trump simplicity and clarity.

[Edit:  Also, the fast constant time implementation used for Curve25519 requires the most significant bit of the private key be one. This breaks some applications, e.g. using the point addition to do public address derivation.]

[Edit: Now having implemented constant time / uniform memory access secp256k1; it's even simpler to make constant time than not constant time. Though the constant time versions are slightly slower than the more complex variable time code.]

Indistinguishability from uniform random strings
This characteristic is kinda weird. It requires that there be a bijective map between a large fraction of b bit strings and a large set of points on the curve. Basically this means that you can use the curve for steganographically embedded encrypted messages. The design of Bitcoin's curve that allows for the high performance implementation completely precludes DJB's "Elligator" mapping used for the curves there, though some other mapping may be possible.  In any case, this criteria is _completely_ inapplicable to the curve Bitcoin uses for signatures.

[Edit: There is a roughly similar scheme which does work for secp256k1, described on page 8 of http://www.di.ens.fr/~fouque/pub/latincrypt12.pdf at least one way; (which is all I needed it for) but I suspect it can be made a bijection without much work]

In short, the criteria Secp256k1 fails are not generally a concern for us. The curves' recommended by the authors did not exist when Bitcoin was created and might have been preferable.  But The popular curves in widespread use today fail in generally worse ways (e.g. no evidence that they aren't cooked by the NSA) and the curve we use offers very high speed implementations and is safe for our use, even if something else would have allowed simpler implementations.

There are other criteria that the implementations of the recommended curves fail— e.g. it looks like curve25519 requires the most significant bit of the private key is set. Beyond reducing the keyspace this has the effect of making it impossible to use schemes like BIP32 for public derivation of addresses. (At least, while using the standard constant time implementations).  Perhaps more interesting is that the page does not penalize curve25519 for having a non-one cofactor. As mentioned this reduces the rho-hardness, but since failure to handle it correctly has resulted in cryptographic weaknesses (e.g. in PAKE schemes). Cryptographic protocols need to multiply their values by the cofactor it's an implementation trap along the lines of the "completeness" examples and this is easier to get wrong if your cofactor isn't one as it is in secp256k1.

[2017 Edit: cofactor in 25519 caused a total break in bytecoin/monero-- can't say I didn't tell you so]

I dunno if anyone will care, but Google Analytics was added to Bitcoin.org today without any prior notice.  https://github.com/bitcoin/bitcoin.org/issues/285

This was somewhat controversial when it was proposed in the past.

If you don't want a third party tracker keeping a record of your visits, it would probably be best to not visit right now. ... presumably anyone who actually cares has completely blocked Google Analytics already, but I thought wide disclosure of this would be prudent since it even took me by surprise, and I follow all the changes to Bitcoin.org.

Getting a new address in each transaction does not require continued active communications, this is one of the use-cases of BIP32.

Business payments absolutely cannot use common addresses because if they do you can't tell who actually paid you.  "What do you mean rent is due? I paid in txid 5. What do you mean unit 1 said that was his payment?!? it was mine!". There are all sorts of security issues that come from reuse before you ever ask about "anonymity".

Besides, this isn't a question of "anonymity" it's a question of basic financial privacy. Do you want your inlaws asking why you and your spouse are buying contraception when they told you they want grandchildren?  Do you want your employer asking you about the charities you support with the money from your paycheck?  Do you want the Barista at the coffees shop seeing that you are wealthy— maybe pointing you out to some thuggish friends as a target? Do you want your landlord saying "I see you got a 10% raise— so I know you can afford this 5% rent hike"?, or if you are the landlord do you want your tennants seeing what the other tenants pay? Do you want your business competitors knowing what your sales volumes are? Your suppliers knowing what your markups are?

Fair, equitable,  and safe transactions require privacy at every step. Human dignity requires a degree of privacy.  When you transact poorly in Bitcoin you don't just toss your own privacy, and you don't just toss it with respect to powerful state-actor boogiemen— you lose your privacy against grandma (and everyone else), and you cause other people to suffer reduced privacy too. When you pin an name on your coins then accept some from me or pay me some, then my finances are disclosed, to some degree, by-proxy.

No other financial transaction system has privacy as poor as Bitcoin's can be with bad usage, and so if we don't act to preserve privacy in Bitcoin the lack of it will be a serious shortfall which will rightfully discourage anyone from using it.

What you're proposing is a non-starter in several other respects as well.  It would require the network to maintain and serve a very costly index of these names that anyone could publish into— including abusing it for storing unrelated data like backups of their porn collection, increasing the cost of operating a node and degrading decentralization. If everyone doesn't run their own node indexing this data, then you end up with a centralized service that people depend on, spying on people, censoring access, or perhaps stealing funds with false responses. This scheme also has the problem that it's highly vulnerable to typosquatting: you might have your name, but I'll register all levenshtein distance one errors and common mishearings and then trivially capture coins based on both honest errors or malicious alterations.

Unlike what you propose it is very unlikely that any bitcoin address typo will result in a valid address, as they contain a 32 bit check value (e.g. only one in four billion addresses is valid, the rest will be rejected by all Bitcoin software— a property you can't achieve with registered 'friendly' names, generating a valid near-miss address in Bitcoin that you have the private key for is computationally intractable). Likewise, friendly names only make malicious alterations worse because they add the credibility of a correct looking name.

Getting easy and safe usage means not having people directly handle addresses at all.  Your landlord should be able to give you a sheet with a QR code on it (or the same data on an online invoice) that allows you to generate an endless series of addresses which are unique to you. You never handle any address directly, you just click pay on an invoice or scan something on a paper one. No ones privacy is lost, Bitcoin loses no value compared to other money-like systems, no crazy market distortion occurs from the inability to keep things private, no funds are stolen by typosquatters.

I wonder if 14 people would vote on a poll entitled "Help me refine my scams"?

I recommend using https://www.bitrated.com/  ... don't bother trusting your funds to a third party.

FWIW, that chart is just showing IP addresses circulated in addr messages... not actual nodes. Most of the node addresses circulated are junk.

(Not that this in away way disagrees with the inaccuracy of his predictions )

The block chain is not a jamming resistant channel, which makes these kinds of ideas a little foolish (see also the evoting people with the same notions).

Indeed, AMC vs AMT. Erp!

I'm not suggesting people to bend over and take it if they believe they've been wronged. I think the situation with mining vendors right now is a major risk to the Bitcoin ecosystem (primarily because small sane individuals are unlikely to invest in mining gear in the current climate, hurting our decentralization).

I'm just attempting to say that if you plan on doing something you should make a full commitment. A half measure of just rejecting the shipment and then doing nothing about it will only hurt you.

I should have hyperlinked, but that search button is sooo far away.  Here you go: https://bitcointalk.org/index.php?topic=304605.msg3893935#msg3893935

The fact that their videos/images were photographed in Bulgaria, along with their bank wire transfer info was very much news to me, and added to my less substantial concerns. But I don't follow very closely. If thats all been neatly explained, please toss over a link.

Cheers.

I'd like to echo concerns upthread— if you're even thinking about refusing shipment as part of a plan that will ultimately end in litigation, I suggest you go get your attorney _now_ and discuss that plan with them.  You will do yourself no service to refuse shipment and then decide that you don't really feel up to suing this out, only to ultimately end up gaining nothing but a huge delay.

VMC is paying people with promises of discounts and early delivery for defending them, not to mention the large number of "share holders" who have a direct interest in propping up perception of its legitimacy (and I suppose potential shareholders who believe its legit but want other people to not believe it's legit). Makes the subject very hard to discuss.

From what I've seen there is a fair amount of relatively concrete evidence that supports concern (including the offer for discounts to shill) and at this point people who jump on people pointing to the evidence ... uh. don't look very good.

Then you missed out on awesome quotes like:

"We are using processors designed and normally used for supercomputers which are not produced in large quantities"
"102 GB/s NOC Bisection Bandwidth"

"Vegetable-based oils can also be used providing the oil is free of debris and has no moisture content"

"Can base units be networked together as one? Theatrically, yes. Practically, no. The computing network of the blades require extreme bandwidth to exchange data between the cores making it unpractical to daisy-chain base units together.".

Some other vendors when they missed their targets contacted customers, a choice of a full refund or additional hardware.

Yes, HF has MPP, but I suspect most buyers considered MPP a valuable bit of insurance against difficulty rises with on-time delivery and a bit of insurance against some regular, random, and unforeseeable delays. I don't think any of the batch1 customers— at least not any of them reading this thread— will feel whole even if by some epic feat deliveries happen before the end of the year without some remediation, since it really does sound like HF really had no reason to believe that it could or would make good on the original advertised delivery date, doubly so when coupled with the repeated communication that everything was on time which practically extended up to the deadline and induced additional sales.

I'm not even sure if there reasonably could be a remediation that would satisfy people at this point which no doubt makes it difficult to deal with. It might be that there is no resolution which would be mutually satisfactory at this point, at least one not involving a time machine.