Absolutely not. Those are not public functions.

secp256k1_ecdsa_pubkey_create(unsigned char *pubkey, int *pubkeylen, const unsigned char *seckey, int compressed)

Is correct... there is more information in the header that defines it.

No.

Pooling for payment? The network doesn't care, thats a matter which only impacts the miners in question. But the common way that miners are implemented using "stratum" is actively harmful to the network and the security model of the Bitcoin system.

You have completely misunderstood the pooled mining process and how its security arises. No secrecy is required or would be in any way helpful. Pooling is secure because miners send failed lower difficulty attemps ('shares') that prove that they were attempting to mine blocks meeting particular criteria. This proves their work in an unforgable way and protects the pool from the miner. (But nothing protects the miners from the pool with centeralized pools, and pools have "lost" the miners funds many times in the past)

It's just an accident of history that hardware operators commonly completely give up control over their vote, blindly selling their computation to a third party... secure mining is perfectly possible while leaving the operators in control of their vote, just by agreeing to pay the earnings according to the pool's policy. (As is implemented in P2pool, but could also be equally accomplished for centeralized pooling systems too)

Incorrect. A block cannot be 'stolen' because it is immutable once authored. Every attempted block has an independant success probablity, and changing any part of the block results in a totally different block.

Lots of things are being done about it, but they're not done yet. Wheres your contribution?

Clearly you haven't: It's very nearly hlinear with the transactions.  There just were very few transactions in the past. There is a lot of sha256, but most of the import time is spent elsewhere. (ECDSA, writing out the database, etc.). There are some changes in the pipe that make it a fair bit faster.

Off-topic, I know, but a useful tip: Switch to ssh key auth only, the brute forcing tools detect that its hopeless and give up.

It's not good news at all-- It's less than a half cent in value, you'll use about that much or more in marginal transaction fees just to include that input. The value to you is basically zero.  At the same time spending the dust will cause your wallet to interlink addresses, lowering your privacy.  Plus, on top of that, these transactions increase the size of the blockchain on disk and slow down the synchronization time-- making Bitcoin slightly less usable to everyone.

And all this to promote a ponzi scheme. Great.

If you're using bitcoin-qt you can use this to sweep away the dust in an efficient way that also helps gum up stupid 'taint' analysis by effectively coinjoining it off. https://github.com/petertodd/dust-b-gone

What you're proposing there isn't new -- it's older than "stealth adresses", but it has many limitations which the current design was constructed to avoid.

The most important is the one you've noticed, but I think it's worse than you think it is:   It prevents any delegation of scanning because you cannot scan without putting one of you spending keys at risk.  This means that it's not ony incompatible with trezor and other hardware devices,  it's also incompatible with good wallet encryption which keeps your private keys out of memory when not in use.  Keeping spending keys offline is an important security practice, and it would be really terrible to have a design which prevented it.

It also prevents you from using a third party scanning service (at the cost of some privacy), meaning you can only use it if you download the whole blockchain yourself.

It creates an assumption that you have access to the private keys on the coins you're spending. In the case of a shared wallet, vault service, escrow, or coinjoin you do not (or only have some of them). If it relaxes which keys can be used for inputs, it would at least still support the coinjoins but require N fold more ECDH work for the scanner (as it much check each input).

It also makes the user pair mapping staionary. If I pay you some coins, and then later pay you some coins recieved to the same key... it'll use the same address, and thats bad for both our privacy. This also means that I cannot forget where I've sent funds without also forgetting my spending keys.

Then, related to the assumption of private key access, there is the issue that it it creates a bad coupling beyween the spender and the recivers pubkey types. If I start using some new kind of multisig script, or perhaps a hash based signature or something else to control my own funds, then suddenly there are all these addresses which I can no longer directly send to.

I'd originally thought it might be useful to _optionally_ support doing something like this, when the stars and moon align to make it possible... but the required bad security practices and huge slowdowns from having to do lots of extra ecdh to scan made it seem much less attractive. Plus there is a risk that the one side of the optional configuration doesn't exist and you get people unable to use different pubkey types, or people losing funds that were sent to them because their software won't notice the payments.

You just have to have alice and bob prove that they know the discrete logs of their own pubkeys (e.g. they sign a message with it while setting up their exchange). Work through the algebra and you'll see why.

If you have logs for #bitcoin from last year, I walked through the somewhat different pay to contract case, which is I think mostly what you're referring to-- in that case you alwas make the contract key G*HMAC(message,pubkey) to avoid someone setting their pubkey to an alternative contract.

Only that it has linear scaling. Such a signature would be many megabytes in size and would take minutes to verify with state of the art ECC code.

People making extraordinary claims should provide extraordinary evidence.

Separately, No one has paid me for the great many ideas I contributed to Bitcoin and the cryptocurrency world— and most ideas, even good ones, are unworkable for boring engineering or user-factor reasons.

Not so. We proved there were no semantic leaks from OpenSSL in the numbers on the stack via exhaustive testing some time ago and removed all use of OpenSSL from the script code (except the calls out for signature verification, of course— so only signature verification and the accompanying signature serialization are handled by it).
Also not so, very intentionally not.

