Seems no one knows, but likewise— who created the paper the printed version of the spec was printed on?  What software was used to spell check the document?  Who came up with the shortname for the curve? maybe they were a secret NSA plant!   if you want to go down the rat whole of _provably_ irrelevant things there is no end to it.  Ultimately people who are not technically sophisticated are at risk of being FUDed by people who are dishonest or themselves confused, but no amount of good process can prevent that.

Exactly like cash is illegal, and precious metals...

Fortunately all the cryptographic privacy systems can be transcript producing. Some of them inherently are, in the bytecoin/monero/fantomcoin system getting your single scanning private key lets the holder identify all your transactions... so it's very much audit-able, just not a free lunch for global passive surveillance and not a total privacy cluster-@#$@ for normal users.

The software uses best-practices in handling, it's adaptively strengthened with a cryptographic KDF and salted (and cracks at no faster than 10 per second on the user's CPU)— but users (including myself) stink at producing passwords or if they manage to produce a good one, they can't remember it.

No amount of encryption can protect you from poor passwords, keyboard sniffers, or other local machine compromises... or from forgetting or disk corruption.  The wallet encryption helps against some things, but the rest is up to you currently.

Of course not. The zercoin code— though very interesting was a technical non-starter for our applications (20-30kb signatures, very slow validation, trusted initialization). As of now it's been abandoned by its developers and not adopted by any altcoins (AFAIK). Of course, techniques improve with time— thus…

Zerocash  (which is unrelated technology to zero-coin) is expected to improve validation speed (signing is still tens of seconds), and get transactions down to only ~5+ times larger than current ones, but will still require a trusted initialization also very new and largely untested cryptography (some of which includes assumptions which are provably non-falsifiable) which, if compromised, grants unbounded undetectable inflation. This isn't exactly a good fit for use as Bitcoin yet. I'd like to use the technology in a side-chain when made available, where the risk could be more contained,— I spent a bit of time making recommendations about how it could be integrated in Bitcoin with them in email and in person— but the people involved seem to be very interested in creating an altcoin specifically as an altcoin. (Which goes along with not publishing an actual implementation of the complete zerocash cryptosystem, e.g. what was benchmarked in the paper).

I have an implementation of bytecoin ring signatures suitable for our system but if I publish it at this time, it will just result in more altcoins... All these cryptographic anonymity proposals are very immature and come with high costs attached (resource usage or cryptographic risks), and are rapidly developing science, some of which I've been directly contributing to. Bitcoin core— under live fire in a consensus system— is precisely the wrong place to be developing them, but a reasonable place for them once they're mature, tested, and have some of the ugly compromises engineered out of them (e.g. trusted initialization (for zerocoin), transaction bloat, or imperfect privacy (BRS)).

There are several other cryptographic approaches which have been invented (some by me), but all have unfortunate tradeoffs so far... but the technology seems to be rapidly improving.

Schemes which provide improved privacy in a safe and compatible way like CoinJoins (e.g. see darkwallet) are already being developed by multiple parties now and are flourishing. They aren't where we need ultimately but they do have good tradeoffs for the short term.

This isn't my experience, but if you'd care to point out any specific instances where something was unfriendly— I'll be glad to go work to resolve it.

I was referring to the donors themselves making a condition as part of their donation (obviously this wouldn't cover dues), other funds— the bylaws wouldn't say anything about this.

As a member you're free to ask— though a better forum might be the foundation forum.  Since this isn't the foundation's current area of interest I'd expect you'd see more success elsewhere with less effort though.

Sure, this is what I'd hoped ripple would become— back before opencoin bought it and turned in into yet-another-alt-coin. (and I had to go and revise a bunch of my posts to remove recommendations to look at the ripple system when it changed entirely).  (And one of the reasons I've been concerned about proposals to raise the block size limits— a world where much of the txn volume moved to fast txn processing systems might look a lot different from ours now and may need lower limits— or very different ones— to retain security in the long term).

Right— well ripple has seemed to leave the membership process undefined (as this proposal seems to have done as well) which is probably a huge liability. ... but the whole notion of a federation of semi-trusted parties isn't a bad one— it's one I've recycled many times myself as an example of a way to do high throughput low value transactions with scale no truly decentralized system can provide. ... But I don't think that kind of the system can really be the underlying basis of a complete worldwide currency because it is still fundamentally based on trust. If it could: we would have had it already long ago— multiple-signer federation isn't a new idea relative to digital-cash.

I read it multiple times as I did not find it clear at all.  Communications is hard. You could help me out by picking apart why some of the things I cited do not apply and that might help my understanding.

