the difficulty will drop drastically in a short time
You could hardly be more wrong. There is no conceivable scenario where difficulty drops quickly. If the last 2016 blocks took less than 2 weeks, then difficulty goes up, not down. The only way for difficulty to drop is for the last 2016 blocks to have taken more than 2 weeks. And the most it can drop is by a factor of 4. But that means that the last 2016 blocks took at least 2 months. So by definition a large drop takes a very long time. If all mining stops, it takes forever to mine another block. If nearly all mining stops, then it will take many months to adjust difficulty. |
|
|
|
if image renderings of a JSON dictionary
Of course they're not rendered as an image. Inscriptions can be any data format you want. |
|
|
|
Perhaps some "Proof of Links" or "Proof of Access Speed" could be created.
For example a Linked List is harder to traverse than an array.
However there is a list ranking algorithm which can run on multiple threads/cores/processors to process the list faster.
Alternatively some kind of network of links could be created in RAM, basically describing some kind of path through the RAM, through cells.
It could be 1D, 2D, 3D or N-D dimensional structure and links.
Some paths/sub paths/links do exist while others don't.
Thus it takes some time to find the way throught the memory. Basically like a MAZE.
How about finding a fixed length path through a random maze-like network of billions of nodes? That gets back to where it started? Which requires following billions of links through cells in RAM? (BTW I think there might already exist some kind of proof of ram or something in some cryptocurrency)
Yes. It's called Cuckoo Cycle, as I mentioned before: https://github.com/tromp/cuckoo |
|
|
|
As I understood more RAM does not increase the chance of winning in cuckoo cycle is it possible to adapt this algorithm to do this? to make a proof of RAM algorithm?Maybe run several times in parallel?
Cuckoo cycle performance depends on several things. 1) memory transaction speed, i.e. how many random bits you can read/write per second. 2) you need to compute a simple siphash24 hash function per memory access 3) You also need a minimum amount of memory, e.g. 512MB of SRAM and 512MB DRAM for Cuckatoo32. You need to balance 1) and 2) so that neither bottlenecks the other. ram memory is much more accessible and "equal" than cpu and then asics.
RAM by itself it useless without the accompanying computing cores to use it. That is, assuming you want to proof of work to actually commit to the contents of the block, so it has to be computed from scratch all the time. We can use cuckoo cycle but instead of increasing the difficulty like in hashcash we increase the amount of memory required. Being asics resistant by design.
That doesn't work too well, since increasing memory also increases the time per solution attempt, and you need to keep that time a tiny fraction of the block interval to keep mining behaving like a random lottery. |
|
|
|
is it possible to make a proof of space that is stored entirely in RAM?
in my opinion proof of space has failed because storing in hard drives is not practical and ends the useful life of the hard drive.
If there is a way to have the voting power based on ram memory, in my opinion,
it would be fairer than proof of work.
i am thinking of just storing hashes in memory and the winner is the hash that is closest to the hash of the previous block.
an attacker can just recalculate the hashes like in conventional pow but in the long run storing the hashes will give an advantage.
if the miner doesn't have a valid hash he can start calculating other hashes with the CPU.
Proof of space is inferior to proof of work in that, in order to prevent grinding, it doesn't directly commit to the transactions in a block [1]. It only commits to a miner private key. The miner then separately provides a signature to commit to the transactions. That means that a group of recent miners can collude to rewrite recent transaction history. A memory bound proof of work, like Cuckoo Cycle [2], seems like a better form of Proof of RAM... [1] https://docs.chia.net/consensus-foliage/[2] https://github.com/tromp/cuckoo |
|
|
|
|
Let's not forget that PoW serves another equally important purpose besides consensus:
PoW is required for fair distribution of coins.
Note that I'm not saying that PoW suffices for fair distribution of coins.
You can still get wealth concentration from premines, instamines, fastmines, mining tax, and so on.
But without PoW you definitely get wealth concentration... weakening decentralization.
|
|
|
|
Ok thats all very fair, is there any evidence so far that DLP is not hard for classical computers? I certainly have not seen any.
Not really, no. But the fact that it's quantum easy does make it more likely to not-hard than NP-complete problem like 3-SAT, that are assumed to be quantum hard as well... |
|
|
|
If ECDLP, the elliptic curve discrete log problem, turns out not to be as computationally hard as we think,
According to Shor leading quantum computers cannot even solve low bit RSA: https://youtu.be/d_5u2qdKoUU?t=3708You misread my post. It has nothing to do with Quantum computers. We assume that ECDLP is hard for *classical* computers, but it may not be... I'm well aware that quantum computers have not been able to factor any number beyond 21 with a general factoring algorithm like Shor's. Shor's algorithm can break RSA and ECC if we get sufficiently powerful quantum computers.
I'd phrase that differently. Algorithms are just mathematical concepts, that exist independently of what hardware we can build to run them on. Shor's algorithm breaks RSA and ECC. But we lack the means to run Shor's algorithm on nontrivial instances. And thus *we* cannot break RSA and ECC. |
|
|
|
what would happen to the value and adoption of Bitcoin if a major flaw in its protocol was discovered and exploited, leading to the loss of a significant portion of the coins in circulation,
and a loss of trust in the technology?
i don't have very technical knowledge about how secure it is .
If ECDLP, the elliptic curve discrete log problem, turns out not to be as computationally hard as we think, and someone happens to stumble on an algorithm to crack it, then they could steal from practically all cryptocurrencies. First they'd steal from ones where inflation remains undetected, by opening Pedersen commitments in arbitrary ways. Next they could try their luck on Bitcoin, taking balances with reused keys. It would probably take a while before public evidence builds. People would first blame victims on poor security practices and such. But if the thief is greedy and keeps at it, people would eventually realize that ECDLP has likely been cracked. Then the value of Bitcoin and all other crypto currencies would quickly plummet. If the thief is not too greedy then the public at large may never suspect though. |
|
|
|
|
A better question would be:
Are you for trying to take measures to hamper, limit, or ban the use of ordinals on bitcoin?
I don't care about ordinals, but given the need to create a competitive fee market, I'm definitely not for any such attempts.
However, to keep with the current poll setup, you could make it less biased by rephrasing
Yes, ordinals are great!
to
Yes, ordinals help create a fee-market that's necessary in the long term.
|
|
|
|
What is the distinction between Dash and monero?
Dash is a cash grab by Evan Duffield, amplifying his insta-mine through rent-seeking masternodes. Dash doesn't offer much in the way of privacy. Monero on the other hand does, by hiding amounts and addresses, and by almost completely obscuring the transaction graph. |
|
|
|
In my study to know more about bitcoin I discovered that difficulty is a measure of the complexity of finding a hash below a given target or the difficulty of mining a Bitcoin block. But I still have problem understanding and I need further clarification about
How blocks of difficulty are stored? And What is the frequency of network difficulty changes?
You should find all your questions answered at https://en.bitcoin.it/wiki/DifficultyIn short: difficulty is stored (in compressed form) in header field "bits" and difficulty adjusts every 2016 blocks. |
|
|
|
That link ranks by market cap, which is not so relevant. Relevant to this discussion is the daily energy spent on mining as approximated by the dollar value of the daily mined coins. You can find this ranking at [1] under column PoW Produced (24h). It shows Monero down in place 9, while Doge and Litecoin are in 2nd and 3rd place respectively. In the long term, coins without a tail emission will slowly drift down this ranking as their mining subsidy dwindles to insignificance. In which case Monero could end up in 4th place behind DOGE, ETC, and Nervos... [1] https://www.f2pool.com/coins |
|
|
|
It's pretty simple, Ordinals is an abuse of the system and abuse has to be prevented to ensure the systems survival. Every tool or a system is created for a clear purpose and when you use it for anything else, that is abuse. Nonsense. Ordinals is an unforeseen use of the system, just as open timestamps is. Neither has to be prevented to ensure bitcoin's survival. Due to the eventually disappearing block subsidy, bitcoin's long term survival is dependent on full blocks creating a fee market, so one clear purpose of bitcoin is to support all uses which help to fill blocks. |
|
|
|
ince there are many miners competing with each other, what's confusing me now is that what if these miners get the same answer at the same time?
Each miner adds their own coinbase tx to the new block. Since the block header commits to all txs in the block (through the root of the tx Merkle tree), this means that each miner works on a unique header. And thus a unique Hashcash PoW puzzle. In case of mining pools, the pool makes sure that different miners on the pool work on different headers as well, e.g. by giving them a unique block template. |
|
|
|
These are arbitrary data that is pushed to the blockchain once to stay there forever, pointlessly increasing the chain size.
As opposed to arbitrary payment data that is pushed to the blockchain once to stay there forever? Like all those silly satoshidice bets? Or the transfers of the NFTs? Or all the "test" transactions that people do to feel more secure about the "real" transaction? In the end nobody can decide what is arbitrary or not. Only fees can. The higher the fees, the higher the barrier for frivolous use, and thus the less arbitrary. Users will always find a way to relay their txs to miners more than willing to earn those higher fees. There's nothing you can do to stop that, only try to make it a little less convenient by imposing standard-ness rules. But with high enough fees, there will always be middleman like ordinals.com to make that process as convenient as can be. If you want less "arbitrary" data, allow all uses of the blockchain to compete and the fees to be raised. Which has to happen anyway if bitcoin is to maintain any long term security. |
|
|
|
I sometimes hear the phrase "it breaks consensus" from hard fork critics. Did Bitcoin Cash break consensus?
Yes, they did, not just by allowing larger blocks, but by in fact *requiring* a block larger than 1MB in size. As a result, BTC block 478559 was rejected by Bitcoin Cash for not exceeding 1MB [1]: ERROR: AcceptBlock: bad-blk-too-small, size limits failed (code 16) (block 00000000000000000019f112ec0a9982926f1258cdcc558dd7c3b7e5dc7fa148)
It took a while longer for Bitcoin Cash to reach height 478559. [1] https://connortumbleson.com/2017/08/02/bitcoin-cash-bcc-is-born/ |
|
|
|
No, we should call on nodes to reject spam transactions that are abusing the system and never relay such transactions.
These are transactions that miners *want* to include because they still pay competitive feerates. So users will find a way to relay them directly to willing miners (as ordinals.com already does), and if not relayed normally, the mempool will show a distorted view of the fee market. You're trying to fight basic economics in a permission-less system. is against the principles of bitcoin, the permit anything file storage system.
Bitcoin is by design a transaction storage system, since the entire tx history must be verifiable. Bitcoin also cannot effectively distinguish between financial scripts and data storage scripts (note that a less efficient data storage in fake P2PK outputs is possible as well). |
|
|
|
|
Show Posts
