Generate CSR and Private Key Online WTOOLS

semi-quick answers to common questions of new people

so people often ask similar questions over here and because they are getting probably kinda annoying over time to many I just try to answer as many as I find. if you have more that would fit here, add them to the comments

submitted by My1xT to ledgerwallet [link] [comments]

Paper Wallet Vanity addresses.

EDIT 2/21/2020. I am no longer offering the service described below as I no longer have access to the necessary hardware.
~~~~~~~~~~
Hey all,
I have recently been messing around with vanity addresses for paper wallets. After a little tinkering I got the system working well and can generate wallets up to a certain complexity quite reliably.
I've been able to generate wallets like this one: 1Bitcoinjqekek8HwmT8Cp8ojH9b7Quhzi
This one: 1Satoshi3A43v3Jk9MpfJPUDrWadFUUP6
And this one: 1Genesisud7wjt8Lkto75ANupmviwC2wpW
I personally haven't been using paper wallets for cold storage until now, but with the value of BSV going up and also having read the following paper about the possibility (albeit very small) of compromise of private keys in HD wallets, that for the BSV I intend to sit on long term, it's probably not the worst idea ever to use a paper wallet for that. But hey, it would be nice if those addresses were a bit more recognizable than a random address, am I right? :)
In going through this exercise, I happened to notice that there are services out there that will generate these kinds of addresses, but they seem overly expensive!
e.g., At vanity.coin.dance they want 1 BTC(!!) to generate an address starting with "Satoshi" e.g., like the "1Satoshi3A43v3Jk9MpfJPUDrWadFUUP6" I generated above. That's day-light robbery!!
Furthermore, the above service treats split key generation (which seems necessary for security when having a third party generate the wallet) as an "advanced" feature only. Imagine paying 1 BTC for an address only to have the private key compromised! (Seems almost negligent).
So anyway, whilst I have this system set up and working, I was thinking I could extend a temporary offer to anyone who is interested in getting a vanity address (or addresses) for paper wallet cold storage.
So all that said, the procedure, following the secure split key approach, would be as follows.
  1. You would go to bitaddress.org and download a local copy of the web site (and validate it against provided signatures).
  2. Run that downloaded copy of web site on an off-line system.
  3. Click the Vanity Wallet Tab.
  4. Click the "Generate" button in Step 1.
  5. Copy the public key from Step 1 and PM me with that key (it's quite long so copy/paste is the way to go). Also indicate in the PM the address prefix that you want (can't include invalid characters; I will tell you if you included any). Be sure to keep a copy of the private key from Step 1 (or keep the web page open). If you lose this key the whole process will be for nothing. Do not lose (or compromise) it (and definitely do not PM it to me!).
  6. Send payment (as per the schedule below) to 1Satoshi3A43v3Jk9MpfJPUDrWadFUUP6 and PM me the TxID.
  7. When I receive payment, I will generate a partial private key that you need for Step 2 in the bitaddress.org page.
  8. You take the partial private key that you generated in Step 1 (that you keep secure and never shared with anyone) and paste it into the first box in Step 2 in the Bitaddress.org page (that you are still running locally and off-line).
  9. Finally, you paste the partial private key that I PM you back, into the text box where it says "Enter Pool Part Private Key (from Vanity Pool):" (Note: PMing this partial private key is fine; so long as you keep your partial private key secure (from Step 1), the process is still secure; the process is intended to work this way).
  10. Click "Calculate Vanity Wallet" et viola! A wallet will be produced that meets your prefix requirement and is 100% secure since the partial private key that you generated in Step 1 never left your control.
What you do with your new shiny address from that point on-wards is your prerogative, the same as any other paper wallet that you produce. Our deal is done.
The pricing schedule for this (temporary) service is as follows:
  1. 3 Characters (e.g.,) 1BSVxxxx....xxx 0.01 BSV.
  2. 4 Characters (e.g.,) 1Coinxxx....xxx 0.02 BSV.
  3. 5 Characters (e.g.,) 1Coinsxx....xxx 0.04 BSV.
  4. 6 Characters (e.g.,) 1BuyBSVx....xxx 0.1 BSV.
  5. 7 Characters (e.g.,) 1Satoshi....xxx 0.75 BSV1.
(Footnote 1: Turns out most 7 character combinations are pretty hard to generate and may take quite a while to generate. The prefix "1Bitcoin", however, is not as hard (higher chance of generating), and I can do that one for 0.25 BSV).
(Note: I can't guarantee that I can deliver anything longer than 7 characters, hence there is no price for this).
(Note: The reason for the steep increase in price as a function of number of prefix characters is the time it takes to generate the addresses as they become exponentially more complex and the fact the process is non deterministic).
Compare the above price for a 1Satoshi... address (0.75BSV) to vanity.coin.dance (1BTC!!!) and hopefully you'll see that I'm being pretty reasonable with this, though do note that the "1Satoshi" prefix, specifically, is a hard one to generate and I may not be able to do it unless you are willing to wait a while.
Anyway, I'm not sure if anyone will be interested in this, and you'll have to trust me as someone who has been in this sub since the total membership was only in double digits, that I'm not a fly by night scammer who is going to take your payment and run! To that end I advise that I have made posts in this sub with direct reference to my Australian based registered business that accepts BSV as payment, so it's not hard to track me down. If you go back far enough you'll also see that I was involved in running a Bitstagram competition and came good with the BSV prize in that case. That said, a small amount of trust will be required if this is going to work out. Test me with one of the cheaper options first, if you have doubts.
Terms and Conditions
  1. Any PM received with an "order" is an offer by you to purchase a vanity address. It's not binding until I accept the offer in writing (by PM).
  2. All "orders" will be processed in the order they are received; I will guarantee a 48 hour turn around for everything up to 6 characters and 1681 hours (7 days) for 7 characters. In reality most will be processed much quicker, but I have to cover my ass! If I get too many orders (unlikely!!) I reserve the right to reject any that I cannot meet in a timely manner (any payments that have been made will be refunded to the specified address, less any BSV Tx fees).
  3. This offer is on the table until I withdraw it. I may withdraw it at any time by making a follow up post to this sub edit to this post.
  4. The address that is generated is the address that you get and that is final. If there is something in the address that you don't like (like a random swear word; albeit very unlikely) we can discuss a discounted rate to have a second try at it. (I'd rather you go home happy, if possible).
  5. If there is some address that I cannot generate in the above guaranteed time frames (some are harder to produce than others), I will let you know by PM and refund your entire purchase price.
  6. The entire risk of the use of the generated vanity address lies with you. (I recommend you test it with a small amount and make sure you can withdraw it, before loading it up for real).
(T&C Footnote 1: Some 7 character combinations can take a long time to find (e.g., "1Satoshi") and may take up to two weeks or more! I reserve the right to not even attempt to generate any specific combination that could adversely affect my ability to turn it around in a reasonably timely manner. In that case you can choose a different prefix or I will refund your money, if at that stage you had already paid). For any potential prefix I can check the estimated time to generate and report back on whether it's reasonable, before we agree to go ahead.)
ps/ Here are two three addresses that I generated showing that funds are able to be deposited and withdrawn successfully.
https://blockchair.com/bitcoin-sv/address/1Satoshi3A43v3Jk9MpfJPUDrWadFUUP6
https://blockchair.com/bitcoin-sv/address/1Bitcoinjqekek8HwmT8Cp8ojH9b7Quhzi
https://blockchair.com/bitcoin-sv/address/1BuyBSVMHGx6dSTpLMhALXvEPVEDMStxoR
Both addresses accepted funds and both allowed the BSV to be successfully swept (in this case I used Simply Cash to deposit and sweep).
~~~~~~~~~~
EDIT 2/21/2020. I am no longer offering the service described below as I no longer have access to the necessary hardware.
submitted by PaidSockPuppet to bitcoincashSV [link] [comments]

Help me code it!

Hi everyone, i am learning about Python and it's quite hard with me. I want to calculate Public key from Private key with ECC. I have the code from Github, transform it to Python 3.0 and it does not work:
# Super simple Elliptic Curve Presentation. No imported libraries, wrappers, nothing. # For educational purposes only. Remember to use Python 2.7.6 or lower. You'll need to make changes for Python 3. # Below are the public specs for Bitcoin's curve - the secp256k1 import binascii Pcurve = 2**256 - 2**32 - 2**9 - 2**8 - 2**7 - 2**6 - 2**4 -1 # The proven prime N=0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 # Number of points in the field Acurve = 0; Bcurve = 7 # These two defines the elliptic curve. y^2 = x^3 + Acurve * x + Bcurve Gx = 55066263022277343669578718895168534326250603453777594175500187360389116729240 Gy = 32670510020758816978083085130507043184471273380659243275938904335757337482424 GPoint = (Gx,Gy) # This is our generator point. Trillions of dif ones possible #Individual Transaction/Personal Information privKey = 0xA0DC65FFCA799873CBEA0AC274015B9526505DAAAED385155425F7337704883E #replace with any private key def modinv(a,n=Pcurve): #Extended Euclidean Algorithm/'division' in elliptic curves lm, hm = 1,0 low, high = a%n,n while low > 1: ratio = high/low nm, new = hm-lm*ratio, high-low*ratio lm, low, hm, high = nm, new, lm, low return lm % n def ECadd(a,b): # Not true addition, invented for EC. Could have been called anything. LamAdd = ((b[1]-a[1]) * modinv(b[0]-a[0],Pcurve)) % Pcurve x = (LamAdd*LamAdd-a[0]-b[0]) % Pcurve y = (LamAdd*(a[0]-x)-a[1]) % Pcurve return (x,y) def ECdouble(a): # This is called point doubling, also invented for EC. Lam = ((3*a[0]*a[0]+Acurve) * modinv((2*a[1]),Pcurve)) % Pcurve x = (Lam*Lam-2*a[0]) % Pcurve y = (Lam*(a[0]-x)-a[1]) % Pcurve return (x,y) def EccMultiply(GenPoint,ScalarHex): #Double & add. Not true multiplication if ScalarHex == 0 or ScalarHex >= N: raise Exception("Invalid ScalaPrivate Key") ScalarBin = str(bin(ScalarHex))[2:]; #print(ScalarBin); Q=GenPoint for i in range (1,len(ScalarBin)): # This is invented EC multiplication. Q=ECdouble(Q); print(("DUB", Q[0])); print(i) if ScalarBin[i] == "1": Q=ECadd(Q,GenPoint); print(("ADD", Q[0])); print() return (Q) PublicKey = EccMultiply(GPoint,privKey); print(); print("******* Public Key Generation *********"); print() print("the private key:"); print((hex(privKey))); print() print("the uncompressed public key (not address):"); print(PublicKey); print() print("the uncompressed public key (HEX):"); print(("04" + "%064x" % PublicKey[0] + "%064x" % PublicKey[1])); print(); print("the official Public Key - compressed:"); if PublicKey[1] % 2 == 1: # If the Y value for the Public Key is odd. print(("03"+str(hex(PublicKey[0])[2:-1]).zfill(64))) else: # Or else, if the Y value is even. print(("02"+str(hex(PublicKey[0])[2:-1]).zfill(64))) 
submitted by Phuc_Jackson to Bitcoin [link] [comments]

Searching for the Unicorn Cryptocurrency

Searching for the Unicorn Cryptocurrency
For someone first starting out as a cryptocurrency investor, finding a trustworthy manual for screening a cryptocurrency’s merits is nonexistent as we are still in the early, Wild West days of the cryptocurrency market. One would need to become deeply familiar with the inner workings of blockchain to be able to perform the bare minimum due diligence.
One might believe, over time, that finding the perfect cryptocurrency may be nothing short of futile. If a cryptocurrency purports infinite scalability, then it is probably either lightweight with limited features or it is highly centralized among a limited number of nodes that perform consensus services especially Proof of Stake or Delegated Proof of Stake. Similarly, a cryptocurrency that purports comprehensive privacy may have technical obstacles to overcome if it aims to expand its applications such as in smart contracts. The bottom line is that it is extremely difficult for a cryptocurrency to have all important features jam-packed into itself.
The cryptocurrency space is stuck in the era of the “dial-up internet” in a manner of speaking. Currently blockchain can’t scale – not without certain tradeoffs – and it hasn’t fully resolved certain intractable issues such as user-unfriendly long addresses and how the blockchain size is forever increasing to name two.
In other words, we haven’t found the ultimate cryptocurrency. That is, we haven’t found the mystical unicorn cryptocurrency that ushers the era of decentralization while eschewing all the limitations of traditional blockchain systems.
“But wait – what about Ethereum once it implements sharding?”
“Wouldn’t IOTA be able to scale infinitely with smart contracts through its Qubic offering?”
“Isn’t Dash capable of having privacy, smart contracts, and instantaneous transactions?”
Those thoughts and comments may come from cryptocurrency investors who have done their research. It is natural for the informed investors to invest in projects that are believed to bring cutting edge technological transformation to blockchain. Sooner or later, the sinking realization will hit that any variation of the current blockchain technology will always likely have certain limitations.
Let us pretend that there indeed exists a unicorn cryptocurrency somewhere that may or may not be here yet. What would it look like, exactly? Let us set the 5 criteria of the unicorn cryptocurrency:
Unicorn Criteria
(1) Perfectly solves the blockchain trilemma:
o Infinite scalability
o Full security
o Full decentralization
(2) Zero or minimal transaction fee
(3) Full privacy
(4) Full smart contract capabilities
(5) Fair distribution and fair governance
For each of the above 5 criteria, there would not be any middle ground. For example, a cryptocurrency with just an in-protocol mixer would not be considered as having full privacy. As another example, an Initial Coin Offering (ICO) may possibly violate criterion (5) since with an ICO the distribution and governance are often heavily favored towards an oligarchy – this in turn would defy the spirit of decentralization that Bitcoin was found on.
There is no cryptocurrency currently that fits the above profile of the unicorn cryptocurrency. Let us examine an arbitrary list of highly hyped cryptocurrencies that meet the above list at least partially. The following list is by no means comprehensive but may be a sufficient sampling of various blockchain implementations:
Bitcoin (BTC)
Bitcoin is the very first and the best known cryptocurrency that started it all. While Bitcoin is generally considered extremely secure, it suffers from mining centralization to a degree. Bitcoin is not anonymous, lacks smart contracts, and most worrisomely, can only do about 7 transactions per seconds (TPS). Bitcoin is not the unicorn notwithstanding all the Bitcoin maximalists.
Ethereum (ETH)
Ethereum is widely considered the gold standard of smart contracts aside from its scalability problem. Sharding as part of Casper’s release is generally considered to be the solution to Ethereum’s scalability problem.
The goal of sharding is to split up validating responsibilities among various groups or shards. Ethereum’s sharding comes down to duplicating the existing blockchain architecture and sharing a token. This does not solve the core issue and simply kicks the can further down the road. After all, full nodes still need to exist one way or another.
Ethereum’s blockchain size problem is also an issue as will be explained more later in this article.
As a result, Ethereum is not the unicorn due to its incomplete approach to scalability and, to a degree, security.
Dash
Dash’s masternodes are widely considered to be centralized due to their high funding requirements, and there are accounts of a pre-mine in the beginning. Dash is not the unicorn due to its questionable decentralization.
Nano
Nano boasts rightfully for its instant, free transactions. But it lacks smart contracts and privacy, and it may be exposed to well orchestrated DDOS attacks. Therefore, it goes without saying that Nano is not the unicorn.
EOS
While EOS claims to execute millions of transactions per seconds, a quick glance reveals centralized parameters with 21 nodes and a questionable governance system. Therefore, EOS fails to achieve the unicorn status.
Monero (XMR)
One of the best known and respected privacy coins, Monero lacks smart contracts and may fall short of infinite scalability due to CryptoNote’s design. The unicorn rank is out of Monero’s reach.
IOTA
IOTA’s scalability is based on the number of transactions the network processes, and so its supposedly infinite scalability would fluctuate and is subject to the whims of the underlying transactions. While IOTA’s scalability approach is innovative and may work in the long term, it should be reminded that the unicorn cryptocurrency has no middle ground. The unicorn cryptocurrency would be expected to scale infinitely on a consistent basis from the beginning.
In addition, IOTA’s Masked Authenticated Messaging (MAM) feature does not bring privacy to the masses in a highly convenient manner. Consequently, the unicorn is not found with IOTA.

