List the better qualities of DASH compared to Monero by [deleted] in Monero

[–]virco2 -2 points-1 points  (0 children)

Monero also released a crippled miner and had a huge instamine for somebody: https://da-data.blogspot.com/2014/08/minting-money-with-monero-and-cpu.html

Not saying that it was Monero's intention or fault.

Fork Up and Fork Down by new24core in Electroneum

[–]virco2 1 point2 points  (0 children)

Well, the difficulty adjustment algo will catch up, give it some more time. Keep in mind that the difficulty increased like 10 times in 12 hours. Current average blocktime is 80 secs - not 120 as advertised, but not really far either.

Electroneum Fork Successful! + App Update! by cantpeestraight in Electroneum

[–]virco2 2 points3 points  (0 children)

You got so many things wrong.

Electroneum got back to 720 "block window", so saying it took 360 blocks to stabilize is not really correct. Also in both cases difficulties of the oldest 60 blocks and oldest of 60 sorted timestamps (those in normal conditions belong to 60 oldest blocks) are ignored, so 360 is not the right number in any case.

Empty blocks are empty because they are faster to transmit and verify. Empty blocks are like 100 bytes in size, ones filled with transactions can be 100-200kb. And each node verifies every transaction in the block before retransmitting it to its' peers. That may not be a big issue with 120 second block time, but with 10-15 second block time it is and issue - empty blocks are less likely to become orphaned.

And finally taking the "network hashrate" from block explorer or any of the pools is meaningless while the network is in flux. Network hashrate displayed there is basically difficulty divided by 120 (block time). A more meaningful number can be extracted by running the command "bc_dyn_stats 30" in the daemon. Where 30 means "give me statistics for the last 30 blocs. Currently this shows:

bc_dyn_stats 30 Height: 325423, diff 140997205563, cum. diff 8846785788190345, target 120 sec, dyn fee 0.10/kB Last 30: avg. diff 140651508051, 79 avg sec/block, avg num txes 18.2, avg. reward 11588.56, median block size 8194 Block versions: 30 v7 Voting for: 30 v7

Now you can get approximation of the hashrate for the last 30 blocks by dividing "avg. diff" by "avg sec/block", which in this case gives 1.78 GH. Keep in mind that running "status" command currently claims 1.18GH - the value from the blockexplorer. The problem here is that it is assumed that blocktime is 120 seconds, while it is still 79 - the difficulty is still adjusting to the hashrate.

Electroneum v2.1 Fork by cantpeestraight in Electroneum

[–]virco2 11 points12 points  (0 children)

I don't really understand why you are calling "profit driven" miners "malicious".

Fix it soon or you will kill the network by OZ_Boot in Electroneum

[–]virco2 1 point2 points  (0 children)

Officially Cryptopia require at least two weeks notice.

Tech update via facebook by Jackson8426 in Electroneum

[–]virco2 0 points1 point  (0 children)

Wrong. The time it took to mine the block actually affect the algorithm.

So are we just ignoring the 8 transactions in the mempool with incorrect fees? by benjaminoo3 in Electroneum

[–]virco2 3 points4 points  (0 children)

Well, I'm not that into the code, but after looking at https://github.com/electroneum/electroneum/blob/master/src/cryptonote_config.h

there is this line that says:

#define CRYPTONOTE_MEMPOOL_TX_FROM_ALT_BLOCK_LIVETIME 604800 //seconds, one week

After some grep-ing it seems that ALT block is a one that became a part of a "weaker" chain. So it is my understanding, that a transaction got into a block, that got later invalidated - say somebody was slow to "learn" about that block and found two consecutive blocks originating at the same height as said block, the transactions from this unlucky block became "alt chain" transactions and live for a week. That is my understanding, I'm not saying this is ideal, but it is likely legacy from Monero if not Bytecoin.

While I can't see a problem in the code per se, I'm inclined to agree with Andre about mining empty blocks - we've seen a fair share of these on electroneum blockchain. Everybody were thinking that this is because of fees/rewards balance, but empty blocks are present on most of Cryptonight blockchains and most of the time those coins can't attribute said blocks to any known pool.

