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.

That was the old thing, but apparently on twitter he's talking about something even less reasonable now.

In any case, I showed this thread to other developers and the response was uniformly a big wtf.

Initial sync time does suck and is a problem, but the damage has been done-- since long ago-- no amount of size reduction will solve it. If it would then perhaps these ideas would get a bit of traction, but it won't...

I never even heard of it until your link.  So yes.

He bought an insignificant sum on mtgox in 2013. There is no evidence that I'm aware of to suggest that he had any when he started scamming Bitcoiners. And there is a lot of evidence he didn't: If he did, why would he be risking them (and his freedom) attempting to defraud the AU government for millions? Why, when the AU government caught him and demanded he prove he had owned bitcoins under risk of imprisonment (his scam required him to claim to have a lot of BTC) -- didn't he reveal some of them instead of taking the risky step of claiming that a bunch of MTGox's coins were his?

The people suing him are doing it just on the basis of his public claims.  For them it's a simple strategy:  Either Wright is telling the truth and they're owed big time, or Wright is lying and he should settle with them (for, say, a few million) quickly before their discovery process reveals more of his criminal fraud. Win/win.  To do this they have to treat his public claims as the truth, even if they don't believe them. Though they might... filing a lawsuit doesn't give them any special insight. The fact that wright is frauding is better for their lawsuit since it creates more incentive for wright to settle quickly.  (Unfortunately for them, he's just not that sane...)

Like some other people that dupe people around this space (... say someone who posted earlier in this thread...) Wright compensates for cluelessness by applying an abusive attitude, technobabble, and choir preaching insults at respected authorities to both elevate his standing and make his audience feel superior (like "I knew it! all along those respected folks were really worst than me!").

People without the relevant background can't judge the content, but they hear the the tone and attitude and they can't imagine using that approach unless they were telling the truth.  They just cant imagine being a pathological liar with testicles of neutronium themselves... and so, improbable as it seems, they actually find Wright's spiel credible even though to the rest of us it wouldn't even make for a credible conman act in a movie.

In fact, his utter implausibility works in his favour in another way: it discourages competent people from spending their time discrediting him, and when they do it they find themselves saying something like "wtf. how could you _possibly_ believe this crap. I can't even.", -- not exactly the most effective, even though it's actually a fair response considering the utter absurdity of the situation.

Also, since no one has linked it and to avoid myself being guilty of just giving a "I can't even" response, the bitcoin wiki page on Wright is obligatory reading: https://en.bitcoin.it/wiki/Craig_Wright

For each of my two dishes:

76cm dish $45
MK1 PLL LNB  $8 (note! EU and Asia need different LNBs!)
Coax from dish to inside-- depends on length, mine was free because I scavenged it-- you can get 50ft of RG6 for $15.
SWIM power injector $7
F to SMA connector $2
TCXO R820T2 SDR $24
USB extender cable $4
Figure a couple dollars in misc hardware, bolts, etc.

Then a suitable computer, you can get something used for $0 to $200 or so, or something new for less than $400.

Many of the parts can be found for free or nearly free depending on your scrounging abilities, proximity to hamfests, and willingness to trade time for money.  (e.g. it's very easy to find 45cm dishes for free at least in the US. Coax and injectors can also be found for free or close to it.  The LNB you'll have to buy-- as blockstream's signal requires an unusually stable LNB, but it won't break the bank.).

If you really have no similar hardware and no experience with this sort of thing you might want to double your estimated price, simply because you'll lose parts, find things that don't fit, need tools, etc.  I used a short piece of RG6 coax while aiming the dishes in order to avoid complications from the long cable run while pointing... My dish is mounted to the wall with lag bolts, if you don't have an impact driver (or at least ratchet, socket, and a lot of patience) you'll probably want to get one. To install it up there on the wall I needed a ladder which I obviously already had, etc. My tool chest is as tall as I am, so there is a certain amount of cost that I didn't experience that you might.

I thought I'd share some pictures of my receiver setup.

I have two dishes, one to pickup the blockstream single on G18, and another to pickup the signal on Eu113-- most of the US are covered by both of these signals.

Once some upgrades are made to the sending side use of both dishes will allow half the delay when sending blocks (and, obviously, more reliability against obstructions or equipment failures)-- pretty handy in places that happen to be covered by multiple signals. At the moment I'm just using one at a time, though both work.

The dishes I'm using are 76cm Winegard DS2076.  I paid $45 each for them on Ebay.  If I hadn't found such a good deal on this I probably would have used 90cm geosat pros (which are about $100).  For my location the 76cm is adequate, though I've had some outages during bad weather-- heavy rain attenuates the 12GHz signal a LOT.

I understand blockstream is going to be making some signal changes that should improve reliablity, and also some modem changes that will make it easier to get pointing really peaked out.  The current tools give a really noisy SNR measurement which swings over a few dB in the space of seconds even when you aren't changing anything, this makes it really hard to dial in the pointing and get a really perfect alignment.   E.g. my polarization could be off by as much as 30deg and I wouldn't have any idea, because the changes just weren't visible on the background noise.

For feed horns and downconversion I'm using MK1 PLL LNBs on the dishes which were an astonishingly low price of $8 on amazon.  These are the appropriate devices for the americas signals, and they seem surprisingly good. Europe and Asia need different LNBs.

The dishes are connected back to my equipment room with a ~250 foot coax run using some fairly low loss cable that I reclaimed from a CATV temporary lateral that was abandoned on the under the grass after the put a permanent install up on the polls.  The reported SNR looks the same both with and without the cable, so I guess it's not too long.  YMMV esp with less heavy duty coax or with LNBs that have less gain or lower voltage power inserters: I kinda expected these to be too long.

Then I'm using Direct TV "swim" power inserters. These cost $7.   They are a little bulky but the only real complaint I have is that they're 120VAC only-- all my computer gear is 240v for efficiency reasons, so these being an odd ball out is a bit of a pain. But I am probably the only US user who is weird enough for this to be a problem.

Finally, I'm using the recommended $24 nesdr USB RTL dongles as the SDRs.  Not much to say about these things. They're inexpensive and they work.  I contemplated using a nicer SDR (I have a couple to choose from...) but I figure my bug reports are more useful if I use common hardware.  I use USB extension cables to hook the SDRs up to the host (otherwise the SDR is a fragile wart on the back of the computer).

These feed an older 3.4GHz quad core E3-1230 1u box that runs the fibre-enabled Bitcoind.

I've encountered a couple bugs which blockstream has been fixing as I've found 'em. In particular the pull-req to store out of order blocks is essential.  I've had a couple internet outages where the sat signals have successfully kept my Bitcoinds receiving blocks. Success!

The biggest issue that I had with the install is that multiple times I used a laptop for initial pointing that was too slow. And the blockstream modem software really doesn't give you a usable warning if the computer is too slow. When the computer is too slow. It _looks_ like its working, but that there is no signal.   My small laptop that was easy to haul up onto a ladder was just too slow, and even when I switched to a faster one it was too slow while not plugged into AC power (so it was fine on the ground but when unplugged to drag it up onto the ladder it started returning junk).  I wasted _hours_ due to this one problem.  Since pointing is a little tricky, esp if you haven't done it a bunch of times it isn't surprising if it takes you a bit, which just makes it take longer to realize that the lack of success is due to a slow system.

On with the pictures. First, a wider show to show how I have the dishes placed:




I decided to wall mount the dishes:  Compared to ground mounting them above where anyone would walk in front of them and block the signal or knock them out of alignment.  Compared to roof mounting they're somewhat protected from the wind, I didn't have to worry about causing any leaks, and they're less conspicuous.

Here is a close-up of the dishes:



Like most small dishes these are offset fed, so they point much higher than they look like (about 24 degrees, in the case of these dishes).

You can see the dishes are aimed 'cross eyed',  there is a power poll that gets a little close to the line of sight of the signal, so I wanted the dish that was pointed more towards the poll to be the dish that was further away from it.  I could have located the dishes elsewhere but this location has the advantage of being invisible inside the buildings unless you push your face right up to the glass.

And my equipment room with the power inserters and SDRs... and a bunch of unrelated stuff. (I have the wall opened up at the moment due to unrelated work) To the right is the top of the rack that has the computer in it that handles the signal.



In the pictures I also have a pair of 1268 MHz-center 35MHz wide bandpass filters between the power inserters and the SDR. They're not required, though I find they do improve SNR by about a half dB or so (the inexpensive SDRs don't have very selective front ends).  Mostly I have them just to avoid any issues with high power transmitters that I have getting picked up by the long coax run.

