... But by all means, continue to be completely obstinate, don't learn anything, use Option 1 and keep telling us that Lightning is a bad idea.
Yes, but tomorrow all people on the planet will open a network channel at the same time, the fees will go through the roof, up to 10000 US dollars, making only the banksters rich, and the centralized servers cannot manage the volume, because the banking hubs have a connection problem with the blockchain, and this can change the values of the FIAT world, and, and, and... people like to throw shells to predict the future, with any type of assumptions in their limited understanding. @DooMAD: This whole gibberish is exactly the tone and voice of Anti-Cen and dinofelis. Even the low level newbies here in the forum can make a text comparison on the posts, and understand that there is the same incentive, just under different names. Don‘t loose your time :-)
|
|
|
... As to the nature of your question, there is MONERO ( which claims to be secure ), and there is the z-cash coin family which have z-obfuscated addressses to backup the public address scheme, the thing with MONERO is its choice of ECDSA is known to be weak and have a back-door, while MONERO may be 'secure', its not secure from the ppl you should fear ( NSA wrote the ecdsa curves for monero ), like NSA wrote Secp256k1 for btc, like NSA wrote sha-256 for btc, ...
These are quite blunt statements without any reference to its origin. Also it is posted by a new member in the forum, where it is difficult to understand his level of reputation. Looking at his others post, there is no single reference, rude wording, and "look it up yourself". So credibility is low, very low. I am wondering why @Danny Hamilton gave it some merits (probably to start a discussion on it, maybe I did not understand his merit policy correctly). secp256k1I skimmed through some older posts, which talk about security of secp256 k1, and it is not recognizable, that NSA wrote the curves for bitcoin. The NIST recommends usage of secp256 r1 (see the " r" for random), and NIST provides recommendations to NSA. The randomness is the factor, where people think, it is not "random" enough and includes the backdoor (implemented by the NSA). It looks like the " k1" curve has been chosen, becuase it was known, that " r1" is used by NSA. This is quite a complex theme, and these two links might provide more inside view: https://bitcointalk.org/index.php?topic=937058.0https://bitcointalk.org/index.php?topic=151120.0https://bitcointalk.org/?topic=2699.0From what I can read (or even understand), secp256k1 was used for performance reasons, knowing it will loose a bit of security. SHA256There is this thread ( https://bitcointalk.org/index.php?topic=2680267.0), which is also full of statements, but without any proof or link. Already the OP choose a name, which make the content doubtful, and the headline doesn't count at all for scientific proofs. It is good to start a discussion, but luckily this post remained unanswered. This thread ( https://bitcointalk.org/index.php?topic=288545.0) has many links to SHA256 and NSA, but it doesn't become obvious, if there is a backdoor or not. It also looks more like speculation. And then one can search vor NSA [secp256k1|sha256|ripemd|ECC|ECDSA] in the forum, just to find an overwhelmingly amount of non scientific comments and speculation. This doesn't withstand scientific proofs. So I can sit more or less comfortably back, happy to know that at current point in time bitcoin is fairly secure, for the following 3 reasons: 1.) to break bitcoin, you need to crack sha256 and ripemed and ECDSA - if NSA had only one of them broken, bitcoin would be the smallest problem 2.) there is only speculation by newbies with low reputation, that NSA has hacked things. Good for bollywood movies and entertainment (and newbies), but doesn't reflect reality. 3.) Maybe there will be no mathematical proof, "only" empirical proof. A bitcoin blockchain with values in the billion dollar range gives me more trust than any centralized system that we are dependant on nowadays. It is based on hashing and signing algos, which are publicly verifiable. And you can't do this with organizations in the FIAT world...
|
|
|
Are there any 3rd party APIs to find out who and how much has been paying a given address?
This data isn't anonymous in the blockchain ...
I need to step in here, cause I fear another discussion on loosing my privacy I look into it from the perspective of help organizations (ONGs). In FIAT world, they usually get funds by foreign countries to their bank accounts. And in the country of operation, they meet conflicting goals. Some governance have then frozen their banking accounts. And I can't stress is importantly enough: THIS IS NOT A PROBLEM OF SMALL THIRD WORLD COUNTRIES! IT HAPPENS ALSO IN THE NORTHERN HEMISPHERE... It is not the always repeated "tax avoiding" issue. So, when you say "who", it's a question of defining what do you mean by "who"? Looking at block explorers (e.g. blockchain.info), they do exactly this, when it comes to bitcoin addresses and values. Even dates. So the "who" can be address x payed y bitcoins to address z at a specific date. This is anonymous data in the blockchain, and becomes pseudo anonymous, when it comes to real people. Chainanalysis has already been mentioned... To avoid that people can link information between me as a person and a used bitcoin address, the concept of "single address usage" must be followed. Then all these analyzers don't make sense. They will work with probabilities, but still there's a lot to go... Personally it would be even better, to use mixers and different exchanges. When is mimble-wimble finally introduced into the bitcoin eco system?
|
|
|
I meant to understand, that AI systems need to be trained for a long time, before they can "grasp" the idea behind an object. Example: take a cup of coffee. Human beings are able to grasp this object and it's function after two or three visual observations. AI systems need to be trained with 2000 pictures of coffee cups, and then they can decide, if it is a cup of coffee or something else. In the underlyings of this "intelligence" is simply a very fast comparison engine, able to handle huge databases. I would even say this is a matching machine. Like partnership matching machines. In principle they "learn", how to sort their pictures efficiently. These systems are reactive, and not (yet) self deciding. Intelligence is an expression, which is based on experience, and capability to make decisions for the future on it. Every human being (well, nearly) is doing this automatically, at more or less complex levels. An AI system, if you didn't tell it (train it), how to use the cup of coffee, will never ever understand what a cup of coffee is. AI is promising since +25 years solutions, but til today hasn't advanced very much, besides gaining speed in CPU power, machine's ressource optimization, and extremly fast sort/recover algorythms (basically "if-then"s). I know that I just became a target (or victim) for all AI fans, cause I'm pessimistic on promises of AI I understand that AI is a substream of IT technology, and necessary, cause it provides additional path of managing huge data. But it is not a promise of "intelligence". So my pessimistic view is against the "intelligence" usage and understanding in this buzz word. Increadible would be a much nicer word, cause the calculations done by these machines, and the algos are really fascinating. Obviously increadible isn't a good marketing word... So (my personal) summary: The really big advantage is the speed, at which the systems work, once they have been trained to sort the data correctly. And the second advantage is, that you can use all marketing language driving cars, neuronal networks, system learning, deep learning, ...), to sell it to the customers The promises of intelligence are yet to be delivered. To come back to bitcoin: Imagine, equivalent of 2-3 cups for human beings to understand the blockchain. And AI systems times 1000... What is the current size of the blockchain? OP seems to be correct, to put Sci-fi in the headline...
|
|
|
... There are no "banks" charging "interest" for "keeping BTC in the ledger". Most people would struggle to fit that much wrongness into a single sentence. If you genuinely want to gain an understanding of how fees and revocation in LN work (but I'm starting to suspect there's nothing genuine about your posts at all), there are plenty of resources available.
You seem to have your fun in responding to the fud. I was always wondering, why lightning nodes should be banksters and centralization (cause they take fees! Chorus of outrage), where miners are not. The ideology of these people is hard to be discussed at a non emotional level, and always has some Monthy Python elements. I stopped to argue with fundamentalistic people. They appear to be too many levels below scientific levels. And in these discussions they pull you down to their level of (non-)understanding, and beat you there with experience. Waste of time?
|
|
|
...
The problem is that, we already know how often the system will only be used and our targeted users, and it's nowhere near the numbers in the case of bitcoins(or any other cryptocurrencies).
In such a small scale application, would a single miner be able to verify those transactions. And if we are the only miners, but everyone of course gets to be a full node, would it still be called decentralized?
We're hoping that it would still be a system wherein users doesn't need to trust us, or anybody for that matter, they just have to trust the system.
In a small system, you can have a single miner. However: You can hardly call a system decentralized, when there is one miner, or miner instance in control of creating the blockchain. Just as a thought experiment (I like the idea of blockchain without miners): is the requirement for Byzantine fault tolerance given in your system? At the same level as in bitcoin? Is the only way to prove correctness of transaction and arranging in a block by proof of work? Could you think about other options to come to a blockchain? Just „thinking out,loud“: could you use a POS system? or a IOTA like confirmation process, where each participant needs to do some work? To avoid spam mails, the idea was used in the very beginning. Not sure, how far you are in your project, and if such changes would be meaningful...
|
|
|
... Addresses technically don't exist in the bitcoin network. Its just a form of representation in an (accepted) human-readable format.
Which is technically correct. The tx leave only hashes and pubkeys in the blockchain. Not addresses. But: the pubkeys can easily be hashed, checksum’d and base58check encoded, to finally have the same thing as the addresses in the wallets. so there is no big distinction between what is in the blockchain, and what is in the wallet. This holds true for P2SH as well. When forensic analysis is done, what does it matter, if you use the hash, the pubkey or the address.you don‘t even need the addresses, and could work through the tx and create a picture of their relationship(s). To see how bitcoins are assigned from pubkey to pubkey or hash to hash. Essentially it will be the same as saying „address to address“. Hence I see the need for anonymization or programs/extensions to provide more privacy.
|
|
|
You have not taken the time to read the white paper and you are free to call lightning hubs what ever you like but they charge both transaction fees and interest on BTC loaned out and the rest of the world tends to call these "Banks"
yadda, yadda, yadda - we already had other people posting about "banks" in exactly the same constructed,weird messages. At the end they somehow disappeared for good reasons. Fundamentalistic behaviour in a religious manner - waste of time...
|
|
|
...
I would not ever use existing source codes. Open source is tempting easy way to build something fast. However I always consider simple rule of thumb "If something is literally money-printing press, why it is free?" Even though I might not know what is wrong with the source, I don't want to waste time and money to find out. It can be anything from inability to handle loads to poor algorithmic or backdoors injected into it. I simply don't want to find out.
Thinking about what you just say here: without open source the bitcoin ecosystem wouldn’t even exist. „Why is it free“ - because it can! The egocentric, capitalistic, „free markets“ economic theories have all a poor and very limited understanding of (intrinsic or altruistic) reality. Open source brought so much to this world, that you would think, without it we would still live in caves. The second part is way better: when handling money, you need to look into the code you‘ll be using. Rigorous testing is required, and a sound understanding, on how you want to secure your users money. Putting yourself in a position of a customer, who gives money to an exchange, you want to be assured, that you deal with experts, and not newbies. So open source can be a way to go, but must not. And it is not an assurance of well functioning code per se. But: anyone can help to make it - bitcoin is dealing with values in the billion Euros, and has proofed to be very, very stable against all sorts of attacks, even those trying to steal the name.
|
|
|
kind of a puzzle game. There is not enough addresses, to see from where to where the funds were send. I get, that EXODUS WALLET address is 1AEdg6CnwG2xrZCuEx6BVMJtDUYTpP2t6u. That is the target address, that never received the funds. So useless to search in this direction.
Obviously the problem comes from the Core wallet. When you want to spent from your core wallet, it generates a double spend. This would mean, that funds from addresses in the core wallet have already been used in a previous transaction.
You say - you have updated your wallet - is it completly sync'd now? And what does it say - how much funds it has? - the coins "left my Bitcoin Core wallet" - how do you know? What are the evidences? (use the command line with "getbalance", "getaddressesbyaccount", "getreceivedbyaccount", "getreceivedbyaddress" and similiar) - this is a bit manual work... I think best is to find the used addresses in your core wallet, and verify their status on blockchain.info or bitaps.com.
Is "17qTnk8CaFRMYsidhFiDsgsi24acKD4NDr" one of your addresses?
And just some questions come to my mind, which may define future research (if you don't know, no prob):
- have you assembled a tx yourself, or did you use only the wallet software? - have you re-used address many times? - have you tried to create private keys and load them into the wallet? - are you sure you didn't send to BCash addresses? - which OS are you using?
@BitMaxz: I think the OP states, that his transaction conflicts with one, that has already 28555 (or 6451) confirmations. But we don't see the tx IDs here ...
|
|
|
... infrastructure apps like AD/Exchange and the blockchain. So if you have a 50,000 user org that requires 50 Exchange servers and 400 TB's of disk for mailbox storage, you can reduce that drastically by somehow utilizing the blockchain...
I doubt that a blockchain is a good storage system. The blockchain is good for decentralized, censorship resistant distributed systems using very little data (see the blocksize discussions, not only in bitcoin). Off topic (from crypto space): Microsoft also understood, that AD is not future proof anymore. It became to complicated to manage (aka too expensive in the companies). And the problem with huge exchange servers and disks stems from the fact, that an email to a group is replicated n times - it doesn’t scale very well. I remember when Lotus Notes had placed links to the attachment in each users profile, and as such a 5Meg attachment was only stored once on the mail server, instead of a thousand times. There are many discussions about data de-duplication. Hash values play an important role. This concept also adopts to backup systems... Now on use cases: initially the blockchain was intended to spend money over the Internet. It became a successful ecosystem, with notary services and last recently crypto kitties game. So there is a certain flexibility to allow for new use cases, and I encourage you to go into the next steps. We are just at the beginning of a new data age. On distributed storage: there is Siacoin and storj as concepts, trying to build the basis for future crypto storage systems. Maybe this is an approach for your thoughts?
|
|
|
You start to sound like AntiCen and dinofelis. Both have had these types of problems with not understanding Lightning, spreading FUD, and have been censored already. Look, just because you have limitations in understanding Lightning,you don’t need to warn others with these constructed (unproved!!!) statements. Show us your Lightning test setup, and the test driven results, which drive your statements. In a way, so we can repeat them, and get inside view of your understanding. I bet you haven’t any setup, and work on a purely theoretical level... It is perfectly ok to stay suspicious, but your predictions and comparisons only make sense in your ideological world. If you have never heard someone stating these misconceptions, this further proofs, that your egocentric picture of the world doesn’t reflect reality. Bitcoin supports only 600k tx/day? Proof it! I am convinced, you will quickly find the error in your very bold message! Looking at the FUD already spreaded, I start to think that next level of FUD will be banking hubs..
|
|
|
ahh, now I can see - the R-Value ("sigR": "16c48a8072e0ac51c2d111eb194f009caef0332446c1bf2097316cf07fa9ffffffff") is part of the tx input section. Directly after the signature itself. Specifically it "runs" into the pubkey, it starts at position 8 and runs until "ffffffff", which is the sequence number: 22: OP_Data(0x01-0x4b): 34 byte(s) to be pushed to the stack 002065D4 --> 16C48A80 72E0AC51C2D111EB 194F009CAEF03324 46C1BF2097316CF0 7FA9 TX_IN[0] Sequence: FFFFFFFF Some counters seem to go wrong. I guess the logic expects sequence number directly after signature (4 bytes of "ff"), but doesn't find it, and runs through the hex data until he got sequence. The sigR would then be displayed everytime, when the tx re-uses the address (and its pub key), which is in itself a bad attitude. maybe drop a message to Sean-Bradley's 2coin.org site?
|
|
|
also I am looking at 2coin.org, but can not see all witness data: "vin": [ { "txid": "880c7b67bfb6d70edaa74292edcd1b3585b91890762eafe123799f6d6599a1eb", "vout": 1, "scriptSig": { "asm": "002065d416c48a8072e0ac51c2d111eb194f009caef0332446c1bf2097316cf07fa9", "hex": "22002065d416c48a8072e0ac51c2d111eb194f009caef0332446c1bf2097316cf07fa9" }, "sequence": 4294967295, "n": 0, "addr": "3422VtS7UtCvXYxoXMVp6eZupR252z85oC", "valueSat": 112485041, "value": 1.12485041, "doubleSpentTxID": null, "sigR": "16c48a8072e0ac51c2d111eb194f009caef0332446c1bf2097316cf07fa9ffffffff", "sigS": "", "sigZ": "7f9dad303b47a86e29a4e362b0e9aaa878ce708c41fe451401fda8e5d6a33800" } ] Just wondering if things are not yet fully (segwit-) developed? I do not understand were the sigR value comes from. Do you have more examples?
|
|
|
Looking at the tx, and decoding, it is a segwit transaction, having several segwit data at the end: VERSION 01000000 SEGWIT (BIP141): this is a segwit tx, marker=00 (BIP141): flag=01 TX_IN COUNT [var_int]: hex=01, decimal=1 TX_IN[0] OutPoint hash: 880C7B67BFB6D70EDAA74292EDCD1B3585B91890762EAFE123799F6D6599A1EB TX_IN[0] OutPoint index: hex=01000000, reversed=00000001, decimal=1 TX_IN[0] Script Length: hex=23, decimal=35 TX_IN[0] Script Sig (uchar[]) 22002065D416C48A8072E0AC51C2D111EB194F009CAEF0332446C1BF2097316CF07FA9 ### decode SIG_script OPCODES 22: OP_Data(0x01-0x4b): 34 byte(s) to be pushed to the stack 002065D416C48A80:72E0AC51C2D111EB 194F009CAEF03324:46C1BF2097316CF0 7FA9 TX_IN[0] Sequence: FFFFFFFF TX_OUT COUNT, hex=03, decimal=3 TX_OUT[0] Value: hex=D013270000000000, dec=2560976, bitcoin=0.02560976 TX_OUT[0] PK_Script Length: hex=17, dec=23 TX_OUT[0] pk_script: A9148C6C69AC0FECCA4925CA2E0B5EE7EE69F590096A87 This is a P2SH script, and translates base58 encoded into this bitcoin address: 3EVWQ3yfCuotskvbWGY33UJwZtyuLohn4D TX_OUT[1] TX_OUT[1] Value: hex=BCBB5B0000000000, dec=6011836, bitcoin=0.06011836 TX_OUT[1] PK_Script Length: hex=19, dec=25 TX_OUT[1] pk_script: 76A91499BC1C4D87B84CC6AEF493799E0DFFF49F259C8788AC This is a P2PKH script, and translates base58 encoded into this bitcoin address: 1F1sjW3ZM3mvoBJzZFQntiV2BhF3wmTSfL TX_OUT[2] TX_OUT[2] Value: hex=018D310600000000, dec=103910657, bitcoin=1.03910657 TX_OUT[2] PK_Script Length: hex=17, dec=23 TX_OUT[2] pk_script: A9141988A27E3C2DF4DDEE7FAD5A2303D086179B2A3087 This is a P2SH script, and translates base58 encoded into this bitcoin address: 3422VtS7UtCvXYxoXMVp6eZupR252z85oC WITNESS TXIN[0] stack elements: hex=04, decimal=4 WITNESS[0] data length, hex=00, decimal=0, data(uchar[]): - missing ? - WITNESS[1] data length, hex=48, decimal=72: 304502210092263215EE8790FB10911CE34530BDE179EDF60176C6E1A6591629D36C8C1E9C022059577755C935B4A7C6A63F12D293B1018600F9A464F7AEAEF67D492A08AED9F501 WITNESS[2] data length, hex=48, decimal=72: 3045022100C357C4DD36AA24D3AB2FBEEFA3730C9D5C9441D7171B72286481F0138744A091022056A7C5E3176A9A09432B959BA0DFFD8941FC6D6655CDC91508A0E1D2DAAD4BF501 WITNESS[3] data length, hex=69, decimal=105: 522102F44ABCF9E23C9A460DA309CCCA56C619C04EED3BDE2C2CFF5E7D78FBCD980B9C2103C9443CF3047BB6C2C82F1B0C44C36109CDC3D0D601D16D1189A1602BF8D1A0A02103BFE867059274412412E088AF5572B92168C2EF495CFE6C9B7A753A009EB37C4853AE LOCK_TIME 00000000 Looking at the witness scripts, Witness[1]: 30: OP_SEQUENCE_0x30: type tag indicating SEQUENCE, begin sigscript 45: OP_LENGTH_0x45: length of R + S 02: OP_INT_0x02: type tag INTEGER indicating length 21: OP_LENGTH_0x21: this is SIG R (33 Bytes) 0092263215EE8790:FB10911CE34530BD E179EDF60176C6E1:A6591629D36C8C1E 9C 02: OP_INT_0x02: type tag INTEGER indicating length 20: OP_LENGTH_0x20: this is SIG S (32 Bytes) 59577755C935B4A7:C6A63F12D293B101 8600F9A464F7AEAE:F67D492A08AED9F5 01: OP_SIGHASHALL: this terminates the ECDSA signature (ASN1-DER structure) Witness[2]: 30: OP_SEQUENCE_0x30: type tag indicating SEQUENCE, begin sigscript 45: OP_LENGTH_0x45: length of R + S 02: OP_INT_0x02: type tag INTEGER indicating length 21: OP_LENGTH_0x21: this is SIG R (33 Bytes) 00C357C4DD36AA24:D3AB2FBEEFA3730C 9D5C9441D7171B72:286481F0138744A0 91 02: OP_INT_0x02: type tag INTEGER indicating length 20: OP_LENGTH_0x20: this is SIG S (32 Bytes) 56A7C5E3176A9A09:432B959BA0DFFD89 41FC6D6655CDC915:08A0E1D2DAAD4BF5 01: OP_SIGHASHALL: this terminates the ECDSA signature (ASN1-DER structure) Witness[3]: 52: OP_2: the number 2 is pushed onto stack ################### we go multisig #################################### 21: OP_DATA_0x21: compressed pub key (33 Bytes) 02F44ABCF9E23C9A:460DA309CCCA56C6 19C04EED3BDE2C2C:FF5E7D78FBCD980B 9C This is MultiSig's compressed Public Key (X9.63 form) corresponding bitcoin address is: 1FiVRNmCHaHxXB9eJ5gG25bzzjzYWVbp2u 21: OP_DATA_0x21: compressed pub key (33 Bytes) 03C9443CF3047BB6:C2C82F1B0C44C361 09CDC3D0D601D16D:1189A1602BF8D1A0 A0 This is MultiSig's compressed Public Key (X9.63 form) corresponding bitcoin address is: 12mUsc3d6x1wkcaT6zRPKNpG2bHBtJvG8N 21: OP_DATA_0x21: compressed pub key (33 Bytes) 03BFE86705927441:2412E088AF5572B9 2168C2EF495CFE6C:9B7A753A009EB37C 48 This is MultiSig's compressed Public Key (X9.63 form) corresponding bitcoin address is: 1ENPdt21dRXeNVFXL9BTaXUHf2Drfmi9hc 53: OP_3: the number 3 is pushed onto stack ################### 2-of-3 Multisig ################################### AE: OP_CHECKMULTISIG: terminating multisig corresponding bitcoin address is: 3LTsBuaRozhM1VNUk8tiNUea4G7yakjYJX So I can see different R-Values for signatures, which looks ok. I also tried to look into 2coin.org, but couldn't find the repeating R-values. Did you mention several different tx IDs? I could only check this single tx...
|
|
|
if you could show the tx ID, it would be interesting to analyze it ...
|
|
|
... Got a testnet node synced and set another testned core wallet on the offline machine, then I put the public keys on the online node to see my funds in watch-only mode, but crating the transactions is too complicated if you need to pick specific inputs...
I thought it is possible to assemble a tx completely on live net, with the watch-only address. Then you’d bring the unsigned tx to the cold storage machine, and sign it. Then bring it back to the online machine, and send it... this would remove the burden of manually playing with the in and outs.
|
|
|
A fairly general statement, leading to speculation... If there were possible security issues in a none-defined incident, what do you want to explain? And one could say: Bitcoin was not attacked, the people handling bitcoins got attacked. So some generic thoughts:
a general pattern in bitcoin is: only if you hold the private keys, you are the owner of the bitcoin (and they are secure with you). If you loose your private key, or someone else has the private key, its a matter of trust into the person, who now holds the private keys. Similiar to your fiat-wallet. People can give it back, or they keep it for themselves. So: only put the trading amount into your exchange, and keep the rest with your personal wallet.
Now the second approach for theft of bitcoins is the protection of your operating system. Similiar to the protection of your house. If there is nothing inside, you don't need to have high walls and an electric fence around it... This translates to:
- small funds can use an online wallet - monthly values have a need for a full node on unixoide systems (yes, really!), and maybe already hardware wallet - and yearly values need to be protected with cold storage and multisigs
I am not a Windows hater, I was using it all the time. But when sound drivers have key loggers, and Win10 is sending keystrokes into log files back to Microsoft, it requires a good piece of knowledge, to secure the OS at an appropriate level. By default installation this system is insecure, and a good entrance door to remote attacks. (Compare this to OpenBSD).
Then there are additional layers of security, were people fall victim: phishing - we all know about the different approaches of phishing, and obviously this reoccurs all the time. This is a social issue, not a technical.
java script - well, this is probably one of the best, cause it brings unverified code via the internet to your local machine. If you are dealing with high valued funds, and have priv keys on your internet connected machine, and java script activated, how can you protect your system?
booking system - on many exchanges there were booking systems not adequatly protected, leading to losses
verification - I have even heard about systems, that put the verification of a transaction or a block to the clients machine
So in summary: Bitcoin per se is secure, the code is verified and reviewed, and only professionals develop it :-) On other crypto currencies one would have to evaluate first the level of security (or again: trust tht "these people" do a correct job, but then don't be surprised if funds are lost).
A good security is a trade-off: if you need to protect high values, you need to invest also higher efforst in security. You need to get away from trusting a mobile device, an operating system or the code to be secure just with their default installation. INVEST IN SECURITY!
|
|
|
|