Including things which are not a function of the transaction changes the model pretty substantially though. There isn't too much that comes to mind as "would also break" but it seems like the sort of thing that may have subtle implications.

Perhaps, but there really isn't a reason that the network couldn't soft fork in more strict time checking such that similar shenanigans would only really work if a supermajority of hashpower was in on it.  An argument against it is that people will use centeralized sources of time if you ask them for second level precision, but thats not fundamental.

I do somewhat wish the nlocktime time check were on the median of 11, which would make the funny business much less attractive— actually that could be a soft-forking change, since the median is strictly less than the block time.  Basically in that case lying about your time wouldn't help you specifically mine a transaction.

You need different Qs if you want multiple signers (in the BRS style) and for them to be mutually anonymous from each other. E.g. to select a group of N out of M trusted parties, where the N don't know who each other are.

What versions are your nodes based on? For current versions there should be relatively little dependency on the number of connections.

Yes, There is a python script that produces every parameter for secp256k1 from first principles, except the generator— and both myself and D. J. Bernstein have given the proof that in-advance choice of the generator is harmless outside of restricted conditions that aren't relevant to normal Bitcoin usage.

Why would you do that (and bump this old thread) except for pure trolling purposes?  Considering that fact that secp256r1 has unexplainable mystery parameters I can't imagine anyone outside of the NSA promoting it.

Perhaps its angels dancing on the heads of pins— but you can never check the validity of a signature without the scriptPubKeys, you can— however— check if the nlocktime is valid, e.g. and defer the more expensive operation of worrying about the signatures for transactions which have met their locktime requirements.

It also means that no transaction scheduling logic— e.g. code that decides if a transaction is locked yet needs to deal with scripts, and it means that the invariant that if a signature is invalid for a transaction is is always invalid, remains preserved (e.g. script remains a pure function with no non-deterministic inputs). E.g. you could still cache the entirety of script evaluation.

The downside with the criteria sniffing is that it's possible to have inputs with a mutually exclusive locktime type— e.g. two txins which can never be spent in the same transaction. This seemed inelegant to me, especially in contrast to the elegance of the rest of the approach. I still think it's better— just wish I had a way to avoid the risk of mutual exclusion. Obviously a receiver can just demand to use one type or the other.

Another odd concern with locktime in general is that it's incompatible with the natural solution to the y2038 problem (which isn't a real problem for the rest of the system since you can just unwrap header timestamps into 64 bit values).

That script is perfectly standard as a P2SH in current code.

Though I suspect you've confused the operation of the machine somewhat.

I'm not asking you to prove that OP_CAT is necessary,  I'm asking you to describe a specific, complete, protocol for which it is sufficient— something that starts with Alice and Bob and Charlie who want to accomplish a task, and a series of specific messages they send, and a series of guaranteed outcomes. Then I could try to help you reimagine a functionally equivalent protocol without it.

It sounds like you're describing an atomic swap or a related transaction. Often they don't need two hashes.  If you really just want something conditionally redeemable by one person or another, I would recommend the transaction type I recommend for reality keys:

Reality keys will reveal private key A if a true/false fact is true, and private key B if it's false.

Alice and Bob want to make a contract to hedge the outcome of a fact because they each have opposing short positions relative to the fact.  Alice will be paid if the fact is true, Bob will be paid if the fact is false.

Reality keys publishes the pubkey pairs  a := gA ; b := gB

Alice has private key X and corresponding pubkey x, Bob has private key Y and corresponding pubkey y.

Alice and Bob compute new pubkeys  q:=x+a  and r:=y+b  and they send their coins to a 1 of 2 multisig of those new pubkeys, q,r.

The values q,r are zero-knoweldge indistinguishable from a and b unless you know x and/or y, so no one except alice and bob, not even reality keys can tell which transaction on the network is mediated by the release of A vs B.

Later, realitykeys releases A or B,  lets say alice wins.  She computes a new private key X+A, and uses it to redeem the multisig.  Bob cannot redeem the multisig because he knows neither X or B.

This looks like a perfectly boring transaction to everyone else. Alice and Bob collectively cannot be robbed by a third party, though they could be held up or if realitykeys conspires with Alice or Bob then there could be cheating. This risk could be reduced by using a threshold of multiple observers— which this scheme naturally extends to.

I absolutely agree that additional type data makes for software which is easier to analyze. The question isn't the result of the program being provable, the question is of the implementations of the interpreter being simple enough to have even a small chance of having multiple absolutely identically behaving implementations, since we are performing this inside of a consensus system.

You continue to miss the point completely.

I circulated a patch for a different approach for Bitcoin a long time ago: https://people.xiph.org/~greg/OP_CHECKLOCKTIMEVERIFY.patch

(It's not complete and doesn't include the transition rules or cover some states, OTOH it simplifies code by not having to check the scripts (which may not even be inside the transaction itself) to know if the transaction is lock-time-good or not).