who will share the list "Undocumented APIs"?
Just use Chrome Dev tools on any page of the explorer, you'll see them being called. They're undocumented not because they're secret, but because there is now compatibility guaranteed, they're from the explorer's purpose, made for the explorer's JS code, and they can be changed / replaced at any time without notice, and they can use obscure ad-hoc formats as well. |
|
|
|
Hi, thanks for reporting, issue should be fixed now ! It was a bug introduced by a recent change in explorer, the change was to accommodate some rounding errors arising from lack of precision in JSON RPC API in some corner cases on some chains. |
|
|
|
... The very bad news is that Poloniex is still owning 8.5 millions of Riecoins. Cryptapus, can't you block RJgv96Q2Qqs91PttwYkgUthgREh669mXqc and all other Poloniex addresses from using your faucet? It is disgusting to see free coins sent to the Poloniex wallet. ... I think fairglu freely admits that the address tagging feature of chainz cannot be trusted. I suspect it's not Polo but one of it's ex users. I don't think it would be wise to start banning addresses as a policy. What cannot be trusted is the guesstimated amount, which is always an underestimation (as it only sees "tainted" addresses of a wallet), but what's there is there (unless the polo private keys got leaked/hacked). Even if Poloniex wallet is offline, it's still quite possible bots forgotten by their owner are still sending funds to those address. Those funds can only be recovered by whoever has the poloniex private keys... |
|
|
|
EXCEPTION: N10tinyformat12format_errorE
tinyformat: Not enough conversion specifiers in format string
lux in ProcessMessages() Not familiar with that kind of error, but if its still occur I suggest to make a full wallet reset, just follow that guide from page 11 and you'll be good https://cdn.discordapp.com/attachments/388703503973089301/492769042327928832/LUX_QT_v5_upgrade_and_reset_guide_for_Win_MAC.pdf[/quote] It's a source code error, tinyformat is basically an alternative to the C printf function which avoids some platform-specific issues at the cost of not being able to detect some errors at compile time, bitcoin core has been making some progress on fixing and detecting those but it's probably not merged in all forks. It's not an entirely innocuous error, there was at least one occurrence where such an error could be used to flood the log file and perform a DoS attack on nodes. |
|
|
|
Hi, the 5.2.5 wallet is complaining with the following error, are there any fixes ? EXCEPTION: N10tinyformat12format_errorE
tinyformat: Not enough conversion specifiers in format string
lux in ProcessMessages() |
|
|
|
Is there a bootstrap available for the v 5 ? Synchronization is going very slowly: I started the daemon a few hours ago, only 212000 headers synchronized and zero blocks. Also debug.log is filling up fast with entries like: 018-07-03 12:07:43 CMasternodeSync::ProcessTick -- nTick 199 nRequestedMasternodeAssets 0 nRequestedMasternodeAttempt 0 nSyncProgress -0.250000 PS: hmmm, it's actually crashing and restarting from scratch at height 392518 PPS: now synch'ed, thx desynct  |
|
|
|
|
I am seeing lots of the following exceptions lately
EXCEPTION: St12out_of_range
CInv::GetCommand() : type=1073741826 unknown type
digitalcoin in ProcessMessages()
Any solutions ?
|
|
|
|
When attempting to compile the latest github from https://github.com/lomtax/digitalcoin it fails with the following error CXXLD digitalcoind
libbitcoin_wallet.a(walletdb.o): In function `copy_file':
/usr/include/boost/filesystem/operations.hpp:381: undefined reference to `boost::filesystem::detail::copy_file(boost::filesystem::path const&, boost::filesystem::path const&, boost::filesystem::copy_option, boost::system::error_code*)'
collect2: error: ld returned 1 exit status
any ideas? this is under Ubuntu 14 LTS PS: it compiles fine under Ubuntu 16 LTS |
|
|
|
Hi, Explorer at https://chainz.cryptoid.info/ccn/ stopped a few hours ago because there is a bug in the chain or the RPC API, as blocks 669665 and 669666 contain the same tx 6702001805f0036a06ba13e544c591f79b935bb5dae1534ed66fcc903f4b4fa6 This means that one of this tx cannot be queried through the RPC API, because the RPC API can only return one tx for a given tx hash (as it should be unique), so the first of the these tx could be doing just about anything. I have manually allowed the explorer to proceed but added a notice, the tx appears to do nothing, but since it should not be possible, it exploited a bug, so manual investigation is warranted to check if the bug was not or could not be exploited in more harmful ways. |
|
|
|
If it bounces on $8800 we are still in the bubble run, which will pop sooner or later. If it stabilizes on $6000, we would be on a ramp up for a second bigger bubble soon, invalidating the next scenario... Long run trend is at $2000, methinks we will get there down slowly throughout 2018 until early or mid 2019. Then we will be shooting for the big million in 2020. It will get real scary mid 2018 when miners will start going out of business with very high difficulty. Lightning will still not be ready to save the day in 2018. There will be bugs. Delays. The usual. But in 2020, you will see governmental and sovereign mining pools, because 2019-2020 sounds about the right timeline for fiat and fiatchains to go tits up, and for Lightning to be ready, tested and deployed. But 2020 will be even more scary, fiat going tits up won't be pretty. Leaving that here for the record   |
|
|
|
This screenshot seems to agree with my explorer on the transaction lines (near bottom), note how the input amount is 26.619, but there are three outputs with values 0, 2498 and 0.015275 respectively. The raw transaction reports the same figures ( https://chainz.cryptoid.info/dmd/tx.dws?fd6bf7e7d04899ebd0b900060bc387c933d5eb47791b869fd02666bb9eb688ce.htm, click "raw transaction" or see below) Not sure why the generated value is reported as 0.0235 in that screenshot, or maybe there is a bug in the raw transaction API ? {
"txid": "fd6bf7e7d04899ebd0b900060bc387c933d5eb47791b869fd02666bb9eb688ce",
"version": 1,
"locktime": 0,
"vin": [
{
"txid": "14a17b25a0348d66c35f78ca490291a20a154daa018f2b777cb919dd9f5de71b",
"vout": 0,
"scriptSig": {
"asm": "3045022100d44734a8ed58bc0ad6b7be12fe156b4a17535a2fa27afccdc1a0251c82579f7202201db3a434c9568b312a7212a6d86d552936f0886f88d0adb66b73a67208fd40e201 03c4f0089b134e63511620e153907dc57ecaa792623b8bbf59bcf6ff91dfa94130",
"hex": "483045022100d44734a8ed58bc0ad6b7be12fe156b4a17535a2fa27afccdc1a0251c82579f7202201db3a434c9568b312a7212a6d86d552936f0886f88d0adb66b73a67208fd40e2012103c4f0089b134e63511620e153907dc57ecaa792623b8bbf59bcf6ff91dfa94130"
},
"sequence": 4294967295
}
],
"vout": [
{
"value": 0,
"n": 0,
"scriptPubKey": {
"asm": "",
"hex": "",
"type": "nonstandard"
}
},
{
"value": 2498,
"n": 1,
"scriptPubKey": {
"asm": "03c4f0089b134e63511620e153907dc57ecaa792623b8bbf59bcf6ff91dfa94130 OP_CHECKSIG",
"hex": "2103c4f0089b134e63511620e153907dc57ecaa792623b8bbf59bcf6ff91dfa94130ac",
"reqSigs": 1,
"type": "pubkey",
"addresses": [
"dJCtEVEqoBuEy5t5A5faZKSKiUBTwKThEb"
]
}
},
{
"value": 0.015275,
"n": 2,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 91257b1e75282903ada3153fdd03d3e5ca12d461 OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a91491257b1e75282903ada3153fdd03d3e5ca12d46188ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"dSekVow8PvDgoSecrJEdAWHwwUeqqHigGt"
]
}
}
],
"blockhash": "7639e9850499ebba1d50781c45b5bbe1cefed951f2b58c5247ed0e4fe0f26d2a",
"confirmations": 275,
"time": 1505793863,
"blocktime": 1505793863
} |
|
|
|
|
With --disable-hardening it compiles, but when starting complains about SSE2 being unsupported (while sse2 is supported, CPU is a Xeon E3)
Makefile contains an -fPIE on CXXFLAGS, when replaced by -fPIC, the error is still there :/
|
|
|
|
try :
make -fPIC
Let me know
Results in make: PIC: No such file or directory
make: *** No rule to make target `PIC'. Stop.
|
|
|
|
I am trying to compile the new 0.9 code and it fails at the end with /usr/bin/ld: libbitcoin_common.a(neoscrypt.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
libbitcoin_common.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status This is under Ubuntu 14LTS 64bit. Any ideas? |
|
|
|
|
AFAICT the 1337 wallet used by the presstab explorer is on a fork: if you look at the presstab difficulty chart, it shows a difficulty drop around height 909k, and their height is just 976843 while CryptoID node shows no such difficulty drop and is at height 1038682.
Presstab explorer also shows most nodes with protocol version 60017, while most of the network is on 60018 (check network tab in my explorer), so maybe it was not updated?
More worryingly some exchanges could have forked as well...
If you look at the "largest wallets" tab on CryptoID, you will see 5 wallets with lots of addresses, these are usually exchange or merchant wallets. Three have recent activity, so are on the same fork as CryptoID node, while the other two have last activity 14 and 31 days ago (as seen from CryptoID node)... meaning they either suspended activity, or may have forked 14 and 31 days ago (and could be stuck on two other distinct forks)
(btw, if you find your exchange deposit address as part of those wallets, let me know and I could have them tagged)
|
|
|
|
I am already on 1.0.1, and this is a windows QT version, for the explorer server-side Linux daemon is required (preferably as source to minimize compatibility issues) Thanks! |
|
|
|
Wallet is reporting Warning: This version is obsolete, upgrade required! However the github was not updated, where can the newer version be found ? Thanks ! |
|
|
|
About time we got a new dev. I am resyncing my wallet. We need more nodes for this coin. Anyone have an active list?
Same problem here, explorer wallet is "stuck" because it has zero connections. |
|
|
|
|
Show Posts
