PoW has a technical flaw of requiring geometrically increasing amounts of energy
No it doesn't. The only reason for Bitcoin to increase its energy use is for Bitcoin to increase in price, on top of roughly doubling every 4 years for the next few decades to compensate halving block subsidies. This is not a requirement. It's merely what seems to have happened in the past. But as we know, past performance is no guarantee of future results. It's more likely that any further price increases fail to compensate for dwindling block rewards, and energy usage will stop rising as fast as it has in the past, or even decline. |
|
|
|
SHA2 and SHA3 have almost identical computational cost. Yet the "PoW Produced (24h)" in that chart is almost the same and ETH hashrates is 4e-6 times bitcoin hashrate.
You REALLY have no idea what you're talking about, do you? ETH's PoW is not SHA3, it's ethash. Computing a single ethash hash involves two SHA3 hashes, along with many other MUCH more expensive computations (computing the DAG whose values are sampled during an ethash hash involves tons of SHA3 itself, but that is done offline once every 30000 blocks). An ethash hash takes at least 4 orders of magnitude more energy to compute than a SHA3 hash. A scrypt hash is 4 orders of magnitude harder to compute than a SHA3-256 hash.
Scrypt has higher cost than SHA2/SHA3 (4 times according to you) It's embarrassing how you don't even know what order of magnitude means. |
|
|
|
algorithms that sometimes are roughly the same too (SHA3-256 vs scrypt)
Clearly you have no idea what you are talking about. A scrypt hash is 4 orders of magnitude harder to compute than a SHA3-256 hash. Daily dollar emission on the other hand is a good proxy for how much energy will be spent competing for those rewards. |
|
|
|
if I somehow acquired 10% of the total coins in circulation, of a PoS crypto, it'd be like I owned a part of the network... Forever.
So exactly the same as if you somehow acquired 10% of the total supply of a capped PoW coin... |
|
|
|
BTC 215,000,000 THS
ETH 995 THS
LTC 443 THS
BCH 1,400,000 THS
Comparing hashrates of different PoWs is quite meaningless... If you want to compare mining efforts, use something more meaningful like daily dollar issuance; see the column labeled "PoW Produced (24h)" in https://www.f2pool.com/coins |
|
|
|
Hello. Will there be another hard fork or upgrade near future ?
No, there won't be. And the PoW is not expected to ever change. |
|
|
|
I want to make a bitcoin transaction, but if it does not make it into the blockchain before a certain blockheight, I want the transaction to expire so that it can no longer be inserted into the blockchain. Is this possible?
As a layer 2 developer of Bitcoin I deem this capability very important and useful.
No. Not only is that not possible, but such a feature is considered undesirable, as it destroys monotonicity. Monotonicity is the property that once a tx in the mempool is verified, then it remains valid as long as its inputs are not spent. Monotonicity not only simplifies mempool management by a lot, but also provides reorg-safety. This means that in case of a re-org, any undone transactions (that wasn't doublespent) can still be redone. |
|
|
|
there would be no need for development in altcoins because different Drivechains will have different features, like all the different features in altcoins.
You can't have arbitrary features on side-chains. Most importantly, you cannot have a change in emission. E.g. a fair one, like 1 per second forever. |
|
|
|
Even with MimbleWimble, Bitcoin can't beat Monero in terms of privacy. Bitcoin would need to implement additional technology such as Ring Confidential Transaction (RingCT)
Monero's RingCT (and ZCash' zkSNARKs) scale poorly since you never know when outputs are spent, so you have to treat all outputs as your UTXO set. |
|
|
|
You do have the option to not buy them from another miner, though.
Well yes, you could in theory design and build your own ASICs. In practice though, you'd buy them from the likes of Bitmain, which really is another miner as much as an ASIC manufacturer. There's no telling how long the ASIC they ship you has been "tested" by them. |
|
|
|
I'm as pro PoW and anti PoS as anyone, but your case is not strengthened by the sloppy reasoning at the end: In proof of work, when you setup your ASICs and start mining you're, intentionally or not, subsidizing decentralization as the rest of the miners suddenly have less power.
The same thing happens in proof of stake: To acquire voting power you buy stake from existing stake-holders, who end up having less power. The opposite happens in proof of stake: To acquire voting power you increase their gains.
Financial gains has little to do with it. If you buy ASICs from another miner, then you also increase their gains. |
|
|
|
you can't even mine with a single GPU, you'd need a GPU rig that consists of multiple units.
That makes no sense to me. How can mining with one GPU not be profitable, when mining with multiple GPUs is profitable? That would seem to require something really weird like a sublinear electricity cost. |
|
|
|
RandomX could be a good candidate for the shadow-coin as second layer of PoW..
making it harder to perform a sybil / DoS attack [1] against nodes [2] in a blockchain system should be the main reason of such suggestion.
RandomX is the worst possible choice for preventing DoS attacks, as it is very expensive to verify. A good PoW should instead offer instant verification, so the verifier's time cannot be wasted. |
|
|
|
seems pooya is stuck on the 'only verification'=full features..
Yes, pooya, along with most others in this discussion, as well as the vast majority of bitcoin experts, is stuck on the notion that full node is short for fully verifying node. You are one of a small minority of people that have miraculously overlooked this established terminology. |
|
|
|
|
> Although definition of certain terms are sometimes flexible but "full node" definition was always about "full verification" not "full storage and full verification".
Agreed.
Furthermore, many of the nodes considered to be full nodes are actually not,
as they ran with the default assumevalid = true.
|
|
|
|
A full (as in fully verifying) node needs two things in order to sync to the state of some current header. 1) the UTXO set 2) a proof that this UTXO set results from a valid block history from genesis to the current header Part 1) only accounts for a small fraction of the 360GB; the vast majority is taken by part 2). But in principle, part 2) could be replaced by a so-called Succinct Non-interactive Argument of Knowledge with recursive verification, that would be vastly smaller than part 1). See this book for more details: https://zcash.github.io/halo2/concepts/proofs.htmlThis technology is still in its infancy, and formalizing the entire Bitcoin consensus model into a SNARK would be a monumental effort, not to mention constructing the proof (which would have to be redone at regular intervals, e.g. every few months). But verification would be very efficient. |
|
|
|
|
Show Posts
