-
Notifications
You must be signed in to change notification settings - Fork 228
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch 'master' into POW-Is-Not-What-Creates-Unscalability
- Loading branch information
Showing
19 changed files
with
446 additions
and
0 deletions.
There are no files selected for viewing
Binary file added
BIN
+83.2 KB
content/blog/2023-09-19-understanding-and-mitigating-re-orgs/banner.jpg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added
BIN
+103 KB
...023-09-19-your-exchange-needs-more-confirmations-the-bitcofn-measure/banner.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
41 changes: 41 additions & 0 deletions
41
.../2023-09-19-your-exchange-needs-more-confirmations-the-bitcofn-measure/index.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,41 @@ | ||
--- | ||
title: "Your Exchange Needs More Confirmations: The BitConf Measure" | ||
date: 2023-09-19 | ||
author: Anonymous | ||
tags: ["education"] | ||
linkImage: ./banner.png | ||
--- | ||
|
||
The following article was originally published on December 17 2018 by an author who wishes to remain anonymous. | ||
|
||
--- | ||
|
||
In cryptocurrency we regularly advise against accepting zero-conf transactions but are entirely happy to accept weakly-conf’d transactions for convenience. And we need to stop. Cryptocurrencies naturally settle to over time, but how fast they settle varies. We need to stop making unreasonable demands of confirmation time. | ||
|
||
> $81,000 of security, and $3,000 of security are not equivalent. Whatever the threshold is, it should be normalized so that all networks have the same security when it comes to deposits and accepting payments. | ||
How blocks see themselves vs. how they actually are. | ||
|
||
Your typical Cryptocurrency exchange requires a different number of confirmations/blocks depending on which Cryptocurrency you’re using. For example, Bitcoin is typically 2, Litecoin is 6, Ethereum is 36, and Ethereum Classic is 72. | ||
|
||
Okay, great, there are different amounts of blocks needed for each network to sufficiently deter attacks that result in reversed transactions. Except these numbers are not at all equivalent. 6 Litecoin blocks are much cheaper to mine than 1 Bitcoin block. | ||
|
||
A Bitcoin block is ~$40,500; we’ll call this 1 BitConf, the equivalent PoW security of mining a single Bitcoin block. So 2 BitConfs is $81,000 of security. | ||
|
||
A Litecoin block is ~$500, or 0.01234 BitConfs. 6 Litecoin blocks are $3,000 of security. | ||
|
||
It’s 27x cheaper to 51% attack Litecoin than Bitcoin on any exchange that waits 6 blocks for a Litecoin and 2 for Bitcoin. For your exchange to have the same security on Litecoin as Bitcoin you need to wait 162 blocks, or 6.75 hours for confirmation. This is the security of the Litecoin network. | ||
|
||
For Ethereum, each block costs $252 and you need 321 of them (or 1.2 hours) for the same confirmation strength as Bitcoin. Ethereum Classic is $14 per block and needs 5,785 blocks or about 1 day to reach 2 BitConfs. | ||
|
||
Maybe an exchange doesn’t need to wait 2 BitConfs, maybe a fraction of a BitConf is enough. Maybe it varies based on how much they’re depositing, a sane attacker is not going to spend $10,000 to double spend $1,000 on your exchange. But $81,000 of security, and $3,000 of security are not equivalent. Whatever the threshold is, it should be normalized so that all networks have the same security when it comes to deposits and accepting payments. | ||
|
||
P.S. It’s also viable to credit deposits instantly & wait confirmations for withdrawals. Some exchanges already do this with cash deposits, start doing it with all deposits. | ||
|
||
*Thanks to Rocco.* | ||
|
||
--- | ||
|
||
**Thank you for reading this article!** | ||
|
||
To learn more about ETC please go to: https://ethereumclassic.org |
38 changes: 38 additions & 0 deletions
38
...23-09-19-your-exchange-needs-more-confirmations-the-bitcofn-measure/index.zh.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,38 @@ | ||
--- | ||
title: "您的交易所需要更多的确认:BitConf度量标准" | ||
date: 2023-09-19 | ||
author: Anonymous | ||
contributors: ["Anonymous"] | ||
tags: ["education"] | ||
linkImage: ./banner.png | ||
--- | ||
|
||
以下文章最初由一位希望保持匿名的作者于2018年12月17日发布。 | ||
|
||
--- | ||
|
||
在加密货币领域,我们经常建议不接受零确认交易,但对于便利起见,我们完全愿意接受弱确认的交易。但我们需要停止这样做。加密货币在自然情况下会随着时间解决,但解决速度有所不同。我们需要停止对确认时间提出不合理的要求。 | ||
|
||
> 81000美元的安全性和3000美元的安全性并不相等。不管阈值是多少,都应该被规范化,以便在存款和接受付款方面,所有网络都具有相同的安全性。 | ||
区块链自身看待自己与其实际情况。 | ||
|
||
您典型的加密货币交易所需要不同数量的确认/区块,这取决于您使用的加密货币。例如,比特币通常需要2个确认,莱特币需要6个,以太坊需要36个,以太经典需要72个。 | ||
|
||
好的,很好,对于每个网络,确保足够防止导致交易被撤销的攻击所需的区块数是不同的。除了这些数字根本不等同。挖掘6个莱特币块比挖掘1个比特币块要便宜得多。 | ||
|
||
一个比特币块约值40500美元;我们称之为1 BitConf,挖掘单个比特币块的等效PoW安全性。因此,2个BitConf的安全性为81000美元。 | ||
|
||
一个莱特币块约值500美元,或者0.01234个BitConf。6个莱特币块的安全性为3000美元。 | ||
|
||
在等待6个莱特币块和2个比特币块的交易所上,51%攻击莱特币比比特币便宜27倍。为了使您的交易所在莱特币和比特币上具有相同的安全性,您需要等待162个区块,或6.75小时的确认时间。这是莱特币网络的安全性。 | ||
|
||
对于以太坊,每个区块的成本为252美元,您需要321个区块(或1.2小时)才能达到与比特币相同的确认强度。以太经典每个区块14美元,需要5785个区块,或大约1天的时间才能达到2个BitConf的安全性。 | ||
|
||
也许一个交易所不需要等待2个BitConf,也许一小部分BitConf就足够了。也许这取决于他们存入了多少资金,一个理智的攻击者不会花费10000美元来双倍花费您交易所上的1000美元。但81000美元的安全性和3000美元的安全性并不相等。不管阈值是多少,都应该被规范化,以便在存款和接受付款方面,所有网络都具有相同的安全性。 | ||
|
||
附:也可以立即将存款记入帐户并等待确认后再提款。一些交易所已经在现金存款方面采取了这种做法,请开始在所有存款方面采取这种做法。 | ||
|
||
**感谢您阅读本文!** | ||
|
||
要了解更多关于以太经典的信息,请访问:https://ethereumclassic.org |
Binary file added
BIN
+83.2 KB
content/blog/2023-09-20-understanding-and-mitigating-re-orgs/banner.jpg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
82 changes: 82 additions & 0 deletions
82
content/blog/2023-09-20-understanding-and-mitigating-re-orgs/index.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,82 @@ | ||
--- | ||
title: "Understanding (and Mitigating) Re-Orgs" | ||
date: 2023-09-20 | ||
author: Anonymous | ||
contributors: ["Anonymous"] | ||
tags: ["education"] | ||
linkImage: ./banner.jpg | ||
--- | ||
|
||
The following article was originally published on May 21 2019 by an author who wishes to remain anonymous. | ||
|
||
--- | ||
|
||
Applying Proof of Work (PoW) to digital currency is an amazing innovation that was first actualized by Satoshi Nakamoto and builds on ideas from Wei Dai, Nick Szabo, Adam Back, and many others. | ||
|
||
Unfortunately the importance of this innovation is exceeded only by woeful misunderstanding of how PoW works. This article seeks to clarify how they happen, when they negatively affect payment recipients **(they rarely do)**, deterring double spends, and whether re-orgs are a Good Thing™. | ||
|
||
This is the first of many articles on this topic, with future ones taking a deeper look at some of the ideas proposed below. If you have any thoughts, comments, or feedback please feel free to reach out. | ||
|
||
## What Is A Re-Org? | ||
|
||
A re-org is simply what happens when your node is aware of Chain A, but then sees a bigger Chain B and switches to it. This happens on occasion and most of the time it is a non-issue. However, Chain B might have parts of its transaction history that don’t match Chain A and this can, **under certain conditions**, cause issues for those receiving transactions on a blockchain. | ||
|
||
## What Happens to Transactions in Chain A? | ||
|
||
Most transactions from Chain A will be placed by miners onto Chain B, they’ll get the fees from the transactions, and most users won’t even notice that their transaction “moved” from the shorter Chain A to the longer Chain B. | ||
|
||
Most importantly is that Chain A and B will share the overwhelming majority of the same history, so if you have Chain A and Chain B split at 10 AM today and you received coins last night then your coins are entirely unaffected. | ||
|
||
Typically only a small bit of the tip of the chain can be re-org’d off, with it becoming cost prohibitive to remove parts of the chain that are even a couple days old. | ||
|
||
## When Is A Re-Org Bad? | ||
|
||
This depends on who you are, re-orgs will affect HODL’rs, Exchanges/Payment Processors, and Miners in different ways. | ||
|
||
Firstly, re-orgs without double spends are occasional and uneventful things. Here’s a [partially complete list](http://web.archive.org/web/20190529192405/https://www.blockchain.com/btc/orphaned-blocks) of them on Bitcoin. | ||
|
||
Re-orgs are only bad when someone creates a double spend to defraud someone they’ve sent a payment to. Creating a double spend is akin to writing a bad check for a large amount of money, receiving the goods, and letting the check bounce. | ||
|
||
When a double spend is created through a re-org it largely affects recipients of a transaction. There may be some collateral issues with old transactions being pushed out of the chain but these are often remined, and unless your exchange is actively trying to steal from you they’ll rebroadcast your missing transaction. | ||
|
||
## How Does a Double Spend (or Re-org) Affect You? | ||
|
||
**HODL’rs**: A double spend is almost never bad for you, the longer your coins are in your wallet the more work that is piled on top of it and the less likely it is you’d ever be double spent. On Bitcoin ~1,900 BTC ($11 million) of new work is added to the chain **every single day**. After 3 months it’s going to cost **over a billion dollars** for someone to double spend you. Much better than the FDIC insurance on your bank account in my non-fiduciary opinion. | ||
|
||
![Safety first.](banner.jpg) | ||
|
||
**Exchanges/Payment Processors**: Double spends are the worst for you and you’re the primary target of them, but I probably don’t need to tell you this. What you should be aware of is that there are many ways to mitigate double spends without immediately resorting to nuclear options (though they are still options). | ||
|
||
**Miners**: Are largely unaffected by double spends themselves but can be negatively impacted by the re-org used to achieve the double spend. In this case they lose [block rewards](http://web.archive.org/web/20190529192405/https://bitcoin.org/en/glossary/block-reward) (block subsidy + [transaction fees](http://web.archive.org/web/20190529192405/https://bitcoin.org/en/glossary/transaction-fee)). | ||
|
||
## How May an Exchange Deter Double Spends?** | ||
|
||
1. **Wait Longer**: Exchanges can simply wait longer before confirming transactions, by waiting more blocks they increase the initial cost of a double spend attack, the higher the initial cost the more money an attacker needs to spend in order to achieve a successful attack. Risking 2 BTC ($11,600) to get away with 200 BTC ($1,160,000) is a low-risk theft. Risking 1,000 BTC ($5,800,000) to get away with 200 BTC is much higher risk. | ||
|
||
Cost of re-orgs varies substantially between chains. To get an idea of confirmation equivalents between chains check out [howmanyconfs.com](http://web.archive.org/web/20190529192405/https://howmanyconfs.com/) which normalizes all chains to ~6 Bitcoin blocks and read their [GitHub README](http://web.archive.org/web/20190529192405/https://github.com/lukechilds/howmanyconfs.com#how-are-these-values-calculated) which has a substantial amount of information and thoughts on this topic. | ||
|
||
Important to note is that you **do not need to harm UX/usability of your exchange; you can improve it while simultaneously becoming more secure.** You can take the approach that many exchanges do when handling cash deposits. Credit them almost immediately, allow trading, and wait an appropriate amount of time/confirmations before allowing withdrawals. | ||
|
||
2. **Account for Transaction Value**: A 2 BTC transaction is not equivalent to a 1,000 BTC transaction. The amount of confirmations you decide to wait should be proportional to the underlying value of the transaction. A simple, but by no means complete, metric is to wait until total block rewards exceed transaction value for the payments you’ve received in a given block. For example, if you receive 100 total BTC in block 575,000 on Bitcoin then you will want to wait at least 8 blocks (100/13.25) before confirming that 100 BTC. 13.25 is currently the average total block reward for successfully mining a block on Bitcoin and only used for example purposes. This particular method of deterrence warrants more investigation and may benefit from an additional “safety multiplier”. Game theorists please DM me on Twitter. | ||
|
||
3. **Be Mindful of Hardware Sets; especially GPUs**: Presently there are two hardware sets that mine Cryptocurrencies, ASICs dedicated to a specific hashing algorithm, and GPUs. This means that the Dagger-Hashimoto PoW algorithm on the Ethereum network is presently the majority for the GPU hardware type. All other GPU-mined chains, regardless of their PoW algorithm, are minority chains as switching costs between algorithms are trivial. | ||
|
||
Currently market inefficiencies create the perception that GPU-mined algorithms are distinct from each other. However this is only due to open market places (ie. Nice Hash, Genesis Mining) selling hashrate at the algorithm and chain level rather than the general GPU level. You can observe the ease of switching between GPU-mined algorithms by taking a look at auto-switching mining pools (ex. MiningPoolHub) which allow miners to automatically switch their hashrate between networks and GPU-mined algorithms. It is inadvisable to rely exclusively on market inefficiencies to prevent exploitation of minority GPU-mined blockchains. | ||
|
||
## Are Re-orgs a Good Thing™? | ||
|
||
Re-orgs are simply a vital component of PoW/Nakamoto Consensus, they are not in and of themselves good or bad. Re-orgs are necessary and irremovable from Nakamoto consensus because they remove trusted middlemen so that someone receiving a blockchain only needs to verify that it’s the longest one they’re aware of. | ||
|
||
In exchange for re-orgs we get PoW blockchains that are expensive to disrupt, and make long term censorship and DoS attacks impossible because they require sustained spending and consumption of finite resources. | ||
|
||
## **In Summary** | ||
|
||
PoW is an incredible experiment in game theory and financial motivations the likes of which we have not seen before. If you’re interested in this industry then you should take at least some effort to understand the innovation that is PoW, learn its limitations, its unexplored dimensions, and enjoy watching this all play out. Ultimately PoW is the only consensus algorithm that we have which allows for a maximally decentralized, permissionless, and censorship-resistant network which naturally resists concentration of power. PoW doesn’t solve technological issues, it solves human issues. | ||
|
||
You can read more on these topics, and similar ones at: [nakamotoinstitute.org](http://web.archive.org/web/20190529192405/https://nakamotoinstitute.org/), [the cryptography mailing list archives](http://web.archive.org/web/20190529192405/http://www.metzdowd.com/pipermail/cryptography/2009-January/), and [the libbitcoin wiki](http://web.archive.org/web/20190529192405/https://github.com/libbitcoin/libbitcoin-system/wiki). | ||
|
||
--- | ||
|
||
**Thank you for reading this article!** | ||
|
||
To learn more about ETC please go to: https://ethereumclassic.org |
Oops, something went wrong.