Topic: [ANN] AEON [2019-09-27: Upgrade to version 0.13.0.0 ASAP HF@1146200 Oct 25] - page 268. (Read 625666 times)

Sell AEON
pm me offer

Try this thread : https://bitcointalksearch.org/topic/aeon-buy-and-sell-thread-1012944

Or start one on the Altcoin Marketplace

Hello community, i like cryptonote coins but i don't have any Aeon, is anybody interested in swap RD Red Wind for Aeon?

Aeon Max supply: ~18.4 million

RD Max supply: ~18.4 Billion

If so, PM me.

Thanks.

Thank you for the great feedback cryptrol!

The quote you cite is relevant, and as I said I want to both trim and prune the blockchain to keep it small.

However, even if you want not full nodes but lightweight SPV-like nodes on mobile devices, they still need to verify PoW (block headers). Currently on a low-end CPU verifying cryptonight takes about 500 ms, which means over 10 minutes to verify PoW for one day worth of 1-minute blocks. By reducing the number of blocks per day and switching to a faster PoW we can get this down to a minute or so, which I find closer to acceptable.

Also, I should add to the roadmap that I intend to merge both:

1. 32-bit and ARM support from Monero

2. Either the db code from Monero or the collection swapping from the cryptonote reference (unlike Bytecoin, the cryptonote reference is under the original MIT license, not GPL). I don't have a timeframe for this; I want to give Monero some more time to get the database deployed and see how it works there first. But ultimately it is essential for mainstream and mobile platforms.

Nice roadmap!
I am glad to see you pushing forward and I am willing to help with whatever I can.

I totally agree with the block time, alts have tended to smaller block times just as a marketing buzzword (" look we are faster than bitcoin!"), without taking into account that this alters security (forks) and usability (massive sync times). Speed must be achieved by other means, which you brilliantly address on point 5 with payment channels. Payment channels are one of the main reasons I was interested in multisig earlier in this thread and they provide the tools to make crypto transactions time more in line of what we are used nowadays with credit cards.

Regarding the PoW, I would say we will never see a mobile device running a full-node, but I always have this phrase in mind :

First, PoS is feasible but not in the short term. There are no other working implementations of cryptonote PoS yet, and developing one is beyond the resources available to this project right now. The only exception to that is the DPoS in XPB, which somewhat different from regular PoS, and not something I would like to pursue. Once there are open source implementations of cryptonote PoS we can consider adopting one. I lean toward a PoW+PoS hybrid that slowly tends toward PoS over time.

Second, the direction I would like to go is toward with this coin is to experiment with a lighter-weight variation of cryptonote that will be friendlier as a payment system for smartphones and other mobile devices. This requires initially some small tweaks and later significant blockchain improvements:

1. Mobile-friendly PoW (CryptoNight Lite). The current PoW is not ideal for smaller devices because the 2MB scratchpad is too large for the cache size on most mobile and lower-end desktop/laptop CPUs. A tweak to use a 1 MB scratchpad would allow it to run efficiently on lower end CPUs including some mobile processors as well as much better performance on mainstream desktops/laptops. Credit for this idea goes to the Louisd'or project (crypto_zoidberg and doe1138), although they didn't clearly explain the benefits of it.

2. Increased block time for fast syncing. The block time determines the number of blocks (or headers) that need to downloaded for syncing on a lightweight client, and in addition, most AEON blocks are currently empty, which is creating wasteful bloat. Finally, all cryptonote coins have higher verification costs compared with BTC forks which leads to more orphans. Instead we should use a 4 minute blocktime, which will reduce sync time by a factor of four, and reduce orphans to a minimum. Coupled with #1 we should improve sync time on lower end devices by at least 10x. Per-block rewards will be increased by 4x to maintain the same emission schedule.

3. Signature trimming for SPV-like clients. a) tweak the transaction format using a variation of the techniques from BBR. b) add a flag to the p2p to allow lightweight clients to not download and verify signatures. They would rely on miners to maintain the integrity of the blockchain, as with SPV wallets. Full nodes will continue to store the entire chain with all signatures.

4. Blockchain pruning for scalability. I propose to expire parts of the chain altogether. After some period of time unspent coins would become unspendable and could be pruned. This will allow the blockchain to stay small forever, and not outgrow small devices. Wallets will need to automatically respend coins that are approaching the expiration window back to the same wallet, or at least recommend that the user do so. There will be a longer grandfather period for existing coins but eventually they too would expire. A way of doing long-term (but not infinite) cold storage with a prepaid storage fee may be added later (likely along with multisig). This will also improve anonymity by reducing age-based attacks.

5. Multisig and payment channels for escrow, contracts and instant payments. Cryptonote coins currently rely on a very lightweight hard-coded scripting system that makes transactions very small, easy to verify, and more secure than full-fledged scripts. I would like to maintain that lightweight system, but add a few more hard-coded cases as required for multisig (escrow, and some forms of contracts) and payment channels (trustless instant payments). This will also require a tool set (library and applications) for implementing the real-time components of payment channels.

Roadmap (schedule target, subject to change according to available resources)

1,2. Tweaked PoW, blocktime (1 week)
2.1. Cryptonote GUI wallet integration (*)
3. Signature trimming  (1-2 month*)
4. Blockchain pruning (3-4 months*)
5. Multisig and payment channels (6 months*)

* subject to evaluation of wallet integration task

Also (planned but no specific schedule)

A. 32-bit and ARM support
B. Database or collection swapping (low memory footprint)

