 Show Posts
|
|
Pages: « 1 [2] 3 »
|
CVE-2018-17144-fixed wallet got stuck again, at block height 261908...It seems the 3rd impact. The block height 261909 is suspicious...you can see it on the Yenten Explorer: https://ytn.overemo.com/block/261909And you will notice the wallet address: YSUD4qhUchTWPUtEiYC6xN2eCmE82C1437 https://ytn.overemo.com/address/YSUD4qhUchTWPUtEiYC6xN2eCmE82C1437Then, absurd transaction: https://ytn.overemo.com/transaction/5cffc6caf05d7ce7c7b1819d066b76b51f666ae9d0b40764948a6ef84d6a112b80000000 YTN was distributed... 80,000,000 YTN... we can see the number on Conan's site: https://conan-equal-newone.github.io/yenten/index2.htmlTotal YTN setting: 84,000,000 YTN Calculated max YTN: about 80,000,000 YTN ...so, it's maximum attack, isn't it? I think that such a deeply polluted block-chain is useless and can't be continued even with hard-fork... and we can see significant drop on STEX and CREX24. It seems that I must say Good-bye Yenten again. |
|
|
|
It’s sadly official, but Yenten is dead and over..
For those who looking for CPU mining coins to mine, i can suggest Cryply, Koto, Elicoin.
It’s time to stop wasting time and to look forward.
I think Cryply and Koto are robust against CVE-2018-17144, as their base source codes look older, like Yenten-1.3.1. Elicoin has not been got maintenance, so still holding a risk of CVE-2018-17144 attack: https://github.com/elicoin/elicoin/blob/master/src/validation.cpp#L2885Yenten was too famous to avoid getting attacks. Maybe its historic role is coming to an end though, I was enough enjoyed on Conan's joke! I have no intention and no ability to force extending its life, but still there are several interesting issues. My biggest interest about Yenten is why v2.0.1 wallet can't sync block-chain from start, without prepared block data. Ironically v1.3.1 wallet still holds the meaning to exist, at this point... - edited: from "no intention and ability" to "no intention and no ability"...I'm not sure it makes difference, but just for clarification...English is difficult for me! |
|
|
|
Doesn't work on Mac bro. Thanks for your efforts anyway.
Oh...thanks for your trying! Probably I wouldn't be able to figure out the issue by my almost zero experience about Mac though, but curious how it doesn't work...any error message? The message is that the macOS is not the latest one (which seems to be required). However, I am on the latest version (Mojave). (This is just a generic message however that I have seen with other programs too when the software will not run). Thanks, so I'll try to update my macOS to Mojave and build the wallet on it! Hmm, I've updated my MacBook-Air to macOS Mojave 10.14.1 and my Yenten-Qt binary still works fine as same as on High Sierra. Here is a screenshot: https://twitter.com/ohashi3d/status/1058119924814495749I have no further idea, sorry... |
|
|
|
Doesn't work on Mac bro. Thanks for your efforts anyway.
Oh...thanks for your trying! Probably I wouldn't be able to figure out the issue by my almost zero experience about Mac though, but curious how it doesn't work...any error message? The message is that the macOS is not the latest one (which seems to be required). However, I am on the latest version (Mojave). (This is just a generic message however that I have seen with other programs too when the software will not run). Thanks, so I'll try to update my macOS to Mojave and build the wallet on it! |
|
|
|
Doesn't work on Mac bro. Thanks for your efforts anyway.
Oh...thanks for your trying! Probably I wouldn't be able to figure out the issue by my almost zero experience about Mac though, but curious how it doesn't work...any error message? |
|
|
|
I agree. It is quite likely that CVE-2018-17144 attacks have happened which is why updating to a fixed wallet is important (2.0.2 unofficial or ohashi3d sources does not matter in this aspect - only difference is 2.0.2 unofficial makes it possible to check how many nodes have updated by advertizing a unique version string). I don't think the chain split is related though. If you look at chainparams.cpp lines 93-96 you see deployment of of BIP68, BIP112, and BIP113 has started 2018-10-01 (i think you noticed this yourself too) and i have seen a 2.0.1 node reject a 1.3.1 block for consensus reason (block versions between 1.3.1 and 2.0.1 are very different and 2.0.1 has started to enforce it's own version). Sadly i did not save the log but in my opinion it that is the reason for the split.
Yeah, BIP68, BIP112 and BIP113 have started from 2018-10-01...though I've not studied them, OP_CSV enough. I'm not sure how OP_CSV related to the attacks or not... I need more and more studies about blockchain. There were two block/hash as the candidate at height 248958: (a) 00000022193d53b1aa17ac7b86fce2ceecbaba36f0e6d2a0a483c227d7aa4d67 (b) 0000002390e6be74008db3fd88a144657de442cf03f72e9f8a2e446fd6f304f1 Here is my quick check thead on my twitter (sorry in Japanese) again: https://twitter.com/ohashi3d/status/1054404573526294528The block/hash (a) has block version = 2, and if block version=2 and BIP66 activated, such a block/hash will be rejected by v2.0.1-based wallet: https://github.com/ohashi3d/yenten/blob/master/src/validation.cpp#L2973and BIP66 was activated at block height 198765 in v2.0.1-based wallet: https://github.com/conan-equal-newone/yenten/blob/master/src/chainparams.cpp#L81The block/hash (b) has ridiculous/absurd transactions as mentioned in my previous post. Both block/hash (a)(b) look suspicious for me... So... Conan's original v2.0.1-fix (this '-fix' doesn't mean CVE-2018-17144) wallet rejected block/hash (a), and picked block/hash (b), though it might be polluted by duplicate input attack. In opposite, v1.3.1 wallet picked block/hash (a) and rejected (b) as duplicate input attack. ...this is my guess for blockchain split mechanism, and CVE-2018-17144-fixed wallet rejected both block/hash in this situation, and got stuck... |
|
|
|
As described in my previous posts (#3936 and #3940), my CVE-2018-17144-fixed wallet got stuck twice, at block height 248957 and 250704, so far. It means that block height 248958 and 250705 were not acceptable, and the transaction you referred above is included in block height 250705. I think there were CVE-2018-17144 related (duplicate input) attacks to Yenten blockchain, and Yenten blockchain was forked at block height 248958. Now there are two blockchains in Yenten world: - v1.3.1 wallet is running around block height 253914 - v2.0.1 wallet is running around blcok height 258800 v1.3.1 chain after block height 248958 is not compatible to v2.0.1 chain, and it might be difficult to update to v2.0.1 if you made any transaction after block height 248958... |
|
|
|
I also checked the block 248958 by v1.3.1: https://twitter.com/ohashi3d/status/1054504341715873793The block version (decimal: 2) is strange, and that's whiy CVE-2018-17144-fixed wallet didn't get this block. Also emply input field is observed... And...though it's quick test by almost default BTC setting, blocks after 248959 by v1.3.1 aren't readable by this BTC-RPC-Explorer... I had been thinking that v1.3.1 blockchain may be healthy, but it doesn't look so. - Originally v201fix source code has a block version check part, and it prevents v201-based wallet from picking the version 2 block. - CVE-2018-17144-fix made the situation that the original wallets and CVE-2018-17144-fixed wallets banned each other. By these two reasons, CVE-2018-17144-fixed wallets couldn't participate in both v1.3.1 and v2.0.1 chains and got stuck at block-height 248957... ...it's my thought, so far. |
|
|
|
I've just tried synchronizing with v1.3.1 daemon and the backup block data at May 25th. ... 2018-10-20 01:31:54 UpdateTip: new best=00000007876142530eaeca32e71d38179480cbebc45fe964fbe0c3e84b012493 height=248957 log2_work=45.519688 tx=1106206 date=2018-10-15 17:10:23 progress=0.997061 2018-10-20 01:31:54 ProcessBlock: ACCEPTED 2018-10-20 01:31:54 ProcessBlock: ORPHAN BLOCK 267, prev=00000025418b7351588bbcbb9c957a6c3a581bd10b433952aef3d694edc68763 2018-10-20 01:31:54 ProcessBlock: ORPHAN BLOCK 268, prev=000000374b9231b2bae0534cd3d4e35924f32a81184aac6eef209697330e2123 2018-10-20 01:31:54 ERROR: CheckTransaction() : duplicate inputs 2018-10-20 01:31:54 ERROR: CheckBlock() : CheckTransaction failed 2018-10-20 01:31:54 ERROR: ProcessBlock() : CheckBlock FAILED 2018-10-20 01:31:54 ProcessBlock: ORPHAN BLOCK 269, prev=0000002593846bb0d8716c00fbf30132c497b42e70315a0f65404ed129fc2e4a 2018-10-20 01:31:54 ProcessBlock: ORPHAN BLOCK 270, prev=0000002390e6be74008db3fd88a144657de442cf03f72e9f8a2e446fd6f304f1 2018-10-20 01:31:54 ProcessBlock: ORPHAN BLOCK 271, prev=000000356605da7b259ec6893892b320bfd305d68edddc92e71fb64da1ba6f50 ... After block 248957, "duplicate inputs" message emerged, so sure enough, there was attacks, I think. Interestingly, v1.3.1 daemon didn't stop synchronizing after block 248958. It processed 300+ orphan blocks, and recorded hash values below: height=248958: 00000022193d53b1aa17ac7b86fce2ceecbaba36f0e6d2a0a483c227d7aa4d67 height=248959: 00000013b54daf77086e740d4e0d7721afd933614c84321c54d2f4d85e553d42 These are same as the values on the Yenten Explorer https://ytn.overemo.com/So...now, the Yenten blockchain became quite unhealthy...we will get different hash value from different version nodes. CVE-2018-17144-fixed wallet may be useless in this situation... And "duplicate inputs" messages still continue emerging on debug.log...it looks hopeless for me, unfortunately. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Edited: I've deleted my CVE-2018-17144-fixed Windows binaries: https://github.com/ohashi3d/yenten/releases/tag/2.0.1fix_CVE-2018-17144Though I may still try running Yenten daemon for my technical interest, Good bye Yenten, for a while, or eternally... |
|
|
|
Use the Debug window command:{getblockhash "height"} on the Official 2.0.1fix wallet, I find the hash of block 248958 and block 248959 is the same with your debug.log of CVE-2018-17144-fixed wallet.
Yeah, these were obtained with the Official 2.0.1fix wallet: block 248958: 0000002390e6be74008db3fd88a144657de442cf03f72e9f8a2e446fd6f304f1 block 248959: 00000015b1fa187ffdc1bd7c16dea391702b58b765bf50433dd1666ca2d3973e I'm curious what version is running on https://ytn.overemo.com/... And my CVE-2018-17144-fixed wallet got stuck again at block height 250704: ... 2018-10-18 04:23:21 UpdateTip: new best=000000224d12ce6300e18f44e5fa449bc1f7185deab6cca655213c9dab468f34 height=250704 version=0x20000001 log2_work=45.524203 tx=1109470 date='2018-10-18 04:22:51' progress=0.999998 cache=0.4MiB(2897txo) 2018-10-18 04:23:21 connect() to 195.201.212.26:9981 failed after select(): Connection refused (111) 2018-10-18 04:24:23 ERROR: ProcessNewBlock: AcceptBlock FAILED 2018-10-18 04:24:28 Misbehaving: 85.175.30.184:54303 peer=736 (0 -> 100) BAN THRESHOLD EXCEEDED ... Still, after syncing with the original 2.0.1-fix wallet, my CVE-2018-17144-fixed wallet got into running again... I'm not sure whether it's a result of attack or not, but anyway it looks chaotic, endless battle... |
|
|
|
CVE-2018-17144-fixed wallet stopped accepting blocks at height 248957. In my debug.log: ... 2018-10-15 17:11:09 UpdateTip: new best=00000007876142530eaeca32e71d38179480cbebc45fe964fbe0c3e84b012493 height=248957 version=0x20000001 log2_work=45.519688 tx=1106206 date='2018-10-15 17:10:23' progress=0.999997 cache=0.7MiB(5617txo) 2018-10-15 17:11:09 CreateNewBlock(): block weight: 12110 txs: 26 fees: 240000 sigops 504 2018-10-15 17:11:15 CreateNewBlock(): block weight: 12560 txs: 27 fees: 314777 sigops 508 2018-10-15 17:11:32 ERROR: ProcessNewBlock: AcceptBlock FAILED 2018-10-15 17:11:32 Misbehaving: 185.185.69.156:9981 peer=2 (0 -> 100) BAN THRESHOLD EXCEEDED 2018-10-15 17:11:32 ERROR: ProcessNewBlock: AcceptBlock FAILED 2018-10-15 17:11:33 Misbehaving: 212.192.89.210:9981 peer=3 (0 -> 100) BAN THRESHOLD EXCEEDED 2018-10-15 17:11:33 ERROR: ProcessNewBlock: AcceptBlock FAILED 2018-10-15 17:11:33 receive version message: /Satoshi:2.0.1/: version 70015, blocks=248958, us=180.42.175.133:41346, peer=87 ... "AcceptBlock FAILED" message is defined in 'ProcessNewBlock' function, in validation.cpp. 'ProcessNewBlock' function calls 'CheckBlock' function, and Fix for CVE-2018-17144 is enabling a check in 'CheckBlock' function. So...my guess is, there was a attack attempt related to CVE-2018-17144 on Oct. 15th. I think running CVE-2018-17144-fixed wallets is very very very few, so the fixed wallets were banned... The original 2.0.1-fix wallet looks working as usual, and once synced with the original wallet, CVE-2018-17144-fixed wallet works again, at least at this moment. But while CVE-2018-17144-fixed wallets aren't in the majority, fixed wallets will be banned again in the next attack... I think this situation will not change easily... Another supporting evidence of attack attempt: The Yenten exploer https://ytn.overemo.com/ shows: block 248957: Block hash: 00000007876142530eaeca32e71d38179480cbebc45fe964fbe0c3e84b012493 block 248958: Block hash: 00000022193d53b1aa17ac7b86fce2ceecbaba36f0e6d2a0a483c227d7aa4d67 block 248959: Block hash: 00000013b54daf77086e740d4e0d7721afd933614c84321c54d2f4d85e553d42 The hash of 248957 is same as my debug.log by logged with the CVE-2018-17144-fixed wallet, but 248958 and 248959 are different from the value by logged with the original 2.0.1-fix wallet: block 248958: 0000002390e6be74008db3fd88a144657de442cf03f72e9f8a2e446fd6f304f1 block 248959: 00000015b1fa187ffdc1bd7c16dea391702b58b765bf50433dd1666ca2d3973e BTW, though I'm a Japanese, the Yenten Disccrd is not comfortable for me, at this moment, unfortunately... I may upload Windows binary of CVE-2018-17144-fixed wallet stamped with version 2.0.2 on GitHub, of my own will, but also I may delete them, of my own will. |
|
|
|
ohashi3d, well done! I have risked  It works for me Thanks, I'm glad to hear it |
|
|
|
Dev,
How many confirmations are needed for this coin to mature.
I'm not a dev, but usually observe that 'yenten-cli listtransactions' shows "immature" upto 100 confirmations, for a newly mined block. After 101 confirmations, the status changes from "immature" to "generate". You are not a dev?? I noticed you provided CVE-2018-17144 security fix for Yenten wallet. To my knowledge, it will close what they call "catastrophic" security holes in the wallet. From your perspectives, when the change will be reflected in the new wallet and released? I wanted to say that I'm not "conan-equal-newone" in my previous post. Of course, there are many experts in this Forum, I think "Dev" is the word for "conan-equal-newone" concerning to Yenten. Indeed, as you wrote, I forked yenten on GitHub and applied the CVE-2018-17144 patch, just as disclosed on Bitcoin's GitHub pages below: https://github.com/bitcoin/bitcoin/commit/696b936aa3ab6f459d0e16f9805eaeb747a0036cBut I'm just playing/studying programming like something puzzle. As for CVE-2018-17144 fix, I just googled and did almost copy/paste work, as the answer was there. Also I have no experience aboiut building Windows Qt Wallet binary. ...I have no word for your question... BTW, another person "u978" had already sent a CVE-2018-17144 fix pull-request 10 days ago, but still not merged, unfortunately. In June, "conan-equal-newone" responded my/our posts about incorrect mining reward setting (250YTN <-> 50YTN). I hope conan still has interest for Yenten... |
|
|
|
Dev,
How many confirmations are needed for this coin to mature.
I'm not a dev, but usually observe that 'yenten-cli listtransactions' shows "immature" upto 100 confirmations, for a newly mined block. After 101 confirmations, the status changes from "immature" to "generate". |
|
|
|
Waiting on pers options 😎
In release v4.5 of Funakoshi-Miner the --pers parameter is supported. I've tried Funakoshi-v4.5 and EWBF-v0.5 for Bitcoin-Gold mining on 2miners. Here is my tweet...of course in Japanese:) https://twitter.com/ohashi3d/status/1038554573357572097Ubuntu 16.04 with nvidia-396.44(CUDA 9.2), for both the single GTX1070 system and the rig(composed of 8 GPUs). * Edited * I'm trying v4.6 now:) * Edited #2 * My tweet: https://twitter.com/ohashi3d/status/1038918179949408256Though EWBF-v0.5 keeps advantage in my environment, I feel there is no apparent difference in actual rewards, such as in hashrate. |
|
|
|
|