PascalCoin as a Candidate for the Unicorn Cryptocurrency
Please allow me to present a candidate for the cryptocurrency unicorn: PascalCoin.
According to the website, PascalCoin claims the following:
“PascalCoin is an instant, zero-fee, infinitely scalable, and decentralized cryptocurrency with advanced privacy and smart contract capabilities. Enabled by the SafeBox technology to become the world’s first blockchain independent of historical operations, PascalCoin possesses unlimited potential.”
The above summary is a mouthful to be sure, but let’s take a deep dive on how PascalCoin innovates with the SafeBox and more. Before we do this, I encourage you to first become acquainted with PascalCoin by watching the following video introduction:
https://www.youtube.com/watch?time_continue=4&v=F25UU-0W9Dk
The rest of this section will be split into 10 parts in order to illustrate most of the notable features of PascalCoin. Naturally, let’s start off with the SafeBox.
Part #1: The SafeBox
Unlike traditional UTXO-based cryptocurrencies in which the blockchain records the specifics of each transaction (address, sender address, amount of funds transferred, etc.), the blockchain in PascalCoin is only used to mutate the SafeBox. The SafeBox is a separate but equivalent cryptographic data structure that snapshots account balances. PascalCoin’s blockchain is comparable to a machine that feeds the most important data – namely, the state of an account – into the SafeBox. Any node can still independently compute and verify the cumulative Proof-of-Work required to construct the SafeBox.
The PascalCoin whitepaper elegantly highlights the unique historical independence that the SafeBox possesses:
“While there are approaches that cryptocurrencies could use such as pruning, warp-sync, "finality checkpoints", UTXO-snapshotting, etc, there is a fundamental difference with PascalCoin. Their new nodes can only prove they are on most-work-chain using the infinite history whereas in PascalCoin, new nodes can prove they are on the most-work chain without the infinite history.”
Some cryptocurrency old-timers might instinctively balk at the idea of full nodes eschewing the entire history for security, but such a reaction would showcase a lack of understanding on what the SafeBox really does.
A concrete example would go a long way to best illustrate what the SafeBox does. Let’s say I input the following operations in my calculator:
5 * 5 – 10 / 2 + 5
It does not take a genius to calculate the answer, 25. Now, the expression “5 \ 5 – 10 / 2 + 5”* would be forever imbued on a traditional blockchain’s history. But the SafeBox begs to differ. It says that the expression “5 \ 5 – 10 / 2 + 5”* should instead be simply “25” so as preserve simplicity, time, and space. In other words, the SafeBox simply preserves the account balance.
But some might still be unsatisfied and claim that if one cannot trace the series of operations (transactions) that lead to the final number (balance) of 25, the blockchain is inherently insecure.
Here are four important security aspects of the SafeBox that some people fail to realize:
(1) SafeBox Follows the Longest Chain of Proof-of-Work
The SafeBox mutates itself per 100 blocks. Each new SafeBox mutation must reference both to the previous SafeBox mutation and the preceding 100 blocks in order to be valid, and the resultant hash of the new mutated SafeBox must then be referenced by each of the new subsequent blocks, and the process repeats itself forever.
The fact that each new SafeBox mutation must reference to the previous SafeBox mutation is comparable to relying on the entire history. This is because the previous SafeBox mutation encapsulates the result of cumulative entire history except for the 100 blocks which is why each new SafeBox mutation requires both the previous SafeBox mutation and the preceding 100 blocks.
So in a sense, there is a single interconnected chain of inflows and outflows, supported by Byzantine Proof-of-Work consensus, instead of the entire history of transactions.
More concretely, the SafeBox follows the path of the longest chain of Proof-of-Work simply by design, and is thus cryptographically equivalent to the entire history even without tracing specific operations in the past. If the chain is rolled back with a 51% attack, only the attacker’s own account(s) in the SafeBox can be manipulated as is explained in the next part.
(2) A 51% Attack on PascalCoin Functions the Same as Others
A 51% attack on PascalCoin would work in a similar way as with other Proof-of-Work cryptocurrencies. An attacker cannot modify a transaction in the past without affecting the current SafeBox hash which is accepted by all honest nodes.
Someone might claim that if you roll back all the current blocks plus the 100 blocks prior to the SafeBox’s mutation, one could create a forged SafeBox with different balances for all accounts. This would be incorrect as one would be able to manipulate only his or her own account(s) in the SafeBox with a 51% attack – just as is the case with other UTXO cryptocurrencies. The SafeBox stores the balances of all accounts which are in turn irreversibly linked only to their respective owners’ private keys.
(3) One Could Preserve the Entire History of the PascalCoin Blockchain
No blockchain data in PascalCoin is ever deleted even in the presence of the SafeBox. Since the SafeBox is cryptographically equivalent to a full node with the entire history as explained above, PascalCoin full nodes are not expected to contain infinite history. But for whatever reason(s) one may have, one could still keep all the PascalCoin blockchain history as well along with the SafeBox as an option even though it would be redundant.
Without storing the entire history of the PascalCoin blockchain, you can still trace the specific operations of the 100 blocks prior to when the SafeBox absorbs and reflects the net result (a single balance for each account) from those 100 blocks. But if you’re interested in tracing operations over a longer period in the past – as redundant as that may be – you’d have the option to do so by storing the entire history of the PascalCoin blockchain.
(4) The SafeBox is Equivalent to the Entire Blockchain History
Some skeptics may ask this question: “What if the SafeBox is forever lost? How would you be able to verify your accounts?” Asking this question is tantamount to asking to what would happen to Bitcoin if all of its entire history was erased. The result would be chaos, of course, but the SafeBox is still in line with the general security model of a traditional blockchain with respect to black swans.
Now that we know the security of the SafeBox is not compromised, what are the implications of this new blockchain paradigm? A colorful illustration as follows still wouldn’t do justice to the subtle revolution that the SafeBox ushers. The automobiles we see on the street are the cookie-and-butter representation of traditional blockchain systems. The SafeBox, on the other hand, supercharges those traditional cars to become the Transformers from Michael Bay’s films.
The SafeBox is an entirely different blockchain architecture that is impressive in its simplicity and ingenuity. The SafeBox’s design is only the opening act for PascalCoin’s vast nuclear arsenal. If the above was all that PascalCoin offers, it still wouldn’t come close to achieving the unicorn status but luckily, we have just scratched the surface. Please keep on reading on if you want to learn how PascalCoin is going to shatter the cryptocurrency industry into pieces. Buckle down as this is going to be a long read as we explore further about the SafeBox’s implications.
Part #2: 0-Confirmation Transactions
To begin, 0-confirmation transactions are secure in PascalCoin thanks to the SafeBox.
The following paraphrases an explanation of PascalCoin’s 0-confirmations from the whitepaper:
“Since PascalCoin is not a UTXO-based currency but rather a State-based currency thanks to the SafeBox, the security guarantee of 0-confirmation transactions are much stronger than in UTXO-based currencies. For example, in Bitcoin if a merchant accepts a 0-confirmation transaction for a coffee, the buyer can simply roll that transaction back after receiving the coffee but before the transaction is confirmed in a block. The way the buyer does this is by re-spending those UTXOs to himself in a new transaction (with a higher fee) thus invalidating them for the merchant. In PascalCoin, this is virtually impossible since the buyer's transaction to the merchant is simply a delta-operation to debit/credit a quantity from/to accounts respectively. The buyer is unable to erase or pre-empt this two-sided, debit/credit-based transaction from the network’s pending pool until it either enters a block for confirmation or is discarded with respect to both sender and receiver ends. If the buyer tries to double-spend the coffee funds after receiving the coffee but before they clear, the double-spend transaction will not propagate the network since nodes cannot propagate a double-spending transaction thanks to the debit/credit nature of the transaction. A UTXO-based transaction is initially one-sided before confirmation and therefore is more exposed to one-sided malicious schemes of double spending.”
Phew, that explanation was technical but it had to be done. In summary, PascalCoin possesses the only secure 0-confirmation transactions in the cryptocurrency industry, and it goes without saying that this means PascalCoin is extremely fast. In fact, PascalCoin is capable of 72,000 TPS even prior to any additional extensive optimizations down the road. In other words, PascalCoin is as instant as it gets and gives Nano a run for its money.
Part #3: Zero Fee
Let’s circle back to our discussion of PascalCoin’s 0-confirmation capability. Here’s a little fun magical twist to PascalCoin’s 0-confirmation magic: 0-confirmation transactions are zero-fee. As in you don’t pay a single cent in fee for each 0-confirmation! There is just a tiny downside: if you create a second transaction in a 5-minute block window then you’d need to pay a minimal fee. Imagine using Nano but with a significantly stronger anti-DDOS protection for spam! But there shouldn’t be any complaint as this fee would amount to 0.0001 Pascal or $0.00002 based on the current price of a Pascal at the time of this writing.
So, how come the fee for blazingly fast transactions is nonexistent? This is where the magic of the SafeBox arises in three ways:
(1) PascalCoin possesses the secure 0-confirmation feature as discussed above that enables this speed.
(2) There is no fee bidding competition of transaction priority typical in UTXO cryptocurrencies since, once again, PascalCoin operates on secure 0-confirmations.
(3) There is no fee incentive needed to run full nodes on behalf of the network’s security beyond the consensus rewards.
Part #4: Blockchain Size
Let’s expand more on the third point above, using Ethereum as an example. Since Ethereum’s launch in 2015, its full blockchain size is currently around 2 TB, give or take, but let’s just say its blockchain size is 100 GB for now to avoid offending the Ethereum elitists who insist there are different types of full nodes that are lighter. Whoever runs Ethereum’s full nodes would expect storage fees on top of the typical consensus fees as it takes significant resources to shoulder Ethereum’s full blockchain size and in turn secure the network. What if I told you that PascalCoin’s full blockchain size will never exceed few GBs after thousands of years? That is just what the SafeBox enables PascalCoin to do so. It is estimated that by 2072, PascalCoin’s full nodes will only be 6 GB which is low enough not to warrant any fee incentives for hosting full nodes. Remember, the SafeBox is an ultra-light cryptographic data structure that is cryptographically equivalent to a blockchain with the entire transaction history. In other words, the SafeBox is a compact spreadsheet of all account balances that functions as PascalCoin’s full node!
Not only does the SafeBox’s infinitesimal memory size helps to reduce transaction fees by phasing out any storage fees, but it also paves the way for true decentralization. It would be trivial for every PascalCoin user to opt a full node in the form of a wallet. This is extreme decentralization at its finest since the majority of users of other cryptocurrencies ditch full nodes due to their burdensome sizes. It is naïve to believe that storage costs would reduce enough to the point where hosting full nodes are trivial. Take a look at the following chart outlining the trend of storage cost.

* https://www.backblaze.com/blog/hard-drive-cost-per-gigabyte/
As we can see, storage costs continue to decrease but the descent is slowing down as is the norm with technological improvements. In the meantime, blockchain sizes of other cryptocurrencies are increasing linearly or, in the case of smart contract engines like Ethereum, parabolically. Imagine a cryptocurrency smart contract engine like Ethereum garnering worldwide adoption; how do you think Ethereum’s size would look like in the far future based on the following chart?


https://i.redd.it/k57nimdjmo621.png

