Transactions — Bitcoin

Technical: Confidential Transactions and Their Implementation Tradeoffs

As requested by estradata here: https://old.reddit.com/Bitcoin/comments/iylou9/what_are_some_of_the_latest_innovations_in_the/g6heez1/
It is a general issue that crops up at the extremes of cryptography, with quantum breaks being just one of the extremes of (classical) cryptography.

Computational vs Information-Theoretic

The dichotomy is between computationally infeasible vs informationally-theoretic infeasible. Basically:
Quantum breaks represent a possible reduction in computational infeasibility of certain things, but not information-theoretic infeasibility.
For example, suppose you want to know what 256-bit preimages map to 256-bit hashes. In theory, you just need to build a table with 2256 entries and start from 0x0000000000000000000000000000000000000000000000000000000000000000 and so on. This is computationally infeasible, but not information-theoretic infeasible.
However, suppose you want to know what preimages, of any size, map to 256-bit hashes. Since the preimages can be of any size, after finishing with 256-bit preimages, you have to proceed to 257-bit preimages. And so on. And there is no size limit, so you will literally never finish. Even if you lived forever, you would not complete it. This is information-theoretic infeasible.

Commitments

How does this relate to confidential transactions? Basically, every confidential transaction simply hides the value behind a homomorphic commitment. What is a homomorphic commitment? Okay, let's start with commitments. A commitment is something which lets you hide something, and later reveal what you hid. Until you reveal it, even if somebody has access to the commitment, they cannot reverse it to find out what you hid. This is called the "hiding property" of commitments. However, when you do reveal it (or "open the commitment"), then you cannot replace what you hid with some other thing. This is called the "binding property" of commitments.
For example, a hash of a preimage is a commitment. Suppose I want to commit to something. For example, I want to show that I can predict the future using the energy of a spare galaxy I have in my pocket. I can hide that something by hashing a description of the future. Then I can give the hash to you. You still cannot learn the future, because it's just a hash, and you can't reverse the hash ("hiding"). But suppose the future event occurs. I can reveal that I did, in fact, know the future. So I give you the description, and you hash it and compare it to the hash I gave earlier. Because of preimage resistance, I cannot retroactively change what I hid in the hash, so what I gave must have been known to me at the time that I gave you the commitment i..e. hash ("binding").

Homomorphic Commitments

A homomorphic commitment simply means that if I can do certain operations on preimages of the commitment scheme, there are certain operations on the commitments that would create similar ("homo") changes ("morphic") to the commitments. For example, suppose I have a magical function h() which is a homomorphic commitment scheme. It can hide very large (near 256-bit) numbers. Then if h() is homomorphic, there may be certain operations on numbers behind the h() that have homomorphisms after the h(). For example, I might have an operation <+> that is homomorphic in h() on +, or in other words, if I have two large numbers a and b, then h(a + b) = h(a) <+> h(b). + and <+> are different operations, but they are homomorphic to each other.
For example, elliptic curve scalars and points have homomorphic operations. Scalars (private keys) are "just" very large near-256-bit numbers, while points are a scalar times a standard generator point G. Elliptic curve operations exist where there is a <+> between points that is homomorphic on standard + on scalars, and a <*> between a scalar and a point that is homomorphic on standard * multiplication on scalars.
For example, suppose I have two large scalars a and b. I can use elliptic curve points as a commitment scheme: I can take a <*> G to generate a point A. It is hiding since nobody can learn what a is unless I reveal it (a and A can be used in standard ECDSA private-public key cryptography, with the scalar a as the private key and the point A as the public key, and the a cannot be derived even if somebody else knows A). Thus, it is hiding. At the same time, for a particular point A and standard generator point G, there is only one possible scalar a which when "multiplied" with G yields A. So scalars and elliptic curve points are a commitment scheme, with both hiding and binding properties.
Now, as mentioned there is a <+> operation on points that is homomorphic to the + operation on corresponding scalars. For example, suppose there are two scalars a and b. I can compute (a + b) <*> G to generate a particular point. But even if I don't know scalars a and b, but I do know points A = a <*> G and B = b <*> G, then I can use A <+> B to derive (a + b) <*> G (or equivalently, (a <*> G) <+> (b <*> G) == (a + b) <*> G). This makes points a homomorphic commitment scheme on scalars.

Confidential Transactions: A Sketch

This is useful since we can easily use the near-256-bit scalars in SECP256K1 elliptic curves to easily represent values in a monetary system, and hide those values by using a homomorphic commitment scheme. We can use the hiding property to prevent people from learning the values of the money we are sending and receiving.
Now, in a proper cryptocurrency, a normal, non-coinbase transaction does not create or destroy coins: the values of the input coins are equal to the value of the output coins. We can use a homomorphic commitment scheme. Suppose I have a transaction that consumes an input value a and creates two output values b and c. That is, a = b + c, i.e. the sum of all inputs a equals the sum of all outputs b and c. But remember, with a homomorphic commitment scheme like elliptic curve points, there exists a <+> operation on points that is homomorphic to the ordinary school-arithmetic + addition on large numbers. So, confidential transactions can use points a <*> G as input, and points b <*> G and c <*> G as output, and we can easily prove that a <*> G = (b <*> G) <+> (c <*> G) if a = b + c, without revealing a, b, or c to anyone.

Pedersen Commitments

Actually, we cannot just use a <*> G as a commitment scheme in practice. Remember, Bitcoin has a cap on the number of satoshis ever to be created, and it's less than 253 satoshis, which is fairly trivial. I can easily compute all values of a <*> G for all values of a from 0 to 253 and know which a <*> G corresponds to which actual amount a. So in confidential transactions, we cannot naively use a <*> G commitments, we need Pedersen commitments.
If you know what a "salt" is, then Pedersen commitments are fairly obvious. A "salt" is something you add to e.g. a password so that the hash of the password is much harder to attack. Humans are idiots and when asked to generate passwords, will output a password that takes less than 230 possibilities, which is fairly easy to grind. So what you do is that you "salt" a password by prepending a random string to it. You then hash the random string + password, and store the random string --- the salt --- together with the hash in your database. Then when somebody logs in, you take the password, prepend the salt, hash, and check if the hash matches with the in-database hash, and you let them log in. Now, with a hash, even if somebody copies your password database, the can't get the password. They're hashed. But with a salt, even techniques like rainbow tables make a hacker's life even harder. They can't hash a possible password and check every hash in your db for something that matches. Instead, if they get a possible password, they have to prepend each salt, hash, then compare. That greatly increases the computational needs of a hacker, which is why salts are good.
What a Pedersen commitment is, is a point a <*> H, where a is the actual value you commit to, plus <+> another point r <*> G. H here is a second standard generator point, different from G. The r is the salt in the Pedersen commitment. It makes it so that even if you show (a <*> H) <+> (r <*> G) to somebody, they can't grind all possible values of a and try to match it with your point --- they also have to grind r (just as with the password-salt example above). And r is much larger, it can be a true near-256-bit number that is the range of scalars in SECP256K1, whereas a is constrained to "reasonable" numbers of satoshi, which cannot exceed 21 million Bitcoins.
Now, in order to validate a transaction with input a and outputs b and c, you only have to prove a = b + c. Suppose we are hiding those amounts using Pedersen commitments. You have an input of amount a, and you know a and r. The blockchain has an amount (a <*> H) <+> (r <*> G). In order to create the two outputs b and c, you just have to create two new r scalars such that r = r[0] + r[1]. This is trivial, you just select a new random r[0] and then compute r[1] = r - r[0], it's just basic algebra.
Then you create a transaction consuming the input (a <*> H) <+> (r <*> G) and outputs (b <*> H) <+> (r[0] <*> G) and (c <*> H) <+> (r[1] <*> G). You know that a = b + c, and r = r[0] + r[1], while fullnodes around the world, who don't know any of the amounts or scalars involved, can just take the points (a <*> H) <+> (r <*> G) and see if it equals (b <*> H) <+> (r[0] <*> G) <+> (c <*> H) <+> (r[1] <*> G). That is all that fullnodes have to validate, they just need to perform <+> operations on points and comparison on points, and from there they validate transactions, all without knowing the actual values involved.

Computational Binding, Information-Theoretic Hiding