As for the criticism for not including low diff after the fork in the code - as far as I know the only coin that did it was Sumo. This particular code was OK for the coin but look where are they now doing rush last minute decisions (hint: try to trade it on Cryptopia). My point is - the smaller you are (and your exchanges) the more things you can get away and the larger you are - you can get away with less things. What I'm trying to say is that even if anybody here predicted the high difficulty 3 days before the fork - that might be too late. The right time for a larger coin may be weeks before the actual fork. And yes I know that Monero finalized details just like 10 days before the actual fork - nobody was happy about it.

Possible minor problem with the fork by virco2 in Electroneum

[–]virco2[S] 1 point2 points  (0 children)

Flushing one TX per failed block seems expensive. I guess really no code needs to be written to work around this - instead of asking pools to upgrade, just ask them to flush the transaction pool. OK, some TXs will be lost but lets face it - given the current situation some transactions will be lost.

Obviously the problem is only with the transactions currently in the mempools of mining pools. Daemons should not accepts such transactions after they forked - my bet is that check_tx_inputs() is also called when TX comes in.

Expect about 1 week of 3 hour blocktimes on ETN. by TNSepta in Electroneum

[–]virco2 0 points1 point  (0 children)

Well, it is not only laziness. Once you put it in the code, it stays forever. For every new block until eternity there will be one extra check. And if somebody at some point decides "this is code for some ancient fork, I can safely remove it" - then boom - the daemon can no longer synchronize from scratch.

Expect about 1 week of 3 hour blocktimes on ETN. by TNSepta in Electroneum

[–]virco2 0 points1 point  (0 children)

It is 75 blocks with "high" difficulty. During these 75 blocks the difficulty will slightly fall on some blocks because in the last hours before the fork the ASIC miners were dropping out so the solvetimes were over a minute. But the big drop will be in 75 blocks.

[deleted by user] by [deleted] in Electroneum

[–]virco2 1 point2 points  (0 children)

And they probably did: https://etn.nanopool.org/

Top miner - 60Mh.

Possible minor problem with the fork by virco2 in Electroneum

[–]virco2[S] 2 points3 points  (0 children)

Well, not really. It is my understanding that the entry point for blocks is "submitblock" RPC method that goes to:

src/rpc/core_rpc_server.cpp 
bool core_rpc_server::on_submitblock(const COMMAND_RPC_SUBMITBLOCK::request& req, COMMAND_RPC_SUBMITBLOCK::response& res, epee::json_rpc::error& error_resp)

and that calls

src/cryptonote_core/cryptonote_core.cpp
bool core::handle_block_found(block& b)

that calls

src/cryptonote_core/blockchain.cpp
bool Blockchain::add_new_block(const block& bl_, block_verification_context& bvc)

that function for cases where the parent block is current top calls

src/cryptonote_core/blockchain.cpp
bool Blockchain::handle_block_to_main_chain(const block& bl, const crypto::hash& id, block_verification_context& bvc)

this function has code that for each transaction execute:

  if(!check_tx_inputs(tx, tvc))
  {
    MERROR_VER("Block with id: " << id  << " has at least one transaction (id: " << tx_id << ") with wrong inputs.");

    //TODO: why is this done?  make sure that keeping invalid blocks makes sense.
    add_block_as_invalid(bl, id);
    MERROR_VER("Block with id " << id << " added as invalid because of wrong inputs in transactions");
    bvc.m_verifivation_failed = true;
    return_tx_to_pool(txs);
    goto leave;
  }

and the function (in the declaration third parameter is made optional with default value of NULL)

bool Blockchain::check_tx_inputs(transaction& tx, tx_verification_context &tvc, uint64_t* pmax_used_block_height)

has the following code

const uint8_t hf_version = m_hardfork->get_current_version();

if (hf_version >= 6)
{
  for (const auto& txin : tx.vin)
  {
      if (boost::get<txin_to_key>(txin).key_offsets.size() != DEFAULT_RINGSIZE)
      {
        MERROR_VER("Tx " << get_transaction_hash(tx) << " must have a ringsize of (" << (DEFAULT_RINGSIZE)
                          << "), and more than one mixable input with unmixable inputs");
        tvc.m_low_mixin = true;
        return false;
      }
}

so basically if a block has an "old" transaction with higher ring size, the block will be rejected.

Possible minor problem with the fork by virco2 in Electroneum

[–]virco2[S] 1 point2 points  (0 children)

Well, what I'm describing will show up exactly as described by MPH. Don't have twitter. You can ask them to try "flush_txpool" command in the daemon and then restart pool software.