I can't figure out what you are saying is a problem here.

As a point of clarification, the reference client is not the Bitcoin foundation's. It's an independent open source project which existed a long before the foundation.  The foundation currently funds some of the folks with commit access, though not all, and pays for some resources and tools.

Notwithstanding that, everything else you said was also perfectly fine.

I'm not, but I've dealt with (literally) hundreds of people who were, so I can forgive you for assuming. I've found that explaining that mining is "progress free", like throwing dice helps people understand the quickest when they suffer that particular confusion.

For simplicity, Imagine you, and I are mining in perfect competition with equal hashrate, and there is another 20% held by others.

I find a block with a very low value— very likely to win under your scheme.  Instead of announcing it I keep it for myself and I mine the successor.  If you find a block I will release mine immediately and win.

Sometimes I find a second block before anyone else does. Sometimes I'll even find a third.  I can begin announcing my older blocks only when there is a non-trivial risk that the network would over take me with the next block it finds.  In this way, even though I do not have a majority hashpower I can exclude large chunks of other miners blocks from the network by having an information advantage over the chain I'm keeping private.

Mining is progress-free, but the blockchain as a whole is potentially not.  Preferring the first seen block creates a strong incentive to announce as fast as possible and helps the whole system behave in a progress free manner.

Your message might get more attention if it had a modicum of civility.

I believe there is nothing to implement in bitcoin core here.

It's already possible to query a local node for such status— e.g. the gettxout rpc exists right alongside getblocktemplate.

But, it's likely meaningless to do so— blocks cannot contain double spends relative to their _own_ chain, so including one would be more or less harmless to the network (it would just result in the miner producing an invalid block the network ignores). Rather the case that you need to worry about is when the block and the local node are on separate forks, in that case some different spends between them are expected and— importantly— can be triggered at any time by people relaying different data to different parts of the network.  Inconsistency does not show misbehavior and, in fact, cannot be avoided otherwise— eliminating inconsistency is why we have mining.

The better thing to do is to simply have a local node provide the chain and transactions while the pool provides only the coinbase. This is pretty much facilitated with GBT already at a protocol level, then the pool centralizes the miners payments but not the state of the network rendering it harmless to anyone except the miners (the pool could still rob the miners blind, as they currently can).

But, not surprisingly none of the miner software implements this and none of the pools care to do so... P2Pool already accomplishes this PLUS preventing the miners from being robbed by pool operators. Those who care are already using P2Pool and everyone else is happy with what they have already.

This is an oft repeated suggestion going back to at least 2011.  It opens a trivial attack where when you do get a very low hash you refrain from announcing it, comfortable in the fact that you're guaranteed to win a race should one arise. In doing so, your competition is all wasting their time mining along a path that is likely to lose. The effect is stronger the larger you are, creating an increase in expectation for larger miners that doesn't otherwise exist.

Sorry, you misunderstand Bitcoin horribly— you're in good company: The blockexplorers present a cooked view of the system to make things simpler, but promote this sort of misunderstanding as an unfortunate side effect.

In Bitcoin you cannot send a precise amount. You must send an amount which is a sum of some subset of the amounts you've previously received. A good mental model is to imagine that when someone pays you they give you a metal coin with a certain weight (value) with a public key of yours written on it.  You know which payment was being made by virtue of which public key received the funds.  When you later want to spend the coin you visit a forge (the network) and ask it to melt down one or more coins that you have and make one or more new coins of equal or lesser weight with whatever public keys you want to be paid paid inscribed on them and you present signatures to show you were authorized to spend the coin(s).

The Bitcoin blockchain has no "balances" and instead tracks atomic "coins" (transaction outputs). When your wallet authors a transaction it picks one or more of the payments you've previously received to spend completely. Often the amount is more than the amount you are spending (obviously it cannot be less), and so you need to take change as part of the transaction.

The coin tracking design is important because it prevents replay and also allows clear deterministic behavior in the event of reorganization. The lack of any persistent accounts is also beneficial for privacy.

Eligius is also not proposting to keep any of that funds for the pools— but do instead return it to the miners who actually earned it, everyone that was mining during the time when the attacker was withholding blocks and were underpaid on account of the attacker being overpaid.

There is a lot of risk of theft by pool operators, but this isn't the form you should expect it to take.

Just in time to redo it using libsnark: https://github.com/scipr-lab/libsnark 

The claim that it has been around for two years isn't credible from what I've seen— not even remotely so.

FWIW, the gettxoutsetinfo rpc iterates over the utxo set, in the past when I've wanted this data I've just added some instrumentation in that function to dump it out. Even if you're not very experienced with C++ it shouldn't be to hard to emulate the rest of the code and print it out... this might be easier (and also more reliable across versions) than trying to read the data.

