In my opinion Turing-complete smart contracts are the biggest blunder to ever grace blockchains. They are simply not rigorous enough for an immutable, adversarial environment. The incentive to exploit a smart contract is too high to rely on scripts that can not be proven to be correct. Accordingly I welcome the decision to keep Simplicity non-Turing-complete. While current Bitcoin scripting capabilities are rather limited, Simplicity could change that in a secure and sane manner. Let's see if it ever gets beyond being a concept though.




That's a silly thing to say.

"Why do we need Bitcoin if we already have the Dollar?"

"Why do we need email if we already have fax?"

"Why do we need automobiles if we already have horses?"

Actually I think for most use cases 550 MB should be plenty.

I'm not sure if I'm missing any metadata, but that's about 140 - 550 blocks worth of confirmations, depending on whether you assume full SegWit-transactions-only or full legacy-transactions-only blocks. Coinbase maturity seems like an adequate baseline and requires 100 confirmations, so these 140 - 550 blocks that a fully pruned node stores look good enough to me for the average user.

I've never heard of BitMiner before, and seeing how they claim to be "an industry leading Bitcoin mining pool" and are expecting you to send them money they are very likely trying to scam people.

BitMinter is a legit mining pool, BitMiner probably not so much.

Two rules of thumb:

1) If a website claims to mine for you, they're only after your money. This includes cloud mining services such as:


2) If a website offers software for download that supposedly mines on your home PC, they are likely trying to get you infected.


In general, cryptocurrency mining requires dedicated hardware. In the case of Bitcoin that's ASICs, specialized hardware that are good for nothing besides mining Bitcoin. Some alternative currencies also require ASICs nowadays. Most alts that don't require ASICs, will make only make sense to mine if you set up a dedicated mining rig using consumer grade, high-end GPUs. Either way you'll have to get physical.


If you're serious about getting into mining, check out the BitcoinTalk mining sub-boards. Make sure to read the stickies first.

Bitcoin mining:
https://bitcointalk.org/index.php?board=14.0

Alt coin mining:
https://bitcointalk.org/index.php?board=160.0

Running full nodes on a VPS is fine, but you definitely want to store the funds in cold storage.

Either implement application logic to immediately move the coins from your VPS hot wallet to cold storage, or better yet, use an xpub key to have the coins sent straight to cold storage without even touching the online server. Then fill the hot wallet from there, as required.

If you have an online server sending Bitcoins to another online server you're doing security wrong.



Only if you set the server up accordingly. Out of the box your run-of-the-mill VPS server is a hackers-delight free-for-all all-you-can-crack buffet.

The chances of an orphaned block happening rely mostly on the interval between blocks and the network connectivity between miners and nodes. With Bitcoin the chances of orphaned blocks are rather slim. To find out the probability of an orphaned block in practice you'll probably have to look at the orphaned block rate of the last few years and make an estimate based on those numbers. You'd probably have to check various sources though, because not all nodes are aware of all orphaned blocks.

If a block with a newly confirmed transaction is orphaned, and the transaction is not included in one of the other blocks, it simply remains unconfirmed until it gets included in a block. So basically -- it's been sent, but the confirmation never happened.



Orphaned blocks happen all the time, the last being recorded by blockchain.info on January 2018:
https://blockchain.info/orphaned-blocks

Note that different nodes may see different orphaned blocks. Some orphans you see may not be seen by other nodes and vice versa. The only thing that is kept consistent across nodes is the blockchain -- consistency across nodes being one of the blockchain's main intent.

What you should be aware of is that anyone who has access to your xpub key will be able to track any transaction that will move through its derived addresses. So while not as critical as private keys, you should also keep your xpub key safe from prying eyes, otherwise your privacy may be compromised.

Other than that, just like bob123 said: No, you can't derive the xpub key from one of its child public keys.

Like many others in this thread I also highly doubt that a hashing algorithm can be found that will remain ASIC proof for the foreseeable future (say, 10 years from deployment), especially given the size of the market and the profits to be made.

I also see a lot of practical problems with your approach -- organizing non-partisan and sound reviews of MemHash, getting the community on board, difficulty / hashrate fluctuations during the transition period for example.

