The chance is 100%. As long as this system comes with a default keylogger, your personal data is insecure.
It must not be Microsoft who uses your data. Wouldn't make sense. But what about their armada of external consultants, or any other person, who could look into the data, when data is transferred over wires, or remote support, or, or, or ...

The whole thing about bitcoin is "BE YOUR OWN BANK". Would you trust a bank without any fences? If yes, go and use Windows, but don't wine around for lost or stolen bitcoins. Forums are full of this...

Summary: one cannot accuse Microsoft to actually steal "your" data, but the numerous occasions of data theft and lost privacy makes Windows a product, that cannot be recommended "out of the box" in security relevant environments. You need to invest many many hours, to get it to a level, where it can be considered "secure enough". You can save these many many hours by using a  BSD/UNIX based OS, paranoia is your/the limit :-).

I read in the posts here an underlying assumption, that bitcoin was developed to make it possible for unlimited coffees be timestamped on a blockchain. I think this was never the goal, and doesn't even make sense. So the use cases for technical or "non tech savvy" people might vary. My point of view is, that "non tech savvy" people should have at least an understanding of what they use ("a bitcoin wallet in a bitcoin universe"). This is fairly easy to use, but has it's limitations. You don't need to understand the underlying technology, but you should know, what game you are playing. One cannot expect to use bitcoin, and have same conditions as FIAT money. This would be dumb.

I do not understand fully the logic of bitcoinfees site. I would go this route:

- I buy a coffee with bitcoin, then I don't care too much on the fees, and send a std tx with one Satoshi per byte, at 4000 US$ a Satoshi is 0.00004 US$. Multiplied with the length of the tx (~300 Bytes) one would get 0.012 US$, or 1.2 cents.

- alternativly, if there is s.th. of low value, that I repeatedly order, I would use lightning. Then I have an "open channel" tx: this is not time critical, as it is done only once (maybe even two or three channels) - so I could open a channel with s.th. between 10 and 50 Satoshi/Byte.