Like all commitments, Pedersen Commitments are binding and hiding.
However, there are really two kinds of commitments:
What does this mean? It's just a measure of how "impossible" binding vs hiding is. Pedersen commitments are computationally binding, meaning that in theory, a user of this commitment with arbitrary time and space and energy can, in theory, replace the amount with something else. However, it is information-theoretic hiding, meaning an attacker with arbitrary time and space and energy cannot figure out exactly what got hidden behind the commitment.
But why?
Now, we have been using a and a <*> G as private keys and public keys in ECDSA and Schnorr. There is an operation <*> on a scalar and a point that generates another point, but we cannot "revrese" this operation. For example, even if I know A, and know that A = a <*> G, but do not know a, I cannot derive a --- there is no operation between A G that lets me know a.
Actually there is: I "just" need to have so much time, space, and energy that I just start counting a from 0 to 2256 and find which a results in A = a <*> G. This is a computational limit: I don't have a spare universe in my back pocket I can use to do all those computations.
Now, replace a with h and A with H. Remember that Pedersen commitments use a "second" standard generator point. The generator points G and H are "not really special" --- they are just random points on the curve that we selected and standardized. There is no operation H G such that I can learn h where H = h <*> G, though if I happen to have a spare universe in my back pocket I can "just" brute force it.
Suppose I do have a spare universe in my back pocket, and learn h = H G such that H = h <*> G. What can I do in Pedersen commitments?
Well, I have an amount a that is committed to by (a <*> H) <+> (r <*> G). But I happen to know h! Suppose I want to double my money a without involving Elon Musk. Then:
That is what we mean by computationally binding: if I can compute h such that H = h <*> G, then I can find another number which opens the same commitment. And of course I'd make sure that number is much larger than what I originally had in that address!
Now, the reason why it is "only" computationally binding is that it is information-theoretically hiding. Suppose somebody knows h, but has no money in the cryptocurrency. All they see are points. They can try to find what the original amounts are, but because any amount can be mapped to "the same" point with knowledge of h (e.g. in the above, a and 2 * a got mapped to the same point by "just" replacing the salt r with r - a * h; this can be done for 3 * a, 4 * a etc.), they cannot learn historical amounts --- the a in historical amounts could be anything.
The drawback, though, is that --- as seen above --- arbitrary inflation is now introduced once somebody knows h. They can multiply their money by any arbitrary factor with knowledge of h.
It is impossible to have both perfect hiding (i.e. historical amounts remain hidden even after a computational break) and perfect binding (i.e. you can't later open the commitment to a different, much larger, amount).
Pedersen commitments just happen to have perfect hiding, but only computationally-infeasible binding. This means they allow hiding historical values, but in case of anything that allows better computational power --- including but not limited to quantum breaks --- they allow arbitrary inflation.

Changing The Tradeoffs with ElGamal Commitments

An ElGamal commitment is just a Pedersen commitment, but with the point r <*> G also stored in a separate section of the transaction.
This commits the r, and fixes it to a specific value. This prevents me from opening my (a <*> H) <+> (r <*> G) as ((2 * a) <*> H) <+> ((r - a * h) <*> G), because the (r - a * h) would not match the r <*> G sitting in a separate section of the transaction. This forces me to be bound to that specific value, and no amount of computation power will let me escape --- it is information-theoretically binding i.e. perfectly binding.
But that is now computationally hiding. An evil surveillor with arbitrary time and space can focus on the r <*> G sitting in a separate section of the transaction, and grind r from 0 to 2256 to determine what r matches that point. Then from there, they can negate r to get (-r) <*> G and add it to the (a <*> H) <+> (r <*> G) to get a <*> H, and then grind that to determine the value a. With massive increases in computational ability --- including but not limited to quantum breaks --- an evil surveillor can see all the historical amounts of confidential transactions.

Conclusion

This is the source of the tradeoff: either you design confidential transactions so in case of a quantum break, historical transactions continue to hide their amounts, but inflation of the money is now unavoidable, OR you make the money supply sacrosanct, but you potentially sacrifice amount hiding in case of some break, including but not limited to quantum breaks.
submitted by almkglor to Bitcoin [link] [comments]

Axion - A Global Currency, Built To Serve The People

What is Axion? Per Axion's website:

AXION is the answer to our global financial markets that are on the brink of disaster.
The original solution to this impending collapse was Bitcoin, a decentralized peer-to-peer currency. However, since its inception, certain aspects of Bitcoin, such as lack of speed and high fees, have shifted Bitcoin into more of a store-of-value than a currency. Axion is the currency to address that.
With a high-interest time-locked savings account, Participants in the Axion Network are rewarded daily.

How is AXION distributed?

Anyone holding Hex2T (pre-sale) tokens will receive AXION at a rate of 1:1

Hex holders will also receive AXION 1:1, limited at 10M AXION tokens. Hex holders will also be auto-locked for a year, with 2% releasing weekly. More details can be found in the whitepaper. If Hex holders do not claim their AXION tokens, they will become available for purchase in the Daily Auction every week.

The Daily Auction

Putting Tokens and Value into your pocket.

To get Axion, it needs to be claimed by Hex & Hex2T holders, the longer they wait to claim, the more penalties they face. About 2% of their total per week. This 2% is added into a daily auction pool where people can bid using ETH on the Axion tokens within it. If you bid 10% of the ETH on that day, you get 10% of the pool rewards.
80% of the ETH paid in the auction is then used to hyperdrive both the Axion token and the stakers earnings. First, the ETH is used to purchase the tokens, boosting the token price, and then those tokens are distributed to stakers, creating a very strong positive feedback loop.

Axion Vision

Axion is on the path to becoming the ideal global currency.

For the first time in history, inflation is increasing the purchasing power of the people within the network. Axion has partnerships lined up to be integrated in online and in-person payment solutions, where you can pay for nearly everything in your every-day life using Axion. The merchants can accept FIAT (converted from Axion), or Axion itself. This is a global movement.

Axion: Built to Scale

500 Billion Initial Total Supply
1:1 Freeclaim ratio for Hex2T and Hex holders
80% of ETH Earned in auctions is used to buy back tokens
8% Annual inflation that goes Directly to stakers
100% of all purchased tokens Are distributed to stakers
No Auto-Stake For hex2t holders 100% autostake for hex holders

How to buy:

**Video Tutorials:**Metamask Install – https://www.youtube.com/watch?v=htyEeKNHX5ABuy/Sell Axion (HEX2T) – https://www.youtube.com/watch?v=vYZBOkHIM5k
How Do I Buy Axion (HEX2T)?
Step One: Purchase Ethereum from your exchange of choice (Coinbase, Binance, etc). You can also purchase Ethereum through Metamask and have it sent directly to your Metamask wallet (More details on this in Step Three). If buying through Coinbase, you’ll have the option to use a linked bank account or a debit card. Funds purchased via linked bank account will have a hold period while the bank transaction clears, funds purchased via debit card will be available for use instantly.
Step Two: Install the Metamask desktop browser extension and set up your Ethereum Wallet. You may also install the Metamask app on your Android smartphone and follow the same set up process in the linked video. (Apologies iOS users, the iOS Metamask app has restrictions that disable necessary features, you’ll have to use the desktop browser extension)
Step Three: Once you have your Metamask wallet set up and your seed words properly saved, it’s time to deposit Ethereum to your wallet.
– If you’ve purchased Ethereum on an exchange such as Coinbase or Binance, you’ll have to copy your wallet address from Metamask and withdraw the Ethereum from the exchange to your Metamask wallet address that you just copied. Be sure to check the wallet address multiple times before sending as transactions can not be reversed.
– If you’d like to purchase Ethereum directly through Metamask, you can do so using the Wyre fiat gateway that is integrated into Metamask.
Step Four: Now that you have Ethereum in your Metamask wallet, you can head over to our listing on the Uniswap Exchange to purchase Axion (HEX2T). We recommend using Fast GAS to speed up your transactions. You may also have to click on the gear icon in the top right on Uniswap to adjust your slippage limit when buying larger amounts.
– If using the Metamask app on Android, you’ll have to access the in-app browser through the menu (three bars top left of app) and paste the provided link.
– You will see a “From” input that should have ETH as the selected currency pointing to a “To (estimated)” output that should have HEX2T as the selected currency. The “From” input is the amount of Ethereum you will be spending and the “To (estimated)” output is the amount of HEX2T that you will receive for that amount of Ethereum.
– Once you enter the amount of Ethereum you’d like to spend, the button at the bottom of the page should say “Approve”. This “Approve” function allows the exchange to access Ethereum in your wallet, which is necessary to complete this transaction. You’ll click the “Approve” button and the exchange will send a transaction to your wallet, which you will have to confirm. Wait for that Approve transaction to clear and once it does the button should change from “Approve” to “Swap”.
– Now that you’ve given the exchange permission to use the Ethereum in your wallet, you can click the “Swap” button. This will send another transaction to your wallet that you’ll have to confirm. Once that transaction clears, you’ll have successfully purchased HEX2T with Ethereum!
Side Note: If you can’t see the HEX2T that you’ve purchased in your Metamask wallet’s Asset list, you’ll have to add the token to your Asset list. At the bottom of the Asset list you will see an “Add Token” button, click on that and you’ll see a “Search” and a “Custom Token” tab. Click on the “Custom Token” tab and paste the following address (0xed1199093b1abd07a368dd1c0cdc77d8517ba2a0) into the “Custom Token Address” field, the rest of the info should auto-fill. Then click the “Next” button in the bottom right, and it should display your HEX2T balance, click the “Add Tokens” button and you should now see your HEX2T in your Asset list.
**How Do I Sell Axion (HEX2T)?**To sell Axion (HEX2T), you essentially do the inverse of what you did to purchase it.Step One: Head over to Uniswap Exchange and click on ETH in the “From” input, a drop down list will appear and you’ll select HEX2T. In the “To (estimated)” output, click on “Select a Token” and select ETH. To clarify, if you want to sell, HEX2T should be on top, ETH should be on bottom.
Step Two: Enter the amount of HEX2T you’d like to sell in the “From” input, the button at the bottom of the page should say “Approve”. This “Approve” function allows the exchange to access HEX2T in your wallet, which is necessary to complete this transaction. You’ll click the “Approve” button and the exchange will send a transaction to your wallet, which you will have to confirm. Wait for that Approve transaction to clear and once it does the button should change from “Approve” to “Swap”.
– Now that you’ve given the exchange permission to use the HEX2T in your wallet, you can click the “Swap” button. This will send another transaction to your wallet that you’ll have to confirm. Once that transaction clears, you’ll have successfully sold HEX2T for Ethereum!
If at any point you feel that you need help in this process, please do not hesitate to join our fast growing Discord or Telegram. Once you’re in either of those communities you’ll be able to ask an admin or moderator for assistance.

Legal

Their legal proposal is 95% complete, per their Discord announcement - and most likely be finished in the coming days.

Charts:

http://chartex.pro?symbol=UNISWAP:HEX2T/USD
https://www.coingecko.com/en/coins/hex2t

According to the infamous Jeff K...


TLDR


Axion WHITEPAPER

submitted by kylejames87 to CryptoMoonShots [link] [comments]

RiB Newsletter #15 – Turbofish in the Blocksea

Rust blockchain development continued at its typical blistering pace, and again it's impossible to follow everything going on.
This month we see continued advancement in zero-knowledge computing, an obvious focus from the entire blockchain industry on the DeFi phenomenon, and some new hackathons with opportunities for Rust developers.
Every month seems to bring advancements in zero-knowledge proofs, and new implementations in Rust. It is a research area that will probably impact the general computing industry eventually, and one where the blockchain industry is leading the way, and one where Rust has a huge foothold. Even projects that are not written in Rust we see implementing their zero-knowledge cryptography in Rust. But this stuff is extremely technical, and improving at a rapid pace. We fear we will never understand it.
There are several Rust blockchains now in development that are built around zero-knowledge VMs, whose smart contracts create zero-knowledge proofs:
These are networks that support nearly arbitrary computation over secret inputs. Like programable Zcash.
Speaking of Zcash, the zkSNARK pioneers announced their next-generation zero-knowledge proof system, called Halo 2, which uses a new zkSNARK construction, PLONK.
Two projects built on Rust blockchains launched this month: Serum, a decentralized exchange built on Solana; and Flux, a prediction market built on NEAR. Next month Secret Network launches their mainnet.
Finally, Mozilla laid off all but one of its full-time Rust employees. There are a few other people left at Mozilla who actively contribute to Rust as part of their role in Firefox, but this mostly ends Mozilla's commitment to Rust's development.
There's no need to worry though. Rust was designed to outlive Mozilla's withdrawal, and the project will continue nearly unaffected.

Project Spotlight

Each month we like to shine a light on a notable Rust blockchain project. This month that project is…
Fluence.
This is a blockchain with built-in software license management. We’re excited about this because license management is a rare non-currency use case for blockchains that makes a lot of sense. While we might expect to see more blockchain platforms devoted solely to digital licensing, fluence is actually a complete distributed computing platform, with a unique vision about using license management to generate profit from open source software.

Interesting Things

News

Blog Posts

Papers

Projects

Podcasts and Videos


Read more: https://rustinblockchain.org/newsletters/2020-09-02-turbofish-in-the-blocksea/
submitted by Aimeedeer to rust [link] [comments]

Dash Core Group - Desperately Seeking Bankers

Introduction
This story starts with DCG and it’s relationship with Dr. Darren Tapp of ASU (Arizona State University). But Dr. Tapp does not stand alone, for there is a loose network of friends with a shared agenda, not only to make dash a regulator-friendly project but to wilfully weaken end-user privacy by upholding a principle of transparency-first.
More than ever, society is engaged in a war on privacy. And when it comes to financial transactions, DCG has taken the position of transparency-first. In sharp contrast, many other projects in this industry are either improving end-user privacy (decred, tezos etc), or actively pursuing privacy first (monero, beam etc).
As you may know, the scaling wars of the past revolved around block size, eventually giving way to “big blocker” projects like bitcoin cash and dash. By enforcing small blocks, Blockstream successfully syphoned off miner fees to the Lightning Network and it’s own Liquid Network. I believe we may be witnessing a similar event with dash. This time it’s not a scaling issue, it’s a privacy issue; transparency-first vs privacy-first.
The Power of Inaction
As many of you know, Dr. Darren Tapp is a research professor at ASU. And you may also be aware, in July 2019, the dash treasury paid ASU 345 dash for research into zero-knowledge proofs. Here’s an excerpt from the proposal along with the relevant link:

“This proposal seeks funding to renew our annual funding commitment to ASU’s Blockchain Research Lab and specifically to fund a research project which would investigate methods to apply zero-knowledge proofs to blockchain identities. It is possible Dash could leverage this research to apply zero-knowledge proofs to identity functions within the Dash network.”
https://www.dashcentral.org/p/dash-core-group-research

To date, there has been zero feedback from this project and, so far, all requests for an update have resulted in silence, including it’s omission from the DCG quarterly call.
I am particularly concerned by a seemingly gross contradiction. The result of this research into zero-knowledge proofs was to apply to blockchain identities but not to actual payments when they hit the dash blockchain. DCG and it’s proponents argue that privacy-first negates the ability to audit the chain for inflation. But if this was true, how can anyone argue with confidence that zero-knowledge proofs would only work with blockchain identities? It is, I say, a bit disingenuous to suggest it can work one way but not the other.
A Tapp Perspective
I now want to draw your attention to a recent interview between Joel Valenzuela and Dr. Darren Tapp on 8 May 2020:
https://www.youtube.com/watch?v=Tikj0O0xphE

Here is a particularly pertinent quote from Dr. Tapp:

@ 1:06:13 DT: “Well, I’ll just tell you my use case for dash, right. You’re talking about your use case. My use case for dash is, well, I’m not going to worry about the coffee guy thinking I have a whole bunch of money because I’m going to pay with my phone and I’m only going to keep a small amount on my phone, right? So that right there, they would have trouble you know, they have to go a few steps back and then they’re not even sure if it’s mine if there’s no Private Send. Um, if I don’t use Private Send. And if, let’s say, if I did want to take some money and put it into Coinbase. Well, if I don’t use Private Send and they’re asking “where’s the money came from?” - and that’s what they’re going to do - it’s going to be a little bit easier to say, “this is where it came from”, right?. I mean, I wouldn’t lie to them, I’d tell them the same thing no matter if I used Private Send or not, but I just think I’m going to have less problems with the bank and stuff if it wasn’t so obfuscated. So yeah, I think there’s a kind of, I think there needs to be room for both on chain. There needs to be.. I mean, I’m glad you’re enjoying Private Send. I think there are some improvements that can be made to Private Send. Umm, but I mean, there were some discussion of MimbleWimble and there is, no, we do not do that. No no no. But like, I mean, if you want to bring over some improvements, maybe start reading about the Cash Fusion that’s on the Bitcoin Cash. Umm, so err and like, I believe if you read Cash Fusion, their paper, I believe we can do Private Send in a way where the masternodes doesn’t know which output corresponds to which input. So, right now we trust that the masternodes aren’t paying attention, aren’t going to, you know… they’re... yeah I mean, and they have the word trust in it, they have a vested interest in the network working so that Private Send works the way it’s supposed to work. But, you know, at the same time, if you can do some small little cryptographic thing for no real cost on your processors and stuff like that, umm, why wouldn’t you? So that’s one thing I think that can be brought in. I think Cash Fusion also might do a better job of keeping the balance separate or something like that, but err., I would definitely be in favor of improving Private Send. Umm, but also at the same time, I’m glad that I’m given a choice if I want to use it or not. And pretty much anything when I’m interacting with the banking system, which I know you’re doing a fiat-free, so you don’t need to worry about that Joel.. but when you’re interacting with the banking system, the easier it is to explain to them, the better off, the easier time they’ll give you. That’s the way it is.”

In other words, Dr. Tapp’s priority is transparency-first for the benefit of the banking system.
What I found particularly interesting was Dr. Tapp’s body language. While he was making the above statement, at 1:07:04 he says, “I wouldn’t lie to them [the bank]” and at this exact same moment he goes to touch his face and pulls back. This is a body language clue that he’s lying or somewhat anxious about saying this. This doesn’t mean he is actually lying because with body language you normally need multiple clues to be sure, but having watched it multiple times, I am personally more convinced than not that he was in fact lying or anxious.
Dr. Tapp has outright rejected MimbleWimble, which is fine because MW is just one of several privacy enhancing technologies. But given the complete lack of feedback regarding zero-knowledge proofs from ASU. And given Dr. Tapp’s stance on transparency-first for the benefit of the banking system, I am wondering if there’s more to this than just one person’s opinion on the matter.
The Yes Chain
DCG asserts that dash has fewer privacy features than bitcoin. To make this case, considerable effort has been made to educate exchanges and regulators:
https://blog.dash.org/dash-complies-with-the-financial-action-task-force-fatf-guidelines-including-the-travel-rule-a4c658efc89d

According to DCG, the benefits of a transparency-first approach are:
a) Transaction monitoring
b) Identifying and blocking transactions that utilized mixing, or are in close proximity of known bad actors or sanctioned wallet addresses.
c) Track anonymity enhanced convertible virtual currencies and wallet addresses sending more private transactions.
d) This means that the VASP can choose to identify, block, and report on all transactions sent with Dash PrivateSend and can track and report on all the components of a mixed transaction.
e) Reporting on your users’ blockchain transactions
f) Establish an automated record keeping system for suspicious activity
g) Activity reporting, customer due diligence, and currency transaction reporting.
h) Track anonymity enhanced convertible virtual currencies and wallet addresses sending more private transactions.
i) Customizable risk scoring

