Orthogonal, there was an update which included a non-consensus change to pass through the higher version number that bitcoin core was already providing, as well as a non-consensus change to require Bitcoin core 0.10+, plus a non-consensus change to emit p2pool share v14, plus a p2pool-consensus change to enable requiring share v14, so that it's possible to fork off the participants who haven't upgraded once BIP66 has taken effect.  The latest p2pool block was v3.

Unfortunately, people thought that upgrading bitcoin was sufficient for p2pool to emit version 3 blocks, but unfortunately there was a min(template.version, 2) in the codebase; I didn't get around to checking until a couple days ago. Forrestv fixed it nearly instantly after I emailed him about it. Sadly, P2pool is hardly even a thing anymore... but the remaining users upgraded quickly and about 63% of P2Pool's hashrate updated in about two days, which I think is pretty good.

Minimum of 212 blocks until BIP66 enforcement right now (as of height 363020).

Pray tell how you will replace ECDSA when the coins are already assigned to keys for it?  (and when everyone and their sister constantly reuses addresses). A compromise of CT would mean that it was feasible to find discrete logs in this group, with that, anyone who learned your public key could recover your private key.  There are scenarios where the hashing, absent any address reuse, helps  (e.g. say the discrete log finding takes weeks)-- but it's important to not exaggerate the gains.

But indeed it isn't the ~quite~ same.

It's perfectly possible to construct schemes for private values which are unconditionally sound; meaning that there is no cryptographic assumption behind their inflation resistance, and a cryptographic break would only result in a loss of privacy.  I had previously thought that it was necessarily the case that any such scheme would have to be less efficient; but I have since realized my original reasoning for that was incorrect; though I do not (yet) know of a way to construct an unconditionally sound scheme which is anywhere near as efficient as CT;  but finding one is on my TODO list (though it falls below other improvements for CT privacy and network security that I'm working on).

No, not at all-- it's just the norm to think about and describe protocols in terms of "people" making moves in a game.  All of this is automated and performed by computers.

No, it's possible to trustlessly coinswap in and out of such a system, with no detectable connectivity.  And there are many reasons to use such a sidechain, such as improved smart contracting.  I consider improved fungiblity to be an essential basic feature.

Unfortunately, it's appears that it isn't possible to trustlessly swap in and out of monero because the developers of bytecoin didn't carry across smart contract functionality which they didn't understand.  Perhaps the capability could be added later.

my logs have those from before, even days ago;  though not multiples.

No offense intended, but you really need to read http://catb.org/~esr/faqs/smart-questions.html   as, for all the time you spend photoshopping the cute image you question doesn't offer a single one of the essential details needed to begin a useful answer.  Asking technical support questions is skill which you can improve and which is critically useful.

In particular--

1. What version are you running? Where did you get it from? Old versions have known memory usage issues which have been fixed, spending further time on this is pointless if you're running an old version. Likewise some parties distribute patched versions with different behavior.
2. What operating system are you on and what version?
3. How are you measuring memory usage?  People often confuse virt and actual used memory. Virt includes memmaped files.
4. Is your system exposed to the internet (e.g. could someone be DOS attacking it.)
5. What patches or settings are you running the software with and are you using the node for anything or just leaving it running?

FWIW, as an example my mining node which has been running a self-compiled copy of 0.10.2 continually since a day before 0.10.2's release on 64bit lLnux and standard dbcache seeings has a current resident size of 701MB.

Egads, what a boggling thread. (I will not be sending a christmas card to the mean person that sent me this link! ).

Go read the context.  Someone was asking me why I'm not doing the some PR blitz to influence people's thinking.  My response was that I don't care to win people over, that if Bitcoin's survival depends on constantly making rescuing it with a political sales pitch and a mass market PR campaign then I think that would mean that its already a failure.  I don't actually believe it is a failure but I'm not frightened of it becoming one, though I'd think it would be a bit sad to have wasted many years chasing a windmill and for the world to lose this opportunity;  but that said, I can just leave if it goes the highly centralized route, and go work on something that still has a prospect of success-- there are just too many important things that need to be done.  I don't think there is anything "threatening" or anything about that.

