Yes, I'm referring to later, not so kind of you to sit quietly amid all those claims that I was lying... when you could have instead happily bragged that you knew all along.   Oh well! I forgive you.

AFAIK I never posted about it on bitcointalk at all... perhaps if I had, I might have posted on the S9 thread. (although most of my testing was actually on an R4 and parts from R4s ...)

They claim this, but the claim seems kind of absurd. The whole point of covert is that it's cover, it's nearly impossible to detect.

Consider though: at great expense they developed an significant performance optimization and baked it into their chips, huge numbers of which they ran themselves ... and then kept it secret but ... just didn't use it?  Why? because they like giving money away to the power company?

There is evidence that bitmain was asicboosting: among other things (Edit: e.g. as frodo mentions, the huge number of empty blocks, which have more or less magically gone away), they mined a small number of blocks that were invalid because transactions were out of dependency order. This would be a pretty difficult mistake to make-- unless you were grinding blocks by swapping around transaction order.  It's just not conclusive proof, unfortunately short of some massive internal document leak conclusive proof is likely impossible.

[Edit: The empty block part is really strong because unlike any other case you can compute the collisions for the empty blocks arbitrarily far in advance, so even if takes you tens of seconds to find one on the FPGA you can keep mining until one is found.]

Of course, there is also no reason to think that bitmain was the only booster.  I think its very interesting that the bitmain funded developers of bcash pushed surprisingly hard for their "canonical transaction order" change shortly after bitmain published overt AB support for their existing hardware... Might well be that once covert boosting wasn't an advantage it was best for overt supporters kill it on bcash in order to disrupt any miners whos hardware was less flexible than Bitmain's. (Because Bitmain used a rather overpowered FPGA for control they could switch between covert/overt/no-ab with just a firmware change... it would have been more power efficient though to have a separate asic for collision finding, but such a design might result in devices that lose half their hashrate when used with a mandatory transaction order or otherwise have to only mine empty blocks...)


Wow. No, I completely hadn't seen that-- I mean it was buried deep in a thread about a vendor who's hardware I didn't have at the time, and didn't mention asicboost in the post... all the details were in a pdf... I wouldn't be surprised if almost no one ever read it.  Too bad, because that was a pretty big revelation. Kudos to you.   It would have saved me an astonishing amount of time if I'd been aware of it.  (in particular figuring out the how to use the multi-midstate with no actual docs on the chip but simply picking through the software and bus captures with unreliable information extracted from the chip design was a big chore).  

As an aside, given that you knew this-- how come when I announced it and so many people were saying that I was lying about it being there, you didn't step up to point it out?

inb4 50k "2x".

Virtually every mining device is a general purpose computer running linux plus a fixed function accelerator.  Is this so different than, say, an android phone which has several fixed function accelerators (like the speech detection 'hello google' hardware, wifi modem, etc.)?

I hope everyone who gives a darn about Bitcoin avoids doing business with Bitmain in the future. Bitmain has been a long standing bad actor in the cryptocurrency ecosystem. We shouldn't forget this just because they replaced their CEO.  As far as I know they have done nothing to undo the damage they've caused or otherwise make amends.  We can see by their continued open source license violations in their products that they haven't changed.

I will award merit to every post that makes a compelling statement against buying from bitmain.

Poe's law man, poe's law.

The bamboozled are going to feel pretty cheated when they figure out that I'm just some nobody that got targeted because of my lifelong promotion of freedom and privacy technology. It's probably no accident that "hacking team" was sending out newsletter claiming that bitcoin could become an establishment threat if got improved privacy and then I become a number one target, complete with an over the top disinformation laden NYT hit piece, short after after I published a design and implementation of Confidential Transactions.  

They're claiming they will be able to do payment channels and lightning, but until they implement the rest of their segwit-under-another-name hash/txid split, they likely won't. Schnorr plus the aborted BIP62 implementation they copied from core aren't enough.

https://www.reddit.com/r/btc/comments/axza7b/id_love_to_get_an_update_on_what_is_happening/ehzhki0/?context=3

