I hope GRIN stays a PoW coin forever.
Not only will Grin stay PoW forever (the memory hard and instantly verifiable cuckatoo32+), but it will also stay, since the time of launch, the ultimately fair 1 Grin per second forever
|
|
|
- Many other cryptocurrencies that offer similar features to Grin. This may make it difficult to distinguish Grin from these coins.
Grin easily stands out from the tens of thousands of other blockchains in being 1) the ONLY one with a fair emission: every generation gets the same share of supply All else being equal, later generations would prefer to adopt a blockchain that hasn't already handed out nearly all supply to earlier generations. 2) the ONLY one focussing on simplicity and elegance in design. See https://bitcointalk.org/index.php?topic=5309951.msg60800901
|
|
|
Cryptographically secure hash functions are irreversible so that ciphertexts can't be decrypted by running the function in reverse. But none of the data in a block is secret, so the block hash is just a checksum, and shouldn't need to be cryptographically secure. Am I wrong?
If someone find SHA256 pre-images, i.e. given y, find an x with SHA256(x)=y, in time 2^240, i.e. 2^16 times faster than brute force, then SHA256 would be considered broken, and in need of replacement, although not urgently. Such an attack need not have any bearing on the cost of bitcoin mining though. The latter corresponds to find *partial* preimages. As long as finding a preimage to n leading 0s, for n up to say 100, takes time roughly 2^n, then bitcoin mining is unaffected. If someone has a partial preimage attack where they can get by with say 2^{0.9n} then they get an unfair advantage at mining.
|
|
|
grin is PoW and using lot of power there
Grin uses very little power; not even 0.02% of the power that Bitcoin does. You could power Grin from just one windmill.
|
|
|
I guess that's the case with GRIN and other privacy coins.
But Grin is not a privacy coin. It's not focussed on privacy. It's focussed on simplicity [1]. In fact it's the only coin with that focus, so it's in a class of its own. Just like its emission is in a class of its own, with 1 Grin per second forever. Every other coin, without exception, confers a big advantage to early miners (or worse, to the coin creators) at the cost of later generations. Such coins will be frowned upon by those later generations. Grin is the only coin that's fair to later generations. So again in a class of its own. Maybe someone else will "resurrect" it? Grin has always been in the top 25 of PoW coins [2], so it's not in need of resurrection. Grin is also quite young emission-wise; it has only emitted 5% of its soft total supply [3]. In 20 years it will be where Bitcoin was after just 2 years; at 25% of emission. So it's still early days for Grin... [1] https://bitcointalk.org/index.php?topic=5309951.msg60800901[2] https://www.f2pool.com/coins[3] https://john-tromp.medium.com/a-case-for-using-soft-total-supply-1169a188d153
|
|
|
For the majority of people, the rate limiting step for the IBD is the validation, not the download itself. If you sync via Bitcoin Core normally, then it validates as it goes.
Except that it skips the most time consuming validation (signatures) up to a block height specified by assumevalid (defaulting to 80400/Aug2023). So that initial part of history could very well be bottlenecked by download speed.
|
|
|
What if that final drop never happened? It would be backward-incompatible. The article considers a hypothetical alternate design that Satoshi could have chosen. It does not propose any change to the existing design. In fact, I consider any proposal of a tail emission for bitcoin to be a non-starter, as the 21M cap and immutability are the core essence of Bitcoin.
|
|
|
i have to warn that you'll face many skepticism since those who download the backup need to trust you.
No trust is needed. The torrent equipped bitcoin node still queries its peers for the most work header. But whenever this node needs a block with a certain hash, it can just see if such a block is present in the torrent and use that instead of asking its peers for it.
|
|
|
It doesn't matter if it is 21 million. What matters most, is that the amount is finite, so it doesn't lose value like fiat currencies.
It doesn't matter if it's finite. Quoting from [1]: It doesn’t take much to change a finite supply into an infinite one. Bitcoin’s block reward drops from 1 satoshi to 0 satoshi somewhere in the year 2140, completing a supply of approximately 21 million bitcoin. What if that final drop never happened? Bitcoin would continue emitting a 1 satoshi block reward in perpetuity, yielding an infinite supply. It would eventually reach 21 million + 1 bitcoin. Let’s see when that happens. We need to wait an additional 100 million blocks, which takes approximately 10⁸/6/24/365 = 1902 years. Would that make make Bitcoin any less hard a currency? I don’t think anyone would be willing to argue that. So what makes a currency hard, if not a capped supply? I think the answer is obvious. Eventual negligible inflation is what makes for hard currency. It is what distinguishes cryptocurrencies from fiat. [1] https://john-tromp.medium.com/a-case-for-using-soft-total-supply-1169a188d153
|
|
|
GRIN is not yet a thing.
At least not for the people in this forum that care more about high marketcap and breaking ATHs than about fundamentals like simplicity and fair distribution. But those fundamentals will make GRIN outlive most other altcoins, so who knows... GRIN could be considered a thing here in a decade or two.
|
|
|
Are we correctly measuring energy efficiency in proof-of-work? This was proven to be false by a lot of "CPU-based altcoins". For example, if you replace SHA-256 with some slow and inefficient hash function, then you will not only slow down mining, and "kill ASICs". At the same time, you will increase the time needed for Initial Blockchain Download, and the time for verifying anything. That only applies to the Hashcash PoW, where verification time equals solution attempt time. There are also asymmetric PoW such as Cuckoo Cycle [1], where mining takes tons of memory and a relatively long time per solution attempt (~ 1% of block interval), but verification is instant and uses 0 memory. [1] https://github.com/tromp/cuckoo
|
|
|
The only way to have a pure payment system and nothing else (zero arbitrary data) is with MimbleWimble (GRIN, BEAM).
A pure Mimblewimble chain like Grin is very inscription resistant, but Beam has added many features, some of which (smart contracts in particular) can be used to store arbitrary data [1]. [1] https://forum.beam.mw/t/beam-inscriptions/822
|
|
|
They are finally going to end this vulnerability!
Except that they can't. By design, Bitcoin allows a fair amount of entropy even in the plainest of transactions, at least 32 bytes per output. The harder that you try to censor the current ordinals encoding, the more you force it to adopt alternative encodings exploiting that entropy, that are indistinguishable from regular payments. While that forces them to pay more in fees, that's clearly not going to stop them. WORSE yet, by forcing their encodings to be indistinguishable from regular txs, you make it impossible to prune the ordinal data from a full node.
|
|
|
Have you ever tried to replace p with n to see what happens? I have and I can say you can break ECC by doing it, don't just panic yet, I have difficulty figuring out to map a point from e.g, n = 67, p = 97 to a curve with n = 97, p = 67. something that could give away a clue from first curve points to the second curve points.
There's something called the secq256k1 curve [1]. Note that > although the two curves are isomorphic, the actual isomorphism is not efficiently computable — as far as we’re aware [1] https://hackmd.io/@dJO3Nbl4RTirkR2uDM6eOA/Bk0NvC8Vo
|
|
|
But we don't have a centralised ledger here and we value our freedom (or, at least, some of us do), which is why we call such projects altcoins. People can go and play with those if they like banning stuff.
You can also have a blockchain that prevents arbitrary data (aka spam) by design rather than by banning: https://bitcointalk.org/index.php?topic=5437464.msg61782921#msg61782921
|
|
|
If the block size can be in a way that 1 sat/vbyte transactions can all be processed in the next block, will this not be good?
No, that will be terrible, since the block subsidy is slowly being phased out, leaving security of the chain entirely up to fees. The capped supply can only work in the long term if a fee market develops based on sustained congestion.
|
|
|
1) there are 1 million solo users with one 1th/s, the hashrate will be 1 exahash No, the hash rate will be 1th/s. Solo miner hash rates do not sum. Do you really believe that two fixed-hashrate solo miners will grow a fixed difficulty blockchain at the same rate as one solo miner?
|
|
|
The work done to mine a block is only cumulative if it was done cooperatively, by the aggregate work of a mining pool.
A block produced by a solo miner isn't cumulative because his work was not a group effort.
All the miners in a mining pool, while working on the same block template, still work on different headers, with different nonce and extra nonce ranges. Literally working on the same block (i.e. on the same header) would be an extraordinary waste. Btw, you should read this older thread, which covers a lot of this material: https://bitcointalk.org/index.php?topic=5432391.0;all
|
|
|
Solo miners work on their own unique blocks, so they do nothing to eliminate bad outcomes for each other.
It matters not in the slightest which block you're trying to mine. Only that it's on top of the latest (more specifically, the highest cumulative difficulty) block.
|
|
|
The problem with solo mining is that there is only one winner per block, and all but one loses, resulting in an extraordinary waste of energy.
That's quite wrong; there's no waste, except a small fraction due to miners not building on the latest block. It's the aggregate hash rate that determines the (cumulative) difficulty and thus the energy required to reorg the chain. The energy is not wasted but converted into reorg resistance.
|
|
|
|