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.

First and foremost, use sendmany.— I don't understand why you're bringing up bc.i.

Technically you can spend unconfirmed outputs, but it's advisable to avoid it.

For high throughput environments you should also avoid merging your coins beyond the amounts you'll be paying where you can, so that you'll have more outputs to spend.

Yes, an enormous difference, P2Pool doesn't just make the shares 20x more frequent than the blocks: you're credited for a three day long rolling window of shares, so more like a ratio of 8640.... even more than that, p2pool users mine at different share difficulties, when a node gets too many shares in the window it increases its share difficulty to make more room for smaller miners (once you've got a few hundred shares in the window more shares hardly decreases your variance— the variance is dominated by the block finding variance at that point).

The end result would be that the only way to get low variance would be to invest in a hosted mining company. This would not be an improvement over pooled mining.

How did you have the onion address in the first place if you don't have it now?

It was offtopic, posting about DarkCoin and IRS black helecoptors over and over again in an unrelated thread… exactly the sort of stuff that gets deleted every day. Post in the correct threads and your posts won't be deleted.

WRT having contact info for the other coins, the bcn&forks have the nice property that I don't have to constantly change the addresses to avoid reuse as I do in Bitcoin. I didn't have any Bitcoin address listed at all except I have to have one to get the moderator payments from the forum, and so I'm stuck replacing it every time it receives a payment. I posted some design criticisms in the bytecoin thread and I got asked to post a donation address, since it doesn't have the reuse problem. I'd list anything else I tried that didn't have the address reuse problem, at the moment thats limted to the bcn&forks.  Altcoins are a mess but I'm happy to take tips of whatever people want to send. Whoptie do, my profile is open and non-secret.


That things happened which you never expected are all the more reason to not take the concerns or criticism personally.  That people are finding cause to speak out aggressively is because of the promotion other people are doing, ... but you don't control them so you shouldn't worry about it too much.

I'll be glad to look at it when its actually released. I don't have the time or interest to review closed systems.

Your BCT account looks suspiciously like one of the ones that was sold after the bct hacks last year.

Do you have the onion address you were given? Do you still have the bytecoin wallet?

I want you to sha256 all the files you have related to bytecoin and post the hashes, then we can ask further questions about them.

You claim here to have been mining with a laptop, but your posting history doesn't support that, e.g.:

As someone who was there and involved in dealing with it I don't recall any _dispute_, I'm really unhappy about the history revisionism people throw around hwere— it was obvious what needed to be done: there was a chain that was acceptable to all nodes, and a chain that was acceptable to a small minority (which, on quick testing didn't include many major businesses)— because of the consolidation of hash-power around pools the mining deployed software looked very much unlike the systems overall, but even if it had been a slim majority only one was acceptable to all nodes.  Being acceptable to all nodes meant that the issue could be healed back to consensus immediately— as soon as the acceptable-to-all chain was also the longest, the other side would have meant weeks of split consensus as people gradually fixed their software.

Not including the two (IIRC) other OT posts of yours that I outright deleted.

Uh, yea when the coin has no real value to folks and is just a speculative bubble or a speculative hedge... thats what happens. Not my cup of tea at least. As I've said, I normally leave the altcoin stuff alone— except for the rare novel idea, or someone pulling me in for an opinion in one way or another.

I agree that the config change is a hard fork, but the point of my post was to point out that those old versions do synchronize okay, they're just unreliable on reorgs involving large blocks depending on the phase of the moon (really how many BDB pages the transactions being modified span).

That there was non determinism wasn't a surprise. It's not even the first non-determinism, the handling of rewrites on reorgs for duplicate txids was also non-deterministic (behavior depended on which order the node saw a series of forks), which was why it had to be fixed. Absent a formal proof you can't be sure software is bug free— or even with one, considering the bugs that have been found in compcert.

There has never been a single political debate about buggy behavior like that, and I never expect there to be one.  Non-determinism in a consensus system is a fatal error, no one has any impression that it ought to stay. A document also will not reliably resolve non-deterministic behavior, since the behavior that would have been non-deterministic would simply have not been specified in the document.

You can sync up a totally unmodified 0.2.10 node, or initial release if you add a gateway to deal with the checksum on the version handshake. They're just not reliable in the face of reorgs (they'll get stuck on reorgs involving large blocks). If you drop in the one line bdb config change, they're even somewhat reliable (but SLLLLLLLLLLLLLOOOOOOOOOOWWWWWWWW).

Fwiw, as far as I know bitnodes.io filters out pre-0.8. There are actually many still running. Though presumably most of the ones that aren't stuck by now have the bdb tweak in place.

I will, if someone remembers to point me to it— ideally if it also comes with a high level design document so I don't have to extract all the behavior from the code (doing so is very time consuming).

As an aside, and apart from the privacy tech—

Whats with the claims here that the subsidy was changed after some millions of coins were created?  Thats pretty damning if true— shades of Solidcoin.

The whole too-low-initial-difficulty plus exponential distribution thing seems to be a trope now. Bitcoin's initial difficulty was high enough (relative to existing hardware and software) that it couldn't even keep up with its 10 minute target during the first year.  If I were crazy enough to launch an altcoin I'd set it so that the real mining didn't begin until it crossed some somewhat reasonable difficulty to reduce the land grab intensity, because it smells pretty fishy otherwise.

I couldn't figure out what you were saying, thats why I asked.
Because not being open on (or even before, at least in the form of a clear technical whitepaper) day one is bad, but it only gets worse the longer it goes on.

If it were open source and usable then presumably it would have been adopted. Even as an altcoin, if it were something good I'd speak positively of it... even if the system itself weren't open a clear description of the techniques it was using (like zerocash has) in a whitepaper would allow peer review and analysis of the techniques without the crappy competitive landscape of the altcoin ecosystem coming to play. Keep in mind though, 99% of the design of these things in 99% of the cases is straight up copied from Bitcoin. Before anyone is too territorial about their own precious inventions, they should keep in mind that they're just variations of a tune created by giants whos shoulders they're standing on— something only possible because those people released their code and their designs instead of keeping them secret.

Must wouldn't be the right word— should would be more correct.  In systems of money Metcalf's law applies much more strongly than in other things because the value of a money is derived exclusively from its liquidity and from people being willing to accept it. If our hope is that trustless cryptocurrencies are broadly successful, we undermine that effort if we disrupt their network effect over and over again by starting a brand new currency for this feature or that. It's like having to build a separate internet per program, madness. There is no technical justification for it... and it endangers the success of the entire field, at least to some extent.  Some starry eyed folks think this is a revolution which cannot fail, I am more cynical than that. Doubly so when the frequent outright scams and failures discourage people from investing in infrastructure in the space.

If there are actual good things developed outside of Bitcoin, I'm happy to see them.

As an aside— the "so and so has XYZ foocoin" assumptions might be pretty spurious, its completely reasonable for people to sell off large amounts of coins they have while they're nearly valueless— if you have a lot and who knows what the future holds. I know this is true for most people who were involved in Bitcoin early on, it may well be true for other things. Or not.

Bitcoin does not have only one set of developers. There are several complete re-implementations, some with active development bases— something you can't say about (AFAIK) any of the altcoins. Moreover, the permissive licensing of Bitcoin means that you aren't, and shouldn't be, dependent on any particular developers... you can freely fork the code at any point for any reason, and many people have. For similar reasons, people working on Bitcoin generally don't make incompatible changes in the software (with a protocol gateway, Bitcoin is compatible with the very first release, and without a gateway, 0.2.10 from 2010 will still happily synchronize with the network, though old versions are not very reliable anymore).

If you're depending on developers to take an active role in the real operation of you decentralized cryptocurrency then it's not really all that decentralized, it's still controlled by the politics of men instead of math. Having a choice of one master out of many is not really freedom.

Another coin heavy with closedness, its hard to analyze and so you won't see much if any serious review. The initial snippits of code they published had a clear and obvious nothing-at-stake vulnerability, and so far I've not seen any explanation as to how its actually viable at all. Perhaps none of the people who actually understand it speak english, but the people who've recently posted about it in the tech subforum didn't give a positive impression at all to others who are clueful about distributed consensus systems.... but this is totally offtopic here.

Anonymity isn't a binary state, there are degrees. Really strong anonymity is very hard to achieve, and needs more than just some features— it's a lifestyle, even a state of mind. I think perfect anonymity is generally beyond human capability except in very limited circumstances.  _Better_ anonymity, or— perhaps more correctly stated as "better privacy"— is possible... and things like the darkwallet and the other tools that implement coinjoin in Bitcoin let people get better privacy today.  Even stronger privacy is possible, but it comes with tradeoffs, which is why it might not be desirable to implement the stronger systems in Bitcoin even though we know how to create them.

Because some darkcoin pumpers showed up in an entirely unrelated thread and started crapping on other people's efforts in order to promote DarkCoin. I certantly wasn't interested in seeking out this discussion, but since it came to me I don't have any problem in responding to it.

Things can be unfair or a bad deal, or simply a failed offering without being a scam.  I too might too easily lapse into the language of "scam" around here, — and there is no shortage of actual ill motivation in the altcoin space— but I do think more of it is really people getting in over their heads.  Cryptosystem work is very difficult, and Bitcoin seems to have resulted in people thinking that creating this stuff is no big deal since they can just copy the code... but in a cryptosystem the details matter, greatly... a single line changed can have subtle effects that ruin the security properties completely.

Hm?  Thats pretty weird, considering that I've said nothing positive about Bitcoin here, and only positive things about cryptocoins (and proposed cryptocoins) that I have had basically nothing to do with.