(turns out that without using minisketch they can't get within an order of magnitude of the known best case for almost pointless marginal optimizations... and it's kinda hard to make a case for how much better you are when all your examples are copying the people you're trying to say you're better than. )

Anonymous account shows up relentlessly promoting a tool that uses custom non-standard cryptography to generate keys for users-- e.g. showed up on #bitcoin and within a week had shared the link 35 times. The claims on the page are outright false (e.g. saying that its quantum safe in ways bip32 are not) meaning that the author is either too incompetent to be writing cryptographic software for public use or is intentionally lying to snow users into using it.

I would strongly urge people to not use this software.

The behaviour you are describing is the perfectly normal behaviour of a new node coming online.

No, the version string is not used to ban peers, in fact taking any programmatic action on it is expressly specified as "strongly unrecommended and extremely bad form."

Your version string example is probably some brain damaged scamcoin client which failed to change the port and protocol magic and it probably got banned for sending invalid blocks.

BIPs are just a publication numbering scheme. They do not indicate that a proposal has been adopted anywhere, or even that it isn't extremely and dangerously broken.

BIP64 IIRC had an immediate "take out all nodes" grade vulnerability, so it wasn't adopted by Bitcoin.

Allowing random completely unverifyable access queries to a node's UTXO set was never shown to be particularly useful in any case (e.g. the application given for it required its own server anyways, so its server could just answer its queries), commits a node to making available data which might be eliminated in the future, and risked creating bad incentives (E.g. making it attractive to use Bitcoin's UTXO as a file storage service)... which goes to explain why (IIRC) no one picked up that effort got a version with the vulnerability fixed adopted.

Don't use closed source wallets.

If anything this incident increases my (nearly zero) estimate of this wallet's security: Someone looked and found at least at the moment it was sending the key material only to Google. That is more secure than should have been expected.

Don't use closed source wallets.

Don't use wallets that support a zillion different cryptocurrencies (just supporting one securely is a task too hard for basically anyone to get right...).

Don't used closed source wallets.

I'm sorry to hear about the OPs loss.

Don't used closed source wallets.

If anyone needed yet another example why the world of cryptocurrency is a cesspool... and why thoughtful people usually run for the hills-- and leave tech forums looking like ghost-towns with little interesting traffic left, well then I guess one has been provided.  I thought I gave a brief but reasoned point by point argument that made the case both from first principles and then again drawing from actual results. I might have expected a response in kind but instead, the response is a litany of abusive invective and personal attacks making it clear that my time-- and everyone elses here-- is just being wasted.

You dare not challenge the strongly held prejudice of the forum warrior. You just don't.

I originally thought this thread was likely to be a train wreak and didn't bother commenting. But I was in a good mood this evening... some day I'll learn.

On the surface at least progpow looks like straight up corruption. If ethereum users won't fall for it, there isn't a chance in hell bitcoin users would.

It appears very unlikely that "asic resistance" is even possible, but putting that aside: there is also little evidence that it would be desirable.  Absolutely asic mining has created a multitude of problems but something having problems doesn't suggest that any particular alternative is better... the alternatives to common practices with known issues are often much worse.

In particular, essentially by definition every "asic resistant" approach I've seen shifts costs to from highly commodity energy (the overwhelming majority of the lifetime cost of a sha256 mining device is power) to highly illiquid upfront manufacturing. (e.g. bitmain s9 last year hit power cost = purchase cost at about 3mo of operation) The economic arguments for mining potentially producing a secure and decentralized system depend on an ongoing cost-- if you reject those models you end up with something more like a quorum of trusted signers (e.g. "bobchain").

Manufacturing centric costs also seem highly prone to even stronger monopoly pressures both due to  government granted artificial monopolies on manufacturing techniques as well as natural monopolies arising from first mover advantage for a highly amortized R&D heavy cost model compared to a commodity energy cost model.

This speculation about the trade-offs also seems to be supported by prior efforts at "asic resistance"  (including litecoin, ethereum's work function, zcash's work function...):  In spite of many hypes and claims they have not actually turned out to be asic resistant at all and have in actuality resulted in a less diverse ecosystem than we've seen for Bitcoin. And enormous windfalls for secret operations...