- I buy something valuable in the range of 1000 US $. I want to make sure tx goes through within half a day, cause delivery is usually next day. Half a day is ~72 blocks, so I look into actual statistics of my full node (or https://jochen-hoenicke.de/), and I see there are several "low" level peaks per hour, and all is "fairly blue" - so I choose 10 Satoshi/Byte.

- I want to do some regular trading or exchange of amounts, therefor I transfer Satoshis/BTCs into a side channel. I open a transaction (similiar to the lightning) for a single time, and from there I'm on a different channel, and fees on bitcoin blockchain get less relevant...

As answered by ETFbitcoin, there are still "annoying weakness" (*like*), yes, I think this is true. All is still new, and as you state, probably not that easy to use, especially when going to side chains. It is hard to say, when maturity is achieved.

So yes, "for non tech savvies", maybe not the immedeate solution. For these people there is BCH (or ABC or unlimited or whatever it is now). And one shouldn't forget Ethereum, which also allows for "higher throughput" (aka tx per block per hour).

Oh, yes, both off-chain solutions are implemented. For sure there is a whitepaper for lightning (http://lightning.network/docs/), and lots of links on the net (and here in the forum). To start your own lightning node: https://medium.com/@dougvk/run-your-own-mainnet-lightning-node-2d2eab628a8b. Also interesting the graphs: https://rompert.com/recksplorer/

On the liquid side chain: https://blockstream.com/2018/10/10/liquid-launch/

I'd like to add two small things:

• Lightning is having more than 300 Bitcoins in it's channels, so just to give an imagination, what can happen in volume and size off-chain.
• And then there is already the first sidechain ("Liquid"), another on/off chain layer (requires a in and out transaction on the blockchain), which allows for additional transactions outside of the bitcoin main blockchain.

So scaling bitcoin isn't a point of discussion anymore (only for those people, who want to make sure, that the coffee they paid for a dollar is forever visible in a blockchain - for tose people it is better to use bitcoin unlimited, abc or cash chains).

you're the man! 

@amaclin: if the tests for standardness on testnet are not implemented, why is the error "mandatory-script-verify-flag-failed" happening? Am I missing s.th.?

Looking at TX_OUT[0] pk_script:
01022103341B4D862E7E1C3D7FE7D0ADE7E97DFAC122760B1EF4FFB21B7A9A27DD525B6C2102EE1 C79ACEE56F0E2CAFCC1069A6E1E1E9D059FF9A60B60904E97A455D5B27F672102839D639C109F09 0104EAB7C3EEF07D6BF25952A5A88C65BC5B185F0EA2A3FAF20103AE

    01: Push next byte as data onto stack
        02 (2-of-x multisig?)
    21: OP_Data33
        03341B4D862E7E1C:3D7FE7D0ADE7E97D
        FAC122760B1EF4FF:B21B7A9A27DD525B
        6C
    21: OP_Data33
        02EE1C79ACEE56F0:E2CAFCC1069A6E1E
        1E9D059FF9A60B60:904E97A455D5B27F
        67
    21: OP_Data33
        02839D639C109F09:0104EAB7C3EEF07D
        6BF25952A5A88C65:BC5B185F0EA2A3FA
        F2
    01: Push next byte as data onto stack
        03 (2-of-3 multisig)
    AE: OP_CHECKMULTISIG

pk1=mqBRdBj2aen8aM3t8vtuSdiQLh2kSDZZfc
pk2=mwyjowbdKK9QHK6nGHTS8HoNEsULxCbNce
pk3=mqxmeXoLf3ANX6fY1epLZEHcnNvr1rYPMA

So if pgmforever assembles his tx with two priv keys of the mentioned pubkeys (the sequence of sigs must be same as the pubkeys), it should be ok? I had the impression, it fails with the mentioned error. 

@pgmforever: maybe we can see the spending tx?
It should be good to go on regtest network as well...

There are 2 links relevant to DER encoding, which helped me to get along:

https://bitcoin.stackexchange.com/questions/41525/regular-expressions-for-der-signature-hex-also-req-address-txids

https://bitcoin.stackexchange.com/questions/12554/why-the-signature-is-always-65-13232-bytes-long?rq=1

are you on testnet or regtest? I'd be interested to see the example, I have from time to time similiar "experience"...
It is clear, that bitcoin demands for the shortest representation of data. So you have to use (from the wiki https://en.bitcoin.it/wiki/Script):

0x01-0x4b   (special) ... The next opcode bytes is data to be pushed onto the stack

for data, which has less than 75 OpCodes.
I'd just like to play with the examples on regtest ...

Same request and further details here:

https://bitcoin.stackexchange.com/questions/80487/how-are-blocks-verified

I receive the same result, when I provide the plain string to openssl;


what I try to say is perhaps better described here (it is on sha256, but also applies to ripemd160):

https://bitcoin.stackexchange.com/questions/43347/how-to-generate-bitcoin-address

yes, the string of your raw transaction is a textual representation of the hex chars. Correct.

I am not sure, what bittcoin did here, it seems that bitcoin client just refused the logic of the script... I was asking how (which library, or manually) you used to assemble the tx... with the bitcoin client?

I try :-)
Bitcoin does not work with hashed strings, instead these are hex values. So I convert string first into the hex values into a file, to be used as input for the hash function. In a simple shell script (POSIX compliant) I do this:



Interestingly enough I get a different result when doing ripemd160 on the string:


Now I'm puzzled, what values are delivered on these web pages... needs some further review.

when I understand the intention of your script correctly, then you try to push a value onto stack, convert it with ripemd160, and do the equal_verify to .
Observation:


Looking at the code:

The EqualVerify tries to compare the result from the ripemd160() to 388756dc... - and fails. A view to the stack:

There are three data pushes (1, c47907ab..., 1), followed by an OP_IF, which "eats" the top element (the "1") as true. So execution goes into first part of the if-clause (the comparison with equalverify).
The top element on stack will then be the c47907ab..., which will be ripemd'd, and pushed again onto the top of stack. The result of ripemd160(c47907ab...) is 940a74dcade2bdb9385c293f30db6640f3ca22dd. With OP_EqualVerify, the stack looks like this:

OP_EQUALVERIFY
388756dc41f4eeadcb3fc5064535d1121a49d3f4
940a74dcade2bdb9385c293f30db6640f3ca22dd
1

Clearly those two values don't match (if my logic is correct). I don't know what input to the function ripemd160() matches with the string "388756dc41f4eeadcb3fc5064535d1121a49d3f4" - if I knew, I wouldn't reply here :-)

Observation: the ripemd160 result of "1" equals to c47907abd2a80492ca9388b05c0e382518ff3960, so if you try "1 1 OP_IF OP_RIPEMD160 c47907abd2a80492ca9388b05c0e382518ff3960 OP_EQUALVERIFY ..." this might work.

btw: what tool do you use to assemble and then sign your tx?

no, I don't. BIP173 and this link is all I have for now...

when someone sends me some [sh|b]itcoins, I might do a picture 

whereas Andrew has provided an extensive answer, I thought I'd add two and a half more things.
I had this confusion with keys in hex and WIF, and then how to come to bitcoin addresses. So I made a small picture, which
I posted on a thread in bitcoin.SE.

Without BECH32, this link http://gobittest.appspot.com/Address shows how to come from priv key to a bitcoin address.
More on addresses here and here.

I had spent some time with Bitcoin Core 0.16 in offline mode, and didn't get to succeed for different reasons. When looking into cold storage and Bitcoin Core, majority seems to talk about keys being offline. So far so good. When it comes to signing a transaction, that seems to be another issue. I stepped over this thread with a remarkable comment from Pieter:

https://bitcoin.stackexchange.com/questions/50924/new-bitcoin-core-0-13-2-as-cold-storage-wallet

I have meanwhile tried to creat a tx on an online system, transfer it to the cold storage system, and get it signed. I started easy, with a simple P2PKH transaction. When I brought this to the cold storage to sign with bitcoin 0.16.1, the bitcoin-cli signrawtransaction command would reply with missing link to previous transaction:


when I tried to provide it additional info, I had the same result:


I was wondering, how the system would check the details. As I am no C/C++ dev, I am not too eager to look into the code... But obviously the client verifies contents, to make sure only "valid" transactions go to the network. This is good user protection, and probably very positive.

I also did some tests with (non-multisig) P2SH and redeemscripts. I created a funding transaction on the live system, and wanted to spend the P2SH. So I had to sign on the cold storage system. Results are also unsuccessful. I tried:


This INVALID OP_IF error happened to several versions of the created raw transactions and redeemscripts. It seems that bitcoind doesn't have enough info to add the signatures. This doesn't necessarily mean, the tx is invalid (one could manually add the sigs from a different program  ). As shown here, I can make a P2SH successful going through (just a hash comparison, without signatures):

https://bitcoin.stackexchange.com/questions/74753/htlc-hash-time-lock-contract-using-bitcoin-qt/74953#74953

From my experience, signing transactions offline with Bitcoin Core is not best way to go. And by this I don't mean to blame the core dev - au contraire! The design seems to go into user protection, and not fulfill dev's ("my") requirements.

I see this input script:

4C is OP_PUSHDATA, saying next byte is # of bytes that go onto stack. Next byte is 14, which is decimal 20 bytes on stack... you say you want to push DATA1 (520 bytes) on stack?
520 bytes is hex 0x208, so maybe you want to say PUSHDATA 0x208 <520 bytes>?

And: "Data push larger than necessary" indicates a situation, where you use 2 opcodes, whereas a single one would be fully sufficient. Hence when pushing 20 bytes (hex 14) to stack, a single command "0x14" is sufficient (https://en.bitcoin.it/wiki/Script).

From another thread, I copied this comment into one of my scripts:
# 1.) OP_PUSHDATA1 and even OP_PUSHDATA2 are allowed inside P2SH scripts fine.
# However, there is another policy in Bitcoin Core to require that all pushes
# are minimal in standard transactions. That means you can only use
# OP_PUSHDATA1 when a direct push is not possible (up to 75 bytes), and only
# use OP_PUSHDATA2 when an OP_PUSHDATA1 is not possible (up to 255 bytes).

base58 handling at the shell level:

https://github.com/grondilu/bitcoin-bash-tools/blob/master/bitcoin.sh

grondilu rocks!

an indirect answer:
I have quickly double checked your data with some of my scripts. The replacement of the transaction and the created double hash value seems to be correct. I am not understanding the pubkey you use in the function main().

When I am using the pubkey of the pubkey script you extracted (of course without the length field and without hex "ac" at the end), then it runs ok.

######################################################################
using the reference from here: http://bitcoin.stackexchange.com/questions/46455/ I get this result:  

pubkey in HEX: 04b0bd634234abbb1ba1e986e884185c61cf43e001f9137f23c2c409273eb16e6537a576782eba6 68a7ef8bd3b3cfb1edb7117ab65129b8a2e681f3c1e0908ef7b
pubkey in PEM format:
-----BEGIN PUBLIC KEY-----
MFYwEAYHKoZIzj0CAQYFK4EEAAoDQgAEsL1jQjSruxuh6YbohBhcYc9D4AH5E38j
wsQJJz6xbmU3pXZ4Lrpmin74vTs8+x7bcRerZRKbii5oHzweCQjvew==
-----END PUBLIC KEY-----

sha256: f27c6c3aa42563c958292922be1e53fe107f4db0dfadba11122f0b12bf77f3ab

ScriptSig:     3044022014d647cd08f1ea5b31d1e6539b6cbceb9182f6e7b2e29fb969354ef7e3434923022028b b4eda36af410149baa936322e7c0e46cc5540a3aa89c811bc3c360028bfd3

*** Signature Verified Successfully ***  

in English:
https://nano.org/en
in French:
https://courscryptomonnaies.com/nano

A DAG based system, which replaces the TANGLE from IOTA with a system called "block lattice".
This is how far I could get from a quick look, just reading 

As d5000 layed out, the double-spend problem is not really solved (and PoS system based is centralized, aka against the idea of Bitcoin), I would see this more related to IOT and similiar, than for "Bitcoin replacement".
probably s.th. which belongs into the altcoin section.

Edit: there is a PoW component: "Unlike Bitcoin, the PoW in Nano is simply used as an anti-spam tool, similar to Hashcash".
Whitepaper is here: https://nano.org/en/whitepaper

Edit2: and the technical discussion is here: https://bitcointalk.org/index.php?topic=1219264.0

Here are two sources, which show how blocks are assembled and then verified:

https://en.bitcoin.it/wiki/Protocol_documentation#Differential_encoding

https://en.bitcoin.it/wiki/Protocol_rules#Block_creation_fee

As you say, the block size could be larger, which data structure do you think of?
Based on the specs it must be a transaction, and if it doesn’t fit the rules on the page mentioned (see rules for blocks and the rules for tx), then there would be invalid data of a supposed transaction, making the block invalid...