Yes it's enforced now; at least by the potentially-minority parts of the miners that are actually enforcing any rules at all.

The message was briefly up for 0.10.2 because 0.10 had failed to increment the protocol version and I failed to account for that. The there are two alerts which are active right now covering everything prior to 0.9 plus the specific subversion strings for 0.9.0-0.9.5.

It's possible to do, prior proposals were dismissed as paranoia. I expect that even the evidence now won't be enough since this expirenced will be discounted as "sure, they were doing that before, but they won't do it again".

And now, you know why chinese pools thought they could survive with 8MB blocks.  Ultimately any proposal to inhibit SPV mining is going to interact in politically complex ways with the block size discussion.

There was about 4% of the hashrate remaining mining old invalid blocks; these SPV miners would extend them-- effectively boosting the invalid-block mining portion of the hashrate to 50% the moment one of those 4% miners produced an invalid block.

Miners that do not verify, even if they don't include transactions, are a huge amplifier on anyone who mines an invalid or malicious block for whatever reason; and are obviously a grave risk to the system.

More of these forks may still happen-- if these large hashrate miners leave the SPV mining code in place, there still is a few percent mining invalid blocks--- I know for the deployment of the P2SH softfork "50 BTC" continued mining invalid blocks for roughly a month.

SPV nodes made it up to 6 bogus confirmations.

There was basically half of the network hashrate extending an invalid chain.

To spare a little credit here; I'm unconcerned in part due to reasons that he was previously unaware of-- I think if I knew only what he knew, I would have been concerned. I'm thankful that people other than the development team are also thinking about these things and raising concerns; and I welcome it (though think it's much more productive if they're expressed in the most polite way possible; simply because adding emotion almost never makes a tricky situation easier)... it's just in this particular case I believe the concerns are adequately addressed for the moment, but I don't mind answering questions about it.

Yes, I estimate it could be corrected in under 5 minutes right now.

WRT result, the primary thing the alert does right now is triggers the error bar in Bitcoin Core and the alert notify output; which almost no one will notice. Past notices have had very little effect in general.