Perhaps even more fundamentally: every commodity computing device is itself already an "asic"-- just one with extraneous parts (and a lot of patents required to build it, the "commodity" is something of a misnomer as a result...).  Simply taking an existing design and stripping off the extraneous area and power wasting I/O components alone is usually enough to make standard parts uncompetitive. After all, mining by its very design seeks to result in near zero returns for the _most_ efficient participants-- you don't have to be much less efficient to be hardly earning at all (or even operating at a loss). 2x the efficiency can mean 20x the profits, if the market is actually competitive. This is especially true because mining devices operate in a very different reliability region than other computing devices: it's typical for a mining device to get the best good-put at a percent or even more incorrect computations because the speedup/power-reduction more than pays for the wasted work. This sort of operation wouldn't be acceptable for virtually any other application, so a lot can be gained simply by designing for that alone.  In practice, every attempt so far (though much hyped, lauded, backed by academic research, and what not) has actually had orders of magnitude more efficiency gains than you'd get from stripping down a generic part. ... but even just the stripped part is likely enough to fatally wound the idea on its own... Before considering the IPR monopoly, amortization-centralization, risk of accidental trapdoor optimizations, or the speedups from customized architectures.

To me it seems that the idea doesn't work in theory and it doesn't work in practice.  It keeps re-occuring because the constant influx of suckers who will buy into things that merely claim to solve things which intuitively sound problematic, even if the solutions are barely credible (or even if they were tried previously and already failed!). There is little interest in actually reasoning out the tradeoffs, e.g. what makes for a good work function and a vested interest to not bother and keep churning out new flavours of snake oil-- because no matter how you want to cut it the picture is not that rosy for these efforts-- at best you might be able to say that with a lot of careful work you got a DIFFERENT set of tradeoffs that were potentially useful something with its own benefits but own serious downsides, far from the panacea that people want to sell-- and that isn't good for shilling the latest scamcoin.

Ineffectual because "crypto" conference have long been thoroughly overrun with scammers. Everyone who takes a strongly principled position on not attending events with scammer sponsors or speakers are already rejecting almost all events in this space.

Scammers just get a much larger marginal return from promotional activities like conference speaking/sponsorships.  Conferences are almost all run as money making enterprises, so the fact that they're saturated with scammers is unsurprising.

NIT: 64 bytes instead of 72 bytes.


So multiple concepts get confused here, so I can't tell exactly what you're talking about.    

There is signature aggregation which combines signatures from multiple inputs (but probably just one transaction) in to one,  or efficient threshold signatures which allows many signers to produce a single signature for a single input.

Both make signatures in transactions much smaller, so don't justify any change in how weight is computed.

This directly makes transactions much smaller, so again, no need to change how weight works.

Yes, it makes the cold cache catchup case spend half the time in signature validation. (non-catchup doesn't do validation in the critical path due to caching! ---  the small batching you can do as txn come in doesn't get much speedup)

The eventual speedup from batching (and the speedup we achieved from caching in the non-catchup case) was part of the justification for having witness data have lower weight to begin with.

With the exception of batching the other advantages you cite already result  in lower weight (in the cross input case, much lower weight).  So they're naturally already awarded.

Different users experience different pain points, some are cpu limited, some are bandwidth limited, some are power limited, some are storage limited. Many are some mixture of multiple of these.  Because of this no single weight formula can be optimal.   What really matters is that it sets the incentives in the right general direction, in order to break ties in the favour of public interest.

Generally we can assume that in the long run most users are going to do whatever is most cost effective for them. If foobar signatures were a LOT better for the network it would still be sufficient that they be only slightly better for the end user, even if making them much better would be justifiable under some cost model... even a little better will get them made a default.  Some users will have different motivations and make different choices, but a small number of exceptions is mostly irrelevant for the overall network health.  This is important, because a perfect balance isn't possible.  E.g. with weight, you could easily argue that an 8:1 ratio or a 16:1 ratio would have been better-- but a higher ratio means a LOT worse worst-case bandwidth, and so wouldn't be  good trade-off for those users who are bandwidth limited.   The fact that the only "direction of incentive" needs to be right, not so much the magnitude, means its possible to make compromises that give good results for everyone without screwing over some cost models.

