HTTPie – A user-friendly CLI HTTP client - <AUTHOR> https://github.com/jakubroztocil/httpie <comment><USER2> HTTPie is amazing, but I grew tired of it being "slow", slower than some of my services response times at least.

Migrated to Curlie [1], `alias http=curlie`, and been happy with it since. Same API, better performance and access to full `curl` flags.

[1] [https://curlie.io](https://curlie.io)

<comment><USER3> > Like curl but unlike httpie, headers are written on stderr instead of > stdout.

What's the thinking here? If I ask for the headers, wouldn't I want that on stdout?

<comment><USER2> IDK, that is one of the things that annoys me to be honest, because sometimes headers get written after the body into the output (idk why, but guess some buffering and/or parsing+formating lag).

I almost forked it to get both outputs into stdout haha

<comment><USER4> I get that sometimes too. It should be fixable without having to send headers to stdout.

</comment></comment></comment></comment><comment><USER5> Truly one of the best cli tools out there. The api is concise and flexible, the --help flag is easy to read. But most importantly, there's _sane_ defaults.

 _defaults to GET request_

       http google.com

_when json body exists it becomes a POST request_

       http google.com user=65

<comment><USER6> I don't get how you think that second part is a "sane" default.

"user=65" is not valid JSON, unless you consider it a single JSON string literal.

HTTPie converts that into a JSON object.

Curl will send the data literally as you send it - if you want to send JSON, give it JSON as the body. If you want to send a "Form POST" quest, give it an encoded query string as the body.

If HTTPie detected that what you gave it was valid JSON, or whatever other media type, and used that to 'guess' the request Content-Type, that would be useful and smart.

But HTTPie not only mangles input, it mangles it in a way that is completely non obvious.

passing it "foo=bar" will send a JSON encoded object like `{"foo": "bar"}`.

passing it "foo=bar&baz=boo" will still send a JSON encoded object like `{"foo": "bar"}`.

So, it knows that ampersand is a field separator, but then promptly ignores all the content after it?

So, no. I call bullshit on "sane defaults" when it mangles data, and silently drops data it's given.

<comment><USER7> Completely agree. Opaque magic to "guess what you want" from incomplete or plain wrong arguments isn't "sane defaults."

It also doesn't make it easy to use, because eventually the magic will guess wrong and it will go from magically the right thing even though I passed garbage arguments to completely the wrong thing at the drop of a hat.

An example of a "sane default" where curl falls short might be to enable redirects by default, because that is usually what the user wants (and correct client behavior).

<comment><USER8> > Opaque magic to "guess what you want" from incomplete or plain wrong > arguments isn't "sane defaults."

Please explain how a well-defined key-value convention is equitable to "incomplete" or "plain wrong" arguments.

In what way is any of this opaque when it's fully documented and quite easy to follow?: [https://github.com/jakubroztocil/httpie#id16](https://github.com/jakubroztocil/httpie#id16)

<comment><USER9> Fairly sure I'd forget all the time that it thinks giving it a syntax that looks like form-encoded _obviously_ means I want to send a JSON request.

<comment><USER8> key=value is a convention used in so many places that have nothing to do with form encoding

Would Java developers see this and imagine you're passing values for a .properties file?

If you've never seen the tool before, you also wouldn't know how it works at all. Once you hit help for the first time (you know, to actually learn how to use it), knowing it defaults to JSON is pretty much a base truth.

It's entire value proposition seems to be stongly tied to JSON support (2nd highest feature in the pitch at the top).

This is like saying you'd forget jq takes JSON strings...

<comment><USER6> How many key/value formats commonly used for http request/response transactions use = ??

The _first_ feature pitch is "user-friendly curl alternative with intuitive UI".

<comment><USER8> I'll leave it at this, I'm glad they prioritized not having to escape JSON on the command line over people who have no idea about how the tool works being able to guess how to pass form inputs.

That is probably the most user friendly difference they could make for working with JSON based APIs

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> I use HTTPie all the time. It's not a curl replacement, it's a competitor in the space of CLI HTTP clients. The argument syntax is easier to use than curl, and it's geared for humans interacting with JSON APIs, including coloring and pretty printing output.

<comment><USER11> > I use HTTPie all the time. It's not a curl replacement, it's a competitor in > the space of CLI HTTP clients.

Sounds like a curl replacement to me. From wikipedia ([https://en.wikipedia.org/wiki/CURL](https://en.wikipedia.org/wiki/CURL)):

"cURL is a command-line tool for getting or sending data including files using URL syntax."

<comment><USER12> Curl is a lot more than something humans can use from the command line for http/s requests.

This seems like a small tool with good ergonomics for http/s requests only.

<comment><USER13> > Curl is a lot more than something humans can use from the command line for > http/s requests.

I continue to be surprised by the protocols which curl supports. SMTP, IMAP, SFTP..

</comment></comment></comment></comment><comment><USER11> As it looks now, I don't see much reason to switch away from curl + jq.

The thing I like about curl + jq is that I can easily switch it out for:

TEMPFILE=`mktemp`; curl -s <REQUEST> >$TEMPFILE; python -c "import json; f = open('$TEMPFILE', 'r'); d = json.load(f); <json processing logic and print statement>; f.close()"

and run in my CI environments or ship in docker images for testing purposes.

That said, I do see the potential for a tool like this. What I would like is the ability to manage different profiles for different URLs from the command line. Profiles could just be collections of header specifications - "Authorization: Bearer <blah>" or "Content-Type: application/json"

(Maybe [https://github.com/postmanlabs/newman#using-newman- cli](https://github.com/postmanlabs/newman#using-newman-cli) ? Didn't know about it until now.)

<comment><USER14> >TEMPFILE=`mktemp`; curl -s <REQUEST> >$TEMPFILE; python -c "import json; f = open('$TEMPFILE', 'r'); d = json.load(f); <json processing logic and print statement>; f.close()"

This is painful. In powershell this is built in and as easy as iwr url/to/json | convertfrom-json | other logic

<comment><USER11> Interesting, looks like Linux users can also try out Powershell now: [https://docs.microsoft.com/en- us/powershell/scripting/instal...](https://docs.microsoft.com/en- us/powershell/scripting/install/installing-powershell-core-on- linux?view=powershell-6)

It's a beefy package, though. Packaged in a docker image on top of alpine:3.10.3 following their installation instructions for alpine: [https://gist.github.com/nkashy1/643e7a263054c02e2caceb3912f8...](https://gist.github.com/nkashy1/643e7a263054c02e2caceb3912f82f20)

The image comes in at 178 MB. alpine:3.10.3 is 5.5 MB. An alpine image in which you add bash, bash-doc, and bash-completion clocks in at 13 MB.

Sounds really powerful for personal use, but not an ideal tool for production use (e.g. when you need to spin up a pod on a Kubernetes cluster to debug an issue in production). Will definitely try it out.

<comment><USER14> Probably because it has to include the entire CLR/.net framework. I suppose that is a concern, but I doubt I'll ever be doing k8s or docker in my career anytime soon.

</comment></comment></comment></comment><comment><USER15> This is pretty handy. I usually default to httpie for playing with my APIs and documenting examples - it's much clearer than curl.

It doesn't seem to get much development attention though. There hasn't really been features I find useful added in the past year. The biggest issue is no support for nested JSON bodies, meaning non-trivial API calls end up just as complex as curl.

<comment><USER16> -H for request headers

-d for body

-X for method

—-verbose to see response headers

How much "clearer" could curl get?

<comment><USER17> hmmm how about this:

-M for Method

-B for Body

-RH for Request Header

you know, so you only have to know the first letter and don't have to remmeber arbitary flags?

I know that it is not that easy, but unix tools do have the problem that often the flags don't make sense on the first glance.

<comment><USER18> > _I know that it is not that easy, but unix tools do have the problem that > often the flags don 't make sense on the first glance._

Should you be sending HTTP requests to something without knowing precisely what you're doing? httpie just sorta assumes from your arguments what you're trying to do, and for me it has often been wrong. Probably works OK if you have a mostly read-only API.

<comment><USER17> I don't send random things, I either look up curl if I need to script something or I just use postman.

EDIT: Depends, most of the time I use standard JSON Rest apis, there is not really that much to misassume I think.

</comment></comment></comment></comment></comment><comment><USER19> For those using Emacs, I'd recommend restclient.el [1]. In Emacs fashion, you can keep REST API documented in a single (or more) files and evaluate parts directly in buffer for testing and playing. Throw that on git/mercurial and you have versioned and documented REST API ;)

[1] [https://github.com/pashky/restclient.el](https://github.com/pashky/restclient.el)

<comment><USER20> Visual Studio Code has a similarly named (seemingly?) API-compatible extension: [https://github.com/Huachao/vscode- restclient](https://github.com/Huachao/vscode-restclient)

</comment></comment><comment><USER21> Those who like HTTPie might also like http-prompt[1] which is an interactive prompt built on top of it.

[1] [http://http-prompt.com/](http://http-prompt.com/)

</comment><comment><USER22> Wonderful tool. I've said this before but something holding it back is that you need python to run it and have a python environment set up. Usually this isn't that big of a deal but it's just enough friction to make me not reach for it most of the time.

Conversely something like jq is trivial to install and use almost anywhere because it is just a binary linked against libc. As a result I use it all the time.

<comment><USER23> The Python dependency for HTTPie is handled by most Linux and macOS package managers [1]. It would be great to have it in Windows package managers as well.

[1]: [https://httpie.org/doc#installation](https://httpie.org/doc#installation)

<comment><USER24> One time I tried to install HTTPie from ubuntu 16.04 apt repository I got an old version that was not compatible with httpie-jwt-auth so I had to install it using pip.

1\. pip3 install httpie.

2\. python3 -m pip install httpie.

3\. sudo pip install httpie.

Finally, it was working. Last week I upgraded to ubuntu 18.04 and surprise, httpie is not working. I didn't bother installing again from pip. Luckily this time, apt repository had a recent version.

Scrolling back through my terminal history, I see that I went through the same struggle with s3cmd.

So yeah, installing anything that requires python is a bit painful. Fortunately, someone in the comments mentioned [https://github.com/rs/curlie](https://github.com/rs/curlie) which is an HTTPie alternative in golang.

<comment><USER25> `snap install http` gets you the latest httpie, fwiw

<comment><USER24> Snapyy doesn't currently work in windows 10 WSL1 but hopefully will work in WSL2

</comment></comment></comment></comment></comment><comment><USER26> For someone who doesn't already know curl it might seem easier to use this, but otherwise it doesn't seem so useful.

Commands are a bit shorter (as it assumes json apparently) but, when working on the terminal, once I wrote my curl command I just keep repeating it anyway or just changing one parameter.

<comment><USER27> I have been using curl for command line http stuff for years and years. I tried out HTTPie a few months ago for testing a json-flavoured API and I found it is _amazing_ , it is so much less awkward than piping curl into jq and struggling with curl's POST body options

<comment><USER28> I'm in the same boat. Every time I have had to use curl over the past ~15 years I've had to look up how to do the few basic things I need to do. With HTTPie, its easy enough that I haven't needed to look anything up after the first two or three times.

Sure, cURL can do it and if I used it frequently enough, I guess I'd remember how to use it without having to look it up every time, but for my basic and infrequent use, HTTPie is more pleasant to me and I can remember how to use it.

</comment></comment></comment><comment><USER29> There's at least 1 thing curl can do but httpie cannot: anyauth where curl sends a request and based on the response curl will send another request with the correct authentication format.

</comment><comment><USER30> The major previous threads are

2018: [https://news.ycombinator.com/item?id=16243700](https://news.ycombinator.com/item?id=16243700)

2016: [https://news.ycombinator.com/item?id=12283365](https://news.ycombinator.com/item?id=12283365)

[https://news.ycombinator.com/item?id=11859777](https://news.ycombinator.com/item?id=11859777)

2015: [https://news.ycombinator.com/item?id=10418882](https://news.ycombinator.com/item?id=10418882)

2014: [https://news.ycombinator.com/item?id=7890367](https://news.ycombinator.com/item?id=7890367)

2012: [https://news.ycombinator.com/item?id=4261263](https://news.ycombinator.com/item?id=4261263)

</comment><comment><USER20> A wonderful program. Apparently this is a hot topic but I've found this tool after growing frustrated with how verbose curl is to type for simply trying out JSON APIs interactively. Combined with something like fx[1] this is a real treat.

[1] [https://github.com/antonmedv/fx](https://github.com/antonmedv/fx)

</comment><comment><USER31> This is the gold standard of CLI tools. Sure, cURL may technically be more capable, but HTTPie is friendier, more memorable, and clearly built with developer UX in mind.

<comment><USER32> It's the other way around, curl is so good its amost like using the spec. directly

</comment></comment><comment><USER33> alias wget='echo "using httpie as wget";http -d'

<comment><USER34> Why would you do this? If you want to use httpie why would type wget? If you're pasting a snippet that uses wget, wouldn't you want it to actually use wget?

I don't see any benefit of using this alias

</comment></comment><comment><USER35> I really like it for functional testing and for describing steps in peer reviews; it's concise and readable.

It's not the only tool out there; sometimes cURL makes more sense depending on the context. Use the right tool for the right job!

</comment><comment><USER36> This is one of the best cli tool I loved it 4 years ago and still do

</comment><comment><USER37> Can it dump all the scripts/images/etc being loaded on a specific website? (not refering to source)

</comment><comment><USER38> what about performance ?

<comment><USER39> I'd say that its intended use case is to familiarise yourself with APIs and test out functionality rather than use it in a place where performance really matters.

I use it all the time for just that, the API is so simple I rarely need to check the docs.

</comment></comment><comment><USER40> When I hear "curl alternative", I think of something low-level, portable and frankly, something that will compile _almost_ anywhere that has a C compiler.

But then I realized I'm thinking of libcurl, not curl. So maybe this isn't so bad in Python as a client tool. Does Python 3 still start up really slow though? (honest question)

<comment><USER41> No, Python has never (last decade) had a startup time that is noticeable by humans when running CLI scripts, unless your CLI script is importing a large codebase. JVM languages are an example of languages which do start up too slowly to be attractive for CLI scripting. You are right that python can be horribly slow to import a large codebase, for example when starting a web server in a large django project.

<comment><USER42> AOT compilation has come back to JVM languages both on HotSpot and Graal. There are now lots of ways to remove JVM startup time penalties and most of them provide for startup times that are as fast as Python independent of code size.

<comment><USER43> Does this apply to scala?

<comment><USER44> Scala Native [0] gives you AOT via LLVM, so it isn't quite the same thing, but can, in some circumstances, significantly speed up your code.

[0] [https://github.com/scala-native/scala-native](https://github.com/scala- native/scala-native)</comment></comment></comment></comment></comment>


Intel x86 considered harmful – survey of attacks against x86 over last 10 years - <AUTHOR> http://blog.invisiblethings.org/2015/10/27/x86_harmful.html <comment><USER3> "System management mode" is a tremendous wart and should be removed wholesale, with Intel adopting a more ARM-style trusted boot chain with explicit cooperation from the OS or hypervisor. And while you're at it, kill UEFI and install a pony for me.

(Seriously, SMM serves either bizarre ILO features that high-end vendors like but are rarely used, or security agencies looking for a layer to hide in.)

<comment><USER4> Actually ILO is pretty useful :-)

I have an APM (ARM64) Mustang, and this takes a rather different approach, but probably not one you'll think is better. The chip advertises 8 x 64 bit cores, but there's a 9th 32 bit core which runs all the time, even when the machine is powered down (although obviously still connected to mains power). It runs a separate firmware, in its own RAM, but can access the main memory at will and invisibly to the main OS.

One way to look at this is it's brilliant that we can just put a tiny Cortex-M3 in a spare bit of silicon and have it do useful management stuff.

<comment><USER3> _It runs a separate firmware, in its own RAM, but can access the main memory at will and invisibly to the main OS_

All watched over by hypervisors of loving grace.

How do you know what the firmware does? Is it even possible to inspect it, let alone replace it? It's just another part of the attack surface - <USER2> necessarily deliberately, but if there are exploitable bugs in that firmware that can be triggered from the rest of the system, it's another security risk.

<comment><USER4> It's possible to update it, not sure about replacing it with ones own code. I know this is "whataboutism" but here goes: Is this different from Intel ME processors with their "hidden" Sparc core?

[http://www.slideshare.net/codeblue_jp/igor-skochinsky- enpub](http://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub)

<comment><USER5> > Is this different from Intel ME processors with their "hidden" Sparc core?

Minor quibble: The IME is not Sun's _SPARC_ architecture, it's ARC International's ARC, the Argonaut RISC Core, which has its origins in (of all things) the Super Nintendo's SuperFX chip.

<comment><USER6> Didn't even know they had ARC processors in them. That's a trip.

</comment></comment></comment></comment></comment></comment><comment><USER7> Probably worth pointing out that the author is the project lead of Qubes, one of the very few promising projects in the vast wasteland of computer security.

<comment><USER8> Very few? Seriously?

<comment><USER7> Seriously. The vast majority of computer security effort is wasted on things like the advisory-and-patch cycle, pen testing, and virus scanning, which can never, by their very nature, provide computer security. That's not to say you don't have to do them — it's just that they're not _productive_.

<comment><USER8> Oh, I understand now and I agree wholeheartedly.

There's been some exciting progress in the formal verification department in recent years, though.

<comment><USER7> I agree!

</comment></comment></comment></comment></comment><comment><USER9> The book referred to by the article -- `Platform Embedded Security Technology Revealed` -- appears to be available for download at no cost right now[1]. Pricing error or not, I've just completed checkout without issue.

For completeness, I have no affiliation or correction with Apress -- please consider this a heads-up.

[1] [http://www.apress.com/9781430265719](http://www.apress.com/9781430265719)

<comment><USER10> It's free for months, so probably not a mistake.

</comment></comment><comment><USER11> So I read the blog post and skimmed the PDF and I'm left with some questions. IF these security issues have been present for 10 years, but there hasn't been any widespread malicious action on them, are they really issues?

To create an analogy, my car doesn't have bullet proof glass, someone could easily shoot it up and i'd be dead. But nobody really goes around shooting up cars, so is it an issue?

<comment><USER10> The problem is that if you're trying to build a secure computing environment (like Joanna is with Qubes OS), you run into limitations all the time.

Those platform issues may not be a problem for Jane Doe on Windows 10, but when users decide that they need more security than that (and Qubes points in the right direction, although there's still some miles to go) they may have a reason (or just paranoia).

In either case, they won't be very happy with the sad state that is x86 "security" because there are way too many places where an undue trust into Intel is implied.

Eg. the SGX feature, which can run userland code in a way that even the kernel (or SMM) can't read it: The keys are likely mediated by the Management Engine (ME) - which also comes with network access and a huge operating system (for the purposes of an embedded system: the smallest version is 2MB) that you, the user, can't get rid of.

So who's SGX protecting you from if you fear involvement by nation state actors? x86 isn't for you in that case (Intel's version in particular, but pretty much all alternatives are just as bad) - and that's what this paper points out.

<comment><USER12> Intel describe[1] SGX as a feature designed to "enable software vendors to deliver trusted[2] applications", where applications would "maintain confidentiality even when an attacker has physical control of the platform and can conduct direct attacks on memory".

This already suggests the owner of the CPU isn't who they are protecting, but it gets worse (even before we consider the risk from AMT). Starting an SGX enclave seems to require[3] a "launch key" that is only known by Intel, allowing Intel to control what software is allowed to be protected by SGX.

[1] [https://software.intel.com/en- us/blogs/2013/09/26/protecting...](https://software.intel.com/en- us/blogs/2013/09/26/protecting-application-secrets-with-intel-sgx)

[2] Before the term "DRM" was coined, the same crap used to be called "trusted computing" (back when Microsoft was pushing Palladium/NGSCB)

[3] [https://jbeekman.nl/blog/2015/10/intel-has-full-control- over...](https://jbeekman.nl/blog/2015/10/intel-has-full-control-over-sgx/)

<comment><USER13> This kind of feature would be amazing for security if it wasn't going to be immediately abused with DRM encumbered vendors, MS, and vague yet menacing government agencies trying to lock users out of their own devices.

If I could provide all the keys my machine could be completely locked down and damn near impossible to break into even with complete physical access and a ECE degree.

<comment><USER14> One thing we would actually want, here, though, is a setup where you can rent out your computer (i.e. as an IaaS provider), without being capable of monitoring the renter. In that kind of setup, the tenant does not want you to own "all the keys to your machine"—or, at least, they want to have some way to verify that you have disabled/discarded those keys.

<comment><USER15> I don't see the point of this. Either you trust your cloud provider, or you don't put it in the cloud. You could think of a technical solution to prevent monitoring, but how can you ever be sure that your provider has actually implemented it? Plus, I don't think providers would want something like this; if there's something gravely illegal going on, you want to be able to know and ban that user from your service.

</comment></comment></comment></comment></comment></comment><comment><USER16> An interesting point I read awhile ago (wish I could find the article) is that variable-length instruction sets (like x86) are preferred by authors of malicious software over fixed length sets because the binaries are harder to analyze. That is because in variable length ISAs, you must use a recursive decent parser to find all code paths in the program, because jump targets are specified in bytes or words instead of discrete instructions. This allows someone to jump into what might be the data portion of an instruction when parsed one way, and now the behavior totally changes because the bytes are being interpreted another way.

<comment><USER17> Are you talking about "The Geometry of Innocent Flesh on the Bone: Return- into-libc without Function Calls (on the x86)"([https://cseweb.ucsd.edu/~hovav/dist/geometry.pdf](https://cseweb.ucsd.edu/~hovav/dist/geometry.pdf))? Great paper with a great title.

<comment><USER16> I wasn't, I'm pretty sure it was a blog post not an academic paper. Regardless, this paper looks awesome thanks for the link :D

</comment></comment></comment><comment><USER18> Hmm, my favorite vulnerability is x86's lack of self-synchronization meaning that the same byte-stream could be two different streams of valid instructions depending on where you start reading.

[http://mainisusuallyafunction.blogspot.com/2012/11/attacking...](http://mainisusuallyafunction.blogspot.com/2012/11/attacking- hardened-linux-systems-with.html)

<comment><USER19> This technique is also used to render W^X useless.

</comment></comment><comment><USER20> There just have to be backdoors built into the Intel Management Engine. Intel won't disclose what code it executes, so we have to assume there's a backdoor. The question is, _whose_ backdoor.

It would be useful to install some honeypot machines which would appear to be interesting to governments (an ISIS bulletin board, for example) and record every packet going in and out.

<comment><USER6> This is why I laugh about people here that laugh about backdoors in their TRNG, etc. Intel's _been_ backdoored for AMT, etc for a while. Those circuits, due to NRE costs, have to be in most of their chips whether they advertise them or not. They have deep read access into everything in the system with who knows what write access. We also know some of their chipsets have radios in them which might be in the others, permanently or temporarily disabled.

Just a huge black box of interconnected black boxes at least one set of which is definitely a backdoor. And worst thing is I heard it can work when the machine is entirely or somewhat powered down. (!) I don't know for sure because I won't buy one lol. The old stuff less likely to have those features works fine for me with my builds.

Gaisler's stuff and RISC-V are best hope as they're both open hardware plus getting fast. Gaisler's are already quad-core with as much I.P. as people could ever use. Anyone wanting trustworthy hardware knows where to start on building it. CheriBSD on CHERI capability processor is also open-source and can run on a high-end FPGA. So, there's that for use or copying in a Gaisler modification.

<comment><USER21> > Gaisler's stuff and RISC-V are best hope as they're both open hardware plus > getting fast. Gaisler's are already quad-core with as much I.P. as people > could ever use. Anyone wanting trustworthy hardware knows where to start on > building it. CheriBSD on CHERI capability processor is also open-source and > can run on a high-end FPGA. So, there's that for use or copying in a Gaisler > modification.

How can you trust the FPGA? Or the very closed-source bitstream generator necessary to compile the VHDL/Verilog code?

Assuming you want to manufacture secure processors from these designs, how can you trust the chip fab?

I'm genuinely interested, as I'm not aware of any research into protection from these issues.

<comment><USER6> You have several ways to deal with trust issues in hardware:

1\. Monitor hardware itself for bad behavior.

2\. Monitor and restrict I/O to catch any leaks or evidence of attacks.

3\. Use triple, diverse redundancy with voter algorithms for given HW chip and function.

4\. Use a bunch of different ones while obfuscating what you're using.

5\. Use a trusted process to make the FPGA, ASIC, or both.

I've mainly used No's 2-4 with No 5 being the endgame. I have a method for No 5 but can't publish it. Suffice it to say that almost all strategies involve obfuscation and shellgames where publishing it gives enemies an edge. kerckhoff's principle is wrong against nation-states: obfuscated and diversified combination of proven methods is best security strategy. Now, ASIC development is so difficult and cutting edge that knowing that the processes themselves aren't being subverted is likely impossible.

So, my [unimplemented] strategy focuses on the process, people, and key steps. I can at least give an outline as the core requirements are worth peer review and others' own innovations. We'd all benefit.

1\. You must protect your end of the ASIC development.

1-1. Trusted people who won't screw you and with auditing that lets each potentially catch others' schemes.

1-2. Trusted computers that haven't been compromised in software or physically.

1-3. Endpoint protection and energy gapping of those systems to protect I.P. inside with something like data diodes used to release files for fabs.

1-4. Way to ensure EDA tools haven't been subverted in general or at least for you specifically.

2\. CRITICAL and feasible. Protect the hand-off of your design details to the mask-making company.

3\. Protect the process for making the masks.

3-1. Ensure, as in (1), security of their computers, tools, and processes.

3-2. Their interfaces should be done in such a way that they always do similar things for similar types of chips with same interfaces. Doing it differently signals caution or alarm.

3-3. The physical handling of the mask should be how they always do it and/or automated where possible. Same principle as 3-2.

3-4. Mask production company's ownership and location should be in a country with low corruption that can't compel secret backdoors.

4\. Protect the transfer of the mask to the fab.

5\. Protect the fab process, at least one set of production units, the same way as (3). Same security principles.

6\. Protect the hand-off to the packaging companies.

7\. Protect the packaging process. Same security principles as (3).

8\. Protect the shipment to your customers.

9\. Some of the above apply to PCB design, integration, testing, and shipment.

So, there you have it. It's a bit easier than some people think in some ways. You don't need to own a fab really. However, you do have to understand how mask making and fabbing are used, be able to observe that, have some control over how tooling/software are done, and so on. Plenty of parties and money involved in this. It will add cost to any project doing it which means few will (competitiveness).

I mainly see it as something funded by governments or private parties for increased assurance of sales to government and security-critical sectors. It will almost have to be subsidized by governments or private parties. My hardware guru cleverly suggested that a bunch of smaller governments (eg G-88) might do it as a differentiator and for their own use. Pool their resources.

It's a large undertaking regardless. Far as specifics, I have a model for that and I know one other high-assurance engineer with one. Most people just do clever obfuscation tricks in their designs to detect modifications or brick the system upon their use with optional R.E. of samples. I don't know those tricks and it's too cat n mouse for me. I'm focused at fixing it at the source.

EDIT: I also did another essay tonight on cost of hardware engineering and ways to get it down for OSS hardware. In case you're interested:

[https://news.ycombinator.com/item?id=10468534](https://news.ycombinator.com/item?id=10468534)

<comment><USER21> I guess I still don't follow. Allow me to better specify the threat model I have in mind:

Consumer wants one computer system that he trusts. Consumer should be able to get one without having to trust any of the manufacturers or integrators. They should not be able to subvert the security of the system, assuming the published code and specs contain no errors. There should be no black boxes to trust.

Design team wants to make and provide open hardware. They want to service Consumer, and they want to do it in a way that Consumer does not need to trust any blackbox processes.

How does this happen? Note that I'm not asking about keeping the VHDL code secure, how to physically secure the shipment to the fab company, etc. I'm asking how Consumer, who gets one IC, can verify that the IC matches exactly with the published VHDL code and contains no backdoors.

It seems you mainly focus on how the design team can minimise the chances of subversion. That's a much lower bar and not really sufficient in my mind. There's still too many places to subvert, and the end consumer still needs to trust his vendor, which is the same situation we have today.

The bit about multiple independent implementations with voting (NASA-style) sounds extremely expensive and inefficient, but also very interesting for high-security systems. Are you aware of any projects implementing it for a general-purpose computer, specifically to prevent hardware backdooring (as opposed to for reliability)?

UPDATE: To clarify, as wording is important in these kinds of discussions: When something is described as 'trusted', that's a negative to me, as a 'trusted' component by definition can break the security of the system. We need a way to do this without 'trusted' components. So when you say 'Use a trusted process to make the FPGA, ASIC, or both.', that sounds like exactly what we have today - the consumer gets a black box, and no way to verify that it does what it's claimed to do. The black box must be 'trusted' because there's no other way. Me knowing that the UPS shipment containing the mask had an armed guard does not make me more likely to want to trust the chip.

<comment><USER6> "Design team wants to make and provide open hardware. They want to service Consumer, and they want to do it in a way that Consumer does not need to trust any blackbox processes. How does this happen?"

That was covered here: " I have a method for No 5 but can't publish it. Suffice it to say that almost all strategies involve obfuscation and shellgames where publishing it gives enemies an edge."

There are black box processes trusted and checked in my best scheme, though, with security ranging from probabilistic to strong with some risks. Mainstream research [1] has a few components of mine. They're getting closer. DARPA is funding research right now into trying to solve the problem without trust in masks or fabs. We're not there yet. Further, the circuits are too small to see with a microscope, the equipment is too expensive, things like optimal proximity correction algorithms too secret, properties of fabs too varying, and too little demand to bring this down to so just anyone can do it and openly. Plus, even tooling itself is black boxes of black boxes out of sheer necessity due to esoteric nature, constant innovation, competition, and patents on key tech.

Note: Seeing chip teardowns at 500nm-1um did make me come up with one method. I noted they could take pictures of circuits with a microscope. So, I figured circuit creators could create, distribute, and sign a reference image for what that should look like. The user could decap and photo some subset of their chips. They could use some kind of software to compare the two. If enough did this, a chip modification would be unlikely except as a denial-of-service attack. Alas, you stop being able to use visual methods around 250nm and it only gets harder [2] from there.

Very relevant is this statement by a hardware guru that inspired my methods which embrace and secure black boxes instead of go for white boxes:

"To understand what is possible with a modern fab you'll need to understand cutting edge Lithography, Advanced directional etching , Organic Chemistry and Physics that's not even nearly mature enough to be printed in any text book. These skills are all combined to repeatedly create structures at 1/10th the wavelength of the light being used. Go back just 10 or 15 years and you'll find any number of real experts (with appropriate Phd qualifications) that were willing to publicly tell you just how impossible the task of creating 20nm structures was, yet here we are!

Not sure why you believe that owning the fab will suddenly give you these extremely rear technical skills. If you dont have the skills, and I mean really have the skills (really be someone that knows the subject and is capable of leading edge innovation) then you must accept everything that your technologists tell you, even when they're intentionally lying. I cant see why this is any better then simply trusting someone else to properly run their fab and not intentionally subvert the chip creation process.

In the end it all comes down to human and organizational trust, "

Very well said. Still an argument for securing machines they use or transportation of design/masks/chips. The critical processes, though, will boil down to you believing someone that claims expertise and to have your interests at heart. I'm not sure I've even seen someone fully understand an electron microscope down to every wire. I'll assure you the stuff in any fabrication process, from masks to packaged IC's, are _much_ more complex. Hence, my framework of looking at it.

"how to physically secure the shipment to the fab company, etc. I'm asking how Consumer, who gets one IC, can verify that the IC matches exactly with the published VHDL code and contains no backdoors."

Now, for your other question, you'd have to arrange that with the fabs or mask makers. Probably cost extra. I'm not sure as I don't use the trusted foundry model [yet]. My interim solution is a combination of tricks that don't strictly require that but are mostly obfuscation. You'd need guards you can trust who can do good OPSEC and it can never leave your sight at customs. You still have to trust mask maker, fab, and packager. That's the big unknown, though, ain't it? The good news is that most of them have a profit incentive to crank out product fast in a hurry at lowest cost while minimizing any risks that hurt business. If they aren't attacking or cooperating, it's probably for that reason.

"how to physically secure the shipment to the fab company, etc. I'm asking how Consumer, who gets one IC, can verify that the IC matches exactly with the published VHDL code and contains no backdoors."

That's semi-true. Re-read my model. The same one can protect the consumer with minor tweaks. That's because my model maps to the whole lifecycle of ASIC design and production. One thing people can do is periodically have a company like ChipWorks tear it down to compare it to published functionality. For patents and security, people will do that already if it's a successful product. So, like Orange Book taught me long ago, I'm actually securing the overall process plus what I can of its deliverables. So long as process stays in check, it naturally avoids all kinds of subversions and flaws. High assurance design and evaluation by independent parties with skill do the rest.

"The bit about multiple independent implementations with voting (NASA-style) sounds extremely expensive and inefficient, but also very interesting for high-security systems. Are you aware of any projects implementing it for a general-purpose computer, specifically to prevent hardware backdooring (as opposed to for reliability)?"

It's not extremely expensive: many embedded systems do it. Just takes extra hardware, an interconnect, and maybe one chip (COTS or custom) for the voting logic. These can all be embedded. Those of us doing it for security all did it custom on a per-project basis: no reference implementation that I know of. There's plenty of reference implementations for the basic scheme under phrases triple modular redundancy, lockstep, voting-based protocols, recovery-oriented computing, etc. Look up those.

You can do the voting or error detection as real-time I/O steps, transactions, whatever. You can use whole systems, embedded boards, microcontrollers, FPGA's, and so on. The smaller and cheaper stuff has less functionality with lower odds of subversion or weaknesses. Helps to use ISA's and interfaces with a ton of suppliers for diversity and obfuscation part. If your targeted, don't order with your name, address, or general location. A few examples of fault- tolerant architectures follow. You're just modifying them to do security checks and preserve invariants instead of mere safety checks, although safety tricks often help given the overlap.

App-layer, real-time embedded [http://www.montenegros.de/sergio/public/SIES08v5.pdf](http://www.montenegros.de/sergio/public/SIES08v5.pdf)

Onboard an ASIC in VHDL [http://www.ijaet.org/media/Design-and-analysis-of- fault-tole...](http://www.ijaet.org/media/Design-and-analysis-of-fault- tolerant-Microprocessor-based-on-TMR-using-VHDL-Copyright-IJAET.pdf)

FPGA scheme [http://crc.stanford.edu/crc_papers/yuthesis.pdf](http://crc.stanford.edu/crc_papers/yuthesis.pdf)

A survey of "intrusion-tolerant architectures" which give insight [http://jcse.kiise.org/files/V7N4-04.pdf](http://jcse.kiise.org/files/V7N4-04.pdf)

"To clarify, as wording is important in these kinds of discussions: When something is described as 'trusted', that's a negative to me, as a 'trusted' component by definition can break the security of the system."

Oops. I resist grammar nazi's but appreciate people catching wording that really affects understanding. That example is a mistake I intentionally try to avoid in most writing. I meant "trustworthy" and "trusted" combined. You can't avoid trusted people or processes in these things. The real goal should be to minimize amount of trust necessary while increasing assurance in what you trust. Same as for system design.

"Me knowing that the UPS shipment containing the mask had an armed guard does not make me more likely to want to trust the chip."

Sorry to tell you that it's not going to get better for you outside making sacrifices of above-style schemes which are only probabilistic and with singificant unknowns in the probabilities. Tool makers, fabs, and packaging must be semi-trusted in all schemes I can think of. They must be turned into circuitry at some point. Best mix is putting detection, voting, or something critical on an older node or custom wiring. What you can vet by eye if necessary. Can still do a lot with 350nm. Many high assurance engineers use older hardware with hand-designed software between modern systems due to subversion risk. I have a survey [3] of that stuff, too. :)

Note: My hardware guru did have a suggestion I keep reconsidering. He said most advanced nodes are so difficult [4] to use that they barely function at all. Plus, mods of an unknown design at mask or wiring level are unlikely to work except most simplistic cases. I mean, they spend millions verifying circuits they _understand_ , so arbitrary modifications to black boxes should be difficult. His advice, though expensive, was to use most cutting-edge node in existence while protecting transfer of design and the chips themselves. Idea being that subversion of ASIC itself would fail or not even be tried due to difficulty. I like it more I think about it.

[1] [https://www.cs.virginia.edu/~evans/talks/dssg.pptx](https://www.cs.virginia.edu/~evans/talks/dssg.pptx)

[2] [https://www.iacr.org/archive/ches2009/57470361/57470361.pdf](https://www.iacr.org/archive/ches2009/57470361/57470361.pdf)

[3] [https://www.schneier.com/blog/archives/2013/09/surreptitious...](https://www.schneier.com/blog/archives/2013/09/surreptitiously.html#c1762647)

[4] [http://electronicdesign.com/digital- ics/understanding-28-nm-...](http://electronicdesign.com/digital- ics/understanding-28-nm-soc-design-arm-based-cores)

</comment></comment></comment></comment></comment></comment><comment><USER22> " "Considered Harmful" Article Titles Considered Derivative and Uncreative"

</comment><comment><USER6> Best enumeration of x86 security problems I've seen so far. Solid argument to avoid Intel in security-critical products where possible. :)

</comment><comment><USER23> The title's dumb but the paper has some good info in it.

</comment><comment><USER24> To paraphrase Stroustrup:

There are two kinds of systems: the ones that have security holes and the ones that people don't use.

</comment><comment><USER25> Yes yes, everyone should move to MCST Elbrus :D

<comment><USER6> No, use Gaisler's stuff:

[http://www.gaisler.com/index.php/products/ipcores/soclibrary](http://www.gaisler.com/index.php/products/ipcores/soclibrary)

Also SPARC but with plenty GPL. Has a quad-core, too, with all of them designed to be easily modified and re-synthesized. :)

<comment><USER26> There are a few of these (open architectures) - but does anyone know how much (ballpark) it'd cost to make something like the Raspberry Pi 2 (ie: a full SoC, with gig ethernet, usb, hdmi, sata) support? Say 10.000 units?

I'm assuming it'd be expensive, as it doesn't appear anyone's doing it...

<comment><USER27> Several million dollars. Everything is extremely expensive - IP licenses, ASIC layout software licenses, simulation and verification software and possibly hardware, mask costs, line setup costs, wafer production costs, packaging costs, testing costs, etc.

<comment><USER26> Ip licences for gpled cpu cores and schemas? Several million doesn't sound that bad. Means that the bar moves to 100k rather than 10k units (if the goal is to break even in the short term). And it's tricky to sell 20k units/year for five years, as the cost to upgrade (clock, ram) would probably be in the same ballbark aa initial investment.?

<comment><USER27> IP licenses for things like analog clock management components/PLLs, analog Ethernet PHYs, analog serializers and deserializers for HDMI, SATA, USB 3, etc. These are all mixed-signal components. I am not aware of any open source designs for any of these for modern ASIC targets. Most open source designs target FPGAs which already have these components built onto the FPGA itself (i.e. the open source design uses the module as a 'black box'). These will probably come in GDSII form (actual layout, not a schematic, RTL, etc.) for a specific process with a specific foundry. If you want to design those yourself, then you would have to get additional licenses for analog design and simulation suites. And you might have to re-spin a couple of times (with millions of $ in mask costs) on each targeted process technology to get the kinks worked out.

<comment><USER26> Thank you for clarifying. Basically I thought maybe something like:

[http://opencores.org/donation](http://opencores.org/donation)

already existed - but apparently not (except for targeting FPGAs as you mention) ?

<comment><USER6> He addressed your point when he said most of them target FPGA's and often leverage what's already on them. I'll add that the quality, documentation, and so on at opencores.org seems questionable given all the complaints I read from pro's and amateurs alike. Some are good but I'm not qualified to say past what was ASIC-proven.

The analog stuff he mentioned is _really tricky_ on any advanced node. Everything is difficult at least. It all needs good tooling that's had around a billion a year in R&D (Big Three) going back over a decade to get to the point they are. OSS tooling is getting better, esp for FPGA's. However, open- source ASIC's are going to happen with open source development model. Like many great things, they'll be built by teams of pro's and then open-source _D_. Gotta motivate them to do that. Hence, my development models in the other post.

<comment><USER26> Right. Which is of course why we have stuff like the NASA/ESA making and releasing designs - big government projects with highly skilled staff. But they don't have much interest in releasing a "personal computer" or a "smart phone" (I'm sure they'd love to have an open hw platform to use for smart phones and tablets - or work stations and super computers, just that it's not high up on the list of priorities in the "millions of dollars" budget lists).

[ed: I'm thinking of things like LEON etc - but as mentioned, and as I understand it, for the ASIC case, maybe not the whole eval board is open. And it's not really in the same ballpark as the dual/quad multi-GHz cpus we've come to expect from low-end hard-ware:

[http://www.gaisler.com/index.php/products/boards/gr-cpci- leo...](http://www.gaisler.com/index.php/products/boards/gr-cpci-leon4-n2x) ]

<comment><USER6> Oh, let me be clear that any starting point will definitely have more work to do and will _never_ be in ballpark as top Intel/AMD/IBM CPU's. The reason is that they use large teams of pro's with the best tools often doing _full- custom_ HW development. Full-custom means they'll do plenty to improve HDL, RTL, and even wiring of gates they use. Think of Standard Cell as Java web applications with full custom being like delivering a whole platform with a board, firmware, assembler, OS components, and native applications. That's maybe illustrative of the differences in skills and complexity.

Example of custom design flow [http://viplab.cs.nctu.edu.tw/course/VLSI_SOC2009_Fall/VLSI_L...](http://viplab.cs.nctu.edu.tw/course/VLSI_SOC2009_Fall/VLSI_Lecture_03.pdf)

Note: Load up this right next to the simple, 90nm MCU PDF I gave you and compare the two. I think that you'll easily see the difference in complexity. One you'll be able to mostly follow just googling terms and understand a lot of what they're doing. You're not going to understand the specifics of the full-custom flow at all. Simply too much domain knowledge built into it that combines years of analog and digital design knowledge. Top CPU's hit their benchmarks using full-custom for pipelines, caches, etc.

Example of verification that goes into making those monstrosities work:

[http://fvclasspsu2009q1.pbworks.com/f/Yang- GSTEIntroPSU2009....](http://fvclasspsu2009q1.pbworks.com/f/Yang- GSTEIntroPSU2009.pdf)

So, yeah, getting to that level of performance would be really hard work. The good news is that modern processors, esp x86, are lots of baggage that drains performance that we _don 't need_. Simpler cores in large numbers with accelerators can be much easier to design and perform much better. Like so:

[http://www.cavium.com/OCTEON-III_CN7XXX.html](http://www.cavium.com/OCTEON- III_CN7XXX.html)

Now, that's 28nm for sure. Point remains, though, as Cavium didn't have nearly the financial resources of Intel despite their processors smoking them in a shorter amount of time. Adapteva's 64-core Epiphany accelerator was likewise created with a few million dollars by pro's and careful choice of tooling. So, better architecture can make up for the lack of speed that comes from full- custom.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER28> The footnote link [13] in section "The audio card" is an unrelated footnote, the correct one appears to be missing.

</comment><comment><USER29> I really could do without "considered harmful" titles. x86 has been one of the most influential technologies of all time and a clickbait title doesn't do it justice imo.

<comment><USER30> The currently prefered clickbait title on HN would be "x86 is the new goto"

<comment><USER31> Really? I only see one of those, from 5 years ago:

[https://hn.algolia.com/?query=%22the%20new%20goto%22&sort=by...](https://hn.algolia.com/?query=%22the%20new%20goto%22&sort=byDate&dateRange=all&type=story&prefix&page=0)

<comment><USER30> I meant generic _X is the new Y_ ; "goto" was just a nod to Dijkstra's.

</comment></comment></comment></comment><comment><USER32> Don't they know considered harmful essays are considered harmful? [http://meyerweb.com/eric/comment/chech.html](http://meyerweb.com/eric/comment/chech.html)

</comment><comment><USER33> Why the second post?

[https://news.ycombinator.com/item?id=10458311](https://news.ycombinator.com/item?id=10458311)

<comment><USER34> [https://news.ycombinator.com/item?id=10223645](https://news.ycombinator.com/item?id=10223645) "We've adjusted the dupe detector to reject fewer URLs...[snip/].. Allowing reposts is a way of giving high-quality stories multiple chances at making the front page. Please do this tastefully and don't overdo it."

Considering that this second post got much more traction than the first, I don't see anything wrong.

<comment><USER31> In this case the same submitter posted two versions of the story:

[http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf](http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf)

[http://blog.invisiblethings.org/2015/10/27/x86_harmful.html](http://blog.invisiblethings.org/2015/10/27/x86_harmful.html)

Not a great approach; one ought just to pick the better of the two, which in this case is the html, because it gives more background, loads faster, and links to the pdf.

General remark: I doubt that we'll make the dupe detector sophisticated enough to catch a case like this, but I do think we'll add software support for users to identify dupes when they see them. That's what happens informally already (as you all did in this thread, and by flagging the other post) so the shortest path to better deduplication for HN seems to be: write software to make community contribution easy. Also I kind of like the idea of giving a karma point to the first user who correctly links a given pair of posts.

</comment></comment></comment><comment><USER35> For all of its shortcomings, I still would pick x86 over mips (which is truly horrendous, or maybe it's just once you go cisc you never take the risc) any day of week

<comment><USER36> Nothing in this paper has anything to do with the ISA.

<comment><USER37> But in practice if you deal with x86 even AMD isn't that much better.</comment></comment></comment>


Learning to code will eventually be as useful as learning Ancient Greek - <AUTHOR> https://work.qz.com/1135017/learning-to-code-will-eventually-be-as-useful-as-learning-ancient-greek/?mc_cid=b88a0dd101&mc_eid=261d7988d8 <comment><USER2> As useful as Ancient Greek?

Comment from Cambridge University:

"What careers do those with a Classics degree go on to? Few degrees offer the same opportunities for acquiring advanced skills in languages, analytical thinking, essay-writing, visual analysis, critical sensitivity, spotting a biased source at a hundred paces, and so on. No wonder that Cambridge classicists are amongst the most employable graduates in the country. Our students have gone on to law, journalism, film and television, banking, consultancy, marketing, museum and gallery work, teaching and academia. In the Guardian's last two University Guide to Classics, Cambridge came top in the country for 'Career Prospects'.

<comment><USER3> Classics at prestigious universities—and especially, I would think, at Cambridge—is a major that tends to attract people that, for class and other reasons, have strong employment prospects independent of educational choices. So, sure, its unsurprising that it _correlates_ with good employability, but I'm somewhat suspicious of claims that it _produces_ that employability.</comment></comment>


Sorting Algorithm Animations - b-man http://www.sorting-algorithms.com/

<comment><AUTHOR> "These visualizations are intended to show that there is no best sorting algorithm."

Thank you. Once we hackers stop debating, we can address the problem at hand.</comment>


IRS issues additional guidance on tax treatment for cryptocurrency - <AUTHOR> https://www.irs.gov/newsroom/virtual-currency-irs-issues-additional-guidance-on-tax-treatment-and-reminds-taxpayers-of-reporting-obligations <comment><USER2> So if you get a new coin from a hard fork, you owe taxes on the fair market value of that new coin you get. This seems pretty dangerous - if the fair market value is high on the first day of trading, but declines a lot, you could get taxed on value that you never realized.

It seems like this will incentivize people to sell off new tokens immediately, in order to pay the taxes they incurred during the fork.

To me it seems very unintuitive to tax a hard fork. It is like taxing a stock split. Your asset hasn't really changed, it is just now represented in a different way.

Another weird thing about these taxes is that they assume that one of the forks is the "real asset" and the other fork is the "new asset". In practice, it seems like a lot of times a fork happens along with a lot of argument about which side of the fork is the "real" one.

Well, I guess the IRS does not see cryptocurrency the same way as my intuition would.

<comment><USER3> > It is like taxing a stock split. Your asset hasn't really changed, it is > just now represented in a different way.

It's not like taxing a stock split. In a 1:2 stock split, you go from having 1 share of AAPL worth $100 to 2 shares of AAPL worth $50 each for a total of $100. It's the same ticker, and represents beneficial ownership of the same fraction of Apple, Inc.

A better analogy might be a dividend. If you hold 1 share of AAPL and it issues a dividend, you now have 1 share of AAPL and + $2.00. This $2.00 is totally unrelated to your ownership stake of AAPL (which of course cryptos don't represent anyways), new value, and you will owe taxes on this event. IMO a crypto fork amounts to a taxable distribution.

A capital gain in these circumstances is actually what you want, because it would be offset by a future capital loss. To your point, the original distribution "plants the flag" with respect to the amount it's worth. If the value drops to 1/3 by the end of the first trading day like a typical crypto pump-n-dump, when you then dispose of that asset, your capital loss from the sale offsets the capital gain from the "flag plant" and you only pay taxes on the new value generated.

It's actually quite fair.

> It seems like this will incentivize people to sell off new tokens > immediately, in order to pay the taxes they incurred during the fork.

Not necessarily immediately but definitely by the end of the quarter or by the end of the tax year.

<comment><USER4> A dividend is not "new value" or "unrelated to your ownership stake". If you hold stock worth $100 and you get a $2 dividend, value of the stock drops to $98. Just like a stock split, or a cryptocurrency hard fork: before the event you had some assets worth $100 and after the event you have some assets worth $100. (Plus some -- mostly random -- fluctuation in asset prices.)

<comment><USER3> You are correct it's not new value per se, I was sort of glossing over that.

A dividend is in fact unrelated to your ownership stake. Before a dividend and after a dividend, you continue to own the same percentage of the underlying entity. You could use the dividend to in fact increase your beneficial ownership stake by re-investing it in the security. What has changed is the market value of your shares -- and to your point, by the dividend amount.

With a crypto fork, what's happening is someone is creating a new asset out of thin air, by copying an existing chain. When that happens, you now have two "assets" X and Y. The value may not even be correlated in any way. If I forked the BTC chain to create MagicPonziCoin2, it's not going to change the value of BTC whatsoever. This is recording that there's some initial value to the post- fork coin. If the fork affects the original holding, you can recognize your gain or losses by selling. If the post-fork coin changes in value, you can recognize your gain or loss there by selling relative to the value at your acquisition.

<comment><USER4> Hard forks can not magically create money out of thin air. If the "new" chain has some value post-fork, that value has been siphoned off the "old" chain (technically neither is "new" or "old" relative to each other, but bear with me for a minute).

Suppose the opposite was true. If you could create value out of thin air like that, we could all get rich just by forking cryptos over and over again. I know it _seems like_ this has been happening in past 2 years. It's an example of irrational market behavior. There is no* reason hard fork should create value.

*Sibling comment is also correct. A hard fork may create value by separating two entities which can thrive separately better than they can together. Similar to how a company that is shelling out dividends may be more valuable than a company which hoards cash.

However, in a rational market this information would be incorporated into prices _before_ the hard fork: there is still no rational reason for the total price of assets to magically jump after the event.

<comment><USER5> >If the "new" chain has some value post-fork, that value has been siphoned off the "old" chain

Not necessarily. I don't see how that follows at all.

>Suppose the opposite was true. If you could create value out of thin air like that, we could all get rich just by forking cryptos over and over again. I know it _seems like_ this has been happening in past 2 years. It's an example of irrational market behavior. There is no* reason hard fork should create value.

How does that matter to the IRS whether market is being irrational or rational?

>However, in a rational market this information would be incorporated into prices _before_ the hard fork: there is still no rational reason for the total price of assets to magically jump after the event.

The crypto market is full of hype and irrational actors

<comment><USER4> > >If the "new" chain has some value post-fork, that value has been siphoned > off the "old" chain

> Not necessarily. I don't see how that follows at all.

If you can make infinite money out of thin air by making infinite hard forks, go ahead. No-one's stopping you.

> >Suppose the opposite was true. If you could create value out of thin air > like that, we could all get rich just by forking cryptos over and over > again. I know it _seems like_ this has been happening in past 2 years. It's > an example of irrational market behavior. There is no* reason hard fork > should create value.

> How does that matter to the IRS whether market is being irrational or > rational?

I didn't say it matters to the IRS.

> >However, in a rational market this information would be incorporated into > prices _before_ the hard fork: there is still no rational reason for the > total price of assets to magically jump after the event.

> The crypto market is full of hype and irrational actors

We are in agreement here.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> In honor of the IRS fork guidance I'm announcing BBV — Bitcoin Bruce's Vision.

It's a Bitcoin fork that gives me an extra 1 million coins. I'll sell one sat to you for $300.

Also: I'm sending a 12 word seed phrase poem to each member of Congress right before the fork.

[https://twitter.com/brucefenton/status/1181981988221329413](https://twitter.com/brucefenton/status/1181981988221329413)

<comment><USER7> Might even be profitable!

[https://money.cnn.com/2010/03/02/pf/taxes/rat_out_tax_cheat/](https://money.cnn.com/2010/03/02/pf/taxes/rat_out_tax_cheat/)

</comment></comment><comment><USER8> If you hold pre-fork currency, and there is a hard fork: IF you gain any of the new currency THEN it's income ELSE it's not.

To quote the final paragraph, emphasis mine:

[https://www.irs.gov/pub/irs-drop/rr-19-24.pdf](https://www.irs.gov/pub/irs- drop/rr-19-24.pdf)

HOLDINGS

(1) A taxpayer _does not_ have gross income under § 61 as a result of a hard fork of a cryptocurrency the taxpayer owns _if_ the taxpayer _does not receive_ units of a _new cryptocurrency_.

(2) A taxpayer _has_ gross income, ordinary in character, under § 61 as a result of an airdrop of a new cryptocurrency following a hard fork _if_ the taxpayer _receives units of new cryptocurrency_.

<comment><USER9> Don't you automatically "receive/gain" the new currency upon a hard fork? Or am I misunderstanding these words?

<comment><USER10> Depends on how you define "receive". Also "new".

If currency X is hardforks and there now exist X and X' then in all ordinary cases you have access to both X and X'. But did you receive? Your access is because X' copies/extended X's state when it came into existence. There wasn't any new transfer to you.

One part of the text sounds like it's possible to not "receive": "Situation 1: A holds 50 units of Crypto M, a cryptocurrency. On Date 1, the distributed ledger for Crypto M experiences a hard fork, resulting in the creation of CryptoN. Crypto N is not airdropped or otherwise transferred to an account owned or controlled by A."

Another part of the text describing the same facts, instead makes it sound like reception is determined by resulting control: "Situation 1: A did not receive units of the new cryptocurrency, Crypto N, from the hard fork; therefore, A does not have an accession to wealth and does not have gross income under § 61 as a result of the hard fork."

So, taking both these parts together, it sounds like situation 1 is describing an irrelevant and obvious case. It's technically possible for N to be created and copy currency M but leave out A's coins. Obviously A wouldn't owe any taxes as a result. Duh. This wasn't a case anyone was concerned with.

So what if you instead say okay, the coins you got access to via state copying were "received"\-- well okay, but now in that case the many times ethereum or bcash were hardforked and the original systems were largely, but not completely, abandoned you'd then owe income tax on essentially the entirety of your holdings. 0_o

</comment></comment></comment><comment><USER11> Finally! Guidance on airdrops and forks was sorely needed.

The guidance seems mostly in line with expectations, but I find one bit confusing. The IRS is drawing a distinction between a hard fork with an airdrop and a hard fork without an airdrop. I don't understand the concept of a hard fork without an airdrop. If the new chain doesn't at least maintain the balances of all existing accounts using the new chain's token, then IMO it's not a fork at all but simply the launch of a new cryptocurrency. Can someone give an example of the kind of hard fork with no airdrop the IRS is talking about?

<comment><USER10> > The guidance seems mostly in line with expectations,

I'm curious what expectation you feel it met?

I believe it somehow managed to provide absolutely no clarity on any of the difficult questions. And to the extent that one can attempt to apply it literally and conservatively the results are unconscionable (e.g. having to pay income tax many times over on any hardfork-prone cryptocurrency).

The only way that I can see that this met expectations is that those of us that don't own hardfork prone centrally administered assets and diligently sold fork coins ASAP and recording ordinary income for their sale won't be impacted significantly by this. But anyone who didn't do those things is now in a world of confusion.

<comment><USER11> I expected that airdrops would be ordinary income based on the market value at airdrop time. I expected that stock split rules would not apply to forks (though this may seem obvious, there were many that were arguing the opposite). I was hoping that tokens you can't access due to exchanges not supporting them or whatever don't count as income. Those are all aligned with my expectations.

I agree that the rules are stupid and have bad outcomes in many cases. But I didn't expect IRS guidance to change that. I also agree that the guidance is ambiguous on hard forks (is it an "airdrop" or not?) and that's a big problem.

<comment><USER10> Except in the situation where the HF coin gets the original ticker or the very rare situation that there is a liquid futures market in advance of the fork (has only arguably happened once that I'm aware of) there is no market value at the time of the fork-- the fork happens at an instant, and the asset cannot be traded at or before that instant.

A market value might well be established in the hours or days after, but it isn't always.

In cases where the newly created cryptocurrency immediately carries the market there is an unambiguous value for the new system (and the original cryptocurrencies value becomes ambiguous), but applying income tax to the new asset there leads to absurd results.

I agree that the ruling seems to generally support some aspects of one of the most obvious conclusions in the simplest of cases, but it fails to meaningfully clarify the application... and also suggests some absurdities that almost no one was expecting.

<comment><USER11> I hadn't considered the situation where the forked coin is the one that retains most of the value. I think in that situation I would be comfortable arguing to the IRS that the old currency is actually the fork, e.g. ETC vs ETH. The technical and legal definitions of "fork" don't necessarily have to match.

I would also be comfortable using the first trading day's close as the market value rather than the instantaneous value at fork time which as you say doesn't exist in most cases. Of course the "close" time is arbitrary but as long as you have a consistent methodology for choosing it you should probably be OK.

In any case, it's clear the IRS didn't think hard enough about the consequences of their guidance here. I hope they clarify more but we are probably in for another long wait. Ideally, Congress would do something to make the rules more reasonable.

<comment><USER10> > I hadn't considered the situation where the forked coin is the one that > retains most of the value. I think in that situation I would be comfortable > arguing to the IRS that the old currency is actually the fork, e.g. ETC vs > ETH. The technical and legal definitions of "fork" don't necessarily have to > match.

Agreed, but that appears to contradict the plain text of the ruling.

It's also not guaranteed to be unambiguous. Even with ETH/ETC and BTC vs BCH/BSV there are people that argue the forks are the real thing, though I agree that they're crazy. But it isn't hard to imagine a situation where the split were closer to 50/50 (and maybe both sides got different tickers).

It's also possible for it to look like one won but have the situation reverse... E.g. it's not completely implausible that ETH might have won originally, but then a week in the political winds changed, all the hash power moved to ETC leaving ETH useless and then had the ethereum foundation people say the fork was a mistake, and then everyone followed along with giving the old chain back the ticker.

When BSV split off, there were two chains each incompatible with each other and the original rules didn't continue (in that case). Many exchanges listed two assets, transferring any bcash holdings into each equally, "Bitcoin ABC" and "Bitcoin SV". Other exchanges gave ABC the BCH ticket. I think at least one gave BSV the BCH ticker. Over time the ABC side got the BCH ticker everywhere. I imagine if BSV had succeeded in their effort to get more hash power the situation would still be highly inconsistent.

In some cases cryptocurrencies have made additional consensus rule changes to make sure hardforks couldn't be undone, in some cases they haven't. Their understanding of hardforks seems to assume that all hardforks are bilateral, but in many cases they're actually one sided and could be undone.

I agree that your interpretation should be the one adopted when it is unambiguous.

> I would also be comfortable using the first trading day's close as the > market value

I would agree if we were talking about orderly or regulated markets. For example, in many bitcoin forks the fork was not meaningfully tradable for a week or more-- and when it became tradable it was only tradable on obscure foreign exchanges whos terms and conditions forbid US residents from using the service. In these illiquid markets the prices have been rather distorted.

FWIW, the interpretation I adopted was that I've just sold fork quickly as soon as I could reasonably move them to a place to sell them, then reconized as income the value I actually received in selling them. ... at least the forks I knew about, but there have likely been other forks that I've never heard of.

There are also likely coins that I could be argued to technically control but which I don't currently know about-- stuff like coins mined in 2012 which are currently lost in corrupted wallet files (or perhaps with forgotten passwords that I'll eventually crack) on old system images that I'll probably find some day, but which I don't know about right now, even after doing a bit of looking.

Consider: for people actually using Bitcoin rather than speculating in an exchange account-- their bitcoin holdings can look a lot more like USD laying around your house than like your S&P 500 ETF in your brokerage account.

Because of these lost cases I think it would be much more reasonable to state that ordinary income is only realized when you demonstrate actual control over the coins, e.g. by moving them. This would have the effect of allowing people to delay the income tax, but they'd do so only with serious risk of value loss and at the cost of delaying the starting date for a capital gains calculation (so it would fail an equivalents test). This would nicely eliminate a lot of the absurd corner cases, including stuff like the winner flip/flop.

<comment><USER11> > FWIW, the interpretation I adopted was that I've just sold fork quickly as > soon as I could reasonably move them to a place to sell them, then reconized > as income the value I actually received in selling them. ... at least the > forks I knew about, but there have likely been other forks that I've never > heard of.

Yup, I did the same. If the IRS audits us we may have to change our calculations but the absolute difference in tax owed should be small.

My understanding is that despite their reputation the IRS is usually fairly chill about this sort of thing if you demonstrate you had good intent. I hope I never have to test that though. Unambiguous guidance sure would be nice!

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> I think this is the first time that the IRS has explicitly stated that specific identification is a valid accounting method for virtual currency:

Q36. I own multiple units of one kind of virtual currency, some of which were acquired at different times and have different basis amounts. If I sell, exchange, or otherwise dispose of some units of that virtual currency, can I choose which units are deemed sold, exchanged, or otherwise disposed of?

A36. Yes. You may choose which units of virtual currency are deemed to be sold, exchanged, or otherwise disposed of if you can specifically identify which unit or units of virtual currency are involved in the transaction and substantiate your basis in those units.

Q37. How do I identify a specific unit of virtual currency?

A37. You may identify a specific unit of virtual currency either by documenting the specific unit's unique digital identifier such as a private key, public key, and address, or by records showing the transaction information for all units of a specific virtual currency, such as Bitcoin, held in a single account, wallet, or address. This information must show (1) the date and time each unit was acquired, (2) your basis and the fair market value of each unit at the time it was acquired, (3) the date and time each unit was sold, exchanged, or otherwise disposed of, and (4) the fair market value of each unit when sold, exchanged, or disposed of, and the amount of money or the value of property received for each unit.

Note, however, that they also clarify that this is not the default accounting method:

Q38. How do I account for a sale, exchange, or other disposition of units of virtual currency if I do not specifically identify the units?

A38. If you do not identify specific units of virtual currency, the units are deemed to have been sold, exchanged, or otherwise disposed of in chronological order beginning with the earliest unit of the virtual currency you purchased or acquired; that is, on a first in, first out (FIFO) basis.

</comment><comment><USER13> I think it's the decision to treat it as property (and not its scalability) that killed the use of crypto in the US as payment mechanism, and limited its use only to store of value, speculation, and illicit payments.

<comment><USER14> They were supposed to treat cryptocurrency as not property? How would that work?

<comment><USER15> Same as dollar. E.g. you are not taxed, if dollar aporeciates.

<comment><USER14> But that would put bitcoin above every other currency. As far as the United States is concerned, one dollar is one dollar and dollar is the unit of currency. Whether you own bitcoin, Mexican Pesos, Canadian dollars, etc, holding another currency as an American citizen means you are subject to appreciation of that currency when compared against the dollar, which is the unit of currency in which the IRS collects tax.

You are right you are not taxed (in nominal terms) if your dollar appreciates. That is because payment to the IRS is rendered in dollars, and dollars only. If your dollar increases, well so does the amount you lose when you give that dollar to the IRS.

<comment><USER13> Not above any foreign currency. Transactions below $200 would be exempt from capital gains. When they made that decision, the implication was that it cannot be used for liquid payments, i.e. be a "currency".

</comment></comment></comment></comment></comment><comment><USER16> So perhaps someone can help me here: When Keybase sent everyone with an account a bunch of Stellar Lumens did they gift everyone with an obligation to file more tax forms?

EDIT: To answer my own question, this FAQ states: "No. If you receive virtual currency as a bona fide gift, you will not recognize income until you sell, exchange, or otherwise dispose of that virtual currency."

Presumably I only have to worry about my lumens if I cash them out or pay someone with them.

</comment><comment><USER17> Without a legal definition of cryptocurrency ownership there is no way to interpret this guidance. I may assert that I own the private key which can transact on the Bitcoin blockchain but also assert that I do not own the exact same private key on the Shitcoin 1234 blockchain. A very crude and simple analogy would be like assuming people with the same bank pin are the same person.

<comment><USER18> The guidance does have a defintion of ownership: "Under § 61, all gains or undeniable accessions to wealth, clearly realized, over which a taxpayer has complete dominion, are included in gross income."

If you are the sole possessor of a private key which grants control of a cryptocurrency address then you have complete dominion over the crypto at that address. Under situation 2 of the guidance: "B has dominion and control of Crypto S at the time of the airdrop, when it is recorded on the distributed ledger, because B immediately has the ability to dispose of Crypto S."

Taken in the most taxpayer hostile interpretation that means that if the ledger is duplicated you have income because you have the ability to dispose of the forked coin with your private key even if you have no desire to touch it in any way.

<comment><USER17> This generates a lot of additional questions. What about a multisig situation? Can I have a buddy withhold a digital signature until I want to transact so that I did not own the crypto up until the transaction? Add in multiple jurisdictions of private key holders and things could get really interesting. Maybe it would be possible to pay no taxes at all! What about exchange coins where the person has no private keys and hence owns no crypto at all? Would they still have to pay taxes on crypto they clearly don't possess? What an absolute mess.

<comment><USER19> Lots of IRS regs are about the common case, not weird cases.

As an analogy: if I get paid by check on december 30th, and the check doesn't clear until january 2nd, is the income for the old year, or the new year? What if I hold onto the check, waiting for the new year? How about if I have the check, but I'm snowed in, and can't get to the bank? What if I can get to the bank on december 30th, but the bank is snowed in and closed?

(Answers: old year, old year, and then two don't knows)

</comment></comment></comment></comment><comment><USER20> The "airdrop" terminology is interesting to say the least.

The closest thing I can see to a definition is in 26 CFR 1.61-1:

> An airdrop is a means of distributing units of a cryptocurrency to the > distributed ledger addresses of multiple taxpayers. A hard fork followed by > an airdrop results in the distribution of units of the new cryptocurrency to > addresses containing the legacy cryptocurrency. However, a hard fork is not > always followed by an airdrop.

[https://www.irs.gov/pub/irs-drop/rr-19-24.pdf](https://www.irs.gov/pub/irs- drop/rr-19-24.pdf)

Consider the Bitcoin/Bitcoin Cash hard fork of 2017. No "distributed ledger addresses" received an airdrop distribution.

What happened instead is that the tokens previously valid on a single network (Bitcoin) became valid on a new network (Bitcoin Cash). There was no "distribution" and as such there was no airdrop according to the IRS definition.

On the first block of the Bitcoin Cash split, there was no "recording" of cryptocurrency receipt on the "distributed ledger." There was just a block containing some unrelated (for most users) Bitcoin Cash transactions.

Either the IRS doesn't understand the basis of a hard fork, or it's specifically singling out hard forks coupled to "airdrops" as having received income.

Likewise Situation 1, from the same document:

> Situation 1: A holds 50 units of Crypto M, a cryptocurrency. On Date 1, the > distributed ledger for Crypto M experiences a hard fork, resulting in the > creation of Crypto N. Crypto N is not airdropped or otherwise transferred to > an account owned or controlled by A.

> ...

> A did not receive units of the new cryptocurrency, Crypto N, from the hard > fork; therefore, A does not have an accession to wealth and does not have > gross income under § 61 as a result of the hard fork.

The use of the word "account" is also problematic, as it implies a custodial relationship with a financial institution, which has nothing to do with Bitcoin itself.

Filling in the blanks:

A holds 50 BTC. On Date 1, BTC experiences a hard fork, resulting in the creation of Bitcoin Cash. Bitcoin Cash is not airdropped or otherwise transferred to an account owned or controlled by A.

A did not receive units of the new cryptocurrency, Bitcoin Cash, from the hard fork; therefore A does not have an accession to wealth and does not have gross income under § 61 as a result of the hard fork.

Stay tuned because these rules are going to be refined - a lot.

<comment><USER21> I think I got a Stellar "air drop" through Keybase. I don't even want their fake money, but now I have to do extra paperwork to deal with it.

I am surprised that McDonalds can offer you 50 cents off a burger without having to file a 1099.

<comment><USER22> > I am surprised that McDonalds can offer you 50 cents off a burger without > having to file a 1099.

A discount is not income. If they gave you a $0.50 gift card though, that's taxable income, and they should collect a W-9, and file a 1099 if the total of annual amounts adds up to $600 or more; as a recipient, you're required to include it in your income regardless of if the originator filed a 1099 or not.

<comment><USER23> This guy taxes.

In seriousness, though, how do you build up this level of comfort/familiarity with the tax code? Did you do it professionally?

<comment><USER22> No professional experience. I'm intrigued by systems of rules with exceptions, and I have pretty good recall for random, mostly useless data. (It's a useful collection in aggregate). Some amount of motive to minimize taxation; the tldr there is if you wanted a super awesome charitable trust, open it in the 80s; and maybe try to figure out how to get startup stock into a Roth account before it's worth much, but this requires prescience to know it's worth the effort. I _think_ there are some brokerages that could offer enough flexibility to do it, but I only looked into it much too late.

I read bogleheads forums and tax questions are usually interesting to me. I don't like filing my tax returns without understanding why everything is where it is.

All that said, discounts aren't income comes up in the context of "why aren't cash back credit cards taxable, but account opening bonuses are" which also touches on 1099 rules because people complain about bank X issuing 1099s for all the bonuses, even when they aren't near the reporting limit. A quick search to verify that gift cards count as income (because they're considered cash equivalent) also reminded me of the name of the W-9 form.

</comment></comment></comment></comment></comment><comment><USER24> >A taxpayer generally realizes capital gain or loss on the sale or exchange of virtual currency that is a capital asset in the hands of the taxpayer.

What does this mean for crypto players that exchanged a lot of crypto, realized gains, then lost their wallet?

Are they still on the hook for taxes on the gains even though they can't access the wallet anymore?

<comment><USER25> How is that different then realizing gains for stock, converting it to cash, then losing the cash?

</comment></comment><comment><USER26> Here's a summary of the key updates in the new guidance in ELI5 terms: [https://www.cointracker.io/blog/new-irs-cryptocurrency- tax-g...](https://www.cointracker.io/blog/new-irs-cryptocurrency-tax-guidance)

</comment><comment><USER27> Why does anyone in tech still pretend there's any real value left in blockchain tech?

The crypto industry is stymied, time to move on and let "real" fintech take the reins...

</comment><comment><USER28> What does this mean if I have coins on an exchange when they fork and the exchange decides not to support the new coin? Is that theft?

<comment><USER29> This just addresses the tax consequences. Theft is something else.

The ruling is basically saying that if your exchange didn't support the fork, you didn't receive any crypto, so there's no taxable income.

But if your exchange did support the fork, you have taxable income once those crypto show up in your exchange account and you can transact with them.

<comment><USER30> Isn't it rather that you have taxable capital gains once you choose to transact those assets?

<comment><USER10> That might be a reasonable position to take: it would nicely avoid the issue that you might not know or be able to know about the fork, that the value at the instant of creation is exceptionally unclear, and it would nicely avoid the issue that you might not meaningfully have access to the coins.

The ruling appears to say nothing like that and nothing that would particularly support that interpretation.

</comment></comment></comment></comment><comment><USER31> Here's a breakdown on the most important info in the new guidance: [https://www.cryptotrader.tax/blog/new-irs-cryptocurrency- tax...](https://www.cryptotrader.tax/blog/new-irs-cryptocurrency-tax-guidance)

</comment><comment><USER32> Oh the same irs that is undefunded to persue billionaire tax avoidance but seems to be quite capable of attempting to tax all cryptocurrency use for us citizens.... yeah this seems like complete bullshit.

<comment> kube-system What makes you think billionaires aren't trying to use cryptocurrencies to their advantage?

</comment></comment><comment><USER33> So does this retroactively apply to existing assets? BCH?

</comment><comment><USER34> A huge day for digital assets. The big highlights for me are:

* fair date accounting for when you take custody of a private-key / access to a wallet holding an asset (air dropped, hard forked or traditionally acquired).

* specific identification is allowed for cost basis accounting! Not sure if this is new but this is a massive game changer for me.

</comment><comment><USER35> I have been suffering from (LUPUS) disease for the last 10 years and had constant pain, especially in my knees. During the first year,I had faith in God that i would be healed someday.This disease started circulate all over my body and i have been taking treatment from my doctor, few weeks ago i came on search on the internet if i could get any information concerning the prevention of this disease, on my search i saw a testimony of someone who has been healed from (LUPUS) by this Man Dr Abiolo and she also gave the email address of this man and advise we should contact him any sickness that he would be of help, so i wrote to Dr Abiolo telling him about my (LUPUS) he told me not to worry that i was going to be cured!! hmm i never believed it,, well after all the procedures and remedy given to me by this man few weeks later i started experiencing changes all over me as the DR assured me that i have cured,after some time i went to my doctor to confirmed if i have be finally healed behold it was TRUE, So friends my advise is if you have such sickness or any other at all you can email Dr Abiolo on (firstname.lastname@example.com) sir i am indeed grateful for the help i will forever recommend you to my friends!!! with your lovely Email Address( firstname.lastname@example.com) or you can also call him on this number +2347012232686Dr Abiolo also cure the following(1) EX BACK(2) HIV/AIDS (3) ALS / LUPUS DISEASE CURE (4) DICK ENLARGEMENT(5) HEPATITIS B(6) ALOPECIA(7) CANCER(8) DIABETES(9) HERPES CURE(10) CURE OF ANY KIND OF DISEASES (11) IMPOTENCE,(12) BARENESS/INFERTILITY(13) DIARRHE / H PYLORI CURE(14) ASTHMA(15) HPV CURE/HSV-1(16) FIBROID CURE....contact him now email email@example.com or WhatsApp +2347012232686... he is ever ready!!!

</comment><comment><USER36> tl;dr if you take possession of any 'new' crypto holdings after a hard fork you now have new tax liability !</comment>