But they don't have to believe _me_, even if they can't review it themselves they can choose anyone else who has (or pay someone to, or learn...).

I'm not sure of the context for this comment, libsecp2561k is plain C.

You should have asked.  I was surprised people didn't. Though there are many reasons around the level of publicly visible review and software testing,  there is more elaboration available now that I couldn't include in the release notes when I wrote them: https://www.reddit.com/r/Bitcoin/comments/2rrxq7/on_why_010s_release_notes_say_we_have_reason_to/

Libsecp256k1 isn't done yet. It won't be used for consensus relevant behavior in Bitcoin core until it's more mature and reviewed. Andytoshi gave a good explanation for the why we can be reasonably comfortable with signing-- that it's verified with a separate implementation at runtime (and has been cross verified against other implementations), and the scope for attacks in signing are narrow and auditable through conventional means, though more review is always useful.

If you were going to attack cryptosystems used in Bitcoin, OpenSSL would arguably make a much better target due to its complexity, opacity, and people's habit of blindly updating it due to its frequent security issues: see also the recent issues with OpenSSL's latest update breaking Bitcoin nodes.

Please describe step by step the actual attack, which things would the attack do to whom and how would they profit from doing so.  AFAICT people are just handwaving here. Actually spelling it out can help clarify your thinking or help me understand (whichever is needing improvement).

Sorry to inform you, but 571 is a prime and quite intentionally so.

They're planned eventual features and the lowmem table is stuff already implemented but not merge ready yet. Our priority for working on low-mem optimization is boosted if someone is around to test and say if it actually works (and perhaps get benchmark numbers). Some of the memory optimizations improve performance for all hosts anyways (e.g. the "compact storage type" code that was merged last night.)

The more immediate issue is that with 32k flash we'll need a code size reduction in addition to the table size reduction.  30k alone is used right now in the binary compiled for x86 is used for the unrolled sha256 implementation. We can have a lowmem compile switch to a looping implementation and such.  How much do you have free on the flash (e.g. how small does the code need to be?) that you could realistically use and have enough free to do something useful with it?

The beginning encodes some metadata, like a version id; so you shouldn't expect the first two characters to be very random. But if the software you're using generates keys beginning with 5 instead of L or K it is outdated and producing keys which will result in significantly more data-size in your transactions.

I would recommend avoiding any browser based key generators. Many of them have dangerous implementations which provide little to no cryptographic security at all, most of them have never been reviewed by a third party.

I don't see how this raises a bar to an attacker in the slightest. The easiest attacks don't involve changing the utxo set at all.

Can you walk me through an attack which would be meaningfully thwarted which isn't already massively more complex than a simple attack? I'm not seeing it.

This doesn't do anything to answer the OP's proposed situation though, since someone who can modify that can modify _anything_.  There is, and seemingly can be, no protection against someone who can silently change arbitrary data on your computer... Fortunately thats just a personal risk and you can protect against it by securing your system in the first place.

This is inadvisable. It doesn't speed things up that much, and it removes the syncup as a check on the correct behavior of your hosts (you may be surprised at how many systems suffer from hardware problems which are exposed by Bitcoin).

Yup, worse, they could return only 80% of solutions after some time or difficulty threshold passes unless fed a secret handshake...  Thats enough a shortfall to make for huge losses, but not enough to make detection easy.

I think I gave you the most useful piece of advice: If you think something ought to be done, you should consider picking up a shovel and doing it. Or paying someone to do it. It sounded like you were griping that other people weren't going and doing it for you... which is not a helpful perspective.  Especially with comments as vague as yours, I couldn't even respond "Item X is being worked on over there, and item Y was tried but failed, item Z is believed to be precluded by physical reality, and item Q was what we used to do but took it out because consideration R."...

To whatever extent any developer is doing something because you think it ought to be done or suggested it, they're doing it as a volunteer, unless you start cutting them checks.

People have very odd notions about the financial implications of software development in this space. It's interesting and important work, but it's also very challenging. Anyone with (or who develops) the skills and background to participate extensively can be paid very well by stable non-bitcoin industry jobs. Sure, Bitcoins themselves may or may not increase in value, but you can acquire Bitcoins and contribute nothing to the technology and still benefit from that, and many do. Considering the difficulty and risk specific to Bitcoin, I doubt anyone works on it instead of all the other well paying technical work they could do, except out of a deep passion for the technology and what it enables in the world.

My own view is that adoption has already outpaced the maturity of the ecosystem. While I don't begrudge other people going for more adoption, I prefer to see more organic growth and less forced effort trying to get people using things that may not be ready for them or which they may not be ready for in turn.

I'm sorry that you feel that volunteers my not be doing enough to serve your personal interests, have you considered working on whatever you believe needs to be done yourself?

You have 4k RAM but I assume a fair bit more more memory addressable flash?