That being said, I'm looking forward to read a fleshed out version of your proposal.

Interesting argument, but the issue still lies with ASICs, in that the access to ASICs is rather restricted -- as opposed to consumer hardware such as GPUs and CPUs -- while ASICs producer also stand to gain money by simpling producing ASICs for themselves rather than the general public.

Cheap electricity leads to geographical hotspots, but the core of the problem is the centralization of power in a handful of companies, rather than territories. A multitude of companies from various nations all mining in China is less of a problem than a single company mining all over the world. Not that the first option would be optimal, mind you.

Basic smart contracts are already supported, otherwise Lightning Network wouldn't be deployable on the Bitcoin blockchain and token protocol layers such as Counterparty and OMNI of Tether fame wouldn't exist. There's little fanfare about it and they are rather limited in comparison to the likes of Ethereum, but Bitcoin does have scripting capabilities even now.

Apart from that there's the Rootstock sidechain in the works, which is already running mainnet tests:
https://www.rsk.co/

And somewhere far, far down the road we might even see the likes of Simplicity implemented and deployed:
https://blockstream.com/simplicity.pdf

Of course. Yet people use services such as Coinbase as a wallet. Some people even seem to prefer centralized cryptocurrencies for whatever good they are, but that's a different matter.

Like Danny pointed out, it's all about options. If centralized watchtowers become a thing I would definitely recommend people to avoid using them, just like I recommend people to not store money on exchanges or other centralized services. Some people may prefer it for convenience or whatever other reason one could think of. But keep in mind that using LN is both optional and probably not the end of the road as far as scaling is concerned. The Bitcoin base layer, ie. on-chain transactions, can still be used as is and other scaling improvements or protocol layers may come up in the future.

LN does not have to become THE payment platform / scaling solution for Bitcoin. But as long as it keeps some of the load off-chain it will definitely help.



Fair enough. Let's hope LN covers enough use cases to help keep transactions off-chain then



And that's exactly what I mean by good user experience mostly being a question of hiding and providing the right amount of information. Just because some aspects of LN's user experience are currently imperfect doesn't mean it has to stay that way.

The point of Bitcoin is to enable global, trustless, permissionless payments and to provide an alternative to already existing centralized services. Mass adoption is a nice-to-have but not the main goal -- at least in my opinion.

Now I'm not saying that user experience isn't important. I'm just saying that it's secondary to keeping Bitcoin as decentralized as possible. Also I'm fairly positive there's still room for improvement despite certain technological limitations. After all creating a good user experience is mostly a question of hiding and providing the right amount of control and information.



Most people already pay someone to check and make sure someone else isn't stealing your money. Banks, credit card providers, PayPal, etc do just that. With the exception of banks they merely got fairly good at hiding these costs from the average consumer.

That being said, I don't think watchtowers are a good solution either. Unless we find a trustless way to solve this issue, that is.

That's what I thought, thank you for confirming my suspicion. I was thinking that I may be missing a subtle technical reason for a mining pool being required to run a full node but I couldn't think of one.



I'm pretty sure most miners just try which pool works best for them and then point their hashrate on it. Unfortunately people are barely caring about keeping the hashrate decentralized, I doubt many care about whether their pool of choice runs a full node or not as long as its reliable. Besides, if your pool is large enough you already got a big fat target painted on your back either way. There's plenty of reasons to DDoS a mining pool, them not running a full node probably being one of the pettiest.



From a purely business-oriented perspective, miners don't care which chain to follow. Rationally speaking they will simply follow the currency that is the most profitable. I also don't think that miners care much about user experience when it comes to a newbie opting for the Bitcoin Core wallet.

Whether they should run a full node from a "corporate responsibility" point of view is a different question of course. But I doubt it meaningfully influences their bottom line.



That I could imagine to be a valid point of concern for a mining pool operator.

To add to what achow101 and bob123 already posted on this matter:

Note that the blockchain is something entirely different from your wallet.

The blockchain is a collection of files that contains the whole history of every transaction ever made. A wallet file is a collection of private keys that enables you to sign transactions for later publishing on the blockchain.