Beyond my issue with the slow computers making me falsely believe my aiming was wrong, the setup was really easy. (Though, I do have a non-trivial amount of experience with radio, SDRs, and Bitcoin (obviously)).

Group computation can be written either in multiplicative or exponential notation, it's the same thing, just a different convention--

If you take the group operation (combination of two points) to be addition, then you write it as P+Q and something like key generation as xG.   If you take the group operation to be multiplication then you write it as PQ and key generation becomes G^x.  I personally prefer additive notation, but the multiplicative style is more common in the literature presumably owing to the fact that finite field operations in the ring of integers mod P literally uses integer multiplication.

[Aside, don't just credit me on that work, the other authors there are far more significant than I am...   My main contribution was probably just finding an actual attack on an earlier construction that Pieter had, which we already suspected might be weak... ]

Indeed, it doesn't really make a difference to use compressed vs uncompressed, but compressed can sometimes be somewhat less computationally expensive to use (less data to hash, potentially less effort needed to compute the Y value completely), so it's usually preferred.

It was you that started the complaining... not I.  All I did was point out that inserting a gigantic financial incentive to reuse addresses is a non-starter. (doubly so because we know how to get the same gain without the bad incentive via aggregation with essentially an identical implementation).

If you're going to complain that my response was terse, please don't also complain when I expand on why I didn't think the matter needed more than a terse response.

Yes, a couple times. If you really care I can dig up an older post.

Not at all, in fact that is a really _super duper_ perplexing claim. Introducing a new script operation is like the canonical example of a softfork. No one would ever consider implementing it any other way.

It really makes me sad that there is so much misinformation being spread about Bitcoin.


A new checksigverify operation is defined out of an existing nop that processes the new style signatures... exactly how any other softfork works.

For aggregation, the operation can take an empty signature, and it just pushes the aggregate signature onto a signature stack, and the last signature in the aggregate isn't empty and provides the signature for the aggregate. Or likewise,

The rehashed discussion is annoying.  People previously proposed  having one signature for reused scriptpubkeys, and it got smashed into the ground over the fact that it would create a huge financial incentive to reuse.  Indeed there are also reasons against reuse but with enough incentive they can be overcome (e.g. only reuse addresses for settled payments... bitpay was already doing that even though there is no incentive in the system, just because they wanted to store fewer private keys...)

There is no hardfork needed for schnorr signatures or aggregation, nor is any desirable for them. All they require is an additional script type.

What you suggest instead is no easier and would create a massive incentive for address reuse.  That just isn't going to happen.

Well, not even quite that:  All the vulnerable nodes would have crashed on restart-- when automatic start-up safety tests caught the issue-- and refused to start again if it were triggered, just as we saw on testnet.

I'm having a hard time figuring out what the original post in this thread is trying to say. It sounds like it's trying to allege that the issue still exists. It doesn't.

There is no concrete proposal yet, but all our design work has targeted keeping the same or lowering delay.


Sketches are additive, so when a node decides to relay a transaction it computes the sketch of that transaction's ID.

Then it adds that sketch the the accumulated sketch for each peer.  Adding the sketch is just an XOR so it essentially takes no time.  This work is done per transaction too, so it doesn't matter how often the peer reconciles.  Reconciling justs causes the responder to send out the accumulated sketch and memset it with zeros.


You haven't explained why you believe that.  It simply isn't true-- see my dumptruck example.  Each transaction is relayed without waiting on the prior ones to arrive anywhere.   Can you try presenting your understanding using the infinite dump-truck analogy so that we can get on the same page?

Transactions announcements to other peers are already delayed for bandwidth reduction (because announcing may at once takes asymptotically about one forth the bandwidth: since ip+tcp+bitcoin have overheads similar to the size of one announcement and the delays usually prevents the same transaction from being announced both ways across a single link) and privacy reasons.  The delays are currently a poisson process with an expected delay of 5 seconds between a node transmitting to all inbound connecting peers. Outbound connections each see 2 second expected delay.

As a result reconciliation based relay doesn't increase delays (in fact, with our current WIP parametrization, it decreases average delays somewhat).  

I share Carlton Banks' concern.  Your tone in past messages as well as the this one is rude and somewhat irritating particularly when coupled with (otherwise innocent) ignorance of Bitcoin 101 topics like how transaction relay works.  The fact that your message went a day here without getting a reply even though you were unaware of the existing batching which any of thousands of people could have pointed out to you demonstrates one of the negative consequences of taking such a tone instead of asking a polite and professional question... If you actually care about learning you should refrain from that sort of behaviour.  If you're not actually interested in that, you should discontinue posting in this sub-forum because that isn't welcome here. People with actually useful answers aren't going to choose to spend their time hanging out somewhere to get insulted by newbies or people who just haven't done their homework.

A number of hostile posters on bitcointalk and reddit seem to be using the word hardfork in a more or less random way.  A hardfork is not a general term for an idea the speaker thinks is a bad idea . A hardfork is a change in consensus rules which is irreconcilably incompatible with prior consensus rules e.g. accepting a block containing spends that previous software would reject as invalid.  Transaction relay is entirely outside of consensus and as a result no possible change to it would be a hardfork (or a softfork, for that matter).  The existing Bitcoin protocol and software even has a mode which disables transaction relay entirely (blocksonly) and it is fully consensus compatible with other nodes (and saves a metric boatload of bandwidth).

All of the computational work in reconciliation is performed by the party that initiates the reconciliation.  So a third party cannot cause you to expend more resources than you want to expend on it.  We've been doing protocol design assuming the need to support rpi3 nodes without an undue burden; which was part of the reason minisketch was required since prior bandwidth efficient reconciliation code was far too slow for limited hardware like that.  rpi3 is more or less the bottom end for running a full node-- already that target takes 20+ days to synchronize the chain.  Slower could still be used, but it would presumably reconcile less often.

Not at all, Bitcoin is already a batch system-- blocks show up at random times and commit to a chunk of transactions, whatever is missed and still valid goes into a subsistent block. Both because blocks are relatively infrequent and because the mining process itself has seconds of latency (e.g. from batching new block templates to mining devices to avoid creating extreme loads on block template servers) the existing delays have little effect on the transaction handling delays.

More fundamentally, the connection you believe exists between tx propagation time and network throughput just doesn't exist:  It could take an hour to propagate transactions and the resulting network throughput would be unchanged because the network doesn't stop and wait while the transactions are being propagated. If it did, it would add an hour until you saw a confirmation, but the number of confirmed transactions per hour would not be changed.

Imagine you had an infinite number of dump trucks to use in hauling gravel from one city to another, 24 hours a day 365 days a year. Each truck carries 1 ton of payload and every 5 minutes a full truck leaves.  During week you will carry 2016 tons of gravel between the cities. It does not matter if the cities are 1 hour apart or 5 hours apart:  Changing latency does not change throughput for non-serialized operations.

In Bitcoin the latency is relevant-- not because of throughput reasons, but because of things like people caring about their transactions being confirmed sooner rather than later.  So long as the TX propagation delays are very small compared to the block finding interval they don't matter much in terms of the user's experience, so it's fine to trade off some small latency for other considerations like reduced bandwidth or increased privacy-- which is something Bitcoin currently does and has always done since the very first version (though the details of the trade-off have changed over time).

There are other minor considerations that make tx propagation delays matter some, but they're all of a sort where they don't matter much so long as they're significantly less than other delays (like block template updating delays).

Bitcoin's capacity has never been "tx/s", the "7tx/s" number comes from assuming every transaction would be a 2-in-1-out transaction.  The block I gave an example of would have only held slightly more than half the number of transactions without segwit. You can also see the effect of the increased capacity because fees have dropped to almost nothing again.

The block I linked to spent 9,039 inputs, which would have been impossible prior to segwit: each input takes 147 bytes, so without segwit a block could only have spent 6,802 even if it made no outputs at all. The block I linked to also made 3,553 outputs.

If all you care about is number of transactions, this block has 12,239... or 20.3 tx/s ... though they are all very small inefficient one-in-one-out transactions without real signatures. Size wise they are functionally segwit transactions because they have empty scriptsigs (technically one byte). (And yes, because segwit was a softfork, segwit-like transactions could be included in the chain from day one, they didn't have to wait for segwit -- they only had to wait for segwit to be secure).

Again your posts are the opposite of the truth.  Services now use sendmany (and indiviguals sometimes coinjoin) combining many transactions into one. This makes the much more efficient. One transaction does the work of three but is only 1.5x the size...



You have maliciously misquoted my message.

In fact, I haven't made any income for since 2017-12-31-- beyond a couple tens of dollars worth a month for helping with forum moderation. I live off selling investments. Not that it's any of your business. But for the record, just in case there are other similar pieces of shit to you that think it's okay to treat your fellow man like dirt relentlessly lying and throwing shit at him simply because you think he earns more than you. I hoped that the dishonest attacks would diminish if I had not further relationship or contact with Blockstream, and for the most part that has been true: It turns out that most of the slimeballs can't find anything negative to say except for baseless slander about where I work. Now, without that to hang their arguments on, they're mostly left either lying about where I work, or saying nothing.

I feel sad that you are such a loathsome and dishonest person, and sad for the world for all the damage you do to it.

You've got it.

The "re-relay" problem that he imagines isn't actually a thing, but even if it were, minisketch would just be an unrelated improvement:  Nodes communicate their minfeerate to peers and don't get offered stuff they'll just drop due to fees. Existing things they do drop (due to being double spends, arriving while they're in the process of changing their fee filter, etc) they remember the txids so they won't fetch them again if a peer offers them, which itself doesn't happen much because txn are only offered when the peer initially accepts them.


https://blockchair.com/bitcoin/block/544791
Size (bytes)    1,700,065

Last I checked 1700065 was greater than 1000000. Segwit increased the blocksize, but didn't increase the size that lite clients have to deal with or break compatibility.

Not really, I mean that might have been why many people on the forum found it exciting,  but separating out witnesses was proposed back in 2012 when no one was really thinking much about L2.   Unintended malleability is just a source of 1001 awful corner cases that are really hard for wallets to handle except by refusing to spend your own unconfirmed outputs, or other similarly terrible and burdensome workarounds. We previously tried fixing these problems via BIP62 but it was just a finger in a failing dam, because the original design was flawed we kept finding more and more avenues and were forced to abandon that approach.  Lightning was proposed before segwit was a thing and at least theoretically lightning can be done without it-- but in practice without the ability to control malleability it is just too awful and dangerous to write any automatic transaction processing software, so after segwit was proposed which completely solved that issue lightning developers decided to wait on its availability.

Not quite-- MTGox's claims were indeed just trying to cover up his insolvency cover-up, but even without that easily fixed accountability screwup malleability is a problem because of spending change output.  There were several big attacks that really messed up and took down basically every big fund sender (e.g. bitstamp)-- we kept them under control by getting miners to blacklist various attack patterns, but that kind of workaround can be evaded by sufficiently motivated attackers.  It actually was important to fix the general case for reasons unrelated to mtgox.  Mtgox just seized on and exaggerated an existing problem that had given then a little trouble (and unlikely ~everyone else actually caused them some funds loss, rather than just a jammed wallet) ... but it still was actually an existing problem.  It was strategic for mtgox to lie in this way, had they imagined some totally new fake problem to blame their insolvency on they would have instantly been called out.

I really don't understand why FUDsters have had any success with the "malleability isn't fixed".  The fact that it's possible to intentionally make a malleable transaction even exists as a useful and intentional feature: e.g. the ability to create anyonecanpay transactions where other people provide part of the funds after you sign. The malleability issue was always that it wasn't possible to spend an unconfirmed output (e.g. as your change, wallets have always refused to spend unconfirmed outputs by other people due to the risk of double spending) without those dependant spends (and their ancestors) being maliciously invalidated by someone else.   -- it's not like intentional malleability is avoidable, after all you could also always double spend yourself.

I guess some people are just pathologically uncomfortable with anyone else having any choice at all in their life.  The fact that you could choose to intentionally make a transaction that they allow other people to modify, and then have to deal with the consequences yourself just seems to drive some people wild.  Similarly, the fact there is some buried command-line configuration option that virtually no one sets to increase the minimum feerate your node will accept-- with essentially no consequence for anyone but yourself-- causes the same people to melt down ... the idea that other people can make their own free choices seems to leave some unable to sleep and stuck obsessively posting about it. The fact that their choice harms no one and is fundamentally impossible to prevent is apparently just not relevant to these people.

Unfortunately, other people see the floods of posts and think that there must be some issue.  But no: sadly, some people on the internet are just broken.

It's really frustrating that they'll say anything to sustain their obsessions ... like above "they introduce RBF to actually help malleators malleate" uh no, third part malleability always either lower feerates or keeps it the same, so if RBF mattered at all it would actually make malleability less sucessful by allowing the original to replace (in practice it doesn't because the mallated txn is only larger by one byte). Not only is the claim untrue, if anything it's the opposite of the truth.  But the speaker will never suffer any negative consequence that he cares about for spreading this lie, and it might convince some ignorant party... so he'll do it every time.