Some of the pre-work for lowmem turns most of the data into const static RO data.

The existing table will be 64kb of static data, and the low mem version will likely be 1kb and about 17% slower.

If you do have a large amount of memory mapped flash, then even the big table would likely work for you. If you don't then code size is likely going to be an issue, even with the smaller tables. Though low mem will also reduce the codesize once we get around to that. (Right now secp256k1 has several special case implementations of various parts which could just be use the most general implementation when complied with lowmem, for a few percent performance hit).

How much read only memory do you have for const static tables / code?

I think we now know a better way to do soft-forks in the future, but it was premature to deploy a new method for this change. Expect to see a BIP proposal on that.

On the warning front, I think we have something of a split preference here. One of the reasons that Mike Hearn has opposed soft forks in the past is an argument that your full node security could be silently downgraded.  The warning could be made less dire ("Your system may be enforcing a subset of the rules that the network may soon begin enforcing. Upgrading your software may be prudent."), and its timing could be somewhat randomized though.

I'd bet his interest is in signing, which doesn't use WNAF.

It's trivial to reduce the memory usage to whatever level is needed. Whats your target?

Pieter and I have been working on low-mem signing (trying for a formulation with the most reduction for the smallest performance it); would signing with 1024 bytes of static data be okay?

These were never valid, they were always an improper encoding. The existing network will not relay or mine them already. I have no evidence of anyone having created any such nlocked invalidly encoded signature, and if they did it could be fixed by anyone (the signature is not under the signature).  I believe you may have missed the point I made that height gating it would _completely_ _entirely_ and _totally_ defeat the point of the change; rendering it totally useless. It also wouldn't achieve the goal you set out, since someone might have created 'outputs' in the past that are not in the chain yet.

I eagerly recommend all miners that aren't me run this patch ASAP:

Hard forking rules aren't something that miners decide.


As far as the difficulty stranding; thats a separable problem. If the system is stuck difficulty wise then politically a hardfork to step it down shouldn't be controversial.

I'm kind of alarmed at the false equivalence you're drawing between all possible changes. That bogus, and I know you know it.

When you're talking about a compact intentional delta you can reason about the exposure; you might fail, you might not. Normally it wouldn't make sense to do this on the balance of the costs.

The _ability_ to do something is important; it's a functional check and balance even if you don't actually pull the trigger on it or if you find those changes are just helpfully welcomed in.  When the consensus is potentially bifurcated without someone doing something awful it reduces the pressure to maintain homogenity as a justification to not deploy features which are harmful to a minority ("let them run their own nodes, and see if anyone cares").
 
There is no "the official" anything in Bitcoin.

There is no escaping that we must care about implementations even run by a small number of people. If something happens in the network that harms them its a harm for all of us.  Outsiders rightfully do not judge Bitcoin for this implementation vs that implementation. We're all in this together.

This is a false dichotomy.  Bitcoin Core is free / open source software. It isn't owned by anyone. Anyone is free to make their own modifications, run arbitrary versions of their own choosing from arbitrary sources, and people do. Even within one project the participants don't report to any authority except themselves.  Your argument actually cuts the other way when more diversity spreads thinner the review resources required to ensure that any implementation does what its users (or even its authors) thinks it does.

I think Hhanh00 comment about burden is weird; I am stuck reviewing redundant code in several language which I am not qualified to review in, and dealing with unfamiliar codebases because I have to cope with the mitigating interoperability risk created by other implementations. Node diversity is an significant cost to anyone working on the Bitcoin system who is not punting on dealing with the risk of the whole thing faulting. I am probably losing about 20% of my review time due to alternative implementations already, we have protocol enhancements hung up on concern that they'll just simply be rejected by other implementations (some of which are not very actively maintained relative to Bitcoin Core), etc.: It's a big enough task that people struggle to get things working, keeping up and working with the community is seemingly too much to ask for some. This isn't a cost we complain about-- it's a necessary consequence of an open system that people can (and inevitably will) do some of this--, but it very much is one. (This also holds for wallets and other tools, not just full nodes: I am not a developer of Bitcoin Core. I am a developer for the Bitcoin system as a whole, Bitcoin core just-- in my view-- is one of the most leveraged places to do work to benefit the Bitcoin system today.  That said, I have found and reported critical security vulnerabilities and design flaws in many wallets, services, and underlying infrastructure, sometimes fixing them by changes to the Bitcoin system when doing so appeared to be the best approach. These things are true for many of the other people who work on Bitcoin Core: We generally tend to take our share of the responsibility for the system as a whole, not exclusively the parts of it we work on most directly; as I've pointed out before: your own software being correct but not agreeing with other people is no great success in this space. Increasing ecosystem software diversity does not reduce the burden, beyond the point that it's best if no one program is asked to accommodate all possible needs.)