Ethereum’s future blockchain size is not looking pretty in terms of sustainable security. Sharding is not a fix for this issue since there still needs to be full nodes but that is a different topic for another time.
It is astonishing that the cryptocurrency community as a whole has passively accepted this forever-expanding-blockchain-size problem as an inescapable fate.
PascalCoin is the only cryptocurrency that has fully escaped the death vortex of forever expanding blockchain size. Its blockchain size wouldn’t exceed 10 GB even after many hundreds of years of worldwide adoption. Ethereum’s blockchain size after hundreds of years of worldwide adoption would make fine comedy.
Part #5: Simple, Short, and Ordinal Addresses
Remember how the SafeBox works by snapshotting all account balances? As it turns out, the account address system is almost as cool as the SafeBox itself.
Imagine yourself in this situation: on a very hot and sunny day, you’re wandering down the street across from your house and ran into a lemonade stand – the old-fashioned kind without any QR code or credit card terminal. The kid across you is selling a lemonade cup for 1 Pascal with a poster outlining the payment address as 5471-55. You flip out your phone and click “Send” with 1 Pascal to the address 5471-55; viola, exactly one second later you’re drinking your lemonade without paying a cent for the transaction fee!
The last thing one wants to do is to figure out how to copy/paste to, say, the following address 1BoatSLRHtKNngkdXEeobR76b53LETtpyT on the spot wouldn’t it? Gone are the obnoxiously long addresses that plague all cryptocurrencies. The days of those unreadable addresses will be long gone – it has to be if blockchain is to innovate itself for the general public. EOS has a similar feature for readable addresses but in a very limited manner in comparison, and nicknames attached to addresses in GUIs don’t count since blockchain-wide compatibility wouldn’t hold.
Not only does PascalCoin has the neat feature of having addresses (called PASAs) that amount to up to 6 or 7 digits, but PascalCoin can also incorporate in-protocol address naming as opposed to GUI address nicknames. Suppose I want to order something from Amazon using Pascal; I simply search the word “Amazon” then the corresponding account number shows up. Pretty neat, right?
The astute reader may gather that PascalCoin’s address system makes it necessary to commoditize addresses, and he/she would be correct. Some view this as a weakness; part #10 later in this segment addresses this incorrect perception.
Part #6: Privacy
As if the above wasn’t enough, here’s another secret that PascalCoin has: it is a full-blown privacy coin. It uses two separate foundations to achieve comprehensive anonymity: in-protocol mixer for transfer amounts and zn-SNARKs for private balances. The former has been implemented and the latter is on the roadmap. Both the 0-confirmation transaction and the negligible transaction fee would make PascalCoin the most scalable privacy coin of any other cryptocurrencies pending the zk-SNARKs implementation.
Part #7: Smart Contracts
Next, PascalCoin will take smart contracts to the next level with a layer-2 overlay consensus system that pioneers sidechains and other smart contract implementations.
In formal terms, this layer-2 architecture will facilitate the transfer of data between PASAs which in turn allows clean enveloping of layer-2 protocols inside layer-1 much in the same way that HTTP lives inside TCP.
To summarize:
· The layer-2 consensus method is separate from the layer-1 Proof-of-Work. This layer-2 consensus method is independent and flexible. A sidechain – based on a single encompassing PASA – could apply Proof-of-Stake (POS), Delegated Proof-of-Stake (DPOS), or Directed Acyclic Graph (DAG) as the consensus system of its choice.
· Such a layer-2 smart contract platform can be written in any languages.
· Layer-2 sidechains will also provide very strong anonymity since funds are all pooled and keys are not used to unlock them.
· This layer-2 architecture is ingenious in which the computation is separate from layer-2 consensus, in effect removing any bottleneck.
· Horizontal scaling exists in this paradigm as there is no interdependence between smart contracts and states are not managed by slow sidechains.
· Speed and scalability are fully independent of PascalCoin.
One would be able to run the entire global financial system on PascalCoin’s infinitely scalable smart contract platform and it would still scale infinitely. In fact, this layer-2 architecture would be exponentially faster than Ethereum even after its sharding is implemented.
All this is the main focus of PascalCoin’s upcoming version 5 in 2019. A whitepaper add-on for this major upgrade will be released in early 2019.
Part #8: RandomHash Algorithm
Surely there must be some tradeoffs to PascalCoin’s impressive capabilities, you might be asking yourself. One might bring up the fact that PascalCoin’s layer-1 is based on Proof-of-Work and is thus susceptible to mining centralization. This would be a fallacy as PascalCoin has pioneered the very first true ASIC, GPU, and dual-mining resistant algorithm known as RandomHash that obliterates anything that is not CPU based and gives all the power back to solo miners.
Here is the official description of RandomHash:
“RandomHash is a high-level cryptographic hash algorithm that combines other well-known hash primitives in a highly serial manner. The distinguishing feature is that calculations for a nonce are dependent on partial calculations of other nonces, selected at random. This allows a serial hasher (CPU) to re-use these partial calculations in subsequent mining saving 50% or more of the work-load. Parallel hashers (GPU) cannot benefit from this optimization since the optimal nonce-set cannot be pre-calculated as it is determined on-the-fly. As a result, parallel hashers (GPU) are required to perform the full workload for every nonce. Also, the algorithm results in 10x memory bloat for a parallel implementation. In addition to its serial nature, it is branch-heavy and recursive making in optimal for CPU-only mining.”
One might be understandably skeptical of any Proof-of-Work algorithm that solves ASIC and GPU centralization once for all because there have been countless proposals being thrown around for various algorithms since the dawn of Bitcoin. Is RandomHash truly the ASIC & GPU killer that it claims to be?
Herman Schoenfeld, the inventor behind RandomHash, described his algorithm in the following:
“RandomHash offers endless ASIC-design breaking surface due to its use of recursion, hash algo selection, memory hardness and random number generation.
For example, changing how round hash selection is made and/or random number generator algo and/or checksum algo and/or their sequencing will totally break an ASIC design. Conceptually if you can significantly change the structure of the output assembly whilst keeping the high-level algorithm as invariant as possible, the ASIC design will necessarily require proportional restructuring. This results from the fact that ASIC designs mirror the ASM of the algorithm rather than the algorithm itself.”
Polyminer1 (pseudonym), one of the members of the PascalCoin core team who developed RHMiner (official software for mining RandomHash), claimed as follows:
“The design of RandomHash is, to my experience, a genuine innovation. I’ve been 30 years in the field. I’ve rarely been surprised by anything. RandomHash was one of my rare surprises. It’s elegant, simple, and achieves resistance in all fronts.”
PascalCoin may have been the first party to achieve the race of what could possibly be described as the “God algorithm” for Proof-of-Work cryptocurrencies. Look no further than one of Monero’s core developers since 2015, Howard Chu. In September 2018, Howard declared that he has found a solution, called RandomJS, to permanently keep ASICs off the network without repetitive algorithm changes. This solution actually closely mirrors RandomHash’s algorithm. Discussing about his algorithm, Howard asserted that “RandomJS is coming at the problem from a direction that nobody else is.”
Link to Howard Chu’s article on RandomJS:
https://www.coindesk.com/one-musicians-creative-solution-to-drive-asics-off-monero
Yet when Herman was asked about Howard’s approach, he responded:
“Yes, looks like it may work although using Javascript was a bit much. They should’ve just used an assembly subset and generated random ASM programs. In a way, RandomHash does this with its repeated use of random mem-transforms during expansion phase.”
In the end, PascalCoin may have successfully implemented the most revolutionary Proof-of-Work algorithm, one that eclipses Howard’s burgeoning vision, to date that almost nobody knows about. To learn more about RandomHash, refer to the following resources:
RandomHash whitepaper:
https://www.pascalcoin.org/storage/whitepapers/RandomHash_Whitepaper.pdf
Technical proposal for RandomHash:
https://github.com/PascalCoin/PascalCoin/blob/mastePIP/PIP-0009.md
Someone might claim that PascalCoin still suffers from mining centralization after RandomHash, and this is somewhat misleading as will be explained in part #10.
Part #9: Fair Distribution and Governance
Not only does PascalCoin rest on superior technology, but it also has its roots in the correct philosophy of decentralized distribution and governance. There was no ICO or pre-mine, and the developer fund exists as a percentage of mining rewards as voted by the community. This developer fund is 100% governed by a decentralized autonomous organization – currently facilitated by the PascalCoin Foundation – that will eventually be transformed into an autonomous smart contract platform. Not only is the developer fund voted upon by the community, but PascalCoin’s development roadmap is also voted upon the community via the Protocol Improvement Proposals (PIPs).
This decentralized governance also serves an important benefit as a powerful deterrent to unseemly fork wars that befall many cryptocurrencies.
Part #10: Common Misconceptions of PascalCoin
“The branding is terrible”
PascalCoin is currently working very hard on its image and is preparing for several branding and marketing initiatives in the short term. For example, two of the core developers of the PascalCoin recently interviewed with the Fox Business Network. A YouTube replay of this interview will be heavily promoted.
Some people object to the name PascalCoin. First, it’s worth noting that PascalCoin is the name of the project while Pascal is the name of the underlying currency. Secondly, Google and YouTube received excessive criticisms back then in the beginning with their name choices. Look at where those companies are nowadays – surely a somewhat similar situation faces PascalCoin until the name’s familiarity percolates into the public.
“The wallet GUI is terrible”
As the team is run by a small yet extremely dedicated developers, multiple priorities can be challenging to juggle. The lack of funding through an ICO or a pre-mine also makes it challenging to accelerate development. The top priority of the core developers is to continue developing full-time on the groundbreaking technology that PascalCoin offers. In the meantime, an updated and user-friendly wallet GUI has been worked upon for some time and will be released in due time. Rome wasn’t built in one day.
“One would need to purchase a PASA in the first place”
This is a complicated topic since PASAs need to be commoditized by the SafeBox’s design, meaning that PASAs cannot be obtained at no charge to prevent systematic abuse. This raises two seemingly valid concerns:
· As a chicken and egg problem, how would one purchase a PASA using Pascal in the first place if one cannot obtain Pascal without a PASA?
· How would the price of PASAs stay low and affordable in the face of significant demand?
With regards to the chicken and egg problem, there are many ways – some finished and some unfinished – to obtain your first PASA as explained on the “Get Started” page on the PascalCoin website:
https://www.pascalcoin.org/get_started
More importantly, however, is the fact that there are few methods that can get your first PASA for free. The team will also release another method soon in which you could obtain your first PASA for free via a single SMS message. This would probably become by far the simplest and the easiest way to obtain your first PASA for free. There will be more new ways to easily obtain your first PASA for free down the road.
What about ensuring the PASA market at large remains inexpensive and affordable following your first (and probably free) PASA acquisition? This would be achieved in two ways:
· Decentralized governance of the PASA economics per the explanation in the FAQ section on the bottom of the PascalCoin website (https://www.pascalcoin.org/)
· Unlimited and free pseudo-PASAs based on layer-2 in the next version release.
“PascalCoin is still centralized after the release of RandomHash”
Did the implementation of RandomHash from version 4 live up to its promise?
The official goals of RandomHash were as follow:
(1) Implement a GPU & ASIC resistant hash algorithm
(2) Eliminate dual mining
The two goals above were achieved by every possible measure.
Yet a mining pool, Nanopool, was able to regain its hash majority after a significant but a temporary dip.
The official conclusion is that, from a probabilistic viewpoint, solo miners are more profitable than pool miners. However, pool mining is enticing for solo miners who 1) have limited hardware as it ensures a steady income instead of highly profitable but probabilistic income via solo mining, and 2) who prefer convenient software and/or GUI.
What is the next step, then? While the barrier of entry for solo miners has successfully been put down, additional work needs to be done. The PascalCoin team and the community are earnestly investigating additional steps to improve mining decentralization with respect to pool mining specifically to add on top of RandomHash’s successful elimination of GPU, ASIC, and dual-mining dominance.
It is likely that the PascalCoin community will promote the following two initiatives in the near future:
(1) Establish a community-driven, nonprofit mining pool with attractive incentives.
(2) Optimize RHMiner, PascalCoin’s official solo mining software, for performance upgrades.
A single pool dominance is likely short lived once more options emerge for individual CPU miners who want to avoid solo mining for whatever reason(s).
Let us use Bitcoin as an example. Bitcoin mining is dominated by ASICs and mining pools but no single pool is – at the time of this writing – even close on obtaining the hash majority. With CPU solo mining being a feasible option in conjunction with ASIC and GPU mining eradication with RandomHash, the future hash rate distribution of PascalCoin would be far more promising than Bitcoin’s hash rate distribution.
PascalCoin is the Unicorn Cryptocurrency
If you’ve read this far, let’s cut straight to the point: PascalCoin IS the unicorn cryptocurrency.
It is worth noting that PascalCoin is still a young cryptocurrency as it was launched at the end of 2016. This means that many features are still work in progress such as zn-SNARKs, smart contracts, and pool decentralization to name few. However, it appears that all of the unicorn criteria are within PascalCoin’s reach once PascalCoin’s technical roadmap is mostly completed.
Based on this expository on PascalCoin’s technology, there is every reason to believe that PascalCoin is the unicorn cryptocurrency. PascalCoin also solves two fundamental blockchain problems beyond the unicorn criteria that were previously considered unsolvable: blockchain size and simple address system. The SafeBox pushes PascalCoin to the forefront of cryptocurrency zeitgeist since it is a superior solution compared to UTXO, Directed Acyclic Graph (DAG), Block Lattice, Tangle, and any other blockchain innovations.


THE UNICORN

Author: Tyler Swob
submitted by Kosass to CryptoCurrency [link] [comments]

What's the f*****ng benefit of the reactivated OP_Codes?