Clearly, the scoring / ranking of coin histories (“risk assessment”) is producing a situation where some coins are more worthy than others.
Let us also consider the recent initiative to get dash re-listed on Japanese exchanges at a cost of 428 dash: https://app.dashnexus.org/proposals/listing-dash-in-japan/overview
Coinfirm-ation
For a number of years, in pursuit of regulatory approval, DCG has been courting chain analysis companies. This started in August 2016 when Robert Wiecko (Dash COO) was invited to attend a bitcoin meetup in Warsaw where he met Pawel Kuskowski (CEO and co-founder of Coinfirm) . Here is the original proposal along with the subsequent Coinfirm interview with Amanda B Johnson:
https://www.dash.org/forum/threads/dash-on-warsaw-block-on-25-08-2016.10211/
https://www.youtube.com/watch?v=KJOhIkeK3Ho

Mr Wiecko’s original proposal failed to mention any relationship or intention to engage with chain analysis companies. Nor was it mentioned that this meetup itself was sponsored by Coinfirm. It comes with little surprise that Robert Wiecko does, in fact, have some experience working with compliance (see @ 27:05 of Amanda’s video).

“Btw, we have, both of us have a compliance background. My last job was with [inaudible] bank, before that within a banking compliance department”

Block the Blockchain
Karen Hsu has a long history with dash. Formally from BlockCypher, she helped dash with various integrations, including Payza. She is now CEO of BlockchainIntel and in April 2020, she helped to facilitate an integration with Reciprocity Trading.
https://blog.dash.org/dash-core-group-reciprocity-trading-and-blockchainintel-focus-on-transparency-in-digital-currency-7a71c8ff84ec

“As more people will be interacting online now and potentially in the future, it will be increasingly important to provide transparency so people can trust those they cannot see,”

Karen is interested in blockchain, machine learning and analytics. And in 2018 she worked with various law enforcement agencies to help track and trace five million dollars worth of dash, allegedly stolen from a retired couple:
https://medium.com/@karenhsumaif-you-have-digital-evidence-for-a-theft-whats-holding-up-justice-e7ebf99eddf0

“The thieves didn’t move the funds right away. A couple months after the initial theft, they started to move the funds to multiple wallet addresses across the world. During their hundreds of transfers, the thieves converted the Dash into other cryptocurrencies. We were able to track their every transfer, whether it was from one Dash address to another, or from a Dash address into another cryptocurrency. In the end, the thieves had transferred the stolen Dash into hundreds of different wallet addresses and exchanged the Dash for Bitcoin, Ether and Bitcoin Cash.
We collaborated with the FBI and traced the funds to an exchange in Asia. Through our connections with that exchange, law enforcement was able to obtain details of the account owner, which led to a bank account. By September 2018, three months after the theft, our tools and collaboration with law enforcement had identified a person involved in this theft. At that point, the victims, law enforcement and us at BlockchainIntel were hopeful there would be some recovery of stolen funds. But that’s when things slowed down. A lot.”

The narrative is clear; an innocent couple were victims of financial crime. Did the thief use Private Send? Was the thief dumb enough not to use Private Send? Is this the type of scenario that Dr. Tapp endorses for transparency-first when dealing with a financial institution?
In contrast, let us take a look at a story from January 2017 by NIAC (National Iranian American Council):
https://www.niacouncil.org/press_room/niac-concerned-u-s-banks-denying-financial-services-iranians-u-s/

“Over the past few years, Iranian visa-holders resident in the United States have seen their bank accounts at U.S. financial institutions shuttered as a result of U.S. sanctions. The most recent case is that of Chase Bank, where NIAC has learned that Chase is closing the bank accounts of Iranian visa-holders. NIAC is deeply concerned that U.S. banks are denying financial services to Iranians in the United States on the basis of their national origin and calls on Chase Bank and other U.S. financial institutions to cease and desist from such discriminatory policies. At the same time, NIAC believes that the repeated nature of these account closures makes it incumbent on the U.S. administration to take immediate steps to provide clarity as to the scope of existing U.S. sanctions laws — none of which bar U.S. banks from opening and maintaining accounts for Iranian visa-holders resident in the United States.”

Great! Who needs banks when Iranians can use dash! But then again, what if the recent history of your dash coins was linked to an innocent Iranian, disqualified and excluded by sanctions?
Closing
A global peer-to-peer electronic cash system needs to be cheap, fast and very easy to use. Dash’s technical ability to meet demand is very much in sight and the Velocity protocol certainly seems promising. But digital cash also requires a high degree of fungibility. The less fungibility there is, the more discretion and division it sows. The path of a coin should not unduly taint a person’s reputation.
Incremental improvements have been made to Private Send but it is today, fundamentally, the same as it was six years ago. Mixing takes a long time and the user requires knowledge to use it in a safe manner. For example, external actors proactively breaking VPN connections to reveal the underlying IP address during mixing.
A poor user experience is probably why Private Send isn’t used very much and that seems like a very convenient situation for those people actively pursuing regulatory approval. I have to wonder, has the internal workings of DCG been compromised by state level actors? Is this why key members of DCG have refused to undergo a polygraph test?
submitted by circleio to dashpay [link] [comments]

Getting closer to purchasing first BTC - help on available options

So I have browsed many of the posts on this forum and have come up with some options/tentative options and am looking for thoughts and input from the community. After careful thought my base line requirements:
  1. Would like to be able to access account on either desktop or mobile (not a deal breaker). If I had to choose will go with mobile wallet (saved on external storage in case phone is damaged)
  2. While I will start out with only bitcoin I would like the option to be able to purchase multiple cryptos on an exchange and transfer to a wallet.
  3. Security is obviously very important along with exchanges and wallets that have longevity.
  4. Longevity is also key as I plan on primarily holding bitcoin for the long term, so a wallet that will be around 10 years from now will be nice. Understand the industry will evolve and this may not be predictable.
  5. If a wallet does disappear, I am assuming my BTC (or other crypto currency) would be recoverable using another wallet. However, a lot of the tutorials mentioned to recover your bitcoin, the private I would have would have to match the private key from the wallet to ensure your BTC was recoverable. While I did consider a cold storage device, it appears most on the market currently support bitcoin (I could be completely wrong on this) and may make that leap later in my journey.
  6. Understand there will be fees but lower fees are better.
In order to meet all the requirements I listed above I have narrowed it down to the following:
Exchanges:
Cash App - can only buy BTC
Coin Base - multiple cryptos. Have read fees are variable, high and/or hard to assess.
Uphold - looks to meet all the requirements above, but have not seen it mentioned here.
Wallets:
Coinbase Wallet
Trust Wallet
MetMask
MyEtherWallet
Green Wallet
Samourai Wallet
Would appreciate any and all thoughts from the community!
submitted by 2013gtr to BitcoinBeginners [link] [comments]

Bull Bitcoin’s Dollar-Cost Averaging tool for Canadians: a detailed overview

Hello fellow Canadian Bitcoiners!
I'm Francis Pouliot, CEO and founder of Bull Bitcoin (previously known as Bitcoin Outlet) and Bylls.
I haven't been active on Reddit for a while but I thought I'd pop back here to let the community know about our new dollar-cost averaging feature, "Recurring Buy"
This post is a copy of my most recent medium article which you can read here if you want to see the screenshots. https://medium.com/bull-bitcoin/bull-bitcoins-dollar-cost-averaging-tool-for-canadians-the-right-time-to-buy-bitcoin-is-every-day-82a992ca22c1
Thanks in advance for any feedback and suggestions!
[Post starts here]
The Bull Bitcoin team is constantly trying to reduce the frictions ordinary people face when investing in Bitcoin and propose innovative features which ensure our users follow Bitcoin best practices and minimize their risks.
We are particularly excited and proud about our latest feature: an automated Bitcoin dollar-cost averaging tool which we dubbed “Recurring Buy”.
The Recurring Buy feature lets Bull Bitcoin users create an automated schedule that will buy Bitcoin every day using the funds in their account balance and send the Bitcoin directly to their Bitcoin wallet straight away.
We put a lot of thought in the implementation details and striking the right trade-offs for a simple and elegant solution. Our hope is that it will become a standard other Bitcoin exchanges will emulate for the benefit of their users. This standard will certainly evolve over time as we accumulate feedback and operational experience.
In this article, I cover:
The problem that we are trying to solve
Recurring Buy feature details, processes and instructions
The rationale (and tradeoffs) behind the main feature design choices
Bull Bitcoin is only available to Canadians, but non-Canadians that wish to have a look at how it works are welcome to make a Bull Bitcoin account and check out how it works here. You will be able to go through the process of create the schedule for testing purposes, but you wont be able to fund your account and actually purchase Bitcoin.
What problems does Dollar-Cost Averaging solve?
The most common concern of Bitcoin investors is, not surprisingly, “when is the right time to buy Bitcoin?”. Bitcoin is indeed a very volatile asset. A quick glance at a Bitcoin price chart shows there are without a doubt “worse times” and “better times” to invest in Bitcoin. But is that the same as the “right” time?
Gurus, analysts and journalists continuously offer their theories explaining what affects the Bitcoin price, supported by fancy trading charts and geopolitical analysis, further reinforcing the false notion that it is possible to predict the price of Bitcoin.
Newbies are constantly bombarded with mainstream media headlines of spectacular gains and devastating losses. For some, this grows into an irresistible temptation to get rich quick. Others become crippled with the fear of becoming “the sucker” on which early adopters dump their bags.
Veterans are haunted by past Bitcoin purchases which were quickly followed by a crash in the price. “I should have waited to buy the dip…”
Many Bitcoin veterans and long-term investors often shrug off the question of when is the right time to buy with the philosophy: “just hodl”. But even those holding until their death will recognize that buying more Bitcoin for the same price is a better outcome.
Given the very high daily volatility of Bitcoin, a hodler can find himself in many years having significantly less wealth just because he once bought Bitcoin on a Monday instead of a Wednesday. His options are either to leave it up to chance or make an attempt to “time the market” and “buy the dip”, which can turn into a stressful trading obsession, irrational decisions (which have a negative impact on budget, income and expenses) and severe psychological trauma. In addition, trying to “buy the dip” is often synonymous to keeping large amounts of fiat on an exchange to be ready for “when the time comes”.
There must be a better way.
Bitcoin investors should be rewarded for having understood Bitcoin’s long-term value proposition early on, for having taken the risk to invest accordingly and for having followed best practices. Not for being lucky.
Overview of features and rules
In this section I go into every detail of the Recurring Buy feature. In the following section, I focus on explaining why we chose this particular user experience.
The user first decides his target investment amount. Ideally, this is a monthly budget or yearly budget he allocates to investing in Bitcoin based on his projected income and expenses.
The user then chooses either the duration of the Recurring Buy schedule or the daily purchase amount. The longer the better.
The frequency is each day and cannot be modified.
The user must submit a Bitcoin address before activating a Recurring Buy schedule. By default, every transaction will be sent to that Bitcoin address. It’s the fallback address in case they don’t provide multiple addresses later.
Once the user has filled the form with target amount, the duration and the Bitcoin address, he can activate the Recurring Buy Schedule.
The user is not required to already have funds in his account balance to activate the schedule.
We will randomly select a time of day at which his transaction will be processed (every hour, so 24 possible times). If the user insists on another time of day, he can cancel his Recurring Buy schedule and try again.


The Recurring Buy feature as displayed on bullbitcoin.com/recurring-buys
The schedule is then displayed to the user, showing the time and date at which transactions that will take place in the future. The user will be able to see how long his current balance will last.
He can follow the progress of the dollar-cost averaging schedule, monitor in real time his average acquisition cost, and audit each transaction individually.
At this point, the user can and should change the Bitcoin address of his next transactions to avoid address re-use. Address re-use is not forbidden, but it is highly discouraged.
After having modified the Bitcoin addresses, there is nothing left for the user to do except watch the bitcoins appear in his Bitcoin wallet every day!
The Bitcoins are sent right away at the time of purchase.
Bitcoin transactions using the Recurring Buy feature will have the lowest possible Bitcoin network transaction fee to avoid creating upwards pressure on the fee market impact other network users.


What users see after first activating a schedule
The Recurring Buy schedule will be cancelled automatically at the time of the next purchase if the balance is insufficient. He can add more funds to his balance whenever he wants.
The Recurring Buy schedule will continue until the target amount is reached or until the account balance runs out.
The user can cancel his Recurring Buy schedule whenever he wants.
If the user wants to change the amount or duration of the schedule, he can simply cancel his current schedule and create a new one.
Each schedule has a unique identifier so that users can keep track of various schedules they perform over time.
Once a schedule is completed, either fully or partially, a summary will be provided which shows the number of transactions completed, the average acquisition cost, the total amount of Bitcoin purchase and the total amount of fiat spent. Useful for accounting!