I care a lot about defending, protecting, and nurturing the system, but not so much that I feel compelled to go around trying to reprogram people to get my way.  To even admit that doing so would be possible is an admission that the system cannot work.   So I'm happy to continue to just communicate frankly in the forums and means that I normally communicate in and see how the experiment pans out.

Unfortunately, Andrew Poelstra was able to break the cryptosystem for this scheme's range-proofs.  The author is working on fixing it, and I'm hopeful for progress there. This may take a bit of time, so if you're looking for something to test right now the CT feature in the Elements/Alpha is the best that is out there  at the moment.

Hi j0kie_smurf,

I welcome your enthusiasm and interest!  You probably want to do some more research on cryptosystems: The output from SHA256 really is 256 bits long. There is no primitive 256 bit type in C/C++ existing hardware, so this 256 bit function is returned using smaller types (e.g. 8 32-bit words).

SHA256 is not an encryption function, but a cryptographic hash (though its possible to build encryption using cryptographic hashes).  There is no encryption in the Bitcoin protocol (the only encryption used in the system is in the wallet).  The cryptographic constructs we use are openly developed, distributed, and widely reviewed. There would be no benefit in keeping their implementations secret, as a principle of modern cryptosystems is that they should be completely secure even when the attacker knows the process exactly (which is a good principle, because its often impossible to keep the attacker in the dark about the process in any case).

I'm not sure where you seeing the "only uses 20 bits" and such from, if you were able to show such a simplistic divergence from random from sha256 it would be a remarkable discovery. I suspect you've just misread the code on that point.

In any case-- I wish you luck on your investigations and learning. Cheers,

Oh don't feel let down. It's highly technical and many people don't understand it.   I'm certainly super excited about it, but balancing a bunch of things right now so I haven't had time to give more feedback than I have so far (thanks for so swiftly integrating that!).

When I first explained the concept behind coinjoin it went nowhere, I had to do substantial work to write a plain explanation and simplify it all down, before people paid any attention at all.   When there is an implementation and such you'll see more interest as well.

For whatever it's worth I consider your work important. Between the soundness and efficiency improvements I went from thinking the probability of deployment of CT in bitcoin proper (rather than just in sidechains) was low but non-zero to-- with your scheme-- a view that its even likely eventually. (assuming Bitcoin doesn't get usurped down a privacy unfriendly angle).

I don't think it's all that interesting: It requires that you trust the miners implicitly for the history, and if you're willing to do that you can use SPV which is much more efficient. And, I say this as the person who originally proposed state commitments in 2011: https://bitcointalk.org/index.php?topic=21995.0

If, for whatever reason, one really is interested in an in-between mode: a side effect of elements alpha witness segregation is that you can sync the chain while skipping 2/3 (to 95% with CT) of the data, but still have perfect security for the utxo set.

The txout commitment schemes have a non-trivial cost for full nodes as the txout set becomes large, e.g. requiring on the order of 20 times the amount of I/O--  so a one time miner trusting init takes less bandwidth but then you have much higher IO and CPU ongoing; so it's not actually clear to me that they're a win; even ignoring the security trade-off... which is part of the reason that they haven't moved forward in the Bitcoin space.

Some of the other things in the miniblockchain stuff are just incorrect. Like it claims to not have transaction malleability; but it does due to the inherent DSA malleability. I don't recall other features you might have been looking for.

There is nothing sloppy here, the software is literally over a hundred times faster than it originally was, and much more reliable too-- in general. What it's doing is just fundamentally hard-- it is independently and autonomously verifying over 70 million transactions.  There are many recent improvements and more in the pipeline, and more that we know are possible but haven't started on yet... but nothing can magically make it fast and easy.  And these reasons, among others, are part of why almost all of the developers of Bitcoin Core are not in favor a >2000% increase in operating cost as a step function in the recent block size drama-- if you think it's bad now, try it with several times the load.