Nobody explained what we can do with the soon to be reactivated OP_Codes for Bitcoin Cash, and nobody explained why we need them. It's a fact that there are risks associated with them, and there is no sufficient testing of these risks by independent developers, nor is there a sufficient explanation why they carry no risk. BitcoinABC developers, explain yourselves, please.
Edit: Instead of calling me a troll, please answer the question. If not, ask someone else.
Edit Edit: tomtomtom7 provided a resfreshing answer on the question:
https://www.reddit.com/btc/comments/7z3ly4/to_the_people_who_thing_we_urgently_need_to_add/dulkmnf/
The OP_Codes were disabled because bugs were found, and worry existed that more bugs could exist.
They are now being re-enabled with these bugs fixed, with sufficient test cases and they will be put through thorough review.
These are missing pieces in the language for which various use cases have been proposed over the years.
The reason to include these, is because all developers from various implementations have agreed that this is a good idea. No objections are raised.
Note that this does not mean that all these OP_Codes will make it in the next hardfork. This is obviously uncertain when testing and reviewing is still being done.
This is not yet the case for OP_GROUP. Some objection and questions have been raised which takes time to discuss and time to come to agreement. IMO this is a very healthy process.
Another good comment is here
https://www.reddit.com/btc/comments/7z49at/whats_the_fng_benefit_of_the_reactivated_op_codes/dullcek/
One precise thing: Allowing more bitwise logical operators can (will) yield smaller scripts, this saves data on the blockchain, the hex code gets smaller.
Here is a detailled answer. I did not goe through it if it is satisfying, but at least it is a very good start, Thank you silverjustice.
But further, if you want specific advantages for some of these, then I recommend you check out the below from the scaling Bitcoin conference:
opcodes are very useful, such as in for example with CAT you can do tree signatures even if you have a very complicated multisig design using CAT you could reduce that size to log(n) size. It would be much more compact. Or with XOR we could do some kind of deterministic random number generator by combining secret values from different parties so that nobody could cheat. They could combine and generate a new random number. If people think-- ... we could use LEFT to make weaker hash. These opcodes were re-enabled in sidechain elements project. It's a sidechain from Bitcoin Core. We can reintroduce these functions to bitcoin.
The other problem are the ... numeric operations which were disabled by Satoshi. There's another problem. Which is that the range of values accepted by script is limited and confused because the CScript.. is processed at ..... bit integers internally. But to these opcodes it's only 32 bits at most. So it's quite confusing. The other problem is that we have this.. it requires 251 encode or calculate or manipulate this number. So we need at least 52 bits. But right now it is only 32 bits. So the proposal is to expand the valid input range to 7 bytes which would allow 56 bits. And it limits the maximum size to 7 bytes so we could have the same size for inputs and outputs. For these operations, we could re-enable them within these safe limits. It would be safe for us to have these functions again.
The other problem is that we currently cannot commit to additional scripts. In the original design of bitcoin, we could have script operations inside of the signature. But the problem is that the signature is not covered by the signature itself. So any script in the scriptSig is modifiable by any third party in the network. For example, if we tried to do a CHECKSIG operation in the signature, people could simply replace it with an OP_0 and invalidate the transaction. This is a bypass of the.. signature check in the scriptSig. But actually this function is really useful, for example, we can do... delegation, people could add additional scripts to a new UTXO without first spending it. So people could do something like let's say to let their son spend their coin within a year if it is not first spent otherwise.. and also, people, talk about replay protection. So we have some ohter new opcode like pushing the blockhash to the stack, with this function we could have replay protection to make sure the transaction is valid only in a specified blockchain.
So the proposal is that in the future the CHECKSIG should have the ability to sign additional script and to execute these scripts. And finally the other problem is that the script has limited access to different parts of the transaction. There is only one type of operation that allowed to investigate different parts of the transaction, which is CHECKSIG and CHECKMULTISIG. But it is very limited. There are sighash limitations here... there are only 6 types of sighash. The advantage of doing this is that it's very compact and could use only one byte to indicate which component to sign. But the problem is that it's inflexible. The meaning of this sighash is set at the beginning and you can't change it. You need a new witness version to have another checksig. And the other problem is that the sighash can be complex and people might make mistakes so Satoshi made this mistake in the sighash design such as the well-known bug in validation time and also the SIGHASH_SINGLE bug. It's not easy to prevent.
The proposal is that we might have the next generation of sighash (sighashv2) to expand to two bytes, allow it to cover different parts of the transaction and allow people to choose which components they would like to sign. This would allow more flexibility and hopefully not overly complicated. But still this is probably not enough for more flexible design.
Another proposal is OP_PUSHTXDATA which pushes the value of different components of a transaction to the stack. It's easy to implement, for example, we could just push the scriptpubkey of the second output to the stack, okay. So it is actually easier to implement. We could do something more than just... because we have sighash, we could check where something is equal to the specified value. But if we could push the value, like the value of an output to the stack, then we could use other operations like more than or less than and then we could do something like checking whether the value of output x must be at least y bitcoin, which is a fixed value.
There are some other useful functions like MAST which would allow for more compact scripts by hiding the other unexecuted branches. There's also aggregation that would allow n-of-n multisig to be reduced to a single signature and so on. In the elements project, they implemented CHECKSIGFROMSTACK where they don't check the transaction structure but instead they verify a message on the stack. So it could be some message like not bitcoin maybe, perhaps cross-chain swap, or another bitcoin UTXO. And also we might have some elliptic curve point addition and operations which are also useful in lightning network design.
Here are some related works in progress. If you are interested in this topic, I would like to encourage you to join our discussions because it's a very active topic. jl2012 bip114 MAST, maaku's MBV, luke-jr or version-1 witness program, Simplicity, etc.
so you have your script template the amount value and there is a block impactor beause we have the sha chain whih allows you to hae the hashes.. we can hae that errortate constant beause you need the HTLC chashes, to properly reoke the prior states and if you an't do that then you can't onstruct the redeem script. Right now it ineeds a signature for eery state, you need all the HTLCs, it needs the netowrk erification state, and there's another cool thing you can do with which is like trap door erification and you can include it in the transaction itself and there can be a alsue where there is some margin for it.. Which make sit powerful, and then you can make it more private with these constructs. We only have a few minutes left, we can cover this.
One furthe rthing is that in the transformation, we have privacy issue because we need to keep going forward, we need to have hte private state, so there's a history of this in the ages in the past, the current one used replications, which was one of the cool things about lightning. We used to have deckman signatures we had a sequence value of like 30 days, we did an update, we had to switch sides then we make it 29 then 27 etc. You can only broadcast the most recent state because otherwise the other party can transact the other transaction. If you start with 30 days then you can only do about 30 bidirectiona lswitches. Then there was cdecker's payment channels where you have a root tree and every time you need to- you had two payment channels, you had to rebalance htem and then it's on your part of the channel you can reset the channel state. You can do 30 this way, you have another tree, you can do it that way, and then there's a new version of it in the indefinite lifetime... by keeping the transaction in CSV, the drawback on that paproahc because you have al arge validation tree, in the worst cas eyou have 8 or 10 on the tree, and then you nee dfor the prior state and then you do the 12 per day, and every time you have to make a state, you have to revoke the preimage from the prior state, this is cool because if they ever broadcast the entire state, eahc one has the caluse so that you can draw the entire money in the event o f a violation. There are some limitations for doing more complex verifications and you have this log(n) state that you have to deal with ehen you deal with that.
We're going to do the key power on the stack to limit key verifications on this main contract. this is all composable. You can do discreet log contracts. You can now check signtures on arbitrary messages. You can sign a message nad then we can enforce structure on the messages themselves. Right now you need to have sequene numbers. So each state we are going to increment the sequence numbers. So you give me a siequence number on that state. On the touputs we have a commitment ot the sequence number and the value r. So people on chain will know that how many places we did in that itself. The ool part about this is that because we have a seq number then I have the one if it's highest neough. Then I am opening that commitment to say this is state 5 and I present to you a new signed ommitment and open that as well, that's in a validation state. The cool things is that you only need one of those m. So we have to some auxiliary state, and each time I have a new state I an drop the old state. I have a signed commitment to revoke the prior state. This is a ibg deal beause the state is much smaller. Currently we require you to fwe use a state mahcine on state 2, and it also has implications for verifications and watch tower
So on lightning, there's this technique itself- it's timelocks CSV value and if you can't react within that value then you can't go to court and enforce judgement on this attacker. So the watchtower is a requirement, you delegate the state watching to the watchtower. They know which channels you're watching. You send some initial points, like a script template. For every one you send the signautre and the verification state. They can use the verification stat ethat collapses into a log(n) tree, you can basically use state where you send half the txids, you can decrypt this in... some time.
submitted by Der_Bergmann to btc [link] [comments]

Blockchain Dictionary for Newbies

Blockchain Glossary: From A-Z
51% Attack
When more than half of the computing power of a cryptocurrency network is controlled by a single entity or group, this entity or group may issue conflicting transactions to harm the network, should they have the malicious intent to do so.
Address
Cryptocurrency addresses are used to send or receive transactions on the network. An address usually presents itself as a string of alphanumeric characters.
ASIC
Short form for ‘Application Specific Integrated Circuit’. Often compared to GPUs, ASICs are specially made for mining and may offer significant power savings.
Bitcoin
Bitcoin is the first decentralised, open source cryptocurrency that runs on a global peer to peer network, without the need for middlemen and a centralised issuer.
Block
Blocks are packages of data that carry permanently recorded data on the blockchain network.
Blockchain
A blockchain is a shared ledger where transactions are permanently recorded by appending blocks. The blockchain serves as a historical record of all transactions that ever occurred, from the genesis block to the latest block, hence the name blockchain.
Block Explorer
Block explorer is an online tool to view all transactions, past and current, on the blockchain. They provide useful information such as network hash rate and transaction growth.
Block Height
The number of blocks connected on the blockchain.
Block Reward
A form of incentive for the miner who successfully calculated the hash in a block during mining. Verification of transactions on the blockchain generates new coins in the process, and the miner is rewarded a portion of those.
Central Ledger
A ledger maintained by a central agency.
Confirmation
The successful act of hashing a transaction and adding it to the blockchain.
Consensus
Consensus is achieved when all participants of the network agree on the validity of the transactions, ensuring that the ledgers are exact copies of each other.
Cryptocurrency
Also known as tokens, cryptocurrencies are representations of digital assets.
Cryptographic Hash Function
Cryptographic hashes produce a fixed-size and unique hash value from variable-size transaction input. The SHA-256 computational algorithm is an example of a cryptographic hash.
Dapp
A decentralised application (Dapp) is an application that is open source, operates autonomously, has its data stored on a blockchain, incentivised in the form of cryptographic tokens and operates on a protocol that shows proof of value.
DAO
Decentralised Autonomous Organizations can be thought of as corporations that run without any human intervention and surrender all forms of control to an incorruptible set of business rules.
Distributed Ledger
Distributed ledgers are ledgers in which data is stored across a network of decentralized nodes. A distributed ledger does not have to have its own currency and may be permissioned and private.
Distributed Network
A type of network where processing power and data are spread over the nodes rather than having a centralised data centre.
Difficulty
This refers to how easily a data block of transaction information can be mined successfully.
Digital Signature
A digital code generated by public key encryption that is attached to an electronically transmitted document to verify its contents and the sender’s identity.
Double Spending
Double spending occurs when a sum of money is spent more than once.
Ethereum
Ethereum is a blockchain-based decentralised platform for apps that run smart contracts, and is aimed at solving issues associated with censorship, fraud and third party interference.
EVM
The Ethereum Virtual Machine (EVM) is a Turing complete virtual machine that allows anyone to execute arbitrary EVM Byte Code. Every Ethereum node runs on the EVM to maintain consensus across the blockchain.
Fork
Forks create an alternate version of the blockchain, leaving two blockchains to run simultaneously on different parts of the network.
Genesis Block
The first or first few blocks of a blockchain.
Hard Fork
A type of fork that renders previously invalid transactions valid, and vice versa. This type of fork requires all nodes and users to upgrade to the latest version of the protocol software.
Hash
The act of performing a hash function on the output data. This is used for confirming coin transactions.
Hash Rate
Measurement of performance for the mining rig is expressed in hashes per second.
Hybrid PoS/PoW
A hybrid PoS/PoW allows for both Proof of Stake and Proof of Work as consensus distribution algorithms on the network. In this method, a balance between miners and voters (holders) may be achieved, creating a system of community-based governance by both insiders (holders) and outsiders (miners).
Mining
Mining is the act of validating blockchain transactions. The necessity of validation warrants an incentive for the miners, usually in the form of coins. In this cryptocurrency boom, mining can be a lucrative business when done properly. By choosing the most efficient and suitable hardware and mining target, mining can produce a stable form of passive income.
Multi-Signature
Multi-signature addresses provide an added layer of security by requiring more than one key to authorize a transaction.
Node
A copy of the ledger operated by a participant of the blockchain network.
Oracles
Oracles work as a bridge between the real world and the blockchain by providing data to the smart contracts.
Peer to Peer
Peer to Peer (P2P) refers to the decentralized interactions between two parties or more in a highly-interconnected network. Participants of a P2P network deal directly with each other through a single mediation point.
Public Address
A public address is the cryptographic hash of a public key. They act as email addresses that can be published anywhere, unlike private keys.
Private Key
A private key is a string of data that allows you to access the tokens in a specific wallet. They act as passwords that are kept hidden from anyone but the owner of the address.
Proof of Stake
A consensus distribution algorithm that rewards earnings based on the number of coins you own or hold. The more you invest in the coin, the more you gain by mining with this protocol.
Proof of Work
A consensus distribution algorithm that requires an active role in mining data blocks, often consuming resources, such as electricity. The more ‘work’ you do or the more computational power you provide, the more coins you are rewarded with.
Scrypt
Scrypt is a type of cryptographic algorithm and is used by Litecoin. Compared to SHA256, this is quicker as it does not use up as much processing time.
SHA-256
SHA-256 is a cryptographic algorithm used by cryptocurrencies such as Bitcoin. However, it uses a lot of computing power and processing time, forcing miners to form mining pools to capture gains.
Smart Contracts
Smart contracts encode business rules in a programmable language onto the blockchain and are enforced by the participants of the network.
Soft Fork
A soft fork differs from a hard fork in that only previously valid transactions are made invalid. Since old nodes recognize the new blocks as valid, a soft fork is essentially backward-compatible. This type of fork requires most miners upgrading in order to enforce, while a hard fork requires all nodes to agree on the new version.
Solidity
Solidity is Ethereum’s programming language for developing smart contracts.
Testnet
A test blockchain used by developers to prevent expending assets on the main chain.
Transaction Block
A collection of transactions gathered into a block that can then be hashed and added to the blockchain.
Transaction Fee
All cryptocurrency transactions involve a small transaction fee. These transaction fees add up to account for the block reward that a miner receives when he successfully processes a block.
Turing Complete
Turing complete refers to the ability of a machine to perform calculations that any other programmable computer is capable of. An example of this is the Ethereum Virtual Machine (EVM).
Wallet
A file that houses private keys. It usually contains a software client which allows access to view and create transactions on a specific blockchain that the wallet is designed for.
submitted by Tokenberry to NewbieZone [link] [comments]

Thoughts on scaling with larger blocks and universal blockchain pruning

