The point of this type of honeypots is to entice the blackhats to just take the crypto and walk away. Making it harder for them to walk away with the money would be counter-productive.
Old situation: blackhats sticks around for weeks or even months, exfiltrate data, blackmail, install crypto miners, etc.
With crypto honeypot: blackhats take the crypto and leaves.
With rigged crypto honeypots that are actually not redeemable:
>on the hacker forums:
>Guy A: "I tried to take the bitcoins from Corp A's honeypot wallet, but they broadcasted a high fee transaction and beat me to it."
>Guy B: "Funny, same thing happened to me last week with Corp B's wallet."
>Guy A: "Guess it's back to the old blackmail method then."
Yes, all correct. But if you offer a CEO the option of a defense that is just as effective, but also steals part of the bait money back? If the potential long-term cost is only hurting the corporation's reputation with a shadowy hacking group, and reducing the effectiveness of the defensive technique for everyone?
Bottom line: I think we can guess which option a CEO would usually choose
Remember that this method works best when it's not obvious that it is a tripwire, and may be best of all when it acts as a bribe to a greedy individual within a group of hackers.
I don't know, it seems like if the corporation sent a high fee transaction they have already been alerted that their defenses need to be raised. so your attack vector has limited efficacy as it might be closed. the hackers need to have the foresight to sit in the server and accumulate other blackmail, but also not lose the chance to take the bitcoin bounty based on another hacker finding it.
I don't have personal knowledge of the marijuana industry, but IRS's site says they accept cash and Money Orders.
There's a $1,000 per day limit for cash, so it's not really feasible for large businesses. Instead, I think you can make Money Orders by going to Western Union or USPS, if banks are to be avoided.
>Only now have measures been taken, as people living within a radius of 15km from Zwijndrecht being advised not to consume eggs laid in their own or anyone’s else’s gardens, whilst pregnant women and children also have to watch out for vegetables from one’s own garden.[0]
Internally strings will either be UTF-16, or if a string can be represented in LATIN-1 it may use a more compact representation.
JEP400 is about I/O, previous to this change when you create something like a FileWriter without specifying the charset the platform default would be used. For a long time this has been recognized as a common foot gun, hence this change to a default that is more likely to be what the developer actually wants.
UTF-16 represents a fairly reasonable compromise, not sure what your disgust is for.
UTF-32 (with no BMP concept) doubles the memory usage of most international text and quadruples the memory usage of ASCII text (which is the most common), yet characters outside the BMP are barely used outside of emoji.
Native UTF-8 in memory makes character indexing a non-constant time operation, which would bite people badly in cases where they've written a loop over the indexes. This is of course the point at which you say, ah but what is a character exactly. If you go down this route you end up with Swift and Emoji Flag Calculus classes. The string APIs become incredibly convoluted or inefficient for the common cases. It hardly seems worth any kind of backwards compatibility break for this.
So Java does the pragmatic thing: String can switch between 8 or 16 bits per "character" and this is basically always good enough. If you care about woring with emoji or Egyptian hieroglyphs in memory, then you either have to deal with combining characters or just bite the bullet and decode to UTF-32.
> Native UTF-8 in memory makes character indexing a non-constant time operation
The only reason that Java's UTF-16 has constant time indexing is because they use a braindead definition of character which is "UTF-16 codepoint".
If you want constant time character indexing you need to go UTF-32. But obviously the downsides are too great for most users. So in practice everyone uses UTF-8 because it is usually the most memory efficient.
Plus it turns out that character indexing isn't actually that common of an operation, so it is really the right move for almost every application.
But in practice the Java definition of a character basically always works, because characters that aren't in the BMP are vanishingly rare in real software outside of emoji, and of course, Java long pre-dates emoji.
Yes, that won't change anything internal. However:
> ...JVM's internal string representation is UTF-16
Hasn't been try for a while. They switched to using a byte array internally for storage, plus an encoding. Currently that's either UTF-16 or Latin 1, unless compact strings are disabled in which case it's all UTF-16.
You're talking about implementation details of java.lang.String. The interface it exposes is still UTF-16.
Latin 1 has the special property that each of its fixed-width code units maps onto a single UTF-16 code unit. It is for that reason alone that CharSequence implementors can use it as an alternative to UTF-16. Imagine trying to implement `char charAt(int index)` if you're backed by a UTF-8 byte array (or UTF-32, for that matter)!
From a programmer's perspective, Java is pretty much as UTF-16 as ever.
It's not a typo because 400A is indeed the highest tier residential service BC Hydro currently offers[0]. 400A is also in the right ballpark for the amount of equipment he describes.
The copper coming from "something" will be at least 1/2 inch thick, probably more so that it doesn't lose voltage. We're probably talking a 7/0 cable where 4/0 would be bare minimum.
Probably larger than that. If they’re 200m from the transformer, 400A service requires (3) 1000kcmil cables per leg. 100m drops it to (3) 350kcmil which is still pretty beefy
1. during the TLS handshake, the domain name itself might be sent in the clear if the SNI extension is used, and if the SNI extension isn't encrypted[1]
2. if the carrier knows the IP, then they can do a reverse DNS lookup to find the domain name
Other alternatives include:
1. shorten it so much that it's not revealing anymore (hil@domain.com)
2. use another language if you're multilingual (hiruton@domain.com for Japanese)