Payment just came (1min ago, 0 confirms yet). All fine :-)

I received 0.00000001BTC ;-p
Graph was refreshed showing nothing for yesterday, last payout still shows yesterday's payout (for 1.10.).
The transaction with which I was paid contains some 3xx payments of 0.00000001BTC each.
Not sure if we can expect anything to be done about it today, germans are celebrating Reunification Day :-)

Kaspersky Internet Security classifies the fixed win exe as being a Trojan.Win32.IRCbot.eci .
Cannot figure out if this is a heuristic hit or a definitive hit, google won't tell me much about this.
Anybody else's Virus scanners finding anything unusual about the exe or is it deemed safe to run?

Thanks
Mike

Hi,

I tried reverting from update 7 to update 6, re-downloaded blockchain, but problem persists. Any ideas?
I have this on three different wallets on three different PCs.

Thanks!
Mike

Hi,

I'm having some strange coin control display with the version from novacoin-nosetup-0.4.4.6-update7-win32-amd64.zip :

Somehow, the # confirmations OR Date don't match here.
Which value to trust?

Thanks
Mike

Well, tranz' fix addresses just that by setting it to zero when it gets negative.
Since it also does some other calculations, it does not yet have a huge impact when it's only slightly negative.

Hi thundertoe,
I don't see the need for a rollback - can't we just hard-fork in n blocks?
Thanks to this being a hybrid coin, we still have PoW blocks, so we can comfortably fork at any point in the future, no?

Kind regards
Mike

Just my 10 cent:
As far as I can tell, the last two proof-of-stake blocks were 467226 and 467227.
Block 467226 was set two hours into the future, i.e.
467225 blocktime 07/30/14 07:47:33 (PoW)
467226 blocktime 07/30/14 09:47:05 (PoS)
467227 blocktime 07/30/14 07:47:32 (PoS)

Presumably whoever mined that block had a system clock that was way off...

in main.cpp, nActualSpacing is calculated as the time that passed between the last two PoS blocks (which in this case would be negative!)
This value is then used for calculating block difficulty bnNew.
I'm not that much into the mechaincs of block difficulty, but I could imagine that this leads to an insanely high block difficulty for PoS minting (bnTargetLimit?)
Perhaps we need a failsafe for negative time between last two PoS blocks?

Some thoughts on that:
Why not use torrent code outright? That way, lots of code reuse could happen. A node could be a full or a partial node (perhaps a configurable %age of blockchain?). A full node could act as torrent seeder. Since the blockchain evolves, how about simulating a file for each x blocks/MB that is then loaded via torrent - would also speed up initializing a node (instead of requesting blocks one-by-one). File compression could also be considered here.

1% of blockchain with 100 nodes would probably be problematic, each piece of the blockchain needs to be held by multiple nodes in case a node drops out of the network. Even when only two nodes have unique information, they might happen to belong to the same network and get lost when going offline.

How would a partial node know which blocks it needs for having complete info on the addresses it holds without broadcasting its addresses (thinking BitMessage here)? Would it download each block but only keep those it needs? Then it would still take ages for a blockchain like Bitcoin to first initialize. Use something like Tor to anonymously find out about the blocks required, but then download those (and some random blocks for obfuscation) via "normal" network?

Store the info about blocks needed in wallet.dat as a way to "cache" it in case of a required blockchain-re-download?

How to handle the improbably event of a new address generation yielding an already existant address? re-scan for needed blocks after any address generation? Also would be necessary when importing an existing address.

Kind regards
Mike

Hi presstab,

I think I found a display issue with the Staking: I bought & withdrew HYP 11.7. 6:22h UTC (time when the transaction was done, which is the time used for display in the wallet). So they appear ripe now, and the wallet is displaying that it would stake any second now for about a day, incl. displaying a weight in coin control.
However, on 11.7. and 12.7., blocks were slooooow and the transactions were only included in a block on 12.7. in the afternoon.
Since blocks are again slow right now as consequence of being slow 9 days ago, I would have expected them to already stake.
So, now I assume that for staking itself, the timestamp of the block will be used, not the timestamp of the transaction.
In a way this is good, because the transaction timestamp might be faked, but perhaps the GUI should take this into consideration and not suggest them being ripe already?

Kind regards
Mike

Hi,

I think I found a minor cosmetic issue with the Coin Control features: They seem to display time stamps in UTC, whereas the transaction tab shows them in local time.
I would expect coin control to also display local time for consistency.

Kind regards
Mike

Why not use difficulty to let the intervals automatically increases once we have an abundance of mature blocks?
That way, a limit of e.g. 2 days could be used, but as soon as there are plenty of blocks it would automatically take longer and we wouldn't experience HBN-like blockchain bloat.

Oh, then that would be different from Novacoin - there you can do it once but then you see errors in the log because of trying to use an invalid txid as input (something like that, it was a while back I last did this and refrained from doing so since then). It would be included in the next block after the block in which the first one will be included, though. But the client would not let you create more than 2 of these transactions, because then coin control would be confused. That's why they added a feature to not select zero-confirmed transactions as transaction inputs.
If you managed to solve this with HYP, then that's a fine thing :-)

Not aware of any. I checked debug.log - whenever a new transaction is accepted you see the current size, the entry looks like this:
CTxMemPool::accept() : accepted d7147e8e47 (poolsz 113)

I see a potential danger for exchanges. Let's assume someone sends 100000HYP there, and 100 people buy 1000HYP each and want to withdraw them.
This would mean a transaction of 1000 to the first person and 99000 back to the own wallet. These 99000 would then be the input for the next transaction, but they can only be used once they were confirmed...

Don't worry, I have the same problem.
They only show in the block explorer once the transactions have been included in a block.
As long as there are few blocks there are more "floating" (unconfirmed) transactions than can be included in a single block, so expect to wait for a few more blocks until the transactions become confirmed. You can see that the most recent block in block explorer had quite a few transactions (~50) included.
Currently I see in the debug window of my client that there is a total of ~110 unconfirmed transactions, so not counting new transactions being generated we can expect to need at least three more blocks before these will be included in one of them.

Suggestion: Could someone with multiple stakes being ripe in short time consider locking the wallet/quitting the wallet for a while, then go back online later etc., to provide for a more continuous flow of block?
Interest should accumulate proportionally although that person might lose some interest on the interest.

Hi hetecon,

I strongly suggest spreading the risk.

Kind regards
Mike

I had the same issue on my windows 0.4 wallet - delete the folders blocks, chainstate and database from the globe data directory and restart the wallet - it will redownload the blockchain just fine.
Also, initial syncing may take a while as long as there are still un-updated nodes outside - it first needs to find nodes that have the newer blocks.
My theory is this: They already "saw" the first of the new blocks and rejected it before they were updated, and won't request it again after being patched, so you are stuck.
Re-downloading the blockchain works around this issue.

Kind regards
Mike
 

Sent you a PM

Two hours since the last block, stuck at 161279.
Seems suspicious to me, but I don't have time to look at the source right now, will be going to dance school now.