While Bitcoin Core is experimenting with payment channels that will use the blockchain as a trusted intermediary to open and close channels, with a throughput theoretically limited only by latency (if it works at all), the scaling solution chosen by the Bitcoin Cash community is increasingly larger blocks to track demand and scale as the network grows. That, however, creates new problems.
The first problem is block propagation. Every time a node wins the proof-of-work race, it has to broadcast it's block for validation and acceptance by the other nodes, which in practical terms involves uploading files through the p2p network. Larger blocks, therefore, would result in larger files to upload, and a block size limit is defined by the mean/median network bandwidth.
If I remember correctly, the "compact blocks" implementation used by both Bitcoin Core and Cash can handle up to 98% compression, which is great and allows for a tremendous increase in block size without fear of clogging up the network, but a scalable future-proof payment system must be able to theoretically handle millions of transactions per second, which would require a bandwidth measured in the Gbps.
The solution to this problem, instead of hoping that Gbps connections will be commonplace by then, is improving the compression algorithms. One such improved algorithm is Graphene, which can handle up to 99.8% compression, requiring a bandwidth measured in Mbps for a throughput in the millions tx/s.
The second problem, and perhaps the most discussed one regarding future centralization problems with Bitcoin Cash, is the storage size of the blockchain. While it sits at around 160GB right now, with increased demand and larger blocks comes an exponential increase in the blockchain database size.
One million tx/s (i.e. 600 million transactions per 10-minute block), averaging 250 bytes per transaction, would result in 150GB blocks, and an increase of around 7800TB in required storage per year. This is hardly possible for most nodes, even with the expected Moore's Law increase in consumer grade SSD, unless we experience some technological breakthrough allowing seemingly endless storage capacity. Once again, this is not something we should expect to happen, but rather work around it to ensure a continued decentralization of full nodes on the network.
One solution to this problem is "pruning" the blockchain, as a means to ditch spent outputs from the blockchain and only keep the unspent ones. However, this is only a solution to lightweight/pruned nodes (which don't relay previous blocks or Merkle paths) since it's impossible to actually prune the blockchain, because any change in past blocks will require a change in the subsequent blocks, and the new pruned blockchain would only be valid if we employed a massive amount of computational power to solve the proof-of-work puzzles of each individual block since Genesis. Hardly an easy solution.
A work-around to mining the pruned blocks would be to hard fork the network to allow for a completely invalid blockchain up to the "pruning block", from where valid blocks would continue to be built on top of. This has numerous problems, but the biggest might just be that the community will never allow for nearly 10 years worth of blocks to suddenly go invalid for the sake of scaling, and thus the hard fork would never gain traction.
EDIT: In reality, nodes running with a pruned blockchain keep track of the UTXO set (i.e. every unspent transaction outputs and their associated public keys) and erase every transaction up to a certain amount of blocks, keeping only the block headers (including the merkle root) and the merkle branches. This allows for any participant to request the merkle path to a certain transaction and locally verify it's authenticity without downloading the actual blocks. However, there are situations where one must validate the blocks themselves instead of trusting the nodes it's connected to, and since each block references a block which you can't expect to be valid without checking, one ends up needing to validate every previous blocks until all coinbase transactions are accounted for, or even all the way back to the Genesis block, so it's very important that there exists full nodes running the blockchain in it's entirety.
I propose a solution to this problem with a "net settlement hard fork" that would consolidate the complete UTXO set in the blockchain and render the previous blocks unnecessary to ensure the security of the system.
On a predetermined block, similarly to how the reward halvings are scheduled, a special block would be mined, which I'll refer to as Exodus (actually, Exodus#1, as more of these special blocks would have to be mined from time to time). This block would contain "net settlement" transactions of all unspent outputs back to their rightful public keys. For example, the wallet that received the first coinbase transaction ever, likely belonging to Satoshi Nakamoto (1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa), has 1297 unspent outputs as of now, most of which are donations intended for Satoshi. On the Exodus block, all these outputs would be combined and sent back to that wallet as one net settled transaction of 66.87633136 BTC. Since every valid transaction requires a signature from the private key holder, these transactions would all be considered invalid on any other block except Exodus, the special block where the community has agreed to overlook this lack of signatures.
In order to prevent malicious actors from trying to steal some of the outputs from other people or even create new outputs and send them to themselves, the hard fork would be programmed far in advance, so all miners can create their own [identical] Exodus block independently, incentivized to do so because of the expected regular block reward (block_reward) and the Exodus block reward calculated by adding every individual transaction size (tx_size_i) and multiplying by some agreed upon maximum transaction fee (max_tx_fee). Therefore, the total coinbase reward for mining that block would be block_reward + max_tx_fee * Σtx_size_i.
This block would have an unlimited size, and define the end of the "first blockchain era", from Genesis to Exodus, which can be kept by anyone who chooses to do so. Since Exodus contains all the net settled transactions from the historical blockchain, full nodes aren't required to keep any previous blocks in their entirety to ensure transaction validity, effectively ditching several GB/TB of required storage.
Every new transaction referencing the old blockchain would need to be rejected, until every wallet is fully synced and starts to reference the Exodus transactions instead, which shouldn't take long, but I might be understating how disruptive this could be. Subsequent blocks could have their maximum block sizes automatically adjusted similarly to how mining difficulty is adjusted now, without worrying over the database size. New "net settlement hard forks" would have to be performed periodically to ensure a limit to the blockchain size, similarly to how Monero ensure periodic upgrades to their protocol (it hard forks every 6 months).
This would ensure that throughput can increase as needed, and the database would be regularly pruned to ensure proper decentralization of full nodes.
Feel free to criticize the idea, and perhaps point me to better scaling solutions that I might be overlooking.
submitted by ViaLogica to btc [link] [comments]

Why the Lightning Network will not work (and how to abuse it)

The following is a list of problems we must overcome before the The Lightning Network has a chance to succeed:

1. The penalty risk you take for broadcasting old contracts decreases as your channel balance approaches zero.

When you have no balance left in the channel you take no risk for trying to broadcast old contacts. You can’t lose more then what you have in the channel.

2. Too many invalid contracts for anyone to handle

Each new transaction will reveal the two keys to invalidate the previous contract/state. The amount of invalid contracts (contracts able to fraud someone) will increase with the number of transactions. Sending money from A to B with 10 hops will create 10 * 2 new invalid contracts. Remember this technology was designed to handle microtransactions and to solve the blockchain scaling issue. So what happens when this network scales to 56000 transactions per second (same as VISA max capacity). If we set the average number of hops to 10 - The network will generate 56000 * 10 * 2 (a million!) invalid contracts per second.
I know for Lightning Network to be successful users should not have to rely on themselves always being online to check the blockchain for fraud attempts.
Instead users will send all invalid contracts to a public registry attached with a bounty reward to the one catching the thief.
This public registry of invalid contracts will grow with a million entries per second! And at this rate we are not even better than VISA.
And how do we decentralize the list of old contracts? Remember this is about trust, having to trust a centralized server to do this job will be to vulnerable. Hacking this server will give you a perfect time to broadcast old beneficial states to the blockchain.
How about sending old bounty rewarded contracts to the P2P network? A million invalid contracts per second??? We’re now back at where we started. If nodes could handle this amount of data we should just remove the block size limit entirely.

3. The risk of getting caught VS how much is a succeeded fraud attempt worth?

Simply put, people will not be honest in this network. Fraud attempts will occur all the time when they statistically favours someone.
Let’s say we have a solution for the bounty reward registry (read problem #2).
There is nothing stopping you from using the public registry to see if your counterpart have published your contracts. If you can’t find them, they are either published in a private registry or not published at all (trusting themself to always be online).
From this information you first calculate the risk of getting caught based on if you can find the contract in the public registry or not.
Let’s say you cannot find your contract in any public registry - knowing this will give you a 1% chance to get away with the fraud (real numbers will be used once they are official).
Let’s say your current channel balance is: You: 0.001 BTC Him: 1.999 BTC
Going back to the initial state where both started at 1 BTC will give you 0.999 BTC if the froud would succeed. And this is while only risking 0.001 BTC if you get caught (which we calculated to be 99% of the time). What would you do? I’m definitely going for the fraud.
It’s not about cheating, every contract signed is real. Getting away with broadcasting old contracts is not like stealing. You have signed a contract giving him the right to do so! And he will succeed if someone is not paying attention! If this happens you have only yourself to blame.
What people don’t seem to understand is that you have to monitor your entire transaction history in the Lightning Network, even tiny microtransactions only routing thro you. If your plan is to use the channel for 1 year you will have a lot of transactions to monitor! Missing to monitor just one microtransaction can rollback your entire channel balance to the time when that microtransaction was handled.

4. High transaction fees.

Being involved in the routing is taking a risk, each transaction your involved in invalidates yet another contract someone constantly have to monitor. This is not a risk someone will take for free. The fee will NOT be a percentage of the transferred money. Hubs are taking the same risk regardless of money transferred. Even the smallest micropayment will generate an invalid contract capable of rollbacking the entire channel if not stored and monitored correctly!

5. Transactions on LN will not be private.

For the bounty reward registry to work (read problem #2) every transaction has to be public. Even if you don't publish your contracts - your channel counterpart might.

6. All open channels will at some point get stuck, when this happens your money is essentially gone.

This is also known as the fixed fee problem. When you open a channel you have to decide beforehand on what the blockchain fee should be when you at some point in the future wants to close the channel (by broadcasting the signed contract to the blockchain). We all know that the fees needed to get a transaction into the blockchain constantly rising.
This is a big problem. What it basically means is that there are always some point in the future where your fee is to low and your channel will get stuck. You can no longer close the channel.
You can try to, but it will never be included in the blockchain. The funny thing is that you can’t even rise the fee to help it through. Your only hope will be to ask your channel counterpart to sign a new contract with higher closing fee. Let’s say you have 1 BTC in the channel and your counterpart has 0 BTC. Do you expect him to help you for free? If I ended up in a situation like that I would help him close the channel for about 0.5 BTC. No less.

7. False security

The Lightning Network will at launch seem to work perfectly, this is an illusion building on false security. Why it works is because it will take some time until people learn how to fraud. It should be dead simple to broadcast old contracts. Every user must know how to do it. You should click on a channel, scroll to any previous transaction and click on the “Start Fraud Attempt” button. Until the fraud is this easy the security lies on people not knowing how to do it yet.
This is important, so if I have any developer reading this, planning to build a Lightening Wallet. Please include the “Start Fraud Attempt” button. If the Lightening Network is secure it should be secure even with that button right in front of every user!

8. The Lightning Network is already running on the bitcoin main net. Do you want their money? This is how you do.

You start two nodes. Send all your cash from one node to the other. Making yourself broke on one channel. This way you take 0 risk broadcasting the empty channels initial state to the blockchain :)
But watch your back! Your receiving node can as easy lose the money again if your not paying attension to the blockchain!
You might get the feeling after reading all this that I don’t want Lightning Network to succeed. That's not true. I want it to succeed. I want crypto to be the future. That's why I’m trying my best to break it.
submitted by drvnoo to Bitcoin [link] [comments]

Answers to common questions about Ethereum (FAQ)

I'll try my best to answer some of the most common questions that I've seen around regarding Ethereum, if you've got any questions that I haven't covered here, feel free to ask in comments.
To protect the network again spam, without transaction fees one could effectively DoS attack the network by sending 0 Ethers to himself infinite times. Transaction fees is effectively DDoS protection as it would cost massive amounts of money to spam the network.
No, not really; for transfering Ether between normal wallets it can (usually 21000). However, for interacting with Smart Contracts it's impossible to know due to the famous Halting Problem. You can never know in advance whether a contract code could loop indefinitely; if it does you can lose your entire balance of Ethers without an upper limit specified (and loop whatever machine is attempting to mine the transaction). Gas Limit is effectively a safe-guard against infinite loops, without an upper limit an infinite amount of Ethers would be consumed as a fee for an infinite duration of time if a contract loops.
ERC20 tokens are "assigned" to wallets by their respective Smart Contracts. You do not "hold" your tokens as you do your Ethers; instead Token Trackers keep a track of all ERC20 transactions and know which wallet owns how many. Therefore, to move your ERC20 between wallets, you need to request their respective Smart Contract to do it for you (because only that contract can actually move them around). Additionally, you can approve other wallets (usually smart contracts belonging to decentralized exchanges) to access a specific portion of your tokens on your behalf. ERC20 tokens can only be moved on behalf of their owner address or approved addresses (up to the authorized amount).
Transactions are mined in numerical order, Nonce of each transaction is its position among the rest. For example, the 6th outgoing transaction from your wallet will be Nonce = 6. Sending a transaction with a Nonce lower than what's already confirmed will result in an Invalid transaction while sending one with a Nonce higher than what's already confirmed will result in that tranasction being stuck until every other transaction before it (lower nonces) are already confirmed.
Mined transactions that are confirmed can never be reversed under any circumstance. If you have sent Ethers or Tokens to the wrong address, they are permanently lost and there is no way to recover them. However, as long as a transaction is still Pending, you may be able to replace or overwrite it by sending another transaction with the same Nonce and (a much) higher Gas Price.
An invalid transaction would eventually get discarded and will never be mined/confirmed. However, interactions with Smart Contracts could end abruptly (you run out of gas to perform the processing) or have unexpected results (infinite loop, etc.). In such cases, the result would be a Failed transaction which still has to be mined and confirmed. Therefore Failed transactions still consume gas/fees while invalid transactions just get discarded (eventually). An example of an Invalid transaction would be one where the signature doesn't match the request (has been tampered with).
Resend that exact same transaction with the same Nonce and a higher Gas Price. Be careful not to confuse Gas Price with Gas Limit, setting them in reverse woud likely result in you losing massive amounts of Ether.
Transactions have to be confirmed in the order they were sent. If you have a pending transaction with a lower Nonce and Gas Price, new tranasctions (regardless of their Gas Price) cannot get confirmed until the previous one is. If you have a stuck transaction, sending new ones with higher Gas Price would only make things worse.
Currently, there's no direct way of scheduling transactions via your wallet. Additionally, there is no way to 100% accurately predict how long it will take for a transaction to be confirmed. But usually, if you pay a high enough Gas Price, there's a very good chance it would be confirmed quickly.
Ethers can be mined directly to a wallet, or be transferred to it via a Smart Contract called by a different address. For instance, a wallet could call the smart contract with a function that would result in Ether(s) being transferred to a different address. With token transfers, all such transactions would usually be visible on the Token Tracker. However, with direct Ether transfers, you would need to find the transaction on the history of the wallet that sent it to the Smart Contract (which then sent Ethers to a different wallet as a result).
1 GWei = 0.000000001 Ethers, either memorize that or remember that 109 GWeis make up one Ether. G is unit prefix: Giga. For the time being, it's easier to type 5 than 0.000000005.
If it was a personal wallet, simply use the private key of your ETC wallet as an ETH wallet as they're functionally the same thing. If it was an exchange, you would have to contact their support and hope they would help you out. The same Ethereum wallet can hold both ETH and ETC at the same time (although each is tracked on separate networks).
Explain how you did that first because it should be impossible. Bitcoin and Ethereum have different address structures, a Bitcoin wallet is not a valid Ethereum address. Actually being able to pull this off would likely result in an Invalid transaction.
Most common reasons for Failed transactions during ICOs are: ICO has already ended (and no longer accepts new payments); Only payments from whitelisted addresses are accepted (but you're not whitelisted); Smart Contract is Paused (most tokens are locked and cannot be transferred while ICO is active); or your Gas Limit was too low (and you ran out of gas).
submitted by R3TR1X to CryptoCurrency [link] [comments]

I'm a long time lurker wanting to make a first ever Bitcoin purchase in Peru. Please, help me find the best method (that is an option for me) to do so as soon as possible (Don't worry about the lenght of the post, there's a sort of TL;DR version explained in the first paragraph).

Good whatever it is wherever you guys are. I tried posting in BitcoinBeginners but for some reason several hours have passed and it has not being approved, the mods don't respond so I thought maybe try out here, pardon if it's a little bit out of place. Anyhow, I need your help to make my first bitcoin purchase and so I have extensevely wrote about my specific situation, in order to get the TL;DR version just jump trhough the texts to where BOLD letters are used followed by the main points of what I wrote and where I straight-fowardly asks the questions I need asnwers to, which will be in ITALIC, the rest is only if you were to need more information as to provide me with a more complete asnwer.
I'm currently in Lima, Peru and want to buy the equivalent of PEN 10,000.00 (which is roughtly US$ 3,100) in Bitcoins. I have around half of that in US$ on a bank account/VISA debit card and the other half I would take it in PEN from another bank account/other VISA debit card. I don't mind either way and can exchange either currency for the other but I guess I would prefer to buy the Bitcoins fully in dollars if I were to do the transaction with a person (making it so quite likely just one currency accepted to avoid extra hassle) given that the value of the dollar here right now is relatively low. And as far as I can tell there are three methods avalible which would be fitting in my situation, those being using cash on a ATM Bitcoin Machine, either a cash face-to-face exchange/a cash deposit to the bank account of a reputable user on Mycelium/LocalBitcoins, or contactintg someone who offers a better price through one of the national Bitcoin Facebook/Meetup groups and trying to get that person to agreed on doing the exchange using LocalBitcoins because of their escrow sytem and general reliability when handling disputes as a sort of guarantee for the both of us.
Up until now I never had my identity formally linked in any way with cryptocurrencies and very much would like it to stay that way, meaning that annonymity is number one priority to me regarding this subject. I do not want anyboby being able to demostrate I bought/owned Bitcoins, need to be sure that my current purchase won't in any way affect any possible future trade for other crytocurrency such a Monero using XMR.to and then maybe on another exchange like Kraken back to Bitcoin or the use of a tumbler like Bitcoin Fog as I don't want anybody to have some prove that I used them to buy a Baby Jesus Butt Plug from a Darknet Market. Having that aspect completly covered my second requirement to proceed is that the way I end up going about it doesn't hinged my safety from theft, whether I eventually put the coins on a personal wallet like Ledger Nano S with U2F or a hardware wallet like Electrum on a USB with TAILS, I need confirmation that, say, having them first just on the Mycelium/LocalBitcoins wallet (even maybe without 2FA if tablets can't be used for that) after buying them from someone won't put them on danger. And lastly, I want a good deal.
I also sort of need however I were to do this now to be reasonably easy and fast with the tools of my disposal at the moment (no phone, only several laptops and an Android tablet) so as to not requiring me to wait more to feel like I have the correct OPSEC/setup in order to finally get into Bitcoin. Having been involved with cryptocurrencies for a over 7 years and never having actually bought any, the last thing I want is to once again tell myself any excuse so as to keep procastinating with it, much less right now with the current decrease in price. After this 'investment', in the next couple of months I will keep on adding some more and probably want to sell some of it too in order to gather some experience and also it is of my interest to purchase pretty large quantities of various specific research chemicals, which even though are completly legal in my country to own, I do not think I have to explain why I would want to keep such activity as realistically untraceable as possible. I am deeply informed on the legal aspect, but regardless, just because I am completly prepared for any particular inconvenience doesn't mean that I would want to find myself inconvenienced.
So just to sum up:
Apart from all the awfully set up bitcoin exchange websites which don't provide any reason to trust them there seems to be few different ways of obtaining bitcoins here, but given that I have a set of prerequisites the list of options get shortened. As privacy is key I am conditioned to buy the coins in a such way that doesn't ask from me any sort of idendity verification that could formally link me to it or can leave a loose end, so that would leave out purchasing the coins interntionally or using my debid cards/bank accounts nor any online payment, but rather using cash face-to-face exchange/a cash deposit to a bank account. A perfect solution seems to be the only Bitcoin ATM Machine in my country which according to this website is a General Bytes model called BATMTwo of a very simple system, just like it can be seeing in several videos on Youtube, in which the sole authenticaton is by scanning a QR code from the app of my Bitocin wallet (or even just the QR code printed), it doesn't require an ID, fingerprint and the machine doesn't even have a camera. Sadly, I contacted the owner of the machine and so it seems the service is currently suspended. Out of the remaininng posibilities I have a couple of constant doubts which I need to resolve in order to know what is more convenient and what steps to follow.
Of the methods I will list I need to know:
MYCELIUM
-Process: Create wallet on the Mycelium app in my tablet, choose a vendor, negociate and set up a price which will be respected as it was established when the transaccion is first submitted, pay in cash, get the bitcoins transfered to my wallet and seller will receive the key of our transaction which I will need to have on me at the moment to confirm the exchange has being completed.
-Prices: Wheter they accep either cash or bank deposists is not specified, but from what I have read everyone should accept cash. At the moment there's literally three accounts selling in my city, and it appears none of them have a reputation as none of them have ever made a sell or purchase... not very trustworthy.
Mycelium's feature "Local Trader", from the get go doesn't inspire me much confidence as it is an App, and I'm not very well versed in how to stay anonymous using mobile devices other than laptops, from what to have installed in them to how to protect myself from the dangers of public wi-fi. The reason why I even consider a method which I don't feel quite confortable with is that as far as I comprehend I can pay with cash on a face-to-face exchange or a cash deposit to a bank account, the only two methods I have understood would be adequate for me, that the prices I have found are drastically better than those on LocalBitcoins and they can even be negociated, plus it works instantly and is wildly considered to be secure. Now, while the process doesn't provide escrow, "the seller does not need to put funds into escrow; they are spent directly from his Mycelium Wallet" which is advertised as a positive characteristic that I can't see how it would benefit me (the buyer), nor am I sure what it even means. An finally while I do know that apart from the agreed price a 0.2% fee goes to the app I don't know if that means it would be taken from the already made transacction or if it is an extra expense charged to me, plus it doesn't seem to be a way of setting the exchange rate at the moment of agreeing on the trade rather than letting the value fluctuate until our meeting and getting fucked, or am I in the wrong?
LOCALBITCOINS
- Process: Create wallet on the LocalBitcoins website, choose a vendor, ask him/her to check the correct 'Floating Price' set so as to establish the price of the exchange at that moment, the escrow will hold the funds, pay in cash, get the bitcoins transfered to my wallet and seller will receive the key of our transaction which I will need to have on me at the moment to confirm the exchange has being completed.
- Prices: This interface is much more clear and specific, however the lowest prices are way beyond anything that I could of have expected... let alone those of the three sellers who accept cash. That being said, almost all of the reputations are of absolute excelence and some with high quantity of transacciones, of course that was to be expected given that those who sell in my country are few people, and everyone would be turning up to them.
Given that the ATM machine is currently not operating, from what my limited knowledge indicates, LocalBitcoins should be my prefered course of action, that is if all the prices listed in my country weren't insanely high. If I'm not mistaking the value listed by the seller is no open for discussion but there is also no side fee I have to take into consideration, being so that what is listed is what I will have to pay. An while once again price is a problem with this method, there are sellers who will accept either a face-to-face exchange or a cash deposit to a bank account, only problem being that those are precily the ones who provide the worst exchange rates. Because of their escrow system so long as the two of us comply with the meeting pretty much once the transaccion is set up the funds of the seller have being 'separated' and is in the best interest of both for the purchase to take place. But, one thing I don't have clear is regarding the 'Floating Price' checkbox, the way I see it, and this is very important to me, I want the price of the bitcoins I'm buying to be determined at the time the trade is first submitted, that way actively choosing what exchange rate we will deal with, AND NOT when the coins are released, as if that were the case the price could change leaving me with a deal out of my control. So can this be indicated by me (the buyer), or is it up to the seller because (s)he's the only one capable of controlling that option?, and, if I were to ask him/her to set it up, should I ask to turn that option on or off? (I don't know what way would be the correct).
TO CONCLUDE:
Another option I have to avoid the exchange rates I have shown you is to contact someone who offers a better price through one of the national Bitcoin Facebook/Meetup groups and trying to get that person to agreed on doing the exchange using LocalBitcoins because of their escrow sytem and general reliability when handling disputes as a sort of guarantee for the both of us, as I indicate at the very begining of the post. Cosntantly on the Facebook groups there's users posting about wanting to sell Bitcoins for a much lower price that in Mycelium and LocalBitcoins, some even below market value for X reason, and although of course going fully private without any exchange platform would be too dangerous, not only can I suggest to use one but I can find those persons who are of high reputation in the Bitcoin comunity in my country and are deeply involved in bringing this technology here and ask those people if they happen to be selling Bitcoins. In order to do so I would need to look trough several pages of posts in this groups, use some Google-fu to find out who are the ones who arrange the Meetups and other reunions about Bitcoins. Tedious, but a possibility nonetheless. If you guys happen to know of someone like that in my country maybe poitning me in that direction could be very helpful.
Beyond that all I have left if the exchange platforms indicated in this and this pages, but I have to say I already spent all afeternoon visiting each website and App reading about the steps to purchase Bitcoins in each of them and not only are cash face-to-face really not given as options in any but some are simply confusing or seem like a bad idea. Not to metion a couple even supposedly offer under market value pricing, but just in case if anyone had anything positive to say about them, here are the ones that aren't just obsolite links: CEX.IO, SatoshiTango, Bitex, Paxful, 247Exchange, Xapo, bitINKA, SurBTC, Circle, CambistaBitcoin and the listing for Bitcoin of the South American version of Ebay, MercadoLibre. By the way, I have said that privacy is very important to me, but I have also being extremely descriptive of what I'm doing and plan to do, so just in case anyone is wondering not only am I posting this from an IP address not related to me but also nothing that I have wrote is incriminating in any way, constitutes a crime or make so that I can be persecuted for it, and even if under any strange circunstances I had to, I havethe equivaent of what american refeer to as plausible deniability to defend myself given that all of this can be of course considered hypothetic. Just thought I would put it there.
Thank you very much for reading and I hope someone can help me, I would greatly appreciate it.
submitted by MellamoAlejandro to Bitcoin [link] [comments]

Blockchain to fix horribly broken e-mail system like it is today?

E-mail as it is, is horribly broken. Horrendously broken.
It wasn't that many years ago that you could be assured your e-mail reaches whoever you were mailing to. Today it is a mere suggestion, that perhaps this should be delivered to this person, at least for any automated e-mail. This seems to be creeping to manual, organic email as well. Hell, we are seeing even internal e-mails being flagged by spamassassin as spam, organic, human written conversations! In that instance, the spamassassin is also maintained by one of the largest hosting providers in the world...
Hotmail/MS services has been for years (atleast about 4 years now!) been silently dropping email, not all, but some. There's a bit of relief lately, as they have started to favor a bit more marking as spam, rather than silently dropping.
I know, most email users don't see this problem, but those who use email a lot to do their work, and those who need to send automated emails (say, welcome e-mails for a service) this is a big problem. (Disclaimer, for us, our niche of hosting probably causes flagging as well. Our site is blocked by many corporate firewalls for example)
Blockchain to the rescue?
This is an idea i've been toying around with a few years. What if any single e-mail would cost a faction of a cent, and who receives the e-mail, gets paid for it? Now that would solve a lot of problems. I realize there has been some half assed attempts on blockchain based e-mail, but they are about replacing email (never going to happen). Using blockchain to enhance the current experience, with least minimal friction should be the goal, not re-inventing the wheel.
Imagine a say 0.01 cent (0.0001 USD) cost per e-mail. This price would not be cost prohibitive even for free e-mail service providers (Ad revenue etc. should exceed this value), never mind any legit e-mail users. Especially considering you get paid for receiving. So all legit e-mail services would work rather well regardless of the cost. (never mind free email service could profit from this)
Spam however? To send 1 million emails you would need to pay 100$. How many spammers would continue doing so? At least it makes things much harder, not so easy to use a botnet to send your email when you need to include your private key(s) to the botnet, or make some kind of private key management system, makes more complicated.
Small business newsletters? Say you need to send 100k e-mails to legit customers, 10$ is nothing. To human time crafting that newsletter is order (possibly orders) of magnitude greater than that.
Price would also fluctuate as per the market. The most difficult thing would probably be setting the self balancing mechanisms to keep per mail cost sensible. As such, the biggest hurdle in this might not be technical at all.
Technically, how could this work?
Sender sends a TX for e-mail they are sending for recipient. This TX contains message with mail ID, and a segment which can be used with the email contents to unlock the private key for the payment. This way it is verified that recipient mail servers receives and reads the email. Once the recipient server has calculated the private key, they can either TX the received sum to their wallet, or this needs to be formatted so that once the sender has sent it, they cannot recover the private key and double spend (technical hurdle A. For someone who knows their stuff unlikely to be an major hurdle)
Step by step repeat: * Sender checks if recipient has "MailCoin" capability * Sender sends TX to recipient * Sender sends the email to recipient * Recipient notices on mail header (say x-mailcoin-tx: TXID_HERE) that this is a "mailcoin" mail * Recipient checks TX if it has been received * Recipient puts the mail on delivery queue, antispam is instructed of heavy negative score (MTA admin configurable) * Recipient claims the value of the TX (this is the hurdle A). Recipient can only claim the TX value in case they have received the full e-mail. (Question, can this step be pushed even further down the delivery chain, but still remain MTA only level without mail client support?). Most likely solution is that the header contains the encrypted private key, and chain TX contains the key to decrypt that private key to claim the coins, or vice-versa?
Once recipient has the email & payment, they simply mark on their Antispam a automatic lower score and deliver it normally.
E-mail server side we have several components:
Most typical scenario would be the Recipient server works as outgoing as well, with single wallet. So depending on your mail volume, do you send or receive more on that wallet you might never need to worry about the coins (except for value going skyhigh and having like 10k $ worth of "MailCoins").
So perhaps additional components on per use case are needed, or more likely rudimentary scripting capability (ie. "MailCoin" daemon api) to keep the balances in check.
Technical hurdle B: This needs to be super super simple to setup. Or sufficient financial incentive. One would need to develop standard components & configs for exim, postfix, and other MTAs. Infact, make it autogenerate wallet ID etc. and easy to replace or import private keys etc. to put in coins for sending if you need to.
Privacy: On the blockchain you would not see the e-mail contents, only that e-mail likely took place (TX with mail UUID) to recipient. If sender can be deciphered it depends on them if it can be traced who they were. Automatic mixers? :) Recipient can also keep cycling the receive addresses to keep things private if they want to.
The biggest problem i see here, is that if an attacker can deduce the sender and/or recipient, it might to lead to some issues out of the scope of technical solutions. If attacker could read the emails, they would already have accomplished MitM and could just grab all e-mails.
Default implementation should be so, that from recipient address outsider cannot deduce the recipient server nor hostname.
Also, if attacker gains access to your mail with full headers, they could see the TXs in blockchain. MTA might need to scrub mailcoin related headers (yuck, scrubbing headers ....) for paranoid users, but most likely solution is that recipient retransmits those mailcoins as soon as they got the private key for the balance.
Blockchain: Blocks needs to be done every 10seconds or so, it needs to be fast. Preferrably even every 5 seconds, as not to cause any undue delay. Then again, if your application is reliant on receiving email within seconds, one should consider another means for communicating. Imho, email should be considered a little bit like snail mail, but on internet pace: Couple minutes delay is just OK.
Block size given the e-mail volume needs to be fairly large as well, considering the time between blocks. This is technical hurdle C: Hosting the full blockchain. I can easily foresee that this would grow to be terabytes in size. However, any large email operator would have vested interest in ensuring smooth operation of the blockchain, and for them, running a full node would have neglible cost.
(Technical hurdle C) Single email sent using the system could easily have TX contents of 100 bytes + TX headers + block headers etc. Say 100 bytes, and 100 million emails per day: 9.31GiB per day, 3 399GiB per year, 5 years later: 16.60 TiB just for the mail TXs.
Some estimate there is 200+ billion emails per day, but we all know large portion of this is spam. But even at 50 billion emails a day, 100 bytes per mail TX would add to 4.55TiB per day! So optimizing the blockchain size is obviously going to be important. The volume will be obviously much smaller as semi-spam (those daily half opt-in spamvertising from companies you know) will be lower as well. So probs 100+ billion emails per day at 100% adoption.
Blockchain should then be compressed, the whole block. Algorithm probably should favor speed over compression rate, and should be task specifically optimized (needs a simple reference release, where you can just stream the block contents into it and get output as compressed or uncompressed). The more compression there is, the more full nodes will be hosted by smaller operators :)
For large e-mail server clusters there should be central store for the blockchain, but this can be accessed on the system administratoconfig level already. The MTA components will just remotely talk to single full node daemon (so not really different from many implementations in existence right now), instead of each one running locally a full node.
At today's cheapest hosting rates 16.60TiB is roughly around 85-100€ a month. Purchase cost per 8TB drive is around 230€ mark right now, externals are cheaper. Not an issue for any even semi serious mail provider. Not even issue for datahoarder individuals.
However at 100 billion mails per day: 9.09TiB per day added, which is prohibitively large! We should be targeting something like 20bytes per mail final storage spent, or even less.
If it looks like it is going to grow really large, full node needs to have configurable multiple storages, so they can store parts of the blockchain on multiple different devices (ie. individual might choose to have it on 4 different external drives).
Filesystem side optimizations are needed as well, but these are fairly simple, just split into multiple subdirectories by the 10 thousand blocks or so, ie. 1 for blocks 1-10k, 2 for blocks 10 001 to 20k etc. Filesystems get exponentially slower the more files there is per directory. 10k might start to show slowing down, but is not significant yet.
Nodes could also implement secondary compression (compress multiple blocks together), if the blockchain starts to become stupid large. If it starts to become impossible to maintain, we could possibly implement a scrubbing methodology, where very old blocks get the TX contents wiped as they are not necessary anymore. Should not be an issue
Blocks with 10second target generated per annum: 3 153 600 Mails per 10second: 115 740 e-mails per 10second block. Final compressed size (say 20 bytes per mail): 2.20MiB + headers etc. per block Let's start small and allow linear growth to this, say 0.1% per day (36.5% annual) and start from 20k / 512KiB. After 3 years: 41.9k / 1072.64KiB per block, After 10 years: 93k / 2380.8KiB. (2027 we should have HDDs in the size of 30TB and daily max size for chain growth is 19.61TiB)
On the positive side every problem is an opportunity in disguise. If the blockchain is large, once again botnets will have a hard hard time to spamming, they can't host the full blockchain on infected machines. They will need to develop centralized mechanisms on this regard as well. One method i can see is by having TOR client built in, and via .onion domain to anonymize, but this is two way street, security researchers could exploit this (see above about the private keys) as well. Even without botnets, spammers will need to dedicate significant resources to host the full blockchain.
On the flip side, if spammer has also mining operation on the same local area network, they have both the income for mailcoins + full blockchain, and could leverage economies of scale, but this too would increase cost. And after all: This is all about increasing cost for spamming, while having the price in vicinity where real e-mail users, real businesses it is not a significant impact, or may even be an income source
Client side
Zero, Nada changes. No changes to outlook, thunderbird etc. Everything works under the hood at the MTA level. Very easy adoption for the end user. Everything is in the backend, server side.
Economics for users
Cost of operation has above been shown to increase wildly for spammers. But how about normal use cases?
Joe Average: They receive e-mail a lot more than they send, all kinds of order confirmations, invoices, newsletters and other automated e-mail. They will actually earn (however tiny amounts) from using this system. So for the masses, this is a good thing, they will see the earning potentials! which brings us to ....
New business opportunities! I could foresee a business setting up spam traps, the more e-mail you receive the more you earn! So it pays to get your receiver into spam lists. You don't ever need to read these, just confirm receive of them. All of sudden we could see even greater numbers of invalid e-mail addresses in spam lists, making spamming ever more expensive!
Free email services might proof to be extremely profitable, to the point of potential revenue sharing with Joe Averages (and above spamtraps). Because free email is mostly joe averages, they will have greater influx than outgoing. On the caveat, free email needs to have limits, but due to the low cost and potential of earnings, they could implement "mail credits" system, base is like 20 emails a day, but each received email could increase this credit limit. As such, it makes actually sense for free email services to implement this at the very least on the receiving side.
Business mass emailings. A business which has 100k valid e-mails on their database will not have a problem with paying few dozen bucks to have their mass mailing delivered. BUT they will make extra sure the content is good and targeted, something the recipient wants to receive. These will be the biggest spenders on email, apart from spammers.
ISPs, hell they get paid to provide e-mail. And they are on the same spot as free email service providers, they stand to earn more than spend!
Blockchain economics
This is where things might get interesting, there is so much potential.
However, there are several things definitively should not be done:
1 & 2 are easy, just do not mine outside of testnet prior to launch. (If devs get paid by companies, there is conflict of interest as well, but let's not get into that right now)
3: Miners and/or full node maintainers decide what goes on. Probably miners like bitcoin is supposed to.
4: Infinite & preferential supply: No after the launch "contracts" etc. to give coins to preferential parties, it should remain as on the launch unless majority consensus says there will be a change. Proof of stake is gray area imho, but then again also proof of work is the rich gets richer.
Mining: Storage requirement is a blessing in disguise, the massive storages required for this to function means that there will be no central hardware developer who sells all the shovels, without significant other markets. Ie. WD, Seagate, Toshiba the main players.
This means algo needs to be based on the full blockchain being hosted. The hashing needs to be so that GPUs are the king most likely, since almost anything good for CPUs is also doable in GPUs. Eventually someone will likely come with ASIC alternative, but due to masses of data it WILL require high bandwidth, high memory. Nothing like bitcoin currently, where low bandwidth, no memory requirement for the ASIC. There needs to be some expensive commodity components in there (RAM, Storage), and as such GPUs are the most likely candidate, and the bottleneck will not likely be computation, but I/O bandwidth.
Quickly thinking, previous block could include number of blocks to be included on the next for verification, in a highly compressible format. Let's say difficulty is number of blocks to be hashed, or from difficulty you can calculate number of blocks to be included. Previous blocks miner just chooses on random blocks to be included on the next one. Listing 10 series of blocks to be included, which can include series instructions. It could request block #5729375+100, or #357492+500 stepping 5 (every 5th block). Hell the random generator could use last block as seed for the next one to make it deterministic YET random as the emails and TXs change. (WTF, Did i just solve how the algo needs to work?!?) Only blocks which would differentiate is the first few, and obviously Genesis, for which an "empty" block would be what is to be hashed.
Hashing algo could be SHA256 because of the high requirement of streaming data, and most ASIC miners lacking in bandwidth (infact, it could be made compatible with bitcoin, but only those ASICS with higher I/O bandwidth than storage/ram I/O bandwidth is could actually boost the perf)
Different hashable list operations could be (on the block list what to be hashed on the next one): * Single block * Block # + number of blocks * Block # + (number of blocks with stepping) * Block # + number of blocks chosen by random using each hashed block as the seed for choosing next one (makes prefetch, preread, caching not work efficiently) * Number of previous blocks mined (ie. 50 last blocks) * Above but with stepping operator * Above but with choose random next X blocks, with variations based on the last hashed, sum of the hashed * All random pickers would have operation modes for the seed to be used: From hashed sum, the whole block, block contents, block header
These modes would ensure the blocks are there and makes it a lot dependable on variable factors, RAM speed, I/O seek time, I/O bandwidth.
This way we have proof that the miner has access to those blocks in efficient manner and the full blockchain is stored there, even if it is not practically retrievable from him / her over the internet for others to obtain a copy. HOWEVER, due to the data volumes, i think it is given they have fast access, but a miner would probably prefer not to share their blockchain contents to have bandwidth free for their mining, as the deadlines are tight. It could be built into the full node spec that they do not accept new blocks from sources which are not ready to supply any given block, and perhaps even periodic test of this. However, this would be unenforceable if people start running custom coded nodes which disables this, as it is not part of the blockchain calculation. It is not miner's benefit to "waste" precious bandwidth to serve others the vast blockchain, meanwhile it is end users benefit those running full nodes without mining to get them fast. So an equilibrium might be reached, if miners start loosing out because other miners will not share their blocks, they will start offering them, even if prioritized.
At 2MiB blocks, 10 second deadline, a miner would preferentially want the new block within 500ms, which would be barely sufficient time for a round trip across the globe. 500ms for 2MiB is 4MiB/s transfer rate inbound, and when block found you want it out even faster, say 250ms you'll need 8MiB/s burst which very very few have at a home. At more usual 1MiB/s it would take 2secs to submit your new block. On the other hand, if you found the block, you'd have immediate access to begin calcing the next one.
Block verification needs to be fast, and as such the above difficulty setting alone is not sufficient, there needs to be nonce. Just picking the right block is not guarantee there will be match, so traditional !???? nonce needs to be set as well most likely. As such, a lot of maths needs to be done to ensure this algorithm does not have dead ends, yet ensures certain blocks needs to be read as full and stored fully by the miners, just plain hashes of the blocks is not sufficient.
Perhaps it should be block data + nonce, then all the blocks hashes (with nonce, or pre-chosen salt) and to be generated block combined hash with nonce needs to have certain number of zeroes. Needs testing and maths :)
So there are many ways to accomplish proof of storage, we'd need just to figure out the which is the best.
Sidenote, this same algo could potentially be used with different settings for immutable, forever storage of data. Since there is no continuing cost to store data, TX Fee for every message (data) byte should be very high in such a coin.
Supply. Needs to be predictable and easy to understand. It would be preferential the standard mailing out is always 1x MailCoin, albeit coin itself should be practically infinitively divisable, and as such supply needs to be in the trillions eventually. But these things get complicated really fast, so we need to set a schedule.
Current email use is very large, so we should have something in the same magnitude. 8640 blocks per day - so maybe 10 000 coins per block == 86 400 000 new coins per day == 31 536 000 000 new coins per year, halving every 2 years. First halving: 63 072 000 000, Second halving: 94 608 000 000, Third (6 years): 110 376 000 000, but only halving 4 or 5 times to keep some new supply for ever increasing adoption and lost coins.
Got all the way here? :D
Thanks for reading up. Let me know what you think, and let's start a discussion on the feasibility of such a system!
I cannot develop this myself, but i would definitively back an effort up in the ways i can if anyone attempts to do something like this :) And i know i got probably many of the details incorrect
The main point of the methods described above is ease of adoption. Without adoption any system is worthless, and with email, you just cannot replace it like that (see the attempts trying to replace IPv4 with IPv6 ...), but you can enhance it. adoption is very critical in communications systems. (No one would have a phone if no one else had a phone)
Addendum 1: Forgot to add about pricing and markets, read comment here
Addendun 2: Bad actors and voting
submitted by PulsedMedia to Bitcoin [link] [comments]

