if you mean real network than no, i'll start real network not earlier than in two days after test net start.

Sorry about start.
Test network is not started yet.
As for development - it is everything ready for start, but have some unresolved organizational problems, and i'm working hard to solve it.
Hope we'll start tomorrow.
Thank you for understanding.

I feel that i need to have more clear description.
Each block's entry in scratchpad is not depends of number of transactions included in it.
It is fixed to about 320 bytes and use prev_id, merkle root, onetime coinbase  key, and hashed coinbase outs (usually 8 ).
I'll put more detailed description.

1. it gives correlation between calculations time and memory wait time.
2. yes. addressing based on state buffer.

Not very big.
It's not about huge memory amount, scratchpad is building on blocks pseudorandom data, such as hashes and tx keys, and will grow about 90MB/year. Huge scratchpad gonna make almost impossible to have SPV-client.

Updated Hash Function topic https://bitcointalk.org/index.php?topic=588421.msg6449056#msg6449056
Tomorrow we starting test network!

IT SEEMS THAT ANY DONATIONS MODEL DOESN'T WORK AT ALL.
It always have a way to cheat.
Probably pozmu was right:


May be we should make some hybrid model(transactions&miners):
Each tx can vote or be neutral.
Miners should vote in coinbase flag, but if miner vote for donation, block can include only tx which voted for donation or neutral. And vice versa, if block voted against donation - it must include only tx voted against or neutral. Pretty weak relation with tx, but it is.

Once a day count blocks that voted for donations and if say 80% is voted than devs gets their fixed percent for this day. Or use this approach without tx voting at all(back to miners power).

Even if this model would be unsuitable may be it is better to go without voting at all - just a pure smoothly emitted premine.

Yes, 2 minutes. I think it's good balance with confirmation speed and blockchain data overhead.

Yes, GitHub is a primary dev tool,at this moment it is used more as a version control, later will be used as bugtrack and wiki, why not.
At first weeks after start i think there will be a lot of bugs and any help would be welcome, so fill free to post issues and even bug fix;)

You right, again. Ok.

Of course.

As for network rules - fee can't be zero, this is only restriction set.
But, block reward actually depends of block cumulative size (size of coinbase blob + transactions blob sizes).
If block cumulative  size bigger than median of last 400 blocks than reward calculated as:
reward =  (base_reward * current_block_size * (2 * median_size - current_block_size) ))/median_size
and if block cumulative size bigger than 2*median_size than block is not allowed.

This self-addapting approach used to avoid (or make expensive) tx flood.
Console wallet in all CryptoNote-based projects have default fee defined as DEFAULT_FEE = DEFAULT_DUST_THRESHOLD = 1000000. (skipped in transfer command options just to avoid overhead with syntax).

So dev is not able to force fee up, it designed as self-regulated model.
The only way i can see is to enable big fee by default in wallet software, but i guess at the same time another wallet will be announced as more profitable

Absobloodylutely!

To be more clear - HP is a two devs at this moment. One more familiar with core and network, another prototyping GUI and made support for MacOS.

Thanks!
But bug was a little different: cb was always called, because "i" was always == rsizw.
Anyway, it's wrong behavior, fixed.

this is it!! really bright idea!

We finaly decided to go in another way in out project, so now we don't use CryptoNote PoW hash at all.
(In test network the only fix we've done is scratchpad reducing, but it wasn't conceptual step, it was just to run testnet and check other features.)

We need to implement final monetization model (that discused here: https://bitcointalk.org/index.php?topic=590520.0), and we want to have may be more tests for hash and for core.
So i think we'll be ready to start test network with final settings at may 8 or 9. With test network start i'll announce real net launch exact time.

I suppose no, since name will be changed project's home dir will be new created.
We going to leave test network alive, like bitcoin does, but daemon may be compiled OR for real network, OR  for testnet(with projectname-test sufix in name macro on sources), to avoid conflicts in blockchain data.

[/quote]

11-12 May

Little surprise for ASIC engineers, considered that effective 64-bit multiplication is pretty expensive to have on each core. (unlike normal CPU)
Just to reduce the enthusiasm.

Good news!
We've added UPnP support with reannouncing every 20 minutes (like bitcoin do). Just merged it in master branch.
Anyone who have UPnP router - please check this - or by running daemon, or just run functional_tests --test_miniupnp.
We've checked it on two devices - one was correctly configured, other failed.

We already have almost this name

For each tx donation value is defined as:
donation(tx) = (if (donation_flag_set) fee; else 0);

For each block average donations value is:
avr_donations(block) = sum_of_all_tx_donatons/tx_count


For example:
block1 have following transactions in txs[]:
txs[0]: fee=100, donation flag=0;
txs[1]: fee=200, donation flag=0;
txs[2]: fee=100, donation flag=1;
txs[3]: fee=150, donation flag=0;
txs[4]: fee=100, donation flag=1;
txs[5]: fee=100, donation flag=0;

avr_donations(block1) = (0 + 0 + 100 + 0 + 100 + 0)/6 = 33


Finally, once a day(each 720th block) donation value to transfer to devs calculated as a median(avr_donations(block0), avr_donations(block1)....avr_donations(block719)) * 720

Does it make sense ?

UPDATE:

donations(block1) = (0 + 0 + 100 + 0 + 100 + 0)  = 200