JorgeStolfi 81.01 fonzie 99.66 AlexGR 12,000.00 I had a dream*, around 2 years ago... actually the dream was 18k, but I lowered it a bit for the contest to 12k since the contest date was for april 2016 (still many months to the end of the year / and many months post-halving). * https://bitcointalk.org/index.php?topic=400235.msg7965071#msg7965071Last night I dreamt about a compassionate Donald Trump. Take that into account the next time you dream about btc  |
|
|
|
JorgeStolfi 81.01 fonzie 99.66 AlexGR 12,000.00 |
|
|
|
I keep seeing similar messages like this, does it mean those connected nodes were not upgraded for the hard fork ? Sync data returned unknown top block: 1012266 -> 1009962 [2304 blocks (-1 days) ahead] As I understand it yes. Those messages usually go away after I get a message that a particular node has been blocked. 6 different IPs have been blocked since I restarted my node 11 hours ago. Last one was blocked 7 minutes ago. |
|
|
|
Demand is high, and supply has left the building.
Seems to be some supply, 300 btc to 434 and 675 btc to 500. Ofc it will take more than that. Just redeemed the deposit bottles I collected after people threw them away and bought a couple of lottery tickets for tonight's drawing with the proceeds. |
|
|
|
My investments will be worth more by then.
I'd advise to stay rational here, there is a large probability that they will be worth less. Both XMR and BTC have an extremely large drawdown. But we are already quite low compared to where we will be |
|
|
|
3 minutes ago MoneroHash found it's first block since the fork  Variance  Looks like the network HR has mostly recovered from the drop that occurred just after the fork. |
|
|
|
Curious observation:
Block reward seems to stick for 3 or 4 blocks before reducing (c 1011075 level), and is far less dusty than before (round to 4 decimal places). Is that by design? Should help with dust accumulation in wallets, I imagine.
edit:
back to 12 decimal dust for one block, then back to rounding and repeating...
Possibly the following explains it.....
3. Minimum mixin requirement on all transactions (with some special exceptions for existing "dust")
4. No new "dust" allowed.
Where can I find the definition of "dust"? Mostly in the code. The idea is anything not conforming to N * 10^M where N is 1-9 and M is an integer. Since these values are limited in number within the range of plausible amounts (a total of 181 are currently possible but some of these are implausible) there will always be available outputs of the same size to mix with, in turn allowing mixing to be required. Unfortunately there were a few edge cases not handled correctly and some new dust will be created in some cases, but the amount will be vastly reduced. This will need to be cleaned up in the next fork. The other definition, of amounts that are simply "small" (such as 10^-12) we are allowing to be handled on an economic level for now. For example, miners are allowed to claim less than the full reward if they like, which means they can exclude the very small outputs. This makes their coinbase transaction smaller, which means it will verify and propagate faster (and of course leaves more room for fee-paying transactions). By default this is cutoff at 10^-5 but that is not forced, if miners disagree with that value they can change it. |
|
|
|
Oh my, 22 btc sell wall @420 eaten in 3 minutes  Now a 4.20 btc sell at 420 just placed, cute. |
|
|
|
On a scale of 1 to 10 how tempted am I to sell any Monero now? 0 A couple of days ago I rethought my position being that the price was relatively high. I had some btc acquired from poker so it's not like I could send it to CB  Instead I sent it to ShapeShift in exchange for Monero. I'm used to placing bids and using SS is the same as buying asks so my rate was 334. Lower than it had been the prior day or 2 and certainly lower than it would be in the future. Today was a pleasant surprise |
|
|
|
My daemon status looks fine. I am at block 10009938 but it says, in yellow lettering, I am 95 blocks (0 days) ahead.
# of blocks ahead keeps increasing as blocks are found.
Found the answer on reddit. It's the peers I was connected to. I had restarted the daemon which didn't do anything until 2 peers got blocked after which there are no more # of blocks ahead messages. Duh  |
|
|
|
|
My daemon status looks fine. I am at block 10009938 but it says, in yellow lettering, I am 95 blocks (0 days) ahead.
# of blocks ahead keeps increasing as blocks are found.
|
|
|
|
Wow, what a failed fork. Difficulty FUCK-UP, no blocks in the last 20+ min... universal-pool not compatible ....
FUCKING AMATEUR DEVS!!!
Right on schedule, Primer-! Over 50% of the net hash has been cut off, universal-pool requires modifications in order to work. THIS WAS NOT COMMUNICATED to the pool owners. INCOMPETENT DEVELOPERS!!! Blocks are being found and the hash rate is only down 20% as expected by smooth in the speculation thread. How do you expect anybody to take you seriously when you cry wolf? |
|
|
|
http://moneroblocks.info/ looks good. But, as Primer pointed out... maybe there's still some issue even with 0.9.1 wallets and mining.... try to upgrade to 0.9.3 and resync? or maybe your pool was linked to a peer that submitted and old style block? not sure if version exclusions were added to the code without looking at it.... for some reason moneroblocks.info shows double the HR |
|
|
|
|
Considering the recent action in the altcoin market it doesn't seem likely that the significant increase in value was because of the future hard fork.
|
|
|
|
Okay, I think I can declare victory, as it touched the 32 handle.
Is game over? |
|
|
|
Thank you, I have your site bookmarked. The only thing I'm wondering is, will I notice anything at all when the fork happens while running an up to date node? |
|
|
|
Monero v0.9.3 - Hydrogen Helix - released! (Urgent and important bug fixes to 0.9.2 Hydrogen Helix) https://github.com/monero-project/bitmonero/releases/tag/v0.9.3
Information from Github:This has urgent and important bug fixes to 0.9.2 Hydrogen Helix - Urgent bug fix for database corruption issues in 0.9.2
- Official Windows 32-bit releases are back
- Updates to miniupnpc
- Sets v3 fork date for September, 2016
- Fixes core tests and re-enables them
- Fixes a problem with --password-file not working in RPC mode
<snip> P.P.S. As long as you are on any 0.9.x version in advance of the hardfork you are fine. Clarification question: From a hard fork perspective, any version of 0.9.x will be compatible. However, from a stability perspective, any version 0.9.x, except 0.9.2, are acceptable since it seems that only 0.9.2 suffers from the database corruption issues, correct? Correct, preferably run 0.9.3 since it includes the most recent fixes over all Hydrogen Helix versions. Updated to 0.9.3 Many thanks to all the devs as well as the community. |
|
|
|
You are funny I meant something like this |
|
|
|
Umm, how do I scare people into selling their coins?
A hardfork will happen in less than 2 days. We all know hardforks are bad. Get out while you still can, before you get forked.
This has been a public service announcement.
Is there somewhere a map that can tell, which ammount of nodes is running on pre 0.9.x series to tell which nodes will collapse in a few days   Not that I know of. The node count went from 125 to 150 with the release of 0.9 and as I type we have 185. These are ones with outgoing connections that can therefore be seen. https://monerohash.com/nodes-distribution.htmlSo we should be OK. No what I meant to say is that we are all going to die, sell while you still can |
|
|
|
|
Umm, how do I scare people into selling their coins?
A hardfork will happen in less than 2 days. We all know hardforks are bad. Get out while you still can, before you get forked.
This has been a public service announcement.
|
|
|
|
|
Show Posts