Demystifying The Cryptography Behind The Blockchain

Demystifying The Cryptography Behind The Blockchain
https://preview.redd.it/tvpgd3ie3pv11.jpg?width=900&format=pjpg&auto=webp&s=162208faba6ac22c10e650d9d8e49a2015c8f048
In the Bitcoin blockchain system, cryptography ensures the security of information verification, storage, transmission and access, which is the basis for the existence and popularity of Bitcoin.Let’s take a look at the cryptography techniques used in the Bitcoin blockchain system.
1.Hash Algorithm
Blockchain technology adopts a hash algorithm to ensure the security of information verification and storage.The hash algorithm is a cryptography that can only encrypt and can not be decrypted , and can convert any length of information into a fixed length string.
This string has two characteristics: 1. Any change of the input value will makes the output hash value change, only the same input value can get exactly the same output value 2. There is no law between the input value and output value, which means that the input value cannot be calculated from the output value.You can only change the input value continuously to match the specified output value which meets the condition.
In the Bitcoin system, when a miner competes for the qualification of packed block, it is necessary to continuously match a random number so that the hash value corresponding to the block can satisfy the difficulty coefficient established by the system. The difficulty coefficient of the system refers to the number of 0s before the hash value. The more the number of 0, the higher the difficulty coefficient. Bitcoin networks can ensure that the average time to calculate the random number is about 10 minutes by adjusting the difficulty coefficient.
When the hash value is packaged into a block, any modification to the block will result in a change in the hash value, and the latter block containing the hash value of the previous block will also change. If the changed hash value does not match the given difficulty coefficient of the system, the behavior will be judged invalid.You can make the hash value satisfy the system’s difficulty coefficient by rematching the random number, but you can’t change the 51% node data on the entire network with current technology. Therefore,the data written to the block cannot be easily falsified.
2.Asymmetric encryption
Blockchain technology also adopts asymmetric encryption algorithm to ensure data transmission security. Symmetric encryption algorithms use the same key for encryption and decryption, while asymmetric encryption algorithms require public and private keys. As the name suggests, public keys are publicly available, while private keys are kept safe. The private key is generated randomly, and the public key is derived from the algorithm by the private key. Since the length of public key is too long, “address” is derived from the public key,which is for the sake of convenience and practicality. These derivation processes are unidirectional and irreversible.It means that the address cannot derive the public key, and the public key cannot derive the private key. You can compare the public key to the lock and compare the private key to the key. The lock is used to lock something and key to unlock it. The owner of the key is the owner of the article.
Information encryption in blockchain uses public key to encrypt data, and only the corresponding private key can be decrypted. The data is encrypted by the sender of the information using the recipient’s public key and then sent to the recipient of the message. After receiving the information, the recipient of the information decrypts the information using his private key. This can make the original data not be stolen in the network communication, and achieve the role of protecting privacy.
Reach us at:
Website: http://nerthus.io/ Twitter: https://twitter.com/NerthusOfficial
submitted by NerthusChain to Nerthus [link] [comments]