You got your answer: You cannot know without getting access to the breaker panel -- either to read the breaker's label, or to reset it after tripping it.

There is no "meter" that can tell what the breaker is other than by overloading it and tripping it.

You absolutely do not want to use a transformer to convert. The cost of that and the losses would be considerable. It would be less costly to get a 120v capable PSU. ... but then you'll probably have too much current for whatever circuit you put it on. 1.8kw / 120v = 15amps, but if you put a 24/7 1.8kw load on a 15amp breaker you _will_ blow it eventually (and perhaps kill the breaker in the process). You shouldn't be running any sustained load of more than 80% of the breaker's label.  ... and 15amp is all you should assume is supporting a standard 120v outlet in the US.

Personally, I prefer to run computer equipment on 240v in any case-- because 120/240v stuff is pretty much universally several percent more efficient on 240v, plus it avoids load balance issues...

But if you don't have access to the breakers it's probably a bad idea to mine: even if your mining is properly at 80% of the rated load on the breaker, you still may manage to trip it during a brown out.  Then what?

That's almost certainly not the case. The only time when fees could at all be high is when there aren't many people doing it.  What we've seen so far in lightning (and previously in joinmarket) is that fees rapidly race to pretty low values in competition.

At the moment, but eliminating any need to run a node is a major focus of development effort for lightning developers.

There is an inherent incentive: radically improved security and privacy.  But it's only enough to overcome a certain (low) level of cost... thus the concern about managing that cost.

As an aside, a lot of that "node hardware" being sold won't keep up for that long due to limited memory/storage/speed.

There isn't any _size_ limit in the protocol or implementation at all anymore, the weight limit completely replaced the blocksize limit. There isn't any "base size" in the protocol.  So a limit to 600k weight would result in blocks roughly 15% of current sizes given current usage patterns (though probably more since usage would change).

"The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man."

That said ... there are degrees.

I'm disappointed with the press circus Luke has contributed to here, -- it's not the first time he's set things up perfectly for his words to be taken out of context and then been so so surprised at what happened. But he does make useful contributions, and in the fullness of time drawing more attention to the initial sync problem may be one too, even though I disagree with the approach.

Careful with those assumptions,  if you filter out nodes from a couple popular VPS providers and nodes that have obvious behavioral tells that they're fake... the picture looks much less rosy.  A lot of "nodes" are sybils setup-- presumably-- to track transaction origins.

Blockstream has unpublished code that implements an alternative serialization that reduces tx sizes by around 25%.   I don't think it would actually improve IBD time except for very fast computers on fairly slow internet connections... initial sync is more utxo-update bound than bandwidth bound for most users. It might even slow it down, since the compact serialization is slower to decode. On a ludicrously fast machine (24 core 3GHz, nvme storage, syncing from local hosts over 10gbe) sync currently only proceeds at about 50mbit/sec.  I've been nagging them to publish it.  Their interest is in using it to increase capacity on the sat signal, but it's more generally useful.

I expect and hope that all the IBD activity will move into the background. After that happens, then the time it takes is less important than the resources-- and at that point a 25% bandwidth improvement would look pretty good.

They've been assigned in blocks in an effort to keep related BIPs together.

Also, sometimes people have ignored the process and self-assigned numbers and started using them in communications-- sometimes multiple people with the same number, when that happens the number gets temporarily skipped for assignment to avoid adding confusion. But primarily just due to grouping.


You absolutely shouldn't do that. The BIP process has virtually no editorial control-- it's just a publication numbering scheme that assigns a number to anything that persists long enough requesting one.  There are many low quality / broken BIPs that no sane party should use.

Essentially the only editorial lever in BIPs is that if many people dislike a proposal they'll encourage the proposer to abandon it before it reaches the point of getting a number assigned. If the proposer can't be convinced or if no one cares enough to convince them and the proposer persists their proposal will get numbered.