Your wallet file, ie. your private keys or the seed from which the private keys are derived, is what you want to keep safe.

That's why the blockchain can be stored on an online device (well, it has to be an online device by necessity, as it has to be connected to other nodes to stay up-to-date) while your private keys should be stored on an air-gapped, offline device.

That's why with Armory you usually have a watch-only wallet that is connected to the internet (the one syncing with the blockchain) and an offline-wallet installed on a separate, air-gapped device that doesn't require the blockchain (the one you use to sign transactions with). Hardware wallets are basically the latter, in a more compact form, with the blockchain being hosted on a third party server.

Note that if you run Armory on a single device, without using two separate devices for a watch-only wallet and an offline-wallet respectively, you are effectively running a hot wallet and not using Armory's full security potential (ie. cold storage).

I think what OP is asking is whether mining pool operators use a full or a pruned node.

In general it seems to make sense for mining pools to run a full node, since if you already harness millions of dollars worth of computational power there's no sense on skimping when it comes to running a node, amirite?

But from a technical perspective it seems like they could run a pruned node just as well, since they only care about current transactions. Or would a mining pool be prevented from publishing blocks if they are not connected to the network as a full node?

I also think that for the most part the upsides of ASICs outweigh their downsides. ASICs themselves are not problematic, it's when there's too little competition in the mining market that things could get ugly.

Given the recent uptick of Bitcoin's valuation I think it's likely that we'll see new players entering the mining business over the next couple of years though -- keeping the market fresh and flowing.



Depends on what kind of flaw is found. Keep in mind that the use case of a PoW scheme is different from the use case of eg. hashing your users' passwords.

Best case it's the kind of flaw that makes SHA256 faster to calculate, in which case we'll simply see a new generation of miners.

Worst case Bitcoin needs to hardfork to a new PoW scheme. This would come with a lot of drama on which algo to choose, possibly leading to a multitude of competing PoW hardforks, but sooner or later one blockchain would emerge as the canonical Bitcoin blockchain. Even then we might see the original, SHA256 Bitcoin, continuing its existence although at likely a much lower market rate, corresponding to the severity of the found flaw.

Nice writeup. While I don't follow Stablecoins all that closely it definitely is interesting to see a comprehensive list of approaches at controlling volatility.

I'm not quite convinced that stability can be reliably achieved within tolerance levels that are acceptable for the general populace (say, < 5%) but they do give an opportunity to look at market forces in wholly new ways.

It really is just transactions all the way down though, that's how the protocol works. All that wallets do is process these transaction in a way that make sense to the user. That is, they scan the blockchain for transactions of which they can spend the outputs and show it to as the balance of the respective address and subsequently as the total balance of the wallet or account (the latter applying to HD wallets).

In the case of Bitcoin, accounts and balances are just metaphors that we use to make our life easier. From a technical perspective they are neither needed nor implemented.

Only your direct counterparty can claim the collateral in case of a explicitely provoked channel state mismatch. Routing nodes along the way have no say in this. They don't even know who's sending how much to whom.



No such thing as different kinds of access to the protocol. Both the protocol specification and the various LN implementations are open source and available to the public.

I'm not sure what you're trying to say here, but mining has nothing to with how much transaction fees are calculated.

There's limited space on the blockchain. As such, if the demand (ie. transaction count) exceeds the supply (ie. available space per block) mining fees go up, as people try to get on top of the priority list. That's how a market works. That's all there is to it.



PayPal and VISA, you forgot about those two.

Solid writeup. Apart from some typos, just two minor nitpicks:


myetherwallet can also be used in conjunction with hardware wallets, which is yet another step up from metamask



Nowadays third party antivirus software is turning out to be more of a liability rather than an improvement. They tend to install questionable root certificates and effectively MitM otherwise secure connections. All in all third party antivirus software increases your attack surface, so in most cases your probably better off using the antivirus software that comes out-of-the-box with your operating system (eg. Windows Defender in the case of, well, Windows).

It is also worth noting that against properly written, targeted attacks, most antivirus software is pretty much useless.


But apart from that, like I said, solid writeup.