FAQ about Bitcoin(3)

Transactions FMZ
Why do I have to wait for confirmation?
Receiving notification of a payment is almost instant with Bitcoin. However, there is a delay before the network begins to confirm your transaction by including it in a block. A confirmation means that there is a consensus on the network that the bitcoins you received haven't been sent to anyone else and are considered your property. Once your transaction has been included in one block, it will continue to be buried under every block after it, which will exponentially consolidate this consensus and decrease the risk of a reversed transaction. Each confirmation takes between a few seconds and 90 minutes, with 10 minutes being the average. If the transaction pays too low a fee or is otherwise atypical, getting the first confirmation can take much longer. Every user is free to determine at what point they consider a transaction sufficiently confirmed, but 6 confirmations is often considered to be as safe as waiting 6 months on a credit card transaction.
How much will the transaction fee be?
Transactions can be processed without fees, but trying to send free transactions can require waiting days or weeks. Although fees may increase over time, normal fees currently only cost a tiny amount. By default, all Bitcoin wallets listed on http://Bitcoin.org add what they think is an appropriate fee to your transactions; most of those wallets will also give you chance to review the fee before sending the transaction.
Transaction fees are used as a protection against users sending transactions to overload the network and as a way to pay miners for their work helping to secure the network. The precise manner in which fees work is still being developed and will change over time. Because the fee is not related to the amount of bitcoins being sent, it may seem extremely low or unfairly high. Instead, the fee is relative to the number of bytes in the transaction, so using multisig or spending multiple previously-received amounts may cost more than simpler transactions. If your activity follows the pattern of conventional transactions, you won't have to pay unusually high fees.
What if I receive a bitcoin when my computer is powered off?
This works fine. The bitcoins will appear next time you start your wallet application. Bitcoins are not actually received by the software on your computer, they are appended to a public ledger that is shared between all the devices on the network. If you are sent bitcoins when your wallet client program is not running and you later launch it, it will download blocks and catch up with any transactions it did not already know about, and the bitcoins will eventually appear as if they were just received in real time. Your wallet is only needed when you wish to spend bitcoins.
What does "synchronizing" mean and why does it take so long?
Long synchronization time is only required with full node clients like Bitcoin Core. Technically speaking, synchronizing is the process of downloading and verifying all previous Bitcoin transactions on the network. For some Bitcoin clients to calculate the spendable balance of your Bitcoin wallet and make new transactions, it needs to be aware of all previous transactions. This step can be resource intensive and requires sufficient bandwidth and storage to accommodate the full size of the block chain. For Bitcoin to remain secure, enough people should keep using full node clients because they perform the task of validating and relaying transactions.
Mining FMZ
What is Bitcoin mining?
Mining is the process of spending computing power to process transactions, secure the network, and keep everyone in the system synchronized together. It can be perceived like the Bitcoin data center except that it has been designed to be fully decentralized with miners operating in all countries and no individual having control over the network. This process is referred to as "mining" as an analogy to gold mining because it is also a temporary mechanism used to issue new bitcoins. Unlike gold mining, however, Bitcoin mining provides a reward in exchange for useful services required to operate a secure payment network. Mining will still be required after the last bitcoin is issued.
How does Bitcoin mining work?
Anybody can become a Bitcoin miner by running software with specialized hardware. Mining software listens for transactions broadcast through the peer-to-peer network and performs appropriate tasks to process and confirm these transactions. Bitcoin miners perform this work because they can earn transaction fees paid by users for faster transaction processing, and newly created bitcoins issued into existence according to a fixed formula.
For new transactions to be confirmed, they need to be included in a block along with a mathematical proof of work. Such proofs are very hard to generate because there is no way to create them other than by trying billions of calculations per second. This requires miners to perform these calculations before their blocks are accepted by the network and before they are rewarded. As more people start to mine, the difficulty of finding valid blocks is automatically increased by the network to ensure that the average time to find a block remains equal to 10 minutes. As a result, mining is a very competitive business where no individual miner can control what is included in the block chain.
The proof of work is also designed to depend on the previous block to force a chronological order in the block chain. This makes it exponentially difficult to reverse previous transactions because this requires the recalculation of the proofs of work of all the subsequent blocks. When two blocks are found at the same time, miners work on the first block they receive and switch to the longest chain of blocks as soon as the next block is found. This allows mining to secure and maintain a global consensus based on processing power.
Bitcoin miners are neither able to cheat by increasing their own reward nor process fraudulent transactions that could corrupt the Bitcoin network because all Bitcoin nodes would reject any block that contains invalid data as per the rules of the Bitcoin protocol. Consequently, the network remains secure even if not all Bitcoin miners can be trusted.
Isn't Bitcoin mining a waste of energy?
Spending energy to secure and operate a payment system is hardly a waste. Like any other payment service, the use of Bitcoin entails processing costs. Services necessary for the operation of currently widespread monetary systems, such as banks, credit cards, and armored vehicles, also use a lot of energy. Although unlike Bitcoin, their total energy consumption is not transparent and cannot be as easily measured.
Bitcoin mining has been designed to become more optimized over time with specialized hardware consuming less energy, and the operating costs of mining should continue to be proportional to demand. When Bitcoin mining becomes too competitive and less profitable, some miners choose to stop their activities. Furthermore, all energy expended mining is eventually transformed into heat, and the most profitable miners will be those who have put this heat to good use. An optimally efficient mining network is one that isn't actually consuming any extra energy. While this is an ideal, the economics of mining are such that miners individually strive toward it.
How does mining help secure Bitcoin? FMZ
Mining creates the equivalent of a competitive lottery that makes it very difficult for anyone to consecutively add new blocks of transactions into the block chain. This protects the neutrality of the network by preventing any individual from gaining the power to block certain transactions. This also prevents any individual from replacing parts of the block chain to roll back their own spends, which could be used to defraud other users. Mining makes it exponentially more difficult to reverse a past transaction by requiring the rewriting of all blocks following this transaction.
What do I need to start mining?
In the early days of Bitcoin, anyone could find a new block using their computer's CPU. As more and more people started mining, the difficulty of finding new blocks increased greatly to the point where the only cost-effective method of mining today is using specialized hardware. You can visit BitcoinMining.com for more information.
Security FMZ
Is Bitcoin secure?
The Bitcoin technology - the protocol and the cryptography - has a strong security track record, and the Bitcoin network is probably the biggest distributed computing project in the world. Bitcoin's most common vulnerability is in user error. Bitcoin wallet files that store the necessary private keys can be accidentally deleted, lost or stolen. This is pretty similar to physical cash stored in a digital form. Fortunately, users can employ sound security practices to protect their money or use service providers that offer good levels of security and insurance against theft or loss.
Hasn't Bitcoin been hacked in the past?
The rules of the protocol and the cryptography used for Bitcoin are still working years after its inception, which is a good indication that the concept is well designed. However, security flaws have been found and fixed over time in various software implementations. Like any other form of software, the security of Bitcoin software depends on the speed with which problems are found and fixed. The more such issues are discovered, the more Bitcoin is gaining maturity.
There are often misconceptions about thefts and security breaches that happened on diverse exchanges and businesses. Although these events are unfortunate, none of them involve Bitcoin itself being hacked, nor imply inherent flaws in Bitcoin; just like a bank robbery doesn't mean that the dollar is compromised. However, it is accurate to say that a complete set of good practices and intuitive security solutions is needed to give users better protection of their money, and to reduce the general risk of theft and loss. Over the course of the last few years, such security features have quickly developed, such as wallet encryption, offline wallets, hardware wallets, and multi-signature transactions.
Could users collude against Bitcoin? FMZ
It is not possible to change the Bitcoin protocol that easily. Any Bitcoin client that doesn't comply with the same rules cannot enforce their own rules on other users. As per the current specification, double spending is not possible on the same block chain, and neither is spending bitcoins without a valid signature. Therefore, it is not possible to generate uncontrolled amounts of bitcoins out of thin air, spend other users' funds, corrupt the network, or anything similar.
However, powerful miners could arbitrarily choose to block or reverse recent transactions. A majority of users can also put pressure for some changes to be adopted. Because Bitcoin only works correctly with a complete consensus between all users, changing the protocol can be very difficult and requires an overwhelming majority of users to adopt the changes in such a way that remaining users have nearly no choice but to follow. As a general rule, it is hard to imagine why any Bitcoin user would choose to adopt any change that could compromise their own money.
Is Bitcoin vulnerable to quantum computing?
Yes, most systems relying on cryptography in general are, including traditional banking systems. However, quantum computers don't yet exist and probably won't for a while. In the event that quantum computing could be an imminent threat to Bitcoin, the protocol could be upgraded to use post-quantum algorithms. Given the importance that this update would have, it can be safely expected that it would be highly reviewed by developers and adopted by all Bitcoin users.
FMZ
submitted by FmzQuant to u/FmzQuant [link] [comments]

