yup, correct.
It becomes a discussion of trust (again).
Cloudflare is MITM. And yet they are here to protect websites (e.g. prevent DOS, and similiar).
I wanted to stay in the scope of the KRACK WiFi attack, so this would happen in your home environment or e.g. in public hotspots.

IMHO security is always a trade off - like how much do you need to invest to protect.
Small values (e.g. less than 100 Euros): you are ok with today's technology.
Values below 1000 Euros need some thoughts, and values above need proper investments in security (and even consulting, if unknown to you). There you want to talk about proper cold storage, but this exceeds certainly the scope of the discussion here - in this forum there are already exising threads.

Just wondering what is best answer to OP: KRACK and Bitcoin. For little values, I don't see immedeate action, as it requires high efforts to gain access.

When using a wallet (on desktop and iPhone), it's anyhow ok to use the wallet software. When using wallet via service provier or when doing trades, make sure Operating system is up to date, look for latest patches that include fix for this KRACK.

comments?

no, not really. In the past we have seen "heartbleed", and today tools like SSLstrip and MITMf allow to bypass SSL, by "downgrading" a connection to a standard HTTP session, then injecting JAVASCRIPT code etc ... and who is looking "all the time" to the green escrow in the top line of the browser?
I would like to add, that this is already a very sophisticated approach to hijack a connection. It certainly depends on "your value", if someone is ready to play with it. If you have less than 10 bitcoins, I'd be not in fear. But if you are "rich" and paranoid ...

based on the document here, it mainly drills down to update client software, and also the routers.
The traffic can be intercepted, and code could be injected.

Now to bitcoin: I have four use cases in mind, I describe below. Perhaps this can be worked out more and more by the audience :-)

using a full node:
===========
you can download up to latest block, "stay" offline, craft the tx, and sign it. Only when sending it, you can go online. If someone messes with your tx, then the signature and hashes will be invalid, and it will simply not be accepted by the network.

using an SPV wallet:
=============
It is difficult to create a tx offline. So you have to be online. I don't see, that electrum wallet would be affected, you'd have to inject code in the communication channel, to fetch tx and build them up locally. Don't know, which attack vector exists, to get "down" to the priv keys. Hoping to get more info from SPV wallet providers (same accounts for Bread and AirBitz).

using an online wallet:
==============
Here is a risk, i.e. if the software is just a "html" based wallet. Code could be injected. Any attack vector through "man-in-the-middle" is thinkable 

online trading:
=========
same as online wallets.

If you are paranoid, connect your PC with Ethernet cable to your router.

I'll answer based on the doc in Andreas' book "mastering bitcoin":

Each full node in the bitcoin network verifies every transaction against a long checklist of criteria. This can be time consuming, when a specially crafted tx is used. But usually tx are checked within milli seconds.

Mining nodes will also validate transactions, they are then added to the mempool, where transactions wait until they can be included into a block. The mining node will aggregate these transactions into a candidate block. The block becomes valid only if the miner succeeds in finding a solution to the proof-of-work algorithm. Usually a hardware mining rig is used to find a solution to the proof-of-work algorithm that makes the block valid. The proof of work is the intensive calculation step.
Once the candidate block is filled with transactions, the hash of this block's header is calculated, until the hash is less than a predefined target. At the current difficulty in the bitcoin network, miners have to try quadrillions of times before finding a nonce that results in a low enough block header hash.
And this is the calculation/computing power intensive step. Not validating transactions.

In the IBM article on

https://www.ibm.com/blogs/blockchain/2017/05/the-difference-between-bitcoin-and-blockchain-for-business/?social_post=1099763016&linkId=43090982

it says:


I was wondering if this statement is correct. Isn't every full node checking conformity to the rules of a transaction? And for the miners the ressource intensive thing is to then find the nonce?
What would the mempool be in this scenario?

