So, I've decided to throw my hat into the mixer, and hopefully be considered as a merit source. I seem to stumble upon posts which I think deserve merit quite often, and ever since the merit system was implemented, and I ran out of my initial merit points I've been keeping a list as I go along, and find quality posts. My idea was to come back to this list, and merit those on it. However, the list keeps on growing, and I find myself meriting current posts rather than those on the list. Only when I get high amounts of merit sent to me in a short period of time do I manage to revisit the list, and merit those that are on it. This isn't the only issue that I'm running into though. I'm currently facing the issue of rewarding only 1/2 maybe 3 merit points per individual post when quite frankly the quality of the post justifies more than that.
My personal merit policy is somewhere along the lines of these, however these are generalizations rather than strict guidelines, and I'm not currently able to follow some of these due to merit restrictions:
- Rank is irrelevant to me, and this isn't a factor on whether I send the merit or how much I send.
- I don't care if your English isn't perfect as long as there's a visible effort, and it's not completely broken.
- A post doesn't have to be 100% correct. Especially, when discussing technical aspects of a subject. If they've clearly made an effort in the post even if it's slightly misguided it doesn't effect my merit distribution. As long as the user isn't ignorant, and are willing to listen to others, and haven't posted complete garbage.
- If a question is particularly interesting, and sparks a interesting discussion off or the potential for a interesting discussion I might send merit to it. This usually means that the question has been thoroughly thought out, and maybe adding their own viewpoint to the question.
-
Generally, the absolute maximum I would send would be 5 merit, and this would have to be a top notch post. Possibly, more may be sent if a post blew me out of the water. This would be exceptionally rare though judging on observations from my merit summary, and posts I have in my text document. - Post has to be unique, and add something new to the discussion.
- Anyone that provides a thought out example to further their point will likely receive 1 extra merit. I quite like when someone goes into the effort of making a practical example which demonstrates their point in action.
- When someone goes on to correct someone's mistake, and provides the explanation why they are incorrect instead of just saying "incorrect" will generally receive some merit off of me. Generally, this would be for more complex issues rather than subjective things like "this exchange is the best", however it's not limited to complex issues. For example, if someone has made a error in a calculation, and someone corrects that error then that would likely receive merit from me.
If you take a look at my merit summary you'll see as soon as I receive merit it's flying out the doors straight away or when I come online. I think I'm active enough within a few sections to merit those that deserve it, and I would hope that I tick the box of an established member. Also, I've decided to pick posts that I've already merited, but still feel are
under merited. The posts quoted below aren't objectively the "best" ones, however for sure they are worthy posts of merit which I currently feel are under merited. (some more than others)
1.
Re: Bitcoin Forks Most of the answers in this thread should have been really helpfull for the OP, i didn't see many mistakes being made by other posters. I did, however, wanted to elaborate on this statement.
If, for example, bitcoin forked into replayattackbitcoin (a fork without replay protection) and you have 1 unspent output funding address 1MyoriGinalAddress before the fork, what could happen if you spent this unspent output on the replayattackbitcoin network?
1) You create a transaction using the unspent output to fund 1AddressGeneratedbyAseller
2) you broadcast the transaction on replayattackbitcoin's network
3) the attacker saves this transaction and broadcasts it on bitcoin's network
4) the transaction gets included into a block on both the original and the new network's blockchain
The end result is that address 1AddressGeneratedbyAseller will become funded on BOTH chains. The attacker cannot use your transaction funding 1AddressGeneratedbyAseller to fund a thirth address owned by the attacker.
In other words, the attacker has to convice you to fund his own address on chain A, then replay the transaction on chain B, otherwise he'll gain nothing from the attack (he can still perform the attack to annoy you, but he won't have any financial motivation to do so).
I actually made this diagram a long time ago (copyright: me). It shows a replay attack and a simple way to protect yourself from such an attack.
2.
Stakes (or stake changes) in any block affect decision process in forks containing that block only, not sibling forks.
A - B0 - C0 - D0
\ B1 - C1
Assuming B0/C0/D0 is the "honest" fork and B1/C1 is an adversarial attempt to a long-range revision attack, any stake changes in B1 and C1 do not affect decision process on the fork B0/C0 etc. Stakes for the decision process are calculated just before each block for that specific fork. More details are in Section 3.3.1 of the paper.
Hi Shunsai,
In the following example, say I had a majority of stake at block A. Then at B0, C0 all the way up to head block H0, I sell off my majority of stake, understanding that there is an upper limit on stake transfer.
A - B0 - C0 - D0 - H0
\ B1 - C1 - D1 - H1
Then, I create a double spend of my stake using the historical private keys, which I still own, thus sending it to myself in a fork continuing fork B1 - C1 - D1 that I create and approve myself (majority stakeholder).
This is not a 50% attack, because I don't own the value held in the private keys anymore, the cost for doing this is nothing.
Why doesn't the network just accept this fork as canon, given that its the same length (or longer if I chose) than the genuine fork?
In another scenario, some stakeholders may only approve their own blocks in an attempt to tilt the winning chances in their own favor. This is a real possibility. A possible mechanism to deter such an "attack" is to simply "blacklist" such stakeholders temporarily. An honest stakeholder can tell within a few blocks with certainty if another stakeholder is not approving his/her valid blocks.
My question is, what does the stakeholder have to gain by approving anyone's blocks but his own? If he has an edge by not doing this, there is a very real problem.
3.
Re: Private Key missing 4 characters In which case, I think the search space is something like (58chars*47positions)*(58chars*47pos)*(58chars*47pos)*(58chars*47pos)... (58*47)
4 = 5.5220891*10
13 possible combinations
---snip---I think your calculation is a bit off. Also we can save computation power by narrowing down search space,
the first 2 chars always start with '5H', '5J', '5K', 51-2 = 49 positions and 49-4 = 45 characters known
if exact position of 4 lost characters are known = 58^4 = 11,316,496 iterations
if exact position is unknown = 58^4 * 4-combination
= (58^4) *
( 49! / 4! (49-4)! ) = (58^4) * (46*47*2*49)
= (58^4) * 211876 = 2,397,693,906,496 iterations = 2.39 * 10
12do I get this right?
I am pretty sure you made a small mistake there. You do ignore the order of the 4 missing words with your statement:
( 49! / 4! (49-4)! )You do iterate through each position with your words, but you have to iterate within the words too.
This should be the correct calculation:
There are
58 choose 4 possible combinations to pick the 4 correct chars from the charspace (without considering the order).
Now consider the first two characters as already known. Only looking at the private key without the first two chars here:
To put the first unknown char into the correct place, you can choose between 1) before of each already existing char (45 possibilities) and 2) behind the last one (45+1).
For the second one you choose either before each char in your privkey (46 possibilities) or behind the last one (46+1)...
Overall there are
46 * 47 * 48 * 49 possible combinations to place the 4 chars into a private key with 45 known characters (ignoring the first two) into the right order. This assumes the already known characters are in a correct order already.
The total search space (for the private key without the first 2 chars) therefore is
46 * 47 * 48 * 49 * (58 choose 4) = 2.1574231*10
12.
Multiplied with 4 (combinations the priv key can start with) = total amount of combinations =
8.6296925 * 1012Considering the birthay paradox, there is a 50% chance to find the correct private key after 1/2 of this space.
Feel free to correct me if i have made a mistake!
4.
Re: [2018-05-16] EU Adopts Rules to Reduce Anonymity for Crypto Users There's an unfortunate endgame to the central bank paradigm.
In principle, once sovereign debt of any state becomes too high (as a % of GNP), the debt becomes unpayable (and it is convincingly argued that because the interest on sovereign bonds isn't created as part of the money supply in the same way that the principal is, that all national debts will end in default on some timescale). Argentina's creditors have recently attempted to use any means necessary (both legal judgements and force) to re-coop their losses, and they go after state assets. That means productive infrastructure that taxpayers supposedly own (lol).
And so the conclusion may well be that the central banking system is the most spectacular long-con ever conceived. When we consider that (for instance) those who instituted the US Federal Reserve provided zero capital for the institution in the first place, it can be argued that central banks represent a leveraged buy-out (where money is borrowed to buy up a company) of an entire country, on behalf of those who buy the bonds (often acquaintances of the central bankers).
It's spectacularly clever if designed that way. All the labour and resources needed to build all that infrastructure existed, the infrastructure itself wouldn't exist if not. The financial system basically lies: all this infrastructure wasn't affordable today, so we'll just throw the part that couldn't be afforded on the national debt. This is essentially a system that creates distortions in prices such that no public money ever gets spent on public infrastructure, it's always borrowed from the central banks, who literally have and provide nothing of value in return (except their debt tokens!). Then the phantom debt can be used to buy the entire state apparatus over the course of a few centuries. It's so clever that the general public sort of deserve to be treated like this, it's so sophisticated as a form of theft that there's not much point in trying to explain it to most people.
5.
Re: Can you think of ways to use LN offline? I remember someone like achow, nullius or theymos saying that right now, you need that both parties are online, otherwise it wouldn't work, which is a big fail and will never get anywhere when it comes to mainstream adoption, but then again, I heard that they are working in ways to mitigate this and avoid needing to have both parties online at the time of the payment which is just ridiculous, it will never catch up, people don't like that, they will most likely resort to third party stuff which will come with a decrease in privacy unfortunately. I wish there was a way to leave the transacion "on hold" until the other peer connected or something.
You're missing the point.
The Lightning Network is a layer on the bitcoin blockchain; it does not have the infrastructure that the underlying blockchain does.
In bitcoin, the recipient of a UTXO does not need to be online because there are other people doing that job: nodes.
Nodes track UTXOs and store unconfirmed transactions in their mempool.
The Lightning Network is just a layer, it does not have nodes.
Even though bitcoin transactions are technically peer-to-peer, the nodes act as
facilitators to Every transaction and UTXO.
The Lightning Network, however, is strictly peer-to-peer.
Transactions between peers in a LN channel are just signed bitcoin transactions that aren't broadcast to the bitcoin blockchain, so they are sent DIRECTLY between themselves, without need for nodes or miners.
If Alice is sending bitcoins to Bob, Bob doesn't need to be online to track or receive the transaction because other nodes do the work because Alice's bitcoin node BROADCASTS the transaction to the other nodes in the blockchain.
If Alice and Bob are peers in a channel, and Alice sends some funds to Bob in form of a commitment transaction, it will fail because Alice is sending the transaction DIRECTLY to Bob's node, not broadcasting it, and if his node is not there to sign the transaction too, then it will fail.
There are no other nodes involved in the transaction so there is no mempool for transactions to reside till the other peer comes online.
Also, commitment transactions are multisig bitcoin transactions (2-of-2 multisig p2wsh transactions to be precise) have to be signed by BOTH parties so if Bob is not online then he can't sign the transaction. A third party, Charlie, can't act in lieu of Bob, because that would require them having Bob's private key.
To summarise the reasons why payments fail when a counterparty is offline are:
1) transactions require the signature of both parties, and obviously won't work with just one signature
2) the transactions are relayed directly p2p, and there are no other nodes that are involved to store transactions
6.
Re: Strategies to prevent shit-postingThere are two overall, often conflicting, strengths in this forum that need to come to terms. On the one hand, there are those that vouch for a spam free forum, centered on Bitcoin discussion. On the other hand, we’ve got a set of Campaigns that are here for their own profit (but that are also a core asset to the Forum’s financial structure), using the Forum as a means to their objectives, but with little regards for the former annotated conflicting strength. This duality of focus, that coexists within a single closed space, leads to the current situation.
Campaigns seem to be here to stay, but that does not mean that the rules that apply to them cannot be tweaked in favour of overall content quality. Merit is an approach in this sense, but it focused on the labour side of Campaign, whilst no additional focus has been placed on the root of the problem, being that Campaigns and Campaign Managers themselves.
Self-awareness by forum elders that also manage campaigns is creating a ripple in the system, by tightening the rules to specific campaigns for those campaigns that they manage, but the main core of campaigns are still running wild and remain rather much exempt for responsibility over their recruits.
I agree therefore that the focus has to be placed there, and that is the reason for the OPs thread, as well as other interesting proposal we’ve seen recently such as this week’s thread by d5000 on the matter (
The core of Bitcointalk's spam problem ), knowing full well that this kind of thread will be buried soon on the nth page of Meta and probably lead nowhere in practice.
But we do have a right to a tantrum and hope to actually get somewhere eventually, so let’s add our two cents to the thread.
<…>
1) Allow forum moderators to penalize users by revoking signature display rights for a month for poor posting habits.
It sounds good, but adds the difficulty of management and an overhead of time to forum moderators which I suspect are not too empty handed right now. If such cases were sort of rare to manage, the overhead would be small, but as we often see, the amount of spammers grows with ease and one signature block on a low ranked account could easily be replaced by another low ranked alt account taking on from there.
2) Penalize bounty campaigns and ICO's that use bumping by shit-posting by displaying their thread permanently on page 10 or a special penalty page which reduces the size of their images and fonts.
A lot of bumping goes on in the Ann section, but so long as it affects the Ann section only, the spill on other Forum sections is not an issue, and delimits only to competing for prime space within the Ann thread. It is not a spam issue, but a “play by the rules of the book”concern as I see it. So long as the bumps are legit (i.e. not paid to bots or serviced accounts that deploy that kind of service), they seem to conform to the organic positioning within the Ann thread.
Bump cheaters could be forced as you say to have a kind of visibility punishment within the Ann Forum Section, but from a the spam point of view at least, what goes on there, if confined to the Ann section, is a lesser issue.
3) Provide preferential listing on page 1 for ICO's and Bounty campaigns that pay to be listed there. Rather than paying an army of shills they could be paying bitcointalk to be listed on the first (featured) page.
The price would have to be heavy though, since I guess that the idea would be that the first page be for paid positioning ICOs and from the second onwards for natural organic bumped ICOs.
I would rather prefer for them to compete for the space than to pay for it. We could bring Merit in to the equation here. For example, we could play with positioning based on three variables:
- Accumulated pre-signature Merit of Campaign´s signatories (this could be gained Merit and not Airdropped Merit for the signatories instead).
- Accumulated Merit of Campaign´s signatories during the actual campaign.
- Natural bumps.
The algoritm would create a scoring based on those three variables, being the second and third more relevant. For example, whenever a signatory is merited, the score for the positioning would be incremented, and thus the ICO’s positioning thread within the Ann section. Gained merit would have more weight than a bump, and a longer time effect in the positioning algorithm.
The above would play on the lines of basing positioning both in terms of participation (natural organic bumping) and quality/interest based by the signatories posting capabilities. Good posters would draw more attention to their signature through their natural activity, whilst rising collaterally the ANN thread’s position. Crappy posters would benefit the Campaign on neither accounts.
7.
Re: Proof-of-Approval: A Better Blockchain Consensus Protocol Am I right that the goals of this protocol are primarily to reduce the finality time in comparison to Bitcoin as well as reduce the cost of running the system?
The image of how blocks are set up (
https://cdn-images-1.medium.com/max/1000/1*fPsB4-t6J_1u1UpF37dYHw.png) reminds me strongly of the way blocks are chained in the "two-hop blockchain" (
https://eprint.iacr.org/2016/716.pdf). I would like to see more in-depth comparisons to other consensus protocols, especially DPoS which seems particularly close in mechanism to Proof-of-Approval.
Your comparison table claims Proof-of-Approval is fully finalized after a single block, however, you also talk about how there may be multiple top-level blocks where the "preferred" chain is unresolved. Doesn't this imply that your transaction being inside a valid block doesn't mean its been fully finalized? How do you reconcile that?
Since any node can produce a candidate block, this seems like it would potentially cause unbounded network traffic with everyone and their mother suggesting blocks to vote on. How is this resolved in the case of, say, an adversarial ddos attack? But I have the same question as monsterer2, why would anyone with stake approve the block of anyone without stake? In fact, why would anyone with stake approve *anyone* else's blocks? It seems there's no incentive to mine on top of someone else's blocks. This could manifest in more subtle attacks where you have stakeholders who refuse to mint on top of a competitor. It could also manifest in deadlock as nodes try to maximize their probability of winning the minted block.
I have a hard time seeing the purpose of having nodes pay attention to timestamps and comparing them to their receive-time. At its core, the mechanism is just voting, right? I don't see why the protocol doesn't just let nodes vote for whatever blocks they want. I see the appeal of a simple stake-voting process for block creation (similar to DPoS), but the Proof of Approval method seems like rational profit-seeking minters would make things devolve into the top 50% stakeholders passing around permission to mine the blocks, completely excluding the other 50%.
Also, could you provide a glossary of variables you use in this paper? Its hard for me to keep track of which variables mean what and find their definition in the prose when I need to refer to what they mean later.
@monsterer2 Are you suggesting that greater permissionlessness is desriable? Also, I've come to the conclusion that bootstrap poisoning can be entirely solved by blockchain checkpoints hardcoded into whatever software you use - since the software should be audited, and malicious software can make your client choose whatever chain it wants, hardcoded checkpoints don't reduce security in any meaningful way and yet completely remove the possibility of long range attacks including bootstrap poisoning.
Also @monsterer2 I would actually call your most recent proposed attack a 51% attack, since you *did* own a majority stake, and are using that fact to attack the network. I'd say its just an interesting twist on a 51% attack.
8.
Re: Noncentral hypergeometric distribution biased by the power-law distribution? For Dfinity, they give the probabilities in the paper for adversarial nodes at 33%, 25%, and 20% of the total nodes.
Correct.
I shouldn’t have posted this thread when I was so sleepy and looking at the screen cross-eyed. I try to push too hard which can be my undoing.
My concern turns out to not really be about the math, because it requires a political-economic assumption as to the maximum percentage of the stake that will collude. And I was incorrect to think we would need a
noncentral hypergeometric distribution. The standard hypergeometric distribution is applicable after we choose a threshold level for the maximum colluding set.
With a fresher mind, clearly the DFINITY paper is computing the case where one (or one colluding set of) entity(ies) would have
⅓ of the (e.g. stake deposited) permissioned nodes. That’s the maximum attack threat they consider, presumably because above that exceeds the
½ safety and liveness thresholds of their design, so the attacker could double-spend or stall the consensus indefinitely.
That very low
½ safety threshold is a significant weakness of their design in the proof-of-stake context, but if they choose instead
⅔ safety threshold then the liveness drops to
⅓ making it much more likely the chain can become stuck if it is not controlled by a “benevolent” (less overt) oligarchy. Moreover, the typical attack on proof-of-stake is not to stuck the chain but rather to be a less obviously malevolent oligarchy and employ the control to extract maximum rents from the system such as by maximizing the transaction fees and/or
capturing disproportionately all or most of the minted block rewards (which in the case of Steem is to
cartelize control over the voting algorithm, see
also). Which could be especially onerous if DFINITY employs the random beacon (as they propose to do) to supply randomness to the smart contracts, then the attacker can do more than just double-spend his own tokens and actually infiltrate smart contracts in presumably insidious ways.
I think they should have computed the maximum adversarial percentage threshold to be more congruent with the reality of power-law distribution of wealth:
The economist Edward N Wolff, of New York University, has pointed out that, as of 2007, the top 1% of households in America owned 34.6% of all privately held wealth, and the next 19% had 50.5% of the wealth. This means that just 20% of the people owned 85% of the wealth, leaving only 15% for the bottom 80% of the people.
And the reality of
how easy it is for an oligarchy to take control of 80+% of the stake of any proof-of-stake project token.
Based on the above reality, I presumed in my analysis of DFINITY that they would have to choose instead
⅔ safety threshold and thus the liveness drops to
⅓. That very low liveness is a significant risk of chain getting stuck, but they really have no choice given the reality above. And also typically the attacker will not choose the stuck chain approach of maximizing profits by shorting the token.
So with 10,000 permissioned nodes, 50% of them controlled by the adversary, and with a
⅔ safety threshold, then I compute roughly the same group size as computed for the
⅓ adversary case in the whitepaper (with
½ safety threshold). So the
⅔ safety threshold seems viable as long as the adversarial stake remains below
50%. I still don’t think it’s very secure (because of the
nothing-at-stake cost free attacks) but that is less unrealistic than their
⅓ adversarial stake assumption.
If adversarial majority is selected, presumably from there they could create a chain that continues to select them as a majority ad infinitum.
Correct. The random beacon can be biased when the safety threshold is exceeded. And I do not know if their BLS threshold signature scheme can be made to function with a
⅔ safety threshold instead of
½. If not, the design is very unrealistic. Presumably it can be. But still the security is weak because of nothing-at-stake and the fact that nothing-at-stake incentivizes an oligarchy to obtain
80+% of the stake. My assertion is that proof-of-stake is not viable unless the nothing-at-stake incentive is removed somehow. But no extant non-proof-of-work design has figured out how to do it. I think I know how to do it.
However, and I probably do not understand the protocol fully, but I wonder why the resulting signature of the majority group is used for the next group's selection. If you set up the whole set to be selected in a complete order at once, it would seem to reduce this vulnerability to only being able to stop fault the network, rather than being able to create a chain that continuously selects your members forever, and thus able to create forks at will with no retribution. If the whole set has a complete order, as long as one honest majority group exists, they can prevent censorship during their window and provably punish certain behavior, AFAICT.
Because the BLS threshold signature does not scale to unbounded set size at the desired slot confirmation delay. And that wouldn’t ameliorate the security issue you are concerned about anyway, because then either it would still be adversarial always or never, because there can be no other additional randomness injected by running the protocol.
The BLS threshold signature is fast enough that they can do it every block (slot), unlike in Ouroboros which can only do unbiased (i.e. secure) multiparty signature every epoch. And this is perhaps related to
Dan Larimer’s criticism of Ouroboros. Algorand isn’t even unbiased.
EDIT: I have more carefully read Dan’s criticisms of Ouroboros and I think
he is being very disingenuous. I have rebutted on his blog.
9.
Re: Would it be possible to implement a cryptocurrency with distribution of wealth?You should look into universal basic income, if you haven't already. If you look into UBI you will find some ideas that pretty much align with what you are suggesting. There are also practical experiments, both past and ongoing, looking into the matter. Using a cryptocurrency as means of distribution would of course lend itself to the idea, but it's not an easy problem to solve, especially with both UBI and cryptocurrencies being rather unexplored fields.
Here's a list of pilot projects that may interest you:
https://en.wikipedia.org/wiki/Basic_income_pilotsI see that nobody here knows how a socialist or communist person is, you guys never talked to one I notice that, that is why you say nobody will be motivated by the currency, not all people in the world is motivated by the money like you guys, for example think about almost any scientist or a lot of students, they don't learn and do science for the money, they do it because they like knowledge, and that is just a quick example.
Of course there are a lot of passion jobs where money is secondary, but at the end of the day they still require money to continue their work. You can't just look at individuals in isolation without their socio-economic surroundings.
Also note that while researchers may not be in it for the money, a lot of them still get paid fairly well and rightfully so.
Point being, it doesn't matter if parts of the population don't care about money. As long as there are
some people striving for wealth, they will try to exploit the current system. And if they are able to exploit the system, that's exactly what they will do -- at the cost of everyone else who "doesn't care about money".
Even if your main intention is to spread wealth evenly amongst the populace, as long as there are some angles to exploit or positions of power to obtain, the approach is prone to failure due to human nature. Case in point, every implementation of Communism so far either digressed into a dictatorship or some form of centrally controlled capitalism.
Communism is easy to romance with if you never lived in it, but it's not a pretty system due to being relatively easy exploited from the top down. Maybe even moreso than Capitalism.
That being said, I'm convinced that due to technological and economical progress, some form of UBI will become a necessity in the future. It's going to be a very hard problem to solve though, regardless of whether it will involve cryptocurrencies or not.
10.
Safe storage of data. GUIDE Often I see questions pop up on the forum regarding safe keeping of passwords and data. I decided to write up a detailed instructions on the encryption of data.
For creating encrypted data base, I use software called VeraCrypt. It is free and open source. More details on the software here:
https://en.wikipedia.org/wiki/VeraCryptDownload and install the software here:
https://www.veracrypt.fr/en/Downloads.html1. Open the software, double click "Create Volume:
2. Now we click the check mark next to "Create an encrypted file container" and click next
3. During the next step we decide whether we want to create a regular encrypted volume or one with double encryption. In these instructions I am going to show regularly encrypted volume. So, we choose "Standard VeraCrypt volume" and click next
4. New we connect our usb drive to the computer. During this step we have to manually enter the path to the file which is going to be placed on the USB. For this open "my computer" and see under which name is our USB (in my case it is E). So, we enter our path for the file being created and click next.
5. Choosing type of encryption as "Twofish", and clicking next
6. Need to choose the encryption size. Here you are going to have to judge yourself. If you are planning to have encrypted just password database and private keys, you will not need much space. My recommendation then would be to take up a small amount of the USB and the rest of it to fill up with various files. This is done so if ever your usb was lost or stolen, and open by a third party, the file would not stick out.
My usb drive size is 3.7gb so I am choosing 1gb for encryption file size and leaving 2.7 gb empty
7. Now need to come up with a password. Password needs to be new and not something you use everywhere else. Better to make something out of 15-20 various symbols with different sizes. Write it down on the paper for you. After a few days on constant input you can throw away the paper
8. Start up the generation of you key encryption, move your mouse around, the key will be generated quicker. When the bar is fully green, press Format
9. The process of encryption itself has began. The larger size you picked during step 6, the longer it will take. For example when I was encrypting 60 gb it took me 30 minutes. Process is complete when you see this message
On the next window press Exit. On this step the process of encryption is complete. Now I will show you how to use it. Access your USB and we see this kind of file. It can ONLY be opened with the software VeraCrypt AND putting in your set password
Upon accessing VeraCrypt we see many different unused volumes in your system. Choose one, say A. Click select file and our created file on the usb and click mount
On the next window enter the password you created during step 7 and click ok. Access my computer and we observe the new local drive.
This is our encrypted volume which appeared only after we entered the password from it. In it we can store our password, private keys etc....
IMPORTANT: Upong ending your work, do not forget to close the volume, otherwise you may risk of losing your data. For this we press Dismount in VeraCrypt
After this we can dismount the USB from the PC (not forgetting about the safe way to eject the usb and not just pulling it out). The process of creating encrypted volume/database will take about 20 minutes but save you a lot of time you could have spent worrying about keeping your data safe
Regardless, of the outcome of this thread. At the very least I hope this provides some exposure to some posts which are currently under merited, and also some exceptional members which continue to make great posts.