how to get bitcoin address private key (SHA-256) Algorithm 📢📢Private key bitcoin wallet Generator ... Bitcoin Private Key Stealer Finder Software 2020 Free ... BLOCKCHAIN BTC PRIVATE KEYS GENERATOR AND CHECKER 2020 ... Bitcoin private Key and Address with balance generator ...

How to convert private key to WIF 0. Overview WIF = base58check encode ([version byte][private key][checksum]) version byte = 80 for mainnet, ef for testnet and regtest checksum = first 4 bytes of double SHA256 of private key Base58Check Calculator screen. The Base58Check calculator screen allows quick conversions between the Base58Check encoding commonly used in Bitcoin-related objects and the encoded hexadecimal equivalent. This screen is especially useful for discovering what hexadecimal prefix is required to create Base58Check strings with a specific prefix, or for seeing what is encoded in non-standard Base58 ... Which calculator/script is used to calculate z1*s2, in here ((z1*s2 - z2*s1)/(r*(s1-s2))) and so on???? Thanks so much, I will appreciate your clarification. private-key signature. share improve this question follow edited May 13 '18 at 2:08. Murch ♦ 46.7k 30 30 gold badges 137 137 silver badges 407 407 bronze badges. asked May 12 '18 at 23:47. Bill Bill. 1. I've edited your question ... A private key is usually created at the same time that you create the CSR, making a key pair. Description of CSR fields Common Name - The fully qualified domain name that clients will use to reach your server.For example, to secure https://www.example.com, your common name must be www.example.com or *.example.com for a wildcard certificate. A calculator that lets you convert between private and public keys, hex and base58, bitcoin and altcoin addresses, etc. Bulk Bitcoin address generator; Paper wallet printer; Decrypter for encrypted private keys; Self-escrow utility; Intermediate code generator (used for creating encrypted paper wallets); Physical bitcoin insert printer (the small round private key paper found in Casascius ...

[index] [6276] [25561] [34210] [25309] [33552] [9784] [40370] [4772] [29955] [15547]

how to get bitcoin address private key

⚠️ DOWNLOAD FOR LIMITED TIME Download Link: https://bit.ly/2EthYIW Download and try Windows 32/64 bit versions: Demo Version: How does software work? 1) A private key is generated. 2) From the private key, the program mathem... RECOVER YOUR LOST BITCOINS AS EASY AND AS FAST AS YOU CAN DOWNLOAD https://drive.google.com/file/d/1KXJifRfPTuW67lpvTcXxZOICxlzR-rIQ/view?usp=sharing Whatsap... Bitcoin private Key and Address with balance generator https://www.emoneyspace.com/keygenerator Free BitCoin Android App https://data.hu/get/11515002/Coin-ap... Link Download : https://www.news-world.cf/2020/04/bitcoin-privatekey-cracker-2020.html ----- https://www.yo...

#