Although my interests are primarily in the area of blockchain technology and experimental improvements to the cryptonote protocol, I invite others to join the project and work on other items such as a GUI wallet (though we can likely adapt existing GUI wallets from other cyptonote coins), mobile wallets, marketing, etc.

I have created a new donation address for the project. The amount of donations received will have some influence on the pace of work, largely because it allows me to gauge the interest of the community in a credible way, and I'm less interested in working on something that no one cares about.


EDIT: Added 32-bit and ARM support, low memory

EDIT: Added cryptonote GUI wallet integration

PoS would be very good addition imo

What about this PoS, is it feasible?

I thought merged mining this with Monero was mentioned earlier. I guess not.

Dude, I'm on the wrong planet.

Merged mining? How? Where?
Aren't you in the wrong thread?

Instead of merged mining this with Monero I would like to see a pure PoS implementation of Cryptonote. I realize this is a big project but maybe on the roadmap this could be the final destination for Aeon.

Greetings Aeonians.

I'm preparing a new development plan for the coin going forward and I would iike to offer this as an opportunity for suggestions from the community. I have some of my own ideas but all serious ideas will be given serious consideration.

Just wanted to say I am moving on.
I have been diving a little into the monero code, TBH there where some small things that I didn't like (openalias, and some unnecessary refactoring of the bytecoin code base) and although it's in essence the same cryptonote technology I don't think it's worth the hassle to try to put time into coding the multisig into this monero fork which judging by it's network hash rate and this thread's activity it's pretty abandoned.
I guess I will have to stick with Bytecoin for the time being, which is more in line with my own views despite it's damn shadiness.

I can point out the issue. The original cryptonote white paper and the transaction types defined in cryptonote_basic.h allow for scripts but it was never implemented. So the task consists of implementing either enough of a scripting language (can be the one from the white paper or another, possibly even simpler, one) or just a special hard coded (no script) transaction type that allows for N/M multisigs. Then modifying the valid transaction type check and implementing code to verify the signatures. Overall it's a fairly simple task. The hard part is very careful coding and testing.

You can read a brief summary of some of the license issues here: http://stackoverflow.com/questions/459833/which-open-source-licenses-are-compatible-with-the-apples-iphone-and-its-offici

I guess I will have to dive inside the original source and the current monero codebase then
This will take some time.

Regarding the license, I thought LGPL was enough for most use cases, but honestly I know nothing about app stores.

I like the idea.

I don't like a license change that will make it impossible to deliver the code in a mobile app-store format (at least on iOS where static linking is required). This includes even lightweight wallets and transaction signing tools (such as using multisig for 2FA) using the code base as a library.

Note that Bytecoin does not suffer from this restriction because it is their own project so they can disregard the license. But with the change to LGPL they have inserted a bit of a poison pill for anyone else who wants to use their code.

I'd rather see the effort going into a new multisig implementation with a less restrictive license. That I would be 100% behind, and I might even contribute some funding for it if that matters. Given that the Bytecoin multisig solution doesn't rely on advanced cryptography and is essentially a basic scripting system (as I understand it, but I haven't examined it carefully), I don't see this as being particularly difficult.

Since you are the current maintainer, your opinion should have higher weight, as I said I am really interested in multisig, what would you think about going the other way around, that is, including the multisig transactions in the monero fork?

I just want to know your opinion since right now I don't know the efforts required to do this, and would need help.

I am opposed, as I think that a project started as a Monero fork should remain a Monero fork absent some good reason for a change (such as Monero becoming unmaintained).

And as I said, I believe the demand for a Bytecoin fork is adequately met by Dashcoin.

Finally, if for some reason you don't like Dashcoin, and you don't feel being a Monero fork is a good path, you can start a new Bytecoin fork.

However, if there is strong community support for turning AEON into a Bytecoin fork I will step aside.

So, the AEON blockchain can be run with both the Bytecoin (current) client and the AEON fork.

I have a couple of nodes running with the modified Bytecoin source and mining blocks.
There is an issue with the synchronization from scratch because Bytecoin introduced a growing block size cap during some of the last years update,
so I will have to figure out the correct params for the AEON blockchain since right now there is no block cap other than CRYPTONOTE_GETBLOCKTEMPLATE_MAX_BLOCK_SIZE.

But before going any further I would like to know if there is people interested in putting some work on this, since obviously maintaining a coin alive involves some work.

My development plan would be changing the codebase of AEON to the current Bytecoin code in order to :
- Be able to use multisig (this would provide us with a very powerful tool to further develop minimum trust apps around AEON). Multisig transactions are not untraceable, so by using it you can opt-out of anonymity (this is useful in many cases where you want to provide transparency).
- Have a client ready that does not take 3 Gb or RAM to run, and have it as fast as we can.

I know this changes the path initiated as a Monero fork by AEON but I seriously consider multisig essential and this last bytecoin update provides just that, so we could be up and running with it relatively fast and build apps around it. I have been considering to build a fork myself, but I really consider that we do have enough alts

So please state your views, either positive or negative, on this and also mention what can you provide to the project (skills, resources, whatever ) so we can move on as a community.

I am willing to contribute coding and devops for the project, as well as some project management.
Also, it would be nice to have the initial developer opinions and help  
Your turn.

I will have to take a look to the monero code base.

BTW, I managed to run the AEON blockchain using the new Bytecoin codebase, the runninng daemon is "only" 500Mb.  :



It works, gets transactions and synchs with peers, of course it needs a lot of testing, and there is a bug that prevents from synching from 0, this may also be a bug in bytecoin. But converting the blockchain to the new format works. I will post my findings here.

EDIT: And I mined a block with the daemon, let's see if it gets accepted