More or less incorrect on both counts. Yes, someone can send a message-- but that message can be disabled, locked out, and replaced with a key compromised method by anyone with the alert key.  For security reasons everyone who has the alertkey is not enumerated (so that someone can't attempt to suppress use of the alert key by targeting multiple people). Multiple people currently active in the project have the key, and there are also other security measures in place.

I hear your concerns. You're not the first or only one to express them; but I believe there is still a more professional cooperative way forward available and I think we should make use of it to the greatest extent possible.

Because of the huge risks and dis-economies of scale (supplying cooling and power at the multiple megawatt level is severely problematic; with installs wanting 20 year contracts and other such fun stuff).  But we're getting off-topic here.

I'm not sure if he's ever identified himself or been identified;  see https://bitcointalk.org/index.php?topic=381687.msg4133974#msg4133974

Cointerra actually shipped me hardware, it was a month late, under-performing and not super reliable--  it was still a MUCH better deal than Hashfast, which was just a pure money sink. I think the cointerra stuff delivered about as expected in risk return turns.

HF had much stronger promises, a full refund policy if they failed to ship-- claims of external investment to fund the operation instead of pre-order money, and a program to deliver hashrate if the miners didn't turn a profit.... and their claims were backed by community regulars who'd visited their facilities in person.  Turns out that they'd taken _massive_ payments, which themselves alone made it impossible for hashfast to deliver on their contract obligations (Can't give a full in-bitcoin refund when you've already given 10% of the Bitcoins away, not with Bitcoin prices rising).

The whole situation with crappy mining companies has done serious lasting harm to Bitcoin.  Small scale mining works _fine_, there are fundamental space/power advantages to not having large installs; and it's a fun real way to contribute to the system--- the real "economy of scale" in Bitcoin mining that actually exists is dealing with the fraud and fail laden ecosystem.   Sketchy companies have a severe commercial advantage because fantasy can always outperform reality.... and basically little incentive for parties to deliver on their word (or even close to their word) because there is basically no repercussion for breaking it.

It's going to take time, education, and effort to heal all the damage done to Bitcoin on the mining ecosystem side, but I think it can be healed...  but it's certainly a lot harder to foster integrity in the ecosystem when there remain no repercussions.  There is only so much we can do however-- prosecutions of "white collar crime" are thin; the perpetrators can throw up a smoke screen of plausible deniability and can afford to fight back.  I'm not just whining here because in this case I actually lost money-- I've made similar comments e.g. related to Zhou Tong even though I lost narry a cent there.  If we are talk about how disputes can be settled without constant (costly) recourse to state authorities (which are often helpless in the face of international disputes in any case), then we also have to live up to it; and at least take what measures we can within the community to protect each other through tools like reputation and social pressure.

We don't really use the alert mechanism, and many of the contributors to Bitcoin Core would like to remove it-- because the value it provides is very low, relative to the administrative overhead we receive in terms of people justifying non-starter proposals based on it (e.g. wanting to use it to remotely control miner default behaviour) or just the cost users have in reasoning about its security implications for them.

That said, there is very little potential for abuse, because if a bogus alert is sent a special alert can be sent that disables further use of the alert system erases all other alerts and sets a static alert key compromised message. As a result, active misuse is already effectively constructively disabled.

And all without fanning any extra drama.

Dunno about that;  after the hashfast failed to deliver many people neg rated him--  and he made it out like he just got some discounted units from them that he lost money on, like the rest of the customers.  Given what he said before understating his involvement, and the fact that he'd claimed that he only benefited if it panned out-- it sounded completely believable. Many people who do equipment reviews, software development, etc. for mining don't get anything more than some free hardware and often just engineering samples.  I pulled back my negative rating, and others did as well; incorrectly sparing his reputation.

After hashfast blew up (I lost ~100 BTC to it, got nothing in return-- bummer considering they'd promised early customers to return deposited coins if they failed to deliver), I negatively rated Cypherdoc on the forum -- after all, he pushed this stuff hard and if reputation is to mean anything at all your reputation ought to take a hit when you promote something that rips people off.   Cypherdoc then emailed me and convinced me that he was just another victim, that got discounts for some promotion-- sure-- but his orders failed too.  I took down the rating. People make mistakes, and being another hashfast victim would be punishment enough.

I was quite surprised to read the complaint-- to learn that he'd been paid an astronomic 3000 BTC for his "promotion" services in addition to discounted hardware that he was refunded for (while many other customers got nothing).  It's also more than a little perplexing-- as a developer of Bitcoin and a moderator of the mining subforum payments like that seem completely out of line with anything I've experienced-- some people get a single demo piece for review and such, or an engineering sample for driver developer but I can't fathom what would justify payments like that, and I can understand why he's being sued to recover them. Doubly so because in my experience while cypherdoc is a long time participant, he was not all that well known outside of certain niche areas of the community (his claim to fame is the "gold collapsing" thread he started), and he appeared to have no expertise in mining that wasn't held by thousands of other participants.

Though my opinions might be colored a bit by the fact that since that time he's been rather rude and aggressive towards me in public (I suppose he's the expert in financial conflicts of interest if nothing else, 'enh?)  ...  but I only restored my negative rating of him on the forum after discovering that his poor-me act was just an act, and that he was by no means just a victim here.  I think he should return the funds which were fraudulently taken from hashfast customers; and that his hundred some shilling posts should not entitle him to walk away with a massive profit while so many of hashfast's customers-- some who did buy specifically on his advice--  have received nothing in return for their payment.

If indeed there was some greater fraud afoot, the parties involved should still find it greatly in there interest to settle this matter as fast as possible before its details come to light in discovery.

The requirement is that it meets all the prior validity criteria (e.g. is locked) and that it is more preferred (plus some additional requirements on what its permitted to conflict with)-- at least thats the intent; you'll need to analyze the implementation, not a forum post, to determine if it accomplishes that.

Read the actual report, in particular http://www.tau.ac.il/~tromer/radioexp/  Q11 and Q8.

Bitcoin Core uses signing which is constant time, constant memory access, and hardened in several other ways against side-channel private key leaks-- and specifically designed to resist these attacks. Actually being leak free also depends on the hardware, but at least in Bitcoin Core the software side of it is much more robust than the kinds of systems they were attacking here.

I'm a bit young to have been a roadie for CSNY in the mid 70s, but heres the oldest picture of me I can find to aid in your diligent sleuthing:



(God knows, one of you will find a picture with me and John Perry Barlow and consider Glebs most crazy theories confirmed... and I can imagine little funnier than that.)

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.