A partially completed Recurring Buy schedule cancelled after 9 days due to insufficient funds
Though process in making our design choices
Recurring Bitcoin Purchases vs. Recurring Payment/Funding
The first and most important design choice was to separate the processes of funding the account balance with fiat (the payment) from the process of buying Bitcoin (the purchase). Users do not need to make a bank transaction every time they do a Bitcoin purchase. They first fund their account manually on their own terms, and the recurring purchases are debited from their pre-funded account balance.
Another approach would have been to automatically withdraw fiat from the user’s bank account (e.g. a direct debit or subscription billing) for each transaction (like our friends at Amber) or to instruct the user to set-up recurring payments to Bull Bitcoin from their bank account (like our friends at Bittr). The downside of these strategies is that they require numerous bank transactions which increases transaction fees and the likelihood of triggering fraud and compliance flags at the user’s bank. However, this does remove the user’s need to keep larger amounts of fiat on the exchange and reduces the friction of having to make manual bank payments.
Bull Bitcoin is currently working on a separate “Recurring Funding” feature that will automatically debit fiat from the user’s bank accounts using a separate recurring schedule with a minimum frequency of once a week, with a target of once every two weeks or once a month to match the user’s income frequency. This can, and will, be used in combination from the “Recurring Buy” feature, but both can be used separately.
The ultimate experience that we wish to achieve is that users will automatically set aside, each paycheck (two weeks), a small budget to invest in Bitcoin using the “Recurring Funding” feature which is sufficient to refill their account balance for the next two weeks of daily recurring purchases.
Frequency of transactions
The second important decision was about customizing the frequency of the schedule. We decided to make it “each day” only. This is specifically to ensure users have a large enough sample size and remain consistent which are the two key components to a successful dollar-cost averaging strategy.
A higher amount of recurring transactions (larger sample size) will result in the user’s average acquisition being closer to the actual average Bitcoin price over that period of time. Weekly or monthly recurring purchases can provide the same effectiveness if they are performed over a duration of time which is 7x longer (weekly) or 30x longer (monthly).
It is our belief that the longer the duration of the schedule, the more likely the user is to cancel the recurring buy schedule in order to “buy the dip”. Dollar-cost averaging is boring, and watching sats appear in the wallet every day is a good way to reduce the temptation of breaking the consistency.
We do not force this on users: they can still cancel the schedule if they want and go all-in. We consider it more of a gentle nudge in the right direction.
Frequency of withdrawals (one purchase = one bitcoin transaction)
This is one of the most interesting design choices because it is a trade-off between scalability (costs), privacy and custody. Ultimately, we decided that trust-minimization (no custody) and privacy were the most important at the expense of long-term scalability and costs.
Realistically, Bitcoin network fees are currently low and we expect them to remain low for the near future, although they will certainly increase massively over the long-term. One of the ways we mitigated this problem was to select the smallest possible transaction fee for transactions done in the context of Recurring Buy, separate from regular transaction fees on regular Bitcoin purchases (which, at Bull Bitcoin, are very generous).
Note: users must merge their UTXOs periodically to avoid being stuck with a large amount of small UTXOs in the future when fees become more expensive. This is what makes me most uncomfortable about our solution. I hope to also solve this problem, but it is ultimately something Bitcoin wallets need to address as well. Perhaps an automated tool in Bitcoin wallets which merges UTXOs periodically when the fees are low? Food for thought.
When transaction fees and scalability becomes a problem for us, it will have become a problem for all other small payments on the Bitcoin network, and we will use whatever solution is most appropriate at that time.
It is possible that Lightning Network ends up being the scalability solution, although currently it is logistically very difficult to perform automated payouts to users using Lightning, particularly recurring payouts, which require users to create Bolt11 invoices and to convince other peers in the network to open channels and fund channels with them for inbound capacity.
These are the general trade-offs:
Send a Bitcoin transaction for every purchase (what we do) - Most expensive for the exchange - Most expensive for the user (many UTXOs) - Increases Bitcoin Network UTXOs set - Inefficient usage of block space - Most private - Zero custody risk
Keep custody of the Bitcoin until the schedule is over or when the user requests a withdrawal (what Coinbase does) - No additional costs -No blockchain bloating - Same level of privacy - High custody risk
Batch user transactions together at fixed intervals (e.g. every day) - Slightly lower transaction costs for the exchange - Same costs for the user - Slightly more efficient use of block space - Same level of UTXO set bloating - Much lower level of privacy - Slightly higher custody risk
Single address vs multiple addresses vs HD keys (xpubs)
The final decision we had to make was preventing address re-use and allowing users to provide an HD key (xpub) rather than a Bitcoin address.
Address re-use generally decreases privacy because it becomes possible for third-party blockchain snoops to figure out that multiple Bitcoin transactions are going to the same user. But we must also consider that even transactions are sent to multiple addresses, particularly if they are small amounts, it is highly likely that the user will “merge” the coins into a single transaction when spending from his wallet. It is always possible for users to prevent this using Coinjoin, in which there is a large privacy gain in not re-using addresses compared to using a single address.
It is important to note that this does not decrease privacy compared to regular Bitcoin purchases on Bull Bitcoin outside of “Recurring Buy”. Whether a user has one transaction of $1000 going to a Bitcoin address or 10x$100 going that same Bitcoin address doesn’t reveal any new information about the user other than the fact he is likely using a dollar-cost averaging mechanism. It is rather a missed opportunity to gain more privacy.
Another smaller decision was whether or not we should ask the user to provide all his addresses upfront before being able to activate the schedule, which would completely remove the possibility of address re-use. We ultimately decided that because this process can take a very long time (imagine doing Recurring Buy every day for 365 days) it is better to let the user do this at his own pace, particularly because he may eventually change his Bitcoin wallet and forget to change the addresses in the schedule.
There are also various legitimate use-cases where users have no choice but to re-use the same address . A discussion for another day!
Asking the user to provide an XPUB is a great solution to address re-use. The exchange must dynamically derive a new Bitcoin address for the user at each transaction, which is not really a technical challenge. As far as I can tell, Bittr is the only Bitcoin exchange exchange which has implemented this technique. Kudos!
It is however important that the user doesn’t reuse this XPUB for anything else, otherwise the exchange can track his entire wallet balance and transaction history.
It is worth noting that not all wallets support HD keys or have HD keys by default (e.g. Bitcoin Core). So it is imperative that we offer the option to give Bitcoin addresses. We believe there is a lot of potential to create wallet coordination mechanisms between senders and recipients which would make this process a lot more streamlined.
In the future, we will certainly allow users to submit an XPUB instead of having to manually input a different address. But for now, we wanted to reduce the complexity to a minimum.
Conclusion: personal thoughts
I have a somewhat unique perspective on Bitcoin users due to the fact that I worked at the Bitcoin Embassy for almost 4 years. During this time, I had the opportunity to discuss face-to-face with thousands of Bitcoin investors. One of my favourite anecdotes is a nocoiner showing up at our office in December 2013 with a bag full of cash attempting to buy Bitcoin, “I know how to read a chart”, furious after being turned away. Many people who went “all-in” for short-term gains (usually altcoins) would show up to the Bitcoin Embassy office months later with heart-breaking stories.
This isn’t what I signed up for. My goal is to help people opt-out of fiat and, ultimately, to destroy the fiat currency system entirely.
This instilled in me a deep-rooted concern for gambling addiction and strong aversion to “trading”. I do not believe that Bitcoin exchanges should blindly follow “what the market dictates”. More often than not, what dictates the market is bad habits users formed because of the other Bitcoin services they used in the past, what other people are used to, and what feels familiar. Running a Bitcoin company should be inseparable from educating users on the best practices, and embedding these best practices into the user experience is the best way for them to learn.
Another important anecdote which motivated me to build a dollar-cost averaging tool is a person very close to me that had made the decision to buy Bitcoin, but was so stressed out about when was the right time to buy that they ended up not buying Bitcoin for a whole 6 months after funding their Bull Bitcoin account. That person eventually gave up and ultimately invested a large amount all at once. In hindsight, it turned out to be one of the worst possible times to invest in Bitcoin during that year.
Investing in Bitcoin can, and should be, a positive and rewarding experience.
Buying Bitcoin every day is the right strategy, but it is not necessarily lead to the best outcome.
The reality is that the best time to buy Bitcoin is at when market hits rock bottom (obviously). Sometimes, the upside from buying the dip can be much bigger than the risk (e.g. when the price dropped below $200 in 2015). But these are exceptions rather than the rule. And the cost of chasing dips is very high: stress, investing time and mental energy, and the very real psychological trauma which results from making bad trading decisions. Ultimately, it’s better to do the right thing than being lucky, but it’s not always a bad idea to cheat on your dollar-cost averaging from time to time if you can live with the costs and consequences.
Yours truly,
Francis
submitted by FrancisPouliot to BitcoinCA [link] [comments]

ICON is about to take off. Here's why ...

This post is primarily about a solid uptick in community involvement, decentralized marketing, and the token side of things.
For the last year and a half we live had a pretty uninvolved community, while the company continued to work under the hood to build something huge.
A lot is happening right now. I feel like nobody knows about it, so a Reddit post was warranted. It just started. Most of it. So your patience will be appreciated. But I’ve never seen so much proactivity in this project on the token-side of things before.
My point in writing this: A LOT is coming in the next 8 to 12 weeks. All of this is centered around recovering and catapulting the price as high as it can possibly go. ICON is seeking out the all-stars in this industry with incredibly resumes, and asking the experts for direction and input.
All of the marketing and promotion has just barely begun. Everything is at ground zero. But its finally happening. All the things we've been hoping for, for a year and a half.
submitted by BitttBurger to helloicon [link] [comments]

A technical dive into CTOR

Over the last several days I've been looking into detail at numerous aspects of the now infamous CTOR change to that is scheduled for the November hard fork. I'd like to offer a concrete overview of what exactly CTOR is, what the code looks like, how well it works, what the algorithms are, and outlook. If anyone finds the change to be mysterious or unclear, then hopefully this will help them out.
This document is placed into public domain.

What is TTOR? CTOR? AOR?

Currently in Bitcoin Cash, there are many possible ways to order the transactions in a block. There is only a partial ordering requirement in that transactions must be ordered causally -- if a transaction spends an output from another transaction in the same block, then the spending transaction must come after. This is known as the Topological Transaction Ordering Rule (TTOR) since it can be mathematically described as a topological ordering of the graph of transactions held inside the block.
The November 2018 hard fork will change to a Canonical Transaction Ordering Rule (CTOR). This CTOR will enforce that for a given set of transactions in a block, there is only one valid order (hence "canonical"). Any future blocks that deviate from this ordering rule will be deemed invalid. The specific canonical ordering that has been chosen for November is a dictionary ordering (lexicographic) based on the transaction ID. You can see an example of it in this testnet block (explorer here, provided this testnet is still alive). Note that the txids are all in dictionary order, except for the coinbase transaction which always comes first. The precise canonical ordering rule can be described as "coinbase first, then ascending lexicographic order based on txid".
(If you want to have your bitcoin node join this testnet, see the instructions here. Hopefully we can get a public faucet and ElectrumX server running soon, so light wallet users can play with the testnet too.)
Another ordering rule that has been suggested is removing restrictions on ordering (except that the coinbase must come first) -- this is known as the Any Ordering Rule (AOR). There are no serious proposals to switch to AOR but it will be important in the discussions below.

Two changes: removing the old order (TTOR->AOR), and installing a new order (AOR->CTOR)

The proposed November upgrade combines two changes in one step:
  1. Removing the old causal rule: now, a spending transaction can come before the output that it spends from the same block.
  2. Adding a new rule that fixes the ordering of all transactions in the block.
In this document I am going to distinguish these two steps (TTOR->AOR, AOR->CTOR) as I believe it helps to clarify the way different components are affected by the change.

Code changes in Bitcoin ABC

In Bitcoin ABC, several thousand lines of code have been changed from version 0.17.1 to version 0.18.1 (the current version at time of writing). The differences can be viewed here, on github. The vast majority of these changes appear to be various refactorings, code style changes, and so on. The relevant bits of code that deal with the November hard fork activation can be found by searching for "MagneticAnomaly"; the variable magneticanomalyactivationtime sets the time at which the new rules will activate.
The main changes relating to transaction ordering are found in the file src/validation.cpp:
There are other changes as well:

Algorithms

Serial block processing (one thread)

One of the most important steps in validating blocks is updating the unspent transaction outputs (UTXO) set. It is during this process that double spends are detected and invalidated.
The standard way to process a block in bitcoin is to loop through transactions one-by-one, removing spent outputs and then adding new outputs. This straightforward approach requires exact topological order and fails otherwise (therefore it automatically verifies TTOR). In pseudocode:
for tx in transactions: remove_utxos(tx.inputs) add_utxos(tx.outputs) 
Note that modern implementations do not apply these changes immediately, rather, the adds/removes are saved into a commit. After validation is completed, the commit is applied to the UTXO database in batch.
By breaking this into two loops, it becomes possible to update the UTXO set in a way that doesn't care about ordering. This is known as the outputs-then-inputs (OTI) algorithm.
for tx in transactions: add_utxos(tx.outputs) for tx in transactions: remove_utxos(tx.inputs) 
Benchmarks by Jonathan Toomim with Bitcoin ABC, and by myself with ElectrumX, show that the performance penalty of OTI's two loops (as opposed to the one loop version) is negligible.

Concurrent block processing

The UTXO updates actually form a significant fraction of the time needed for block processing. It would be helpful if they could be parallelized.
There are some concurrent algorithms for block validation that require quasi-topological order to function correctly. For example, multiple workers could process the standard loop shown above, starting at the beginning. A worker temporarily pauses if the utxo does not exist yet, since it's possible that another worker will soon create that utxo.
There are issues with such order-sensitive concurrent block processing algorithms:
In contrast, the OTI algorithm's loops are fully parallelizable: the worker threads can operate in an independent manner and touch transactions in any order. Until recently, OTI was thought to be unable to verify TTOR, so one reason to remove TTOR was that it would allow changing to parallel OTI. It turns out however that this is not true: Jonathan Toomim has shown that TTOR enforcement is easily added by recording new UTXOs' indices within-block, and then comparing indices during the remove phase.
In any case, it appears to me that any concurrent validation algorithm would need such additional code to verify that TTOR is being exactly respected; thus for concurrent validation TTOR is a hindrance at best.

Advanced parallel techniques

With Bitcoin Cash blocks scaling to large sizes, it may one day be necessary to scale onto advanced server architectures involving sharding. A lot of discussion has been made over this possibility, but really it is too early to start optimizing for sharding. I would note that at this scale, TTOR is not going to be helpful, and CTOR may or may not lead to performance optimizations.