If anyone can mine with no ID and no disadvantage what prevents every miner (including the attacker) from using a unique ID in every single block, and thus being indistinguishable?  

Alternatively, if you pin blocks based on the decisions of some of these "optional" IDs to the detriment of IDless miners, what prevents the ID-ed miners from pinning a particular otherwise-non-consensus blockchain (e.g. to enforce some economic policy in excess of the system's rules).

Coinbase outputs cannot be spent until they mature 100 blocks later. This addresses some incentive concerns related to miner honest and prevents a fungibility difference from the fact that recently generated coins are at greater risk of irreversible loss since they cannot be restored if they fall out of the chain in a reorg.

This is a fairly basic part of the Bitcoin system.

The Bitcoin Foundation in no way owns or controls the Bitcoin core implementation hosted at github.com/bitcoin. The Bitcoin Foundation currently sponsors some of the work there, since that is currently a good way to support the ecosystem— but this may not always be the case, and in the future the Bitcoin foundation may better spend its funds supporting the ecosystem in other ways (including other technical ways).

As such, I don't think the the bylaws should single this out.

I do not know if the BCF accepts restricted donations, some organizations do— some do not—  if they do then thats potentially a way you could better target your funds.  Additionally, there are other groups and indivigual developers working in the ecosystem who's work you could support directly and separately from the foundation. Increased diversity of support is good for the ecosystem and you may be able to support work which better aligns with your concerns and values than the initiatives currently being undertaken by the Bitcoin Foundation.

It may also be that some of the work you'd like to see done would best be accomplished outside of Bitcoin core— because the importance of the software is so high its a more challenging platform to experiment in. It can be easier to prove and refine an idea outside of it using other software on the network and then implement it back in Bitcoin Core once the design is clear.

If you're going to remove the non-membership of mining and require certified (and ... presumably licensed by states, since the process will make it easy to pin them down) you might as well eliminate the mining, use signatures, and call it SWIFT.

There are perfectly legitimate uses for signature based systems— they have useful security/performance tradeoffs— but they're very much at odds with Bitcoin's security model. In Bitcoin mining is anonymous (in the sense that it has no membership) as part of the process of making it decenteralized and somewhat censorship resistant.

Anything that lets you tell if blocks are from the "same dude" creates hooks to force miners to only mine particular transactions.

(WRT "protocol changes", the coins produced by the coinbase transaction cannot be spent for 100 blocks)

You have, but I've given up responding.

I certantly wouldn't agree there. For people that are actually willing to write code an inability to just copy and paste is not much of a barrier.

How about, you know, actually offering a distinct value that justifies having a whole other currency (e.g. friecoin)?

Edit: I removed some spam plugging Bytecoin based (e.g. bytecoin, monero, fantom, etc.) coins from this thread which also spammed other threads— but to the extent that there was a genuine misunderstanding, and not just a desire to spam I figure I should comment... the bytecoin ring signature is pretty straight forward to add to Bitcoin— though it implies a pretty considerable scalability tradeoff. Andytoshi and I have come up with some pretty substantial cryptographic improvements, e.g. https://download.wpsoftware.net/bitcoin/wizardry/brs-arbitrary-output-sizes.txt

Forget that— even ignoring the scaling they require the participants to be enumerated in advance.  Thats generally a non-starter to begin with for what Bitcoin attempts to achieve.

A neat variation is that for the parties that compute H(R_n) you make H() really be g*R_n  on bitcoin, and require that the transaction commuting to the scheme actually be doing a coinjoin with the R_n parties, putting up some non-trivial amount of bitcoin to be held under each of the private keys for the duration of mining time.  This means that if any of the parties leak their R_n value to a miner (or other R_n) holders during the mining interval so that the miner could attempt to grind a solution with a particular output then someone could instead steal their coins... so the integrity of the process would be bonded.  The bonds could potentially be very large.

I think since each block already hashes the prev block we already have that property without doing it explicitly!

There is an argument that it should be using toeplitz hashing with as much data as possible as an input as the entropy extraction, but there is a tradeoff that more "unusual crypto" in the scheme makes it harder to trust.

Yep. The idea is that you lay out all the "influence" parts up front, then use the blockchain to 'cut the deck' in a hard to rig way.

Even if someone didn't personally witness the process they still have the blockchain POW as evidence for a minimum computational cost in retrying. E.g. doing 2^70 blockchain work multiple times to rig it might be conceivable, but not the 2^128 work required to do 2^58 retries.

The next annoying property is that you want to have curve-acceptability tests but too many tests and perhaps you are actually testing for weakness-included. E.g. DJB would perhaps have you test that there exists a specific mapping to nearly uniform scalars (e.g. elegator), but perhaps that guarantees a vulnerability. Or in our case secp256k1 is selected with the efficient endomorphism to permit the GLV method for faster operations.

Well, it is different— say there is a class of weak curves known to the NSA but the weakness requires you to select a one in 2^128 set of parameters... without a pre-image attack on the hash function you couldn't use one of these 'random' procedures to pick such a curve.

If the weakness was a 2^32 one— you could, thus the bada55 curves.

The scheme you suggest has a weakness in that there are potentially too many plausible schemes.  For example, an attacker might use their ability to choose a hash function and value serializations to choose insecure parameters.

What I would prefer is a scheme that worked like this:

(1) Take a scheme like yours, but give it an initialization seed as an input. The scheme should be designed such that all acceptable parameters are equally likely to be selected (assuming good properties of some cryptographic hash).
(2) Publish the scheme, and ask various mutual distrusting parties to compute random values R_0, R_1 ... and each of them publishes X_n = H(R_n).
(3) Take the H(scheme) and X_n and commit to them in a bitcoin transaction, publicly announce this commitment.
(4) 100s blocks after the commitment, take the block hash 100 blocks after the comment and have the parties release their R_x numbers. H(scheme||R_n...||block hash)

The idea here is that up to the preimage resistance of the hash function, to influence the selection you must both compromise all the distrusting parties AND do a huge amount of sha256 computation.

But thats all for where a random selection can't be avoided... the "fixed by security/performance considerations" approach is probably best.  An interesting question how reasonable it would be to formalize all those considerations in order to combine the approaches... since DJB's claims notwithstanding, there really is many degrees of freedom in within that (otherwise secp256k1 _and_ ed25519 wouldn't both exist).

As mentioned in my prior response— if you did this then your proposal is completely ineffective. First you double spend, and then you spend your double-spent coins to yourself.  If you do not also unwind the child transaction then the doublespender walks free for nothing but the cost of an extra transaction. If you do unwind the children then everyone is at constant risk.

Please read the thread. We explain in detail how choice of G is not relevant for our own applications. If you don't believe that, DJB also argues why choice of G is usually irrelevant on safe-curves (SafeCurves does not place restrictions on the choice of this base point. If there is a "weak" base point W allowing easy computations of discrete logarithms, then ECDLP is weak for every base point)— an argument he added after I emailed him and suggested he add an explanation of his own G choice, which he did not previously provide... it took me inventing a novel attack against a contrived hypothetical protocol (not Bitcoin) where choice of G actually mattered to convince him to say anything at all.

I don't believe your post contained a "proposed solution" when I initially responded, if it did— I missed it.

But it's not a solution, alas. Ignoring other issues, at best it still leaves it at a simple piece of extortion "return most of the funds to me or I will reliably destroy your payment". It that sense pretty much isomorphic to "replace by fee scorched earth". The ongoing effort has other problems— a txout can be spent again immediately in the same block. Imagine it takes months to get the fraud notice out (heck, imagine a malicious miner creating one and intentionally withholding it).  By that time perhaps virtually all coins in active circulation are deprived from the conflicted coins. Now they finally get the notice out (/finally stop hiding it). What do you do?  Nothing? Invalidate _everyone's_ coins? Partially invalidate everyone's coins?  Each option is horrible. Do nothing makes the 'fix' ineffective in all cases: the attacker just always sends the coins to themselves in the same block, the others make the failure propagate— potentially forever, and don't just hit the unlucky merchant with the potentially unwise policy.

(It should be noted that already systems reject from their mempool discard later double-spend transactions from their local perspective, because— duh)

Many places, I'll pick an example from myself— (note the log I reference there 12:37 < gmaxwell> pirateat40: you can have 10% of the hash power and attack.)

The bada55 curves were created to show the worthlessness "verifyably random" (at least as done by NIST), they are "random"— but the authors (ab)used the process to make sure the parameters had "bada55" in them. You are supposed to imagine an attacker armed with a mathematical breakthrough who could compromise 1/2^24 random curves doing the same kind of seed grinding.

I didn't believe the post I was responding to was at all talking about the bada55 curves, the subject had drifted and the post was talking about the curves recommended by the site. Presumably if I failed to answer the authors question he could respond.

Huh, the fact that someone with <<50% hashpower can successfully double spend has been repeated many many times on this forum, by dozens of people (including myself), along with comments that mining pools or (especially) vertically integrated closed mining operations with double digit percentages of the hashrate are all concerning, even if its not near 50%. The original Bitcoin whitepaper gives the formal for calculating the success rates.