How does this play with bitcoin priv keys?
I understand these principles, and the underlying math. Also read about ECDSA and points on the curve. This is what probably happens with open or libressl?
 $ openssl ecparam -genkey -name secp256k1 -rand /dev/urandom -out $PRIVATE_KEY

However: I read, that bitcoin priv keys are a random string of hex chars (2^64 Bytes), that can be generated by rolling dice. And eventually  converted to a hex representation (see e.g. here: http://www.swansontec.com/bitcoin-dice.html).

I think I am looking to match these two different approaches to the priv key. How do they "match"?
In your example what would the private key look like? The pub key is clear, would the priv key have some additional random chars (seed)?

After rereading his post, it comes to me that he might talk about the addresses he sees in a (HD) wallet. There you usually have one priv key, and a set of derived pubkeys.
Seeing that the post is from a fairly new member, giving him direction to bitcoin.org is surely the right way.

@blackhat988 - in short:
the addresses and wallets are effectivly representations of the data, so we as humans can easily grasp the idea and use case. A wallet is then a combination of only priv/pub keys. You need these keys to do transactions. Transactions have inputs and outputs, from which you can spend. The input usually came to you via a bitcoin address, that you once provided. The output is generated by your wallet software with the target address. When the transaction is confirmed, it is  saved in the blockchain.
And as Bob123 replied, each transaction detail can be seen, e.g. on blockchain.info, you can search for your address or your transaction number. This helps to clarify, along with bitcoin.org.

just another short update: as it is time to play with segwit, I have extended the tx analyzer (tcls_tx2txt.sh) with capabilities for SegWit. The decomposition would show now the details of any SegWit tx.
(as usual testcases are also included). 

similiar discussion here: https://bitcointalk.org/index.php?topic=2131710.0

this is correct, and I think the way to look at it is this: who can benefit from the Bitcoin system?
The community - aka the vast majority (e.g. running core nodes) definetly did not express their wish to use SegWit2x.

The miners would like to have SegWit2x. By this they are willing to take the vast majority of users as "hostage", to follow "their" will. This prevented already in the last 2 years the bring-in of SegWit, and with it the further development of the Bitcoin. Wether this was intentionally or accidentially, I don't want to judge.

The work of the miners is to stabilize the network, and get the incentive for it. As mining is more and more centralized, this is a super-vast minority, which from my point of view should not be in a position, to decide, what the super-super vast majority wants. I see, that many companies also signed the NYA. So what? This still doesn't make a majority.
There are more developpers listed on the bitcoin.org webpage (aka "core developpers"), then people/groups/companies in NYA.

I understand the community does not accept a minority giving direction against the way, the core developpers take.
And also I can see, that majority of SegWit2x people tend to think, that core devs are two or three names (Luke Jr, Greg Maxwell and Adam Beck). This is not the case, as I just showed with a look at bitcoin.org (there are hundreds of names). Looks like the SegWit2x group does not (want to) understand, that the concept of Bitcoin is a non-centralized system, where a single group or person is prevented from changing direction. There is no "king" or "government" in Bitcoin. With the current situation miners and NYA teams play the role of a government, and this contradicts the main principles of Bitcoin. 

same question here, answered in the same sense:

https://bitcoin.stackexchange.com/questions/59678/questions-about-bitcoin-transactions/59684#59684

try to avoid, it's only double work. The experts are in both areas  

it is not a problem, that people don't get it. But unnecessary to post it. 
And what is the reason, that people ask, how far "we" are from using this service also as upstrem? 
Can these people outline, what was their contribution?
Have they payed people to develop uplink software? Have they invested in hardware to create an uplink channel? Have they tried to reflect, what it needs, to get un uplink up and running? Have they even read the documentation and intention of this blockchain distribution channel?
The answer must be "no".

And yes, with a very little bit of imagination one could think about creatng a tx and bring it to a service like blockchain.info, which uploads to the blockchain. An SMS, a letter, a file, and other options come to mind.
Come on people, go beyond your barriers and limitations, and proof, that the complaints here are only preps for your next extension in the wonderful crypto world.

The wallet can be seen as a container for your private keys and the derived public keys, and this container has special locks to open it (seeds, passwords, ...). Once you opened it, you can create with the wallet software a bitcoin transaction, that confirms to the rules of he network, and the wallet has software to send a transaction into the network. Also it is able to request data from the network (with light wallets), or it stores the blockchain itself  on a local drive (full node).
So the wallet is a piece of software that makes it easy for the enduser, to communicate/participate in the network.

this page looks alot like https://bitcoincore.org/, and this one: I don't see it somehow protected or secured...
better double check to trust the information on this page.

I think there is some misunderstanding: there are no such things as "none" existing addresses. Once a tx has been accepted by a full node, it is valid :-)
Maybe you think about addresses, who have "no known owner with his privkey"? Or do you think about those tx which are non-spendable (cause the script was invalid, stupid, intentionally ...)
This has been discussed already here in the forum, and the point is, who can decide what is invalid, and what not. The idea of bringing back coins into the cycle is nice, to avoid scarcity, but the problems around it are not yet fully understood (maybe the ideas are not yet mature). Danny and Achow provided already a short view on this. 