Block propagation (graphene)

A major bottleneck that exists in Bitcoin Cash today is block propagation. During the stress test, it was noticed that the largest blocks (~20 MB) could take minutes to propagate across the network. This is a serious concern since propagation delays mean increased orphan rates, which in turn complicate the economics and incentives of mining.
'Graphene' is a set reconciliation technique using bloom filters and invertible bloom lookup tables. It drastically reduces the amount of bandwidth required to communicate a block. Unfortunately, the core graphene mechanism does not provide ordering information, and so if many orderings are possible then ordering information needs to be appended. For large blocks, this ordering information makes up the majority of the graphene message.
To reduce the size of ordering information while keeping TTOR, miners could optionally decide to order their transactions in a canonical ordering (Gavin's order, for example) and the graphene protocol could be hard coded so that this kind of special order is transmitted in one byte. This would add a significant technical burden on mining software (to create blocks in such a specific unusual order) as well as graphene (which must detect this order, and be able to reconstruct it). It is not clear to me whether it would be possible to efficiently parallelize sorting algortithms that reconstruct these orderings.
The adoption of CTOR gives an easy solution to all this: there is only one ordering, so no extra ordering information needs to be appended. The ordering is recovered with a comparison sort, which parallelizes better than a topological sort. This should simplify the graphene codebase and it removes the need to start considering supporting various optional ordering encodings.

Reversibility and technical debt

Can the change to CTOR be undone at a later time? Yes and no.
For block validators / block explorers that look over historical blocks, the removal of TTOR will permanently rule out usage of the standard serial processing algorithm. This is not really a problem (aside from the one-time annoyance), since OTI appears to be just as efficient in serial, and it parallelizes well.
For anything that deals with new blocks (like graphene, network protocol, block builders for mining, new block validation), it is not a problem to change the ordering at a later date (to AOR / TTOR or back to CTOR again, or something else). These changes would add no long term technical debt, since they only involve new blocks. For past-block validation it can be retroactively declared that old blocks (older than a few months) have no ordering requirement.

Summary and outlook

Taking a broader view, graphene is not the magic bullet for network propagation. Even with the CTOR-improved graphene, we might not see vastly better performance right away. There is also work needed in the network layer to simply move the messages faster between nodes. In the last stress test, we also saw limitations on mempool performance (tx acceptance and relaying). I hope both of these fronts see optimizations before the next stress test, so that a fresh set of bottlenecks can be revealed.
submitted by markblundeberg to btc [link] [comments]

12-13 15:04 - 'Read this went the opposite way' (self.Bitcoin) by /u/fukya40 removed from /r/Bitcoin within 38-48min

'''
// Copyright (c) 2008 Satoshi Nakamoto // // Permission is hereby granted, free of charge, to any person obtaining a copy // of this software and associated documentation files (the "Software"), to deal // in the Software without restriction, including without limitation the rights // to use, copy, modify, merge, publish, distribute, sublicense, and/or sell // copies of the Software, and to permit persons to whom the Software is // furnished to do so, subject to the following conditions: // // The above copyright notice and this permission notice shall be included in // all copies or substantial portions of the Software. // // THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR // IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, // FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT // SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR // OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING // FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS // IN THE SOFTWARE.
class COutPoint; class CInPoint; class CDiskTxPos; class CCoinBase; class CTxIn; class CTxOut; class CTransaction; class CBlock; class CBlockIndex; class CWalletTx; class CKeyItem;
static const unsigned int MAX_SIZE = 0x02000000; static const int64 COIN = 1000000; static const int64 CENT = 10000; static const int64 TRANSACTIONFEE = 1 * CENT; /// change this to a user options setting, optional fee can be zero ///static const unsigned int MINPROOFOFWORK = 40; /// need to decide the right difficulty to start with static const unsigned int MINPROOFOFWORK = 20; /// ridiculously easy for testing
extern map mapBlockIndex; extern const uint256 hashGenesisBlock; extern CBlockIndex* pindexGenesisBlock; extern int nBestHeight; extern CBlockIndex* pindexBest; extern unsigned int nTransactionsUpdated; extern int fGenerateBitcoins;
FILE* OpenBlockFile(unsigned int nFile, unsigned int nBlockPos, const char* pszMode="rb"); FILE* AppendBlockFile(unsigned int& nFileRet); bool AddKey(const CKey& key); vector GenerateNewKey(); bool AddToWallet(const CWalletTx& wtxIn); void ReacceptWalletTransactions(); void RelayWalletTransactions(); bool LoadBlockIndex(bool fAllowNew=true); bool BitcoinMiner(); bool ProcessMessages(CNode* pfrom); bool ProcessMessage(CNode* pfrom, string strCommand, CDataStream& vRecv); bool SendMessages(CNode* pto); int64 CountMoney(); bool CreateTransaction(CScript scriptPubKey, int64 nValue, CWalletTx& txNew); bool SendMoney(CScript scriptPubKey, int64 nValue, CWalletTx& wtxNew);
class CDiskTxPos { public: unsigned int nFile; unsigned int nBlockPos; unsigned int nTxPos;
CDiskTxPos() { SetNull(); }
CDiskTxPos(unsigned int nFileIn, unsigned int nBlockPosIn, unsigned int nTxPosIn) { nFile = nFileIn; nBlockPos = nBlockPosIn; nTxPos = nTxPosIn; }
IMPLEMENT_SERIALIZE( READWRITE(FLATDATA(*this)); ) void SetNull() { nFile = -1; nBlockPos = 0; nTxPos = 0; } bool IsNull() const { return (nFile == -1); }
friend bool operator==(const CDiskTxPos& a, const CDiskTxPos& b) { return (a.nFile == b.nFile && a.nBlockPos == b.nBlockPos && a.nTxPos == b.nTxPos); }
friend bool operator!=(const CDiskTxPos& a, const CDiskTxPos& b) { return !(a == b); }
void print() const { if (IsNull()) printf("null"); else printf("(nFile=%d, nBlockPos=%d, nTxPos=%d)", nFile, nBlockPos, nTxPos); } };
class CInPoint { public: CTransaction* ptx; unsigned int n;
CInPoint() { SetNull(); } CInPoint(CTransaction* ptxIn, unsigned int nIn) { ptx = ptxIn; n = nIn; } void SetNull() { ptx = NULL; n = -1; } bool IsNull() const { return (ptx == NULL && n == -1); } };
class COutPoint { public: uint256 hash; unsigned int n;
COutPoint() { SetNull(); } COutPoint(uint256 hashIn, unsigned int nIn) { hash = hashIn; n = nIn; } IMPLEMENT_SERIALIZE( READWRITE(FLATDATA(*this)); ) void SetNull() { hash = 0; n = -1; } bool IsNull() const { return (hash == 0 && n == -1); }
friend bool operator<(const COutPoint& a, const COutPoint& b) { return (a.hash < b.hash || (a.hash == b.hash && a.n < b.n)); }
friend bool operator==(const COutPoint& a, const COutPoint& b) { return (a.hash == b.hash && a.n == b.n); }
friend bool operator!=(const COutPoint& a, const COutPoint& b) { return !(a == b); }
void print() const { printf("COutPoint(%s, %d)", hash.ToString().substr(0,6).c_str(), n); } };
// // An input of a transaction. It contains the location of the previous // transaction's output that it claims and a signature that matches the // output's public key. // class CTxIn { public: COutPoint prevout; CScript scriptSig;
CTxIn() { }
CTxIn(COutPoint prevoutIn, CScript scriptSigIn) { prevout = prevoutIn; scriptSig = scriptSigIn; }
CTxIn(uint256 hashPrevTx, unsigned int nOut, CScript scriptSigIn) { prevout = COutPoint(hashPrevTx, nOut); scriptSig = scriptSigIn; }
IMPLEMENT_SERIALIZE ( READWRITE(prevout); READWRITE(scriptSig); )
bool IsPrevInMainChain() const { return CTxDB("r").ContainsTx(prevout.hash); }
friend bool operator==(const CTxIn& a, const CTxIn& b) { return (a.prevout == b.prevout && a.scriptSig == b.scriptSig); }
friend bool operator!=(const CTxIn& a, const CTxIn& b) { return !(a == b); }
void print() const { printf("CTxIn("); prevout.print(); if (prevout.IsNull()) { printf(", coinbase %s)\n", HexStr(scriptSig.begin(), scriptSig.end(), false).c_str()); } else { if (scriptSig.size() >= 6) printf(", scriptSig=%02x%02x", scriptSig[4], scriptSig[5]); printf(")\n"); } }
bool IsMine() const; int64 GetDebit() const; };
// // An output of a transaction. It contains the public key that the next input // must be able to sign with to claim it. // class CTxOut { public: int64 nValue; unsigned int nSequence; CScript scriptPubKey;
// disk only CDiskTxPos posNext; //// so far this is only used as a flag, nothing uses the location
public: CTxOut() { nValue = 0; nSequence = UINT_MAX; }
CTxOut(int64 nValueIn, CScript scriptPubKeyIn, int nSequenceIn=UINT_MAX) { nValue = nValueIn; scriptPubKey = scriptPubKeyIn; nSequence = nSequenceIn; }
IMPLEMENT_SERIALIZE ( READWRITE(nValue); READWRITE(nSequence); READWRITE(scriptPubKey); if (nType & SER_DISK) READWRITE(posNext); )
uint256 GetHash() const { return SerializeHash(*this); }
bool IsFinal() const { return (nSequence == UINT_MAX); }
bool IsMine() const { return ::IsMine(scriptPubKey); }
int64 GetCredit() const { if (IsMine()) return nValue; return 0; }
friend bool operator==(const CTxOut& a, const CTxOut& b) { return (a.nValue == b.nValue && a.nSequence == b.nSequence && a.scriptPubKey == b.scriptPubKey); }
friend bool operator!=(const CTxOut& a, const CTxOut& b) { return !(a == b); }
void print() const { if (scriptPubKey.size() >= 6) printf("CTxOut(nValue=%I64d, nSequence=%u, scriptPubKey=%02x%02x, posNext=", nValue, nSequence, scriptPubKey[4], scriptPubKey[5]); posNext.print(); printf(")\n"); } };
// // The basic transaction that is broadcasted on the network and contained in // blocks. A transaction can contain multiple inputs and outputs. // class CTransaction { public: vector vin; vector vout; unsigned int nLockTime;
CTransaction() { SetNull(); }
IMPLEMENT_SERIALIZE ( if (!(nType & SER_GETHASH)) READWRITE(nVersion);
// Set version on stream for writing back same version if (fRead && s.nVersion == -1) s.nVersion = nVersion;
READWRITE(vin); READWRITE(vout); READWRITE(nLockTime); )
void SetNull() { vin.clear(); vout.clear(); nLockTime = 0; }
bool IsNull() const { return (vin.empty() && vout.empty()); }
uint256 GetHash() const { return SerializeHash(*this); }
bool AllPrevInMainChain() const { foreach(const CTxIn& txin, vin) if (!txin.IsPrevInMainChain()) return false; return true; }
bool IsFinal() const { if (nLockTime == 0) return true; if (nLockTime < GetAdjustedTime()) return true; foreach(const CTxOut& txout, vout) if (!txout.IsFinal()) return false; return true; }
bool IsUpdate(const CTransaction& b) const { if (vin.size() != b.vin.size() || vout.size() != b.vout.size()) return false; for (int i = 0; i < vin.size(); i++) if (vin[i].prevout != b.vin[i].prevout) return false;
bool fNewer = false; unsigned int nLowest = UINT_MAX; for (int i = 0; i < vout.size(); i++) { if (vout[i].nSequence != b.vout[i].nSequence) { if (vout[i].nSequence <= nLowest) { fNewer = false; nLowest = vout[i].nSequence; } if (b.vout[i].nSequence < nLowest) { fNewer = true; nLowest = b.vout[i].nSequence; } } } return fNewer; }
bool IsCoinBase() const { return (vin.size() == 1 && vin[0].prevout.IsNull()); }
bool CheckTransaction() const { // Basic checks that don't depend on any context if (vin.empty() || vout.empty()) return false;
// Check for negative values int64 nValueOut = 0; foreach(const CTxOut& txout, vout) { if (txout.nValue < 0) return false; nValueOut += txout.nValue; }
if (IsCoinBase()) { if (vin[0].scriptSig.size() > 100) return false; } else { foreach(const CTxIn& txin, vin) if (txin.prevout.IsNull()) return false; }
return true; }
bool IsMine() const { foreach(const CTxOut& txout, vout) if (txout.IsMine()) return true; return false; }
int64 GetDebit() const { int64 nDebit = 0; foreach(const CTxIn& txin, vin) nDebit += txin.GetDebit(); return nDebit; }
int64 GetCredit() const { int64 nCredit = 0; foreach(const CTxOut& txout, vout) nCredit += txout.GetCredit(); return nCredit; }
int64 GetValueOut() const { int64 nValueOut = 0; foreach(const CTxOut& txout, vout) { if (txout.nValue < 0) throw runtime_error("CTransaction::GetValueOut() : negative value"); nValueOut += txout.nValue; } return nValueOut; }
bool ReadFromDisk(CDiskTxPos pos, FILE** pfileRet=NULL) { CAutoFile filein = OpenBlockFile(pos.nFile, 0, pfileRet ? "rb+" : "rb"); if (!filein) return false;
// Read transaction if (fseek(filein, pos.nTxPos, SEEK_SET) != 0) return false; filein >> *this;
// Return file pointer if (pfileRet) { if (fseek(filein, pos.nTxPos, SEEK_SET) != 0) return false; *pfileRet = filein.release(); } return true; }
friend bool operator==(const CTransaction& a, const CTransaction& b) { return (a.vin == b.vin && a.vout == b.vout && a.nLockTime == b.nLockTime); }
friend bool operator!=(const CTransaction& a, const CTransaction& b) { return !(a == b); }
void print() const { printf("CTransaction(vin.size=%d, vout.size=%d, nLockTime=%d)\n", vin.size(), vout.size(), nLockTime); for (int i = 0; i < vin.size(); i++) { printf(" "); vin[i].print(); } for (int i = 0; i < vout.size(); i++) { printf(" "); vout[i].print(); } }
bool TestDisconnectInputs(CTxDB& txdb, map& mapTestPool) { return DisconnectInputs(txdb, mapTestPool, true); }
bool TestConnectInputs(CTxDB& txdb, map& mapTestPool, bool fMemoryTx, bool fIgnoreDiskConflicts, int64& nFees) { return ConnectInputs(txdb, mapTestPool, CDiskTxPos(1, 1, 1), 0, true, fMemoryTx, fIgnoreDiskConflicts, nFees); }
bool DisconnectInputs(CTxDB& txdb) { static map mapTestPool; return DisconnectInputs(txdb, mapTestPool, false); }
bool ConnectInputs(CTxDB& txdb, CDiskTxPos posThisTx, int nHeight) { static map mapTestPool; int64 nFees; return ConnectInputs(txdb, mapTestPool, posThisTx, nHeight, false, false, false, nFees); }
private: bool DisconnectInputs(CTxDB& txdb, map& mapTestPool, bool fTest); bool ConnectInputs(CTxDB& txdb, map& mapTestPool, CDiskTxPos posThisTx, int nHeight, bool fTest, bool fMemoryTx, bool fIgnoreDiskConflicts, int64& nFees);
public: bool AcceptTransaction(CTxDB& txdb, bool fCheckInputs=true); bool AcceptTransaction() { CTxDB txdb("r"); return AcceptTransaction(txdb); } bool ClientConnectInputs(); };
// // A transaction with a merkle branch linking it to the timechain // class CMerkleTx : public CTransaction { public: uint256 hashBlock; vector vMerkleBranch; int nIndex;
CMerkleTx() { Init(); }
CMerkleTx(const CTransaction& txIn) : CTransaction(txIn) { Init(); }
void Init() { hashBlock = 0; nIndex = -1; }
IMPLEMENT_SERIALIZE ( nSerSize += SerReadWrite(s, (CTransaction)this, nType, nVersion, ser_action); if (!(nType & SER_GETHASH)) READWRITE(nVersion); READWRITE(hashBlock); READWRITE(vMerkleBranch); READWRITE(nIndex); )
int SetMerkleBranch(); int IsInMainChain() const; bool AcceptTransaction(CTxDB& txdb, bool fCheckInputs=true); bool AcceptTransaction() { CTxDB txdb("r"); return AcceptTransaction(txdb); } };
// // A transaction with a bunch of additional info that only the owner cares // about. It includes any unrecorded transactions needed to link it back // to the timechain. // class CWalletTx : public CMerkleTx { public: vector vtxPrev; map mapValue; vector > vOrderForm; unsigned int nTime; char fFromMe; char fSpent;
//// probably need to sign the order info so know it came from payer
CWalletTx() { Init(); }
CWalletTx(const CMerkleTx& txIn) : CMerkleTx(txIn) { Init(); }
CWalletTx(const CTransaction& txIn) : CMerkleTx(txIn) { Init(); }
void Init() { nTime = 0; fFromMe = false; fSpent = false; }
IMPLEMENT_SERIALIZE ( /// would be nice for it to return the version number it reads, maybe use a reference nSerSize += SerReadWrite(s, (CMerkleTx)this, nType, nVersion, ser_action); if (!(nType & SER_GETHASH)) READWRITE(nVersion); READWRITE(vtxPrev); READWRITE(mapValue); READWRITE(vOrderForm); READWRITE(nTime); READWRITE(fFromMe); READWRITE(fSpent); )
bool WriteToDisk() { return CWalletDB().WriteTx(GetHash(), *this); }
void AddSupportingTransactions(CTxDB& txdb); void AddSupportingTransactions() { CTxDB txdb("r"); AddSupportingTransactions(txdb); }
bool AcceptWalletTransaction(CTxDB& txdb, bool fCheckInputs=true); bool AcceptWalletTransaction() { CTxDB txdb("r"); return AcceptWalletTransaction(txdb); }
void RelayWalletTransaction(CTxDB& txdb); void RelayWalletTransaction() { CTxDB txdb("r"); RelayWalletTransaction(txdb); } };
// // Nodes collect new transactions into a block, hash them into a hash tree, // and scan through nonce values to make the block's hash satisfy proof-of-work // requirements. When they solve the proof-of-work, they broadcast the block // to everyone and the block is added to the timechain. The first transaction // in the block is a special one that creates a new coin owned by the creator // of the block. // // Blocks are appended to blk0001.dat files on disk. Their location on disk // is indexed by CBlockIndex objects in memory. // class CBlock { public: // header uint256 hashPrevBlock; uint256 hashMerkleRoot; unsigned int nTime; unsigned int nBits; unsigned int nNonce;
// network and disk vector vtx;
// memory only mutable vector vMerkleTree;
CBlock() { SetNull(); }
IMPLEMENT_SERIALIZE ( if (!(nType & SER_GETHASH)) READWRITE(nVersion); READWRITE(hashPrevBlock); READWRITE(hashMerkleRoot); READWRITE(nTime); READWRITE(nBits); READWRITE(nNonce);
// ConnectBlock depends on vtx being last so it can calculate offset if (!(nType & (SER_GETHASH|SER_BLOCKHEADERONLY))) READWRITE(vtx); else if (fRead) const_cast(this)->vtx.clear(); )
void SetNull() { hashPrevBlock = 0; hashMerkleRoot = 0; nTime = 0; nBits = 0; nNonce = 0; vtx.clear(); vMerkleTree.clear(); }
bool IsNull() const { return (nBits == 0); }
uint256 GetHash() const { return Hash(BEGIN(hashPrevBlock), END(nNonce)); }
uint256 BuildMerkleTree() const { vMerkleTree.clear(); foreach(const CTransaction& tx, vtx) vMerkleTree.push_back(tx.GetHash()); int j = 0; for (int nSize = vtx.size(); nSize > 1; nSize = (nSize + 1) / 2) { for (int i = 0; i < nSize; i += 2) { int i2 = min(i+1, nSize-1); vMerkleTree.push_back(Hash(BEGIN(vMerkleTree[j+i]), END(vMerkleTree[j+i]), BEGIN(vMerkleTree[j+i2]), END(vMerkleTree[j+i2]))); } j += nSize; } return (vMerkleTree.empty() ? 0 : vMerkleTree.back()); }
vector GetMerkleBranch(int nIndex) const { if (vMerkleTree.empty()) BuildMerkleTree(); vector vMerkleBranch; int j = 0; for (int nSize = vtx.size(); nSize > 1; nSize = (nSize + 1) / 2) { int i = min(nIndex1, nSize-1); vMerkleBranch.push_back(vMerkleTree[j+i]); nIndex >>= 1; j += nSize; } return vMerkleBranch; }
static uint256 CheckMerkleBranch(uint256 hash, const vector& vMerkleBranch, int nIndex) { foreach(const uint256& otherside, vMerkleBranch) { if (nIndex & 1) hash = Hash(BEGIN(otherside), END(otherside), BEGIN(hash), END(hash)); else hash = Hash(BEGIN(hash), END(hash), BEGIN(otherside), END(otherside)); nIndex >>= 1; } return hash; }
bool WriteToDisk(bool fWriteTransactions, unsigned int& nFileRet, unsigned int& nBlockPosRet) { // Open history file to append CAutoFile fileout = AppendBlockFile(nFileRet); if (!fileout) return false; if (!fWriteTransactions) fileout.nType |= SER_BLOCKHEADERONLY;
// Write index header unsigned int nSize = fileout.GetSerializeSize(*this); fileout << FLATDATA(pchMessageStart) << nSize;
// Write block nBlockPosRet = ftell(fileout); if (nBlockPosRet == -1) return false; fileout << *this;
return true; }
bool ReadFromDisk(unsigned int nFile, unsigned int nBlockPos, bool fReadTransactions) { SetNull();
// Open history file to read CAutoFile filein = OpenBlockFile(nFile, nBlockPos, "rb"); if (!filein) return false; if (!fReadTransactions) filein.nType |= SER_BLOCKHEADERONLY;
// Read block filein >> *this;
// Check the header if (nBits < MINPROOFOFWORK || GetHash() > (~uint256(0) >> nBits)) return error("CBlock::ReadFromDisk : errors in block header");
return true; }
void print() const { printf("CBlock(hashPrevBlock=%s, hashMerkleRoot=%s, nTime=%u, nBits=%u, nNonce=%u, vtx=%d)\n", hashPrevBlock.ToString().substr(0,6).c_str(), hashMerkleRoot.ToString().substr(0,6).c_str(), nTime, nBits, nNonce, vtx.size()); for (int i = 0; i < vtx.size(); i++) { printf(" "); vtx[i].print(); } printf(" vMerkleTree: "); for (int i = 0; i < vMerkleTree.size(); i++) printf("%s ", vMerkleTree[i].ToString().substr(0,6).c_str()); printf("\n"); }
bool ReadFromDisk(const CBlockIndex* blockindex, bool fReadTransactions); bool TestDisconnectBlock(CTxDB& txdb, map& mapTestPool); bool TestConnectBlock(CTxDB& txdb, map& mapTestPool); bool DisconnectBlock(); bool ConnectBlock(unsigned int nFile, unsigned int nBlockPos, int nHeight); bool AddToBlockIndex(unsigned int nFile, unsigned int nBlockPos, bool fWriteDisk); bool CheckBlock() const; bool AcceptBlock(); };
// // The timechain is a tree shaped structure starting with the // genesis block at the root, with each block potentially having multiple // candidates to be the next block. pprev and pnext link a path through the // main/longest chain. A blockindex may have multiple pprev pointing back // to it, but pnext will only point forward to the longest branch, or will // be null if the block is not part of the longest chain. // class CBlockIndex { public: CBlockIndex* pprev; CBlockIndex* pnext; unsigned int nFile; unsigned int nBlockPos; int nHeight;
CBlockIndex() { pprev = NULL; pnext = NULL; nFile = 0; nBlockPos = 0; nHeight = 0; }
CBlockIndex(unsigned int nFileIn, unsigned int nBlockPosIn) { pprev = NULL; pnext = NULL; nFile = nFileIn; nBlockPos = nBlockPosIn; nHeight = 0; }
bool IsInMainChain() const { return (pnext || this == pindexBest); }
bool EraseBlockFromDisk() { // Open history file CAutoFile fileout = OpenBlockFile(nFile, nBlockPos, "rb+"); if (!fileout) return false;
// Overwrite with empty null block CBlock block; block.SetNull(); fileout << block;
return true; }
bool TestDisconnectBlock(CTxDB& txdb, map& mapTestPool) { CBlock block; if (!block.ReadFromDisk(nFile, nBlockPos, true)) return false; return block.TestDisconnectBlock(txdb, mapTestPool); }
bool TestConnectBlock(CTxDB& txdb, map& mapTestPool) { CBlock block; if (!block.ReadFromDisk(nFile, nBlockPos, true)) return false; return block.TestConnectBlock(txdb, mapTestPool); }
bool DisconnectBlock() { CBlock block; if (!block.ReadFromDisk(nFile, nBlockPos, true)) return false; return block.DisconnectBlock(); }
bool ConnectBlock() { CBlock block; if (!block.ReadFromDisk(nFile, nBlockPos, true)) return false; return block.ConnectBlock(nFile, nBlockPos, nHeight); }
void print() const { printf("CBlockIndex(nprev=%08x, pnext=%08x, nFile=%d, nBlockPos=%d, nHeight=%d)\n", pprev, pnext, nFile, nBlockPos, nHeight); } };
void PrintTimechain();
// // Describes a place in the timechain to another node such that if the // other node doesn't have the same branch, it can find a recent common trunk. // The further back it is, the further before the branch point it may be. // class CBlockLocator { protected: vector vHave; public:
CBlockLocator() { }
explicit CBlockLocator(const CBlockIndex* pindex) { Set(pindex); }
explicit CBlockLocator(uint256 hashBlock) { map::iterator mi = mapBlockIndex.find(hashBlock); if (mi != mapBlockIndex.end()) Set((*mi).second); }
IMPLEMENT_SERIALIZE ( if (!(nType & SER_GETHASH)) READWRITE(nVersion); READWRITE(vHave); )
void Set(const CBlockIndex* pindex) { vHave.clear(); int nStep = 1; while (pindex) { CBlock block; block.ReadFromDisk(pindex, false); vHave.push_back(block.GetHash());
// Exponentially larger steps back for (int i = 0; pindex && i < nStep; i++) pindex = pindex->pprev; if (vHave.size() > 10) nStep *= 2; } }
CBlockIndex* GetBlockIndex() { // Find the first block the caller has in the main chain foreach(const uint256& hash, vHave) { map::iterator mi = mapBlockIndex.find(hash); if (mi != mapBlockIndex.end()) { CBlockIndex* pindex = (*mi).second; if (pindex->IsInMainChain()) return pindex; } } return pindexGenesisBlock; }
uint256 GetBlockHash() { // Find the first block the caller has in the main chain foreach(const uint256& hash, vHave) { map::iterator mi = mapBlockIndex.find(hash); if (mi != mapBlockIndex.end()) { CBlockIndex* pindex = (*mi).second; if (pindex->IsInMainChain()) return hash; } } return hashGenesisBlock; }
int GetHeight() { CBlockIndex* pindex = GetBlockIndex(); if (!pindex) return 0; return pindex->nHeight; } };
extern map mapTransactions; extern map mapWallet; extern vector > vWalletUpdated; extern CCriticalSection cs_mapWallet; extern map, CPrivKey> mapKeys; extern map > mapPubKeys; extern CCriticalSection cs_mapKeys; extern CKey keyUser;
'''
Read this went the opposite way
Go1dfish undelete link
unreddit undelete link
Author: fukya40
submitted by removalbot to removalbot [link] [comments]

Portfolio Tracker

I have done a poor job tracking my cryptocurrency purchases and trades, so I am looking for software that will allow me to both connect to exchange APIs (such as Binance and Coinbase), as well as let me input a bunch of public addresses and trace their transactions. I'm specifically looking for something to help me track Bitcoin, Bitcoin Cash, Ethereum, and Litecoin, but if it can do others like Nano and Monero, that would be a bonus.
For example, in the past I remember using Shapeshift to convert between Bitcoin and Ethereum, but I didn't record any details about those trades. I'm thinking that if I can add my Bitcoin and Ethereum wallet addresses to this software and have them trace the transactions, I can figure out which ones line up by date and amount, so I can connect them together.
One main feature I really need is the ability to export the transactions once this software has tracked them all down, so something like a CSV or JSON, etc. I would really prefer using an application on my Linux PC as opposed to my phone (web-based is fine too). Finally, I really prefer to use open source software, and super bonus points to having it be something I can self-host, or otherwise something that I don't need to sign up an account for.
Does anyone know of something like this? I have searched all over Github but I can't seem to get the keywords right. I have searched the subreddit and found Blockfolio, but that seems to be just a phone app. I also found Delta, which seems promising (they have an AppImage for Linux), but the limitation I ran into is that I cannot add multiple wallets without the Pro version. I may be willing to upgrade to Pro, but I wanted to see if anyone had suggestions for other alternatives first.
submitted by thunder9861 to CryptoCurrency [link] [comments]

batching in Bitcoin

On May 6th, 2017, Bitcoin hit an all-time high in transactions processed on the network in a single day: it moved 375,000 transactions which accounted for a nominal output of about $2.5b. Average fees on the Bitcoin network had climbed over a dollar for the first time a couple days prior. And they kept climbing: by early June average fees hit an eye-watering $5.66. This was quite unprecedented. In the three-year period from Jan. 1 2014 to Jan. 1 2017, per-transaction fees had never exceeded 31 cents on a weekly average. And the hits kept coming. Before 2017 was over, average fees would top out at $48 on a weekly basis. When the crypto-recession set in, transaction count collapsed and fees crept back below $1.
During the most feverish days of the Bitcoin run-up, when normal users found themselves with balances that would cost more to send than they were worth, cries for batching — the aggregation of many outputs into a single transaction — grew louder than ever. David Harding had written a blog post on the cost-savings of batching at the end of August and it was reposted to the Bitcoin subreddit on a daily basis.
The idea was simple: for entities sending many transactions at once, clustering outputs into a single transaction was more space- (and cost-) efficient, because each transaction has a fixed data overhead. David found that if you combined 10 payments into one transaction, rather than sending them individually, you could save 75% of the block space. Essentially, batching is one way to pack as many transactions as possible into the finite block space available on Bitcoin.
When fees started climbing in mid-2017, users began to scrutinize the behavior of heavy users of the Bitcoin blockchain, to determine whether they were using block space efficiently. By and large, they were not — and an informal lobbying campaign began, in which these major users — principally exchanges — were asked to start batching transactions and be good stewards of the scarce block space at their disposal. Some exchanges had been batching for years, others relented and implemented it. The question faded from view after Bitcoin’s price collapsed in Q1 2018 from roughly $19,000 to $6000, and transaction load — and hence average fee — dropped off.
But we remained curious. A common refrain, during the collapse in on-chain usage, was that transaction count was an obfuscated method of apprehending actual usage. The idea was that transactions could encode an arbitrarily large (within reason) number of payments, and so if batching had become more and more prevalent, those payments were still occurring, just under a regime of fewer transactions.

“hmmm”
Some sites popped up to report outputs and payments per day rather than transactions, seemingly bristling at the coverage of declining transaction count. However, no one conducted an analysis of the changing relationship between transaction count and outputs or payments. We took it upon ourselves to find out.
Table Of Contents:
Introduction to batching
A timeline
Analysis
Conclusion
Bonus content: UTXO consolidation
  1. Introduction to batching
Bitcoin uses a UTXO model, which stands for Unspent Transaction Output. In comparison, Ripple and Ethereum use an account/balance model. In bitcoin, a user has no balances, only UTXOs that they control. If they want to transfer money to someone else, their wallet selects one or more UTXOs as inputs that in sum need to add up to the amount they want to transfer. The desired amount then goes to the recipient, which is called the output, and the difference goes back to the sender, which is called change output. Each output can carry a virtually unlimited amount of value in the form of satoshis. A satoshi is a unit representing a one-hundred-millionth of a Bitcoin. This is very similar to a physical wallet full of different denominations of bills. If you’re buying a snack for $2.50 and only have a $5, you don’t hand the cashier half of your 5 dollar bill — you give him the 5 and receive some change instead.
Unknown to some, there is no hardcoded limit to the number of transactions that can fit in a block. Instead, each transaction has a certain size in megabytes and constitutes an economic incentive for miners to include it in their block. Because miners have limited space of 2 MB to sell to transactors, larger transactions (in size, not bitcoin!) will need to pay higher fees to be included. Additionally, each transaction can have a virtually unlimited number of inputs or outputs — the record stands at transactions with 20,000 inputs and 13,107 outputs.
So each transaction has at least one input and at one output, but often more, as well as some additional boilerplate stuff. Most of that space is taken up by the input (often 60% or more, because of the signature that proves they really belong to the sender), while the output(s) account for 15–30%. In order to keep transactions as small as possible and save fees, Bitcoin users have two major choices:
Use as few inputs as possible. In order to minimize inputs, you can periodically send your smaller UTXOs to yourself in times when fees are very low, getting one large UTXO back. That is called UTXO consolidation or consolidating your inputs.
Users who frequently make transfers (especially within the same block) can include an almost unlimited amount of outputs (to different people!) in the same transaction. That is called transaction batching. A typical single output transaction takes up 230 bytes, while a two output transaction only takes up 260 bytes, instead of 460 if you were to send them individually.
This is something that many casual commentators overlook when comparing Bitcoin with other payment systems — a Bitcoin transaction can aggregate thousands of individual economic transfers! It’s important to recognize this, as it is the source of a great deal of misunderstanding and mistaken analysis.
We’ve never encountered a common definition of a batched transaction — so for the purposes of this study we define it in the loosest possible sense: a transaction with three or more outputs. Commonly, batching is understood as an activity undertaken primarily by mining pools or exchanges who can trade off immediacy for efficiency. It is rare that a normal bitcoin user would have cause to batch, and indeed most wallets make it difficult to impossible to construct batched transactions. For everyday purposes, normal bitcoiners will likely not go to the additional effort of batching transactions.
We set the threshold at three for simplicity’s sake — a normal unbatched transaction will have one transactional output and one change output — but the typical major batched transaction from an exchange will have dozens if not hundreds of outputs. For this reason we are careful to provide data on various different batch sizes, so we could determine the prevalence of three-output transactions and colossal, 100-output ones.
We find it helpful to think of a Bitcoin transaction as a mail truck full of boxes. Each truck (transaction) contains boxes (outputs), each of contains some number of letters (satoshis). So when you’re looking at transaction count as a measure of the performance and economic throughput of the Bitcoin network, it’s a bit like counting mail trucks to discern how many letters are being sent on a given day, even though the number of letters can vary wildly. The truck analogy also makes it clear why many see Bitcoin as a settlement layer in the future — just as mail trucks aren’t dispatched until they’re full, some envision that the same will ultimately be the case for Bitcoin.

Batching
  1. A timeline
So what actually happened in the last six months? Let’s look at some data. Daily transactions on the Bitcoin network rose steadily until about May 2017, when average fees hit about $4. This precipitated the first collapse in usage. Then began a series of feedback loops over the next six months in which transaction load grew, fees grew to match, and transactions dropped off. This cycle repeated itself five times over the latter half of 2017.

more like this on coinmetrics.io
The solid red line in the above chart is fees in BTC terms (not USD) and the shaded red area is daily transaction count. You can see the cycle of transaction load precipitating higher fees which in turn cause a reduction in usage. It repeats itself five or six times before the detente in spring 2018. The most notable period was the December-January fee crisis, but fees were actually fairly typical in BTC terms — the rising BTC price in USD however meant that USD fees hit extreme figures.
In mid-November when fees hit double digits in USD terms, users began a concerted campaign to convince exchanges to be better stewards of block space. Both Segwit and batching were held up as meaningful approaches to maximize the compression of Bitcoin transactions into the finite block space available. Data on when exchanges began batching is sparse, but we collected information where it was available into a chart summarizing when exchanges began batching.

Batching adoption at selected exchanges
We’re ignoring Segwit adoption by exchanges in this analysis; as far as batching is concerned, the campaign to get exchanges to batch appears to have persuaded Bitfinex, Binance, and Shapeshift to batch. Coinbase/GDAX have stated their intention to begin batching, although they haven’t managed to integrate it yet. As far as we can tell, Gemini hasn’t mentioned batching, although we have some mixed evidence that they may have begun recently. If you know about the status of batching on Gemini or other major exchanges please get in touch.
So some exchanges have been batching all along, and some have never bothered at all. Did the subset of exchanges who flipped the switch materially affect the prevalence of batched transactions? Let’s find out.
  1. Analysis
3.1 How common is batching?
We measured the prevalence of batching in three different ways, by transaction count, by output value and by output count.

The tl;dr.
Batching accounts for roughly 12% of all transactions, 40% of all outputs, and 30–60% of all raw BTC output value. Not bad.
3.2 Have batched transactions become more common over time?
From the chart in 3.1, we can already see a small, but steady uptrend in all three metrics, but we want to dig a little deeper. So we first looked at the relationship of payments (all outputs that actually pay someone, so total outputs minus change outputs) and transactions.

More at transactionfee.info/charts
The first thing that becomes obvious is that the popular narrative — that the drop in transactions was caused by an increase in batching — is not the case; payments dropped by roughly the same proportion as well.
Dividing payment count by transaction count gives us some insight into the relationship between the two.

In our analysis we want to zoom into the time frame between November 2017 and today, and we can see that payments per transactions have actually been rallying, from 1.5 payments per transaction in early 2017 to almost two today.
3.3 What are popular batch sizes?
In this next part, we will look at batch sizes to see which are most popular. To determine which transactions were batched, we downloaded a dataset of all transactions on the Bitcoin network between November 2017 and May 2018from Blockchair.
We picked that period because the fee crisis really got started in mid-November, and with it, the demands for exchanges to batch. So we wanted to capture the effect of exchanges starting to batch. Naturally a bigger sample would have been more instructive, but we were constrained in our resources, so we began with the six month sample.
We grouped transactions into “batched” and “unbatched” groups with batched transactions being those with three or more outputs.

We then divided batched transactions into roughly equal groups on the basis of how much total output in BTC they had accounted for in the six-month period. We didn’t select the batch sizes manually — we picked batch sizes that would split the sample into equal parts on the basis of transaction value. Here’s what we ended up with:

All of the batch buckets have just about the same fraction of total BTC output over the period, but they account for radically different transaction and output counts over the period. Notice that there were only 183,108 “extra large” batches (with 41 or more outputs) in the six-month period, but between them there were 23m outputs and 30m BTC worth of value transmitted.
Note that output value in this context refers to the raw or unadjusted figure — it would have been prohibitively difficult for us to adjust output for change or mixers, so we’re using the “naive” estimate.
Let’s look at how many transactions various batch sizes accounted for in the sample period:


Batched transactions steadily increased relative to unbatched ones, although the biggest fraction is the small batch with between 3 and 5 outputs. The story for output counts is a bit more illuminating. Even though batched transactions are a relatively small fraction of overall transaction count, they contain a meaningful number of overall outputs. Let’s see how it breaks down:


Lastly, let’s look at output value. Here we see that batched transactions represent a significant fraction of value transmitted on Bitcoin.


As we can see, even though batched transactions make up an average of only 12% of all transactions, they move between 30%-60% of all Bitcoins, at peak times even 70%. We think this is quite remarkable. Keep in mind, however that the ‘total output’ figure has not been altered to account for change outputs, mixers, or self-churn; that is, it is the raw and unadjusted figure. The total output value is therefore not an ideal approximation of economic volume on the Bitcoin network.
3.4 Has transaction count become an unreliable measure of Bitcoin’s usage because of batching?
Yes. We strongly encourage any analysts, investors, journalists, and developers to look past mere transaction count from now on. The default measure of Bitcoin’s performance should be “payments per day” rather than transaction count. This also makes Bitcoin more comparable with other UTXO chains. They generally have significantly variable payments-per-transaction ratios, so just using payments standardizes that. (Stay tuned: Coinmetrics will be rolling out tools to facilitate this very soon.)
More generally, we think that the economic value transmitted on the network is its most fundamental characteristic. Both the naive and the adjusted figures deserve to be considered. Adjusting raw output value is still more art than science, and best practices are still being developed. Again, Coinmetrics is actively developing open-source tools to make these adjustments available.
  1. Conclusion
We started by revisiting the past year in Bitcoin and showed that while the mempool was congested, the community started looking for ways to use the blockspace more efficiently. Attention quickly fell on batching, the practice of combining multiple outputs into a single transaction, for heavy users. We showed how batching works on a technical level and when different exchanges started implementing the technique.
Today, around 12% of all transactions on the Bitcoin network are batched, and these account for about 40% of all outputs and between 30–60% of all transactional value. The fact such that a small set of transactions carries so much economic weight makes us hopeful that Bitcoin still has a lot of room to scale on the base layer, especially if usage trends continue.
Lastly, it’s worth noting that the increase in batching on the Bitcoin network may not be entirely due to deliberate action by exchanges, but rather a function of its recessionary behavior in the last few months. Since batching is generally done by large industrial players like exchanges, mixers, payment processors, and mining pools, and unbatched transactions are generally made by normal individuals, the batched/unbatched ratio is also a strong proxy for how much average users are using Bitcoin. Since the collapse in price, it is quite possible that individual usage of Bitcoin decreased while “industrial” usage remained strong. This is speculation, but one explanation for what happened.
Alternatively, the industrial players appear to be taking their role as stewards of the scarce block space more seriously. This is a significant boon to the network, and a nontrivial development in its history. If a culture of parsimony can be encouraged, Bitcoin will be able to compress more data into its block space and everyday users will continue to be able to run nodes for the foreseeable future. We view this as a very positive development. Members of the Bitcoin community that lobbied exchanges to add support for Segwit and batching should be proud of themselves.
  1. Bonus content: UTXO consolidation
Remember that we said that a second way to systematically save transaction fees in the Bitcoin network was to consolidate your UTXOs when fees were low? Looking at the relationship between input count and output count allows us to spot such consolidation phases quite well.

Typically, inputs and outputs move together. When the network is stressed, they decouple. If you look at the above chart carefully, you’ll notice that when transactions are elevated (and block space is at a premium), outputs outpace inputs — look at the gaps in May and December 2017. However, prolonged activity always results in fragmented UTXO sets and wallets full of dust, which need to be consolidated. For this, users often wait until pressure on the network has decreased and fees are lower. Thus, after transactions decrease, inputs become more common than outputs. You can see this clearly in February/March 2017.

Here we’ve taken the ratio of inputs to outputs (which have been smoothed on a trailing 7 day basis). When the ratio is higher, there are more inputs than outputs on that day, and vice versa. You can clearly see the spam attack in summer 2015 in which thousands (possibly millions) of outputs were created and then consolidated. Once the ratio spikes upwards, that’s consolidation. The spike in February 2018 after the six weeks of high fees in December 2017 was the most pronounced sigh of relief in Bitcoin’s history; the largest ever departure from the in/out ratio norm. There were a huge number of UTXOs to be consolidated.
It’s also interesting to note where inputs and outputs cluster. Here we have histograms of transactions with large numbers of inputs or outputs. Unsurprisingly, round numbers are common which shows that exchanges don’t publish a transaction every, say, two minutes, but instead wait for 100 or 200 outputs to queue up and then publish their transaction. Curiously, 200-input transactions were more popular than 100-input transactions in the period.


We ran into more curiosities when researching this piece, but we’ll leave those for another time.
Future work on batching might focus on:
Determining batched transactions as a portion of (adjusted) economic rather than raw volume
Looking at the behavior of specific exchanges with regards to batching
Investigating how much space and fees could be saved if major exchanges were batching transactions
Lastly, we encourage everyone to run their transactions through the service at transactionfee.info to assess the efficiency of their transactions and determine whether exchanges are being good stewards of the block space.
Update 31.05.2018
Antoine Le Calvez has created a series of live-updated charts to track batching and batch sizes, which you can find here.
We’d like to thank 0xB10C for their generous assistance with datasets and advice, the people at Blockchair for providing the core datasets, and David A. Harding for writing the initial piece and answering our questions.
submitted by miguelfranco1412 to 800cc [link] [comments]

How To Invest in Cryptocurrencies: The Ultimate Beginners Guide

All statements are based on the author’s experiences. I take pride in informing the public and helping as many as I can through sharing my experiences with my readers. That said, no one except you can take responsibility for your Cryptocurrency Investing decisions, so do think it through before investing.
If you would like to learn more about the techlogogy behind cryptocurrencies, please check out our blockchain courses on crypto.
When I first started taking an interest in cryptocurrency I thought I was so lost in this huge sea of unknowns. Where do I start? What are the useful keywords to look up and keep in mind? What are the available helpful resources? This cryptocurrency investing guide is written so that in just 20 minutes, you would have a sense of what to expect of your upcoming crypto journey, and how to best go about starting it. Enjoy it, it might just be the most exhilarating ride of your life.

Rise of the Cryptocurrencies
As the tech literacy of the population increases, acceptance of crypto as a legitimate store of value follows, and it boomed. Titles along the lines of ‘Bitcoin price hits new all-time high’ and ‘Ethereum price surges’ are starting to perforate the general public’s news feed. What we know for sure is that people who were once skeptical of Bitcoin and the technology behind it are slowly understanding and getting increasingly involved with crypto. As at the time of writing, the market cap of the entire crypto space is at 30.9 billion USD. It was 20 billion just four months ago. What would it be four months from now?
Current Makeup of the Cryptocurrency Space
You would have heard of Bitcoin and the ‘altcoins.’ How this naming convention started was because back in the days of 2011, forks of Bitcoin appeared in the markets. The forks, or clones, each aspire to serve a niche area, aiming to be ‘better’ than Bitcoin. Since then countless new crypto has emerged, eroding away Bitcoin’s crypto market cap dominance. These altcoins are gaining market share at an alarming speed. Ten times or more growth has been observed in a time span as short as six weeks (see PIVX, an altcoin).
Cryptocurrency, Stocks, and Fiat
The currencies we know are referred to as ‘fiat’ by the cryptocurrency community. Although having ‘currency’ in its name, cryptocurrencies share more similarities with stocks than currencies. When you purchase some cryptocurrency, you are in fact buying some tech stock, a part of the blockchain and a piece of the network.
Cryptocurrency Exchanges
The most common place where people buy and trade cryptocurrency is on the exchanges. Exchanges are places where you may buy and sell your crypto, using fiat. There are multiple measures to judge the reliability and quality of an exchange, such as liquidity, spread, fees, purchase and withdrawal limits, trading volume, security, insurance, user-friendliness. Out of all these, I find Coinbase as the best exchange hands down. It has a beginner-friendly user interface, and an unbeatable 100% crypto insurance.
After setting up an intermediary bank account and verifying your details with Coinbase, you are only five simple steps away from a Bitcoin purchase:
  1. Access the ‘Buy/Sell Bitcoin’ tab
  2. Select the payment method using the drop-down menu
  3. Enter the desired amount
  4. Click ‘Buy Bitcoin Instantly.’
  5. View your credited Bitcoins on your dashboard
When you get acquainted with buying crypto and start to itch for some crypto trading (e.g. BTC/ETH), simply perform an instant transfer from Coinbase to GDAX free of charge and start trading. Think of Coinbase as the place to conveniently buy and store your crypto and GDAX as your margin trading platform. Transfers between the two are instant and free.
As you slowly get familiar with other currencies, you might want to have the option of investing in them. Bittrex and Polo are two exchanges that offer a wide selection range.
When signing up on these exchanges for the first time, do make it a point to verify your account with the required documents early, as you do not want to be caught in the middle of some tedious and slow admin work when the trading opportunity comes. Verification on these exchanges may take days, and purchase/withdraw limits may only increase gradually as you trade.
An additional point to note: if you are using a currency other than USD, do check out the exchange’s ease of funding and withdrawal. You do not want your exchange to come into fiat withdrawal problems like Bitfinex did recently.
Cryptocurrency Wallets
Exchanges have inbuilt online wallets to keep the cryptocurrency you purchased. However, for those who heard of the Mt. Gox hack, you might feel uneasy to put on an exchange. If you do not wish to keep your crypto holdings on the exchange, you have the option to either use a paper wallet service like myetherwallet.com or spend 99 USD on a hardware wallet like KeepKey. Both serve the purpose of removing platform risk, at the cost of taking up the responsibility of keeping your cryptocurrency safe.
To transfer your crypto from exchanges to your hardware wallet for long term storage, simply follow these steps, using Coinbase and KeepKey as an example:
  1. Plug in your KeepKey USB cable
  2. Open your KeepKey Client (on Google Chrome under Apps)
  3. Find your wallet address on the KeepKey Client UI
  4. Access Coinbase ‘Send/Request’ tab and input your KeepKey wallet address
  5. Confirm amount and click ‘Send Funds’
Take note to first send a tiny amount (e.g. 0.0001 BTC) for testing before sending the bulk, lest an error occurred and the transfer amount is lost. A small network transfer fee might be charged.
Personally, I own a hardware wallet, as I love the feeling of a having around a tangible reminder of my crypto holdings. Also, the hardware wallet’s user interface makes it easy to keep multiple coins, which is especially handy when you participate in ICOs (Initial Coin Offering) in the future.

Cryptocurrency as a Percentage of Your Investment Portfolio

This part will be wildly subjective. Crypto has the potential to realize many ‘rags to riches’ stories, but its volatility makes it unpredictable. As a precaution, the money you put in crypto should be money that you are fine with losing. I cannot emphasize the importance of this as we often underestimate how the volatility affects our emotional capacities. The upside is huge, but it comes with lots of risks and, if I may put it, emotional torment.
A conservative portfolio I would suggest is as follows:
< 30 years old (max) 30% Crypto, 50% Traditional Investments
30 – 40 years old (max) 20% Crypto, 60% Traditional Investments
> 40 years old (max) 10% Crypto, 70% Traditional Investments
This is not meant to be age discriminatory but considers the fact that one takes up more financial responsibilities (mortgage, family) as he grows older.
Within the designated crypto share of your portfolio, you may diversify your coins based on your risk appetite.

Show Me the Money! Cryptocurrency Investing

Now, this is where it gets exciting.
How do we pick the winner? How do we avoid picking the loser?
Note that crypto is now in a huge bull market and anything could rise over time. Also, do not dismiss the possibility that we may be in a bubble like the-dot-com boom back in 2000. Still, ask yourself these questions before you decide to invest in a coin:
Short Term Trading with Margin
Once you get familiarized with crypto, you may want to trade on your ‘stash’ in hopes of increasing it. For the experienced forex traders, this is nothing new. But for the new crypto investor, you may want to brief up on how to make a leveraged trade.
Short-term trading takes advantages of incoming news to make a quick buck. If you foresee good news from an upcoming release of a coin, you may want to open a long and see how it goes. Remember, buy the rumor, sell the news; act fast and be daring if you wish to make a profit with short term trading.
Mining
For those who are more comfortable with a predictable form of reward, mining is the way. Mining involves setting up of a rig, consisting of GPUs or CPUs and an investment in the electricity. Mining is only possible on cryptocurrencies that follow the Proof of Work protocol. It takes some effort to setup and gets things running, but it is attractive as a long-term passive income as long as you frontload the work.
Staking
Staking is the Proof of Stake version of ‘mining.’ Think of this as making dividends on your stock. The reward rate and staking method differ greatly among Proof of Stake coins, but in general, it takes less effort as compared to mining.
Arbitraging
As you get a hand in multiple exchanges, you may wish to buy from one exchange and sell on another to make ‘arbitrage’ gains when you spot an arbitraging opportunity. Take note of two things if you wish to do so: remember to factor in fees, and remember that the price could change when you are transferring your coin between exchanges, especially during volatile times. USD tends to be liquid so this happens less for it, but for other currencies such as CAD (Canadian dollar) and SGD (Singapore dollar), there may exist more arbitraging opportunities to exploit.
That’s about all I have, for now, invest smart and most importantly, don’t forget to have fun!
submitted by alifkhalil469 to BtcNewz [link] [comments]

Multiply your Bitcoin with this...!? BITCOIN [Class 2]: Transactions, Inputs & Outputs (2018) How to Verify Your Debit:Credit Card in Coinbase - YouTube How to Combine Inputs POS Coin Control Tutorial Using Buzz Coin Wallet Bitcoin BTC Adder add 5 btc

Bitcoin transactions may contain several inputs and outputs. Transaction Fee: Also known as a "miner's" fee, a transaction fee is an amount of bitcoin included in each transaction that is collected by miners. This is to encourage miners to add the transaction to a block. Multiple inputs are often listed in a transaction. All of the new transaction's input values (that is, the total coin value of the previous outputs referenced by the new transaction's inputs) are added up, and the total (less any transaction fee) is completely used by the outputs of the new transaction. Previous tx is a hash of a previous ... Bitcoin is a distributed, worldwide, decentralized digital money. Bitcoins are issued and managed without any central authority whatsoever: there is no government, company, or bank in charge of Bitcoin. You might be interested in Bitcoin if you like cryptography, distributed peer-to-peer systems, or economics. The figure above shows the main parts of a Bitcoin transaction. Each transaction has at least one input and one output. Each input spends the satoshis paid to a previous output. Each output then waits as an Unspent Transaction Output (UTXO) until a later input spends it. When your Bitcoin wallet tells you that you have a 10,000 satoshi balance, it really means that you have 10,000 satoshis ... prior coin histories involv es multiple parties providing inputs to a Bitcoin trans- action, and similarly multiple outputs being directed back to those parties. Fur-

[index] [3487] [13406] [25488] [12590] [12409] [10362] [15164] [4579] [3362] [17125]

Multiply your Bitcoin with this...!?

You can use multiple Bitcoin wallet to get BTC on different Bitcoin wallets. You can use any Bitcoin Wallet: example (BlockChain.com, CoinBase.com, Copay.io, Xapo.com) and other BTC Wallet. We Earn Bitcoin - Directly Pay to Us in Our Digital Wallets. Coinbase Signup Link: https://www.coinbase.com/join/58f2a554ee8ea50105548e08 Contact Us: Faceboo... How to send bitcoin to yourself and get a hash code in Coinbase and Blockchain. 👇🏻Support the channel by using my affiliate links below👇🏻 Exchanges I'm using: Coinbase FIAT https://www.coinbase.com/join/59398125002bcc03276297d6 Bin... This video is unavailable. Watch Queue Queue. Watch Queue Queue

#