It's doing this because this persons state is corrupted and they have rejected the chain as invalid.  As far as its concerned these peers are just attacking it by feeding it invalid blocks.

Why precisely it rejected the chain is hard to say without a log of where the rejection happened, and even with those logs it can be hard to know why without more testing. This can be due to hardware errors, or due e.g. to antivirus software corrupting the database. (or bugs, but I am not aware of any that would cause chainstate corruption right now). The corruption can be resolved with a reindex, but without knowing why it happened it may just corrupt again before you even finish the reindex.

Unfortunately, Bitcoin is a fantastic hardware test. (The unfortunate part is that a surprisingly large amount of hardware is slightly flaky)

I just found out about this and it blew me away.  When the crap hit the fan and hashfast refused to make good on their promises to early customers I'd down-rated cypherdoc-- after all, he traded on his reputation to convince others to buy and when it didn't go as he presented if his reputation didn't take a hit, what good is reputation as a signal?   Subsequently he convinced me that in spite of his paid shilling he was mostly just another victim of this mess and convinced me to remove the rating; the shilling was crappy, but everyone makes mistakes and his "losses" in hashfast surely were enough punishment.

Today I read that litigation and discovered that he actually received 3000 BTC for his shilling services plus other considerations (and even a refund on an order), and walked with it while so many of the rest of us got squat. What the ?!?! So much for just another victim!  I've gone and restored my negative rating, damn.

It's not as simple as that, e.g. I could grind the circuit generator to find 'random' hash algorithms which a heuristic solver of mine can answer much faster than naive execution.  There have been some altcoin POW proposals that failed pretty seriously to this.

It's also the case that whatever parameterization you create, someone can just create an ASIC specialized for it... if nothing else stripping excess IO pincount and other costs.  Keep in mind, CPUs are ASIC too, ones with incredibly complex, secret, patented designs-- which can be mass produced by their makers at a marginal price which is a tiny fraction of what they sell for... "Be careful what you ask for".

CPUs are asics. The specific thing you're asking for is deeply impossible. The best you could ask for is something where existing general hardware was not worse than specialized hardware, and that seems really likely to be impossible too, simply because by definition general hardware will have "fat". If nothing else it's perfectly fine for a miner to run at a error rate approaching 1% (sometimes more!) but you'd never design a CPU to operate under those conditions. Since mining, by definition seeks towards 0 profits, even small factors like 10x efficiency would easily make a general purpose part totally unusual-- but perhaps your question is not really related to mining. But then as I pointed out above, even if you were successful, the result might just be giving a free license to Intel and AMD, which probably wasn't what you wanted.

I can't say that it's impossible to do better than the work-function bitcoin has... but it's very easy to do substantially worse.

As a point of order; since this seems to be a common and oft-exploited set of misconceptions.

Or the proposals to add censorship to tor that _seriously_ pissed off the tor developers? Or the coin confiscation proposal? Or the near constant, first short recourse to centralized, authoritarian solutions-- at a level of consistency that it would be a comedy if it weren't so sad?

Mike has never been a core committer-- he's only ever submitted a couple patches, in fact.  His work has been mostly on BitcoinJ, which is whats used by android wallet and multibit hd. He's certainly knowledgeable about the Bitcoin system, so I point this out only as a correction-in-fact not a judgement statement.