yup, and Andreas' book is great!
There are lots of OpCodes not used, or their combinations creates transactions, which are not forwarded.
I think this is a protection of the network, to avoid loops in scripts and similiar. But the experts need to confirm.
When trying to play with scripts, there is lot of history here, maybe a bit longer ago, but search the forum (maybe the keywords like "OpCode" and "bitcoin contracts").
And when you have an idea, try it on testnet first, then go to live net. I had a lot of help here: http://bitcoin-script-debugger.visvirial.com/

p.s.:
found the reference here in the forum: https://bitcointalk.org/index.php?topic=1840303.0

I'd like to throw my 2 cents in:
generally tx are a serialization of bytes, which are constructed as explained for P2PKH here: https://bitcoin.org/en/developer-guide#p2pkh-script-validation
what helped me alot to go through was this: http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html
good pictures and nice tables to understand the layout of a tx (obviously no segwit )
and this blockchain analyzer displays very nicely (with segwit): http://srv1.yogh.io/
I then created some shel lscripts for for decoding (and more) at the OpenBSD/Unix/OSX shells, there: https://github.com/pebwindkraft/trx_cl_suite
It displays and explains OpCodes in a tx...

I have some concerns with this post: 
The post is "a bit pushy", also the question why noone is answering - so soon? What is the offer? It is unclear. And some "I have a big project in my mind, which I cannot tell you at this point in time" creates more doubts than questions on the reputation of the post.

Usually it is not recommend to download software/libraries from untrusted sources.
As such it is good to have the sources on github.
Compiled executables can have too many negative impacts, and we don't know yet, what it gives. We'd need a reference with checksums first, so this can be verified on some systems with users from the community, to raise level of trust.

That said, I like the sharing idea, I see it like steganography. Also it is similiar to the seeds we have in use. What makes your approach different from the existing solutions? What improves their security or handling? Can you elaborate a bit?

Maybe I am missing something in this logic, but yet it is just an opinion, and no proof:


For sure, when it is money, we trust a lot, in Bitcoin world we trust the mathematical rules, not a person. Not sure what the author means by "Bob has to trust Carol". The author should explain, what happens, when Carol plays wrong, and what are the lightning protections to prevent this. IMHO, this has nothing to do with HTLCs. If Bob feels that Carol is not playing honestly, he can close the channel immedeatly... before the HTLC time locks in. Also the author doesn't explain, why multisig addresses are "funky". The multisig addresses can be seen as simple checks, where two or more people must sign, to validate it - what is funky about this?

Can't make up my mind yet, having difficulties to follow the logic in this article. 
I hope some more enlighted people will explain 

thx, got it. And thanx for your patience, explaining twice to me.
I went through Andreas' book, which says:
...
But it doesn't mention this handshake or protocol. I might send him a note ...