Not really useful, since you could always split yourself up to a bunch of small accounts... and even if you weren't attacking you'd prudently do this to avoid any delays, even if they were small.   ... if you thought your odds of getting a block soon were good why would you be on the pool in the first place?

OT has been talking about interesting things in connection with Bitcoin since at least mid 2011 (my personal recollection) but in all this time has still not, as far as I know, produced even the simplest tool to do anything useful with it and Bitcoin.

I wish them the best of luck, but to the extent that the promotion without delivery is distracting people from actually creating stuff that people can use it's not a good thing.

This is really a deep software internal and may change from version to version. You really should not be writing external software that does anything with it— and if you do, well— you get to keep the pieces. It's documented in the source (serialize.h) I'd worry that putting it on the wiki would make it sound like there was some commitment at all to preserve it.

Oh come on, just follow the calls.. not so hard to find the ctxoutcompressor and the call to decompress amount:


Because there are millions of txouts the format works fairly hard to save every byte (the leveldb compression does nothing useful for txouts at all).

Nope, still sold and supported— and there was a new version (third generation) released last year. (I also have a second generation card to screw around with…)

What you described there doesn't prevent pooling, since the block could just be submitted to the pool, who could sign it.  Though a non-randomized signature could be used by using its value in the target check.

It wouldn't even necessarily need to be incompatible with multisig, since it could just support an arbitrary script.... but yea, incompatibility with pooling is worse than the alternatives you'd get instead it seems.

This subject has been a frequent one in #bitcoin-wizards.

The point I like to make is that anything you can do with script or a sufficiently enhanced script you can do with N of M oracles plus additional things (E.g. things which need secrecy or trusted I/O).   So putting something in the consensus network is merely a security improvement.   It would seem reasonable to me to expect any grand application that wants a significant script change to _first_ be implemented as N of M oracles to hammer out the use case before making the consensus system changes.

One thing I've had in mind would be to use such a system to stage any new Script2.0 for bitcoin— e.g. the oracles can just run the proposed new script directly.

There are some enhancements we could make in the Bitcoin system to facilitate oracles— for example, our multisignature system has good loose coupling, but it scales poorly: the signatures are linear in N+M. A threshold signature would be constant size— making things like 16 of 30 oracles completely practical. Though the ECDSA threshold cryptography proposed might be adequate, though it requires more communications rounds between the signers.

I have a science project grade implementation of an oracle system that I've been slowly toying with.  In mine I use the Moxie virtual machine plus some special handling for fast crypto functions, I used moxie because it's GCC targetable and an implementation of the VM is just a 1kloc switch statement— easy to audit.  My design works by the user having one or more scripts (binary inputs for the VM), which they commit to in a hash-tree. The root of the hash-tree is the ID of the script-set.   When you ask the oracle to run a script, you give it the script, it's index, and the tree fragments connecting it to the root— and also a cycle count limit which determines how much you have to pay.  Outside of the secure execution environment the oracle computes HMAC(root_hash, oracle_secret_key)  and makes the resulting value available to the script, along with the time, and other inputs provided by the user.  The script is free to then do things like generate and return a pubkey, or sign messages.  The use of the tree means that you don't have to waste the oracle's bandwidth with contingency code you never run (or lose privacy about those branches).

I didn't allow any script directed I/O in my design at all, instead, I planned on having IO done as a pre-processing stage and provided as inputs to the scripts— they're pure functions.  Turns out it's a lot easier to handle the VM security when it does no IO, it's also easier to handle resource usage when the script won't be blocking to wait on the network.

Part of my concern with resource control and IO complexity is that ultimately I'd like to have this virtual machine running inside an IBM cryptocard, with remote attestation... not just to protect the users from a cheating operator, but to protect the operator from being threatened by users that might want to try to coerce them.

I imagined the way payment would work is that you could purchase (with bitcoin) chaum tokens from the oracles for units of compute... then supply them with your scripts when you want to run them.  The oracle could maintain a work queue, constantly working on the script with the best tokens per max_cycle remaining... if you're unhappy with how long your script is taking to make it to the head of the line, you could add more tokens to it after the fact.  Though I don't know how valuable this would be to implement out of the gate— being taxed for resource would be a huge success.

There are some extra neat things you can do along these lines— Oracles are already more private than using the consensus network (absent rocket science like script-in-ZK), but you can do even better:  For a script arbitrating a transaction has a binary winner and loser where the winner takes all, you can make the script release private keys instead of signing.  By summing a public key from the oracle prior to the contract and summing the private keys after you can cryptographically blind the oracle so that it doesn't know which transaction it was deciding the fate for...

I have a hack of an implementation for cpu only— I don't have any gpus anymore, so doing more than that wasn't interesting to me. https://people.xiph.org/~greg/compressed.keys.patch

Still no compressed keys?  I'm kinda surprised considering how much faster it makes the searching.