...unless I can fix the terrible design flaw that has plagued Yacoin since day one. That is, using the PoW hash for EVERYTHING. This, as you know makes the client use more and more resources to run and gets worse for every Nf change. It shouldn't take a coin 15 days to sync and a non mining client shouldn't run at a high CPU and Memory rate. That's the main reason Yacoin is not on any exchanges.
Litecoin uses GetPoWHash TWICE, Yacoin, almost 100.
OH MY GAWD.
:facepalm:So, let me verify that I understand correctly—because I just can’t believe it:
Yacoin uses scrypt as a generalized hash!?That is easily one of the ten worst altcoin ideas that I have ever seen (and the other nine are from BSV). I think that I will now die of laughter. Thanks.
But alas, your coin is not yet optimally pessimal. I can help you pessimize it further.
I doubt that Yacoin really uses scrypt for
everything. What about digital signatures? ECDSA needs a hash; deterministic ECDSA needs several hashes. If you instantiate those hashes with scrypt, preferably at a high
Nfactor, then you will make validation
extremely slower.
* Nullius the Cynic is a grandmaster of pessimization.
But why stop there? Why not use for all hashing purposes a Verifiable Delay Function based on
iterated scrypt?
While you are at it, find anywhere in the code that uses a sorting function, and change it to use
permutation sort. Once upon a time, as a fun learning exercise, I wrote an optimally pessimal permutation sort implementation; if I can find that old code, perhaps I could contribute it. That makes almost as much sense as using a
password hashing function as a general-purpose cryptographic hash!
Someone needs to tell Colin Percival, the designer of scrypt, that an altcoin is using it as a hash function for
everything. He was unhappy when he heard about Litecoin’s misuse of his creation; it is not designed as a POW hash, and using it for that purpose is stupid enough.
Reminder: YACoin 1.0 is a completely open, decentralized cryptocurrency,
Yes, we don't need the NFactor hash for everything. It is Yet Another flaw to address, although it is overblown. A solution to that is already in the works. It's not like other cryptocurrencies haven't address this. In the meantime,
for downloading and syncing the chain, you can use this link.https://mega.nz/file/SZcVWSRK#HEP0u6GkrNBuvloZv-vijcJtCXPNgiHv1WHAzeSoxDY“Download the blockchain from this anonymous Mega link, and don’t validate it
at all because it is too computationally expensive to validate” is not what I would call “decentralized”.
That Mega link can contain any version of the ledger that you may desire.
It can even contain an invalid ledger. You are now a trusted central authority.
Hello, do you realize that Bitcoin Core even removed
checkpoints? The whole concept was replaced long ago with
-assumevalid. I myself recommend setting up your first node with
assumevalid=0,
viz., validate all scripts in all transactions; and then, you can set up other nodes using an
assumevalid hash from something near the chaintip of your own node.
assumevalid only skips script verification;
everything still needs to be hashed.
Stop allowing this nonsense.
if (
(0 < nPosBlockCount)
&&
(
(
fTestNet
&&
pprev
)
||
!fUseOld044Rules //(nTime >= YACOIN_NEW_LOGIC_SWITCH_TIME)
)
)
What the fuck is that, COBOL?
It reminds me of one fine day in early 2014, when I decided to try to audit OpenSSL. The code looked just like that, plus mazes of nested
#ifdefs. To avoid blindness and insanity, I gave up after about ten minutes. By coincidence, this was about two months before Heartbleed was discovered; if I had persisted, perhaps I could have been the one to discover it!
Upgrade all code. No one is going to take seriously a coin that is running Bitcoin 0.8.6 code. You mention fixing a few errors, GREAT, what about the few hundred commits that have occurred in Bitcoin since?
A “few hundred commits”? Nice guess; you are off by only two orders of magnitude.
nullius@onion:~/src/bitcoin$ git rev-list v0.8.6...v0.21.0 | wc -l
22543
Oh, and...
nullius@onion:~/src/bitcoin$ git rev-list v0.21.0...HEAD | wc -l
1931
Of course, this does not count commits from any of the many PRs that are reviewed, rejected, and closed without merging.
Bitcoin development is highly active. Core is slow to release new features, because breaking the network could wreck a trillion dollars in value; they do not “move fast and break things”. Whereas Bitcoin has some of the most active development of any cryptocurrency!
Joe_Bauers, my condolences.
If you want to try to salvage something from this mess, I suggest calling it “Yacoin Classic” instead of “Yacoin Cash”. Well, that is if you avoid a network hardfork. Bcash was a network hardfork; the various coins called “Classic”, such as Ethereum Classic, were typically created to
avoid contentious hardforks. If you want to remove the “use scrypt for everything” pessimization, I infer that you probably need your own hardfork; in that case, perhaps try “Yacoin Optimized”. (I first thought to suggest “Yacoin Unbroken” or “Yacoin Less-Stupid”, but that would just be cruel.)
Merging fixes and upgrades from Bitcoin can have huge benefits. I have some practical experience with this;
e.g., after Zcash pulled in Core’s switch from OpenSSL to libsecp256k1 for validating signatures, I could
feel how much faster sync was. Quantitatively, jlopp measured “
significant performance improvements to the tune of more than a 50% speedup” between his tests of Zcash 2.0.1 and Zcash 2.1.1, probably due to merges of such upstream improvements—yes, sync time was
cut in half. Of course, faster point arithmetic for secp256k1 is relatively meaningless if you have a maximally pessimized coin that is using scrypt for all of its hashing needs.
Thanks for the laughs. I mean that sincerely and unironically. This thread made my day.