Gavin does not lead the Bitcoin Core project-- the project lead is Wladimir and has been for some time (and I mean this in actual documented agreed on roles, and not just in terms of activities), and Gavin has been largely inactive for the last year (I don't say this to complain-- he was very busy with troubled times at the Bitcoin foundation).



You have some comparison a bit backwards there, there are other people lobbing for a sudden rule change to the system-- against substantial controversy and out from under the preferences of a substantial minority (e.g. your poll shows a quarter in opposition) whos interest you might want to explore.

Two of the Five people with commit access to Bitcoin core (or a half dozen out of a hundred contributors) created Blockstream to build some important tech that we the space need (and had been lamenting it's non-existence for a long time before we went and found a way to fund doing it!). As the primary technical innovators in this space (certainly if you exclude altcoin work) we can be assured good consulting incomes so long as we keep doing good, important, quality work-- regardless of what happens with SC or LN... and we have a _long_ backlog of powerful technology that we couldn't release for use in Bitcoin without it just ending up in an altcoin before the prospect of sidechains.  But no matter what you protest, you cannot stop LN or SC from existing in some form or another; and they offer advantages Bitcoin by itself fundamentally cannot: e.g. LN can give _instantly_ irreversible payments-- think of all the applications that hold of on using Bitcoin for lack of that; but it's not possible in the plain Bitcoin system.  Look at CT-- we can't just go and try that in Bitcoin and figure out how to advance it, prior to SC there was no avenue to adapt to new needs without picking switching from Bitcoin to a competing currency. None of these things have anything to do with block size, and-- in fact, both SC and LN _strongly_ prefer the biggest blocksize the network can handle.  What they can't tolerate, however, is Bitcoin being very centralized-- and I don't think your own interests can tolerate that either (assuming you still own some Bitcoin).

I bring up spinoffs beyond it just being an honest question because it was your argument on these points-- why worry about what happens to bitcoin when we can create some altcoin that enriches the existing bitcoin holders.  I don't know how much this perspective influences your position here, arguably a spinnoff perspective would strongly prefer original bitcoin would fail, it it would just transfer ownership into a new network before people notice and buy up their coins on the cheap as the developers of counterparty did. ::shrugs:: It's easy to throw rocks about conflicts of interest. But the reality is that the arguments I've presented are straightforward, coherent, extend long before any plausibly argued conflict of interest, and are shared to some degree or another by almost everyone in the technical space, including ones which no amount of fevered imagination can construct a coherent conflict of interest story.

(And at least in my case you know who I am, what business I'm in, what my history is, heck I've even shared details of my employment contract with you---- this is not the same for most other people. But even with that opacity, it's easy to find "shadows" of conflict of interest, if someone wants take your approach of claiming any that can be claimed whenever it supports an argument)

Though back to your question, if you've given up on spinoffs as a salvation-- what do you think is going to make Bitcoin competative against the eventual altcoin that actually gets the formula right and makes significant, no compromise, technical advantages over Bitcoin--- and probably doesn't bother to cut you in on it?  Keep in mind, most of the people we hope will some day use Bitcoin haven't even been born yet.  Unless we fail and sully the potential for cryptocurrency in the public's mind, this is only the very beginning of a long history.

Your selective quoting ignores how this was a response to a 'how could this possibly work at all'.  I've used the same kind of response to "omg flooding network! how could that possibly work! it's completely non-scalable!" -- to point out that even non-scalable can achieve some remarkable stuff.  This doesn't answer any particular question about the exact tradeoff that works, but works to wake people up.  Particular because before Bitcoin the alternative was exclusively centralized systems so when you show that if you don't care about decentralization (which you must not if you question the value it provides compared to all that came before) then it can reach arbitrarily high scale.

We can't hope to guess at what anyone from back then would think about the current state of the world, though we do know that e.g. the current mining ecosystem would have been regarded as a system failure from the original precepts; and we also know that decentralization and autonomy were principle motivations for the creation of the system in the first place.

While I'm here, hows your Bitcoin Spinoffs project going, Cypherdoc?

secp256k1 is self contained. GMP is optional. Releases of Bitcoin Core do not currently use GMP.

Libsecp256k1 is still unreleased experimental software. Our use of it in Bitcoin core is intentionally very narrow (only for signing, always checked against OpenSSL). I would not advise using it in a production consensus system currently. If you're interested in using it-- you could help support its maturation to full release by supporting review of the software.

Thats a complete misunderstanding, and I have no clue where you could have gotten it from-- can you specify so I can go hunt down that location and get them to fix it?  PM please-- this is offtopic for this thread.

The computation on BC.i is darn near a random number generator. The main thing it accomplishes is making people think they're more (or, infrequently, less) private than they are.